GNU bug report logs - #43519
28.0.50; Overlay at end of minibuf hides minibuf's real content

Previous Next

Full log

Message #194 received at 43519 <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <ghe <at> sdf.org>
To: 43519 <at> debbugs.gnu.org
Subject: Re: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's
 real content
Date: Sun, 20 Sep 2020 19:50:33 +0000

After some further analysis, the problem here is in resize_mini_window().

In the comments one finds:

"Set W->start to the right place to begin display.  If the whole contents 
fit, start at the beginning.  Otherwise, start so as to make the end of 
the contents appear.  This is particularly important for y-or-n-p, but 
seems desirable generally."

I won't judge the "seems desirable generally", but in this case at least 
it is clearly not desirable, so there should be a way to do something 
else.

More precisely, in this case height > max_height, so

init_iterator (&it, w, ZV, ZV_BYTE, NULL, DEFAULT_FACE_ID);

is called, followed by

move_it_vertically_backward (&it, height - unit);

which does nothing given that height == unit, so start is set to ZV.

What I would suggest is to add a user option to set start to BEGV when 
height > max_height, which is what is needed here.  It would be reset to 
nil in read_minibuf() before calling minibuffer-setup-hook, and would be 
used in resize_mini_window() as follows:

/* Compute a suitable window start.  */
if (height > max_height && !EQ (Vstart_display_at_beginning_of_minibuffer, Qt))

This would not break any existing behavior.  Would this be a good way to 
solve that problem?

Previous Next

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