[Top][All Lists]

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

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

From: Drew Adams
Subject: `isearch-allow-scroll' - a misnomer and a bad design
Date: Fri, 9 Sep 2011 13:38:16 -0700

1. The doc for this option, as well as its name, give the impression that it is
about allowing scrolling.  It is not.

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.

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

At a minimum, the doc should be adjusted.  The option name should also be
changed to fit what it really does.  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.

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.

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.

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.

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

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

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.

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.

reply via email to

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