[Top][All Lists]

[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:33:38 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5

2013-04-20 15:38, martin rudalics skrev:
 >> So you will probably have to tell me on which platforms turning off WM
 >> size hints is needed.
 > We should not turn off WM size hints on any platform IMHO.  If we do
 > that, the resize feedback from the window manager shows pixels instead
 > of rows x columns.  The latter is much more useful.  I don't understand
 > why we want to resize in pixels instead of characters.

In order to maximze a frame, for example.  Maybe also just in order to
do what other applications do.  Here, Emacs was the only application
whose window I could not resize pixelwise.  I doubt you can find mamy of
them nowadays.

They are not at all hard to find.  Any terminal emulator does this.
Also, resizing the frame is one thing, and resizing windows are another. The emacs frame is already resizable by pixels, in the sense that it indeed covers the whole screen when made fullscreen. What is missing is windows resizing in pixels. It is that that leads to the partial blank row at the bottom for fullscreen frames.

 > But if you insist on resizing with pixels instead of characters, you
 > have turn WM hints off for NS and X.  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.

I don't have the resources to do that.  Hopefully, someone can step in.
In any case, people can always get the current behavior if they do not
set one of the two variables I mentioned earlier.

 > I'd rather see that text is text.  Fringe and scrollbars should not be
 > included, nor should margins

... currently margins are text ...

Oops, my mistake.  They should be included then.

 > or borders.  Non-text portions should be
 > able to have any width/height in pixels.  This includes the native toolbar.

Currently, we do lots of acrobatics to round such non-text portions.  So
we should decide on what to do here.  And obviously, if all non-text
portions can be sized pixelwise we have to size the remaining text
portion pixelwise as well in order to fit them to the frame size.

Yes, windows, not frame.

 > But I'd prefer if the text part is resizable only in terms of
 > lines/columns. An exception to this is tiling window managers and
 > fullscreen behaviour.

Lines and columns are abstractions that probably get less and less
important with variable width fonts and variable text heights/spacings.

This may be true, but Emacs is after all a text editor, and lines and columns are important. Even general document editors do talk about rows and columns even if they can display images, tables and much more that Emacs can't.

 > So resizing fringes and scrollbars ought to resize the frame.

It currently does not when I set them buffer- and/or window-locally.
And frame-based it doesn't make much sense with two windows
side-by-side: Should I resize the frame by two scrollbar-widths then?

This is a just policy.  Do whatever you think works best.

        Jan D.

reply via email to

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