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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: rudalics <at> gmx.at, esabof <at> gmail.com, 14233 <at> debbugs.gnu.org
Subject: bug#14233: 24.3; Don't constrain frame size to character multiples
Date: Sat, 20 Apr 2013 22:54:24 +0300

> Date: Sat, 20 Apr 2013 21:26:39 +0200
> From: Jan Djärv <jan.h.d <at> swipnet.se>
> CC: rudalics <at> gmx.at, esabof <at> gmail.com, 14233 <at> debbugs.gnu.org
> 
> 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.

Thanks.

However, does it really make sense to resize in increments of
canonical character size?  The user could have changed the face to be
something else, and even with the default font the "canonical
character"s size is different from many characters of the same font.
So we get partial characters even with character-size increments.

Hmm...  I guess character-size increments of the frame might still
make sense at least in some use cases, because from the user POV, not
every size change is meaningful.  E.g., a user could want to have N
extra lines or columns.  But OTOH, these goals are perfectly
achievable with pixel-unit resizes.  So it's not clear to me what
would be the benefit of keeping character-size increments.

> >> 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.

Terminal emulators generally use a single typeface, so this makes more
sense there.  Also, a terminal emulator must have integer values of
LINES and COLUMNS, as text-mode programs expect that.  Emacs doesn't
have these limitations.

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

That's possible.

Martin, do we have any important use cases beyond fullscreen where
pixel-unit resize of frames is really necessary?

Previous Next

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