GNU bug report logs - #14233
24.3; Don't constrain frame size to character multiples

Previous Next

Full log

Message #65 received at 14233 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, esabof <at> gmail.com, 14233 <at> debbugs.gnu.org
Subject: Re: bug#14233: 24.3; Don't constrain frame size to character multiples
Date: Sat, 20 Apr 2013 21:33:38 +0200

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.