unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: New multi-command facility displays in the wrong echo area.
Date: Sat, 10 Oct 2020 12:44:46 +0000	[thread overview]
Message-ID: <20201010124446.GC5662@ACM> (raw)
In-Reply-To: <834kn25o6b.fsf@gnu.org>

Hello, Eli.

On Sat, Oct 10, 2020 at 14:13:32 +0300, Eli Zaretskii wrote:
> > Date: Sat, 10 Oct 2020 10:32:33 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org

> > > Do you intend to leave the active minibuffer on the original frame, and
> > > use the other frame for Isearch?  Note that Isearch also uses the
> > > minibuffer.

> > I'm not understanding that, properly.  When I enter characters into
> > isearch in F2, this doesn't throw an error when the F1 minibuffer is
> > still active.  Is isearch perhaps just using the echo area, here?

> > Anyway, I tried the suggestion of Gregory Heytings from yesterday evening
> > at 21:48:49 +0000.  He put an extra condition into
> > set-minibuffer-message, so that it only does its thing when the current
> > frame is also the minibuffer's frame.  It appears to work well.

> Does that work if you set tty-menu-open-use-tmm non-nil, then press
> f10 while the I-search: prompt is active?  This is one case where
> Isearch reads from the minibuffer.

Ah, yes.  Sorry for being a bit dim, there.

When just the isearch is active, f10 does indeed work.  When,
additionally, C-x b is active on another frame, it throws the error
"Command attempted to use minibuffer while in minibuffer".  This is
surely correct.  However, the isearch highlighting doesn't get removed in
this error case.  That is incorrect.

> Another, perhaps more important, use case is when you type "M-s e"
> during Isearch: that enters the minibuffer to let you edit the search
> string.

This works fine.  Without the C-x b in another frame, it just works.
With the C-x b in the other frame it throws the "Command ... minibuffer"
error and removes the highlighting.

> Yet another similar use case is when you type "C-x 8 RET" during
> Isearch: that reads the character's name/codepoint from the minibuffer.

This goes wrong.  With C-x b active on frame F1, move to F2, start an
isearch, C-x 8 RET, use TAB completion to select a character and RET.
This displays

    Switch to buffer (default xdisp.c):  [Failing I-search: su�] 

on F2.  On terminating the isearch and completing the C-x b action in
F2's minibufer, the buffer switch has worked in frame F1.

At a guess, C-x 8 RET uses a recursive edit, but fails to bind the
variable holding the minibuffer frame.  It changes this variable, but on
exiting the recursive edit, fails to restore it.  Or something like that.

> These are the use cases I had in mind when I asked about Isearch using
> the minibuffer.

OK.

-- 
Alan Mackenzie (Nuremberg, Germany).



  parent reply	other threads:[~2020-10-10 12:44 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-09 16:34 New multi-command facility displays in the wrong echo area Alan Mackenzie
2020-10-09 19:47 ` Stefan Monnier
2020-10-09 20:38   ` Alan Mackenzie
2020-10-09 22:12     ` Stefan Monnier
2020-10-09 22:56       ` Drew Adams
2020-10-10  6:52     ` Eli Zaretskii
2020-10-10 10:32       ` Alan Mackenzie
2020-10-10 11:13         ` Eli Zaretskii
2020-10-10 12:36           ` Gregory Heytings via Emacs development discussions.
2020-10-10 12:44           ` Alan Mackenzie [this message]
2020-10-10 12:50             ` Eli Zaretskii
2020-10-10 13:00               ` Eli Zaretskii
2020-10-10 20:30                 ` Gregory Heytings via Emacs development discussions.
2020-10-11 14:38                   ` Eli Zaretskii
2020-10-12  9:12                     ` Gregory Heytings via Emacs development discussions.
2020-10-12 12:00                       ` Alan Mackenzie
2020-10-12 12:18                         ` Gregory Heytings via Emacs development discussions.
2020-10-12 14:37                       ` Eli Zaretskii
2020-10-12 15:41                         ` Gregory Heytings via Emacs development discussions.
2020-10-12 16:01                           ` Eli Zaretskii
2020-10-12 16:31                             ` Gregory Heytings via Emacs development discussions.
2020-10-12 17:20                               ` Eli Zaretskii
2020-10-12 21:06                                 ` Gregory Heytings via Emacs development discussions.
2020-10-13 14:03                                   ` Eli Zaretskii
2020-10-13 19:27                                     ` Gregory Heytings via Emacs development discussions.
2020-10-13 21:22                                       ` Gregory Heytings via Emacs development discussions.
2020-10-12 17:12                         ` Drew Adams
2020-10-12 17:34                           ` Eli Zaretskii
2020-10-12 19:46                         ` Juri Linkov
2020-10-13  2:25                           ` Eli Zaretskii
2020-10-14 20:44                       ` Gregory Heytings via Emacs development discussions.
     [not found]                         ` <1cd65040-f7ad-4613-b3fb-7cfa62bb0488@default>
2020-10-14 22:15                           ` Gregory Heytings via Emacs development discussions.
2020-10-14 22:51                         ` Stefan Monnier
2020-10-16  7:19                           ` Eli Zaretskii
2020-10-16  7:19                         ` Eli Zaretskii
2020-10-10 13:03             ` Gregory Heytings via Emacs development discussions.
2020-10-10 13:47               ` Alan Mackenzie
2020-10-10 20:20                 ` Gregory Heytings via Emacs development discussions.
2020-10-09 21:14   ` Gregory Heytings via Emacs development discussions.
2020-10-09 21:48     ` Gregory Heytings via Emacs development discussions.
2020-10-10 10:15       ` Alan Mackenzie
2020-10-10 13:44         ` Stefan Monnier
     [not found] <<20201009163445.GB4027@ACM>
     [not found] ` <<jwv362nkwss.fsf-monnier+emacs@gnu.org>
     [not found]   ` <<20201009203810.GC4027@ACM>
     [not found]     ` <<83imbi609a.fsf@gnu.org>
2020-10-10 16:11       ` Drew Adams
2020-10-10 20:40         ` Gregory Heytings via Emacs development discussions.
2020-10-11  0: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

  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=20201010124446.GC5662@ACM \
    --to=acm@muc.de \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --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).