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

[E Sabof <esabof@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3264 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4404 bytes --]