GNU bug report logs - #14233
24.3; Don't constrain frame size to character multiples

Previous Next

Full log

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 'Eli Zaretskii' <eliz <at> gnu.org>, jan.h.d <at> swipnet.se, esabof <at> gmail.com,
	14233 <at> debbugs.gnu.org
Subject: RE: bug#14233: 24.3; Don't constrain frame size to character multiples
Date: Sun, 21 Apr 2013 09:17:34 -0700

>  > You seem to be saying that such problems were solved long 
>  > ago (Emacs 21, no less).  But no, it is an open enhancement
>  > request to be able to compute the buffer "text" area size
>  > in pixels, as _displayed_ (in order, e.g., to fit a
>  > window/frame to it).
> 
> I suppose you mean to (1) compute the area size in pixels as displayed
> and (2) pixelwise fit the window/frame to it.  This is indeed what I'm
> doing here.

Yes.  I think (still) that my posts here have been appropriate for this thread.
If I learn otherwise then I will excuse myself for being off-topic.

I have code (in fit-frame.el) that tries to fit frames to their displayed
buffers, typically one buffer per frame.  It currently does not (cannot) take
into account the kinds of things I mentioned, which amount to all the various
ways in which what is displayed in the buffer ("text" area) cannot be modeled
exactly by just knowing the number of text lines, the frame char size, and the
maximum line length.

The fit-frame code takes into account the screen real estate used for things
like a toolbar and menu bar, but it does not yet take into account the buffer
"text" _as displayed_.  That is what the enhancement request in bug #7822 is
about.  And AFAICT it is also partly what this bug (#14233) is about.

Previous Next

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