[Top][All Lists]

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

Re: `isearch-allow-scroll' - a misnomer and a bad design

From: Alan Mackenzie
Subject: Re: `isearch-allow-scroll' - a misnomer and a bad design
Date: Sat, 10 Sep 2011 12:13:49 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

Hi, Juri.

On Sat, Sep 10, 2011 at 02:47:08PM +0300, Juri Linkov wrote:
> > Maybe what you want is a new option `isearch-pass-through-categories',
> > which would be a list of symbol properties, so any command who has
> > a non-nil value for one of those properties is allowed to run without
> > exiting isearch.

> > Then `scroll-command' becomes one possible element of
> > isearch-pass-through-categories.

> I think this would be the best thing to do.  And to add
> a new property that doesn't exit Isearch regardless of the value of
> `isearch-allow-scroll'.  And put it on all universal argument commands
> `universal-argument', `negative-argument', `digit-argument', i.e.:

Please everybody, this whole thing is balooning out of control.  What
everybody seems to be forgetting is that this feature can only be used
with commands which:

1. Don't change the buffer being isearched through;
2. Don't move point;
3. Don't swap to another buffer, window or frame;
4. Don't mess with isearch's state (e.g. with search-regexp functions).

This is really a TINY number of commands, mostly to do with scrolling,
changing window arrangement, and the prefix arg.  Any other command would
screw up the isearch horribly.

>   ;; Universal argument commands
>   (put 'universal-argument 'isearch-inhibit-exit t)
>   (put 'negative-argument 'isearch-inhibit-exit t)
>   (put 'digit-argument 'isearch-inhibit-exit t)

> that will do TRT by default for commands unrelated to scrolling.

I agree these three commands should be separated out.  I've already
supplied a rough patch for this.

But for any more additional complexity, we should have a firm use case.
Complexity without reason is a Bad Thing.

Alan Mackenzie (Nuremberg, Germany).

reply via email to

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