unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 14825@debbugs.gnu.org
Subject: bug#14825: 24.3.50; split-window-below miscounts window lines
Date: Sat, 13 Jul 2013 15:56:50 +0200	[thread overview]
Message-ID: <51E15CA2.70600@gmx.at> (raw)
In-Reply-To: <83sizi4qun.fsf@gnu.org>

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





  reply	other threads:[~2013-07-13 13:56 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-08 17:52 bug#14825: 24.3.50; split-window-below miscounts window lines Eli Zaretskii
2013-07-09  9:09 ` martin rudalics
2013-07-09 16:12   ` Eli Zaretskii
2013-07-10  7:20     ` martin rudalics
2013-07-10 15:42       ` Eli Zaretskii
2013-07-11  6:27         ` martin rudalics
2013-07-11 16:52           ` Eli Zaretskii
2013-07-12  8:21             ` martin rudalics
2013-07-12  9:09               ` Eli Zaretskii
2013-07-12 10:12                 ` martin rudalics
2013-07-12 13:29                   ` Eli Zaretskii
2013-07-12 14:57                     ` Juanma Barranquero
2013-07-13 11:10                     ` martin rudalics
2013-07-13 11:54                       ` Eli Zaretskii
2013-07-13 13:56                         ` martin rudalics [this message]
2013-07-13 14:38                           ` Eli Zaretskii
2019-10-15 17:38 ` martin rudalics
2020-09-21 12:38   ` Lars Ingebrigtsen
2020-09-21 14:29     ` Eli Zaretskii
2020-09-21 17:46       ` martin rudalics
2020-09-21 17:48         ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51E15CA2.70600@gmx.at \
    --to=rudalics@gmx.at \
    --cc=14825@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).