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.
> 
> 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. For example, with the current diff:

$ tog tree regress/cmdline
2<backspace>
# move up two levels to root /

If we use backspace to abort input, the same sequence will only return
to /regress (i.e., up one level).

I did think about aborting input; however, at present, any non-numeric
input that is not a valid key map will abort and reset counter input to
0. Similarly, because we only block for half a second, momentarily
delaying input will also abort the counter. For example:

$ tog
99x5j # abort 99 counter input and move down 5 lines
3xj   # abort 3 ... move down 1 line

does the same as:

$ tog
99 *wait >500ms* 5j
3 *wait >500ms* j

Are you thinking about something more explicit such that the above would
be done with:

$ tog
99 <abortkey> 5j
3 <abortkey> j

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?

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?

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