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)

> [...]
>
> 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?

(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 :)


Thanks,

Omar Polo