Thanks for the feedback! Would this application fit? https://github.com/junegunn/fzf
Yes, a 'display-message' would be fine for a non-interactive script. For an interactive, I just couldn't figure out the pane management aspects. I don't know all the dark corners of tmux. Is there already a similar mode for a pane? The only thing in that direction would be a zoomed pane. Dru Redwood City, California On Fri, Nov 16, 2018 at 2:12 AM Nicholas Marriott < nicholas.marri...@gmail.com> wrote: > Hi > > The idea sounds quite good and makes sense - what you are suggesting is > mainly an alternate screen stack. However, if you want to add a > completely new escape sequence, especially one that is relatively > complicated, I'm not going to just hope someone will use it - you'll > need a patch for at least one relatively mainstream application and a > clear sign they will merge it. > > What would be nicer for tmux itself is to add a way to display text as > an overlay within a pane by using an existing command (such as > display-message). This could be done by adding a new mode that (like > copy mode) just copies the existing pane content then draws whatever you > specify on top. This would probably be more convenient for scripts but > less so for applications. > > Thanks > > > On Thu, Nov 15, 2018 at 03:16:20PM -0800, Dru Nelson wrote: > > 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 thinkingA 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: > > A pros: > > A A - no new ANSI terminal protocol > > A A - gives the new program its own pty > > A A - guarantees zero interference to underlying pane (content, > terminal > > states, pty state) > > A A - this would open it up for bash or less sophisticated programs > > A cons: > > A A - this would require another pane type > > A A - this would complicate pane management and layout > > A A - UI for pane border etc would be up for debate > > A A - (weak one) requires tmux > > new 'stackable screen buffer'.A > > A pros: > > A A - (huge) no changes to tmux pane system > > A A - might become something other terminals eventually support > > A cons: > > A A - 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: > > A - Send sequence to create new 'stackable screen buffer' > > A - Set exit handler to send 'stackable screen buffer' reset sequence > > A - Set tty raw/etc. modes > > A - Set exit handler to restore tty modes > > A - Draw your window at passed in rect > > A - Perform interactions > > A - exit > > Thanks for reading so far.A > > 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 tmux-users+unsubscr...@googlegroups.com. > > To post to this group, send email to tmux-users@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > -- 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 tmux-users+unsubscr...@googlegroups.com. To post to this group, send an email to tmux-users@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
