From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: rms@gnu.org
Cc: md5i@md5i.com, dan.colascione@gmail.com, emacs-devel@gnu.org,
juri@jurta.org, Stefan Monnier <monnier@iro.umontreal.ca>,
dmoncayo@gmail.com, acm@muc.de, yandros@mit.edu,
drew.adams@oracle.com
Subject: Re: `isearch-allow-scroll' - a misnomer and a bad design
Date: Thu, 22 Sep 2011 01:35:02 +0900 [thread overview]
Message-ID: <87r539c0qx.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <E1R6O9I-00075T-BX@fencepost.gnu.org>
Richard Stallman writes:
> > FWIW: Several people have expressed this idea, with which I agree.
> > C-u should do nothing by itself (and that includes not exiting
> > Isearch, of course). Its only effect should be to provide a prefix
> > argument to the next command, to extend its behavior.
>
> I tend to agree.
>
> This reasoning is based on thinking of Isearch as a kind of a mode,
> but that's exactly what we should avoid.
Why? That's like saying, "thinking of Shovel as a kind of a digging
implement" is exactly what we should avoid! I am not saying we should
have gratuitious modality in Emacs. I'm saying that if we have
unavoidable modality, we should not kid ourselves. In the present
Isearch implementation, I see no way to disabuse users of the naive
intuition that one "enters" and "exits" Isearch. The minibuffer
activates and deactivates, and so does an idiosyncratic form of
highlighting in the buffer. The behavior of the minibuffer is itself
changed, since the cursor does *not* jump to the minibuffer as it
normally does. Normally self-inserting characters become motion
commands. If that last is not modal, what is?
In any case, my own intuition happens to be the opposite of yours. I
see the *current* behavior of C-u as being very much affected by the
modality of Isearch, and it bothers me. When I type C-u in any other
situation, Emacs quietly waits until I type something else. It does
not immediately make any perceptible change to the Emacs environment.
But when using Isearch, C-u visibly disturbs state, ie, the state of
the search.
From this point of view, the whole point of Alan's changes (and of
Drew's suggestion as well) is to *reduce* the modality of isearch.
With Alan's option *on*, scrolling commands now work as they do
elsewhere in Emacs: the visible portion of the buffer at hand changes,
without disturbing the state of the buffer or the search. With
Drew's option *on*, C-u now works as it does elsewhere in Emacs,
providing additional context to the next command, without disturbing
the state of the buffer or the search.
It seems to me that both of these changes make Emacs as a whole less
modal, not more so. And I agree that making Emacs less modal is a
good thing.
As for the other bindings in isearch-mode, I agree that even the
relatively few we have now do increase the modality of Isearch, and
I'm of mixed feelings about almost all of them (especially C-w and
C-y, which are both most useful to me personally, but also require the
most effort of me to overcome muscle memory). However, I see such
bindings as a very different issue from the more subtle changes of
which Alan and Drew wish to avail themselves.
next prev parent reply other threads:[~2011-09-21 16:35 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
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 [this message]
[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=87r539c0qx.fsf@uwakimon.sk.tsukuba.ac.jp \
--to=stephen@xemacs.org \
--cc=acm@muc.de \
--cc=dan.colascione@gmail.com \
--cc=dmoncayo@gmail.com \
--cc=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
--cc=juri@jurta.org \
--cc=md5i@md5i.com \
--cc=monnier@iro.umontreal.ca \
--cc=rms@gnu.org \
--cc=yandros@mit.edu \
/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.