From: "Drew Adams" <drew.adams@oracle.com>
To: <rms@gnu.org>, "'Alan Mackenzie'" <acm@muc.de>
Cc: emacs-devel@gnu.org
Subject: RE: `isearch-allow-scroll' - a misnomer and a bad design
Date: Tue, 13 Sep 2011 14:04:00 -0700 [thread overview]
Message-ID: <7E2EE144B11D413583E1E659CDE15186@us.oracle.com> (raw)
In-Reply-To: <E1R3ZE4-0005LA-EY@fencepost.gnu.org>
> I don't think there will be any inconvenience at all.
> Unless the user sets the option, isearch will behave
> exactly as it has done.
>
> If the default is the current behavior, I guess the other
> option can't hurt.
As a famous person is wont to say, why not poll the users about the default
behavior?
We can at least discuss it here. (But the important thing is of course to give
users the option.)
Unlike Richard, I am in favor of passing `C-u' through (e.g. to a command on
`isearch-mode-map') by default, that is, _not_ making it exit Isearch. Yes,
that would be a change from past behavior.
It would have the advantage that a library can bind a command in
`isearch-mode-map', and its users need not customize the new Isearch option in
order to let that command receive `C-u' during Isearch. They would not need to
customize anything - the command/key would just work as advertised, including
wrt a prefix arg.
Users of such a library/command have presumably already made the choice to use
it. Why should the library have to add to the command's doc that if you want to
use a prefix argument with it (in Isearch) then you have to customize option
`isearch-blah'?
Where else do we not allow a command on a keymap to see a prefix arg used with
its key? Why should this not be the default behavior for Isearch, too?
To me, this is all the more important because, as some have pointed out in the
past, `isearch-mode-map' is already pretty full. Letting a command bound in
that map use a prefix arg has the effect of putting multiple commands on the
same key, distinguished by the prefix arg. That's a good thing.
I suspected from the beginning that Richard might want `C-u' to exit Isearch (he
has indicated before that he generally likes Control keys to exit), which is why
I proposed making the behavior fix optional.
Until Richard spoke up, my impression was that the consensus of those speaking
about the issue seemed to be to let `C-u' pass through (not exit Isearch), by
default. Maybe, maybe not. At any rate, Alan's first patch presumably tried to
implement that behavior (without any user choice), but when he added the option
in his second patch, he made the default behavior exit Isearch.
It should still be an open question, so far, what the default behavior will be.
The only arguments I've seen are (a) what I say above versus (b) tradition (no
change in the default behavior). That is essentially (a) providing consistency
with other keymaps versus (a) keeping the same inconsistency we've enjoyed in
the past.
Any other arguments wrt the default value?
next prev parent reply other threads:[~2011-09-13 21:04 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
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 [this message]
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=7E2EE144B11D413583E1E659CDE15186@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=acm@muc.de \
--cc=emacs-devel@gnu.org \
--cc=rms@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.