bug#18357: 24.3.93; Calendar not fully displayed

bug#18357: 24.3.93; Calendar not fully displayed

[Stephen Berman]

0. emacs -Q
   (sanity check) M-x calendar => The Calendar is fully displayed in the
   lower fitted window.
1. M-x customize-option RET calendar-week-start-day RET, set value to 1
   and save for current session.
   M-x customize-face RET mode-line RET, show all attributes, check
   `Overline' set its value to `On' and save for current session.
2. M-x calendar => Only the last four lines of the Calendar are
   displayed in the lower fitted window.

It looks as if point is centered in the Calendar window, but if I type
`C-l', it displays the last five lines, not just the last four.  Also,
the date could be relevant, since point is on today's date, which is on
the last line of the displayed Calendar; if this changes on September 1,
I'll report back.

I'm not sure but I think I first observed this problem in my build of
2014-08-20.  I don't remember seeing it in my previous build of
2014-07-22, but if I do the above recipe with the executable from the
that build, I do see the problematic display, which suggests it is due
to a change in a non-pre-loaded lisp file, though nothing in the
ChangeLog looks relevant, so perhaps my memory of when this began is
failing me.

The Calendar display problem also happens in my 2014-08-21 build from
the trunk, but only when configured --without-toolkit-scroll-bars; a
trunk build with (GTK+) scroll bars (including the new horizontal scroll
bar) does not show the problem.  However, I just rebuilt the current
emacs-24 --without-toolkit-scroll-bars and still see the problem there.

In GNU Emacs 24.3.93.4 (x86_64-suse-linux-gnu, GTK+ Version 3.10.4)
 of 2014-08-29 on rosalinde
Repository revision: 117464 rgm@gnu.org-20140828191824-o5hn2x503w527yhn
Windowing system distributor `The X.Org Foundation', version 11.0.11403901
System Description:	openSUSE 13.1 (Bottle) (x86_64)

Configured using:
 `configure --without-toolkit-scroll-bars CFLAGS=-g3'

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

bug#18357: 24.3.93; Calendar not fully displayed

[Stephen Berman]

On Fri, 29 Aug 2014 20:24:09 +0200 Stephen Berman <stephen.berman@gmx.net> wrote:

> 0. emacs -Q
>    (sanity check) M-x calendar => The Calendar is fully displayed in the
>    lower fitted window.
> 1. M-x customize-option RET calendar-week-start-day RET, set value to 1
>    and save for current session.
>    M-x customize-face RET mode-line RET, show all attributes, check
>    `Overline' set its value to `On' and save for current session.
> 2. M-x calendar => Only the last four lines of the Calendar are
>    displayed in the lower fitted window.
>
> It looks as if point is centered in the Calendar window, but if I type
> `C-l', it displays the last five lines, not just the last four.  Also,
> the date could be relevant, since point is on today's date, which is on
> the last line of the displayed Calendar; if this changes on September 1,
> I'll report back.
>
> I'm not sure but I think I first observed this problem in my build of
> 2014-08-20.  I don't remember seeing it in my previous build of
> 2014-07-22, but if I do the above recipe with the executable from the
> that build, I do see the problematic display, which suggests it is due
> to a change in a non-pre-loaded lisp file, though nothing in the
> ChangeLog looks relevant, so perhaps my memory of when this began is
> failing me.
>
> The Calendar display problem also happens in my 2014-08-21 build from
> the trunk, but only when configured --without-toolkit-scroll-bars; a
> trunk build with (GTK+) scroll bars (including the new horizontal scroll
> bar) does not show the problem.  However, I just rebuilt the current
> emacs-24 --without-toolkit-scroll-bars and still see the problem there.
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  I meant: with toolkit scroll bars

> In GNU Emacs 24.3.93.4 (x86_64-suse-linux-gnu, GTK+ Version 3.10.4)
>  of 2014-08-29 on rosalinde
> Repository revision: 117464 rgm@gnu.org-20140828191824-o5hn2x503w527yhn
> Windowing system distributor `The X.Org Foundation', version 11.0.11403901
> System Description:	openSUSE 13.1 (Bottle) (x86_64)
>
> Configured using:
>  `configure --without-toolkit-scroll-bars CFLAGS=-g3'
>
> Important settings:
>   value of $LANG: en_US.UTF-8
>   value of $XMODIFIERS: @im=ibus
>   locale-coding-system: utf-8-unix

bug#18357: 24.3.93; Calendar not fully displayed

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Date: Fri, 29 Aug 2014 20:24:09 +0200
> 
> 0. emacs -Q
>    (sanity check) M-x calendar => The Calendar is fully displayed in the
>    lower fitted window.
> 1. M-x customize-option RET calendar-week-start-day RET, set value to 1
>    and save for current session.
>    M-x customize-face RET mode-line RET, show all attributes, check
>    `Overline' set its value to `On' and save for current session.
> 2. M-x calendar => Only the last four lines of the Calendar are
>    displayed in the lower fitted window.
> 
> It looks as if point is centered in the Calendar window, but if I type
> `C-l', it displays the last five lines, not just the last four.  Also,
> the date could be relevant, since point is on today's date, which is on
> the last line of the displayed Calendar; if this changes on September 1,
> I'll report back.
> 
> I'm not sure but I think I first observed this problem in my build of
> 2014-08-20.  I don't remember seeing it in my previous build of
> 2014-07-22, but if I do the above recipe with the executable from the
> that build, I do see the problematic display, which suggests it is due
> to a change in a non-pre-loaded lisp file, though nothing in the
> ChangeLog looks relevant, so perhaps my memory of when this began is
> failing me.
> 
> The Calendar display problem also happens in my 2014-08-21 build from
> the trunk, but only when configured --without-toolkit-scroll-bars; a
> trunk build with (GTK+) scroll bars (including the new horizontal scroll
> bar) does not show the problem.  However, I just rebuilt the current
> emacs-24 --without-toolkit-scroll-bars and still see the problem there.

Sorry, I don't see any problem here: with the customized face of the
mode line, the window showing the calendar buffer is not tall enough
to show all of the buffer _and_ show the cursor on today's date (we
don't allow point to be in a partially visible line).  So Emacs
scrolls the display to make the line with point fully visible.  That's
perfectly normal, not a problem.

calendar.el includes a facility to fit the window to the buffer's
contents, but it only does so when "M-x calendar" is invoked from the
window that displays the calendar:

    ;; Don't do any window-related stuff if we weren't called from a
    ;; window displaying the calendar.
    (when in-calendar-window
      (if (window-combined-p)
	  ;; Adjust the window to exactly fit the displayed calendar.
	  (fit-window-to-buffer nil nil calendar-minimum-window-height)
	;; For a full height window or a window that is horizontally
	;; combined don't fit height to that of its buffer.
	(set-window-vscroll nil 0))
      (sit-for 0))

This code has been there for ages, so I don't believe some change done
lately changed anything there.  Rather, I'm guessing that this is
caused by the fact that today's date is on the last line of the
buffer, which wasn't so before.

You can customize calendar-minimum-window-height to work around "the
problem".

bug#18357: 24.3.93; Calendar not fully displayed

[Stephen Berman]

On Sat, 30 Aug 2014 12:58:26 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Date: Fri, 29 Aug 2014 20:24:09 +0200
>> 
>> 0. emacs -Q
>>    (sanity check) M-x calendar => The Calendar is fully displayed in the
>>    lower fitted window.
>> 1. M-x customize-option RET calendar-week-start-day RET, set value to 1
>>    and save for current session.
>>    M-x customize-face RET mode-line RET, show all attributes, check
>>    `Overline' set its value to `On' and save for current session.
>> 2. M-x calendar => Only the last four lines of the Calendar are
>>    displayed in the lower fitted window.
>> 
>> It looks as if point is centered in the Calendar window, but if I type
>> `C-l', it displays the last five lines, not just the last four.  Also,
>> the date could be relevant, since point is on today's date, which is on
>> the last line of the displayed Calendar; if this changes on September 1,
>> I'll report back.
>> 
>> I'm not sure but I think I first observed this problem in my build of
>> 2014-08-20.  I don't remember seeing it in my previous build of
>> 2014-07-22, but if I do the above recipe with the executable from the
>> that build, I do see the problematic display, which suggests it is due
>> to a change in a non-pre-loaded lisp file, though nothing in the
>> ChangeLog looks relevant, so perhaps my memory of when this began is
>> failing me.
>> 
>> The Calendar display problem also happens in my 2014-08-21 build from
>> the trunk, but only when configured --without-toolkit-scroll-bars; a
>> trunk build with (GTK+) scroll bars (including the new horizontal scroll
>> bar) does not show the problem.  However, I just rebuilt the current
>> emacs-24 --without-toolkit-scroll-bars and still see the problem there.
>
> Sorry, I don't see any problem here: with the customized face of the
> mode line, the window showing the calendar buffer is not tall enough
> to show all of the buffer _and_ show the cursor on today's date (we
> don't allow point to be in a partially visible line).  So Emacs
> scrolls the display to make the line with point fully visible.  That's
> perfectly normal, not a problem.
[...]
>                                 Rather, I'm guessing that this is
> caused by the fact that today's date is on the last line of the
> buffer, which wasn't so before.
>
> You can customize calendar-minimum-window-height to work around "the
> problem".

Your analysis is convincing (and makes explicit what I vaguely suspected
about point being on the last line; moreover, I was mistaken in saying
that the amount scrolled was different from doing `C-l': it depends on
which line point is on when you type `C-l', of course).  In addition,
the workaround is acceptable, so I'm closing this bug.

Two questions remain for me: (i) Since I use the Calendar pretty much
daily and the triggering configuration comes up about every four weeks,
why don't I remember seeing this before? (This isn't a question I think
you can answer; I guess my memory just isn't good enough.) (ii) Why
doesn't "the problem" happen in the trunk build with toolkit scroll
bars?  Is this perhaps because Martin's window changes add an extra
pixel or two, leaving enough space?

Steve Berman

bug#18357: 24.3.93; Calendar not fully displayed

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 18357-done@debbugs.gnu.org
> Date: Sat, 30 Aug 2014 13:32:24 +0200
> 
> Your analysis is convincing (and makes explicit what I vaguely suspected
> about point being on the last line; moreover, I was mistaken in saying
> that the amount scrolled was different from doing `C-l': it depends on
> which line point is on when you type `C-l', of course).  In addition,
> the workaround is acceptable, so I'm closing this bug.

Thanks.

> Two questions remain for me: (i) Since I use the Calendar pretty much
> daily and the triggering configuration comes up about every four weeks,
> why don't I remember seeing this before? (This isn't a question I think
> you can answer; I guess my memory just isn't good enough.)

You could try paying attention from now on.

> (ii) Why doesn't "the problem" happen in the trunk build with
> toolkit scroll bars?  Is this perhaps because Martin's window
> changes add an extra pixel or two, leaving enough space?

Maybe.  Strangely, I can no longer reproduce this on the emacs-24
branch.  If you still can, fire up 2 Emacsen, one each from either
branch, put their frames side by side, and compare the dimensions of
the text area.

bug#18357: 24.3.93; Calendar not fully displayed

[Stephen Berman]

[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]

On Sat, 30 Aug 2014 15:34:59 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> (ii) Why doesn't "the problem" happen in the trunk build with
>> toolkit scroll bars?  Is this perhaps because Martin's window
>> changes add an extra pixel or two, leaving enough space?
>
> Maybe.

Actually, the difference is due to the horizontal scroll bar, as the
attached screen shot makes clear.

>         Strangely, I can no longer reproduce this on the emacs-24
> branch.  If you still can, fire up 2 Emacsen, one each from either
> branch, put their frames side by side, and compare the dimensions of
> the text area.

The screen shot shows builds from trunk without and with toolkit scroll
bars.  For the former, window-height of the Customize buffer is 26 in
both, while window-height of the Calendar buffer is 8 for the
non-toolkit and 9 for the toolkit build.  Interestingly, it looks to me
like the Customize buffer of the non-toolkit build is 2-3 pixels higher
than that of the toolkit build, but I assume that it due to the exact
height of the horizontal scroll bar, which takes up a line of height.

Steve


[-- Attachment #2: calendar display --]
[-- Type: image/png, Size: 145786 bytes --]

bug#18357: 24.3.93; Calendar not fully displayed

[martin rudalics]

 > The screen shot shows builds from trunk without and with toolkit scroll
 > bars.  For the former, window-height of the Customize buffer is 26 in
 > both, while window-height of the Calendar buffer is 8 for the
 > non-toolkit and 9 for the toolkit build.  Interestingly, it looks to me
 > like the Customize buffer of the non-toolkit build is 2-3 pixels higher
 > than that of the toolkit build, but I assume that it due to the exact
 > height of the horizontal scroll bar, which takes up a line of height.

If you use horizontal scroll bars, the height of the initial frame is
larger by the height of one scroll bar.  You should be able to verify
this by calling `window--dump-frame' in that frame.  Note that the
height of the scroll bar is specified by the toolkit and should be taken
exactly, without rounding to lines.  Any line/column values you see are
only estimates due to rounding.  If you set `window-resize-pixelwise' to
t, `fit-window-to-buffer' should also size the calendar exactly to its
height - modulo the mode line height which it cannot tell in advance.

martin

bug#18357: 24.3.93; Calendar not fully displayed

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]

 > Why
 > doesn't "the problem" happen in the trunk build with toolkit scroll
 > bars?  Is this perhaps because Martin's window changes add an extra
 > pixel or two, leaving enough space?

I don't think so.  For example here on Windows XP, emacs -Q with current
trunk, evaluating

(progn
   (custom-set-faces
    '(mode-line ((t (:background "#000040" :foreground "wheat" :box (:line-width 2 :color "#000040") :weight bold :family "Verdana"))))
    '(mode-line-inactive ((t (:inherit mode-line :background "grey48" :foreground "wheat" :box (:line-width 2 :color "#000040"))))))
   (setq calendar-week-start-day 1)
   (calendar))

gives screenshot calendar-1.png while evaluating

(progn
   (custom-set-faces
    '(mode-line ((t (:background "#000040" :foreground "wheat" :box (:line-width 2 :color "#000040") :weight bold :family "Verdana"))))
    '(mode-line-inactive ((t (:inherit mode-line :background "grey48" :foreground "wheat" :box (:line-width 2 :color "#000040"))))))
   (setq calendar-week-start-day 1)
   (sit-for 0)
   (calendar))

gives the expected screenshot calendar-2.png.

martin

[-- Attachment #2: calendar-1.png --]
[-- Type: image/png, Size: 28112 bytes --]

[-- Attachment #3: calendar-2.png --]
[-- Type: image/png, Size: 32630 bytes --]

bug#18357: 24.3.93; Calendar not fully displayed

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]

> I don't think so.  For example here on Windows XP, emacs -Q with current
> trunk, evaluating
>
> (progn
>    (custom-set-faces
>     '(mode-line ((t (:background "#000040" :foreground "wheat" :box (:line-width 2 :color "#000040") :weight bold :family "Verdana"))))
>     '(mode-line-inactive ((t (:inherit mode-line :background "grey48" :foreground "wheat" :box (:line-width 2 :color "#000040"))))))
>    (setq calendar-week-start-day 1)
>    (calendar))
>
> gives screenshot calendar-1.png while evaluating
>
> (progn
>    (custom-set-faces
>     '(mode-line ((t (:background "#000040" :foreground "wheat" :box (:line-width 2 :color "#000040") :weight bold :family "Verdana"))))
>     '(mode-line-inactive ((t (:inherit mode-line :background "grey48" :foreground "wheat" :box (:line-width 2 :color "#000040"))))))
>    (setq calendar-week-start-day 1)
>    (sit-for 0)
>    (calendar))
>
> gives the expected screenshot calendar-2.png.

Sorry.  The screenshots were from an earlier experiment.  The current ones
should fit the description above.

martin


[-- Attachment #2: calendar-1.png --]
[-- Type: image/png, Size: 26938 bytes --]

[-- Attachment #3: calendar-2.png --]
[-- Type: image/png, Size: 29730 bytes --]

bug#18357: 24.3.93; Calendar not fully displayed

[Eli Zaretskii]

> Date: Sat, 30 Aug 2014 14:48:55 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
> 
> > I don't think so.  For example here on Windows XP, emacs -Q with current
> > trunk, evaluating
> >
> > (progn
> >    (custom-set-faces
> >     '(mode-line ((t (:background "#000040" :foreground "wheat" :box (:line-width 2 :color "#000040") :weight bold :family "Verdana"))))
> >     '(mode-line-inactive ((t (:inherit mode-line :background "grey48" :foreground "wheat" :box (:line-width 2 :color "#000040"))))))
> >    (setq calendar-week-start-day 1)
> >    (calendar))
> >
> > gives screenshot calendar-1.png while evaluating
> >
> > (progn
> >    (custom-set-faces
> >     '(mode-line ((t (:background "#000040" :foreground "wheat" :box (:line-width 2 :color "#000040") :weight bold :family "Verdana"))))
> >     '(mode-line-inactive ((t (:inherit mode-line :background "grey48" :foreground "wheat" :box (:line-width 2 :color "#000040"))))))
> >    (setq calendar-week-start-day 1)
> >    (sit-for 0)
> >    (calendar))
> >
> > gives the expected screenshot calendar-2.png.
> 
> Sorry.  The screenshots were from an earlier experiment.  The current ones
> should fit the description above.

I see no differences between the 2 progn forms you evaluated, so I
cannot really judge whether they correspond to what Stephen reported.

bug#18357: 24.3.93; Calendar not fully displayed

[martin rudalics]

 > I see no differences between the 2 progn forms you evaluated, so I
 > cannot really judge whether they correspond to what Stephen reported.

You mean the `sit-for' doesn't make a difference for you?  I suppose we
have to do a redisplay to know the mode-line height when fitting the
window in `calendar' but maybe you have a better explanation for this.

martin

bug#18357: 24.3.93; Calendar not fully displayed

[Eli Zaretskii]

> Date: Sat, 30 Aug 2014 15:51:50 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 18357@debbugs.gnu.org, stephen.berman@gmx.net
> 
>  > I see no differences between the 2 progn forms you evaluated, so I
>  > cannot really judge whether they correspond to what Stephen reported.
> 
> You mean the `sit-for' doesn't make a difference for you?  I suppose we
> have to do a redisplay to know the mode-line height when fitting the
> window in `calendar' but maybe you have a better explanation for this.

The original report was about mode-line face causing the problem.  Are
you saying that the problem is not the face, but the lack of sit-for
somewhere?

bug#18357: 24.3.93; Calendar not fully displayed

[martin rudalics]

 > The original report was about mode-line face causing the problem.  Are
 > you saying that the problem is not the face, but the lack of sit-for
 > somewhere?

The mode line face specifies the height of the mode line.  IIUC
`fit-window-to-buffer' gets this height via CURRENT_MODE_LINE_HEIGHT (in
dispextern.h) which is likely wrong if the font has not been applied yet
to the target window.

Note that we allow the font to change the height of the mode line which
may partially overwrite the last line(s) of the window text.  This seems
to backfire here (I haven't checked it).  Personally, I'd prefer to have
the user specify the height of the modeline in advance and have the
display engine use a smaller font if the one the user asked for doesn't
fit within the specified height.  Maybe that's over-engineering but it
should avoid problems like the present one.

martin

bug#18357: 24.3.93; Calendar not fully displayed

[Eli Zaretskii]

> Date: Sat, 30 Aug 2014 18:40:39 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 18357@debbugs.gnu.org, stephen.berman@gmx.net
> 
>  > The original report was about mode-line face causing the problem.  Are
>  > you saying that the problem is not the face, but the lack of sit-for
>  > somewhere?
> 
> The mode line face specifies the height of the mode line.  IIUC
> `fit-window-to-buffer' gets this height via CURRENT_MODE_LINE_HEIGHT (in
> dispextern.h) which is likely wrong if the font has not been applied yet
> to the target window.

Yes, but the original recipe involved Customize to change the
mode-line face, so in that case the changes in the mode-line face have
propagated long ago by the time "M-x calendar" is invoked.

So I don't see how the above explanation could be relevant to the
original issue.

> Note that we allow the font to change the height of the mode line which
> may partially overwrite the last line(s) of the window text.  This seems
> to backfire here

I see no "backfire".  Emacs scrolls the window to make point fully
visible, that's all.

bug#18357: 24.3.93; Calendar not fully displayed

[martin rudalics]

 >> The mode line face specifies the height of the mode line.  IIUC
 >> `fit-window-to-buffer' gets this height via CURRENT_MODE_LINE_HEIGHT (in
 >> dispextern.h) which is likely wrong if the font has not been applied yet
 >> to the target window.
 >
 > Yes, but the original recipe involved Customize to change the
 > mode-line face, so in that case the changes in the mode-line face have
 > propagated long ago by the time "M-x calendar" is invoked.

They propagated to the selected window only.  The calendar window does
not even exist at that time.

 > So I don't see how the above explanation could be relevant to the
 > original issue.

I have no other one.  The scenarios differ in one point: In mine the
mode lines of all windows are the same height, but
`fit-window-to-buffer' doesn't know that height yet when it's executed.

For Stephen's the estimate is for a non-selected window and `calendar'
selects the window _after_ `fit-window-to-buffer' was executed.

If you have a better explanation, I'll be all ears.

 >> Note that we allow the font to change the height of the mode line which
 >> may partially overwrite the last line(s) of the window text.  This seems
 >> to backfire here
 >
 > I see no "backfire".  Emacs scrolls the window to make point fully
 > visible, that's all.

It backfires because `fit-window-to-buffer' can't make the window tall
enough since it doesn't yet know how large the mode line will be.  And
since it never will be clairvoyant enough to know which window will be
selected, I see no chance to reliably fix Stephen's scenario.

martin

bug#18357: 24.3.93; Calendar not fully displayed

[Eli Zaretskii]

> Date: Sat, 30 Aug 2014 19:15:54 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 18357@debbugs.gnu.org, stephen.berman@gmx.net
> 
>  > So I don't see how the above explanation could be relevant to the
>  > original issue.
> 
> I have no other one.  The scenarios differ in one point: In mine the
> mode lines of all windows are the same height, but
> `fit-window-to-buffer' doesn't know that height yet when it's executed.

Are you sure fit-window-to-buffer was called?  My reading of
calendar.el is that it isn't in this scenario.

> For Stephen's the estimate is for a non-selected window and `calendar'
> selects the window _after_ `fit-window-to-buffer' was executed.

See above: are you sure?

> If you have a better explanation, I'll be all ears.

I don't see what I need to explain.  From my POV, what we see here is
all normal, as I already explained in my original response to Stephen.

>  >> Note that we allow the font to change the height of the mode line which
>  >> may partially overwrite the last line(s) of the window text.  This seems
>  >> to backfire here
>  >
>  > I see no "backfire".  Emacs scrolls the window to make point fully
>  > visible, that's all.
> 
> It backfires because `fit-window-to-buffer' can't make the window tall
> enough since it doesn't yet know how large the mode line will be.  And
> since it never will be clairvoyant enough to know which window will be
> selected, I see no chance to reliably fix Stephen's scenario.

Then you agree with me: there's no problem here, just normal reaction
to the fact that point entered a partially visible line.

bug#18357: 24.3.93; Calendar not fully displayed

[martin rudalics]

 > Are you sure fit-window-to-buffer was called?  My reading of
 > calendar.el is that it isn't in this scenario.

It is.

 >> For Stephen's the estimate is for a non-selected window and `calendar'
 >> selects the window _after_ `fit-window-to-buffer' was executed.
 >
 > See above: are you sure?

Yes.  Stephen please verify.

 >> If you have a better explanation, I'll be all ears.
 >
 > I don't see what I need to explain.  From my POV, what we see here is
 > all normal, as I already explained in my original response to Stephen.

The problem is that `fit-window-to-buffer' shouldn't leave a line
partially visible.  At least not in the case at hand where there's
plenty of space.

 > Then you agree with me: there's no problem here, just normal reaction
 > to the fact that point entered a partially visible line.

See above.  Stephen, does it fit if you make the font of a non-active
mode line just as high as that of an active one?

martin

bug#18357: 24.3.93; Calendar not fully displayed

[Stephen Berman]

On Sat, 30 Aug 2014 20:08:55 +0200 martin rudalics <rudalics@gmx.at> wrote:

>> Are you sure fit-window-to-buffer was called?  My reading of
>> calendar.el is that it isn't in this scenario.
>
> It is.

Martin is correct: when calendar-generate-window is called from
calendar-basic-setup, the selected window is the one containing the
*Calendar* buffer (this is because calendar-basic-setup previously
called `(pop-to-buffer calendar-buffer)').

>>> For Stephen's the estimate is for a non-selected window and `calendar'
>>> selects the window _after_ `fit-window-to-buffer' was executed.
>>
>> See above: are you sure?
>
> Yes.  Stephen please verify.

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.

>>> If you have a better explanation, I'll be all ears.
>>
>> I don't see what I need to explain.  From my POV, what we see here is
>> all normal, as I already explained in my original response to Stephen.
>
> The problem is that `fit-window-to-buffer' shouldn't leave a line
> partially visible.  At least not in the case at hand where there's
> plenty of space.
>
>> Then you agree with me: there's no problem here, just normal reaction
>> to the fact that point entered a partially visible line.
>
> See above.  Stephen, does it fit if you make the font of a non-active
> mode line just as high as that of an active one?

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.

Steve Berman

bug#18357: 24.3.93; Calendar not fully displayed

[martin rudalics]

 > 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

bug#18357: 24.3.93; Calendar not fully displayed

[martin rudalics]

The following is based on my scenario.  With emacs -Q evaluate the
following form

(progn
   (custom-set-faces
    '(mode-line ((t (:background "#000040" :foreground "wheat" :box (:line-width 2 :color "#000040") :weight bold :family "Verdana"))))
    '(mode-line-inactive ((t (:inherit mode-line :background "grey48" :foreground "wheat" :box (:line-width 2 :color "#000040"))))))
   (setq calendar-week-start-day 1)
   (calendar))

In `calendar' two interesting things happen.  The first one is a
`split-window-sensibly' call to set up the calendar window.  I've put a
breakpoint in estimate_mode_line_height giving the following backtrace
(the function estimate_window_mode_line_height works around the problem
to set a breakpoint exclusively for calls from CURRENT_MODE_LINE_HEIGHT,
the redefinitions appear below for anyone interested).

#0  estimate_mode_line_height (f=0x17ca658, face_id=MODE_LINE_INACTIVE_FACE_ID) at xdisp.c:1908
#1  0x0102406d in estimate_window_mode_line_height (w=0x4988718) at xdisp.c:1928
#2  0x010860f0 in Fwindow_mode_line_height (window=...) at window.c:1010
[...]
#87 0x010fa4f7 in main (argc=2, argv=0xa32808) at emacs.c:1645

Lisp Backtrace:
"window-mode-line-height" (0x82ae8c)
"window--min-size-1" (0x82b1b8)
"window-min-size" (0x82b4e8)
0x12a2bb8 PVEC_COMPILED
"walk-window-tree-1" (0x82bb48)
"walk-window-tree-1" (0x82be78)
"walk-window-tree" (0x82c1a8)
"window--sanitize-window-sizes" (0x82c4c8)
"byte-code" (0x82c760)
"split-window" (0x82cb68)
"split-window-below" (0x82cea8)
"split-window-sensibly" (0x82d1e4)
"funcall" (0x82d1e0)
"window--try-to-split-window" (0x82d668)
"display-buffer-pop-up-window" (0x82d998)
"display-buffer--maybe-pop-up-frame-or-window" (0x82dcb8)
"display-buffer" (0x82dff8)
"pop-to-buffer" (0x82e328)
"calendar-basic-setup" (0x82e658)
"calendar" (0x82e8f0)
"progn" (0x82eadc)
"eval" (0x82ebe0)
"eval-last-sexp-1" (0x82ef0c)
"eval-last-sexp" (0x82f338)
"funcall-interactively" (0x82f334)
"call-interactively" (0x82f550)
"command-execute" (0x82f890)
(gdb)

If I here print the value of the box_line_width of the
MODE_LINE_INACTIVE_FACE_ID I get:

(gdb) p face->box_line_width
$24 = -1

which is obviously not up to date given the specification I requested.
It's only during the next redisplay that the value of 2 is recognized
and applied:

#0  realize_x_face (cache=0xf94eb0, attrs=0x82d91c) at xfaces.c:5617
#1  0x010f1d25 in realize_face (cache=0xf94eb0, attrs=0x82d91c, former_face_id=1) at xfaces.c:5443
#2  0x010f1c4c in realize_named_face (f=0x17ca658, symbol=..., id=1) at xfaces.c:5414
#3  0x010f11b7 in realize_basic_faces (f=0x17ca658) at xfaces.c:5225
#4  0x010e7259 in recompute_basic_faces (f=0x17ca658) at xfaces.c:725
#5  0x0102ae1a in init_iterator (it=0x82da44, w=0x4988718, charpos=-1, bytepos=-1, row=0x0, base_face_id=DEFAULT_FACE_ID) at xdisp.c:2890
#6  0x010424de in x_consider_frame_title (frame=...) at xdisp.c:11623
#7  0x010428dd in prepare_menu_bars () at xdisp.c:11725
#8  0x01046b0b in redisplay_internal () at xdisp.c:13549
#9  0x0104590e in redisplay () at xdisp.c:13168
#10 0x010ff5e1 in read_char (commandflag=1, map=..., prev_event=..., used_mouse_menu=0x82f7ef, end_time=0x0) at keyboard.c:2590
#11 0x0110cf87 in read_key_sequence (keybuf=0x82f8e4, bufsize=30, prompt=..., dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9152
#12 0x010fd149 in command_loop_1 () at keyboard.c:1462
#13 0x011891ce in internal_condition_case (bfun=0x10fcdc4 <command_loop_1>, handlers=..., hfun=0x10fc62f <cmd_error>) at eval.c:1347
#14 0x010fca7a in command_loop_2 (ignore=...) at keyboard.c:1193
#15 0x01188782 in internal_catch (tag=..., func=0x10fca56 <command_loop_2>, arg=...) at eval.c:1111
#16 0x010fca34 in command_loop () at keyboard.c:1172
#17 0x010fc1cb in recursive_edit_1 () at keyboard.c:782
#18 0x010fc388 in Frecursive_edit () at keyboard.c:853
#19 0x010fa4f7 in main (argc=2, argv=0xa32808) at emacs.c:1645

Lisp Backtrace:
"redisplay_internal (C function)" (0x205e398)
(gdb) p XINT (value)
$25 = 2
(gdb)

The second interesting thing happening in `calendar' is the call to
`fit-window-to-buffer'.  Since this call happens _between_ the two
backtraces reproduced above, it does not add the line-widths of the box
to the height of the mode line.  In the present case, the missing 4
pixels are responsible for (1) not making the calendar window high
enough and (2) scrolling the calendar window to move `point' out of the
scroll margin.

Obviously, putting in a `sit-for' before calling `calendar' realizes the
mode line face and the subsequential calls use the correct value.

I suppose that we should realize the mode line face whenever we call
estimate_mode_line_height but have no idea whether and how this can be
done.

martin


CURRENT_MODE_LINE_HEIGHT redefinitions.

#define CURRENT_MODE_LINE_HEIGHT(W)					\
   (W->mode_line_height >= 0						\
     ? W->mode_line_height						\
     : (W->mode_line_height						\
        = estimate_window_mode_line_height (W)))				\

int
estimate_window_mode_line_height (struct window *w)
{
   int x;

   if (MATRIX_MODE_LINE_HEIGHT (w->current_matrix))
     x = MATRIX_MODE_LINE_HEIGHT (w->current_matrix);
   else
     x = estimate_mode_line_height (XFRAME (w->frame), CURRENT_MODE_LINE_FACE_ID (w));

   return x;
}