all messages for Emacs-related lists mirrored at yhetil.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: Fri, 12 Jul 2013 12:12:49 +0200	[thread overview]
Message-ID: <51DFD6A1.4010904@gmx.at> (raw)
In-Reply-To: <83ehb45eli.fsf@gnu.org>

 > Yes, I know.  But note that this extended explanation is also
 > misleading, because it silently assumes that the default face was not
 > remapped.  If the default face _is_ remapped, then "the frame's
 > default font" is ambiguous at best, since '(face-font 'default)' will
 > return a font whose size is not the one meant by the above
 > description.

Much, much worse: The description implies that a frame and its windows
(and its scrollbars, fringes, toolbars) have to be resized when the
default face changes (no remapping involved).

 >> If we want to put this explanation into the doc-strings, we'd probably
 >> have to change the doc-strings of frame functions too.
 >
 > We could just have a warning there about not using these functions to
 > count text lines in a window.

I don't understand - frame functions usually don't count text lines.

 > Yes, but it's not only about the default face.  Did you try setting
 > line-spacing to something non-nil lately?  Try it: it's a lot of fun
 > looking at what window-text-height and its ilk return in that case.

I'll do as soon as I'm able to build.  On my present, old build I don't
see anything abnormal.

 >> Now if the window is the only one on its frame, you would have to change
 >> the frame's nominal height as well
 >
 > The number of lines in the frame does not necessarily need to change,
 > because a frame has other elements, even if it has only one window --
 > the mode line,

... the mode line belongs to the window (albeit in some different font)
...

 > the menu bar, the tool bar, etc.  What matters is the
 > root window, not the frame.  So we can still measure a frame in
 > canonical units.

This means that you no more have sensible means to compare the
sizes and positions of windows with those of their frames.

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

 >> Lifting the present relationship without providing a viable alternative
 >> would be a misconception IMO.
 >
 > That's why I suggested to introduce a separate set of APIs.

What would their specification look like?

 >  . Say in the doc strings of all these functions that their return
 >    values should NOT be used to count lines or columns of text in a
 >    window;

In the doc-strings of `split-height-threshold' or `window-min-height'?

 >  . Add a separate set of APIs for counting the number of default-face
 >    text lines and characters in a window.

I don't understand: Would `window-text-height' be part of this set?  Or
would I have to write `window-default-text-height'?  Maybe you could
enumerate two or three existing functions and tell me what they
currently do wrong and what they or their counterparts in the new API
would have to do instead.

martin





  reply	other threads:[~2013-07-12 10:12 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 [this message]
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
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

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

  git send-email \
    --in-reply-to=51DFD6A1.4010904@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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.