On 22-06-22 04:08pm, Omar Polo wrote:
> Mark Jamsek <mark@jamsek.com> wrote:
> > On 22-06-21 06:56pm, Stefan Sperling wrote:
> > > On Wed, Jun 22, 2022 at 01:08:49AM +1000, Mark Jamsek wrote:
> > > > I got the idea from naddy the other day when he mentioned the behaviour
> > > > of less(1) in the discussion about C-d/C-u d/u. It's something I use in
> > > > vim a lot too, so I wanted to see how others feel about it.
> > > > 
> > > > I figured it'd be easier to explain with an example so the following
> > > > diff demonstrates the intended behaviour. Basically, for movement
> > > > keymaps, they can be prefixed with a count modifier, which determines
> > > > how many times the requested movement is performed.
> > > > 
> > > > For example, 123j will move down 123 lines, and 3f will scroll down
> > > > 3 pages. I like the diff context where n] will increase context by
> > > > n lines, which is like the ^v context buttons in Fossil and GitHub to
> > > > expand the diff in large chunks.
> > > 
> > > Yes, having n] and n[ would be very useful in particular.
> > 
> > That was the main impetus after I got the idea from naddy's comments.
> > 
> > > > This is just a feeler. I added some hints to the docs but if you use
> > > > this in less or vim it's pretty much the same behaviour except with
> > > > C-d/C-u: in less(1) and vi(1), nC-d or nC-u will scroll n lines--not
> > > > half pages. In vi(1), nC-b and nC-f will scroll n pages, but in less(1)
> > > > it will scroll n lines. I think it's more useful and consistent to
> > > > modify the normal scroll amount because we can already move n lines with
> > > > the normal jk and up/down keys.
> > > > 
> > > > The only thing I'm not sure is whether I prefer massaging view->count at
> > > > each keymap case in the input handlers or if I'd rather validate in one
> > > > routine at input but I wanted to get comments first.
> > > 
> > > No objections here to the general idea.
> 
> I like the feature too!
> 
> > > Perhaps there should be a way to abort input of the counter, by typing
> > > a special key (e.g. backspace) while the number is being read?
> > 
> > Backspace wouldn't quite work because it's the tree key map to return
> > to the parent directory.
> 
> I was a bit surprised by how it's implemented to be honest.  I would
> have expected something like how the "/" works: showing the number as
> it's typed in the last line of the window.  This would allow to have
> backspace (and any other key we want) available without issues.
> 
> it would also mirror what less(1) does.  (but admittedly less(1) doesn't
> have backspace bound to anything by default in the "global" keymap)

That would be my vim bias, tbh. In vim, you have the (t)timeoutlen
setting to configure how long to wait between keys when entering
compound key maps. Also, the number isn't echoed to the screen either.
That's really the only reason I implemented it this way.

> > [...]
> >
> > This also raises the question: is 500ms a good timeout or would
> > something slightly longer or even configurable with an envvar, for
> > example, be preferable? I have key maps timeout at 1000ms in vim and key
> > codes at 100ms, but I thought given we would have just the one simple
> > compound mapping in tog (i.e., nKEY), we could use a short timeout.
> > Perhaps we could start with this and later make it configurable if it
> > feels warranted?
> 
> This is another thing that quite surprised me: why a timeout in the
> first place?

No real reason apart from that's what I'm used to. I use this in vim
a lot more than less(1).

> (with a "hidden" counter I see why the timeout, but if we show the
> number being typed, then we don't need the timeout I guess)
> 
> > I'm happy to add an explicit abort key, or do you think documenting the
> > timeout and how that cancels a preceding count modifier would suffice?
> > If we add an abort key, what should we use if not backspace?
> 
> abort keys are IMHO one of the weakest point of tog :)
> 
> (i've lost the count of the times I've pressed C-c, C-g, ESC and every
> possible other key to abort a search before realizing i was inside tog
> and it just doesn't work.)
> 
> If I can suggest something here, I'd go with with C-g.  I'm biased
> because Emacs uses it to interrupt various kinds of things, but less(1)
> uses it too.  ESC maybe would be familiar for vi users?
> 
> Anyway, don't mind my questions, I've realized that most of the times
> when something doesn't work as I expect it's actually for a good reason
> and my expectations were wrong in the first place :)
> 

I prefer the timeout approach, but I'm happy to change it if you think
it's better? I don't have any real argument apart from that's just what
I'm accustomed to so I haven't even given much thought to what could be
the "better" approach.

-- 
Mark Jamsek <fnc.bsdbox.org>
GPG: F2FF 13DE 6A06 C471 CA80  E6E2 2930 DC66 86EE CF68