add non-chord keys to repeat isearch

add non-chord keys to repeat isearch

[Drew Adams]

I often repeat `C-s' (same search string), over and over and over.
You too, right?  Poor pinky.

(define-key isearch-mode-map [next]  'isearch-repeat-forward)
(define-key isearch-mode-map [prior] 'isearch-repeat-backward)

Duh! Why I never bothered to do that before, I dunno. I've been doing it forever
in Framemaker (which doesn't have incremental search), but I never thought to do
it for Emacs too. Blinded by habit, I guess.

I propose that Emacs do the same thing out of the box.

Someone (Richard?) will no doubt argue that he prefers to have `next' exit
Isearch and move down a page, and similarly for alternative bindings one might
propose here. And perhaps there will be other arguments against (I know some
people just don't like adding bindings to `isearch-mode-map'). But to me this is
a no-brainer (now that I think of it ;-)).

WDOT?

P.S. No removal of any bindings, just addition of these two.
You can still use `C-s C-s C-s C-s C-s C-s' if you prefer.

Re: add non-chord keys to repeat isearch

[Deniz Dogan]

2009/6/9 Drew Adams <drew.adams@oracle.com>:
> I often repeat `C-s' (same search string), over and over and over.
> You too, right?  Poor pinky.
>
> (define-key isearch-mode-map [next]  'isearch-repeat-forward)
> (define-key isearch-mode-map [prior] 'isearch-repeat-backward)
>
> Duh! Why I never bothered to do that before, I dunno. I've been doing it forever
> in Framemaker (which doesn't have incremental search), but I never thought to do
> it for Emacs too. Blinded by habit, I guess.
>
> I propose that Emacs do the same thing out of the box.
>
> Someone (Richard?) will no doubt argue that he prefers to have `next' exit
> Isearch and move down a page, and similarly for alternative bindings one might
> propose here. And perhaps there will be other arguments against (I know some
> people just don't like adding bindings to `isearch-mode-map'). But to me this is
> a no-brainer (now that I think of it ;-)).
>
> WDOT?
>
> P.S. No removal of any bindings, just addition of these two.
> You can still use `C-s C-s C-s C-s C-s C-s' if you prefer.

I have no idea what the "next" and "prior" keys mean. Could you please
explain? Thanks.

-- 
Deniz Dogan

RE: add non-chord keys to repeat isearch

[Drew Adams]

> I have no idea what the "next" and "prior" keys mean. Could you please
> explain? Thanks.

They are the (pseudo-function) keys that are typically labeled `Page Down' and
`Page Up'. (They are often next to the keys labeled `Home' and `End'.)

Their Emacs names are often written `<next>' and `<prior>'. (I tend to drop the
angle brackets.) When binding, they are written [next] and [prior].

Re: add non-chord keys to repeat isearch

[Alan Mackenzie]

Hi, Drew!

On Tue, Jun 09, 2009 at 08:44:41AM -0700, Drew Adams wrote:
> I often repeat `C-s' (same search string), over and over and over.  You
> too, right?  Poor pinky.

Mine doesn't seem to mind at all.  But I know some do.

> (define-key isearch-mode-map [next]  'isearch-repeat-forward)
> (define-key isearch-mode-map [prior] 'isearch-repeat-backward)

> Duh! Why I never bothered to do that before, I dunno. I've been doing
> it forever in Framemaker (which doesn't have incremental search), but I
> never thought to do it for Emacs too. Blinded by habit, I guess.

> I propose that Emacs do the same thing out of the box.

> Someone (Richard?) will no doubt argue that he prefers to have `next'
> exit Isearch and move down a page, and similarly for alternative
> bindings one might propose here. And perhaps there will be other
> arguments against (I know some people just don't like adding bindings
> to `isearch-mode-map'). But to me this is a no-brainer (now that I
> think of it ;-)).

> WDOT?

Please don't.  These two keys are already used in Isearch Mode for
scrolling.  To see this, set `isearch-allow-scroll' to t.  Then <next>
and <prior> are handy keys for seeing more text around the match without
having to leave isearch and start again.

The same applies to any keys bound to commands which have the
`isearch-scroll' non-nil.

I can't think of any more suitable keys for this - maybe keypad-+/-, or
keypad-del/enter, but they're probably not reliably on all keyboards.
Sorry to be so negative.

> P.S. No removal of any bindings, just addition of these two.
> You can still use `C-s C-s C-s C-s C-s C-s' if you prefer.

-- 
Alan Mackenzie (Nuremberg, Germany).

RE: add non-chord keys to repeat isearch

[Drew Adams]

> Please don't.  These two keys are already used in Isearch Mode for
> scrolling.  To see this, set `isearch-allow-scroll' to t.  Then <next>
> and <prior> are handy keys for seeing more text around the 
> match without having to leave isearch and start again.

(I wasn't aware of that option. I've just filed a bug to index it in the Emacs
manual.)

However, just because some binding was made previously (when someone first had
the idea of scrolling without exiting Isearch) is no reason not to reconsider
that binding in light of a better suggestion. Emacs is not purely
first-come-first-served.

`M-v' and `C-v' can be used for scrolling (when the option is non-nil).
And `<prior>' and `<next>' can be used for repeat search. There's room for all.

[BTW, scrolling during isearch doesn't seem to work beyond a single screen
height. Is that a bug or a feature? IOW, `C-s C-v C-v': the second `C-v' has no
effect.]

> The same applies to any keys bound to commands which have the
> `isearch-scroll' non-nil.

That's fine, but a specific key binding can override that. We can choose to bind
`<prior>' to `isearch-repeat-backward' even though `scroll-up' has non-nil
property `isearch-scroll'. Works fine. There is no need to sacrifice all keys
that might be bound globally to `scroll-up'.

Re: add non-chord keys to repeat isearch

[Deniz Dogan]

2009/6/9 Drew Adams <drew.adams@oracle.com>:
>> Please don't.  These two keys are already used in Isearch Mode for
>> scrolling.  To see this, set `isearch-allow-scroll' to t.  Then <next>
>> and <prior> are handy keys for seeing more text around the
>> match without having to leave isearch and start again.
>
> (I wasn't aware of that option. I've just filed a bug to index it in the Emacs
> manual.)
>
> However, just because some binding was made previously (when someone first had
> the idea of scrolling without exiting Isearch) is no reason not to reconsider
> that binding in light of a better suggestion. Emacs is not purely
> first-come-first-served.
>
> `M-v' and `C-v' can be used for scrolling (when the option is non-nil).
> And `<prior>' and `<next>' can be used for repeat search. There's room for all.
>
> [BTW, scrolling during isearch doesn't seem to work beyond a single screen
> height. Is that a bug or a feature? IOW, `C-s C-v C-v': the second `C-v' has no
> effect.]
>
>> The same applies to any keys bound to commands which have the
>> `isearch-scroll' non-nil.
>
> That's fine, but a specific key binding can override that. We can choose to bind
> `<prior>' to `isearch-repeat-backward' even though `scroll-up' has non-nil
> property `isearch-scroll'. Works fine. There is no need to sacrifice all keys
> that might be bound globally to `scroll-up'.

Why not add an option to let the user decide?

-- 
Deniz Dogan

Re: add non-chord keys to repeat isearch

[Alan Mackenzie]

Hi, Drew!

On Tue, Jun 09, 2009 at 10:08:34AM -0700, Drew Adams wrote:
> > Please don't.  These two keys are already used in Isearch Mode for
> > scrolling.  To see this, set `isearch-allow-scroll' to t.  Then <next>
> > and <prior> are handy keys for seeing more text around the 
> > match without having to leave isearch and start again.

> (I wasn't aware of that option. I've just filed a bug to index it in
> the Emacs manual.)

> However, just because some binding was made previously (when someone
> first had the idea of scrolling without exiting Isearch) is no reason
> not to reconsider that binding in light of a better suggestion. Emacs
> is not purely first-come-first-served.

That someone was me, by the way.

> `M-v' and `C-v' can be used for scrolling (when the option is non-nil).
> And `<prior>' and `<next>' can be used for repeat search. There's room
> for all.

What about people's poor pinkies while operating those key sequences?
;-)

Of course, another idea would be to allow C-s (etc.) to get a repeat
count - wouldn't be at all hard to do.  C-u C-u C-s could take you a
long, long way.

> [BTW, scrolling during isearch doesn't seem to work beyond a single
> screen height. Is that a bug or a feature? IOW, `C-s C-v C-v': the
> second `C-v' has no effect.]

It's a feature as far as I'm concerned, a bug to a few others.  In Emacs,
point is always in the Window, so this carries over quite naturally to
the whole isearch match staying in the window, too.  The other design
alternative would have been to allow point to scroll to the top/bottom of
the window even when that would put part of the match outside it.

As a matter of interest, you can give a repeat count to scroll that
number of lines.

> > The same applies to any keys bound to commands which have the
> > `isearch-scroll' non-nil.

> That's fine, but a specific key binding can override that. We can
> choose to bind `<prior>' to `isearch-repeat-backward' even though
> `scroll-up' has non-nil property `isearch-scroll'. Works fine. There is
> no need to sacrifice all keys that might be bound globally to
> `scroll-up'.

For consistency, the same operation (modulo your above comment) should
have the same key binding(s) inside and outside Isearch Mode.  If any
(non self-inserting) keys have a standard meaning throughout "all"
computer programs, it's surely <prior> and <next>.

Another argument in their favour is that anybody who's scrolling up and
down within Isearch is in a mode where there's no cost in using keys not
in the home position.  I quite often scroll up and down in rapid
succession (in isearch), and would find switching between C-v and M-v
intolerably awkward.

-- 
Alan Mackenzie (Nuremberg, Germany).

RE: add non-chord keys to repeat isearch

[Drew Adams]

> > `M-v' and `C-v' can be used for scrolling (when the option 
> > is non-nil). And `<prior>' and `<next>' can be used for
> > repeat search. There's room for all.
> 
> What about people's poor pinkies while operating those key sequences?
> ;-)

Precisely the point. Which do you repeat 14 times in a row, `scroll-up' or
`isearch-repeat-forward'?

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.

> Of course, another idea would be to allow C-s (etc.) to get a repeat
> count - wouldn't be at all hard to do.  C-u C-u C-s could take you a
> long, long way.

Are you being serious or facetious? When searching, you typically want to see
the next search hit to decide whether you want to move on to the one after that.

> > [BTW, scrolling during isearch doesn't seem to work beyond a single
> > screen height. Is that a bug or a feature? IOW, `C-s C-v C-v': the
> > second `C-v' has no effect.]
> 
> It's a feature as far as I'm concerned, a bug to a few 
> others.  In Emacs, point is always in the Window, so this
> carries over quite naturally to the whole isearch match
> staying in the window, too.  The other design
> alternative would have been to allow point to scroll to the 
> top/bottom of the window even when that would put part of the
> match outside it.

Whatever. 

IMO, it's not a great design (since we can't rightfully call it a bug). Suppose
you want to check occurrences of `foo' in Info, and you're looking for something
specific in the context of `foo', but it's not feasible or easy to add that
something to the regexp search string, so you just use `C-s foo'.

You can easily see a windowful of `foo' hits, thanks to lazy highlighting - very
helpful. It's often easy to scan those visually without actually moving point
among them. You can pretty easily tell if you see the context of interest
somewhere among the hits, most of which are more or less noise.

This is what to me would be a typical use case for scrolling during Isearch. And
in this use case, there is no reason to limit scrolling to a single scroll. On
the contrary; I would want to keep scrolling, letting lazy Isearch highlight
indicate the hits, but not bothering to move point among them.

> As a matter of interest, you can give a repeat count to scroll that
> number of lines.

Not a matter of much interest, to me.

> > > The same applies to any keys bound to commands which have the
> > > `isearch-scroll' non-nil.
> 
> > That's fine, but a specific key binding can override that. We can
> > choose to bind `<prior>' to `isearch-repeat-backward' even though
> > `scroll-up' has non-nil property `isearch-scroll'. Works 
> > fine. There is no need to sacrifice all keys that might be bound
> > globally to `scroll-up'.
> 
> For consistency, the same operation (modulo your above comment) should
> have the same key binding(s) inside and outside Isearch Mode.

Why? Consistency is most important _within_ a given context.
Consistency across contexts is not the be-all-and-end-all.

1. There are plenty of Isearch bindings that differ from their global
counterparts. Inconsistency.

2. And `C-w' is bound in Isearch to `isearch-yank-word-or-char', while
`S-<delete>' is not bound - it just exits Isearch and does its global thing. But
`C-w' and `S-<delete>' have the same global binding. Inconsistency.

> If any (non self-inserting) keys have a standard meaning
> throughout "all" computer programs, it's surely <prior> and <next>.

But in Isearch, they do not have that standard meaning, do they? They either
exit Isearch and do their standard thing (so no Isearch meaning) or, if
`isearch-allow-scroll' is non-nil, they scroll only one windowful. Inconsistent
with the standard behavior.

> Another argument in their favour is that anybody who's 
> scrolling up and down within Isearch is in a mode where there's
> no cost in using keys not in the home position.

On the contrary, `C-v' is quite handy to repeated `C-s', as well as to typing
more search chars. Not so `<next>'.

> I quite often scroll up and down in rapid succession (in isearch),

Only one windowful, presumably (unless you stop and use a repeat count while
you're busily thrashing up and down).

> and would find switching between C-v and M-v intolerably awkward.

Well, if you can't tolerate it, I guess we'll just have to forego it. ;-)

(Like Unicode -
http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3501#30.)

Re: add non-chord keys to repeat isearch

[Alan Mackenzie]

Good Evening, yet again, Drew!

On Tue, Jun 09, 2009 at 11:27:30AM -0700, Drew Adams wrote:
> > > `M-v' and `C-v' can be used for scrolling (when the option 
> > > is non-nil). And `<prior>' and `<next>' can be used for
> > > repeat search. There's room for all.

> > What about people's poor pinkies while operating those key sequences?
> > ;-)

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

> 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.  Look,
Drew, I've already admitted I wrote this feature, so please stop
expecting me to take a detached unbiassed view on it.  ;-)

> > Of course, another idea would be to allow C-s (etc.) to get a repeat
> > count - wouldn't be at all hard to do.  C-u C-u C-s could take you a
> > long, long way.

> Are you being serious or facetious? When searching, you typically want
> to see the next search hit to decide whether you want to move on to the
> one after that.

Maybe a bit of both.  There are times, admittedly not many, where I bash
C-s many times in succession (such as when searching through the mutt
manual for "pattern") when I'd love to be able to type M-23 C-s.  As for
patching isearch.el, half an hour at the most.

> > > [BTW, scrolling during isearch doesn't seem to work beyond a single
> > > screen height. Is that a bug or a feature? IOW, `C-s C-v C-v': the
> > > second `C-v' has no effect.]

> > It's a feature as far as I'm concerned, a bug to a few others.  In
> > Emacs, point is always in the Window, so this carries over quite
> > naturally to the whole isearch match staying in the window, too.  The
> > other design alternative would have been to allow point to scroll to
> > the top/bottom of the window even when that would put part of the
> > match outside it.

> Whatever. 

> IMO, it's not a great design (since we can't rightfully call it a bug).
> Suppose you want to check occurrences of `foo' in Info, and you're
> looking for something specific in the context of `foo', but it's not
> feasible or easy to add that something to the regexp search string, so
> you just use `C-s foo'.

Hi-lock Mode comes in handy for this sort of thing.

> You can easily see a windowful of `foo' hits, thanks to lazy
> highlighting - very helpful. It's often easy to scan those visually
> without actually moving point among them. You can pretty easily tell if
> you see the context of interest somewhere among the hits, most of which
> are more or less noise.

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.

> This is what to me would be a typical use case for scrolling during
> Isearch. And in this use case, there is no reason to limit scrolling to
> a single scroll. On the contrary; I would want to keep scrolling,
> letting lazy Isearch highlight indicate the hits, but not bothering to
> move point among them.

There's a very good reason.  In Emacs, point is always on the screen.
During an isearch, point is at the current match.  The essence of the
scrolling is not to interact with the searching.  Accepting those two
constraints and one design aim, you cannot scroll further than one
screenful.  If you want to drop one of them, you're designing a different
feature. 

> > > > The same applies to any keys bound to commands which have the
> > > > `isearch-scroll' non-nil.

> > > That's fine, but a specific key binding can override that. We can
> > > choose to bind `<prior>' to `isearch-repeat-backward' even though
> > > `scroll-up' has non-nil property `isearch-scroll'. Works 
> > > fine. There is no need to sacrifice all keys that might be bound
> > > globally to `scroll-up'.

> > For consistency, the same operation (modulo your above comment)
> > should have the same key binding(s) inside and outside Isearch Mode.

> Why? Consistency is most important _within_ a given context.
> Consistency across contexts is not the be-all-and-end-all.

> 1. There are plenty of Isearch bindings that differ from their global
> counterparts. Inconsistency.

OK.  Do you want consistency or inconsistency?  If the former, the
scrolling binding gives it to you.  If the latter, the fact that the
consistency is unusual in Isearch Mode gives you that.  I'm not in much
of a sensible arguing mood at the moment.  Sorry.

> 2. And `C-w' is bound in Isearch to `isearch-yank-word-or-char', while
> `S-<delete>' is not bound - it just exits Isearch and does its global
> thing. But `C-w' and `S-<delete>' have the same global binding.
> Inconsistency.

Yes.  Horrible, isn't it?

> > If any (non self-inserting) keys have a standard meaning
> > throughout "all" computer programs, it's surely <prior> and <next>.

> But in Isearch, they do not have that standard meaning, do they? They
> either exit Isearch and do their standard thing (so no Isearch meaning)
> or, if `isearch-allow-scroll' is non-nil, they scroll only one
> windowful. Inconsistent with the standard behavior.

They're as consistent as they can be (see above).

> > Another argument in their favour is that anybody who's scrolling up
> > and down within Isearch is in a mode where there's no cost in using
> > keys not in the home position.

> On the contrary, `C-v' is quite handy to repeated `C-s', as well as to
> typing more search chars. Not so `<next>'.

<next> and <prior> are much easier to type alternately than C-v and M-v.
I do this often enough for it to matter to me.  By contrast, I would
think it to be quite rare to type C-r after typing a C-s (especially
given that <DEL> achieves the same thing with less bureaucracy).

> > I quite often scroll up and down in rapid succession (in isearch),

> Only one windowful, presumably (unless you stop and use a repeat count while
> you're busily thrashing up and down).

Actually, I've got C-S-<up>, C-S-<down> bound to commands to scroll 6
lines, and I use these a lot.

> > and would find switching between C-v and M-v intolerably awkward.

> Well, if you can't tolerate it, I guess we'll just have to forego it.
> ;-)

I'm glad we agree on something.  ;-)  Actually, although I'm not in
favour of making your bindings a standard default, I wouldn't be that
vehement in arguing against them.

> (Like Unicode -
> http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3501#30.)

No, I don't like unicode, thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

RE: add non-chord keys to repeat isearch

[Drew Adams]

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

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

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

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

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

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

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


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

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.


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.

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

Re: add non-chord keys to repeat isearch

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
>> What about people's poor pinkies while operating those key sequences?
>> ;-)
>
> Precisely the point. Which do you repeat 14 times in a row, `scroll-up' or
> `isearch-repeat-forward'?
>
> 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.

Using `C-s' / `C-r' to repeat the isearch is not a biggie either.

You (1) hold Control with your pinky, and (2) keep hitting `s'.

-Miles

-- 
Opposition, n. In politics the party that prevents the Goverment from running
amok by hamstringing it.

RE: add non-chord keys to repeat isearch

[Drew Adams]

> Using `C-s' / `C-r' to repeat the isearch is not a biggie either.
> You (1) hold Control with your pinky, and (2) keep hitting `s'.

As I said, I've been doing that for decades.
So yes, it can be done. ;-)

I'm happy, however, to no longer _have_ to hold down Control while repeating
search 200 times. Yes, Mr. Pinky can do that, but why should he?

You can walk down the sidewalk backwards - no biggee.
But why would you, most of the time?