From: Alan Mackenzie <acm@muc.de>
To: Drew Adams <drew.adams@oracle.com>
Cc: emacs-devel@gnu.org
Subject: Re: `isearch-allow-scroll' - a misnomer and a bad design
Date: Fri, 9 Sep 2011 21:52:55 +0000 [thread overview]
Message-ID: <20110909215255.GD2733@acm.acm> (raw)
In-Reply-To: <AF6BB550F92F40CF91E48D533EAA1A4A@us.oracle.com>
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).
next prev parent reply other threads:[~2011-09-09 21:52 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-09 20:38 `isearch-allow-scroll' - a misnomer and a bad design Drew Adams
2011-09-09 21:52 ` Alan Mackenzie [this message]
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=20110909215255.GD2733@acm.acm \
--to=acm@muc.de \
--cc=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.