From: "Drew Adams" <drew.adams@oracle.com>
To: <emacs-devel@gnu.org>
Subject: `isearch-allow-scroll' - a misnomer and a bad design
Date: Fri, 9 Sep 2011 13:38:16 -0700 [thread overview]
Message-ID: <AF6BB550F92F40CF91E48D533EAA1A4A@us.oracle.com> (raw)
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
scrolling.
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.
next reply other threads:[~2011-09-09 20:38 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-09 20:38 Drew Adams [this message]
2011-09-09 21:52 ` `isearch-allow-scroll' - a misnomer and a bad design Alan Mackenzie
2011-09-09 23:07 ` Drew Adams
2011-09-10 0:58 ` Stefan Monnier
2011-09-10 7:48 ` Drew Adams
2011-09-10 11:28 ` Alan Mackenzie
2011-09-10 16:44 ` Drew Adams
2011-09-10 11:47 ` Juri Linkov
2011-09-10 12:13 ` Alan Mackenzie
2011-09-10 2:03 ` Stephen J. Turnbull
2011-09-10 11:10 ` Alan Mackenzie
2011-09-10 16:43 ` Drew Adams
2011-09-10 19:04 ` Alan Mackenzie
2011-09-10 20:22 ` PJ Weisberg
2011-09-10 23:06 ` Stephen J. Turnbull
2011-09-11 0:47 ` Drew Adams
2011-09-11 10:39 ` Alan Mackenzie
2011-09-11 16:54 ` Drew Adams
2011-09-11 17:30 ` Alan Mackenzie
2011-09-11 18:53 ` Drew Adams
2011-09-12 2:46 ` Richard Stallman
2011-09-12 9:36 ` Alan Mackenzie
2011-09-13 1:39 ` Richard Stallman
2011-09-13 14:27 ` Alan Mackenzie
2011-09-13 20:05 ` Richard Stallman
2011-09-13 21:04 ` Drew Adams
2011-09-13 22:52 ` Juri Linkov
2011-09-14 0:32 ` Daniel Colascione
2011-09-14 0:41 ` Drew Adams
2011-09-14 14:10 ` Richard Stallman
2011-09-14 14:35 ` PJ Weisberg
2011-09-15 4:11 ` Richard Stallman
2011-09-14 14:44 ` Drew Adams
2011-09-18 2:52 ` Richard Stallman
2011-09-19 19:08 ` chad
2011-09-20 15:16 ` Richard Stallman
2011-09-20 19:17 ` Michael Welsh Duggan
2011-09-20 19:59 ` Dani Moncayo
2011-09-21 1:22 ` Stefan Monnier
2011-09-21 14:51 ` Richard Stallman
2011-09-21 15:01 ` Dani Moncayo
2011-09-21 15:10 ` Drew Adams
2011-09-21 16:35 ` Stephen J. Turnbull
[not found] ` <E1R6Tii-0000zy-Jw@f!! encepost.gnu.org>
2011-09-21 20:48 ` Richard Stallman
2011-09-21 21:13 ` Drew Adams
2011-09-22 13:58 ` Richard Stallman
2011-10-08 21:13 ` Drew Adams
2011-09-22 5:33 ` Stephen J. Turnbull
2011-09-22 13:59 ` Richard Stallman
2011-09-22 10:35 ` Alan Mackenzie
2011-09-22 21:44 ` Richard Stallman
2011-09-22 22:23 ` PJ Weisberg
2011-09-23 12:30 ` Richard Stallman
2011-09-21 9:04 ` Alan Mackenzie
2011-09-21 9:27 ` Dani Moncayo
2011-09-21 9:29 ` chad
2011-09-21 13:22 ` Drew Adams
2011-09-21 14:50 ` Richard Stallman
2011-09-12 14:59 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AF6BB550F92F40CF91E48D533EAA1A4A@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.