Hi,
I use and enjoy tmux and I want to implement a new terminal overlay feature.
The TLDR is at the bottom.
The use case for this feature is for pop-up suggestion windows on my shell
command line. There are quite a few like this. However, they typically hack
around the difficult issue of restoring the screen by requiring the content
to be displayed below the command line. They implement this by forcing the
shell output to scroll up and then display the pop-up in the new space at
the bottom. These hacks can be quite jarring and would look much nicer if
they followed typical UI behaviors.
Some of them use the 'alternate screen buffer'. The problem with those is
that it clears the screen so you lose all the context.
After thinking about it some more, I came to the conclusion that this
problem would be much easier if the terminal had some overlay support. I
believe that support would be best realized as a new 'stackable screen
buffer' feature.
Here is my thought process. I considered two possibilities:
1. Implement this as a pane in tmux.
2. Implement this as a new 'alternate screen buffer' in the terminal. In
this version, the alternate screen buffer *does not* erase the previously
displayed data. Essentially, this lets the client paint over the screen.
Also, these could be stacked. When the 'alternate screen mode' was reset,
it pops that overlay off of the stack and restores what was beneath.
Here are the pro's and cons of both:
new pane in tmux:
pros:
- no new ANSI terminal protocol
- gives the new program its own pty
- guarantees zero interference to underlying pane (content, terminal
states, pty state)
- this would open it up for bash or less sophisticated programs
cons:
- this would require another pane type
- this would complicate pane management and layout
- UI for pane border etc would be up for debate
- (weak one) requires tmux
new 'stackable screen buffer'.
pros:
- (huge) no changes to tmux pane system
- might become something other terminals eventually support
cons:
- More complex on the client side.
The 'no changes to tmux pane system' feels like the winner. I think it will
be the smallest change with the greatest impact.
Client complexity is unavoidable do to the design of the Unix tty system.
Vim, 'less', and every other interactive shell program already has to be
careful about restoring the tty state on exit.
TLDR
Given the above, I would like to implement a new 'stackable screen buffer'.
I would be happy to implement this and submit the patch.
- It will not clear the screen.
- It would use DEC Private Mode '2010'.
- It would push any previous buffer (normal, legacy alternate buffer, or
new alternate buffer) on a 'set'. It will 'pop' and restore on a 'reset'.
- It would store the cursor position *and* any other terminal state on a
'set' and restore previous on a 'reset'
If a shell invoked a command that utilized this mode. It would be the
shell's responsibility to pass the desired rect for the command to operate
in.
A typical command flow would be:
- Send sequence to create new 'stackable screen buffer'
- Set exit handler to send 'stackable screen buffer' reset sequence
- Set tty raw/etc. modes
- Set exit handler to restore tty modes
- Draw your window at passed in rect
- Perform interactions
- exit
Thanks for reading so far.
What do you think?
Dru
Redwood City, California
--
You received this message because you are subscribed to the Google Groups
"tmux-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
