[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: add non-chord keys to repeat isearch

From: Drew Adams
Subject: RE: add non-chord keys to repeat isearch
Date: Tue, 9 Jun 2009 11:27:30 -0700

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

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.


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 -

reply via email to

[Prev in Thread] Current Thread [Next in Thread]