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

[Alan Mackenzie]

Hi, Drew,

I kind of feel myself being addressed here.  :-)

On Fri, Sep 09, 2011 at 01:38:16PM -0700, Drew Adams wrote:
> 1. The doc for this option, as well as its name, give the impression that it 
> is
> about allowing scrolling.  It is not.

It is largely about scrolling.  Try enabling the option and use <PgUp>,
<PgDn> during an isearch.  Or try C-l.  The need to scroll during a
search was what inspired the feature.

> 1. For one thing, a non-nil value allows *any* command bound to a key in
> `isearch-mode-map' to take advantage of a prefix arg.  That is, `C-u' is 
> passed
> through to the command if the option value is non-nil.  The command need not
> have anything to do with scrolling.

I'm not sure that's quite true.  Or if it is, keys like C-s don't react
to it.

> And there are already at least two such vanilla commands:
> `isearch-query-replace' and `isearch-query-replace-regexp' (`M-%', `C-M-%').  
> A
> `C-u' changes the command behavior in a way that has nothing to do with
> scrolling.

It's good that the C-u works, though.  ;-)

> At a minimum, the doc should be adjusted.  The option name should also be
> changed to fit what it really does.

What would you suggest?  What does the option really do, in your
judgement?  Scrolling is an essential part of the option.

> Likewise, the functions (e.g.  `isearch-lookup-scroll-key') and other
> code and doc strings in isearch.el that paint this feature as having to
> do with scrolling.

They're stricly internal functions, so changing their names/doc strings
wouldn't be a big deal.

> 1b. For another thing (i.e., forgetting about `C-u'), *any* command can 
> benefit
> from the same Isearch feature as a scrolling command.  It suffices to put a
> non-nil `isearch-scroll' property on the command symbol.

This isn't true.  Only commands which don't foul up the isearch can be
permitted to use the feature.  Only a few commands meet the criteria.
`universal-argument' is such a command.

> 2. I would like to see us separate the treatment of a prefix arg - whether it
> gets passed it through to a command or it exits Isearch - from the other
> uses/effects of this option.

I agree, that would be a good idea.  It wouldn't take very much work.

> IOW, I would like to be able to set some option to have Isearch pass `C-u'
> through, and have that be independent of the setting of some other option that
> controls whether scrolling (or some other behavior) is allowed.  Even if
> allowing scrolling (or whatever) might also require the ability to pass 
> through
> `C-u', that does not mean that being able to pass through `C-u' should allow
> scrolling.  It makes little sense to couple these two features.

Need it be an option?  Why not just let C-u through no matter what?

> The query-replace commands are a good example, and users (such as yours truly)
> might well want similar `C-u' pass-through for other commands, without also
> wanting scrolling (or whatever).

As a matter of interest, have you tried setting isearch-allow-scroll?  If
you have and didn't like it, what about it didn't you like?

> 3. Wrt controlling which commands are affected by the option (i.e., forgetting
> about `C-u' now): The current design makes the library designer responsible 
> for
> this choice, not the user.  That is another flaw, IMO.  A user should be able 
> to
> easily (using Customize, not just putting `put' here and there) choose which
> commands are affected.

I disagree totally here.  The sophisticated user can set a suitable
command to be a "scrolling" command.  The unsophisticated user is going
to get his Emacs into a thorough mess by messing around in this area.

> Instead of a Boolean option (`isearch-allow-scroll'), users should have
> an option that specifies the affected commands.  (It could also
> configure any specifics for each command, if there are such.)

Again, familiarise yourself with just how restricted the permissible
commands are.  There's a list of criteria in isearch.el ~L1760 (think -
number of yards in a mile :-).

> 4. Why are there currently _two_ different properties that turn on this
> sensitivity (i.e., "scrolling")?  From the code comments:

> ;; ... property called `isearch-scroll'.
> ;; If a command's symbol has the value t for this property or for the
> ;; `scroll-command' property, it is a scrolling command.

I haven't a clue.  I've no idea who put `scroll-command' in or why.

> This means that if someone adds property `scroll-command' for some command 
> then
> it automatically acts as if s?he also added property `isearch-scroll'.  Why
> couple these two things?  Why assume that every `scroll-command' command is 
> also
> one for which Isearch should allow scrolling.

> All of this smacks of being a carryover from someone's (hi Alan) personal
> customizations, rather than being thought out in terms of users in general.

Pretty much all standard commands that can be "scrolling" commands
already are.  Let me know if there are any I have missed.

Users capable of writing their own "scrolling" commands will be quite
capable of putting the `isearch-scroll' property on them.  (I have done
this.)

-- 
Alan Mackenzie (Nuremberg, Germany).