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.
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 So if I'm just scrolling, I'll use Shift-PgUp/Dn and when I get to the bottom, I'm back in normal mode. But if I see something and change my mind in the middle of scrolling, I'll let go of Shift and I no longer get dropped out (say I want to copy something from the bottom page after all). If I'm searching for a specific string, or looking to copy some text, I'll use either Prefix-[ or S-PgUp, depending on where the text I'm looking for is - they have different behaviors in terms of which page I end up looking at, so it seems like an orthogonal concern whether hitting the bottom again is going to cancel. Rather, it makes a lot more sense to me that the key I'm hitting *right now* is going to determine the immediate behavior. Finally, I don't think we necessarily need to have only one way to do this. I imagine the separate models approach makes a lot of sense to a fraction of users; just not to me. I've been using a patched tmux with this behavior for several years now and it's been really nice - I just figured it would be helpful to finally upstream the feature now that I'm finally merging and rebuilding again, in case others find it useful as well. On Wed, Oct 25, 2017 at 7:37 PM, Cam Hutchison <[email protected]> wrote: > On 26 October 2017 at 05:39, Stephen Hicks <[email protected]> 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 [email protected]. > > To post to this group, send email to [email protected]. > > 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.
