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: Sun, 29 Nov 2020 10:43:18 -0500 Message-ID: References: <65A18F9E-3193-4DBD-84D8-4EDCA5AB95A1@toadstyle.org> 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="38908"; 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 Sun Nov 29 16:44:14 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 1kjOs2-000A17-JC for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 29 Nov 2020 16:44:14 +0100 Original-Received: from localhost ([::1]:58012 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kjOs1-0005dU-LW for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 29 Nov 2020 10:44:13 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59786) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kjOrq-0005b9-KN for bug-gnu-emacs@gnu.org; Sun, 29 Nov 2020 10:44:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40735) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kjOrq-0004KQ-DB for bug-gnu-emacs@gnu.org; Sun, 29 Nov 2020 10:44:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kjOrq-00054q-Bw for bug-gnu-emacs@gnu.org; Sun, 29 Nov 2020 10:44: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: Sun, 29 Nov 2020 15:44: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.160666460819440 (code B ref 44933); Sun, 29 Nov 2020 15:44:02 +0000 Original-Received: (at 44933) by debbugs.gnu.org; 29 Nov 2020 15:43:28 +0000 Original-Received: from localhost ([127.0.0.1]:52281 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kjOrH-00053T-LA for submit@debbugs.gnu.org; Sun, 29 Nov 2020 10:43:28 -0500 Original-Received: from mail-qk1-f176.google.com ([209.85.222.176]:42734) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kjOrF-00053D-Dh for 44933@debbugs.gnu.org; Sun, 29 Nov 2020 10:43:26 -0500 Original-Received: by mail-qk1-f176.google.com with SMTP id z188so8684742qke.9 for <44933@debbugs.gnu.org>; Sun, 29 Nov 2020 07:43:25 -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=r5UE3a4jxxbv8a9d4aBk4ft2nua4nWRf74NmTpbPI1E=; b=xziyiGq1ddTEUIPq3Q8Cj1BSJ+fFLKzHNm0Qx/jflmfxRbQBfCnoqj37F2090DpGwZ gJzKb4CElOFoqUcDea7radk0xb7ddZfJoyGToM1fhWseW/3W5XcQaRj/CjAk+dokxLoV r8KQ0RmLwsE6WNAKolEGljrqytBu23mq7dm+c8vqj1dEy7yhMj51K5i7H6gpJaGpSuqN YgWxx4Uc3Fq6yF2YeMidUmeozJ/t/mGdPgq5wNvI8wnoejbz58PHYurh+jXrL3yrJYOB i5y6pu6DpbwhaBqXtHgR8E3lzyUayre9l2rQR8HGLlkHRhDggvb6cJNPCSuW7fiZH8M9 mLUA== 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=r5UE3a4jxxbv8a9d4aBk4ft2nua4nWRf74NmTpbPI1E=; b=GfhY/kzkWUnnKXLmGBkcPY8K6gvhXaLHEAn0F5juNpXcr6ywK9AfLEQE1hLF0Gj3DD rh3V7NCeHbSTc27YrCEHB3dTf7OpikytkKWu1Ms/E7r6Md4wo1uQs5lFPxnsbH3wRkHm C/eES4nV+ylNyAwLXCPo057/PdpIfQ0HsSymmBS/FeJTwm9IsNDErpdN94nMk+2Xh8HQ a90YcSL85xwXxmCJ0INARUKoPdhNBjTU7xYS6PdkfuymJF0lJP+g8te/hCd/g0UsemVY 8Lw75ASn+/iRXczwbSZMQiFyT57sAoYtJnBGN9389/oMC7QsKB9+vvsx/MIXXwYt7sxR mhqQ== X-Gm-Message-State: AOAM530HbllrhsNA3nZk70Aj375D45Rr24PbPtk3qjOhNvfX/RUlq/80 Hxj5x9ngHtMhftkB9OA5LJdRQo4TQbsYwA== X-Google-Smtp-Source: ABdhPJzOsW0HnPzSZ5LPzbuR8JP/LEBWIZPSNlvPz8R2JHoKjitug6XdijyCJfaeMnl+82BkL5pYog== X-Received: by 2002:a05:620a:852:: with SMTP id u18mr7389883qku.365.1606664599816; Sun, 29 Nov 2020 07:43:19 -0800 (PST) Original-Received: from ?IPv6:2604:2000:14c6:84b0:f026:b7b7:6302:bfe1? ([2604:2000:14c6:84b0:f026:b7b7:6302:bfe1]) by smtp.gmail.com with ESMTPSA id g70sm11519531qke.8.2020.11.29.07.43.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Nov 2020 07:43:19 -0800 (PST) In-Reply-To: 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:194564 Archived-At: Hi Martin, > On Nov 29, 2020, at 3:22 AM, martin rudalics wrote: >=20 > > Selecting a different frame ephmerally (e.g. via = `with-selected-frame` > > in a timer callback) shrinks the minibuffer. This is true whether or = not > > the minibuffer is active. > > > > Reproduction steps: > > > > 1. Evaluate this form in the scratch buffer: > > > > (run-with-timer nil 13 (lambda () (with-selected-frame > > (next-frame)))) > > > > 2. Evaluate this form in the scratch buffer: > > > > (run-with-timer nil 11 (lambda () (window-resize = (minibuffer-window) > > 10))) > > > > 3. Observe that the minibuffer grows and shrinks as the timers fire. >=20 > Here I need two frames to observe 3. With one frame the minibuffer > window grows continuously. Ah, you=E2=80=99re right. I had left this out of my reproduction steps. = Sorry! >=20 > > You can run some completing read command (e.g. `M-x`) to see that = the > > resizing happens whether or not the minibuffer is active. > > > > This is relevant for completing read implementations that resize the > > minibuffer to display a vertical list of candidates. I noticed the > > behavior while using selectrum = (https://github.com/raxod502/selectrum) > > while I had a subprocess running under term in another frame. Since = the > > `term-emulate-terminal` function selects windows in the background > > whenever the subprocess sends output, it was causing the selectrum > > minibuffer to shrink. > > > > I'm not sure what the correct behavior is here, but this was = unexpected > > to me. I think that if the minibuffer is active, ephemeral frame or > > window selections should not affect its size. (I'm less certain = about > > the inactive minibuffer case, but I think the size should stay the = same > > there as well.) >=20 > To my knowledge we have no means to select a frame "ephemerally". > 'with-selected-frame', 'with-selected-window' are just as "hard" as > 'select-frame' and 'select-window'. And so the only way to prevent > switching frames from shrinking the previously selected frame's > minibuffer window is to set 'resize-mini-windows' to nil. OTOH with > 'resize-mini-windows' non-nil, re-selecting the previously selected = frame > when returning from a 'with-selected-frame' should size its minibuffer > window back to its contents provided it is still active. But I'm = never > sure whether all these work as advertised. I see, thank you. It looks like the default value for `resize-mini-windows` is `grow-only`. The docs for `resize-mini-windows` suggest it is used along with the text in the minibuffer to decide how to resize the window. I think this may be the issue, since my minibuffer has no text spanning multiple lines. In my reproduction, the minibuffer window is grown manually via `window-resize`. 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. 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). 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. 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. Finally, I wonder if `with-selected-window` (which `term-emulate-terminal` does not currently use) should bind `resize-mini-windows`. 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. Thanks! >=20 > martin