You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
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:Alternatively messages could wrap, unless you use M-enter
The text was updated successfully, but these errors were encountered: