"GOT", but the "O" is a cute, smiling pufferfish. Index | Thread | Search

From:
Stefan Sperling <stsp@stsp.name>
Subject:
Re: [rfc] compound keymaps with prefixed count modifier like vi(1)
To:
Mark Jamsek <mark@jamsek.com>
Cc:
gameoftrees@openbsd.org
Date:
Tue, 21 Jun 2022 18:56:41 +0200

Download raw body.

Thread
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.

> 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?