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: Stefan Monnier
Subject: bug#38457: 27.0.50; dabbrev-expand regression due to message change
Date: Tue, 10 Dec 2019 12:08:14 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

> The original problem was, AFAIU, that various minibuffer prompts
> become obscured by echo-area display of messages.  So one possible
> solution is to modify the subroutines of 'message', e.g.,
> set_message_1, to detect the conditions of the minibuffer being
> active, and insert the contents of the minibuffer into the echo-area
> buffer before the message text.

Ha!  Clever!

> Does anyone see problems with this?

[ I presume that additionally from inserting the minibuffer's contents
  we'd add some delimiters to clearly separate the message from the
  minibuffer's contents.  ]

I guess there could be some visible artifacts of this subterfuge in the
case where the minibuffer's content is currently affected by overlays
(since we presumably wouldn't copy those to the echo-area), but I'm not
sure this would be a real problem.

One such case of overlays is when icomplete-mode is enabled, and it
would simply temporarily hide the completion-list displayed by
icomplete-mode, which seems quite harmless or maybe even beneficial.

Another issue could be when the minibuffer is large, in which case we'll
want to try and preserve the window-start but also we'll want to make
sure the new message is visible.

BTW, we should probably think about replacing `message` with something
that lets the caller give more information about the intended behavior
(e.g. to also solve the issue of several successive calls to message
resulting in the user only seeing the last message).  Of course, this
would be for Emacs-28.


        Stefan






reply via email to

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