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

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

bug#18357: 24.3.93; Calendar not fully displayed


From: martin rudalics
Subject: bug#18357: 24.3.93; Calendar not fully displayed
Date: Sun, 31 Aug 2014 13:28:57 +0200

> If I follow you (but I'm not sure I do), I think you are mistaken here:
> when I step through the code, fit-window-to-buffer is called (in
> calendar-generate-window, as noted above) with *Calendar* buffer window
> already being the selected window.  In any case, the estimate for the
> mode line height should be the same in my case as in yours, see below.

It seems you're right.  If, with my recipe, I set a breakpoint at line
9880 in xdisp.c

    y = y + WINDOW_MODE_LINE_HEIGHT (w);

then, for some reason I can't explain, the value of w->mode_line_height
is already set to a non-negative value although from my reading of the
code this should happen only if line 1428 of xdisp.c (in pos_visible_p)
was executed before, a thing which doesn't happen here.  I must admit
that I don't understand the window mode line height caching mechanism.

> In my recipe, both active and inactive mode lines have the same height:
> face mode-line-inactive inherits the overline attribute from face
> mode-line.
>
> One interesting observation (which I do not understand), is that when I
> execute the recipe and step through calendar-generate-window with
> Edebug, after the call to fit-window-to-buffer, the height of the
> Calendar window is 9, and the Calendar is fully displayed.  But when I
> execute the recipe alone, the height is 8 and the display is partial.

Probably edebug has the same effect as the `sit-for' in my scenario.  It
redisplays the window and the new mode line height is used when fitting
the window.  In any case the `sit-for' in my scenario makes sure that
w->mode_line_height is 20 at the breakpoint mentioned above as opposed
to 16 without the `sit-for'.

martin





reply via email to

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