From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Stop frames stealing eachothers' minibuffers! Date: Sat, 21 Nov 2020 10:02:15 +0100 Message-ID: References: <20201119104035.GB6259@ACM> <9aacff47-8ac2-93a2-5112-6153ee986b57@gmx.at> <20201120210005.GA1034@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15829"; mail-complaints-to="usenet@ciao.gmane.io" Cc: enometh@meer.net, emacs-devel@gnu.org, Eli Zaretskii , Andrii Kolomoiets , Stefan Monnier To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 21 10:05:46 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 1kgOq1-0003zy-UI for ged-emacs-devel@m.gmane-mx.org; Sat, 21 Nov 2020 10:05:46 +0100 Original-Received: from localhost ([::1]:59352 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kgOq0-0001zo-Ev for ged-emacs-devel@m.gmane-mx.org; Sat, 21 Nov 2020 04:05:44 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48256) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kgOmt-0001TL-98 for emacs-devel@gnu.org; Sat, 21 Nov 2020 04:02:31 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:38077) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kgOmq-0005pY-QH; Sat, 21 Nov 2020 04:02:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1605949337; bh=LWn9pcP9F9WB+Mxqsp1fEJ9eFWx9WvFWEARMPJQGPxE=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=HtKRkStEoksFKN6ufTga0GqGlhKVfVfiWmekaUt1ZPcL2JjOANKMxE5h4/SFEWWui vx/teImOD+T7UcK6q2xagz8hZnni4WQgQU0vJoXPJ3An8i93bHP0GiRNYZLCShOzrJ PL0duFseeDrOjh5iLvzp8sAIebCDGuaP5l8Sqvs0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.100] ([212.95.5.81]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mxm3K-1kJd271Eyc-00zG7j; Sat, 21 Nov 2020 10:02:17 +0100 In-Reply-To: <20201120210005.GA1034@ACM> Content-Language: en-US X-Provags-ID: V03:K1:slVMw/pOerCQkZFEJDDkVZ90x6ANsbkjc1MLv2o/DToguGN9h1L xy6gKAe62jCtQ8qE5NEtIScIss5AmQM8fbXQBphrKrHkircuG/m5xH9M3WemC7v2Hpja5So 3Q7jD2QylwxZWUhPtm/o2ZxeP8dBvd7iO8NQm7Fa1/fwamp2wDd0SsYZ1wMEqnyFuHaGqYR i567OBfApkSv5esw/fPoQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:j6Zt16ZVh+Y=:kcNufh2ej72ewnvjqJfJFO 5z46Zk0VntMnEB01a6MNg2J9NTOqzhFYsMqG6eFmV9gRQRLbkCoNp+sXrhygvOc9zcXdkTM71 d7WH+RA09OfNYVU6HsYPeFsWBJAH7KVddBwQCwHtwZL6laZ8G7ef5FuR+7VcdPavb4Nxy1e+a OIuACVQ4V2A3aOhOABhmyxJ+anpAAz0RBU0SrcjxSQX90TDPy02WIyCOuddGkcdaj7YAErTjP 4CHRMKQ6jifIrnHL2Fe+e7z8ACQq6PCrQ7gN3j9p7mXLG+kDE0IsYj/OMuUkXPWqoWpSN0IE0 ShurGpyqeYxpFGAu8TQQrew4opoM66Yd2hW0VQ+WrcbF3zcRwT78kIb2dYAtqxhaTutscFmxg q3INFKmNZx04MKJj+rz4djj5fqzxWYnQuNnblGTNjIwRE3lso8srhFlxsJF8nsLWMxT6NdYZU uKwq0CjT5/W3lHzmgWSe2xH00/YMmOq1/LR7bst3Rto/Jg/xXRoM+cbAoHlsnIEImzYkflOJC uu/8IPwIvujoIqfsHxkf/x4dYIcOOHSh6nF5+6IhqYLmOiUU2zAZYvmLXq/LZ2Ge+mNHqr8v6 7WOubzwjDuttjNRqCwgfZrNMDzLrogbCaTiUjKyukwl6p9zOxvjPGVW4z5rNYsC+zb8ffh2FJ hK8y2obB4xIai64VSj0pO+Hd1z/C+DIFMPkRmoXOFD1f0Rs3nwsxodVwJcrsgjAoAqA8mRg6U oRVJuZUfhqUGK4nJYHwT925PGcjmDfY7XJqqVTXoHTfC5jfWdSGla8lr00Hi5v0Xt9t2G+km Received-SPF: pass client-ip=212.227.17.21; envelope-from=rudalics@gmx.at; helo=mout.gmx.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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:259519 Archived-At: >> (setq default-frame-alist '((minibuffer . nil))) > >> (defun foo () >> (interactive) >> (read-from-minibuffer "...?") >> (insert (format "%s" (selected-frame)))) > >> insert (foo) into *scratch* and type C-x C-e. After answering the >> prompt this gets me #. Do the same with >> Emacs 27 and it will get you the *scratch* frame. > > Yes, I see this (except for the Emacs 27 bit which I haven't tried, > yet). > > However, if I type (frame-list) into *scratch* and do C-x C-e I get only > one frame in the list, and it has the same address in the # > output as the " *Minibuf-1* 0xxxx" output. You have to _load_ the (setq default-frame-alist '((minibuffer . nil))) part, it won't work after your default initial frame has been already set up. Run Emacs via something like emacs -Q --load ~/foo.el to see the effect (and please try to get used to test any changes in this area with such a setup as well). But indeed, with Emacs -Q executing 'foo' defined as (defun foo () (interactive) (read-from-minibuffer "...?") (insert (format "window: %s .. frame: %s" (selected-window) (selected-frame)))) reveals another aspect broken by your change. The values reported by 'selected-window' and 'select-frame' do not match up any more (unless our masochistic way or printing frame names hides an important detail). > In other words, I think your (insert (format "%s" (selected-frame))) is > getting the correct frame, but the current buffer within it is still the > minibuffer. The frame is _not_ correct - try with a separate minibuffer frame. > Might you possibly have simplified the recipe so much that the problem > is no longer shown by the recipe? Removing the setting of > default-frame-alist from the file doesn't seem to make any difference. See above. > Why were we selecting a frame as an "incidental" side effect of restoring > a window configuration? Surely the frame to be selected should be > selected deliberately and explicitly. Agreed. But I suppose the current behavior was chosen precisely to support the use case we're discussing here: With a separate minibuffer frame it has to restore the frame that was selected before the minibuffer interaction started. All the remaining stuff done by restore_window_configuration is rubbish IMHO. Basically, minibuffer only frames could work seamlessly were it not for the complications that people added over the years: 'restore_window_configuration': Anything the minibuffer dialogue changes in the window configuration of a normal frame (like popping up completions) should be undone immediately by the associated code. Any changes to the configuration done explicitly by the user in between (like, for example, splitting a window to run some other application in it) should not be undone. 'redirect-frame-focus': There's should be no need for that - when the minibuffer becomes active, raise its frame to send keystrokes to it. With the above minibuffer nil setting here I get a minibuffer frame that is hidden by the non-minibuffer frame when it shows the prompt - no wonder that people immediately refrain from using such a set up. The prompt must be initially visible - always and everywhere. Emacs should be no hide-and-seek game. 'frame-auto-hide-function': No need for that either. When a minibuffer frame becomes active, it should become visible and be displayed on top of the frame from where the dialogue originated. When the dialogue terminates, the minibuffer frame should return to its prior state. Obviously, people might dislike a minibuffer-only frame getting focus every time something is displayed in the echo area. But that's just a consequence of Emacs habit to conflate minibuffer and echo area in one and the same part of a user's display. > I'm thinking that what needs restoring is the frame's current buffer, and > I'm wondering why that wasn't done by the (set-window-configuration foo > t) which happened near the end of read_minibuf. A frame does not have a current buffer. The "current buffer" is a completely different concept. The only real connection is that in keyboard.c the set_buffer_internal (XBUFFER (XWINDOW (selected_window)->contents)); resets the current buffer to that of the selected window which also should be the selected frame's selected window. But your change apparently broke that. martin