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

[E Sabof]

On Sat, Apr 20, 2013 at 8:26 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:

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@swipnet.se>
CC: Eli Zaretskii <eliz@gnu.org>, esabof@gmail.com,
  14233@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.

I admit not having partial lines has an appeal, at least to me. At the same time I don't enjoy window hinting. 

For columns, the remaining bit could be distributed between margins (if present), and the rightmost edges.

The remaining vertical space could be added below the echo-area/mini-buffer, and would inherit it's fringes and it's background. The distribution option is not acceptable here, as this would suggest that an empty line follows.

 

This shouldn't make a any difference implementation-time-wise, assuming the maximized window, and tiling cases are taken into account.

The downside is that clunky window re-sizing remains. Which I prefer over half-characters, but I suspect some wouldn't.

Evgeni