From unknown Fri Aug 15 04:03:38 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#66773 <66773@debbugs.gnu.org> To: bug#66773 <66773@debbugs.gnu.org> Subject: Status: 29.1; Ido displays incorrectly with multiple frames when ido-max-window-height=1 Reply-To: bug#66773 <66773@debbugs.gnu.org> Date: Fri, 15 Aug 2025 11:03:38 +0000 retitle 66773 29.1; Ido displays incorrectly with multiple frames when ido-= max-window-height=3D1 reassign 66773 emacs submitter 66773 Spencer Williams severity 66773 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 27 05:27:20 2023 Received: (at submit) by debbugs.gnu.org; 27 Oct 2023 09:27:21 +0000 Received: from localhost ([127.0.0.1]:35078 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qwJ7a-0000Tr-PI for submit@debbugs.gnu.org; Fri, 27 Oct 2023 05:27:20 -0400 Received: from lists.gnu.org ([2001:470:142::17]:32834) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qw6rQ-0004wR-Ro for submit@debbugs.gnu.org; Thu, 26 Oct 2023 16:21:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qw6qq-0004rc-8B for bug-gnu-emacs@gnu.org; Thu, 26 Oct 2023 16:21:08 -0400 Received: from [23.94.94.179] (helo=mail.plexwave.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qw6qe-0004Wz-21 for bug-gnu-emacs@gnu.org; Thu, 26 Oct 2023 16:21:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plexwave.org; s=mail; t=1698351308; bh=XZDON+3idRKJIId0OCOcDZWVic9eGcKuOzTWSSt2hYg=; h=From:To:Subject:Date:From; b=CoxGyj8V4uPJFV002ggoZlv9VRPbY9GNvBQwAu+FCMPqNWWkuI4z9bRxGKW/loO2p eieVdM21w1bDuPWjdbzrJv2qGbaP0p813UOjm6BOJxryuYlnOOw3oLaGxf4nHXnGVn 9qsOSNmia4xxTdg+BuJ5r9PTPw/l9LXxB/92DH0qEgoICo3NsnEm1N8FL9bPXvbYgq 2H2P+OX3dHXGOc/dWZ93y1LkHZKbETLTI5dVKKoW4crakopWO1BfP+D3Foj4o1q1ow N09vTR0dGxpcuH29zOV6eXDoLJpU46OrTSdJGa7ry4stcVr64cRlumodEnB30BCpyM GV5kFQ3Os0kZg== From: Spencer Williams To: bug-gnu-emacs@gnu.org Subject: 29.1; Ido displays incorrectly with multiple frames when ido-max-window-height=1 Date: Thu, 26 Oct 2023 16:15:07 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Host-Lookup-Failed: Reverse DNS lookup failed for 23.94.94.179 (failed) Received-SPF: pass client-ip=23.94.94.179; envelope-from=spnw@plexwave.org; helo=mail.plexwave.org X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Fri, 27 Oct 2023 05:27:01 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) When using multiple graphical frames, setting ido-max-window-height to 1 only works as expected on the initial frame. On all other frames, supposing the minibuffer length is great enough, the beginning will be occluded until user input is received. This can be easily demonstrated by running the following code on a fresh graphical Emacs, and then pressing C-x b to switch buffers: (progn (ido-mode 1) (setq ido-max-window-height 1) (dotimes (i 100) (generate-new-buffer "foobar")) (make-frame)) The bug manifests on both Linux and macOS (vanilla builds). It was not present on Emacs 28. I ran a git-bisect and the "first bad commit" appears to be c0b9041ebde82907711cc00a7c307fe622fb541c. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 27 06:50:29 2023 Received: (at 66773) by debbugs.gnu.org; 27 Oct 2023 10:50:30 +0000 Received: from localhost ([127.0.0.1]:35200 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qwKQ6-0005nJ-GY for submit@debbugs.gnu.org; Fri, 27 Oct 2023 06:50:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44918) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qwKQ4-0005n6-Uu for 66773@debbugs.gnu.org; Fri, 27 Oct 2023 06:50:25 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qwKPU-0006OK-8k; Fri, 27 Oct 2023 06:49:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=CS2SrVHnnrX7BuSbvROxZNEkH5FK5f2DqJLMHP4j05Y=; b=Wv9mbi6sb4FH l7XO8ogwxk3ZdnS8IZu0P0fHofun3IOV5IoAE+xSubDMwxaUQdAxmKGT20S3TBMn2U8JQ3AcXSoVz xFZRyjobq93Q+BZHpp9sHoWvkiWZ6GxbtKcc2UbQ7GctJvvDSeFpRHN/3A8n3iaP7lLIWmtQgBKTZ s9ZNDpiOSO2sxLv7coCLa7MbZ1Qaw5l36MlYLD+DW/Ll+RfgAYDHCh+nhPB5jprM7biy/42bT/wYn WdvCWZ0ZLRSVQ/QRMxCH1BdGEiVdPG0NFP8TOkSaAO9Huljmr742SfooKM8kSZfg0thPaLefZ1lQr yOM++Uhllbq6GXqJKkQM0A==; Date: Fri, 27 Oct 2023 13:49:56 +0300 Message-Id: <83leboe3vv.fsf@gnu.org> From: Eli Zaretskii To: Spencer Williams In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#66773: 29.1; Ido displays incorrectly with multiple frames when ido-max-window-height=1 References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66773 Cc: 66773@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Thu, 26 Oct 2023 16:15:07 -0400 > From: Spencer Williams via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > When using multiple graphical frames, setting ido-max-window-height to 1 > only works as expected on the initial frame. On all other frames, > supposing the minibuffer length is great enough, the beginning will be > occluded until user input is received. > > This can be easily demonstrated by running the following code on a fresh > graphical Emacs, and then pressing C-x b to switch buffers: > > (progn > (ido-mode 1) > (setq ido-max-window-height 1) > (dotimes (i 100) > (generate-new-buffer "foobar")) > (make-frame)) > > The bug manifests on both Linux and macOS (vanilla builds). It was not > present on Emacs 28. I ran a git-bisect and the "first bad commit" > appears to be c0b9041ebde82907711cc00a7c307fe622fb541c. If the minibuffer text is longer than what the mini-window can show, then it is not clear whether Emacs should show the beginning or the end of the minibuffer text. So I don't see how this is a bug and why would the alternative behavior be better. Also, if you just type C-b, you will see the rest of the buffer text. If, for some reason, ido-mode wants to always display the beginning of the minibuffer text, it can do that with a change specific to ido-mode. The change to which you point affect general Emacs behavior, it isn't specific to ido-mode. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 28 04:23:27 2023 Received: (at 66773) by debbugs.gnu.org; 28 Oct 2023 08:23:27 +0000 Received: from localhost ([127.0.0.1]:37709 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qwebO-0000TJ-GO for submit@debbugs.gnu.org; Sat, 28 Oct 2023 04:23:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59308) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qwebL-0000T0-Oo for 66773@debbugs.gnu.org; Sat, 28 Oct 2023 04:23:25 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qweak-0006mB-G5; Sat, 28 Oct 2023 04:22:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=x1zHnPCUly/j527KvI2hF4cSI3nyotBXFvw0PU9KbXE=; b=iLJYSjUEhaXc v44L4WPk2q9t8US+b2UPofviSjc8EUCo8nP9/PHWaknw9eY537x6oiVBfRWEBGSYzr4ugZLQicjwN 6iSXraAPQ0tM8aTsvQ5g/QyA5HWI8T1P0M8CBGaYfIjFtAStfwEe/dGOZ/IJ8McsSmk5/Gs6yvTsQ Psgd+dV6dfcfex4sYnGFmmedmtil6QA21qjQZmF6UVDjyVzo12UrNAHi8qwk7M+JbMjemD2j0BAb7 jYOW6ZjICmqJROgB5u2UfuFhPrh6fuy9CBWEvRYc80k5L1hWDjau3XUcu+2qf+9UGFaPKGRfCF8R4 5rzrnXzl0Or9Cx3bsFD83w==; Date: Sat, 28 Oct 2023 11:22:59 +0300 Message-Id: <83ttqbcg0s.fsf@gnu.org> From: Eli Zaretskii To: Spencer Williams In-Reply-To: (message from Spencer Williams on Fri, 27 Oct 2023 18:47:40 -0400) Subject: Re: bug#66773: 29.1; Ido displays incorrectly with multiple frames when ido-max-window-height=1 References: <83leboe3vv.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66773 Cc: 66773@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Williams > Cc: 66773@debbugs.gnu.org > Date: Fri, 27 Oct 2023 18:47:40 -0400 > > > Eli Zaretskii writes: > > > If the minibuffer text is longer than what the mini-window can show, > > then it is not clear whether Emacs should show the beginning or the > > end of the minibuffer text. So I don't see how this is a bug and why > > would the alternative behavior be better. Also, if you just type C-b, > > you will see the rest of the buffer text. > > I consider it a bug due to inconsistent behavior. With multiple > frames, the behavior is different than it is with only one frame. OK, I didn't understand this from your original report, sorry. But in that case, the result of Git bisection is incorrect, since reverting that commit doesn't change the behavior in this recipe, at least on my system. Did you see any change in behavior when you reverted the commit to which "git bisect" pointed? > > If, for some reason, ido-mode wants to always display the beginning of > > the minibuffer text, it can do that with a change specific to > > ido-mode. > > In Ido's case it is certainly incorrect to show the end first, due to > the prompt and selection being at the beginning. My concern is that in > Emacs 28 it had no trouble, and in Emacs 29 it acts erratically. > > > The change to which you point affect general Emacs behavior, it > > isn't specific to ido-mode. > > I understand that. I originally meant for this report to be more > general, as I did believe Emacs's drawing code to be at fault, but in > the end Ido was the only definitive example of wrong behavior I could > reproduce. I included the commit reference on the outside chance it > might save someone some digging (as I'd already put a little work into > finding a solution myself). > > I hope that if it is indeed an Ido-specific bug, this report will still > be of some use. Thanks for your time. The reason for what you see is the new handling of mini-windows introduced in Emacs 28 (not in 29), whereby by default we show the end of the mini-buffer text, not its beginning. It looks to me that when ido-max-window-height is set to 1, the variable redisplay-adhoc-scroll-in-resize-mini-windows should be set to the nil value, which will make the behavior in your recipe consistent, at least in my testing. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 28 07:47:41 2023 Received: (at 66773) by debbugs.gnu.org; 28 Oct 2023 11:47:42 +0000 Received: from localhost ([127.0.0.1]:37871 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qwhn3-0005mF-0u for submit@debbugs.gnu.org; Sat, 28 Oct 2023 07:47:41 -0400 Received: from [23.94.94.179] (port=46656 helo=mail.plexwave.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qwVgS-0007Or-Ag for 66773@debbugs.gnu.org; Fri, 27 Oct 2023 18:52:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plexwave.org; s=mail; t=1698447087; bh=sJ6pvMnQcR8kJP5T3QEJH8juQts4dj1dNC9N9lVX2Aw=; h=References:From:To:Cc:Subject:Date:In-reply-to:From; b=CbUwH/AuBLPtdvv9ItIbRcYHK2yL95CiDs9PQK3Z3J1YLVBz1dKcMF5vpYCzetjI7 dRrNUjYGPBP0vtM3TKBOURMku5AmT5ukX4Y7KCtyvsjgWDFZEDkH277Nk2kHzdDf5c oqUt8588xwUSgx6sU7NuRTFyqEV4QYY0pvjoDT+0UY1f2ztq2vY6mwwGQTDY3fzCYP tFmnncvdmDhNGjj6SilzXTmKxAbAWgckcKa2zZjFLXxHkDPRkMslVrk/RsUWvTWRxK 8Sv+FaI32M6UmAJL1lZaTZR3VxNU9sT4H9fEbaAAIyiOg79t2nqKddXr8KxiF2+OiF KW5p/D+DGbKnA== References: <83leboe3vv.fsf@gnu.org> User-agent: mu4e 1.10.7; emacs 29.1 From: Spencer Williams To: Eli Zaretskii Subject: Re: bug#66773: 29.1; Ido displays incorrectly with multiple frames when ido-max-window-height=1 Date: Fri, 27 Oct 2023 18:47:40 -0400 In-reply-to: <83leboe3vv.fsf@gnu.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: > If the minibuffer text is longer than what the mini-window can show, > then it is not clear whether Emacs should show the beginning or the > end of the minibuffer text. So I don't see how this is a [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-Debbugs-Envelope-To: 66773 X-Mailman-Approved-At: Sat, 28 Oct 2023 07:47:36 -0400 Cc: 66773@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii writes: > If the minibuffer text is longer than what the mini-window can show, > then it is not clear whether Emacs should show the beginning or the > end of the minibuffer text. So I don't see how this is a bug and why > would the alternative behavior be better. Also, if you just type C-b, > you will see the rest of the buffer text. I consider it a bug due to inconsistent behavior. With multiple frames, the behavior is different than it is with only one frame. > If, for some reason, ido-mode wants to always display the beginning of > the minibuffer text, it can do that with a change specific to > ido-mode. In Ido's case it is certainly incorrect to show the end first, due to the prompt and selection being at the beginning. My concern is that in Emacs 28 it had no trouble, and in Emacs 29 it acts erratically. > The change to which you point affect general Emacs behavior, it > isn't specific to ido-mode. I understand that. I originally meant for this report to be more general, as I did believe Emacs's drawing code to be at fault, but in the end Ido was the only definitive example of wrong behavior I could reproduce. I included the commit reference on the outside chance it might save someone some digging (as I'd already put a little work into finding a solution myself). I hope that if it is indeed an Ido-specific bug, this report will still be of some use. Thanks for your time. From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 29 04:01:56 2023 Received: (at 66773) by debbugs.gnu.org; 29 Oct 2023 08:01:56 +0000 Received: from localhost ([127.0.0.1]:40289 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qx0k5-0007Y2-If for submit@debbugs.gnu.org; Sun, 29 Oct 2023 04:01:56 -0400 Received: from [23.94.94.179] (port=52474 helo=mail.plexwave.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qwszi-0002Fh-4w for 66773@debbugs.gnu.org; Sat, 28 Oct 2023 19:45:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plexwave.org; s=mail; t=1698536692; bh=0rRNUf5CYyvwVBOhEdlbdd61rbH3rNzhdtPZJ+UEmZg=; h=References:From:To:Cc:Subject:Date:In-reply-to:From; b=Hh8nJZh0vwURtEDw94aJny2LK4PkNU0JHsxQz84KAWe3y6qhG3J8WeImy1bxWIBL8 /xnUCKiIqAzCQoB6e0n5Iq3VGNteKYrKtbhdDcUh3PyLiAi6tpPNkDUuc4dzjUDryR geg+DWOMdMxqXzm9uuUELc4Cv/trj8EyFN33cnMPDNeJIfWK6Mj7H49cbqnFYzDjKy Ep52Dx9EIQ5sH/3UPCOx/jNdHnM6tnubRWKoSiW3c45Pb6myBDOQ6MvM05b42B0+Oy zpXzhVbSVmod640kNk3odnkUwazwZhKpHmW3eTySdAw8lrUdc/21YUd7FsX1Qq9/F9 joZWF2Id0MC1Q== References: <83leboe3vv.fsf@gnu.org> <83ttqbcg0s.fsf@gnu.org> User-agent: mu4e 1.10.7; emacs 29.1 From: Spencer Williams To: Eli Zaretskii Subject: Re: bug#66773: 29.1; Ido displays incorrectly with multiple frames when ido-max-window-height=1 Date: Sat, 28 Oct 2023 19:41:45 -0400 In-reply-to: <83ttqbcg0s.fsf@gnu.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: > But in that case, the result of Git bisection is incorrect, since > reverting that commit doesn't change the behavior in this recipe, at > least on my system. Did you see any change in behavior when [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-Debbugs-Envelope-To: 66773 X-Mailman-Approved-At: Sun, 29 Oct 2023 04:01:51 -0400 Cc: 66773@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii writes: > But in that case, the result of Git bisection is incorrect, since > reverting that commit doesn't change the behavior in this recipe, at > least on my system. Did you see any change in behavior when you > reverted the commit to which "git bisect" pointed? There is no change when reverting it against Emacs 29 or master. I apologize for not mentioning this before. There is a change, however, when reverting against the commit's immediate parent; so, coincidentally or otherwise, the commit does manifest the behavior I've demonstrated. I cannot speak to the ramifications for the rest of the codebase (I understand much has likely changed in the two years since that commit was made). > The reason for what you see is the new handling of mini-windows > introduced in Emacs 28 (not in 29), whereby by default we show the end > of the mini-buffer text, not its beginning. That is certainly interesting, as I can affirm this behavior was not present in any version of Emacs 28 I've tested (up to emacs-28.3-rc1). > It looks to me that when ido-max-window-height is set to 1, the > variable redisplay-adhoc-scroll-in-resize-mini-windows should be set > to the nil value, which will make the behavior in your recipe > consistent, at least in my testing. It does, and I thank you much for turning me onto that, as it at least provides a usable fix for now. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 18 03:35:04 2023 Received: (at 66773-done) by debbugs.gnu.org; 18 Nov 2023 08:35:04 +0000 Received: from localhost ([127.0.0.1]:47750 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4Gn8-0006J3-TU for submit@debbugs.gnu.org; Sat, 18 Nov 2023 03:35:04 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:34722) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4Gn6-0006IQ-0q for 66773-done@debbugs.gnu.org; Sat, 18 Nov 2023 03:35:01 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r4Gmz-0004z8-TK; Sat, 18 Nov 2023 03:34:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=60vVjJAlEEv/G2hVrwR6Fc+oNmuE34GQnGVcH95cNhw=; b=J8gVtpKU6uTy n2mbXzAQI1Ws+rBgsDvcgKh98XCq7VUsDDqLEQYwxAdZrnEP4COpVAvD4rF608Up2r4CjztBB2go4 duxQpm3/vhgyRwSSrNLffba7EDj6sxrpUCxFzSJRMOwseM9NtW2we/Uk8AqH7HVWzFBoiAFvh5Tq+ QZ0m9StCtBYldPc58Ex/rU6U4y3bY0srP+dz3inQ8N1s6Uar/1a7zT52PwYs6zrm9+2+MoQMJTIw2 w39h4FB6T+0681s/2U9jrUkuzAGn3hZ/cRDEeU99JHLS3cGbDaUfwBSAJ8eZwytbRpCBmuBuZcP1X 6QBJ5EmoUATP4DdQ92gRbA==; Date: Sat, 18 Nov 2023 10:34:50 +0200 Message-Id: <838r6vo3x1.fsf@gnu.org> From: Eli Zaretskii To: Spencer Williams In-Reply-To: (message from Spencer Williams on Sat, 28 Oct 2023 19:41:45 -0400) Subject: Re: bug#66773: 29.1; Ido displays incorrectly with multiple frames when ido-max-window-height=1 References: <83leboe3vv.fsf@gnu.org> <83ttqbcg0s.fsf@gnu.org> X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 66773-done Cc: 66773-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Williams > Cc: 66773@debbugs.gnu.org > Date: Sat, 28 Oct 2023 19:41:45 -0400 > > > Eli Zaretskii writes: > > > It looks to me that when ido-max-window-height is set to 1, the > > variable redisplay-adhoc-scroll-in-resize-mini-windows should be set > > to the nil value, which will make the behavior in your recipe > > consistent, at least in my testing. > > It does, and I thank you much for turning me onto that, as it at least > provides a usable fix for now. No more comments, so I'm now closing the bug as done. From unknown Fri Aug 15 04:03:38 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 16 Dec 2023 12:24:08 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator