From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Sean Devlin Newsgroups: gmane.emacs.bugs Subject: bug#44933: 27.1; Ephemeral frame selection shrinks minibuffer Date: Tue, 1 Dec 2020 15:32:48 -0500 Message-ID: References: <65A18F9E-3193-4DBD-84D8-4EDCA5AB95A1@toadstyle.org> <0dec5a12-e2f6-a210-6300-835bb3358d53@gmx.at> <000004F6-7D67-4D1D-84EA-517E254FBBDE@toadstyle.org> <782db472-6b44-c62c-e175-44e77589b85f@gmx.at> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.31\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_875FD9EF-9E57-48E4-A5DD-7455ECA1559E" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8633"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 44933@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 01 21:38:15 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 1kkCPf-00029b-0H for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Dec 2020 21:38:15 +0100 Original-Received: from localhost ([::1]:35436 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kkCPd-00089h-VV for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Dec 2020 15:38:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33042) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kkCKd-0002FW-JB for bug-gnu-emacs@gnu.org; Tue, 01 Dec 2020 15:33:07 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50018) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kkCKb-0003dN-Um for bug-gnu-emacs@gnu.org; Tue, 01 Dec 2020 15:33:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kkCKb-0003LU-OH for bug-gnu-emacs@gnu.org; Tue, 01 Dec 2020 15:33:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Sean Devlin Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Dec 2020 20:33:01 +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.160685478012853 (code B ref 44933); Tue, 01 Dec 2020 20:33:01 +0000 Original-Received: (at 44933) by debbugs.gnu.org; 1 Dec 2020 20:33:00 +0000 Original-Received: from localhost ([127.0.0.1]:33331 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kkCKZ-0003LE-Nc for submit@debbugs.gnu.org; Tue, 01 Dec 2020 15:33:00 -0500 Original-Received: from mail-qk1-f175.google.com ([209.85.222.175]:41482) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kkCKX-0003Ky-1b for 44933@debbugs.gnu.org; Tue, 01 Dec 2020 15:32:58 -0500 Original-Received: by mail-qk1-f175.google.com with SMTP id d9so2662196qke.8 for <44933@debbugs.gnu.org>; Tue, 01 Dec 2020 12:32:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toadstyle-org.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=6h0klKW16QG1+RYJbNKbIBAkau1PeZRFGft9ABGLd/A=; b=Q9DdQVDi+B1HCMFJR6Ci792WY8OhR7G+HWS3dCjo9wsteZpOXPgmpovTmaPrlAvIpU n5GE9OcziMYQj45rCI+DcuqjXoiJVzsYROCbhFbiVjZUlNDGEzqByFunWZFuF369o9VE YAB3tvXWEFxaebXP6BC+DDfFZKjdX4jtiB2FFtK7S+AUdHfaWhNxMndGCERkMWCOx8uS Lv1oHpESGPjDPMt2nfH7/TnDblNPGAgHWqD2phWA93CxvggkJ+NYMYoxPiIQ6TudiAaH YCbnAoy0lnYgCpiBlMgVu4xQ+GO4tprp2z8a6GqPHqE0irPsH7bVEwr7HUG4Y1d4V2Eb QiAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=6h0klKW16QG1+RYJbNKbIBAkau1PeZRFGft9ABGLd/A=; b=O2D83xQoY6Y6CE+yfOfaTfq4uqZkhU8Tdy4m0uQY6a6ZvwpDEPnLdEiQYYpFeLDwyQ Xp/RvE3/wqy4I51xHYAVbK3AKXPJlh9nZuPh50vCy2M/dp6dv9RdxrjJY3eTsefE8qmr 0Ved1keZkqBACAg2en3V7so+D54OG83XeYuiytBcIYLw3lMwS9TIXdoi0FmjiJ1XIqQY w6ZOrhs1RGIh3LNdo+jcAwHFDNO3MEEAPO3mylftSucX2v1Zbus2wcW6uvxuNR0coTt0 Gj00RGCNvpld/tL7B68JXxtasL+W9YGxzUKM2X6OohmiNHq7po4rI8HvYGELrUCPeKSD Xzuw== X-Gm-Message-State: AOAM532352hek9q0gmIj6b0lmjUE0lXrUU8pbbxb+Es/ZGId09uRb2ho TIi/aFV5jo4tjNrrJ7fjPFGhvw== X-Google-Smtp-Source: ABdhPJwv+jfnu+14N2YZvC430shi1W4KumnGGwHRHBeT/OsfH7pnZiJInlCSgdUw1wdpTmn4y+8kGA== X-Received: by 2002:ae9:ed0f:: with SMTP id c15mr4931828qkg.348.1606854771278; Tue, 01 Dec 2020 12:32:51 -0800 (PST) Original-Received: from ?IPv6:2604:2000:14c6:84b0:7527:ad6a:987b:415e? ([2604:2000:14c6:84b0:7527:ad6a:987b:415e]) by smtp.gmail.com with ESMTPSA id y1sm829105qky.63.2020.12.01.12.32.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Dec 2020 12:32:50 -0800 (PST) In-Reply-To: <782db472-6b44-c62c-e175-44e77589b85f@gmx.at> X-Mailer: Apple Mail (2.3654.40.0.2.31) 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:194759 Archived-At: --Apple-Mail=_875FD9EF-9E57-48E4-A5DD-7455ECA1559E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Martin, > On Dec 1, 2020, at 4:33 AM, martin rudalics wrote: >=20 > > 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 = just > > wondering.) >=20 > 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 see, so redisplay could happen at any time, and redisplay can resize = the minibuffer window (contingent on `resize-mini-windows`). I guess in = the extreme case, any code could call the `redisplay` function = explicitly. >=20 > > 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 = scratch 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 = minibuffer: =E2=80=9Cthis is some text=E2=80=9D. This is true across all = three frames. > > > > 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 select them by clicking and then select some other frame. > > > > On the other hand, if I select frames by calling `other-frame` via a = key binding, the behavior is slightly different: the minibuffer window = on a frame expands to four lines as that frame loses focus, and the = minibuffer window on the newly selected frame contracts back down to one = line. > > > > Are all of these behaviors expected and correct? (Again, I have no = opinion; I=E2=80=99m just trying to understand how things are meant to = work.) >=20 > 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. Fair point, it=E2=80=99s definitely a contrived example. >=20 > > 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. >=20 > 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 >=20 > (setq win (next-window win nil t)) >=20 > in 'term-emulate-terminal' and the subsequent >=20 > (select-window win) >=20 > really get executed and the latter selects a _different_ frame thus > causing the earlier mentioned >=20 > if (!for_deletion && FRAME_HAS_MINIBUF_P (sf)) > resize_mini_window (XWINDOW (FRAME_MINIBUF_WINDOW (sf)), 1); >=20 > 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. Yeah, I think it does depend on having multiple frames. In the specific = case where I first noticed the strange behavior, my setup was: Frame X with a window displaying a subprocess running under term Frame Y with a window displaying some other buffer Frame Y is selected Selectrum (https://github.com/raxod502/selectrum) is installed as the = completing read implementation I invoked some command that performed a completing read via selectrum = (e.g. `find-file` or similar) with the list of candidates displayed = vertically below the prompt. While I was sitting with that prompt, the = subprocess sent some output. This induced the temporary selection of = frame X via the code in term, which caused the list of completing read = candidates to disappear. Anyway, I=E2=80=99ll perform the instrumentation you suggest, so we can = understand specifically what is happening. >=20 > >> With the recently added 'minibuffer-follows-selected-frame' we now = have > >> 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 = for > >> 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? >=20 > 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. Thanks, I=E2=80=99ll check it out. >=20 > > =46rom 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. >=20 > 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? Yes, exactly. I can try to make a video of this if it would help. Thanks! >=20 > martin >=20 --Apple-Mail=_875FD9EF-9E57-48E4-A5DD-7455ECA1559E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Martin,

On Dec 1, 2020, at 4:33 AM, martin rudalics = <rudalics@gmx.at> = wrote:

> 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 just
> 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 = see, so redisplay could happen at any time, and redisplay can resize the = minibuffer window (contingent on `resize-mini-windows`). I guess in the = extreme case, any code could call the `redisplay` function = explicitly.


> 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 scratch = 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 = minibuffer: =E2=80=9Cthis is some text=E2=80=9D. This is true across all = three frames.
>
> 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 select them by = clicking and then select some other frame.
>
> On the other hand, if I select frames by calling = `other-frame` via a key binding, the behavior is slightly different: the = minibuffer window on a frame expands to four lines as that frame loses = focus, and the minibuffer window on the newly selected frame contracts = back down to one line.
>
> Are all of = these behaviors expected and correct? (Again, I have no opinion; I=E2=80=99= m 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.

Fair point, it=E2=80=99s definitely a contrived = example.


> 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.

Yeah, = I think it does depend on having multiple frames. In the specific case = where I first noticed the strange behavior, my setup was:

  • Frame X = with a window displaying a subprocess running under term
  • Frame Y with a window displaying some other buffer
  • Frame Y is selected
  • Selectrum (https://github.com/raxod502/selectrum) is installed as = the completing read implementation

I invoked some command that performed a = completing read via selectrum (e.g. `find-file` or similar) with the = list of candidates displayed vertically below the prompt. While I was = sitting with that prompt, the subprocess sent some output. This induced = the temporary selection of frame X via the code in term, which caused = the list of completing read candidates to = disappear.

Anyway, I=E2=80=99ll perform the = instrumentation you suggest, so we can understand specifically what is = happening.


>> With = the recently added 'minibuffer-follows-selected-frame' we now have
>> 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 for
>> 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.

Thanks,= I=E2=80=99ll check it out.


> =  =46rom 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?

Yes, = exactly. I can try to make a video of this if it would = help.

Thanks!


martin


= --Apple-Mail=_875FD9EF-9E57-48E4-A5DD-7455ECA1559E--