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.bugs Subject: bug#44933: 27.1; Ephemeral frame selection shrinks minibuffer Date: Tue, 1 Dec 2020 10:33:42 +0100 Message-ID: <782db472-6b44-c62c-e175-44e77589b85f@gmx.at> References: <65A18F9E-3193-4DBD-84D8-4EDCA5AB95A1@toadstyle.org> <0dec5a12-e2f6-a210-6300-835bb3358d53@gmx.at> <000004F6-7D67-4D1D-84EA-517E254FBBDE@toadstyle.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32922"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 44933@debbugs.gnu.org To: Sean Devlin Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 01 10:34:35 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1kk23N-0008NQ-V3 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Dec 2020 10:34:34 +0100 Original-Received: from localhost ([::1]:37266 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kk23M-0007xH-F7 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Dec 2020 04:34:32 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52064) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kk22s-0007wm-Ei for bug-gnu-emacs@gnu.org; Tue, 01 Dec 2020 04:34:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46287) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kk22s-0007Th-7C for bug-gnu-emacs@gnu.org; Tue, 01 Dec 2020 04:34:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kk22s-0006ex-3d for bug-gnu-emacs@gnu.org; Tue, 01 Dec 2020 04:34:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Dec 2020 09:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44933 X-GNU-PR-Package: emacs Original-Received: via spool by 44933-submit@debbugs.gnu.org id=B44933.160681523225585 (code B ref 44933); Tue, 01 Dec 2020 09:34:02 +0000 Original-Received: (at 44933) by debbugs.gnu.org; 1 Dec 2020 09:33:52 +0000 Original-Received: from localhost ([127.0.0.1]:57833 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kk22i-0006eb-Gn for submit@debbugs.gnu.org; Tue, 01 Dec 2020 04:33:52 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:54925) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kk22g-0006eN-S8 for 44933@debbugs.gnu.org; Tue, 01 Dec 2020 04:33:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1606815224; bh=RoQJ7graPf/T8IhQ9xHx4wWfYfKW0MxH+2cFWcGTo+k=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=SYPEzGCLuXKrH298eElrJmvhzBHlJnZyYtnytpc52MMZ8EaLNqnQrkYBApcUe6s2W lGWTvMxY44ZHYzdozZ3de9cNGiyKnpTD5bDZ/KFsxIKkIjyxNJOyg+FIK09qRRgSPK y2ZElOcnbfyhU3YhdotuW/DZr7C1ZSC5lleEj4/A= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.100] ([212.95.5.163]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MKsnF-1kTrXB0hAr-00LHps; Tue, 01 Dec 2020 10:33:44 +0100 In-Reply-To: <000004F6-7D67-4D1D-84EA-517E254FBBDE@toadstyle.org> Content-Language: en-US X-Provags-ID: V03:K1:jo2RbYVQAjB15GfzNjEi9+LLJJPQmEP9tsrGLnc4/82FA2mUb7m WTCIkSoUJW4rAoiNhHJSMHe15sO/MCsJYe9d2WFTMOYLVKh0s0+HSa8FTWnUvDPZAyV7AkI x3wDT4HLePE72BUBA4NjCyJUamUiI4eyGw/+7qbn0OQmLTfz+4GkOH4LzU1aVwJ/hjNj8f6 jw8Tqs5jQjlNx2zLxjO/A== X-UI-Out-Filterresults: notjunk:1;V03:K0:5hGRc85oLZg=:RoB+K183r/03x5Z9tW6/Xz 48JfzA4xdV6gn3NpL77E5X2bftpL+kvS0m6xg7RcDotFMdeeckvs5YjfBGUh9A2GNyubUK8Tn tKj6uG9Jzs2EWae4CxK26Jf8JNwk+CxNDy4+qNNck2UBl2sq/OfC7pTd+ap/dsKvXMwr7n8jV 3NG+IVBjWq9K4Pw178O7xgUTn77Q7rRreVVLlGtXCnKNttR/AZ5RcrkXn9R7Uzel2vc7Qpi6V dO07hxO6sbwYYtEzRYlakXGPVO4l2i3ITG0IVMLnsvLsMkXBIcitksxPscrcz8PHgk6DXu07h igTmmGwLyinXY8tlCgYmmwCTIXY5HVl/Legvd93gjPdvkCZ7D1BCRQdeBhpP9CfoUVciFGdt9 kiSpjgB9U7+YmZVxMfOqLO+hpNAVDhR9IGZvKFpFysoNE3pICOBJSHHCVnsOZBxGfJyFZFFJE zwf2/kJMQSdjm2cU6MhfoQFg6k2a/IbKepR3VXG4y5eippbvrCNB/dH2Z4h9SidFqiIGu+dyh idIQzq4qiAR36f0wSvryKRnMdu3sUewwDhFWdSaJPcYOR9pTIY8dI6WbhMLJooXDIysVpPfNN BkOq1it48nZF8ZqYA1KjOfF0ijTqUFnSBoNN/j/xdgmcXPwjn49V84/Rd164VnTgubRKle+Sx LB6HEuY0SOHPH/rtFwr0gGqvNPE0etQLkMvsFcOYWfDoI3hSaSuTYgMBzcsqE8jq1vy7l7HKD J1wr94nbsdT2rwLkhMQp0ohj2/1NzzRI739JJkQJfmFvZaHLTK1lxftSkv3KWUF0aPC8CoMD X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:194719 Archived-At: > I=E2=80=99m not sure I understand. Are you saying a program should not= be able > to grow the minibuffer window this way? Or just that it will be undone= > by the next resizing event? (Of course, this is a toy example, so I > have no opinion on what the correct behavior should be. I=E2=80=99m ju= st > wondering.) With 'resize-mini-windows' non-nil, redisplay can resize a normal minibuffer window (the one at the bottom of a normal frame) any time thus overriding any manual resizing done by the user. With 'grow-only' it cannot auto-shrink it to some value above the minimum one, so if you make the window manually very large, redisplay can shrink it only when the minibuffer gets empty. Note that there is no "correct" behavior here, everything grew out of fixing inconveniences found in daily use. > I=E2=80=99ve been playing with this a bit (on a recent Emacs 28.0.50),= and I=E2=80=99m not sure I understand the current behavior. > > For example, I have three frames open and I ran this code in the scrat= ch buffer: > > (with-current-buffer (window-buffer (minibuffer-window)) > (remove-overlays) > (erase-buffer) > (insert "this is some text") > (let ((ov (make-overlay (point) (point) nil t t))) > (overlay-put ov 'after-string "\none\ntwo\nthree"))) > > After moving the point, all I can see is the first line in the minibuf= fer: =E2=80=9Cthis is some text=E2=80=9D. This is true across all three f= rames. > > If I select the other frames by clicking on them, the frame that just = lost focus will now show all four lines (i.e. including the overlay). The= minibuffer windows on the other frames will stay at one line until I sel= ect them by clicking and then select some other frame. > > On the other hand, if I select frames by calling `other-frame` via a k= ey binding, the behavior is slightly different: the minibuffer window on = a frame expands to four lines as that frame loses focus, and the minibuff= er window on the newly selected frame contracts back down to one line. > > Are all of these behaviors expected and correct? (Again, I have no opi= nion; I=E2=80=99m just trying to understand how things are meant to work.= ) Your example is a bit contrived in the sense that just inserting text into a minibuffer that is not active is not something redisplay really cares about. Putting that overlay into a prompt and then switching frames is more realistic wrt what redisplay really cares about. > This function is the process filter for a term process, so it handles > new output from the process. After doing so, it iterates over all the > windows to see if any contain the process buffer. For any that are, it= > selects those windows and scrolls those windows appropriately. I didn't read the code very attentively but let's make sure one thing: The behavior you see happens only when there are at least two frames so the (setq win (next-window win nil t)) in 'term-emulate-terminal' and the subsequent (select-window win) really get executed and the latter selects a _different_ frame thus causing the earlier mentioned if (!for_deletion && FRAME_HAS_MINIBUF_P (sf)) resize_mini_window (XWINDOW (FRAME_MINIBUF_WINDOW (sf)), 1); Maybe you could instrument 'term-emulate-terminal' and 'do_switch_frame' (debugging this is probably useless) so that they write something into a buffer and we can see the precise interleaving of steps leading to the behavior seen. >> With the recently added 'minibuffer-follows-selected-frame' we now ha= ve >> an additional source of complications to consider. Maybe you could, = as >> soon as the implementation of the latter has consolidated, play with = the >> various values of 'resize-mini-windows' and suggest suitable fixes fo= r >> the documentations of 'select-window' and 'select-frame'. > > Sure, I can do that. Is there a timeline for this or some place I can = follow development progress? You can try to follow the thread "Stop frames stealing eachothers' minibuffers!" on emacs-devel and you will see that we all are quite often surprised by how the various versions of Emacs handle switching from one minibuffer window to another. > From testing the current implementation, it seems selectrum has a > similar issue here: when I switch to a new frame, the minibuffer does > follow, but the list of candidates is hidden until I enter a new > input. I suppose "showing the list of candidates" is part of a minibuffer interaction and the initial prompt is shown correctly on its frame but disappears when moving to another frame via C-x 5 o. Right? martin