Stephen, Sorry for the delay in responding - life got in the way...
Stephen Hicks wrote: > In my mind, those two models are not mutually exclusive. When I use the > mouse wheel to initiate a scrollback, I do tend to be in the second model, > but on the keyboard, how I enter copy mode is more related to whether the > thing I'm looking for is on the screen or not, in addition to whether I'm > searching, scrolling, or copying. No, not mutually exclusive but when nicm said to also remove the -e option, I didn't see how your proposed changes would allow me to retain the mode I ues. > My setting looks roughly like this: > > bind [ copy-mode > bind -n S-PgUp copy-mode -u > bind -T copy-mode PgUp send-keys -X page-up > bind -T copy-mode S-PgUp send-keys -X page-up > bind -T copy-mode PgDn send-keys -X page-down > bind -T copy-mode S-PgDn send-keys -X page-down-maybe-cancel I wonder if a simpler way would be to define two new copy mode commands, autoexit-on and autoexit-off. It's not quite ideal as two commands, as it smells more like an option but there are no pane options or copy mode options. With these two commands, you could replace 'copy-mode -e' with 'copy-mode; send-keys -X autoexit-on' and you could replace your bindings with a similar sequence that sends autoexit-off then page-down, or autoexit-on then page-down, etc. That is, give control of the basic components needed to compose the higher-level behaviour. I'd be happy with getting rid of copy-mode -e with something like this If I seem a little defensive of copy-mode -e its because I added it :-) Cheers, Cam > On Wed, Oct 25, 2017 at 7:37 PM, Cam Hutchison <c...@camh.ch> wrote: > > > On 26 October 2017 at 05:39, Stephen Hicks <stephenhi...@gmail.com> wrote: > > > I appreciate the patch that went in a while back to add "copy-mode -e", > > > allowing to automatically exit copy-mode when reaching the bottom of the > > > buffer. But I find that this functionality is a bit of "spooky action > > at a > > > distance": the decision to exit depends not on the input the caused the > > > scroll-down, but instead of the input that initially scrolled up. > > > > I'm not sure I understand your use case or your issue with the current > > behaviour. Is it just the "spooky action at a distance" that you object to? > > > > The current behaviour is intended to model two different ways that copy > > mode can be used: > > > > 1) The normal mode where you are copying data out of the scrollback > > buffer, searching through it, or some other explicit action. This mode > > requires you to take an equally explicit action to exit. > > > > 2) Scrollback mode, where you are just scrolling back through the > > terminal history. In this mode, you enter typically with just a PageUp > > or ScrollUp event, not a binding that is explicitly copy-mode. This > > way, exiting mirrors your entry - when you scroll back to where you > > started, you're no longer in copy mode. > > > > I don't understand the "spooky action at a distance" (I get that how you > > enter the mode defines how you can exit the mode, but that's all related > > and not spooky unrelated stuff, or at a distance). > > > > I can't see how your approach allows the distinction between these two > > use cases to be retained. Perhaps using separate key tables, but that > > feels like a lot of extra configuration. > > > > Can you explain why you want to change this? > > > > > > > > I've put together a small patch to allow opting into the auto-exit > > behavior > > > on scroll-down commands instead. Currently I've overloaded the > > send-keys -R > > > argument (which seems somewhat appropriate given that exiting copy-mode > > is a > > > sort of "reset"), but I'd also be happy to find a different way to pass > > the > > > option (either adding an additional argument to send-keys, or adding > > > scroll-down, etc, to the 1-arg branch so that you'd write "send-keys -X > > > scroll-down -e", though in that case I'm not sure what to do if the > > argument > > > is anything *other* than -e - currently it silently does nothing if a > > > command has the wrong (number of) arguments, which isn't great. > > > > > > Please let me know how to proceed so that this functionality can be > > added. > > > Or if you'd rather continue on a GitHub pull request, that would be > > great as > > > well. > > > > > > Thanks! > > > steve > > > > > > -- > > > 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.
