bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#38457: 27.0.50; dabbrev-expand regression due to message change
Date: Fri, 13 Dec 2019 10:57:59 +0200

> From: Juri Linkov <juri@linkov.net>
> Cc: 38457@debbugs.gnu.org
> Date: Fri, 13 Dec 2019 01:12:50 +0200
> 
> >> If you want to set message-in-echo-area to t in the release branch,
> >> that's fine.
> >
> > That would mean bring back all the problems for which these changes
> > were made.  So it would be the worst of all worlds, and thus makes
> > very little sense to me.
> 
> Then your proposed implementation should be activated when
> minibuffer-message-timeout is set to a non-nil value.
> Otherwise, when it's a number, it should use the timer.

That leaves open the issue of the default value of
minibuffer-message-timeout.  I don't think we can change it, because
it affects minibuffer-message as well.  But we could have a new
option, which would affect only the duplicate function you mention
below.  If the new option by default makes the message stay until the
next one or until user input, I think this would be an okay solution
that satisfies everyone, at least for Emacs 27.

> > And in any case, minibuffer-message already behaves differently: it
> > logs the message in *Messages*, something it never did and is not
> > documented, and you suggested another change, to make it start the
> > debugger per debug-on-message.  These change behavior of any direct
> > callers of minibuffer-message in incompatible ways, something I don't
> > think we have a good reason to do.
> 
> I see no reason not to change minibuffer-message.  But if you think
> it should never change, let's create a duplicate function
> message-in-minibuffer.

Fine with me, as long as the duplicate is an internal function.  Maybe
that new internal function should be invoked from message3_nolog
instead, btw?  That would remove the need to duplicate the
functionality of message_dolog.

Assuming you agree, once this change is made, some of the recent
changes related to these issues should be reverted.  Can I ask you to
review those related changesets and publish a list of those which need
to be reverted or augmented?

Thanks.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]