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: Stop frames stealing eachothers' minibuffers! Date: Sun, 22 Nov 2020 18:38:26 +0000 Message-ID: <20201122183826.GG5912@ACM> References: <20201119104035.GB6259@ACM> <9aacff47-8ac2-93a2-5112-6153ee986b57@gmx.at> <20201120210005.GA1034@ACM> <20201121102751.GA11643@ACM> <18a901b8-3250-b461-eb2a-c13988616e93@gmx.at> <20201121124550.GB11643@ACM> <535bd6d4-3997-2e64-ea43-5de6f0892062@gmx.at> <20201122105947.GA5912@ACM> <59f8d2fa-3db9-078b-56e2-c793f6e69edd@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22352"; mail-complaints-to="usenet@ciao.gmane.io" Cc: enometh@meer.net, emacs-devel@gnu.org, Eli Zaretskii , Andrii Kolomoiets , Stefan Monnier To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 22 19:39:47 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 1kguH4-0005iL-RO for ged-emacs-devel@m.gmane-mx.org; Sun, 22 Nov 2020 19:39:46 +0100 Original-Received: from localhost ([::1]:43594 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kguH3-0007f4-TX for ged-emacs-devel@m.gmane-mx.org; Sun, 22 Nov 2020 13:39:45 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56116) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kguFu-0007CG-19 for emacs-devel@gnu.org; Sun, 22 Nov 2020 13:38:34 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:34055 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1kguFp-0005bn-Jq for emacs-devel@gnu.org; Sun, 22 Nov 2020 13:38:32 -0500 Original-Received: (qmail 77833 invoked by uid 3782); 22 Nov 2020 18:38:27 -0000 Original-Received: from acm.muc.de (p2e5d52bc.dip0.t-ipconnect.de [46.93.82.188]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Sun, 22 Nov 2020 19:38:25 +0100 Original-Received: (qmail 12455 invoked by uid 1000); 22 Nov 2020 18:38:26 -0000 Content-Disposition: inline In-Reply-To: <59f8d2fa-3db9-078b-56e2-c793f6e69edd@gmx.at> 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-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=unavailable 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:259638 Archived-At: Hello, Martin. On Sun, Nov 22, 2020 at 18:57:30 +0100, martin rudalics wrote: > > diff --git a/src/minibuf.c b/src/minibuf.c > > index 464e3018f7..fc3fd92a88 100644 > > --- a/src/minibuf.c > > +++ b/src/minibuf.c > > @@ -508,7 +508,10 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt, > > mini_frame = WINDOW_FRAME (XWINDOW (minibuf_window)); > > if (!EQ (mini_frame, selected_frame)) > > record_unwind_protect (restore_window_configuration, > > - Fcons (Qt, > > + Fcons (/* Arrange for the frame later to be > > + switched back to the calling > > + frame. */ > > + Qnil, > > Fcurrent_window_configuration (mini_frame))); > > > > /* If the minibuffer is on an iconified or invisible frame, > This one immediately chokes when I run > emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))" > and type C-x 5 2. Here the cursor disappears entirely although when I > do some typing now the text shows up in the minibuffer window. TRT as > with Emacs 27 is to select and focus the new frame. On my machine (XFCE on X-Windows on GNU) I see TRT when I do this. Could it be something to do with your window manager? > > There seem to be quite a few things wrong, even on Emacs 27. On > > starting it with loading your initialisation file from the command > > line, the initial selected frame is the minibuffer frame, which is > > surely suboptimal. > Here the minibuffer-only frame is selected but partially hidden by the > normal frame so that I don't see no cursor initially. I don't know why > people like it that way. A minibuffer child frame is explicitly not > selected. Do people like it, or is it just not a big enough annoyance for anybody to complain? If I were a minibuffer-only frame user, I suspect it would drive me up the wall. > Note that the way Emacs creates the two frames layout is atrocious - we > first make a normal frame to do our usual initialization stuff and then > we create the minibuffer-only and the minibuffer-less frames and delete > the initial one (compare 'frame-notice-user-settings'). It's for years > that I want to rewrite that ... Yes, I can understand that. But you will be aware of all the nasty little things which will leap out in front of you and force you to solve along the way. > > On M-: followed by C-x 5 o (moving to the normal frame), > > the unfinished command in the minibuffer frame cannot now be cancelled, > > and C-x 5 o doesn't move back into the minibuffer. > 'other-frame' never selects a minibuffer-only frame. It probably should. I'm more of the view that a minibuffer-only frame should never be selected other than by activating a minibuffer. > And the behavior of C-g in a separate minibuffer frame IME usually > varies with the time of the day. > > Yes, maybe, but modal dialogues are a right pain for the user, as can be > > seen by using virtually any commericial software on non-free systems. > Modal dialogues are supported by the windowing subsystem, regardless of > whether it's free or not. Yes. I hate these dialogues, which force you to cancel them and start again, should you need some information from another part of the program to be able to fill them in. > martin -- Alan Mackenzie (Nuremberg, Germany).