bug#14233: 24.3; Don't constrain frame size to character multiples

[Eli Zaretskii]

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