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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: rgm <at> gnu.org, esabof <at> gmail.com, 14233 <at> debbugs.gnu.org
Subject: Re: bug#14233: 24.3; Don't constrain frame size to character multiples
Date: Sat, 20 Apr 2013 19:25:57 +0300

> Date: Sat, 20 Apr 2013 15:38:50 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: rgm <at> gnu.org, esabof <at> gmail.com, 14233 <at> debbugs.gnu.org
> 
>  >> There are some subtle issues.  Suppose I now have two adjacent windows
>  >> each 200 pixels high.  I have to give these windows suitable line
>  >> heights.  Giving them both either 12 lines or 13 lines will break
>  >> calculations based on the return values of `window-edges'.
>  >
>  > What will break?
> 
> It will break tests for adjacency of windows based on checking whether
> the bottom/right edge of a window equals the top/left edge of another
> window.
> 
>  > Is it possible to avoid the breakage without
>  > imposing arbitrary restrictions on pixel dimensions of windows?
> 
> One can check whether pixel-edges are equal.

Yes, I think that's a better solution for that.

>  >> But on Windows the toolbar is included in the frame's text height and
>  >> sometimes even the menubar is.  And the display margins, whether outside
>  >> or inside the fringes, are part of the text width.  Aren't these mental
>  >> dissonances as well?
>  >
>  > No, because a tool bar is just another window (albeit a special one).
> 
> Which usually doesn't display text.

Windows in Emacs can display images as well, and that's exactly what
the tool bar window does, see redisplay_tool_bar.  It displays text
with display properties that specify images.

> Also the frame's internal border is drawn in between toolbar and the
> frame's root window

At least on MS-Windows, I see no border.  Or perhaps I don't know what
to look for.

>  > As for display margins, they do display text, don't they?
> 
> IIUC they could display anything fringes can display

No.  Fringes can only display bitmaps.  The cannot display text or
images that we support in the text area or on margins.

>  > It could be that the fringes are included because of the display
>  > margins outside the fringes configuration (which is the default).
> 
> I'm missing you here.

I'm trying to think why the fringes were included.  It is possible
that the reasons were practical rather then anything else.  Like the
desire to have the text area contiguous.

> All this "a frame's width is the width of its text area" stuff is
> only a hindrance in this regard.

I was not arguing in favor of it.  If you want to change that, I'm not
going to object.

> BTW, I've never been able to understand the manuals and doc-strings in
> this regard.  Consider the doc-string of `set-frame-width': "Specify
> that the frame FRAME has COLS columns."  Or its manual entry: "This
> function sets the width of FRAME, measured in characters."

What's wrong with those?

Previous Next

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