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

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

bug#38828: 26.3; Customized mode line breaks height of vertical scroll b


From: martin rudalics
Subject: bug#38828: 26.3; Customized mode line breaks height of vertical scroll bar
Date: Thu, 2 Jan 2020 20:19:05 +0100

>> window.c doesn't use it.  It's used in xdisp.c only.  And I'm sure it
>> can return negative values, sometimes.  So I presume we can do away
>> with it then?
>
> I think we could.  But I'd rather not do that on the emacs-27 branch,
> not unless we find situations where it actually causes bugs.

Agreed.  I'd be more interested anyway in (1) getting the

ml_row && ml_row->mode_line_p

check into CURRENT_MODE_LINE_HEIGHT (if that makes sense) so we could
use CURRENT_MODE_LINE_HEIGHT everywhere (maybe without its embedded
assignment) and (2) improve and (remove from there) the

&& WINDOW_PIXEL_HEIGHT (w) > WINDOW_FRAME_LINE_HEIGHT (w));

check from window_wants_mode_line to use the latest calculated mode
line height instead.  I'd like to reserve one bit for each window's
scroll bars, margins, fringes, mode lines whether they would fit into
the window and suppress their display if they don't.  This would mean
that one can easily shrink a window to some bare minimum, maybe even
to zero height/width.

> There's more than one problem here (didn't you wonder why pressing F3
> doesn't immediately redraw the mode line?).

It never did that unless I changed the size of some window too, so why
should I have wondered?

> A more thorough patch is
> below.

It's a pleasant experience now.  How expensive is watching a variable?
So far I was convinced this would be used for debugging purposes only.

> The dispnew.c part is semi-cleanup: it isn't strictly needed
> after the changes in window_box_height, although originally that flag
> not being reset upon window resizing was exactly the root cause for
> the problem after "F2 up".  But I don't like the idea of this flag
> remaining set, even if no one should be looking at it.  Hmm... maybe I
> should reset the flag even if we did reallocate current_matrix...

What does "resizing a window without allocating new rows" encompass?
Is this only shrinking the window height ('shrink-/split-window') or
also making a special line like the mode line taller (eating away some
of the remaining matrix lines, naively spoken)?

martin





reply via email to

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