From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#39379: 27.0.60; Fix for #38457 broke ido-vertical-mode Date: Mon, 10 Feb 2020 17:44:08 +0200 Message-ID: <83zhdqbg6v.fsf@gnu.org> References: <83a762k9p2.fsf@gnu.org> <71c2898c-aca7-ea92-e7d2-f4fd122b566d@gmail.com> <83ftfthsqs.fsf@gnu.org> <83d0awj42l.fsf@gnu.org> <83a760j23r.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="70716"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 39379@debbugs.gnu.org, wyuenho@gmail.com To: dgutov@yandex.ru Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Feb 10 16:45:13 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 1j1BFI-000IEb-NT for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 10 Feb 2020 16:45:12 +0100 Original-Received: from localhost ([::1]:35300 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j1BFH-0003DJ-Bw for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 10 Feb 2020 10:45:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41267) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j1BFA-0003DC-5C for bug-gnu-emacs@gnu.org; Mon, 10 Feb 2020 10:45:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j1BF8-0002OS-RD for bug-gnu-emacs@gnu.org; Mon, 10 Feb 2020 10:45:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49283) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j1BF8-0002NS-N3 for bug-gnu-emacs@gnu.org; Mon, 10 Feb 2020 10:45:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j1BF8-0000Rp-JG for bug-gnu-emacs@gnu.org; Mon, 10 Feb 2020 10:45:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 10 Feb 2020 15:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39379 X-GNU-PR-Package: emacs Original-Received: via spool by 39379-submit@debbugs.gnu.org id=B39379.15813494691665 (code B ref 39379); Mon, 10 Feb 2020 15:45:02 +0000 Original-Received: (at 39379) by debbugs.gnu.org; 10 Feb 2020 15:44:29 +0000 Original-Received: from localhost ([127.0.0.1]:55256 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j1BEb-0000Qn-Bd for submit@debbugs.gnu.org; Mon, 10 Feb 2020 10:44:29 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:54264) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j1BEZ-0000Qb-C5 for 39379@debbugs.gnu.org; Mon, 10 Feb 2020 10:44:27 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49131) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1j1BEU-00024I-1e; Mon, 10 Feb 2020 10:44:22 -0500 Original-Received: from [176.228.60.248] (port=2169 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1j1BET-0008LC-9V; Mon, 10 Feb 2020 10:44:21 -0500 In-reply-to: <83a760j23r.fsf@gnu.org> (message from Eli Zaretskii on Sun, 02 Feb 2020 20:06:16 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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:175877 Archived-At: > Date: Sun, 02 Feb 2020 20:06:16 +0200 > From: Eli Zaretskii > Cc: 39379@debbugs.gnu.org, dgutov@yandex.ru > > > Date: Sun, 02 Feb 2020 19:23:46 +0200 > > From: Eli Zaretskii > > Cc: 39379@debbugs.gnu.org, dgutov@yandex.ru > > > > I think this could be a bug in the display engine, related to resizing > > the mini-window when an after-string that includes many newlines is > > put at EOB. Let me look into it. > > Looks like my guess was correct. I'll try to devise a solution. Sorry for a relatively long delay. In my defense, I first tried a couple of easy solutions, but they didn't work. And that got me thinking, since my experience with solving issues like this due to overlay strings is that the solutions tend to be less than elegant, and take several attempts to get them right. So now, after thinking about this for some time, I think I want to change my mind and ask why do we need to use an overlay with after-string in ido.el? Re-reading related discussions, it seems the answer is "so that the temporary display of messages is not at the end of the minibuffer, where it could be invisible due to resize-mini-windows being nil or restrictions imposed by ido.el via ido-max-window-height". Is that the correct conclusion? If so, then I think we can solve that problem without overlays. See the proposed patch below, which basically reverts ido.el to its previous shape, and uses a special text property to instruct set-minibuffer-message where to put the overlay (defaulting to EOB). WDYT? diff --git a/lisp/ido.el b/lisp/ido.el index 6707d81407..edc848f52f 100644 --- a/lisp/ido.el +++ b/lisp/ido.el @@ -4728,16 +4728,10 @@ ido-exhibit (let ((inf (ido-completions contents))) (setq ido-show-confirm-message nil) (ido-trace "inf" inf) - (when ido--overlay - (delete-overlay ido--overlay)) - (let ((o (make-overlay (point-max) (point-max) nil t t))) - (when (> (length inf) 0) - ;; For hacks that redefine ido-completions function (bug#39379) - (when (eq (aref inf 0) ?\n) - (setq inf (concat " " inf))) - (put-text-property 0 1 'cursor t inf)) - (overlay-put o 'after-string inf) - (setq ido--overlay o))) + (let ((pos (point))) + (insert inf) + (put-text-property pos (1+ pos) 'minibuffer-message t)) + ) )))) (defun ido-completions (name) diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index 0589211877..767fc8dff8 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -763,6 +763,16 @@ minibuffer-message-clear-timeout (defvar minibuffer-message-timer nil) (defvar minibuffer-message-overlay nil) +(defun minibuffer--message-overlay-pos () + "Return position where `set-minibuffer-message' shall put message overlay." + ;; Starting from point, look for non-nil 'minibuffer-message' + ;; property, and return its position. If none found, return the EOB + ;; position. + (let* ((pt (point)) + (propval (get-text-property pt 'minibuffer-message))) + (if propval pt + (next-single-property-change pt 'minibuffer-message nil (point-max))))) + (defun set-minibuffer-message (message) "Temporarily display MESSAGE at the end of the minibuffer. The text is displayed for `minibuffer-message-clear-timeout' seconds @@ -784,8 +794,9 @@ set-minibuffer-message (clear-minibuffer-message) - (setq minibuffer-message-overlay - (make-overlay (point-max) (point-max) nil t t)) + (let ((ovpos (minibuffer--message-overlay-pos))) + (setq minibuffer-message-overlay + (make-overlay ovpos ovpos nil t t))) (unless (zerop (length message)) ;; The current C cursor code doesn't know to use the overlay's ;; marker's stickiness to figure out whether to place the cursor