GNU bug report logs - #4535
toolkit dependence of frame-height

Previous Next

Package: emacs;

Reported by: Glenn Morris <rgm <at> gnu.org>

Date: Wed, 23 Sep 2009 08:20:03 UTC

Severity: normal

Done: Glenn Morris <rgm <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #29 received at 4535 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 4535 <at> debbugs.gnu.org, "Jan D." <jan.h.d <at> swipnet.se>
Subject: Re: bug#4535: toolkit dependence of frame-height
Date: Fri, 25 Sep 2009 09:39:56 +0200
>> It depends on what "always have height 1 and 2" stand for.
>
> Well, I hadn't thought it through, because lines may have a variable
> height. Duh.
>
> And I can increase the buffer font-size many times over without
> changing the result of frame-height (or -width), so now I don't
> understand what "number of lines available for display" in the doc of
> frame-height means.
>
> I guess it means number of lines in units of the default face? So I
> guess that's what my original question meant.

Most frame variables seem to have a historical interpretation which
somehow got lost with the evolution of GUIs and the adaptations to
different operating systems and toolkits.  Thinking of frame sizes in
lines and columns is asking for trouble in anything but a text-only
environment.  Documenting the current behavior seems next to impossible
to me.

> I'm not going to be able to document the Windows behaviour in any
> case; maybe you'd like to do that?

I can't.  I don't understand it.  But I'll gladly read anything you come
up with for other platforms ;-)

martin



This bug report was last modified 15 years and 232 days ago.

Previous Next


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