bug#38457: 27.0.50; dabbrev-expand regression due to message change

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 38457@debbugs.gnu.org
> Date: Tue, 17 Dec 2019 00:29:32 +0200
> 
> > However, I hoped we could have at least part of what you did in Emacs
> > 27, and not lose all of it.  We could install a function like
> > 'minimess-minibuffer-message', and make one of the subroutines of
> > 'message' call it under the right conditions.
> 
> The most low-level functions where it could be called from
> are 'set_message' and 'clear_message'.

I had in mind set_message_1 rather than set_message, but the
difference is not critical for this discussion.

> > Then the message which
> > 'minimess-minibuffer-message' displays could be removed by a timer if
> > the new timeout defcustom is a number, and if that defcustom is not a
> > number (which will be the default), the message stays and sit-for is
> > not called.
> 
> This is almost how 'minimess-minibuffer-message' was implemented,
> with one difference: defcustom is a number by default.
> Why shouldn't it be a number by default?

By making the default not a number, we keep the previous behavior of
'message' in this aspect, thus minimizing potential unintended
consequences.  At the same time, we gain another aspect: we avoid
hiding the minibuffer prompt.  So this will be a partial improvement
wrt the current behavior, with an option for users who would like that
to customize the value to a number, and thus get the message removed
automatically after some delay.

> How the user would be able to remove an old message when the
> function doesn't call sit-for?

Like they do today: type something.  And in some situations, not even
that, if the Lisp program which displayed the message will shortly
follow up with clearing the echo area (that's what happens with
dabbrev, for example).

> > Do you see any danger with the above?  If not, can I persuade you do
> > install such a change?
> 
> I'm not sure if now is the right time to implement this feature.
> But if implementation would be straightforward and if you see no problems
> then why not.

The implementation looks straightforward to me, since you already
implemented almost all of it in that ELPA package.  What's left is
minor details.

> >>   (if (and
> >>        ;; When `inhibit-message' is non-nil, the intention was to just
> >>        ;; log the message to the *Messages* buffer using `message'.
> >>        (null inhibit-message)
> >>        (window-live-p (active-minibuffer-window))
> >>        (window-live-p (old-selected-window))
> >>        (bufferp (window-buffer (old-selected-window)))
> >>        (minibufferp (window-buffer (old-selected-window))))
> >
> > Btw, can you explain why every part of this condition is needed?  IOW,
> > why isn't just the below enough?
> >
> >    (window-live-p (active-minibuffer-window))
> >
> > (I do understand the reason for the test of inhibit-message).
> >
> > Maybe the other conditions need a comment to explain them?
> 
> Unfortunately, I forgot why they were added, i.e. during testing
> I added them one by one when noticed that some cases don't work.
> Now I'll try to reproduce these cases by removing conditions
> and checking which part doesn't work.

Thank you.