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

Previous Next

Full log

View this message in rfc822 format

From: Gregory Heytings <ghe <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 43519 <at> debbugs.gnu.org
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Date: Mon, 21 Sep 2020 06:50:22 +0000

>
> 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?
>

After further testing, doing this is not enough, because it is necessary 
to update height even when start_display_at_beginning_of_minibuffer.  So 
the code should be:

if (height > max_height && !EQ (Vstart_display_at_beginning_of_minibuffer, Qt))
{
  ...
}
else
{
  if (height > max_height) height = (max_height / unit) * unit;
  SET_TEXT_POS (start, BEGV, BEGV_BYTE);
}

Another note to answer Eli's previous questions:

>
>  . Define in more detail what situations we would like to fix in the
>    display code, so that we could install special ad-hoc changes
>    there to handle those situations.  For example: is it true that in
>    all of these situations starting the mini-window display at BOB
>    would DTRT?  If so, I think this could be arranged.  If not, why
>    not, and what is the more correct definition of the situations we
>    want to handle?
>

It is "true that in all of these situations starting the mini-window 
display at BOB would DTRT", but it is also true that in all of these 
situations the height overflow is due to an overlay at EOB.  So another 
solution, which I think would be even better, but might change the 
existing behavior marginally, would be to calculate the height two times, 
once at EOB and once at EOB-1.  With this Emacs would detect by itself the 
situations in which it is better to show the first max-mini-window-height 
lines instead of the last max-mini-window-height lines, and it would not 
be necessary to explicitly set a variable in minibuffer-setup-hook.  The 
code would be:

if (it.line_wrap == TRUNCATE)
  height_near_eob = height = unit;
else
{
  last_height = 0;
  move_it_to (&it, ZV - 1, -1, -1, -1, MOVE_TO_POS);
  if (it.max_ascent == 0 && it.max_descent == 0)
    height_near_eob = it.current_y + last_height;
  else
    height_near_eob = it.current_y + it.max_ascent + it.max_descent;
  height_near_eob -= min (it.extra_line_spacing, it.max_extra_line_spacing);
  move_it_to (&it, ZV, -1, -1, -1, MOVE_TO_POS);
  ...
}

if (height > max_height && height_near_eob > max_height)
{
  ...
}
else
{
  if (height > max_height) height = (max_height / unit) * unit;
  SET_TEXT_POS (start, BEGV, BEGV_BYTE);
}

Previous Next

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