bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jan Djärv
Subject: bug#14233: 24.3; Don't constrain frame size to character multiples
Date: Sat, 20 Apr 2013 21:26:39 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5

Hello.

2013-04-20 15:13, Eli Zaretskii skrev:
Date: Sat, 20 Apr 2013 14:56:47 +0200
From: Jan Djärv <address@hidden>
CC: Eli Zaretskii <address@hidden>, address@hidden,
  address@hidden

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.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]