From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: New multi-command facility displays in the wrong echo area. Date: Sat, 10 Oct 2020 12:44:46 +0000 Message-ID: <20201010124446.GC5662@ACM> References: <20201009163445.GB4027@ACM> <20201009203810.GC4027@ACM> <83imbi609a.fsf@gnu.org> <20201010103233.GB5662@ACM> <834kn25o6b.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21397"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 10 14:46:02 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kREG9-0005R0-R2 for ged-emacs-devel@m.gmane-mx.org; Sat, 10 Oct 2020 14:46:01 +0200 Original-Received: from localhost ([::1]:59542 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kREG8-0003vn-ST for ged-emacs-devel@m.gmane-mx.org; Sat, 10 Oct 2020 08:46:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57348) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kREF3-0003Nx-35 for emacs-devel@gnu.org; Sat, 10 Oct 2020 08:44:54 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:38184 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1kREF0-0004j3-H4 for emacs-devel@gnu.org; Sat, 10 Oct 2020 08:44:52 -0400 Original-Received: (qmail 19183 invoked by uid 3782); 10 Oct 2020 12:44:47 -0000 Original-Received: from acm.muc.de (p2e5d5308.dip0.t-ipconnect.de [46.93.83.8]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Sat, 10 Oct 2020 14:44:46 +0200 Original-Received: (qmail 6180 invoked by uid 1000); 10 Oct 2020 12:44:46 -0000 Content-Disposition: inline In-Reply-To: <834kn25o6b.fsf@gnu.org> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/10 08:44:47 X-ACL-Warn: Detected OS = FreeBSD 9.x or newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:257320 Archived-At: 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 > > 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).