GNU bug report logs - #16013
24.3.50; Rows in height is interpreted as pixels.

Previous Next

Package: emacs;

Reported by: Jan Djärv <jan.h.d <at> swipnet.se>

Date: Sat, 30 Nov 2013 13:10:01 UTC

Severity: normal

Tags: moreinfo

Found in version 24.3.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


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

From: martin rudalics <rudalics <at> gmx.at>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: "16013 <at> debbugs.gnu.org" <16013 <at> debbugs.gnu.org>
Subject: Re: bug#16013: 24.3.50; Rows in height is interpreted as pixels.
Date: Sun, 12 Jan 2014 12:46:03 +0100
> This has been inconsistent historically, i.e. Lucid/Motif/No toolkit counts differently than Gtk/NS.
> I think the Gtk count makes more sense.  If a user requests 50 lines he probably means 50 editable lines, not 47.  So I think we should not count tool bar or menu bar.

I agree.  Obviously, the fact that initial and subsequent frames have
different heights is a bug per se but I wanted a directive in either
direction.

> The documentation says
> "The height of the frame contents, in characters."
> I don't think menu and tool bar is content.
>
> This may break some lisp code that counts lines and does it differently for the two cases.  I don't know if there are any such code though.
>
> BTW what values does the frame parameter height have now that pixelwise resize may show partial lines?  A floating point value?

No.  It's calculated thusly

  height = (f->new_height
	    ? (f->new_pixelwise
	       ? (f->new_height / FRAME_LINE_HEIGHT (f))
	       : f->new_height)
	    : FRAME_LINES (f));
  store_in_alist (&alist, Qheight, make_number (height));

so it's rounded down.

martin




This bug report was last modified 4 years and 257 days ago.

Previous Next


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