GNU bug report logs - #48669
Inconsistent overlay placement between minibuffer-message and set-minibuffer-message

Previous Next

Package: emacs;

Reported by: João Guerra <joca.bt <at> gmail.com>

Date: Wed, 26 May 2021 12:52:02 UTC

Severity: normal

Tags: fixed, patch

Fixed in version 28.0.50

Done: Juri Linkov <juri <at> linkov.net>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 48669 in the body.
You can then email your comments to 48669 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#48669; Package emacs. (Wed, 26 May 2021 12:52:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to João Guerra <joca.bt <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 26 May 2021 12:52:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: João Guerra <joca.bt <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Inconsistent overlay placement between minibuffer-message and
 set-minibuffer-message
Date: Wed, 26 May 2021 14:50:20 +0200
[Message part 1 (text/plain, inline)]
`minibuffer-message' and `set-minibuffer-message' place the overlay
containing the message slightly differently, resulting in a different
behaviour when there are other overlays present at the end of the
minibuffer.

The overlay created by `minibuffer-message' always gets added to the
end of the minibuffer.
The overlay created by `set-minibuffer-message' also gets added to the
end of the minibuffer, but its properties make it so that it is shown
before other overlays at the position.
This is particularly important when the user uses packages that add
overlays to the minibuffer, such as vertical completion packages like
selectrum, vertico, and others.
The way `set-minibuffer-message' configures the overlays makes it so
that the overlay is displayed before the other overlays, which I
believe is more compatible with external packages (see attached image
for a visual example).

Would it make sense to change this behaviour (i.e. overlay
configuration) so that it is consistent in both functions?
[image.png (image/png, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48669; Package emacs. (Mon, 31 May 2021 20:32:03 GMT) Full text and rfc822 format available.

Message #8 received at 48669 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: João Guerra <joca.bt <at> gmail.com>
Cc: 48669 <at> debbugs.gnu.org
Subject: Re: bug#48669: Inconsistent overlay placement between
 minibuffer-message and set-minibuffer-message
Date: Mon, 31 May 2021 23:24:14 +0300
> `minibuffer-message' and `set-minibuffer-message' place the overlay
> containing the message slightly differently, resulting in a different
> behaviour when there are other overlays present at the end of the
> minibuffer.
>
> The overlay created by `minibuffer-message' always gets added to the
> end of the minibuffer.
> The overlay created by `set-minibuffer-message' also gets added to the
> end of the minibuffer, but its properties make it so that it is shown
> before other overlays at the position.
> This is particularly important when the user uses packages that add
> overlays to the minibuffer, such as vertical completion packages like
> selectrum, vertico, and others.
> The way `set-minibuffer-message' configures the overlays makes it so
> that the overlay is displayed before the other overlays, which I
> believe is more compatible with external packages (see attached image
> for a visual example).

To support completion packages such as icomplete, the overlay in
`set-minibuffer-message' was fixed, but not `minibuffer-message'.

> Would it make sense to change this behaviour (i.e. overlay
> configuration) so that it is consistent in both functions?

Right, `minibuffer-message' should be consistent with `set-minibuffer-message'
by copying this part:

        ;; Make sure the overlay with the message is displayed before
        ;; any other overlays in that position, in case they have
        ;; resize-mini-windows set to nil and the other overlay strings
        ;; are too long for the mini-window width.  This makes sure the
        ;; temporary message will always be visible.
        (overlay-put minibuffer-message-overlay 'priority 1100)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48669; Package emacs. (Sat, 05 Jun 2021 22:29:01 GMT) Full text and rfc822 format available.

Message #11 received at 48669 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: João Guerra <joca.bt <at> gmail.com>
Cc: 48669 <at> debbugs.gnu.org
Subject: Re: bug#48669: Inconsistent overlay placement between
 minibuffer-message and set-minibuffer-message
Date: Sun, 06 Jun 2021 00:43:54 +0300
[Message part 1 (text/plain, inline)]
> Would it make sense to change this behaviour (i.e. overlay
> configuration) so that it is consistent in both functions?

Thanks for the very useful suggestion.  This could be fixed
with the following patch where I tried to sync everything
overlay-related from set-minibuffer-message to minibuffer-message:

[minibuffer-message-overlay.patch (text/x-diff, inline)]
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index ffb74235e8..cb12226c07 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -741,7 +741,8 @@ minibuffer-message
                 ;; Don't overwrite the face properties the caller has set
                 (text-properties-at 0 message))
       (setq message (apply #'propertize message minibuffer-message-properties)))
-    (let ((ol (make-overlay (point-max) (point-max) nil t t))
+    (let* ((ovpos (minibuffer--message-overlay-pos))
+           (ol (make-overlay ovpos ovpos nil t t))
           ;; A quit during sit-for normally only interrupts the sit-for,
           ;; but since minibuffer-message is used at the end of a command,
           ;; at a time when the command has virtually finished already, a C-g
@@ -755,8 +756,14 @@ minibuffer-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
               ;; before or after the string, so let's spoon-feed it the pos.
-              (put-text-property 0 1 'cursor t message))
+              (put-text-property 0 1 'cursor 1 message))
             (overlay-put ol 'after-string message)
+            ;; Make sure the overlay with the message is displayed before
+            ;; any other overlays in that position, in case they have
+            ;; resize-mini-windows set to nil and the other overlay strings
+            ;; are too long for the mini-window width.  This makes sure the
+            ;; temporary message will always be visible.
+            (overlay-put ol 'priority 1100)
             (sit-for (or minibuffer-message-timeout 1000000)))
         (delete-overlay ol)))))
 

Added tag(s) patch. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sat, 05 Jun 2021 22:31:01 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48669; Package emacs. (Sun, 06 Jun 2021 05:59:02 GMT) Full text and rfc822 format available.

Message #16 received at 48669 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: joca.bt <at> gmail.com, 48669 <at> debbugs.gnu.org
Subject: Re: bug#48669: Inconsistent overlay placement between
 minibuffer-message and set-minibuffer-message
Date: Sun, 06 Jun 2021 08:58:27 +0300
> From: Juri Linkov <juri <at> linkov.net>
> Date: Sun, 06 Jun 2021 00:43:54 +0300
> Cc: 48669 <at> debbugs.gnu.org
> 
> 
> [1:text/plain Hide]
> 
> > Would it make sense to change this behaviour (i.e. overlay
> > configuration) so that it is consistent in both functions?
> 
> Thanks for the very useful suggestion.  This could be fixed
> with the following patch where I tried to sync everything
> overlay-related from set-minibuffer-message to minibuffer-message:
> 
> 
> [2:text/x-diff Hide]
> 
> diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
> index ffb74235e8..cb12226c07 100644
> --- a/lisp/minibuffer.el
> +++ b/lisp/minibuffer.el
> @@ -741,7 +741,8 @@ minibuffer-message
>                  ;; Don't overwrite the face properties the caller has set
>                  (text-properties-at 0 message))
>        (setq message (apply #'propertize message minibuffer-message-properties)))
> -    (let ((ol (make-overlay (point-max) (point-max) nil t t))
> +    (let* ((ovpos (minibuffer--message-overlay-pos))
> +           (ol (make-overlay ovpos ovpos nil t t))

Doesn't this rely too much on the internal details of
minibuffer--message-overlay-pos?  At least, without any comments, this
call looks like a riddle that isn't easy to unlock.

> -              (put-text-property 0 1 'cursor t message))
> +              (put-text-property 0 1 'cursor 1 message))

Why this change?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48669; Package emacs. (Sun, 06 Jun 2021 21:16:02 GMT) Full text and rfc822 format available.

Message #19 received at 48669 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: joca.bt <at> gmail.com, 48669 <at> debbugs.gnu.org
Subject: Re: bug#48669: Inconsistent overlay placement between
 minibuffer-message and set-minibuffer-message
Date: Sun, 06 Jun 2021 23:54:58 +0300
>> @@ -741,7 +741,8 @@ minibuffer-message
>>                  ;; Don't overwrite the face properties the caller has set
>>                  (text-properties-at 0 message))
>>        (setq message (apply #'propertize message minibuffer-message-properties)))
>> -    (let ((ol (make-overlay (point-max) (point-max) nil t t))
>> +    (let* ((ovpos (minibuffer--message-overlay-pos))
>> +           (ol (make-overlay ovpos ovpos nil t t))
>
> Doesn't this rely too much on the internal details of
> minibuffer--message-overlay-pos?  At least, without any comments, this
> call looks like a riddle that isn't easy to unlock.

If minibuffer--message-overlay-pos serves its purpose for
set-minibuffer-message, it seems suitable for
minibuffer-message as well.

>> -              (put-text-property 0 1 'cursor t message))
>> +              (put-text-property 0 1 'cursor 1 message))
>
> Why this change?

Only to make minibuffer-message the identical copy of
set-minibuffer-message.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48669; Package emacs. (Tue, 08 Jun 2021 00:06:03 GMT) Full text and rfc822 format available.

Message #22 received at 48669 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: joca.bt <at> gmail.com, 48669 <at> debbugs.gnu.org
Subject: Re: bug#48669: Inconsistent overlay placement between
 minibuffer-message and set-minibuffer-message
Date: Mon, 07 Jun 2021 15:21:04 +0300
> From: Juri Linkov <juri <at> linkov.net>
> Cc: joca.bt <at> gmail.com,  48669 <at> debbugs.gnu.org
> Date: Sun, 06 Jun 2021 23:54:58 +0300
> 
> >> -    (let ((ol (make-overlay (point-max) (point-max) nil t t))
> >> +    (let* ((ovpos (minibuffer--message-overlay-pos))
> >> +           (ol (make-overlay ovpos ovpos nil t t))
> >
> > Doesn't this rely too much on the internal details of
> > minibuffer--message-overlay-pos?  At least, without any comments, this
> > call looks like a riddle that isn't easy to unlock.
> 
> If minibuffer--message-overlay-pos serves its purpose for
> set-minibuffer-message, it seems suitable for
> minibuffer-message as well.

So you object to adding a comment there which would explain what that
call does?

> >> -              (put-text-property 0 1 'cursor t message))
> >> +              (put-text-property 0 1 'cursor 1 message))
> >
> > Why this change?
> 
> Only to make minibuffer-message the identical copy of
> set-minibuffer-message.

I'd say make it the other way around.  Handling the 'cursor' property
with a numeric value is more expensive and tricky than if the value is
t, and in this case the effect is exactly the same.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48669; Package emacs. (Tue, 08 Jun 2021 16:57:02 GMT) Full text and rfc822 format available.

Message #25 received at 48669 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: joca.bt <at> gmail.com, 48669 <at> debbugs.gnu.org
Subject: Re: bug#48669: Inconsistent overlay placement between
 minibuffer-message and set-minibuffer-message
Date: Tue, 08 Jun 2021 19:52:07 +0300
tags 48669 fixed
close 48669 28.0.50
thanks

>> >> -    (let ((ol (make-overlay (point-max) (point-max) nil t t))
>> >> +    (let* ((ovpos (minibuffer--message-overlay-pos))
>> >> +           (ol (make-overlay ovpos ovpos nil t t))
>> >
>> > Doesn't this rely too much on the internal details of
>> > minibuffer--message-overlay-pos?  At least, without any comments, this
>> > call looks like a riddle that isn't easy to unlock.
>> 
>> If minibuffer--message-overlay-pos serves its purpose for
>> set-minibuffer-message, it seems suitable for
>> minibuffer-message as well.
>
> So you object to adding a comment there which would explain what that
> call does?

Now I added a comment, and pushed to master.

>> >> -              (put-text-property 0 1 'cursor t message))
>> >> +              (put-text-property 0 1 'cursor 1 message))
>> >
>> > Why this change?
>> 
>> Only to make minibuffer-message the identical copy of
>> set-minibuffer-message.
>
> I'd say make it the other way around.  Handling the 'cursor' property
> with a numeric value is more expensive and tricky than if the value is
> t, and in this case the effect is exactly the same.

So I changed the 'cursor' property to t.




Added tag(s) fixed. Request was from Juri Linkov <juri <at> linkov.net> to control <at> debbugs.gnu.org. (Tue, 08 Jun 2021 16:57:03 GMT) Full text and rfc822 format available.

bug marked as fixed in version 28.0.50, send any further explanations to 48669 <at> debbugs.gnu.org and João Guerra <joca.bt <at> gmail.com> Request was from Juri Linkov <juri <at> linkov.net> to control <at> debbugs.gnu.org. (Tue, 08 Jun 2021 16:57:03 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48669; Package emacs. (Tue, 08 Jun 2021 18:13:01 GMT) Full text and rfc822 format available.

Message #32 received at 48669 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: joca.bt <at> gmail.com, 48669 <at> debbugs.gnu.org
Subject: Re: bug#48669: Inconsistent overlay placement between
 minibuffer-message and set-minibuffer-message
Date: Tue, 08 Jun 2021 21:12:10 +0300
> From: Juri Linkov <juri <at> linkov.net>
> Cc: joca.bt <at> gmail.com,  48669 <at> debbugs.gnu.org
> Date: Tue, 08 Jun 2021 19:52:07 +0300
> 
> >> If minibuffer--message-overlay-pos serves its purpose for
> >> set-minibuffer-message, it seems suitable for
> >> minibuffer-message as well.
> >
> > So you object to adding a comment there which would explain what that
> > call does?
> 
> Now I added a comment, and pushed to master.
> 
> >> >> -              (put-text-property 0 1 'cursor t message))
> >> >> +              (put-text-property 0 1 'cursor 1 message))
> >> >
> >> > Why this change?
> >> 
> >> Only to make minibuffer-message the identical copy of
> >> set-minibuffer-message.
> >
> > I'd say make it the other way around.  Handling the 'cursor' property
> > with a numeric value is more expensive and tricky than if the value is
> > t, and in this case the effect is exactly the same.
> 
> So I changed the 'cursor' property to t.

Thank you.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 07 Jul 2021 11:24:07 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 265 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.