Re: add non-chord keys to repeat isearch

[Alan Mackenzie]

Hi, Drew!

On Wed, Jun 10, 2009 at 10:32:17AM -0700, Drew Adams wrote:
> > > Precisely the point. Which do you repeat 14 times in a row, 
> > > `scroll-up' or `isearch-repeat-forward'?

> > Scrolling up and down, actually.  Thought the "repetition" is 
> > more often at different matches: something like C-s <next>
> > <prior> C-s C-s <next> <prior> <next> C-s, ....

> (That's not repetition. That's thrashing: scrolling once, then undoing the
> scroll.  <next> <next> <next> is repeating.)

No, it's not thrashing.  Scrolling doesn't _do_ anything, so there's no
undoing involved.  Scrolling here is for looking at the buffer.  The
sequence I described is repetition, necessitated by the limitations of
the hardware, namely that the screen isn't infinitely tall.

> Just use `C-l'. Repeating it (twice) puts you back where you were. It
> works fine with non-nil `isearch-allow-scroll' (thank you for that).

Yuck!  (Highly customised emotional reaction ;-)  Functions which "do the
Right Thing" in this manner aren't my cup of tea.  One of the first
things which will be going into my .emacs when Emacs 23 gets released is
a rebinding for C-l back to `recenter'.  OK, I know that
`recenter-top-bottom' is recenter that `recenter', but I haven't actually
got a top bottom, nor do I bare any recentment against that change.

I've got my own functions to scroll point to the top and bottom of the
screen, but I still want <prior> and <next> to work in Iscroll.

> > > Using a chord to scroll is not a biggee. Especially since
> > > apparently repeating `C-v' in Isearch has no effect.  If you can do
> > > `C-v' only once in a row, pinky can have no complaint.

> > It's a biggee for me. It's having to shift between C-v and M-v.

> Just use `C-l'.

No.  (See above)  ;-)

> > What happens often is that C-s finds a match 2 lines above the bottom
> > of the window, and you need to see the line just below the window to
> > see if you've found the right match, yet.  That bugged me so badly
> > that I wrote the scrolling feature.

> Just use `C-l'.

No.  (See above)  ;-)

> > <next> and <prior> are much easier to type alternately than C-v and
> > M-v.

> `C-l' is even easier. Repeat, don't alternate at all. No need for two
> different keys to do what you want, and no need to leave the home row
> of the keyboard.

Yuck!  (See above)  ;-)

> > I do this often enough for it to matter to me.
> > > > I quite often scroll up and down in rapid succession (in
> > > > isearch),

> > Actually, although I'm not in favour of making your bindings a
> > standard default, I wouldn't be that vehement in arguing against
> > them.

> As a compromise, we could bind <next> and <prior> in Isearch to
> commands that do what you want when `isearch-allows-scroll' is non-nil,
> and that repeat Isearch when it is nil.

This might be the worst thing to do, combining complexity with a
compromise that doesn't really suit anybody.

> (I personally will use those keys for repeated Isearch even though I
> now use non-nil `isearch-allows-scroll' (thank you) - but that's a
> personal customization.)

Just as I will carry on using them as they currently are, even if I have
to do my own customisation.

> Suggestion #1: Since repeated `C-v' and repeated `M-v' are no-ops in
> your scrolling context, you might consider letting each of them toggle
> between the two: scrolling up/down. That way, you could use `C-v C-v'
> or `M-v M-v' instead of `C-v M-v' or `M-v C-v'. Just a suggestion.
> Either of those is slightly shorter and less distracting than `C-l C-l
> C-l'.

I suppose so.  But in which direction does the first C-v go, and what key
sequence would you need to change that direction?

> But if you decide to make no change in this regard, at least provide
> some feedback, to let users know that repeating the scrolling command
> is not supposed to have any effect. Users naturally expect repeating
> these commands to keep scrolling - let them know that not doing so is
> intended, not a bug.

I'm not sure how this can be done, since the minibuffer is already in use
for the search string.  Given that the current match is highlighted at
an edge of the window, I'm not sure it's really needed.  Of course,
sometimes the match is too small for the highlighting to be seen.

> Suggestion #2: Add some info to the doc string for
> `isearch-allow-scroll', to let users know that it is not just
> "scrolling commands" (unclear just what that means) that are affected,
> but any command whose symbol has non-nil property `isearch-scroll'.
> That's important information for users:

> 1. It helps them discover that commands such as `C-l', which they might
> not think of as "scrolling commands" can also work here. (`recenter' is
> mentioned in the Emacs manual, but not in the doc string. BTW, `C-l' is
> no longer `recenter', by default.)

> 2. It lets them know that _they_ can add or remove commands for which
> scrolling is allowed, and how to do that. This feature means the option
> can act not only as a general boolean - the behavior can be
> command-specific. This info is in the Emacs manual, but it would help
> to mention it in the doc string - it has a major impact on the option's
> behavior.

As you say, all that information is in the Emacs manual.  I think that
this property is already on pretty much every command for which it makes
sense and is valid.  I also think that modifying this set of commands
would be a very rare thing to want to do; I can't really see anybody
wanting the property on `scroll-up' but not `recenter', for example.

But yes, the doc string for isearch-allow-scroll is rather terse.

-- 
Alan Mackenzie (Nuremberg, Germany).