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