From: Alan Mackenzie <acm@muc.de>
To: Daniel Mendler <daniel@mendler.net>
Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>,
"monnier@iro.umontreal.ca" <monnier@iro.umontreal.ca>,
"kevin.legouguec@gmail.com" <kevin.legouguec@gmail.com>,
Eli Zaretskii <eliz@gnu.org>,
"arstoffel@gmail.com" <arstoffel@gmail.com>,
Drew Adams <drew.adams@oracle.com>
Subject: Re: [External] : Re: Indicate better the current use of the echo area / minibuffer [was: Controlling Isearch from minibuffer]
Date: Thu, 13 May 2021 15:24:23 +0000 [thread overview]
Message-ID: <YJ1Ep1JIP0gA/635@ACM> (raw)
In-Reply-To: <61c85b87-98f2-1fa2-4e0a-aba40b080049@mendler.net>
Hello, Daniel.
On Thu, May 13, 2021 at 16:41:10 +0200, Daniel Mendler wrote:
> On 5/13/21 4:11 PM, Drew Adams wrote:
> >>> As I've said, I, for one, think it's good that Isearch
> >>> doesn't use the minibuffer. But I think it might help
> >>> if there were a visual indication of some kind, to
> >>> distinguish Isearching from use of the minibuffer, and
> >>> Isearching from (other) use of the echo area.
> >> There is such an indication: the cursor is not in the mini-window.
> > Yes, there is indeed an "indication of some kind".
> > ABut as the Subject says, this is about _better_
> > indicating such things - being _more_ helpful.
> Personally, I would not like to use such a colorful "subtle" indication
> in the echo area. To me this seems more like an implementation detail,
> which should not be visible to the user.
> The echo area/minibuffer distinction comes up from time to time in
> discussions with new users. I know that I had been confused for a while
> with the Isearch behavior. The Isearch use of the echo area is
> unexpected. Users expect to enter a search string into a separate input
> form as is common in many other programs. In Emacs this input form is
> the minibuffer.
That's a rather misleading way of portraying it. Users used to other
programs tend not to be familiar with incremental search, where point is
not in "a separate input form" but in the buffer they're searching
through. There is no "separate input form".
Besides, currently isearch can be used in the mini-window, searching
through a minibuffer. If we are not to lose this feature, things will
get complicated and messy.
> I would welcome the changes by Augusto. The minibuffer-controlled
> Isearch makes entering the search string more robust with regards to
> various editing commands as mentioned before by Kévin Le Gouguec.
But it's a gross kludge. The principle behind the minibuffer is that
the current edit is suspended, and the current window is switched to a
minibuffer window, and (more or less) normal editing happens in that
mini-window until the user terminates it. This clashes with the concept
of incremental searching, where point stays in the target window at all
times, guided by a sequence of commands, there being no recursive edit.
> There exists the ctrlf package on MELPA which also uses the minibuffer,
> but it feels hardly justified to install an extra package only to get a
> minibuffer-controlled search mode. I also don't want to replace such a
> tightly integrated component like Isearch with an external package. If a
> minibuffer mode can be added to Isearch with small effort and in a
> reasonably clean way, why not do that?
See above. It would be anything but clean, given the clash between the
way the minibuffer works and the way incremental search works.
Augusto's original patch was ~500 lines long, which scarcely suggests
"reasonably clean".
You seem to be asking for an Emacs internal mechanism (the minnibuffer)
to be used rather than for particular user visible effects to be seen.
Why not concentrate on the latter, so that we can evaluate such
suggestions and incorporate them into the current way isearch is
implemented?
I am worried that these suggestions for using the minibuffer will get
implemented, and searching in Emacs will move from the delightfully
lightweight feature we have at the moment to something awkward and
sluggish, like most other programs' searching is.
> Daniel
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2021-05-13 15:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-12 23:47 Indicate better the current use of the echo area / minibuffer [was: Controlling Isearch from minibuffer] Drew Adams
2021-05-13 6:28 ` Eli Zaretskii
2021-05-13 14:11 ` [External] : " Drew Adams
2021-05-13 14:41 ` Daniel Mendler
2021-05-13 15:24 ` Alan Mackenzie [this message]
2021-05-13 16:12 ` Daniel Mendler
2021-05-13 16:21 ` Augusto Stoffel
2021-05-13 16:44 ` Eli Zaretskii
2021-05-13 16:16 ` Daniel Martín
2021-05-13 16:33 ` Daniel Mendler
2021-05-13 17:41 ` Drew Adams
2021-05-13 18:07 ` Daniel Mendler
2021-05-13 19:36 ` Drew Adams
2021-05-14 21:02 ` John Yates
2021-05-14 21:55 ` Drew Adams
2021-05-15 7:57 ` martin rudalics
2021-05-15 19:46 ` Drew Adams
2021-05-14 18:16 ` Juri Linkov
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YJ1Ep1JIP0gA/635@ACM \
--to=acm@muc.de \
--cc=arstoffel@gmail.com \
--cc=daniel@mendler.net \
--cc=drew.adams@oracle.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=kevin.legouguec@gmail.com \
--cc=monnier@iro.umontreal.ca \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).