GNU bug report logs - #14825
24.3.50; split-window-below miscounts window lines

Previous Next

Full log

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14825 <at> debbugs.gnu.org
Subject: Re: bug#14825: 24.3.50; split-window-below miscounts window lines
Date: Sat, 13 Jul 2013 15:56:50 +0200

>> What is "the actual number of text lines in a window"?
>
> The number of glyph rows visible in the window.

So this is something that changes with the text displayed in the window
and not only when changing the buffer's default face.  Wouldn't your
proposal then imply that before I want to split a window I have to check
how many lines it actually displays?  So if I'm currently watching an
*info* buffer, the height of the new window would depend on whether I'm
currently seeing a title line or not.

Also, would we then have four different units to measure window heights
- frame lines, pixels, buffer lines, displayed lines?

>>  >>  >> If OTOH the frame contains more than one window, we would have a
>>  >>  >> hard time to relate the height of these windows to that of the
>>  >>  >> frame.
>>  >>  >
>>  >>  > The only reliable way of doing that is in pixels anyway.
>>  >>
>>  >> Currently it's done in lines and columns.
>>  >
>>  > Which is why we don't need to bother that it will become unreliable,
>>  > as it is already there.
>>
>> You mean it's not reliable currently?
>
> Yes.

In what sense?  I obviously agree because I consider it wrong when
changing a frame's default face can affect its size but I suppose what
you have in mind is something different.

>> But this is what I asked for here months ago: A function that tells me
>> how much space a buffer text would occupy if displayed in a certain
>> window
>
> Well, you now have window-screen-lines ;-)

I haven't looked at it yet.  Where is it?  Does it accept arbitrary
buffer start and end points?  Does it return pixel sizes?

>> and what I wrote `window-text-pixel-size' for.  But this is based
>> on actual line heights, not necessarily those specified by the buffer's
>> default face plus line spacing.  And I suppose moving by lines calls for
>> actual line heights too.
>
> Yes, of course.  If you need to count in units of the default face and
> also take the line-spacing into consideration, window-screen-lines is
> your friend.

So we should call `window-screen-lines' before splitting a window?

> Which probably means that split-window should be told what is expected
> of it: use canonical lines or lines the current window actually uses.

I don't understand all implications of such an approach yet but in any
case we can try to support it as an option.

martin

Previous Next

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