Multiline message composition

[Svante Bengtson]

It would be great to be able to read the entire message you're composing before sending. right now it scrolls horizontally as you compose. The tricky part I guess would be to distinguish it from M-enter. I've got some idea's: A new message created by M-enter adds a new ^ and $, an overflowing/line-wrapped message doesn't. for example:

^this is a message$
^this is another message by M-enter. this one is also too long
 to fit on one line and therefore wraps.$

Alternatively messages could wrap, unless you use M-enter

[Eric Mertens]

The concerns I had when writing the current logic:

• I should always be able to tell if I'm looking at the beginning or end of the input, or if the line has scrolled off one edge or the other.
• I should always be able to identify whitespace at the beginning or end of a line of input.
• I should be able to have multiple lines of input queued up as a single unit.
• It should be clear which line is the first line; this is the line that will be transmitted when pressing enter
• The input buffer should be able to contain a multi-line paste.

Questions/concerns with multiline:

• Does up go to previous edit line in current buffer to previous entry in history? I probably need two bindings.
• Does the cursor have to jump suddenly from one side of the screen to the other instead of staying local like it does now.
• How configurable is the height of the new edit mode. I probably need to keep the old behavior around for when it's configured to 1 high.
• The new behavior shouldn't be drastically different from the old behavior if both of them are going to exist at the same time.
• Does the edit box have a maximum height (other than window size)? I'm imaging that it won't be common to have a screenful of input text, so there might be no reason to truncate it.
• I could support both rendering modules; it would be easy to toggle between the two for some reason with a hot key.

I like the idea; I just need to figure out the corner cases.