Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiline message composition #89

Open
swantzter opened this issue Jan 27, 2021 · 1 comment
Open

Multiline message composition #89

swantzter opened this issue Jan 27, 2021 · 1 comment

Comments

@swantzter
Copy link

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

@glguy
Copy link
Owner

glguy commented Jan 28, 2021

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.

glguy added a commit that referenced this issue Jan 31, 2021
Default configuration toggles this with `/toggle-editor` and F6

See #89
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants