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: Mon, 30 Nov 2020 14:32:27 -0500 Message-ID: <000004F6-7D67-4D1D-84EA-517E254FBBDE@toadstyle.org> References: <65A18F9E-3193-4DBD-84D8-4EDCA5AB95A1@toadstyle.org> <0dec5a12-e2f6-a210-6300-835bb3358d53@gmx.at> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.31\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40732"; 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 Mon Nov 30 20:33:16 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 1kjovC-000AOL-Mb for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 30 Nov 2020 20:33:14 +0100 Original-Received: from localhost ([::1]:38540 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kjovB-00084W-NG for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 30 Nov 2020 14:33:13 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50966) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kjov1-000832-8o for bug-gnu-emacs@gnu.org; Mon, 30 Nov 2020 14:33:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45162) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kjov0-0002Wq-Cl for bug-gnu-emacs@gnu.org; Mon, 30 Nov 2020 14:33:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kjov0-0000ej-98 for bug-gnu-emacs@gnu.org; Mon, 30 Nov 2020 14:33:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Sean Devlin Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 Nov 2020 19:33: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.16067647572490 (code B ref 44933); Mon, 30 Nov 2020 19:33:02 +0000 Original-Received: (at 44933) by debbugs.gnu.org; 30 Nov 2020 19:32:37 +0000 Original-Received: from localhost ([127.0.0.1]:56708 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kjoub-0000e6-9N for submit@debbugs.gnu.org; Mon, 30 Nov 2020 14:32:37 -0500 Original-Received: from mail-qt1-f176.google.com ([209.85.160.176]:34465) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kjouY-0000ds-Gs for 44933@debbugs.gnu.org; Mon, 30 Nov 2020 14:32:35 -0500 Original-Received: by mail-qt1-f176.google.com with SMTP id 7so9088748qtp.1 for <44933@debbugs.gnu.org>; Mon, 30 Nov 2020 11:32:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toadstyle-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IfdKtvrvZ5dPfZctOAO6qhy9tJGFgxn78RhZkGyrJgo=; b=DFR82xw9Pxw4MBdi5BHd2uPpUkGScMfZfCVNPq2XOezM/AHs53R5V5SCId1qeDjCEH dTh5KZ/+9BflB+rOODoja05x9jMDECRp2RjwvUui4Y5gECv/U9xJc/MDUdVsyipSkWqo xaji3q9Hwz8lLi/2VT5m8D6o51XuPRXiokhgFuU4l+hmpzsKjC8g4I3OWtPi9mGRJf0v Ve0wqrZhgvGpACH3LtmiQDrVJ+30tVRHzWWy+5X4yG8tkZJAav4qEz+rnARL0hi3BCQ1 Y4QjpM14YWK4fHLDAjLyVj14p+H/FI8iPIhhjFHZ2naD7qi15T/ShEGgtxtgM2PdVprA JYyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IfdKtvrvZ5dPfZctOAO6qhy9tJGFgxn78RhZkGyrJgo=; b=XNtL845oViLbLE0BmkwMgRvIccWpgqXYNQCEyi02PPzeOpzyrgw6XmexjdwLJqxUTT 3z1rVXCeXbEW/zgzidRZlgx1VyEzTkgtvNG0eDS4yDU4PJ5tWprPYxaVHQpwQiWAwQZE X+OC1MngjPh2h5HBcqj25gRwon63HA7bKa875/oaOxp5St90CokF3l0P25bSaSFtSfkn 0H8Ebw89+oPOpFi5aogRC3PRM5aw2ZK9ZoUjBXH88XHWH/nSK8NBz+t8+FFRmBLo4MWL zCLrv5H78q/crBM5IDePwgZ9ccu66k62Y0qgwxKZ9jE0WA7GueXsnWW4geNSkseQd5Xr 1NyQ== X-Gm-Message-State: AOAM533vXm2b4abbEXZP6zndGXyN1qy/In1xq1egYSWGySBPG8Evv0RC n0Cx4qvVMu3pt7UDzTw9dCsBAw== X-Google-Smtp-Source: ABdhPJx+cU1N2oupWGbpf3HXjV4dsO3YaT/QXM2mT3hmhsqmf58f7igXnPNEbVA1anEgDEldcQMvvg== X-Received: by 2002:ac8:6bc6:: with SMTP id b6mr23880728qtt.127.1606764748893; Mon, 30 Nov 2020 11:32:28 -0800 (PST) Original-Received: from ?IPv6:2604:2000:14c6:84b0:2038:7137:c288:7ddf? ([2604:2000:14c6:84b0:2038:7137:c288:7ddf]) by smtp.gmail.com with ESMTPSA id f14sm15730919qkk.89.2020.11.30.11.32.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Nov 2020 11:32:28 -0800 (PST) In-Reply-To: <0dec5a12-e2f6-a210-6300-835bb3358d53@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:194677 Archived-At: Hi Martin, > On Nov 30, 2020, at 4:04 AM, martin rudalics wrote: >=20 > > In my reproduction, the minibuffer window is grown manually via > > `window-resize`. >=20 > With 'resize-mini-windows' non-nil this usually has no visible effect > because any such manual resizing is immediately undone by the = automatic > resizing scheme. 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 > > In the case of selectrum, the completing read > > candidates are displayed via overlay. I think this means that a > > resizing function that considers the buffer text only will resize > > these back down to a single line. >=20 > The routine that determines the window size (resize_mini_window in > xdisp.c) should consider overlays as well (if they are in the right > buffer). Anything else would be a bug. 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 > > I just tested, and binding `resize-mini-windows` to nil around the > > window selection in `term-emulate-terminal` does solve my > > problem. Does this seem like the right fix? I think it is surprising > > that output from a term process coming in the background should = resize > > a minibuffer window (and especially an active one). >=20 > If you look into the code of do_switch_frame (in frame.c) you will be > able to spot >=20 > if (!for_deletion && FRAME_HAS_MINIBUF_P (sf)) > resize_mini_window (XWINDOW (FRAME_MINIBUF_WINDOW (sf)), 1); >=20 > which means that currently even redisplay itself may resize the mini > window every time it constructs a mode line or frame title. I can = only > offer two advices: (1) Avoid 'with-selected-window/frame' in timers = and > (2) make sure no redisplay happen _within_ such a form. Interesting. I think this partially explains the behaviors I=E2=80=99m = seeing above. To be clear, `term-emulate-terminal` is a process filter. I=E2=80=99m = not sure if that=E2=80=99s exactly like a timer under the hood, but it = does run without user interaction. >=20 > > Also, I see that `term-emulate-terminal` is calling `select-window` = to > > perform its window selections. =46rom my reading of the docs, I = think it > > might make sense for it to pass `mark-for-redisplay` as the = `norecord` > > argument. It doesn't seem like we should be modifying the buffer = list > > or most recently selected window in this case, but we do want to > > redisplay the new output. >=20 > I would have to understand the semantics of 'term-emulate-terminal' to > answer that. Hopefully, someone else can chime in here. I can give a little information here, though someone else will surely = know more. 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 think the documentation should clarify that window selection can > > change window sizes as a side effect. The docs for selecting windows > > = (https://www.gnu.org/software/emacs/manual/html_node/elisp/Selecting-Windo= ws.html) > > do not mention that `select-window` can change minibuffer sizes. The > > docs for minibuffer windows > > = (https://www.gnu.org/software/emacs/manual/html_node/elisp/Minibuffer-Wind= ows.html) > > do mention these variables to control how minibuffer windows can be > > resized automatically, but they do not say what functions might try = to > > do this automatic resizing. >=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? =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 > Alternatively, we could consider skipping the >=20 > resize_mini_window (XWINDOW (FRAME_MINIBUF_WINDOW (sf)), 1); >=20 > above for temporary window/frame selections (and at least for = redisplay > as I currently do here) but the consequences of such a step are not > easily fathomable. >=20 > > Finally, I wonder if `with-selected-window` (which > > `term-emulate-terminal` does not currently use) should bind > > `resize-mini-windows`. >=20 > ... with the consequences I mentioned in the sentence before ... >=20 > > The docs say it is "the preferred way to > > temporarily work with" a selected window, so it does seem like > > automatic resizing is not in the spirit of the function. On the = other > > hand, I don't know all the existing use cases; maybe this would = break > > things. >=20 > Right. >=20 > martin