[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: |
Fri, 9 Sep 2011 21:52:55 +0000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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).