Have you got some key bindings that do copy-mode -e and some that just do plain copy-mode?
On Sun, Oct 29, 2017 at 01:17:37PM +1100, Cam Hutchison wrote: > 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. -- 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.
