Re: add non-chord keys to repeat isearch

[Alan Mackenzie <acm@muc.de>]

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