GNU bug report logs - #39564
28.0.50; read-key function do not display the prompt if called from read-from-minibuffer

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Matt Kramer <mccleetus <at> gmail.com>
Cc: 39564 <at> debbugs.gnu.org
Subject: bug#39564: 
Date: Mon, 02 Mar 2020 10:46:50 +0200

> From: Matt Kramer <mccleetus <at> gmail.com>
> Date: Sun, 1 Mar 2020 23:20:23 -0800
> Cc: 39564 <at> debbugs.gnu.org
> 
> Followup: The regression in Ivy appears to be fixed when
> set-message-function is bound to nil at the top of the misbehaving
> function.

That is indeed the simplest solution, but it is not the best one.  It
would be better for Ivy to provide its own set-message-function which
plays by the new Emacs 27 rules, i.e. presents the message text in a
way that doesn't completely obscure the original prompt.

> In general, it seems like, given the new defaults defined in
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=485b423e8f0df2711a850be7f254665f64ab0bdb,
> it will be necessary to make a similar change to any existing function
> that, say, calls read-key under the assumption that the prompt will
> take over the mini-window. (At least when the prompt contains multiple
> lines). I guess that's the fundamental issue here. The new behavior
> may be a nice improvement, but it's unclear how much code there is out
> there that relies on the old behavior.

Relying on the old behavior was always not a future-proof assumption,
so I see no way around the problem except fixing the code which makes
such assumptions, sorry.

Previous Next

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