Thanks Nicholas - I will start working on getting a patch merged with fzf
and a simple implementation for tmux.

Dru
Redwood City, California

On Fri, Nov 16, 2018 at 12:41 PM Nicholas Marriott <
[email protected]> wrote:

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

Reply via email to