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

Previous Next

Full log

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 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 21:26:39 +0200

Hello.

2013-04-20 15:13, Eli Zaretskii skrev:
>> Date: Sat, 20 Apr 2013 14:56:47 +0200
>> From: Jan Djärv <jan.h.d <at> swipnet.se>
>> CC: Eli Zaretskii <eliz <at> gnu.org>, esabof <at> gmail.com,
>>   14233 <at> debbugs.gnu.org
>>
>> I don't understand why we want to resize in pixels instead of
>> characters.
>
> See the beginning of this bug report, and the TODO item.
>
> In a nutshell, we resize in units of canonical character size that
> mean nothing to the windowing system and the rest of the machine.  The
> downside of that is that some specifications of the dimensions produce
> surprising results, and for no good reason.
>
>> But if you insist on resizing with pixels instead of characters, you have turn
>> WM hints off for NS and X.
>
> Could you describe in short the role of those hints for Emacs display?
> I don't believe we have this documented anywhere.

WM hints tell the window manager the width increment and height increment that 
the Emacs frame wants to be resized in.  This means when a user resizes by 
dragging the window border, the window manager only allows resize increments 
by the specified width/height increments.  So there is no half characters 
showing.  In addition, when resize occurs some, not all, window managers shows 
the size while resizing.  When width/height increments have been set, the WM 
shows the size in these units, which for Emacs translates to rows and columns.

This does not mean that the toolbar, menubar, scrollbar, fringe etc. has to be 
in a multiple of these increments.  In addition to the increments, you also 
specify a base width/height in pixels.  That base width/height is the non-text 
portions width/height.

So at any time the WM maintains the invariant:
   width = base width + n x width increment
   height = base height + m x height increment

n, m are integers.

You can also specify a minimum size, but that is not relevant to this issue.

Note that for fullscreen, the WM does not keep this invariant, nor does tiling 
window managers.  For other types of resize (i.e. interactive with the mouse) 
I'd like to keep the WM size hints, because it is more userfriendly.

If we want to make windows display partial lines that is OK, and even 
preferrable for the fullscreen/tiling case, but we should not disregard WM 
size hints for the other case.

>
>> You should thoroughly test this change on X with a couple of
>> different window manager before checking it in.  Resizing is a bit
>> of a mess on X because the intreactions with the window manager, and
>> the strange ways Emacs deals with GUI elements.
>
> Those "strange ways" are partly explained by the restrictions Martin
> is trying to lift, AFAIK.

Not really, it has more to do with how Emacs adds toolbars and menubars (after 
the frame is created).

>
>> But I'd prefer if the text part is resizable only in terms of lines/columns.
>
> Why?  Is there any other reason beyond WM hints?

Usability.  For example, all terminal emulators does this.

>
>> An exception to this is tiling window managers and fullscreen behaviour.
>
> If we cannot resize in pixels, we cannot make those exceptions, can
> we?

We only need to make Emacs windows be resizable in pixels, not the frame as I 
tried to explain above.

	Jan D.

Previous Next

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