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

Previous Next

Full log

View this message in rfc822 format

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: 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.

Previous Next

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