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

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

[E Sabof]

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

The limitation makes emacs frames rather clumsy, especially when using
maximization, or some form of tiling. I'd think there would already be a
report on it, as the issue shows up periodically on reddit. I couldn't find
one, so here it is.

Evgeni

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

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

[Glenn Morris]

E Sabof wrote:

> The limitation makes emacs frames rather clumsy, especially when using
> maximization, or some form of tiling. I'd think there would already be a
> report on it, as the issue shows up periodically on reddit. I couldn't find
> one, so here it is.

etc/TODO:

** Remove the limitation that window and frame widths and heights can
  be only full columns/lines.

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

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Fri, 19 Apr 2013 20:17:25 -0400
> Cc: 14233@debbugs.gnu.org
> 
> E Sabof wrote:
> 
> > The limitation makes emacs frames rather clumsy, especially when using
> > maximization, or some form of tiling. I'd think there would already be a
> > report on it, as the issue shows up periodically on reddit. I couldn't find
> > one, so here it is.
> 
> etc/TODO:
> 
> ** Remove the limitation that window and frame widths and heights can
>   be only full columns/lines.

Right.  And I don't think the wording of the problem in both cases is
accurate enough.  There is no such limitation, except in functions
that actually resize the frame/window.  The display engine doesn't
require integral number of character cells.

So, if someone wants to bite the bullet, the way to go is:

  . introduce interfaces to specify frame/window size in pixels

  . in the implementation of those interfaces, round up the sizes in
    column and line units to the integral numbers, so that the glyph
    matrices are large enough

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

[martin rudalics]

 >> ** Remove the limitation that window and frame widths and heights can
 >>   be only full columns/lines.
 >
 > Right.  And I don't think the wording of the problem in both cases is
 > accurate enough.  There is no such limitation, except in functions
 > that actually resize the frame/window.  The display engine doesn't
 > require integral number of character cells.
 >
 > So, if someone wants to bite the bullet, the way to go is:
 >
 >   . introduce interfaces to specify frame/window size in pixels

I'm mostly done with the low-level parts of the implementation.  What
might be lacking is a better interface specification.  So far I have:

- An option `frame-resize-pixelwise' which, when non-nil, passes resize
   requests from the window manager pixelwise to the frame and window
   resizing routines.

- An option `window-resize-pixelwise' which, when non-nil, makes some
   window resize functions (like `adjust-window-trailing-edge' or
   `fit-window-to-buffer') operate pixelwise.

- Functions like `window-resize', `split-window' or `set-frame-size'
   take an optional argument PIXELWISE which means to interpret their
   size/delta/width/height argument pixelwise.

Some issues still deserve discussion:

- The window resize routines work pixelwise although when resizing I
   still try to preserve full lines/columns first and give the remainder
   to one window only.  That is, if I have three windows and 90 pixels
   height to distribute, by default I assign 32, 32 and 26 pixels instead
   of 30 pixels to each.  If you prefer a different solution tell me - I
   have no strong opinion here.

- We currently include a frame's fringe widths and scroll bar widths in
   the frame's pixel width but not in the frame's text width.  This is
   very inconvenient on graphic systems and leads to all sorts of subtle
   bugs like bug#14222.  Do we really care about this distinction or
   could we simply say that specifying a frame's width specifies also the
   width of that frame's root window (minus the internal border width)?

- IIUC we currently do not allow to specify the sizes of display margins
   pixelwise.  Are we interested in lifting this restriction?  We would
   have to invent suitable terms for these.

- We currently round fringe widths (in compute_fringe_widths) and scroll
   bar widths (in x_set_scroll_bar_width) to columns.  Is this still
   desirable or shall this be lifted too?

- The heights of the tool and menubar are specified in lines.  Do we
   intend to change that to pixels?

 >   . in the implementation of those interfaces, round up the sizes in
 >     column and line units to the integral numbers, so that the glyph
 >     matrices are large enough

I tried to do that.  Usually, the display routines are so robust that
hardly anything could ever break them.

martin

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

[Jan Djärv]

Hello.

20 apr 2013 kl. 10:53 skrev martin rudalics <rudalics@gmx.at>:

> >> ** Remove the limitation that window and frame widths and heights can
> >>   be only full columns/lines.
> >
> > Right.  And I don't think the wording of the problem in both cases is
> > accurate enough.  There is no such limitation, except in functions
> > that actually resize the frame/window.  The display engine doesn't
> > require integral number of character cells.
> >
> > So, if someone wants to bite the bullet, the way to go is:
> >
> >   . introduce interfaces to specify frame/window size in pixels
> 
> I'm mostly done with the low-level parts of the implementation.  What
> might be lacking is a better interface specification.  So far I have:
> 
> - An option `frame-resize-pixelwise' which, when non-nil, passes resize
>  requests from the window manager pixelwise to the frame and window
>  resizing routines.
> 
> - An option `window-resize-pixelwise' which, when non-nil, makes some
>  window resize functions (like `adjust-window-trailing-edge' or
>  `fit-window-to-buffer') operate pixelwise.
> 
> - Functions like `window-resize', `split-window' or `set-frame-size'
>  take an optional argument PIXELWISE which means to interpret their
>  size/delta/width/height argument pixelwise.
> 

How does these interact with WM size hints?  Are you turning them off when resizing pixelwise?

> Some issues still deserve discussion:
> 
> - The window resize routines work pixelwise although when resizing I
>  still try to preserve full lines/columns first and give the remainder
>  to one window only.  That is, if I have three windows and 90 pixels
>  height to distribute, by default I assign 32, 32 and 26 pixels instead
>  of 30 pixels to each.  If you prefer a different solution tell me - I
>  have no strong opinion here.
> 
> - We currently include a frame's fringe widths and scroll bar widths in
>  the frame's pixel width but not in the frame's text width.  This is
>  very inconvenient on graphic systems and leads to all sorts of subtle
>  bugs like bug#14222.  Do we really care about this distinction or
>  could we simply say that specifying a frame's width specifies also the
>  width of that frame's root window (minus the internal border width)?

Are you proposing that the width of the scroll bar and the fringe be included in the text width?  You need to explain this better.

> 
> - IIUC we currently do not allow to specify the sizes of display margins
>  pixelwise.  Are we interested in lifting this restriction?  We would
>  have to invent suitable terms for these.
> 
> - We currently round fringe widths (in compute_fringe_widths) and scroll
>  bar widths (in x_set_scroll_bar_width) to columns.  Is this still
>  desirable or shall this be lifted too?
> 
> - The heights of the tool and menubar are specified in lines.  Do we
>  intend to change that to pixels?

This is dependent on the port.  For the Gtk+ port, toolbar and menubar height has no restriction to be in lines.  A value > 0 means "on".  The actual height is not the height of a line, but whatever height the toolkit chooses.

	Jan D.

> 
> >   . in the implementation of those interfaces, round up the sizes in
> >     column and line units to the integral numbers, so that the glyph
> >     matrices are large enough
> 
> I tried to do that.  Usually, the display routines are so robust that
> hardly anything could ever break them.
> 
> martin
> 
> 

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

[Eli Zaretskii]

> Date: Sat, 20 Apr 2013 10:53:52 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: Glenn Morris <rgm@gnu.org>, esabof@gmail.com, 14233@debbugs.gnu.org
> 
>  >> ** Remove the limitation that window and frame widths and heights can
>  >>   be only full columns/lines.
>  >
>  > Right.  And I don't think the wording of the problem in both cases is
>  > accurate enough.  There is no such limitation, except in functions
>  > that actually resize the frame/window.  The display engine doesn't
>  > require integral number of character cells.
>  >
>  > So, if someone wants to bite the bullet, the way to go is:
>  >
>  >   . introduce interfaces to specify frame/window size in pixels
> 
> I'm mostly done with the low-level parts of the implementation.

Thanks.

> - An option `frame-resize-pixelwise' which, when non-nil, passes resize
>    requests from the window manager pixelwise to the frame and window
>    resizing routines.
> 
> - An option `window-resize-pixelwise' which, when non-nil, makes some
>    window resize functions (like `adjust-window-trailing-edge' or
>    `fit-window-to-buffer') operate pixelwise.
> 
> - Functions like `window-resize', `split-window' or `set-frame-size'
>    take an optional argument PIXELWISE which means to interpret their
>    size/delta/width/height argument pixelwise.

Sounds reasonable to me.  It might be a good idea to release this
as-is, and wait for comments and complaints by those who will use
them.

> - The window resize routines work pixelwise although when resizing I
>    still try to preserve full lines/columns first and give the remainder
>    to one window only.  That is, if I have three windows and 90 pixels
>    height to distribute, by default I assign 32, 32 and 26 pixels instead
>    of 30 pixels to each.  If you prefer a different solution tell me - I
>    have no strong opinion here.

I think what's important is to have a way of resizing a specific
window to a specific pixel-size.  What happens to other windows as
result is less important.

> - We currently include a frame's fringe widths and scroll bar widths in
>    the frame's pixel width but not in the frame's text width.  This is
>    very inconvenient on graphic systems and leads to all sorts of subtle
>    bugs like bug#14222.  Do we really care about this distinction or
>    could we simply say that specifying a frame's width specifies also the
>    width of that frame's root window (minus the internal border width)?

The fact that the fringes and the scroll bar are excluded from the
dimensions of the text area sounds correct to me.  Otherwise, it would
be confusing to have non-text portions included in the text area
dimensions, and could lead to subtle bugs due to this mental
dissonance.

What is the relation of these frame dimensions to the frame's root
window, though?  Can we handle the problem on that level, i.e. when
computing window dimensions from frame dimensions?

> - IIUC we currently do not allow to specify the sizes of display margins
>    pixelwise.  Are we interested in lifting this restriction?  We would
>    have to invent suitable terms for these.

Display margins are very rarely used.  I don't recommend enhancing
them without an explicit request and a use case that really requires
that.

> - We currently round fringe widths (in compute_fringe_widths) and scroll
>    bar widths (in x_set_scroll_bar_width) to columns.  Is this still
>    desirable or shall this be lifted too?

Should probably be lifted, but it doesn't have to be part of the
initial change that gets committed.

> - The heights of the tool and menubar are specified in lines.  Do we
>    intend to change that to pixels?

I don't think so: clipping the displayed stuff in these "windows"
doesn't make sense, IMO.  IOW, a tool bar whose icons are only
partially visible is ugly, and I'm not aware of a single application
that does that.  Likewise with the menu bar (only applicable to a
non-toolkit X build, btw).

>  >   . in the implementation of those interfaces, round up the sizes in
>  >     column and line units to the integral numbers, so that the glyph
>  >     matrices are large enough
> 
> I tried to do that.  Usually, the display routines are so robust that
> hardly anything could ever break them.

You should only need to do that where we allocate glyph matrices.

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

[martin rudalics]

 >> - An option `frame-resize-pixelwise' which, when non-nil, passes resize
 >>  requests from the window manager pixelwise to the frame and window
 >>  resizing routines.
[...]
 > How does these interact with WM size hints?  Are you turning them off when resizing pixelwise?

No.  But I've tested this on Windows only where in an initial stage I
did in x_wm_set_size_hint

SetWindowLong (window, WND_FONTWIDTH_INDEX, 1);
SetWindowLong (window, WND_LINEHEIGHT_INDEX, 1);

which worked.  But later I found out that this was not needed - all I
had to do was turning off rounding in the case of WM_WINDOWPOSCHANGING
in w32_wnd_proc.

So you will probably have to tell me on which platforms turning off WM
size hints is needed.

 > Are you proposing that the width of the scroll bar and the fringe be included in the text width?  You need to explain this better.

Yes.  Have you tried the scenario of bug#14222 ?  I think it's a direct
consequence of the dichotomy that OT1H we do want changing fringe widths
affect the size of the frame on the screen but OTOH do not want these
changes to have any impact immediately.

BTW: When the toolbar is part of the frame we do include its height in
the frame's text height (obviously so, because otherwise wrapping the
toolbar would resize the frame) and IIUC we always include margins in
the frame's text width but do refuse to so with fringes and scrollbars.

 > This is dependent on the port.  For the Gtk+ port, toolbar and menubar height has no restriction to be in lines.  A value > 0 means "on".  The actual height is not the height of a line, but whatever height the toolkit chooses.

I know.  I just wanted to know whether we should do that on other ports
as well and how to specify that.

martin

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

[martin rudalics]

 > I think what's important is to have a way of resizing a specific
 > window to a specific pixel-size.  What happens to other windows as
 > result is less important.

There are some subtle issues.  Suppose I now have two adjacent windows
each 200 pixels high.  I have to give these windows suitable line
heights.  Giving them both either 12 lines or 13 lines will break
calculations based on the return values of `window-edges'.  So I have to
give one of these windows 12 lines and the other 13 lines although their
pixel heights are exactly the same.

 > The fact that the fringes and the scroll bar are excluded from the
 > dimensions of the text area sounds correct to me.  Otherwise, it would
 > be confusing to have non-text portions included in the text area
 > dimensions, and could lead to subtle bugs due to this mental
 > dissonance.

But on Windows the toolbar is included in the frame's text height and
sometimes even the menubar is.  And the display margins, whether outside
or inside the fringes, are part of the text width.  Aren't these mental
dissonances as well?

 > Display margins are very rarely used.  I don't recommend enhancing
 > them without an explicit request and a use case that really requires
 > that.

OK

 >> - We currently round fringe widths (in compute_fringe_widths) and scroll
 >>    bar widths (in x_set_scroll_bar_width) to columns.  Is this still
 >>    desirable or shall this be lifted too?
 >
 > Should probably be lifted, but it doesn't have to be part of the
 > initial change that gets committed.

OK

 >> - The heights of the tool and menubar are specified in lines.  Do we
 >>    intend to change that to pixels?
 >
 > I don't think so: clipping the displayed stuff in these "windows"
 > doesn't make sense, IMO.  IOW, a tool bar whose icons are only
 > partially visible is ugly, and I'm not aware of a single application
 > that does that.

I had in mind the case where toolbar elements and borders asked for some
arbitrary pixel height.  IIUC we currently do some rounding there to fit
them into screen line multiples.  Such rounding would not be needed any
more.

It goes without saying that clipping the toolbar doesn't make sense.
Note in this context that on Windows the toolbar is allowed to occupy
the entire frame, obscuring everything else, something we are usually
trying to avoid like the plague.

 > Likewise with the menu bar (only applicable to a
 > non-toolkit X build, btw).
 >
 >>  >   . in the implementation of those interfaces, round up the sizes in
 >>  >     column and line units to the integral numbers, so that the glyph
 >>  >     matrices are large enough
 >>
 >> I tried to do that.  Usually, the display routines are so robust that
 >> hardly anything could ever break them.
 >
 > You should only need to do that where we allocate glyph matrices.

Hopefully.  There are some wrinkles with display areas not getting
cleared appropriately but these existed already with non-pixelwise
resizing.

martin

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

[Eli Zaretskii]

> Date: Sat, 20 Apr 2013 13:01:52 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: rgm@gnu.org, esabof@gmail.com, 14233@debbugs.gnu.org
> 
>  > I think what's important is to have a way of resizing a specific
>  > window to a specific pixel-size.  What happens to other windows as
>  > result is less important.
> 
> There are some subtle issues.  Suppose I now have two adjacent windows
> each 200 pixels high.  I have to give these windows suitable line
> heights.  Giving them both either 12 lines or 13 lines will break
> calculations based on the return values of `window-edges'.

What will break?  Is it possible to avoid the breakage without
imposing arbitrary restrictions on pixel dimensions of windows?

>  > The fact that the fringes and the scroll bar are excluded from the
>  > dimensions of the text area sounds correct to me.  Otherwise, it would
>  > be confusing to have non-text portions included in the text area
>  > dimensions, and could lead to subtle bugs due to this mental
>  > dissonance.
> 
> But on Windows the toolbar is included in the frame's text height and
> sometimes even the menubar is.  And the display margins, whether outside
> or inside the fringes, are part of the text width.  Aren't these mental
> dissonances as well?

No, because a tool bar is just another window (albeit a special one).
As for display margins, they do display text, don't they?

It could be that the fringes are included because of the display
margins outside the fringes configuration (which is the default).  If
that is the case, then perhaps we should leave this alone, although it
feels wrong.

>  >> - The heights of the tool and menubar are specified in lines.  Do we
>  >>    intend to change that to pixels?
>  >
>  > I don't think so: clipping the displayed stuff in these "windows"
>  > doesn't make sense, IMO.  IOW, a tool bar whose icons are only
>  > partially visible is ugly, and I'm not aware of a single application
>  > that does that.
> 
> I had in mind the case where toolbar elements and borders asked for some
> arbitrary pixel height.  IIUC we currently do some rounding there to fit
> them into screen line multiples.  Such rounding would not be needed any
> more.

Well, in that case, just keep this in the wishlist, instead of
rejecting ;-)

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

[Jan Djärv]

Hello.

2013-04-20 13:00, martin rudalics skrev:
>  >> - An option `frame-resize-pixelwise' which, when non-nil, passes resize
>  >>  requests from the window manager pixelwise to the frame and window
>  >>  resizing routines.
> [...]
>  > How does these interact with WM size hints?  Are you turning them off when
> resizing pixelwise?
>
> No.  But I've tested this on Windows only where in an initial stage I
> did in x_wm_set_size_hint
>
> SetWindowLong (window, WND_FONTWIDTH_INDEX, 1);
> SetWindowLong (window, WND_LINEHEIGHT_INDEX, 1);
>
> which worked.  But later I found out that this was not needed - all I
> had to do was turning off rounding in the case of WM_WINDOWPOSCHANGING
> in w32_wnd_proc.
>
> 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.

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.

>
>  > Are you proposing that the width of the scroll bar and the fringe be
> included in the text width?  You need to explain this better.
>
> Yes.  Have you tried the scenario of bug#14222 ?  I think it's a direct
> consequence of the dichotomy that OT1H we do want changing fringe widths
> affect the size of the frame on the screen but OTOH do not want these
> changes to have any impact immediately.
>
> BTW: When the toolbar is part of the frame we do include its height in
> the frame's text height (obviously so, because otherwise wrapping the
> toolbar would resize the frame) and IIUC we always include margins in
> the frame's text width but do refuse to so with fringes and scrollbars.

I'd rather see that text is text.  Fringe and scrollbars should not be 
included, nor should margins or borders.  Non-text portions should be able to 
have any width/height in pixels.  This includes the native toolbar.

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.

So resizing fringes and scrollbars ought to resize the frame.

>
>  > This is dependent on the port.  For the Gtk+ port, toolbar and menubar
> height has no restriction to be in lines.  A value > 0 means "on".  The actual
> height is not the height of a line, but whatever height the toolkit chooses.
>
> I know.  I just wanted to know whether we should do that on other ports
> as well and how to specify that.

IMHO we should do that on all ports.

	Jan D.

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

[Eli Zaretskii]

> 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.

> 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.

> 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?

> An exception to this is tiling window managers and fullscreen behaviour.

If we cannot resize in pixels, we cannot make those exceptions, can
we?

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

[martin rudalics]

 >> There are some subtle issues.  Suppose I now have two adjacent windows
 >> each 200 pixels high.  I have to give these windows suitable line
 >> heights.  Giving them both either 12 lines or 13 lines will break
 >> calculations based on the return values of `window-edges'.
 >
 > What will break?

It will break tests for adjacency of windows based on checking whether
the bottom/right edge of a window equals the top/left edge of another
window.

 > Is it possible to avoid the breakage without
 > imposing arbitrary restrictions on pixel dimensions of windows?

One can check whether pixel-edges are equal.  In any case, if we want
pixelwise resizing, there can't be any restrictions on window sizes.

 >> But on Windows the toolbar is included in the frame's text height and
 >> sometimes even the menubar is.  And the display margins, whether outside
 >> or inside the fringes, are part of the text width.  Aren't these mental
 >> dissonances as well?
 >
 > No, because a tool bar is just another window (albeit a special one).

Which usually doesn't display text.  Also the frame's internal border is
drawn in between toolbar and the frame's root window, so the frame's
text area is not necessarily contiguous vertically.  Dissonant IMHO.

 > As for display margins, they do display text, don't they?

IIUC they could display anything fringes can display - I don't see the
basic difference.  And, as you say below, they are drawn by default
outside the fringes (probably because otherwise continuation glyphs
would be too far away) so the frame's text area is not necessarily
horizontally contiguous either.  Very dissonant IMHO.

 > It could be that the fringes are included because of the display
 > margins outside the fringes configuration (which is the default).

I'm missing you here.  The default is to draw, in this order, a
scrollbar which is not part of the text area, a margin which is part of
the text area, a fringe which is not, the window proper which is, ...

 > If
 > that is the case, then perhaps we should leave this alone, although it
 > feels wrong.

I'd tend to say that we could make life easier for those who want to
position two Emacs frames on screen in some accordance (look at the
tribulations of `dframe-reposition-frame-emacs', for example).  All this
"a frame's width is the width of its text area" stuff is only a
hindrance in this regard.

BTW, I've never been able to understand the manuals and doc-strings in
this regard.  Consider the doc-string of `set-frame-width': "Specify
that the frame FRAME has COLS columns."  Or its manual entry: "This
function sets the width of FRAME, measured in characters."

martin

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

[martin rudalics]

 >> 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.

 > 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 ...

 > 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.

 > 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.

 > 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?

 >> I know.  I just wanted to know whether we should do that on other ports
 >> as well and how to specify that.
 >
 > IMHO we should do that on all ports.

Maybe.

martin

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

[Drew Adams]

> I'd rather see that text is text.  Fringe and scrollbars 
> should not be included, nor should margins or borders.
> Non-text portions should be able to have any width/height
> in pixels.  This includes the native toolbar.
> 
> 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.

There are other exceptions too, besides tiling WMs and fullscreen.  The "text"
area can include images, boxed text (which can increase the apparent char
height/width), fonts of different sizes in the same line, and various other
display artifacts/properties.

IOW, "Text" and the text area are not just about lines and columns anymore, at
least when it comes to resizing a window or frame to fit it.

Users should be able to calculate the needed "text" area to display a given
buffer portion well (i.e. to fit it).

It is good to keep each area of a frame and window separate in terms of its
treatment (toolbar, menu-bar, fringe, text area, etc.).  Users (and higher-level
predefined functions) can then combine them as needed when calculating the
desired size etc.

IOW, let programmers deal with each such area individually when they need to.
If possible, do not give them just an overall knob to turn and force them to
rely upon Emacs to juggle all of the parts well and make a good compromise
automatically under the covers.

For a given application it _could_ make sense to privilege the display of the
first or last text line's height fully and sacrifice a couple pixels from the
full height of a toolbar or a fringe or whatever.

Emacs can provide good overall compromises, but it is still good to give users
control over the combining for the cases where they need it.

Perhaps (dunno) even give users functions/parameters to let them explicitly pad
chosen display areas with "extra" pixels and trim pixels from other display
areas.  IOW, the kinds of thing that you might be doing automatically to make
things work right.  That would not be the first thing they would do, but it
might still be useful to be able to do.  Dunno.

----

FWIW, I have not followed this thread well, but I will probably be interested in
the outcome.

Another meta-comment would be that this project is bound to be difficult,
perhaps long, and involve some compromises.  Let's try to attack it
progressively, in stages.  A goal should remain that we not break what works now
(the line/column sizing etc.) as we advance.  (Preaching to the choir, no
doubt.)

Thanks for working on this.

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

[Eli Zaretskii]

> Date: Sat, 20 Apr 2013 15:38:50 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: rgm@gnu.org, esabof@gmail.com, 14233@debbugs.gnu.org
> 
>  >> There are some subtle issues.  Suppose I now have two adjacent windows
>  >> each 200 pixels high.  I have to give these windows suitable line
>  >> heights.  Giving them both either 12 lines or 13 lines will break
>  >> calculations based on the return values of `window-edges'.
>  >
>  > What will break?
> 
> It will break tests for adjacency of windows based on checking whether
> the bottom/right edge of a window equals the top/left edge of another
> window.
> 
>  > Is it possible to avoid the breakage without
>  > imposing arbitrary restrictions on pixel dimensions of windows?
> 
> One can check whether pixel-edges are equal.

Yes, I think that's a better solution for that.

>  >> But on Windows the toolbar is included in the frame's text height and
>  >> sometimes even the menubar is.  And the display margins, whether outside
>  >> or inside the fringes, are part of the text width.  Aren't these mental
>  >> dissonances as well?
>  >
>  > No, because a tool bar is just another window (albeit a special one).
> 
> Which usually doesn't display text.

Windows in Emacs can display images as well, and that's exactly what
the tool bar window does, see redisplay_tool_bar.  It displays text
with display properties that specify images.

> Also the frame's internal border is drawn in between toolbar and the
> frame's root window

At least on MS-Windows, I see no border.  Or perhaps I don't know what
to look for.

>  > As for display margins, they do display text, don't they?
> 
> IIUC they could display anything fringes can display

No.  Fringes can only display bitmaps.  The cannot display text or
images that we support in the text area or on margins.

>  > It could be that the fringes are included because of the display
>  > margins outside the fringes configuration (which is the default).
> 
> I'm missing you here.

I'm trying to think why the fringes were included.  It is possible
that the reasons were practical rather then anything else.  Like the
desire to have the text area contiguous.

> All this "a frame's width is the width of its text area" stuff is
> only a hindrance in this regard.

I was not arguing in favor of it.  If you want to change that, I'm not
going to object.

> BTW, I've never been able to understand the manuals and doc-strings in
> this regard.  Consider the doc-string of `set-frame-width': "Specify
> that the frame FRAME has COLS columns."  Or its manual entry: "This
> function sets the width of FRAME, measured in characters."

What's wrong with those?

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sat, 20 Apr 2013 09:22:05 -0700
> Cc: esabof@gmail.com, 14233@debbugs.gnu.org
> 
> There are other exceptions too, besides tiling WMs and fullscreen.  The "text"
> area can include images, boxed text (which can increase the apparent char
> height/width), fonts of different sizes in the same line, and various other
> display artifacts/properties.

Yes.  But there are no problems with that, and it is unrelated to this
discussion.

> IOW, "Text" and the text area are not just about lines and columns anymore, at
> least when it comes to resizing a window or frame to fit it.

"Lines and columns" are just units of measurement in the context of
this discussion.  No one is saying that Emacs should be able to
display only integral number of characters and lines; that restriction
was removed in Emacs 21, and no one would even dream about going back.

> Users should be able to calculate the needed "text" area to display a given
> buffer portion well (i.e. to fit it).

Users cannot calculate that, because the dimensions of the images and
even characters of non-default fonts are not exposed to Lisp.  Lisp
programs can only guess what the required dimensions will be.  In
"normal" windows that display some buffer, you could perhaps use
posn-at-point and such to find some approximation, but in special
windows like the tool bar you cannot do even that (because they are
produced from strings, not from some buffer, and those strings are
constructed internally by the display engine and not accessible from
Lisp).  And with some modern toolkits, the tool bar is not even built
by Emacs.

The character units dimensions discussed here are for the "canonical"
characters, which means _some_ character from the frame's default
face's font.

IOW, I cannot possibly see how your comments are related to what is
being discussed here.

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

[martin rudalics]

 >> One can check whether pixel-edges are equal.
 >
 > Yes, I think that's a better solution for that.

But we also should try to not break code outside our code base.

 >> Also the frame's internal border is drawn in between toolbar and the
 >> frame's root window
 >
 > At least on MS-Windows, I see no border.  Or perhaps I don't know what
 > to look for.

With emacs -Q try

(set-frame-parameter (selected-frame) 'internal-border-width 12)

 >>  > As for display margins, they do display text, don't they?
 >>
 >> IIUC they could display anything fringes can display
 >
 > No.  Fringes can only display bitmaps.  The cannot display text or
 > images that we support in the text area or on margins.

Yes.  But I meant that display margins can display images and bitmaps as
well.  Or am I missing something?

 > I'm trying to think why the fringes were included.  It is possible
 > that the reasons were practical rather then anything else.  Like the
 > desire to have the text area contiguous.

With the default they fail precisely in this regard.

 >> BTW, I've never been able to understand the manuals and doc-strings in
 >> this regard.  Consider the doc-string of `set-frame-width': "Specify
 >> that the frame FRAME has COLS columns."  Or its manual entry: "This
 >> function sets the width of FRAME, measured in characters."
 >
 > What's wrong with those?

That they never explain what the "width of a frame" is.  The best
explanation I could find is

http://www.xemacs.org/Documentation/21.5/html/internals_29.html#SEC275

(in particular section 29.7 "The Displayable Area") but it still lacks
an explanation of frame fringe widths (maybe because XEmacs doesn't have
them).

martin

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

[E Sabof]

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

> >>  > As for display margins, they do display text, don't they?
> >>
> >> IIUC they could display anything fringes can display
> >
> > No.  Fringes can only display bitmaps.  The cannot display text or
> > images that we support in the text area or on margins.
>
> Yes.  But I meant that display margins can display images and bitmaps as
> well.  Or am I missing something?


There are also organizational issues. If one wants both line
numbers, and crosses for error lines, he can use one mode for the
first, and another for the second. If there were only margins,
there would be more competition between modes.

Evgeni

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

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

[Eli Zaretskii]

> Date: Sat, 20 Apr 2013 19:35:18 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: rgm@gnu.org, esabof@gmail.com, 14233@debbugs.gnu.org
> 
>  >> One can check whether pixel-edges are equal.
>  >
>  > Yes, I think that's a better solution for that.
> 
> But we also should try to not break code outside our code base.

To some point, yes.  But in this case, I think there's no other way.
Or maybe introduce new APIs for pixel-unit resizing.

>  >> Also the frame's internal border is drawn in between toolbar and the
>  >> frame's root window
>  >
>  > At least on MS-Windows, I see no border.  Or perhaps I don't know what
>  > to look for.
> 
> With emacs -Q try
> 
> (set-frame-parameter (selected-frame) 'internal-border-width 12)

But that just proves that I was right: a tool bar is just another
window, so its size should be included in the frame's text height.
What am I missing?  What is exactly that we are disagreeing about
here?

>  >>  > As for display margins, they do display text, don't they?
>  >>
>  >> IIUC they could display anything fringes can display
>  >
>  > No.  Fringes can only display bitmaps.  The cannot display text or
>  > images that we support in the text area or on margins.
> 
> Yes.  But I meant that display margins can display images and bitmaps as
> well.

The fringes can display _only_ bitmaps.  No text or images of other
formats.

>  >> BTW, I've never been able to understand the manuals and doc-strings in
>  >> this regard.  Consider the doc-string of `set-frame-width': "Specify
>  >> that the frame FRAME has COLS columns."  Or its manual entry: "This
>  >> function sets the width of FRAME, measured in characters."
>  >
>  > What's wrong with those?
> 
> That they never explain what the "width of a frame" is.

Of course, they do.  Which part of "width of FRAME, measured in
characters" is unclear?

> The best explanation I could find is
> 
> http://www.xemacs.org/Documentation/21.5/html/internals_29.html#SEC275
> 
> (in particular section 29.7 "The Displayable Area") but it still lacks
> an explanation of frame fringe widths (maybe because XEmacs doesn't have
> them).

XEmacs has an entirely different display engine, developed
independently and with somewhat different goals.

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

[Jan Djärv]

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.

>
>> 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.

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

[Jan Djärv]

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.

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

[Eli Zaretskii]

> Date: Sat, 20 Apr 2013 21:26:39 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: rudalics@gmx.at, esabof@gmail.com, 14233@debbugs.gnu.org
> 
> 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.

Thanks.

However, does it really make sense to resize in increments of
canonical character size?  The user could have changed the face to be
something else, and even with the default font the "canonical
character"s size is different from many characters of the same font.
So we get partial characters even with character-size increments.

Hmm...  I guess character-size increments of the frame might still
make sense at least in some use cases, because from the user POV, not
every size change is meaningful.  E.g., a user could want to have N
extra lines or columns.  But OTOH, these goals are perfectly
achievable with pixel-unit resizes.  So it's not clear to me what
would be the benefit of keeping character-size increments.

> >> 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.

Terminal emulators generally use a single typeface, so this makes more
sense there.  Also, a terminal emulator must have integer values of
LINES and COLUMNS, as text-mode programs expect that.  Emacs doesn't
have these limitations.

> We only need to make Emacs windows be resizable in pixels, not the frame as I 
> tried to explain above.

That's possible.

Martin, do we have any important use cases beyond fullscreen where
pixel-unit resize of frames is really necessary?

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

[E Sabof]

[-- 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 --]

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

[Drew Adams]

> Yes.  But there are no problems with that, and it is unrelated to this
> discussion.
> 
> > IOW, "Text" and the text area are not just about lines and 
> > columns anymore, at least when it comes to resizing a window
> > or frame to fit it.
> 
> "Lines and columns" are just units of measurement in the context of
> this discussion.  No one is saying that Emacs should be able to
> display only integral number of characters and lines; that restriction
> was removed in Emacs 21, and no one would even dream about going back.

> IOW, I cannot possibly see how your comments are related to what is
> being discussed here.

If this is not at all related to being able to compute/determine the actual
pixel size of various buffer/window/frame areas, in particular the "text" area,
then please excuse the interruption.

But if it does concern that, at least in part, then please reread my post.

You seem to be saying that such problems were solved long ago (Emacs 21, no
less).  But no, it is an open enhancement request to be able to compute the
buffer "text" area size in pixels, as _displayed_ (in order, e.g., to fit a
window/frame to it).

See, for example:

http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00323.html

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7822

Again, apologies if this in fact has nothing to do with the current thread.  I
thought it did (and still think it does, so far - but you will please set me
straight).

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

[Drew Adams]

> Martin, do we have any important use cases beyond fullscreen where
> pixel-unit resize of frames is really necessary?

Tiling frames?  Fitting a frame to an image that is the only thing in a buffer?
Fitting a frame to a buffer containing text of different size faces and inline
images and various `display' property thingies and...?

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

[Stefan Monnier]

> Martin, do we have any important use cases beyond fullscreen where
> pixel-unit resize of frames is really necessary?

Most of my frames are "fullheight".  So that's one important use case
for me.  Furthermore I put it in quotes because they don't actually cover
the whole height of the screen (due to the presence of other elements at
the top/bottom of my screens that I don't want to overlap).

I generally end up "rounding down", so it's mostly a question of
"wasting a few pixels".  IOW it's not a really big deal (which is why
I never even considered looking into fixing this issue), but I'd
appreciate pixel-precise sizing of my frames.


        Stefan

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

[Jan Djärv]

Hello.

21 apr 2013 kl. 05:40 skrev Stefan Monnier <monnier@iro.umontreal.ca>:

>> Martin, do we have any important use cases beyond fullscreen where
>> pixel-unit resize of frames is really necessary?
> 
> Most of my frames are "fullheight".  So that's one important use case
> for me.  Furthermore I put it in quotes because they don't actually cover
> the whole height of the screen (due to the presence of other elements at
> the top/bottom of my screens that I don't want to overlap).
> 
> I generally end up "rounding down", so it's mostly a question of
> "wasting a few pixels".  IOW it's not a really big deal (which is why
> I never even considered looking into fixing this issue), but I'd
> appreciate pixel-precise sizing of my frames.

Wouldn't you rather have pixel-sizing of windows so those wasted pixels are not wasted?

	Jan D.

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

[martin rudalics]

 >> With emacs -Q try
 >>
 >> (set-frame-parameter (selected-frame) 'internal-border-width 12)
 >
 > But that just proves that I was right:

There was nothing to prove.  You're always right ;-)

 > a tool bar is just another
 > window, so its size should be included in the frame's text height.
 > What am I missing?  What is exactly that we are disagreeing about
 > here?

OK.  But if the criterion to count something in the text height is that
of being "just another window", we shouldn't include the display margins
in the text width.

 > Which part of "width of FRAME, measured in
 > characters" is unclear?

A frame, according to the Elisp manual, is a screen object that contains
one or more Emacs windows.  When with emacs -Q I evaluate (frame-width)
and (window-width) I get the values 80.  If I split the window into two
side-by-side windows (frame-width) still evaluates to 80, but for both
emanating windows (window-width) evaluates to 38.  Somehow 4 characters
got lost in a black hole.  And bug#14222 demonstrates that Emacs itself
sometimes doesn't understand its own nomenclature.

 > XEmacs has an entirely different display engine, developed
 > independently and with somewhat different goals.

Yet it's the most accurate description of an Emacs frame I could find.

martin

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

[martin rudalics]

 > 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.

At least for the window manager of Windos XP this is not true.

 > 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.

Again with Windows XP resizing an Emacs frame shows the new sizes
pixelwise.  Only when releasing the mouse button the frame snaps back to
its previous size unless I made it beyond the character size barrier.
But in this case it's just Emacs not honoring the WM's request.

 > 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.

Can you explain what the base width/height is?  Something like a minimum
size?

 > 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.

A minimum size for what?

 > Note that for fullscreen, the WM does not keep this invariant, nor does
 > tiling window managers.

What about maximized frames?

 > 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.

 From the Emacs POV this is easy: I could accept `frame-resize-pixelwise'
being a list that enumerates all WM operations that should be
interpreted pixelwise and have t stand for "all are pixelwise" and nil
for "none are".  The problem is that IIUC a maximize frame request
should be interpreted pixelwise but comes in just as a plain resize
request.  What are your experiences in this regard?  How does ns do
that?

 > 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 agree with you.  But we should make them customizable.

 >>> 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.

OK.  But this should not impede us from providing an adequate graphical
implementation.

 >>> 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.

Tiling, fullscreen and maximization requests are all incarnations of
pixelwise resizing of frames.  How else would you call them?

martin

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

[martin rudalics]

 > Hmm...  I guess character-size increments of the frame might still
 > make sense at least in some use cases, because from the user POV, not
 > every size change is meaningful.  E.g., a user could want to have N
 > extra lines or columns.  But OTOH, these goals are perfectly
 > achievable with pixel-unit resizes.  So it's not clear to me what
 > would be the benefit of keeping character-size increments.

As explained earlier, I still keep character-size increments for window
based resizing.  When resizing a window combination I give all windows
but at most one a multiple of the default character size.

 > Martin, do we have any important use cases beyond fullscreen where
 > pixel-unit resize of frames is really necessary?

We have three use cases: Requests from tiling WMs, maximization requests
which leave the taskbar visible and are triggered, for example, when the
taskbar gets resized or auto-hidden, and fullscreen requests which ask
for hiding everything else.  IIUC the most common ones are maximization
requests.

martin

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

[martin rudalics]

 > You seem to be saying that such problems were solved long ago (Emacs 21, no
 > less).  But no, it is an open enhancement request to be able to compute the
 > buffer "text" area size in pixels, as _displayed_ (in order, e.g., to fit a
 > window/frame to it).

I suppose you mean to (1) compute the area size in pixels as displayed
and (2) pixelwise fit the window/frame to it.  This is indeed what I'm
doing here.

martin

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

[martin rudalics]

 > Most of my frames are "fullheight".  So that's one important use case
 > for me.  Furthermore I put it in quotes because they don't actually cover
 > the whole height of the screen (due to the presence of other elements at
 > the top/bottom of my screens that I don't want to overlap).

Are they fullheight because of WM requests or do you resize them
yourself?  How do you get the height of those "other elements "?

martin

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

[martin rudalics]

 >> I generally end up "rounding down", so it's mostly a question of
 >> "wasting a few pixels".  IOW it's not a really big deal (which is why
 >> I never even considered looking into fixing this issue), but I'd
 >> appreciate pixel-precise sizing of my frames.
 >
 > Wouldn't you rather have pixel-sizing of windows so those wasted pixels are not wasted?

How would he do that in the first place if the frame doesn't get resized
pixelwise?

martin

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

[Eli Zaretskii]

> Date: Sun, 21 Apr 2013 11:26:10 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: rgm@gnu.org, esabof@gmail.com, 14233@debbugs.gnu.org
> 
>  > a tool bar is just another
>  > window, so its size should be included in the frame's text height.
>  > What am I missing?  What is exactly that we are disagreeing about
>  > here?
> 
> OK.  But if the criterion to count something in the text height is that
> of being "just another window", we shouldn't include the display margins
> in the text width.

Display margins are certainly a part of window text.

>  > Which part of "width of FRAME, measured in
>  > characters" is unclear?
> 
> A frame, according to the Elisp manual, is a screen object that contains
> one or more Emacs windows.  When with emacs -Q I evaluate (frame-width)
> and (window-width) I get the values 80.  If I split the window into two
> side-by-side windows (frame-width) still evaluates to 80, but for both
> emanating windows (window-width) evaluates to 38.  Somehow 4 characters
> got lost in a black hole.  And bug#14222 demonstrates that Emacs itself
> sometimes doesn't understand its own nomenclature.

So you are saying that the doc strings leave a lot in the fog, I
guess.

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

[Drew Adams]

>  > You seem to be saying that such problems were solved long 
>  > ago (Emacs 21, no less).  But no, it is an open enhancement
>  > request to be able to compute the buffer "text" area size
>  > in pixels, as _displayed_ (in order, e.g., to fit a
>  > window/frame to it).
> 
> I suppose you mean to (1) compute the area size in pixels as displayed
> and (2) pixelwise fit the window/frame to it.  This is indeed what I'm
> doing here.

Yes.  I think (still) that my posts here have been appropriate for this thread.
If I learn otherwise then I will excuse myself for being off-topic.

I have code (in fit-frame.el) that tries to fit frames to their displayed
buffers, typically one buffer per frame.  It currently does not (cannot) take
into account the kinds of things I mentioned, which amount to all the various
ways in which what is displayed in the buffer ("text" area) cannot be modeled
exactly by just knowing the number of text lines, the frame char size, and the
maximum line length.

The fit-frame code takes into account the screen real estate used for things
like a toolbar and menu bar, but it does not yet take into account the buffer
"text" _as displayed_.  That is what the enhancement request in bug #7822 is
about.  And AFAICT it is also partly what this bug (#14233) is about.

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

[Jan Djärv]

21 apr 2013 kl. 11:28 skrev martin rudalics <rudalics@gmx.at>:

> >> I generally end up "rounding down", so it's mostly a question of
> >> "wasting a few pixels".  IOW it's not a really big deal (which is why
> >> I never even considered looking into fixing this issue), but I'd
> >> appreciate pixel-precise sizing of my frames.
> >
> > Wouldn't you rather have pixel-sizing of windows so those wasted pixels are not wasted?
> 
> How would he do that in the first place if the frame doesn't get resized
> pixelwise?

As I explained earlier, when the window managers maximizes, fullscreen:s or tiles Emacs frames, the size hint is ignored, so the frame is sized pixelwise, in the sense that the frame size is not an integer multiple of the character size.  But the fraction that isn't a full character size gets wasted, because windows (in Emacs terms) can not resie pixelwise.

	Jan D.

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

[Jan Djärv]

Hello.

21 apr 2013 kl. 11:26 skrev martin rudalics <rudalics@gmx.at>:

> > 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.
> 
> At least for the window manager of Windos XP this is not true.

That is why testing this on anything but X11 gives the wrong impression on how things work.

> 
> > 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.
> 
> Again with Windows XP resizing an Emacs frame shows the new sizes
> pixelwise.  Only when releasing the mouse button the frame snaps back to
> its previous size unless I made it beyond the character size barrier.
> But in this case it's just Emacs not honoring the WM's request.
> 
> > 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.
> 
> Can you explain what the base width/height is?  Something like a minimum
> size?

Sort of a minimu size if we would have zero columns and lines.

> 
> > 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.
> 
> A minimum size for what?

A minimum size for the frame.  We do say that the minimum frame is one line and one column, but it could be anthing.  We could say that the minimum size is 5 rows and 14 coulmns, or whatever we choose.  The WM will then not shrink the window below this.

> 
> > Note that for fullscreen, the WM does not keep this invariant, nor does
> > tiling window managers.
> 
> What about maximized frames?

Not for that either.

> 
> > 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.
> 
> From the Emacs POV this is easy: I could accept `frame-resize-pixelwise'
> being a list that enumerates all WM operations that should be
> interpreted pixelwise and have t stand for "all are pixelwise" and nil
> for "none are".  The problem is that IIUC a maximize frame request
> should be interpreted pixelwise but comes in just as a plain resize
> request.  What are your experiences in this regard?  How does ns do
> that?
> 

For NS a maximized and fullscreen requests comes in as separate requests, for X they are normal resize request.

The problem is that you think from the W32 point of view where (if I interepret you correctly), Emacs applies size hints after the resize request has been delivered.

This is not so for NS and X.  Any size in a resize request is accepted.  If it follows WM size hints, great, if it don't, who cares?.  The frame size is set to the size in the request anyway.

So for NS and X, fullscreen, maximized and such is no problem.  A minor glitch in NS is that we calculate the maximized sizes ourself, and these are rounded to character sizes.  If windows could handle pixel sizes, we could easily fix this.

> > 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 agree with you.  But we should make them customizable.
> 
> >>> 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.
> 
> OK.  But this should not impede us from providing an adequate graphical
> implementation.
> 
> >>> 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.
> 
> Tiling, fullscreen and maximization requests are all incarnations of
> pixelwise resizing of frames.  How else would you call them?

But there is no restriction on NS and X11 frames to resize by pixel (i.e. not character multiples).  We do that already.  The bug reports we get usually concern when we don't adhere to WM size hints, like fullscreen.  Then there are wasted pixels, becaue windows can't resize pixelwise.
That is where the restriction is.

	Jan D.

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

[Jan Djärv]

Hello.
21 apr 2013 kl. 11:26 skrev martin rudalics <rudalics@gmx.at>:

> A frame, according to the Elisp manual, is a screen object that contains
> one or more Emacs windows.  When with emacs -Q I evaluate (frame-width)
> and (window-width) I get the values 80.  If I split the window into two
> side-by-side windows (frame-width) still evaluates to 80, but for both
> emanating windows (window-width) evaluates to 38.  Somehow 4 characters
> got lost in a black hole.  And bug#14222 demonstrates that Emacs itself
> sometimes doesn't understand its own nomenclature.

If I split in 2 I get window-size 37.  If I remove fringes I get 40.
If I remove scrollbars, I get frame-size 83, and window-size 41.
So one character is lost somewhere.

This is a mess, and needs clearing up.  I suspect differences between ports exist.
Maybe the best is to define how things ought to be and then fix the ports, rather than look at the current implementation(s).
 
	Jan D.

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

[martin rudalics]

 > So you are saying that the doc strings leave a lot in the fog, I
 > guess.

Deliberately so, I think.  Apparently, nobody knows how Emacs behaves or
should behave in this regard.

martin

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

[martin rudalics]

 >> How would he do that in the first place if the frame doesn't get resized
 >> pixelwise?
 >
 > As I explained earlier, when the window managers maximizes,
 > fullscreen:s or tiles Emacs frames, the size hint is ignored, so the
 > frame is sized pixelwise, in the sense that the frame size is not an
 > integer multiple of the character size.  But the fraction that isn't a
 > full character size gets wasted, because windows (in Emacs terms) can
 > not resie pixelwise.

Maybe we have different conceptions of Stefan's use case then.  He said
"I'd appreciate pixel-precise sizing of my frames" but maybe this just
refers to the fact that these pixels stay at the bottom of the correctly
sized frame.

martin

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

[martin rudalics]

 > For NS a maximized and fullscreen requests comes in as separate
 > requests, for X they are normal resize request.
[...]
 > The problem is that you think from the W32 point of view where (if I
 > interepret you correctly), Emacs applies size hints after the resize
 > request has been delivered.

I think so.

 > This is not so for NS and X.  Any size in a resize request is
 > accepted.  If it follows WM size hints, great, if it don't, who
 > cares?.  The frame size is set to the size in the request anyway.

IIUC we do care because we want to fit the frame's windows according to
the incoming request.

 > So for NS and X, fullscreen, maximized and such is no problem.  A
 > minor glitch in NS is that we calculate the maximized sizes ourself,
 > and these are rounded to character sizes.  If windows could handle
 > pixel sizes, we could easily fix this.

In any case, the maximized size of the frame is not necessarily an
integral multiple of character sizes so the frame gets or should get
resized pixelwise.

 > But there is no restriction on NS and X11 frames to resize by pixel
 > (i.e. not character multiples).

So by default, on Windows I always accept a maximize request and resize
windows accordingly.  For any other size request I process a non-rounded
size iff the variable `frame-resize-pixelwise' is non-nil.

On all other platforms, `frame-resize-pixelwise' has no impact.  If and
whether size hints are turned on and have any impact depends on settings
for the window manager used and is of no concern to me.  Whatever size
is requested by the WM is processed without any rounding.

The interface to the window subsystem will be the function

change_frame_size (struct frame *f, int new_width, int new_height,
		   bool pretend, bool delay, bool safe, bool pixelwise)

which processes new_width and new_height in terms of pixels if pixelwise
is non-nil.

martin

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

[martin rudalics]

 > If I split in 2 I get window-size 37.  If I remove fringes I get 40.

How do you "remove fringes"?  There are at least three ways to do that.

 > If I remove scrollbars, I get frame-size 83, and window-size 41.

How do you "remove scrollbars"?

 > So one character is lost somewhere.

I suppose it's used for the vertical divider.

martin

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

[Jan Djärv]

Hello.

22 apr 2013 kl. 11:34 skrev martin rudalics <rudalics@gmx.at>:

> > For NS a maximized and fullscreen requests comes in as separate
> > requests, for X they are normal resize request.
> [...]
> > The problem is that you think from the W32 point of view where (if I
> > interepret you correctly), Emacs applies size hints after the resize
> > request has been delivered.
> 
> I think so.
> 
> > This is not so for NS and X.  Any size in a resize request is
> > accepted.  If it follows WM size hints, great, if it don't, who
> > cares?.  The frame size is set to the size in the request anyway.
> 
> IIUC we do care because we want to fit the frame's windows according to
> the incoming request.

In the future, yes, but we can't resize windows pixelwise yet.

> 
> > So for NS and X, fullscreen, maximized and such is no problem.  A
> > minor glitch in NS is that we calculate the maximized sizes ourself,
> > and these are rounded to character sizes.  If windows could handle
> > pixel sizes, we could easily fix this.
> 
> In any case, the maximized size of the frame is not necessarily an
> integral multiple of character sizes so the frame gets or should get
> resized pixelwise.

We don't do that now because we can't resize windows pixelwise yet.

> 
> > But there is no restriction on NS and X11 frames to resize by pixel
> > (i.e. not character multiples).
> 
> So by default, on Windows I always accept a maximize request and resize
> windows accordingly.  For any other size request I process a non-rounded
> size iff the variable `frame-resize-pixelwise' is non-nil.
> 
> On all other platforms, `frame-resize-pixelwise' has no impact.  If and
> whether size hints are turned on and have any impact depends on settings
> for the window manager used and is of no concern to me.  Whatever size
> is requested by the WM is processed without any rounding.
> 
> The interface to the window subsystem will be the function
> 
> change_frame_size (struct frame *f, int new_width, int new_height,
> 		   bool pretend, bool delay, bool safe, bool pixelwise)
> 
> which processes new_width and new_height in terms of pixels if pixelwise
> is non-nil.
> 

This is insane. it means changing lots and lots of calls, and makes merging between branches harder.
Make a new function (change_frame_size_pixelwise for example), with the arguments above, and let change_frame_size call it with the last argument false.

	Jan D.

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

[Jan Djärv]

Hello.

22 apr 2013 kl. 11:34 skrev martin rudalics <rudalics@gmx.at>:

> > If I split in 2 I get window-size 37.  If I remove fringes I get 40.
> 
> How do you "remove fringes"?  There are at least three ways to do that.

Menu bar, options show.

> 
> > If I remove scrollbars, I get frame-size 83, and window-size 41.
> 
> How do you "remove scrollbars"?
> 

Menu bar, options show.

> > So one character is lost somewhere.
> 
> I suppose it's used for the vertical divider.
> 

That is not so, the divider is just a one pixel wide line.

	Jan D.

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

[Stefan Monnier]

> Wouldn't you rather have pixel-sizing of windows so those wasted
> pixels are not wasted?

Of course, I also want pixel sizing of windows, but that wouldn't help
me much without pixel sizing of frames: my window manager does not
force the frame size to be "fullheight" (and indeed, while they are
fullheight in a sense, the window manager I use doesn't have the needed
info to be able to understand it).


        Stefan

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

[martin rudalics]

 >> The interface to the window subsystem will be the function
 >>
 >> change_frame_size (struct frame *f, int new_width, int new_height,
 >> 		   bool pretend, bool delay, bool safe, bool pixelwise)
 >>
 >> which processes new_width and new_height in terms of pixels if pixelwise
 >> is non-nil.

I meant 1 here.

 > This is insane. it means changing lots and lots of calls, and makes merging between branches harder.

Currently, change_frame_size doesn't know anything about the various
platforms' requirements going beyond those of the frame's text area.

 > Make a new function (change_frame_size_pixelwise for example), with the arguments above, and let change_frame_size call it with the last argument false.

And how would change_frame_size know what the new pixel dimensions of
the frame's text area are?

martin

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

[martin rudalics]

 >> I suppose it's used for the vertical divider.
 >>
 >
 > That is not so, the divider is just a one pixel wide line.

IIUC the vertical divider counts as a one character wide column.

martin

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

[Jan Djärv]

Hello. 


22 apr 2013 kl. 17:36 skrev martin rudalics <rudalics@gmx.at>:

> >> The interface to the window subsystem will be the function
> >>
> >> change_frame_size (struct frame *f, int new_width, int new_height,
> >>           bool pretend, bool delay, bool safe, bool pixelwise)
> >>
> >> which processes new_width and new_height in terms of pixels if pixelwise
> >> is non-nil.
> 
> I meant 1 here.
> 
> > This is insane. it means changing lots and lots of calls, and makes merging between branches harder.
> 
> Currently, change_frame_size doesn't know anything about the various
> platforms' requirements going beyond those of the frame's text area.

I don't understand what you are trying to say. 

> > Make a new function (change_frame_size_pixelwise for example), with the arguments above, and let change_frame_size call it with the last argument false.
> 
> And how would change_frame_size know what the new pixel dimensions of
> the frame's text area are?

As Emacs has always done, multiply by canonical character pixel size. 

The point is that for X and NS there are probably just a few places where pixel size is needed.  Better to have a new name anyway so that we see it is a different function. This helps in backports, for example. 

    Jan D. 

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

[martin rudalics]

 >>> This is insane. it means changing lots and lots of calls, and makes merging between branches harder.
 >> Currently, change_frame_size doesn't know anything about the various
 >> platforms' requirements going beyond those of the frame's text area.
 >
 > I don't understand what you are trying to say.

change_frame_size has no idea whether it is called for a text or a
graphical frame.  Text frames might want to call it as before using
character sizes.  Callers that are able to process pixels and want them
applied will call it with pixel sizes.  In any case, the callers have to
strip space used for tool- or menubars because change_frame_size does
not know whether these are part of the frame or not.

 >>> Make a new function (change_frame_size_pixelwise for example), with the arguments above, and let change_frame_size call it with the last argument false.
 >> And how would change_frame_size know what the new pixel dimensions of
 >> the frame's text area are?
 >
 > As Emacs has always done, multiply by canonical character pixel size.

Doing that would just leave things as they are now.

When I maximize a frame, that frame may get a new pixel size which is
not necessarily a multiple of the frame's character size.  If I now want
to resize that frame's windows (and not leave some spare pixels at the
bottom of the frame as we do now) I have to communicate the new pixel
size of the frame's root window to the window resizing mechanism.  The
function that does that is change_frame_size.

martin

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

[Eli Zaretskii]

> Date: Mon, 22 Apr 2013 18:38:51 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: Eli Zaretskii <eliz@gnu.org>, "esabof@gmail.com" <esabof@gmail.com>, 
>  "14233@debbugs.gnu.org" <14233@debbugs.gnu.org>
> 
> change_frame_size has no idea whether it is called for a text or a
> graphical frame.

That is done very easily, given the frame pointer (which
change_frame_size accepts as its 1st argument).  E.g.:

  if (FRAME_WINDOW_P (f))
    /* do the GUI thing */

> Text frames might want to call it as before using character sizes.

On text-mode frames, each character is one pixel.  Emacs knows that
already.

> In any case, the callers have to strip space used for tool- or
> menubars because change_frame_size does not know whether these are
> part of the frame or not.

Why can't change_frame_size know that?

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

[Eli Zaretskii]

> Date: Mon, 22 Apr 2013 17:36:28 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: Eli Zaretskii <eliz@gnu.org>, esabof@gmail.com, 
>  14233@debbugs.gnu.org
> 
>  >> I suppose it's used for the vertical divider.
>  >>
>  >
>  > That is not so, the divider is just a one pixel wide line.
> 
> IIUC the vertical divider counts as a one character wide column.

Correct.  If it were a single pixel, one couldn't drag it to resize
windows.  See coordinates_in_window.

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

[martin rudalics]

 >> How do you "remove fringes"?  There are at least three ways to do that.
 >
 > Menu bar, options show.
 >
 >>> If I remove scrollbars, I get frame-size 83, and window-size 41.
 >> How do you "remove scrollbars"?
 >>
 >
 > Menu bar, options show.

BTW, what you do here reveals the basic problem with how Emacs currently
handles fringes and scrollbars.  When you remove the scrollbars the
Emacs frame shrinks.  When you remove the fringes it does not shrink.
Yet, when changing frame sizes we are expected to handle fringes and
scrollbars alike: They are no text, they are no windows and therefore
should not be counted in the width of the frame's text area.  This
cannot ever work right.

martin

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

[martin rudalics]

 >> change_frame_size has no idea whether it is called for a text or a
 >> graphical frame.
 >
 > That is done very easily, given the frame pointer (which
 > change_frame_size accepts as its 1st argument).  E.g.:
 >
 >   if (FRAME_WINDOW_P (f))
 >     /* do the GUI thing */

A couple of weeks ago I asked you whether HAVE_WINDOW_SYSTEM would be
sufficient but got no answer :-( The problem is that I'm still not sure
whether FRAME_WINDOW_P is sufficient.  At least in frame.c all
FRAME_WINDOW_P calls are guarded by HAVE_WINDOW_SYSTEM checks as

#ifdef HAVE_WINDOW_SYSTEM
       if (FRAME_WINDOW_P (XFRAME (this)))
	...
#endif

so some doubt remains whether this predicate is correctly installed on
every platform.  In any case I'd want either an #ifdef or a simple and
robust predicate without having to care about #ifdefs.

 >> Text frames might want to call it as before using character sizes.
 >
 > On text-mode frames, each character is one pixel.  Emacs knows that
 > already.

In the past weeks I started to doubt whether Emacs really knows
everything it pretends to know.

 >> In any case, the callers have to strip space used for tool- or
 >> menubars because change_frame_size does not know whether these are
 >> part of the frame or not.
 >
 > Why can't change_frame_size know that?

The callers should know best whether a toolbar is part of their frames
or not.  But we could obviously teach change_frame_size to check that.

martin

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

[martin rudalics]

 > Correct.  If it were a single pixel, one couldn't drag it to resize
 > windows.  See coordinates_in_window.

The problem is that I have no idea how many pixels it really occupies.
So my calculations for the no-scrollbar case are probably wrong.

And obviously such dividers should be always available so that one can

(1) mouse-drag window borders sideways in a human manner, and

(2) mouse-drag window borders up and down even in the absence of mode
     lines,

and ideally their width and background would be customizable.

martin

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

[Jan Djärv]

Hello.

22 apr 2013 kl. 18:38 skrev martin rudalics <rudalics@gmx.at>:

> >>> This is insane. it means changing lots and lots of calls, and makes merging between branches harder.
> >> Currently, change_frame_size doesn't know anything about the various
> >> platforms' requirements going beyond those of the frame's text area.
> >
> > I don't understand what you are trying to say.
> 
> change_frame_size has no idea whether it is called for a text or a
> graphical frame.  Text frames might want to call it as before using
> character sizes.  Callers that are able to process pixels and want them
> applied will call it with pixel sizes.  In any case, the callers have to
> strip space used for tool- or menubars because change_frame_size does
> not know whether these are part of the frame or not.

We do have macros like FRAME_MENUBAR_HEIGHT and FRAME_TOOLBAR_HEIGHT that can be used.  It is better to have that calculation in one place, rather than in each port, so this might be a good time to move it.

> 
> >>> Make a new function (change_frame_size_pixelwise for example), with the arguments above, and let change_frame_size call it with the last argument false.
> >> And how would change_frame_size know what the new pixel dimensions of
> >> the frame's text area are?
> >
> > As Emacs has always done, multiply by canonical character pixel size.
> 
> Doing that would just leave things as they are now.
> 
> When I maximize a frame, that frame may get a new pixel size which is
> not necessarily a multiple of the frame's character size.  If I now want
> to resize that frame's windows (and not leave some spare pixels at the
> bottom of the frame as we do now) I have to communicate the new pixel
> size of the frame's root window to the window resizing mechanism.  The
> function that does that is change_frame_size.

That is one occasion where a pixel-function is needed.  But for most calls, pixel precision is not needed.  These are the non-tile/fullscreen/maxmimized cases in X and NS.

	Jan D.

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

[martin rudalics]

 > We do have macros like FRAME_MENUBAR_HEIGHT and FRAME_TOOLBAR_HEIGHT
 > that can be used.  It is better to have that calculation in one place,
 > rather than in each port, so this might be a good time to move it.

If someone wants and knows how to do this cleanly, please go for it.
Currently, these macros are a horrible mess as calc_absolute_offset in
window.c demonstrates.

 >> When I maximize a frame, that frame may get a new pixel size which is
 >> not necessarily a multiple of the frame's character size.  If I now want
 >> to resize that frame's windows (and not leave some spare pixels at the
 >> bottom of the frame as we do now) I have to communicate the new pixel
 >> size of the frame's root window to the window resizing mechanism.  The
 >> function that does that is change_frame_size.
 >
 > That is one occasion where a pixel-function is needed.  But for most calls, pixel precision is not needed.  These are the non-tile/fullscreen/maxmimized cases in X and NS.

I need them for the fullscreen/maximized case on X and NS as well when
the screen estate assigned to Emacs is not a multiple of its character
size.

martin

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

[Eli Zaretskii]

> Date: Tue, 23 Apr 2013 08:50:53 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: Eli Zaretskii <eliz@gnu.org>, esabof@gmail.com, 
>  14233@debbugs.gnu.org
> 
> When you remove the scrollbars the Emacs frame shrinks.  When you
> remove the fringes it does not shrink.  Yet, when changing frame
> sizes we are expected to handle fringes and scrollbars alike: They
> are no text, they are no windows and therefore should not be counted
> in the width of the frame's text area.

I think this peculiar handling of the fringes is because of the desire
to count the display margins, if they are present, as part of the text
area.

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

[Eli Zaretskii]

> Date: Tue, 23 Apr 2013 08:52:08 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: jan.h.d@swipnet.se, esabof@gmail.com, 14233@debbugs.gnu.org
> 
>  >> change_frame_size has no idea whether it is called for a text or a
>  >> graphical frame.
>  >
>  > That is done very easily, given the frame pointer (which
>  > change_frame_size accepts as its 1st argument).  E.g.:
>  >
>  >   if (FRAME_WINDOW_P (f))
>  >     /* do the GUI thing */
> 
> A couple of weeks ago I asked you whether HAVE_WINDOW_SYSTEM would be
> sufficient but got no answer :-( The problem is that I'm still not sure
> whether FRAME_WINDOW_P is sufficient.  At least in frame.c all
> FRAME_WINDOW_P calls are guarded by HAVE_WINDOW_SYSTEM checks as
> 
> #ifdef HAVE_WINDOW_SYSTEM
>        if (FRAME_WINDOW_P (XFRAME (this)))
> 	...
> #endif

That's because the members of 'struct frame' that are tested by
FRAME_WINDOW_P do not exist unless HAVE_WINDOW_SYSTEM is defined.
Emacs caters to TTY frames both in a build --without-x, where
HAVE_WINDOW_SYSTEM is not defined and none of the X code is compiled;
and in a build that does support GUI frames, but just created a
text-mode frame for some reason.  Thus the need to have the code both
ifdef'ed away at compile time and tested at run time.

> so some doubt remains whether this predicate is correctly installed on
> every platform.

There's no doubt: it is, as described above.

> In any case I'd want either an #ifdef or a simple and robust
> predicate without having to care about #ifdefs.

Sorry, you can't, not with the current infrastructure.  You must do it
with a predicate that is also protected with an ifdef.

>  >> Text frames might want to call it as before using character sizes.
>  >
>  > On text-mode frames, each character is one pixel.  Emacs knows that
>  > already.
> 
> In the past weeks I started to doubt whether Emacs really knows
> everything it pretends to know.

Maybe so, but "1 character == 1 pixel on TTY frames" does not belong
to any gray areas.

>  >> In any case, the callers have to strip space used for tool- or
>  >> menubars because change_frame_size does not know whether these are
>  >> part of the frame or not.
>  >
>  > Why can't change_frame_size know that?
> 
> The callers should know best whether a toolbar is part of their frames
> or not.  But we could obviously teach change_frame_size to check that.

I think all the information is already stored in the frame object.

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

[Eli Zaretskii]

> Date: Tue, 23 Apr 2013 08:54:33 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: jan.h.d@swipnet.se, esabof@gmail.com, 14233@debbugs.gnu.org
> 
>  > Correct.  If it were a single pixel, one couldn't drag it to resize
>  > windows.  See coordinates_in_window.
> 
> The problem is that I have no idea how many pixels it really occupies.

Exactly one, like Jan said.

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

[Eli Zaretskii]

> Date: Tue, 23 Apr 2013 14:33:18 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: Eli Zaretskii <eliz@gnu.org>, "esabof@gmail.com" <esabof@gmail.com>, 
>  "14233@debbugs.gnu.org" <14233@debbugs.gnu.org>
> 
>  > We do have macros like FRAME_MENUBAR_HEIGHT and FRAME_TOOLBAR_HEIGHT
>  > that can be used.  It is better to have that calculation in one place,
>  > rather than in each port, so this might be a good time to move it.
> 
> If someone wants and knows how to do this cleanly, please go for it.

Can you explain what macros/functions would you like to have, exactly,
to be able to do this job cleanly?  Maybe FRAME_MENUBAR_HEIGHT
etc. are not what you need, but perhaps there are other means to get
the information cleanly.

>  > That is one occasion where a pixel-function is needed.  But for most calls, pixel precision is not needed.  These are the non-tile/fullscreen/maxmimized cases in X and NS.
> 
> I need them for the fullscreen/maximized case on X and NS as well when
> the screen estate assigned to Emacs is not a multiple of its character
> size.

I think we should postpone this argument until you are able to present
some code, including its influence on the callers of
change_frame_size.

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

[martin rudalics]

 >> When you remove the scrollbars the Emacs frame shrinks.  When you
 >> remove the fringes it does not shrink.  Yet, when changing frame
 >> sizes we are expected to handle fringes and scrollbars alike: They
 >> are no text, they are no windows and therefore should not be counted
 >> in the width of the frame's text area.
 >
 > I think this peculiar handling of the fringes is because of the desire
 > to count the display margins, if they are present, as part of the text
 > area.

Then this is a bad desire.  Otherwise, how would you explain that when
removing fringes first and scrollbars afterwards, Emacs reduces the frame
width by both.  Removing scrollbars first and fringes afterwards, reduces
the frame width by the width of the scrollbars only.

martin

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

[martin rudalics]

 >> In any case I'd want either an #ifdef or a simple and robust
 >> predicate without having to care about #ifdefs.
 >
 > Sorry, you can't, not with the current infrastructure.  You must do it
 > with a predicate that is also protected with an ifdef.

Then I don't see any motivation to move the platform dependent parts to
change_frame_size.  It would only make the code uglier than it already
is.

 > In the past weeks I started to doubt whether Emacs really knows
 >> everything it pretends to know.
 >
 > Maybe so, but "1 character == 1 pixel on TTY frames" does not belong
 > to any gray areas.

As a matter of fact, I only pretended to doubt.  Anyway, the entire
window resizing code now works pixelwise so on TTY frames nothing will
change.

 > I think all the information is already stored in the frame object.

Which makes me wonder why calc_absolute_offset looks like it does.

martin

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

[martin rudalics]

 >>  > We do have macros like FRAME_MENUBAR_HEIGHT and FRAME_TOOLBAR_HEIGHT
 >>  > that can be used.  It is better to have that calculation in one place,
 >>  > rather than in each port, so this might be a good time to move it.
 >>
 >> If someone wants and knows how to do this cleanly, please go for it.
 >
 > Can you explain what macros/functions would you like to have, exactly,
 > to be able to do this job cleanly?  Maybe FRAME_MENUBAR_HEIGHT
 > etc. are not what you need, but perhaps there are other means to get
 > the information cleanly.

A function that would tell me in a platform independent way the pixel
offset of the frame's root window from the top edge of the frame's
"client rectangle" (sorry for the Windows parlance).

I can calculate the remaining pixel edges of the frame's root window by
subtracting the frame's interior pixel width around it.  The minibuffer
window has either what frame-char-height tells me or gets me its pixel
height exactly when called by resize_mini_window.  So the upper part is
the only missing one (modulo the fringe/scrollbar tribulations mentioned
elsewhere).

martin

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

[Jan Djärv]

Hello.

24 apr 2013 kl. 08:39 skrev martin rudalics <rudalics@gmx.at>:

> >>  > We do have macros like FRAME_MENUBAR_HEIGHT and FRAME_TOOLBAR_HEIGHT
> >>  > that can be used.  It is better to have that calculation in one place,
> >>  > rather than in each port, so this might be a good time to move it.
> >>
> >> If someone wants and knows how to do this cleanly, please go for it.
> >
> > Can you explain what macros/functions would you like to have, exactly,
> > to be able to do this job cleanly?  Maybe FRAME_MENUBAR_HEIGHT
> > etc. are not what you need, but perhaps there are other means to get
> > the information cleanly.
> 
> A function that would tell me in a platform independent way the pixel
> offset of the frame's root window from the top edge of the frame's
> "client rectangle" (sorry for the Windows parlance).
> 

Using MS Windows narrows your world view.  If you used Emacs for Gtk+ you would know that the toolbar can be on any edge (top, bottom, left or right).  So getting just top edge offset is not enough.  You need all four offsets.

	Jan D.

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

[Eli Zaretskii]

> Date: Wed, 24 Apr 2013 08:38:43 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: jan.h.d@swipnet.se, esabof@gmail.com, 14233@debbugs.gnu.org
> 
>  >> When you remove the scrollbars the Emacs frame shrinks.  When you
>  >> remove the fringes it does not shrink.  Yet, when changing frame
>  >> sizes we are expected to handle fringes and scrollbars alike: They
>  >> are no text, they are no windows and therefore should not be counted
>  >> in the width of the frame's text area.
>  >
>  > I think this peculiar handling of the fringes is because of the desire
>  > to count the display margins, if they are present, as part of the text
>  > area.
> 
> Then this is a bad desire.

Could be, but if we want to change that, we need to come up with some
useful idea of how to deal with a situation where you have the fringe
between the display margins and the rest of the text area.  Surely, in
this case you must include the display margins in the window
dimensions, but OTOH the fringes separate the window into 2 disjoint
areas.

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

[Eli Zaretskii]

> Date: Wed, 24 Apr 2013 08:39:05 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: jan.h.d@swipnet.se, esabof@gmail.com, 14233@debbugs.gnu.org
> 
>  >> In any case I'd want either an #ifdef or a simple and robust
>  >> predicate without having to care about #ifdefs.
>  >
>  > Sorry, you can't, not with the current infrastructure.  You must do it
>  > with a predicate that is also protected with an ifdef.
> 
> Then I don't see any motivation to move the platform dependent parts to
> change_frame_size.

HAVE_WINDOW_SYSTEM and FRAME_WINDOW_P are platform INdependent.  Code
they guard is almost always also platform-independent.  There are 3 or
4 platforms we currently support that provide GUI frames, and they all
are handled by these predicates.

Or maybe I don't understand what you are saying above.

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

[Eli Zaretskii]

> Date: Wed, 24 Apr 2013 08:39:39 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: jan.h.d@swipnet.se, esabof@gmail.com, 14233@debbugs.gnu.org
> 
>  > Can you explain what macros/functions would you like to have, exactly,
>  > to be able to do this job cleanly?  Maybe FRAME_MENUBAR_HEIGHT
>  > etc. are not what you need, but perhaps there are other means to get
>  > the information cleanly.
> 
> A function that would tell me in a platform independent way the pixel
> offset of the frame's root window from the top edge of the frame's
> "client rectangle" (sorry for the Windows parlance).

Does Emacs even know that today, in any way, form, or shape?  At least
with toolkits, I'm not sure this is possible without having the
toolkit tell us this information.  But I'm not the expert on this.

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

[Jan Djärv]

24 apr 2013 kl. 19:15 skrev Eli Zaretskii <eliz@gnu.org>:

>> Date: Wed, 24 Apr 2013 08:39:39 +0200
>> From: martin rudalics <rudalics@gmx.at>
>> CC: jan.h.d@swipnet.se, esabof@gmail.com, 14233@debbugs.gnu.org
>> 
>>> Can you explain what macros/functions would you like to have, exactly,
>>> to be able to do this job cleanly?  Maybe FRAME_MENUBAR_HEIGHT
>>> etc. are not what you need, but perhaps there are other means to get
>>> the information cleanly.
>> 
>> A function that would tell me in a platform independent way the pixel
>> offset of the frame's root window from the top edge of the frame's
>> "client rectangle" (sorry for the Windows parlance).
> 
> Does Emacs even know that today, in any way, form, or shape?  At least
> with toolkits, I'm not sure this is possible without having the
> toolkit tell us this information.  But I'm not the expert on this.

Emacs knows this, but every toolkit has its own implementation on how to get the information.  And some toolkits sometimes lies to us (Gtk+ 3.x).

	Jan D.

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

[Stefan Monnier]

> Could be, but if we want to change that, we need to come up with some
> useful idea of how to deal with a situation where you have the fringe
> between the display margins and the rest of the text area.  Surely, in
> this case you must include the display margins in the window
> dimensions, but OTOH the fringes separate the window into 2 disjoint
> areas.

FWIW, I haven't followed all the details of this discussion, but it
seems to be about "how do we adjust the size of the frame when some
display elements are added/removed".  If so, then one answer is "never
adjust it".  Of course with frames measured in "lines × columns" this
comes with its own set of problems, but if we switch to measuring frames
in pixels, the problem should hopefully become simpler.


        Stefan

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

[Jan Djärv]

Hello.

24 apr 2013 kl. 20:50 skrev Stefan Monnier <monnier@iro.umontreal.ca>:

>> Could be, but if we want to change that, we need to come up with some
>> useful idea of how to deal with a situation where you have the fringe
>> between the display margins and the rest of the text area.  Surely, in
>> this case you must include the display margins in the window
>> dimensions, but OTOH the fringes separate the window into 2 disjoint
>> areas.
> 
> FWIW, I haven't followed all the details of this discussion, but it
> seems to be about "how do we adjust the size of the frame when some
> display elements are added/removed".  If so, then one answer is "never
> adjust it".  Of course with frames measured in "lines × columns" this
> comes with its own set of problems, but if we switch to measuring frames
> in pixels, the problem should hopefully become simpler.

I don't see how.  The problem is what to do with leftover pixels when the removed element isn't a multiple of the character size.  Measuring the frame in pixels does not help when removing, for example, a tool bar that is 1.5 character high.  It is the same problem, what to do with 0.5 character height.  Now if windows are measured in pixels, we can give those pixels to windows, but frames measured in pixels does not help.

	Jan D.

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

[martin rudalics]

 >> A function that would tell me in a platform independent way the pixel
 >> offset of the frame's root window from the top edge of the frame's
 >> "client rectangle" (sorry for the Windows parlance).
 >
 > Using MS Windows narrows your world view.  If you used Emacs for Gtk+
 > you would know that the toolbar can be on any edge (top, bottom, left
 > or right).  So getting just top edge offset is not enough.  You need
 > all four offsets.

If you had a broader world view, you would have noticed that the Gtk+
toolbar is not part of the client rectangle (the rectangle passed to
change_frame_size), so your point is moot in this context.  What I
wanted are the much simpler macros

#define FRAME_MENU_BAR_HEIGHT(f) (f)->menu_bar_height

#define FRAME_TOOL_BAR_HEIGHT(f) (f)->tool_bar_height

#define FRAME_TOP_MARGIN_HEIGHT(F)				\
   (FRAME_MENU_BAR_HEIGHT (F) + FRAME_TOOL_BAR_HEIGHT (F))

where tool_bar_height would count (in pixels) things like
`tool-bar-button-margin', `tool-bar-button-relief' and
`tool-bar-border', wherever applicable, together with the actual toolbar
and menubar heights (in particular, when these have been wrapped).

If you want for tiled/user specified/maximized/fullscreen mode on Gtk+
change_frame_size to subtract the Gtk+ toolbar size from that of the
screen, then we'd have to first include this size in that of the
rectangle passed to change_frame_size.  This would, however, constitute
a considerable change in the design of the frame/window interface and
would be better done in a separate project.

martin

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

[martin rudalics]

 > Could be, but if we want to change that, we need to come up with some
 > useful idea of how to deal with a situation where you have the fringe
 > between the display margins and the rest of the text area.  Surely, in
 > this case you must include the display margins in the window
 > dimensions,

... but the display margins were always included in the window
dimensions ...

 > but OTOH the fringes separate the window into 2 disjoint
 > areas.

... so what am I missing?  All I want is to maintain fringes exclusively
inside the frame's root window.

martin

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

[martin rudalics]

 >> A function that would tell me in a platform independent way the pixel
 >> offset of the frame's root window from the top edge of the frame's
 >> "client rectangle" (sorry for the Windows parlance).
 >
 > Does Emacs even know that today, in any way, form, or shape?  At least
 > with toolkits, I'm not sure this is possible without having the
 > toolkit tell us this information.  But I'm not the expert on this.

I suppose so since otherwise we were not able to draw that correctly.
Note that the client rectangle refers to the part of the frame that is
controlled by the application, in our case Emacs.  The Gtk+ toolbar, for
example, is not part of the client rectangle as anything else that can
be obtained only via a frame's output_data.

martin

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

[martin rudalics]

 > FWIW, I haven't followed all the details of this discussion, but it
 > seems to be about "how do we adjust the size of the frame when some
 > display elements are added/removed".

... or change size, yes.

 > If so, then one answer is "never
 > adjust it".

That's the answer I would have liked to hear in the first place.  And
that's what we currently do when a frame internal toolbar wraps, for
example, by occupying two lines instead of one.  And we do it
(unintentionally, alas) when the menubar wraps on Windows (but this is a
problem of the Windows API and not of Emacs).

We currently don't do it when changing a frame's nominal scrollbar size.
In most cases, changing a frame's scrollbar size is done, however, in a
consistent fashion.  The only problem I remarked earlier happens when
changing the scrollbar size of a fullscreen/maximized frame which
usually is no more fullscreen/maximized afterwards (maybe this has been
fixed meanwhile).

And we don't do it currently when changing fringe widths.  Changing
fringes, however, is done in a pretty uncoordinated fashion as bug#14222
and the discussions in this thread document.

 > Of course with frames measured in "lines × columns" this
 > comes with its own set of problems, but if we switch to measuring frames
 > in pixels, the problem should hopefully become simpler.

The problem remains as it is.  It's up to us to decide what we want.

martin

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

[martin rudalics]

 > I don't see how.  The problem is what to do with leftover pixels when
 > the removed element isn't a multiple of the character size.  Measuring
 > the frame in pixels does not help when removing, for example, a tool
 > bar that is 1.5 character high.  It is the same problem, what to do
 > with 0.5 character height.  Now if windows are measured in pixels, we
 > can give those pixels to windows, but frames measured in pixels does
 > not help.

Maybe we are just miscommunicating.  IIUC the above scenario is of
interest only with an "external" element on a tiled/fullscreen/maximized
frame (if the frame is not of that kind we just remove the external
element).

If you agree on that, we have to find out what to do with the leftover
pixels.  And I earlier said that "you" should pass these leftover pixels
via change_frame_size to the window resizing subsystem.  This means that
the routine that removes the element has to (1) calculate the number of
pixels occupied by it, (2) communicate the removal of the element to the
window manager, if necessary, and (3) add the number of pixels of the
element to the number of pixels occupied by the frame's text size and
call change_frame_size with the new value.  What am I missing?

martin

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

[Jan Djärv]

Hello. 

25 apr 2013 kl. 09:29 skrev martin rudalics <rudalics@gmx.at>:

> >> A function that would tell me in a platform independent way the pixel
> >> offset of the frame's root window from the top edge of the frame's
> >> "client rectangle" (sorry for the Windows parlance).
> >
> > Using MS Windows narrows your world view.  If you used Emacs for Gtk+
> > you would know that the toolbar can be on any edge (top, bottom, left
> > or right).  So getting just top edge offset is not enough.  You need
> > all four offsets.
> 
> If you had a broader world view, you would have noticed that the Gtk+
> toolbar is not part of the client rectangle (the rectangle passed to
> change_frame_size), so your point is moot in this context.  

It is the terminology that is unclear. I took "frame's root window" to mean the X window, not the Emacs window. 

     Jan D. 

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

[Jan Djärv]

Hello.

25 apr 2013 kl. 09:31 skrev martin rudalics <rudalics@gmx.at>:

> > I don't see how.  The problem is what to do with leftover pixels when
> > the removed element isn't a multiple of the character size.  Measuring
> > the frame in pixels does not help when removing, for example, a tool
> > bar that is 1.5 character high.  It is the same problem, what to do
> > with 0.5 character height.  Now if windows are measured in pixels, we
> > can give those pixels to windows, but frames measured in pixels does
> > not help.
> 
> Maybe we are just miscommunicating.  IIUC the above scenario is of
> interest only with an "external" element on a tiled/fullscreen/maximized
> frame (if the frame is not of that kind we just remove the external
> element).

If the goal is to not resize the frame, removing an external element will always mean there are leftover pixels. 
So the scenario always apply. 

> 
> If you agree on that, we have to find out what to do with the leftover
> pixels.  And I earlier said that "you" should pass these leftover pixels
> via change_frame_size to the window resizing subsystem.  This means that
> the routine that removes the element has to (1) calculate the number of
> pixels occupied by it, (2) communicate the removal of the element to the
> window manager, if necessary, and (3) add the number of pixels of the
> element to the number of pixels occupied by the frame's text size and
> call change_frame_size with the new value.  What am I missing?

   Jan D. 

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

[martin rudalics]

> It is the terminology that is unclear. I took "frame's root window" to mean the X window, not the Emacs window. 

The root window is even less: It doesn't include the
minibuffer window.

martin

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

[martin rudalics]

 > If the goal is to not resize the frame, removing an external element will always mean there are leftover pixels.
 > So the scenario always apply.

Who am I to object?  But then we obviously should refrain from resizing
the frame when we change fringes, scrollbars or the menubar.

martin

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

[Jan Djärv]

Hello. 

25 apr 2013 kl. 13:58 skrev martin rudalics <rudalics@gmx.at>:

> > If the goal is to not resize the frame, removing an external element will always mean there are leftover pixels.
> > So the scenario always apply.
> 
> Who am I to object?  But then we obviously should refrain from resizing
> the frame when we change fringes, scrollbars or the menubar.

I agree. 

     Jan D. 

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

[Richard Stallman]

I have not followed this discussion, but getting rid of this
limitation is an important step.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

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

[Eli Zaretskii]

> Date: Thu, 25 Apr 2013 09:29:20 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: jan.h.d@swipnet.se, esabof@gmail.com, 14233@debbugs.gnu.org
> 
>  > Could be, but if we want to change that, we need to come up with some
>  > useful idea of how to deal with a situation where you have the fringe
>  > between the display margins and the rest of the text area.  Surely, in
>  > this case you must include the display margins in the window
>  > dimensions,
> 
> ... but the display margins were always included in the window
> dimensions ...

Yes, and that might explain why so are the fringes.

>  > but OTOH the fringes separate the window into 2 disjoint
>  > areas.
> 
> ... so what am I missing?  All I want is to maintain fringes exclusively
> inside the frame's root window.

I don't know anymore who misses what.  You said:

>  >> When you remove the scrollbars the Emacs frame shrinks.  When you
>  >> remove the fringes it does not shrink.  Yet, when changing frame
>  >> sizes we are expected to handle fringes and scrollbars alike: They
>  >> are no text, they are no windows and therefore should not be counted
>  >> in the width of the frame's text area.

which to me means that you want fringes to NOT be included in the
window text area.  Therefore, I tried to explain what was (or could
be) the motivation to INCLUDE fringes in the text area: because
otherwise, the display margins, which ARE part of text area, would
become disjoint from the rest of the window's text area by the fringes
that are in-between.

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

[martin rudalics]

 >> ... but the display margins were always included in the window
 >> dimensions ...
 >
 > Yes, and that might explain why so are the fringes.

... but the fringes never were ...

 >>  > but OTOH the fringes separate the window into 2 disjoint
 >>  > areas.
 >>
 >> ... so what am I missing?  All I want is to maintain fringes exclusively
 >> inside the frame's root window.
 >
 > I don't know anymore who misses what.  You said:
 >
 >>  >> When you remove the scrollbars the Emacs frame shrinks.  When you
 >>  >> remove the fringes it does not shrink.  Yet, when changing frame
 >>  >> sizes we are expected to handle fringes and scrollbars alike: They
 >>  >> are no text, they are no windows and therefore should not be counted
 >>  >> in the width of the frame's text area.
 >
 > which to me means that you want fringes to NOT be included in the
 > window text area.  Therefore, I tried to explain what was (or could
 > be) the motivation to INCLUDE fringes in the text area: because
 > otherwise, the display margins, which ARE part of text area, would
 > become disjoint from the rest of the window's text area by the fringes
 > that are in-between.

You misread.  There's a difference between what I want to do and what
has to be done to fix an existing bug.  Let me start with the latter
first.

------

An Emacs frame contains a text area and a non-text area, both of which
are not necessarily contiguous.  Traditionally, the text area contains
the displayed buffer texts, the display margins, the minibuffer window,
the toolbar window and the menubar window.  The non-text area contains
the scrollbars and vertical divider lines, the fringes, and the internal
borders of the frame.

In addition, a frame usually has parts maintained externally like an
external toolbar, menubar, decorations and external borders.  Parts
maintained externally are not directly controlled by Emacs, their sizes
and appearances are subject to negotiations with the operating system's
window manager.

Part of this traditional convention is that when certain aspects of the
appearance of a frame change, Emacs tries to keep the size of the
displayed buffer text unchanged in terms of lines and columns.  This
implies that when we add/remove/change the size of a scrollbar or a
fringe, the size of the frame as a whole has to change to keep the
number of columns in the text area (which is already an abstraction of
the displayed buffer text due to the presence of display margins)
constant.  We also resize the frame when we change its default font or
the internal border width.

We do not change the frame size when we modify the buffer text, change
the height of the minibuffer window, a toolbar window, a menubar window,
or the size of display margins.

I don't know whether changing parts maintained externally (like removing
an external toolbar or setting the operating system's default font for
menubar items), may affect the size of the rest of the frame.  I guess
that usually the OS/window manager tries to keep the size of the entire
frame (inlcuding the external parts) constant, but this might not be
always the case.  I'd be glad if someone informed me about the behavior
of Emacs in this regard on the various platforms we maintain.

The traditional concept works well for frames that contain one window
only.  It fails already, where a frame is built from two windows one
above the other where one of these windows comprises two side-by-side
windows.  In this case, changing a scrollbar or a fringe will invalidate
the attempt to keep the number of columns/lines of displayed buffer text
(the text areas) unchanged.

In addition, the concept sketched above has been softened with the
addition of window/buffer-local fringes and scrollbars.  Changing these
affect the window(s) displaying a certain buffer only and do not change
the size of the frame.

Note that with side-by-side windows frame-local fringe/scrollbar widths
have been practically eradicated - they continue to live virtually only
(mainly serving as a default value for windows and buffers that don't
define their own).

Unfortunately, later changes clashed with the earlier defined concepts
in a number of ways.  Here I shall sketch two of them:

(1) Over the time, the fringe handling code has been rewritten (in a
     routine called compute_fringe_widths) such that changing a frame's
     fringes will not cause the frame to get resized immediately but
     stores the new values in the corresponding frame parameter only.

     This behavior is the immediate cause of bug#14222 and should be
     fixed, either by sending a resize request to the OS (which might be
     tricky) or by having fringes become part of the frame's text area.

(2) Maximized/fullscreen frames do not play nicely with keeping the
     numbers of columns/lines unchanged.  Emacs should not resize such a
     frame when changing default font or parts of the non-text area.

This concludes my assessment of how Emacs frames traditionally behave
and what should be done to fix some shortcomings.  It's by no means
related to the introduction of pixelwise resizing and/or to how I want
Emacs frames to behave.

-----------------------

What I _want_ to do is no less than to remove the aim to keep the number
of columns/lines unchanged when changing aspects that control the
appearance of frames like scrollbars, fringes, or internal borders.
And, as Jan remarked, we should also try to keep the combined size of an
Emacs frame + its externally maintained parts unchanged when, for
example, removing an external toolbar (unless the window manager handles
this case already as it apparently already does when resizing an
external menubar).

This aim has two immediate consequences:

(1) We do not distinguish between a frame's text and non-text areas any
     more.  The frame size changes only when explicitly requested.  This
     also means that we don't have to contact the OS/window manager when
     adding/removing scrollbars/internal borders or changing the default
     font.

(2) In some case we may now have to contact the OS/window manager, for
     example, when removing an external toolbar, we may have to issue a
     request to fill the freed screen space with the to-be-enlarged Emacs
     frame.  Whether and where this is necessary is beyond my knowledge
     though.

I'm still uncertain whether this behavior should be applied to textual
frames too.

-----------

Finally note that I do not intend to implement any of the things I
sketched here in my pixelwise implementation of frame/window resizing.
This implementation will emulate the current behavior (with all its bugs
and shortcomings) as closely as possible.

martin

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

[Stefan Monnier]

> What I _want_ to do is no less than to remove the aim to keep the number
> of columns/lines unchanged when changing aspects that control the
> appearance of frames like scrollbars, fringes, or internal borders.
> And, as Jan remarked, we should also try to keep the combined size of an
> Emacs frame + its externally maintained parts unchanged when, for
> example, removing an external toolbar (unless the window manager handles
> this case already as it apparently already does when resizing an
> external menubar).

Sounds good to me.


        Stefan

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

[Drew Adams]

Lots of good background info for those of us who are not up on this stuff -
thanks, Martin.

Just one remark, from one user and use case.  Not sure how relevant it is to
what you guys are discussing - if not, please ignore.

> We also resize the frame when we change its default font...

I have code that relies on this behavior to shrink not only the default font
size (of all windows in the frame) but the frame itself.  I do this not only to
zoom (shrink or enlarge) a frame and its text slightly.  I do it also to shrink
it a lot - down to a thumbnail/icon size - and later restore it.

I would not like to see this behavior change, so that, e.g., Emacs stopped
resizing the frame when I change the font size for the frame.

We already have the ability to scale text (for a particular buffer, but not a
window or all windows in a frame) without the frame shrinking.  Both kinds of
behavior, buffer zooming and frame zooming, are useful.

In fact, each of my zoom commands can do either, and can toggle between the two
behaviors: zoom the current buffer or zoom the selected frame.

Just wanted to point out this probably not-so-obvious use case that is based on
the frame-size-follows-font-size behavior has long enjoyed.  If you change
something that might jeopardize this, please at least make it optional for the
frame and font size to be coupled this way.  Thx.

http://www.emacswiki.org/emacs-en/download/zoom-frm.el
http://emacswiki.org/emacs/SetFonts#ChangingFontSize

http://www.emacswiki.org/emacs-en/download/thumb-frm.el
http://www.emacswiki.org/emacs-en?FisheyeWithThumbs

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

[martin rudalics]

 > I have code that relies on this behavior to shrink not only the default font
 > size (of all windows in the frame) but the frame itself.  I do this not only to
 > zoom (shrink or enlarge) a frame and its text slightly.  I do it also to shrink
 > it a lot - down to a thumbnail/icon size - and later restore it.
 >
 > I would not like to see this behavior change, so that, e.g., Emacs stopped
 > resizing the frame when I change the font size for the frame.

It depends on the interface you use.  The function `set-frame-font' has
the KEEP-SIZE argument and I don't intend to change its semantics (I'll
probably remove the rounding when `frame-resize-pixelwise' is non-nil).

martin

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

[Drew Adams]

>  > I have code that relies on this behavior to shrink not 
>  > only the default font size (of all windows in the frame)
>  > but the frame itself.  I do this not only to zoom
>  > (shrink or enlarge) a frame and its text slightly.  I do
>  > it also to shrink it a lot - down to a thumbnail/icon size
>  > - and later restore it.
>  >
>  > I would not like to see this behavior change, so that, 
>  > e.g., Emacs stopped resizing the frame when I change the
>  > font size for the frame.
> 
> It depends on the interface you use.

Already that does not sound very good.  Why should the behavior be different
depending on how you change a frame parameter?

> The function `set-frame-font' has the KEEP-SIZE argument
> and I don't intend to change its semantics (I'll probably
> remove the rounding when `frame-resize-pixelwise' is non-nil).

I use `modify-frame-parameters', providing a new value for parameter `font'.
The new value is calculated this way (in frame-cmds.el):

(defun enlarged-font-name (fontname frame increment)
  "FONTNAME, after enlarging font size of FRAME by INCREMENT.
FONTNAME is the font of FRAME."
  (when (query-fontset fontname)
    (let ((ascii  (assq 'ascii
                        (aref (fontset-info fontname frame) 2))))
      (when ascii (setq fontname (nth 2 ascii)))))
  (let ((xlfd-fields  (x-decompose-font-name fontname)))
    (unless xlfd-fields (error "Cannot decompose font name"))
    (let ((new-size  (+ (string-to-number
                         (aref xlfd-fields
                               xlfd-regexp-pixelsize-subnum))
                       increment)))
      (unless (> new-size 0)
        (error "New font size is too small: %s" new-size))
      (aset xlfd-fields xlfd-regexp-pixelsize-subnum
            (number-to-string new-size)))
    ;; Set point size & width to "*", so frame width will adjust
    ;; to new font size
    (aset xlfd-fields xlfd-regexp-pointsize-subnum "*")
    (aset xlfd-fields xlfd-regexp-avgwidth-subnum "*")
    (x-compose-font-name xlfd-fields)))

This is the function that uses that new value:

(defun enlarge-font (&optional increment frame)
  "Increase size of font in FRAME by INCREMENT.
Interactively, INCREMENT is given by the prefix argument.
Optional FRAME parameter defaults to current frame."
  (interactive "p")
  (setq frame (or frame (selected-frame)))
  (let ((fontname  (cdr (assq 'font (frame-parameters frame))))
        (count enlarge-font-tries))
    (setq fontname (enlarged-font-name fontname frame increment))
    (while (and (not (x-list-fonts fontname))
                (wholenump (setq count (1- count))))
      (setq fontname (enlarged-font-name fontname frame increment)))
    (unless (x-list-fonts fontname)
      (error "Cannot change font size"))
    (modify-frame-parameters frame (list (cons 'font fontname)))
    ;; Update faces that want a bold or italic version of default.
    (when (< emacs-major-version 21) (frame-update-faces frame))))

I use this code a lot: in doremi-frm.el to enlarge/shrink incrementally; in
zoom-frm.el to do likewise, but differently; in thumb-frm.el to (de)thumbify.

I really hope this will not be broken by whatever changes you envision.  Thx.

The code is here:
http://www.emacswiki.org/emacs-en/download/frame-cmds.el
http://www.emacswiki.org/emacs-en/download/zoom-frm.el
http://www.emacswiki.org/emacs-en/download/thumb-frm.el

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

[martin rudalics]

 >>  > I would not like to see this behavior change, so that,
 >>  > e.g., Emacs stopped resizing the frame when I change the
 >>  > font size for the frame.
 >>
 >> It depends on the interface you use.
 >
 > Already that does not sound very good.  Why should the behavior be different
 > depending on how you change a frame parameter?
 >
 >> The function `set-frame-font' has the KEEP-SIZE argument
 >> and I don't intend to change its semantics (I'll probably
 >> remove the rounding when `frame-resize-pixelwise' is non-nil).
 >
 > I use `modify-frame-parameters', providing a new value for parameter `font'.

Conceptually, `modify-frame-parameters' allows to change several frame
parameters for the next redisplay.  But the outcome depends on the
evaluation order of the ALIST argument.  Suppose you want to change a
frame's font and size in one and the same call.  The result would depend
on which element is evaluated first due to the fact that changing the
font allows to change the size of the frame too.  This is not my idea of
clean semantics.

 > The new value is calculated this way (in frame-cmds.el):
[...]
 >     (modify-frame-parameters frame (list (cons 'font fontname)))

I suppose it would be trivial to change this single line to use
`set-frame-font' in order to deal with the change I propose.  But if
people like the current behavior I can obviously leave things as they
are now.

martin

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

[Drew Adams]

> Conceptually, `modify-frame-parameters' allows to change several frame
> parameters for the next redisplay.  But the outcome depends on the
> evaluation order of the ALIST argument.  Suppose you want to change a
> frame's font and size in one and the same call.  The result 
> would depend on which element is evaluated first due to the fact
> that changing the font allows to change the size of the frame too.
> This is not my idea of clean semantics.

Respecting the order means that it is clear - pretty much equivalent,
presumably, to modifying one frame parameter at a time, in order.

Whether you do that using (a) separate calls, in sequence, to single-parameter
setting functions or (b) using one or more calls to a general setting function
that accepts an alist (which is of course ordered), changes nothing, AFAICT.

Either way, you still have to take into account any interdependence among
parameters.

>  > The new value is calculated this way (in frame-cmds.el):...
>  >     (modify-frame-parameters frame (list (cons 'font fontname)))
> 
> I suppose it would be trivial to change this single line to use
> `set-frame-font' in order to deal with the change I propose.  But if
> people like the current behavior I can obviously leave things as they
> are now.

1. `set-frame-font' apparently has this side effect, which is not appropriate
here:

  Also, if FRAME is non-nil,
  alter the user's Customization settings as though the
  font-related attributes of the `default' face had been "set in
  this session", so that the font is applied to future frames.

(It should say FRAMES, not FRAME, BTW.)

Why does `set-frame-font' not allow you to change the font for a given frame
(besides the selected frame), without also changing face `default' for future
frames?

Interestingly, in Emacs 20 (and in 21 it was essentially the same),
`set-frame-font' just used `modify-frame-parameters' - very clear and simple:

(defun set-frame-font (font-name)
  "Set the font of the selected frame to FONT.
When called interactively, prompt for the name of the font to use.
To get the frame's current default font, use `frame-parameters'."
  (interactive "sFont name: ")
  (modify-frame-parameters (selected-frame)
			   (list (cons 'font font-name)))
  (frame-update-faces (selected-frame)))

;; And `frame-update-faces' was a no-op (obsolete in Emacs 21):
(defun frame-update-faces (frame) nil)

Nowadays, `set-frame-font' is an incomprehensible monster.

2. `modify-frame-parameters' is the basic, general, workhorse function for
frames.  It lets you set any number of frame parameters in any order.  Yes, I
would very much like it to continue working in the same, straightforward manner,
including for parameter `font'.

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

[Drew Adams]

> 1. `set-frame-font' apparently has this side effect, which is 
> not appropriate here:
> 
>   Also, if FRAME is non-nil,
>   alter the user's Customization settings as though the
>   font-related attributes of the `default' face had been "set in
>   this session", so that the font is applied to future frames.
> 
> (It should say FRAMES, not FRAME, BTW.)
> 
> Why does `set-frame-font' not allow you to change the font 
> for a given frame (besides the selected frame), without also
> changing face `default' for future frames?

Actually, I don't think I see this behavior, or perhaps I misunderstand what is
meant by that text.

After changing the font (e.g. to a different size) using a list of only the
current frame as parameter FRAMES, the changed face `default' does not seem to
affect new frames.

Tracing `set-frame-font' in the debugger, I do see that face `default' gets its
font attributes updated, including the size.  But new frames created after doing
this still seem to use the original `default' size.

E.g.:

emacs -Q
(frame-parameter nil 'font) ; =>
"-outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1"

M-x customize-face-other-window default RET
Shows the height as 98 and the State as STANDARD.

(set-frame-font
  "-outline-Courier New-normal-normal-normal-mono-9-*-*-*-c-*-iso8859-1"
  (list (selected-frame)))

(face-font 'default) ; Shows exactly that font with size `9'.

M-x customize-face-other-window default RET
Shows the height as 69 and the State as STANDARD.

So far, `set-frame-font' seems to do what its doc string says wrt face `default'
- a misfeature, perhaps, but so be it.  Except for one thing: Customize says the
State is "STANDARD" instead of "SET for current session only.", which is what
the doc string specifies. 

But the real difference I see is that `C-x 5 f foo' creates a new frame with
font size 13 again.  And `M-x customize-face-other-window default RET' in that
frame shows the height as 98 again (and the State still as STANDARD).  (And of
course this value of 98 is now seen in the Customize window on the other frame
as well.)

So it does not seem to me like the documented behavior actually occurs.  It does
so partially (the height value is shown changed in the same frame), but not wrt
new frames created.

What am I missing here?

Again, the documented behavior of affecting new frames seems like a misfeature
to me, so I'm not complaining that it does not work as advertised.  I'm just
saying that it does not seem to work as advertised, and I'm asking what I'm
missing.

(This is all outside the discussion about `modify-frame-parameters'.  I mention
it because you drew my attention to `set-frame-font'.)

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

[martin rudalics]

 > Respecting the order means that it is clear - pretty much equivalent,
 > presumably, to modifying one frame parameter at a time, in order.
 >
 > Whether you do that using (a) separate calls, in sequence, to single-parameter
 > setting functions or (b) using one or more calls to a general setting function
 > that accepts an alist (which is of course ordered), changes nothing, AFAICT.
 >
 > Either way, you still have to take into account any interdependence among
 > parameters.

As someone who used this for the first time I'd be surely surprised if
interchanging the order of two alist elements would have any such
consequences.  But maybe `modify-frame-parameters' isn't intended for
less experienced users.

 > 1. `set-frame-font' apparently has this side effect, which is not appropriate
 > here:
 >
 >   Also, if FRAME is non-nil,
 >   alter the user's Customization settings as though the
 >   font-related attributes of the `default' face had been "set in
 >   this session", so that the font is applied to future frames.
 >
 > (It should say FRAMES, not FRAME, BTW.)
 >
 > Why does `set-frame-font' not allow you to change the font for a given frame
 > (besides the selected frame), without also changing face `default' for future
 > frames?

Maybe because they would tell you to select the frame first and then
call it with FRAME nil.

 > Interestingly, in Emacs 20 (and in 21 it was essentially the same),
 > `set-frame-font' just used `modify-frame-parameters' - very clear and simple:
 >
 > (defun set-frame-font (font-name)
 >   "Set the font of the selected frame to FONT.
 > When called interactively, prompt for the name of the font to use.
 > To get the frame's current default font, use `frame-parameters'."
 >   (interactive "sFont name: ")
 >   (modify-frame-parameters (selected-frame)
 > 			   (list (cons 'font font-name)))
 >   (frame-update-faces (selected-frame)))
 >
 > ;; And `frame-update-faces' was a no-op (obsolete in Emacs 21):
 > (defun frame-update-faces (frame) nil)
 >
 > Nowadays, `set-frame-font' is an incomprehensible monster.

IMO `modify-frame-parameters' should keep the frame size and everything
else unchanged when changing the font.  Changing the appearance of
scrollbars, fringes and sizes or the appearance of future frames should
be done on top of that, for example, by `set-frame-font' albeit in a
more transparent fashion than currently.

 > 2. `modify-frame-parameters' is the basic, general, workhorse function for
 > frames.  It lets you set any number of frame parameters in any order.  Yes, I
 > would very much like it to continue working in the same, straightforward manner,
 > including for parameter `font'.

When setting one frame parameter can implicitly change another one, I
wouldn't consider that as "straightforward".  But since I never tried to
customize my emacs in this area I trust you.  Maybe someone who both
uses frame parameters and knows how they should work can eventually fix
the problems in this area then.

martin

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

[Drew Adams]

>  > Either way, you still have to take into account any 
>  > interdependence among parameters.
> 
> As someone who used this for the first time I'd be surely surprised if
> interchanging the order of two alist elements would have any such
> consequences.  But maybe `modify-frame-parameters' isn't intended for
> less experienced users.

You would have the same surprise with separate calls to parameter-setting
functions: the order matters.  Someone who is not aware that a few frame
parameters are not independent of each other will be in for a surprise no matter
how s?he sets them, if not paying attention to the order of setting.

If you think the doc of `modify-frame-parameters' is not sufficiently clear wrt
its alist argument (and the same likely applies to other functions or variables,
such as `default-frame-alist'), then please add to the doc to make this clearer.

Do we even make explicit in the doc which parameters depend on which other
parameters?  That would be the place to start wrt this problem, not some
specific function that sets parameters.

>  > 1. `set-frame-font' apparently has this side effect, which 
>  > is not appropriate here:
>  >
>  >   Also, if FRAME is non-nil,
>  >   alter the user's Customization settings as though the
>  >   font-related attributes of the `default' face had been "set in
>  >   this session", so that the font is applied to future frames.
>  >
>  > (It should say FRAMES, not FRAME, BTW.)
>  >
>  > Why does `set-frame-font' not allow you to change the font 
>  > for a given frame (besides the selected frame), without also
>  > changing face `default' for future frames?
> 
> Maybe because they would tell you to select the frame first and then
> call it with FRAME nil.

They who?  Sorry, I don't understand.  Why does `set-frame-font' not let you act
on a given frame (any frame), without also changing face `default' for future
frames?  That makes no sense to me.

Maybe the logic behind that coupling could be made more explicit in the doc?  Or
maybe that "enhancement" should be reverted?

> IMO `modify-frame-parameters' should keep the frame size and 
> everything else unchanged when changing the font.

IMO, it should not.  Such an incompatible change will break all of the code I
mentioned, for one thing.

Why do you suppose that there is an optional parameter KEEP-SIZE for
`set-frame-font'?  And why do you suppose it is optional (i.e., the default
behavior does NOT keep the same size)?

And now you propose to, in effect, impose KEEP-SIZE behavior everywhere, and not
even provide a no-keep-size optional behavior (i.e., traditional Emacs
behavior)?

> Changing the appearance of scrollbars, fringes and sizes or the
> appearance of future frames should be done on top of that,

You are mixing a lot of things in there.

Why should `modify-frame-parameters', applied to a single frame, affect future
frames at all?

That mistake was already introduced into `set-frame-font' (in Emacs 22, I
believe).  Such future-changing has no business being coupled into the behavior
of the basic function for changing a frame's parameters.

> for example, by `set-frame-font' albeit in a
> more transparent fashion than currently.
> 
>  > 2. `modify-frame-parameters' is the basic, general, 
>  > workhorse function for frames.  It lets you set any number
>  > of frame parameters in any order.  Yes, I would very much
>  > like it to continue working in the same, straightforward
>  > manner, including for parameter `font'.
> 
> When setting one frame parameter can implicitly change another one, I
> wouldn't consider that as "straightforward".

The non-independence of some frame parameters is a general condition - not
specific to `modify-frame-parameters' at all.

> But since I never tried to customize my emacs in this area
> I trust you.  Maybe someone who both uses frame parameters
> and knows how they should work can eventually fix
> the problems in this area then.

And I trust you and your knowledge of windows and frames, which is certainly far
beyond mine.  It's possible for your knowledge and my particular experience to
work together.

I know that because it has happened before.  You have fixed badly broken frame
behavior several times now, working with info about my particular experience.  I
thank you again for all that patient and careful work.

One thing that seems unfortunate to me is the coupling of (a) changing a
parameter value for a single frame with (b) changing the default value of that
parameter for future frames.  IIUC, that is what `set-frame-font' does now, and
it seems wrong to me.  Are there other parameter-setting functions that also act
like that?

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

[martin rudalics]

 > You would have the same surprise with separate calls to parameter-setting
 > functions: the order matters.

Only if I do not redraw the frame in between.

 > Someone who is not aware that a few frame
 > parameters are not independent of each other will be in for a surprise no matter
 > how s?he sets them, if not paying attention to the order of setting.

That someone might be a person who wants to do two things at the same
time in her Emacs: Use a specific font size and a specific frame size.

 > If you think the doc of `modify-frame-parameters' is not sufficiently clear wrt
 > its alist argument (and the same likely applies to other functions or variables,
 > such as `default-frame-alist'), then please add to the doc to make this clearer.
 >
 > Do we even make explicit in the doc which parameters depend on which other
 > parameters?  That would be the place to start wrt this problem, not some
 > specific function that sets parameters.

I'm afraid that nobody will do that.  Some of these dependencies are
platform specific, other are encrusted since the early days of Emacs.
Moreover alist elements get reversed, processed out of order, ...

 >> Maybe because they would tell you to select the frame first and then
 >> call it with FRAME nil.
 >
 > They who?  Sorry, I don't understand.  Why does `set-frame-font' not let you act
 > on a given frame (any frame), without also changing face `default' for future
 > frames?  That makes no sense to me.

"They" are those who programmed it that way.  IIUC `set-frame-font' was
called `set-default-font' before and maybe didn't even pay attention to
frames at that time.

 > Maybe the logic behind that coupling could be made more explicit in the doc?  Or
 > maybe that "enhancement" should be reverted?

Did you find out when that enhancement was made?

 >> IMO `modify-frame-parameters' should keep the frame size and
 >> everything else unchanged when changing the font.
 >
 > IMO, it should not.  Such an incompatible change will break all of the code I
 > mentioned, for one thing.

I understand that meanwhile.

 > Why do you suppose that there is an optional parameter KEEP-SIZE for
 > `set-frame-font'?

... because on 2003-04-09 Ehud Karni added it ...

 > And why do you suppose it is optional (i.e., the default
 > behavior does NOT keep the same size)?

... because that's how it behaved on the first day.

 > And now you propose to, in effect, impose KEEP-SIZE behavior everywhere, and not
 > even provide a no-keep-size optional behavior (i.e., traditional Emacs
 > behavior)?

I did so and still think it's the correct answer in an environment that
has to cater for fullscreen and maximized frames as well as for tiling
window managers.  I don't think that zooming the font size in any of
these modes should change the frame size.

 >> Changing the appearance of scrollbars, fringes and sizes or the
 >> appearance of future frames should be done on top of that,
 >
 > You are mixing a lot of things in there.

Not me.  When you change the font size these are the things Emacs
changes along with it.

 > Why should `modify-frame-parameters', applied to a single frame, affect future
 > frames at all?

Maybe because when it creates a new frame Emacs has it inherit certain
things from the selected one?

 > That mistake was already introduced into `set-frame-font' (in Emacs 22, I
 > believe).  Such future-changing has no business being coupled into the behavior
 > of the basic function for changing a frame's parameters.

As I said above, that function was probably supposed to set the default
value.  In any case, I'm confident/afraid that people had good reasons
for applying such a change.

 > The non-independence of some frame parameters is a general condition - not
 > specific to `modify-frame-parameters' at all.

Yes.  But I would remove such interdependence wherever possible.

 > And I trust you and your knowledge of windows and frames,

... my knowledge of frames is slightly above zero ....

 > which is certainly far
 > beyond mine.  It's possible for your knowledge and my particular experience to
 > work together.
 >
 > I know that because it has happened before.  You have fixed badly broken frame
 > behavior several times now, working with info about my particular experience.  I
 > thank you again for all that patient and careful work.
 >
 > One thing that seems unfortunate to me is the coupling of (a) changing a
 > parameter value for a single frame with (b) changing the default value of that
 > parameter for future frames.  IIUC, that is what `set-frame-font' does now, and
 > it seems wrong to me.  Are there other parameter-setting functions that also act
 > like that?

I have no idea.  And I never managed to understand the interactions of
initial, default, and actual parameters of frames.

martin

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

[Drew Adams]

>  > Maybe the logic behind that coupling could be made more 
>  > explicit in the doc?  Or maybe that "enhancement" should
>  > be reverted?
> 
> Did you find out when that enhancement was made?

I think we're talking about this behavior:

 Also, if FRAME is non-nil, alter the user's Customization
 settings as though the font-related attributes of the
 `default' face had been \"set in this session\", so that
 the font is applied to future frames.

Emacs 24.1 added this, AFAICT.  It added optional 3rd arg FRAMES for
`set-frame-font'.

But see my earlier msg where I mention that I do not in fact see the
future-changing behavior that is advertised for new frames.  Do you see it?

(Wrt the optional 2nd arg KEEP-SIZE, it was Emacs 22 that added that.)

>  > Why do you suppose that there is an optional parameter 
>  > KEEP-SIZE for `set-frame-font'?
> 
> ... because on 2003-04-09 Ehud Karni added it ...
> 
>  > And why do you suppose it is optional (i.e., the default
>  > behavior does NOT keep the same size)?
> 
> ... because that's how it behaved on the first day.
> 
>  > And now you propose to, in effect, impose KEEP-SIZE 
>  > behavior everywhere, and not even provide a no-keep-size
>  > optional behavior (i.e., traditional Emacs behavior)?
> 
> I did so and still think it's the correct answer in an 
> environment that has to cater for fullscreen and maximized
> frames as well as for tiling window managers.  I don't think
> that zooming the font size in any of these modes should
> change the frame size.

Use `set-frame-font' with non-nil KEEP-SIZE if you do not want the frame to zoom
along with its text and you want to change how much text is visible in the same
frame.  That's what KEEP-SIZE is for.

>  >> Changing the appearance of scrollbars, fringes and sizes or the
>  >> appearance of future frames should be done on top of that,
>  >
>  > You are mixing a lot of things in there.
> 
> Not me.  When you change the font size these are the things Emacs
> changes along with it.

The scrollbars and the fringe are not changed when the frame font size is
changed.  Not on MS Windows, at least.  Prior to Emacs 22, the scrollbars (but
not fringe) were zoomed along with the text.

The big thing that doesn't belong mixed in with the others is changing the
appearance of future frames.  Changing a frame parameter in one frame should not
affect future frames.

>  > Why should `modify-frame-parameters', applied to a single 
>  > frame, affect future frames at all?
> 
> Maybe because when it creates a new frame Emacs has it inherit
> certain things from the selected one?

Certain things are inherited from the selected frame.
But you want to change which things are inherited.

And now you bring in "the selected one".  In the proposal, IIUC, ALL future
frames would have their font size changed, not just those frames created when
the altered frame happens to be selected.

>  > That mistake was already introduced into `set-frame-font' 
>  > (in Emacs 22, I believe).  Such future-changing has no
>  > business being coupled into the behavior of the basic
>  > function for changing a frame's parameters.
> 
> As I said above, that function was probably supposed to set 
> the default value.  In any case, I'm confident/afraid that
> people had good reasons for applying such a change.

I consider it a mistake.  But I'm not trying to fix/change `set-frame-font'
here.  And as I said, I do NOT even SEE the (misguided) future-changing behavior
that its doc claims for it.

My concern is to keep `modify-frame-parameters' doing the right thing wrt
parameter `font'.

If someone wants to get the affect you prefer then s?he can use `set-frame-font'
with non-nil KEEP-SIZE (but I think that function might need to be "fixed" so
that actually works).

There is no good reason to change `modify-frame-parameters' so that such odd
behavior (not even the default for `set-frame-font') becomes the new norm.

> ... my knowledge of frames is slightly above zero ....

I have more experience with my particular use of frames.  You are far more
knowledgable about the frame-affecting code, I'm sure.

>  > One thing that seems unfortunate to me is the coupling of 
>  > (a) changing a parameter value for a single frame with
>  > (b) changing the default value of that parameter for
>  > future frames.  IIUC, that is what `set-frame-font' does
>  > now, and it seems wrong to me.  Are there other
>  > parameter-setting functions that also act like that?
> 
> I have no idea.

I don't think there are.

> And I never managed to understand the interactions of
> initial, default, and actual parameters of frames.

;-)

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

[martin rudalics]

 > I think we're talking about this behavior:
 >
 >  Also, if FRAME is non-nil, alter the user's Customization
 >  settings as though the font-related attributes of the
 >  `default' face had been \"set in this session\", so that
 >  the font is applied to future frames.
 >
 > Emacs 24.1 added this, AFAICT.  It added optional 3rd arg FRAMES for
 > `set-frame-font'.

I see.  It's probably for the sake of `menu-set-font' which calls it
with t as third argument.  And `set-frame-font' has

	   (frame-list (cond ((null frames)
			      (list this-frame))
			     ((eq frames t)
			      (frame-list))
			     (t frames)))

so any non-t value will not affect other existing frames.  But any
non-nil FRAMES value will "alter the user's Custom setting of the
`default' face, but only for font-related attributes" whatever that
means.  Maybe it should do that iff FRAMES equals t.

 > But see my earlier msg where I mention that I do not in fact see the
 > future-changing behavior that is advertised for new frames.  Do you see it?

If you gave me a recipe for what to try.  I haven't touched my font
related Emacs settings for ages - the effect was that I usually ended up
with a completely messed up frame.  Do you see a changed default face at
least when you call that function?

 >> I did so and still think it's the correct answer in an
 >> environment that has to cater for fullscreen and maximized
 >> frames as well as for tiling window managers.  I don't think
 >> that zooming the font size in any of these modes should
 >> change the frame size.
 >
 > Use `set-frame-font' with non-nil KEEP-SIZE if you do not want the frame to zoom
 > along with its text and you want to change how much text is visible in the same
 > frame.  That's what KEEP-SIZE is for.

I can only repeat that I won't change the behavior of
`modify-frame-parameters' wrt the font parameter if you don't want it.
But this means that the interaction of `modify-frame-parameters' with
window managers will remain as it is now.  I won't change its behavior
wrt fringes or scrollbars only.

 > The scrollbars and the fringe are not changed when the frame font size is
 > changed.  Not on MS Windows, at least.  Prior to Emacs 22, the scrollbars (but
 > not fringe) were zoomed along with the text.

Here on MS Windows the Emacs 24.3 fringe zooms along with the text.  The
scrollbar currently doesn't - but it has larger increments IIRC.

 > The big thing that doesn't belong mixed in with the others is changing the
 > appearance of future frames.  Changing a frame parameter in one frame should not
 > affect future frames.

Do I understand correctly that `modify-frame-parameters' never affects
future frames?

 >> Maybe because when it creates a new frame Emacs has it inherit
 >> certain things from the selected one?
 >
 > Certain things are inherited from the selected frame.
 > But you want to change which things are inherited.

Why do you say such a thing?  Apart from the current buffer I wouldn't
even know what is inherited.

 > And now you bring in "the selected one".  In the proposal, IIUC, ALL future
 > frames would have their font size changed, not just those frames created when
 > the altered frame happens to be selected.

If "the proposal" stands for my earlier suggestion to use
`set-frame-font' instead of `modify-frame-parameters', then I obviously
withdraw that suggestion provided we cannot turn off the impact on
future frames.

 > I consider it a mistake.  But I'm not trying to fix/change `set-frame-font'
 > here.  And as I said, I do NOT even SEE the (misguided) future-changing behavior
 > that its doc claims for it.

This would mean we have two bugs already.

 > My concern is to keep `modify-frame-parameters' doing the right thing wrt
 > parameter `font'.

And my concern was to change the conception on what the right thing wrt
parameter `font' is.

 > If someone wants to get the affect you prefer then s?he can use `set-frame-font'
 > with non-nil KEEP-SIZE (but I think that function might need to be "fixed" so
 > that actually works).
 >
 > There is no good reason to change `modify-frame-parameters' so that such odd
 > behavior (not even the default for `set-frame-font') becomes the new norm.

That "odd behavior" is the standard here with applications like Firefox,
Thunderbird, ...  The fact that Emacs is special doesn't give me a valid
reason to call the rest of the world odd.

martin

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

[Drew Adams]

>  > Emacs 24.1 added this, AFAICT.  It added optional 3rd arg 
>  > FRAMES for `set-frame-font'.
> 
> I see.  It's probably for the sake of `menu-set-font' which calls it
> with t as third argument.  And `set-frame-font' has
> 	   (frame-list (cond ((null frames)
> 			      (list this-frame))
> 			     ((eq frames t)
> 			      (frame-list))
> 			     (t frames)))
> so any non-t value will not affect other existing frames.  But any
> non-nil FRAMES value will "alter the user's Custom setting of the
> `default' face, but only for font-related attributes" whatever that
> means.  Maybe it should do that iff FRAMES equals t.

Maybe.  Or maybe KEEP-SIZE is not really needed?  (Dunno.)

>  > But see my earlier msg where I mention that I do not in 
>  > fact see the future-changing behavior that is advertised
>  > for new frames.  Do you see it?
> 
> If you gave me a recipe for what to try.

I did, starting from emacs -Q.  Please see my msg of 2013-04-28:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14233#272.  Let me know if
something in that recipe is not clear.

> Do you see a changed default face at least when you call that function?

Please see what I wrote.  I detailed what Emacs tells me about face `default',
which seems to depend on the current frame and something else.  AFAICT, it does
not work as advertised, at least on MS Windows.

> I can only repeat that I won't change the behavior of
> `modify-frame-parameters' wrt the font parameter if you don't want it.

Thank you.

> But this means that the interaction of `modify-frame-parameters' with
> window managers will remain as it is now.  I won't change its behavior
> wrt fringes or scrollbars only.

I can't speak to that.  I'm not sure what changes wrt fringe/scrollbars you had
in mind.

>  > The scrollbars and the fringe are not changed when the 
>  > frame font size is changed.  Not on MS Windows, at least.
>  > Prior to Emacs 22, the scrollbars (but not fringe) were
>  > zoomed along with the text.
> 
> Here on MS Windows the Emacs 24.3 fringe zooms along with the text.

Really?  Here it does not, and never has, ever since fringe has existed (Emacs
21).

I change only the `font' parameter, substituting a different number for the
height/size in the font string.  The fringe remains the same width.  I can
shrink or enlarge the font (and hence the frame) more and more, but the fringe
width stays the same.

> The scrollbar currently doesn't - but it has larger increments IIRC.

I believe I was told that this is a toolkit thing (or something like that).  The
scrollbar changed size when you changed the font size prior to Emacs 21.  Since
21 it has not changed size along with the font.

I just now retested all of this (scroll bars, fringe), from emacs -Q, in Emacs
20, 21, and 24.  Changing only frame parameter `font', and only wrt the
height/size, has the effect I just described, in MS Windows XP (SP3).

>  > The big thing that doesn't belong mixed in with the others 
>  > is changing the appearance of future frames.  Changing a frame
>  > parameter in one frame should not affect future frames.
> 
> Do I understand correctly that `modify-frame-parameters' never affects
> future frames?

I believe that is correct.  It affects only its targeted frame.

>  >> Maybe because when it creates a new frame Emacs has it inherit
>  >> certain things from the selected one?
>  >
>  > Certain things are inherited from the selected frame.
>  > But you want to change which things are inherited.
> 
> Why do you say such a thing?  Apart from the current buffer I wouldn't
> even know what is inherited.

I guess I misunderstood your proposal, sorry.

>  > And now you bring in "the selected one".  In the proposal, 
>  > IIUC, ALL future frames would have their font size changed,
>  > not just those frames created when the altered frame happens
>  > to be selected.
> 
> If "the proposal" stands for my earlier suggestion to use
> `set-frame-font' instead of `modify-frame-parameters', then I 
> obviously withdraw that suggestion provided we cannot turn off
> the impact on future frames.

Great.  Let's not argue about what might have been proposed or misunderstood as
having been proposed.  What is important is what the behavior is and will/should
be.

My concerns, which I'm sure you understand, are these:

a. `modify-frame-parameters' should not be changed so that it affects future
behavior.

b. Changing the `font' parameter of a frame should also shrink/enlarge the
frame, as it does today.  That is, shrink/enlarge in terms of screen size
(pixels), but not in terms of number of lines/cols.  IOW, the frame size should
keep the same number of lines/cols.

Wrt (b):

1. Keeping the same number of lines/cols when the `font' size changes does not
mean that the frame must be an integral number of lines/cols, AFAIK.  I too want
frames to be sizable in terms of pixels.  All I am saying for (b) is that the
lines/cols should remain the same when changing the `font' size, as is the case
now.  Numbers of additional pixels can be different.

2. If someone needs/wants to be able to change the `font' parameter without
changing the frame size, I am not against providing such an option somehow.
That was apparently what was done for `set-frame-font' by adding the new
optional parameter KEEP-SIZE.  So presumably this want/need has already been
satisfied.

>  > I consider it a mistake.  But I'm not trying to fix/change 
>  > `set-frame-font' here.  And as I said, I do NOT even SEE the
>  > (misguided) future-changing behavior that its doc claims for it.
> 
> This would mean we have two bugs already.
> 
>  > My concern is to keep `modify-frame-parameters' doing the 
>  > right thing wrt parameter `font'.
> 
> And my concern was to change the conception on what the right 
> thing wrt parameter `font' is.

My impression is that perhaps in the desire to allow better sizing of frames
pixelwise you would abandon the fact that resizing the `font' resizes the frame
accordingly so that the number of displayed lines/cols remains the same.

I don't think that should be necessary.  I understand that pixels not directly
related to text display might need to be different for different `font' (hence
frame) sizes.  But I think we should be able to keep the same lines/cols
displayed.

Now, when embedded images are involved, for example, since they are not related
to the `font' size, they will not shrink/enlarge along with the `font' and
frame.  So in that case the lines/cols would not be the same.  Likewise for tool
bars etc., as is already the case today.

Changing the frame `font' size zooms only the text.  Other forms of zooming
would need to be combined with that to also shrink/enlarge non-text things.

But wrt text display it is important (to me anyway) that the frame try to show
the same text display, regardless of its size: same lines/cols, which means also
same overall text appearance.

If someone wants to zoom the text of a buffer without also shrinking the frame,
s?he can use `text-scale-adjust'.

>  > If someone wants to get the affect you prefer then s?he can use
>  > `set-frame-font' with non-nil KEEP-SIZE (but I think that
>  > function might need to be "fixed" so that actually works).
>  >
>  > There is no good reason to change `modify-frame-parameters' so
>  > that such odd behavior (not even the default for `set-frame-font') 
>  > becomes the new norm.
> 
> That "odd behavior" is the standard here with applications 
> like Firefox, Thunderbird, ...  The fact that Emacs is special
> doesn't give me a valid reason to call the rest of the world odd.

OK, yes, let me say that both behaviors should be possible.  Some people,
sometimes, will want the frame to stay the same size when they shrink/enlarge
its text.  Other people, other times, will want the frame to shrink/enlarge
along with the text.

I am generally in the latter camp, because I save screen real estate when I
shrink frames (including to thumbnail size).  I use many frames, often visible
at the same time.  Someone who uses frames the way one might use tabs in a web
browser, i.e., showing only one frame at a time, will prefer a different
behavior, no doubt.

We should be able to accommodate both use cases.

If you looked at my screen now, you would see several frames at different font
sizes and thus different frame sizes.  Some are even just thumbnails - almost
like icons.  I dynamically enlarge particular frames that I want to focus more
on, while others are shrunk to different degrees so I can still see their text
clearly but they do not take up as much space.

I do not claim that my use of Emacs frames is a common one, but I do know that
there are some others who use it.

BTW, I will note that even when I enlarge text size in a web browser I often
also (manually) increase the browser size so that the text lines fit better.
Likewise, when I decrease the text size I often narrow the browser window, so
the lines are shorter.

There is a reason that newspapers (which are wide) divide the text into columns,
even when there is only one article on the page: long lines are harder to read.

Line length is typically determined by browser width, and for the same reason
that newspapers shorten lines by creating columns, it can make sense for a user
to resize the browser window when s?he changes the text size.

Do many users bother to resize their browser when they resize text?  Dunno,
probably not.  But I do, quite often.

(Many readers probably never resize browser text.  And many browser pages are in
fact divided into columns.  And many other browser pages prevent you from
resizing the text at all.)

The point here is that with a web browser you have to perform two separate
operations: resize the text and then resize the window to best fit the new text
size.

In Emacs, zooming the frame font is the same as zooming the frame: they move
together in a coordinated way, so that what you see remains pretty much the
same: same lines/cols, same line width (in terms of number of chars).

Best will be to let users (a) have this convenient, coordinated behavior or (b)
optionally choose, for a *given frame* or *generally*, the typical web-browser
behavior of keeping the frame size fixed when zooming.

Being able to calculate the pixel size needed to display a given buffer portion,
which I hope will also be provided by this bug fix, is something I've been
hoping for for a long time.  But it is independent, I think, of trying to let a
frame keep the same number of displayed lines/cols when shrunk/enlarged.

Similarly, not constraining a frame size to char multiples (this bug report's
subject) is, I think, pretty much independent of whether a frame tries to keep
the same lines/cols displayed when zoomed.

Yes, exact fitting of a frame to a particular pixel size will often forego
maintaining the same number of displayed lines/cols - of course.  That is
something different from zooming.

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

[martin rudalics]

 >> I see.  It's probably for the sake of `menu-set-font' which calls it
 >> with t as third argument.  And `set-frame-font' has
 >> 	   (frame-list (cond ((null frames)
 >> 			      (list this-frame))
 >> 			     ((eq frames t)
 >> 			      (frame-list))
 >> 			     (t frames)))
 >> so any non-t value will not affect other existing frames.  But any
 >> non-nil FRAMES value will "alter the user's Custom setting of the
 >> `default' face, but only for font-related attributes" whatever that
 >> means.  Maybe it should do that iff FRAMES equals t.
 >
 > Maybe.  Or maybe KEEP-SIZE is not really needed?  (Dunno.)

I don't see what KEEP-SIZE has to do with this.

 >>  > But see my earlier msg where I mention that I do not in
 >>  > fact see the future-changing behavior that is advertised
 >>  > for new frames.  Do you see it?
 >>
 >> If you gave me a recipe for what to try.
 >
 > I did, starting from emacs -Q.  Please see my msg of 2013-04-28:
 > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14233#272.  Let me know if
 > something in that recipe is not clear.

Honestly, I don't understand the customization stuff you mention there.

 >> Do you see a changed default face at least when you call that function?

Yes.  That is, when I invoke `menu-set-font' (which calls
`set-frame-font') I see that the default face changed.

 > Please see what I wrote.  I detailed what Emacs tells me about face `default',
 > which seems to depend on the current frame and something else.  AFAICT, it does
 > not work as advertised, at least on MS Windows.

When I change my font via `menu-set-font' to

"-outline-Lucida Console-normal-normal-normal-mono-21-*-*-*-c-*-iso8859-1"

I get as (face-font 'default) that value and when I do C-x 5 2 I get a
new frame with precisely that font.

 >> Here on MS Windows the Emacs 24.3 fringe zooms along with the text.
 >
 > Really?  Here it does not, and never has, ever since fringe has existed (Emacs
 > 21).

Using `menu-set-font' I can produce with emacs 24.3

(frame-parameter nil 'font) ; =>
"-outline-Lucida Console-normal-normal-normal-mono-16-*-*-*-c-*-iso8859-1"
(window-fringes) ; =>
(10 10 nil)
(frame-parameter nil 'font) ; =>
"-outline-Lucida Console-normal-normal-normal-mono-21-*-*-*-c-*-iso8859-1"
(window-fringes) ; =>
(13 13 nil)

Whether this actually results in a visible change is a stochastic
phenomena whose behavior I can't describe yet.  Maybe I never will be
able to do so.  But eventually the size of at least one fringe changes.

 > I change only the `font' parameter, substituting a different number for the
 > height/size in the font string.  The fringe remains the same width.  I can
 > shrink or enlarge the font (and hence the frame) more and more, but the fringe
 > width stays the same.

Maybe some rounding effect?  Also, as I mentioned, fringe changes get
sometimes miraculously delayed.

 >> The scrollbar currently doesn't - but it has larger increments IIRC.
 >
 > I believe I was told that this is a toolkit thing (or something like that).  The
 > scrollbar changed size when you changed the font size prior to Emacs 21.  Since
 > 21 it has not changed size along with the font.

I wouldn't be that sure.  You might have to play around some time with
very large sizes.  There's all sorts of rounding effects when adjusting
these parameters.

 > I just now retested all of this (scroll bars, fringe), from emacs -Q, in Emacs
 > 20, 21, and 24.  Changing only frame parameter `font', and only wrt the
 > height/size, has the effect I just described, in MS Windows XP (SP3).

I could experiment further but it's too annoying because my frame always
gets larger than my screen.

 > My concerns, which I'm sure you understand, are these:
 >
 > a. `modify-frame-parameters' should not be changed so that it affects future
 > behavior.

My concern is that it should be changed.

 > b. Changing the `font' parameter of a frame should also shrink/enlarge the
 > frame, as it does today.  That is, shrink/enlarge in terms of screen size
 > (pixels), but not in terms of number of lines/cols.  IOW, the frame size should
 > keep the same number of lines/cols.

I'd prefer the frame + external objects to keep the same number of pixels.

 > Wrt (b):
 >
 > 1. Keeping the same number of lines/cols when the `font' size changes does not
 > mean that the frame must be an integral number of lines/cols, AFAIK.  I too want
 > frames to be sizable in terms of pixels.  All I am saying for (b) is that the
 > lines/cols should remain the same when changing the `font' size, as is the case
 > now.  Numbers of additional pixels can be different.

OK

 > 2. If someone needs/wants to be able to change the `font' parameter without
 > changing the frame size, I am not against providing such an option somehow.
 > That was apparently what was done for `set-frame-font' by adding the new
 > optional parameter KEEP-SIZE.  So presumably this want/need has already been
 > satisfied.

But not for `modify-frame-parameters'.  And that's the problem.  When
you change the frame size you have to contact your window manager, wait
till it gets back to you, and then you have to fit all your objects into
the space alloted by the window manager.  Now, obviously you have to do
all these things also when you just resize the frame.  But in that case
you didn't change the font.  Or if you did, you did it without intending
to change the frame size with it.

An action like changing both frame size and font in some coordinated
sense is per se complicated and I'd rather do it only when not changing
anything else.  And that's why I don't want this to be handled by
`modify-frame-parameters' where one can change any other parameter as
well.  There should be one special function to change font and frame
size in a coordinated manner and when people call that function, for
example, for zooming, they should not set other frame parameters at the
same time.  And if they do, they might be on their own.

 > My impression is that perhaps in the desire to allow better sizing of frames
 > pixelwise you would abandon the fact that resizing the `font' resizes the frame
 > accordingly so that the number of displayed lines/cols remains the same.
 >
 > I don't think that should be necessary.  I understand that pixels not directly
 > related to text display might need to be different for different `font' (hence
 > frame) sizes.  But I think we should be able to keep the same lines/cols
 > displayed.

But you probably agree that we should not change the pixel size of a
maximized frame.  In any case, my concern is to make frame parameter
handling via `modify-frame-parameters' predictable, in some sense at
least.  Currently, I'm completely lost in a jungle of things that get
processed in some incomprehensible fashion.

 > Now, when embedded images are involved, for example, since they are not related
 > to the `font' size, they will not shrink/enlarge along with the `font' and
 > frame.  So in that case the lines/cols would not be the same.  Likewise for tool
 > bars etc., as is already the case today.

Are you sure?  What if toolbars have accompanying text?

 > Changing the frame `font' size zooms only the text.

Not here.

 > Other forms of zooming
 > would need to be combined with that to also shrink/enlarge non-text things.
 >
 > But wrt text display it is important (to me anyway) that the frame try to show
 > the same text display, regardless of its size: same lines/cols, which means also
 > same overall text appearance.
 >
 > If someone wants to zoom the text of a buffer without also shrinking the frame,
 > s?he can use `text-scale-adjust'.

I don't care about the functions for achieving some specific effect.  I
care about the basic functionality of `modify-frame-parameters'.

 > Being able to calculate the pixel size needed to display a given buffer portion,
 > which I hope will also be provided by this bug fix, is something I've been
 > hoping for for a long time.  But it is independent, I think, of trying to let a
 > frame keep the same number of displayed lines/cols when shrunk/enlarged.

Mostly so, I hope.

martin

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

[Drew Adams]

>  >> I see.  It's probably for the sake of `menu-set-font' 
>  >> which calls it with t as third argument.  And `set-frame-font' has
>  >> 	   (frame-list (cond ((null frames)
>  >> 			      (list this-frame))
>  >> 			     ((eq frames t)
>  >> 			      (frame-list))
>  >> 			     (t frames)))
>  >> so any non-t value will not affect other existing frames.  But any
>  >> non-nil FRAMES value will "alter the user's Custom setting of the
>  >> `default' face, but only for font-related attributes" 
>  >> whatever that means.  Maybe it should do that iff FRAMES equals t.
>  >
>  > Maybe.  Or maybe KEEP-SIZE is not really needed?  (Dunno.)
> 
> I don't see what KEEP-SIZE has to do with this.

My bad.  The disjointedness of our edited emails made me think somehow that this
was about KEEP-SIZE, not FRAMES.  IOW, I lost the thought thread.

>  >>  > But see my earlier msg where I mention that I do not in
>  >>  > fact see the future-changing behavior that is advertised
>  >>  > for new frames.  Do you see it?
>  >>
>  >> If you gave me a recipe for what to try.
>  >
>  > I did, starting from emacs -Q.  Please see my msg of 2013-04-28:
>  > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14233#272.  
>  > Let me know if something in that recipe is not clear.
> 
> Honestly, I don't understand the customization stuff you 
> mention there.

My bad again.  In the recipe I gave, I used what I intended as the FRAMES arg as
the KEEP-SIZE arg, and so I actually omitted the FRAMES arg.

So I take back what I said about it not doing what is documented.
Sorry for that noise.

>  >> Here on MS Windows the Emacs 24.3 fringe zooms along with 
>  >> the text.
>  >
>  > Really?  Here it does not, and never has, ever since 
>  > fringe has existed (Emacs 21).
> 
> Using `menu-set-font' I can produce with emacs 24.3
> 
> (frame-parameter nil 'font) ; =>
> "-outline-Lucida 
> Console-normal-normal-normal-mono-16-*-*-*-c-*-iso8859-1"
> (window-fringes) ; =>
> (10 10 nil)
> (frame-parameter nil 'font) ; =>
> "-outline-Lucida 
> Console-normal-normal-normal-mono-21-*-*-*-c-*-iso8859-1"
> (window-fringes) ; =>
> (13 13 nil)
> 
> Whether this actually results in a visible change is a stochastic
> phenomena whose behavior I can't describe yet.  Maybe I never will be
> able to do so.  But eventually the size of at least one 
> fringe changes.

I see; good test.  I was only judging by appearance, and I was judging poorly.
Looking closer now, I can see that the fringe does change size.

But it does not change proportionately wrt the font change.

With font size 25 I see fringe of width 15 (ratio: 1.667)
               13                        8 (ratio: 1.625)
                9                       10 (ratio: 1.111)

And the last two lines really make one wonder.  Anyway, you are correct that the
fringe does get resized.  But zooming the font does not zoom the fringe
similarly.

Anyway, let's not won't worry too much about the fringe behavior, for now. 

>  >> The scrollbar currently doesn't - but it has larger 
>  >> increments IIRC.
>  >
>  > I believe I was told that this is a toolkit thing (or 
>  > something like that).  The scrollbar changed size when
>  > you changed the font size prior to Emacs 21.  Since
>  > 21 it has not changed size along with the font.
> 
> I wouldn't be that sure.  You might have to play around some
> time with very large sizes.  There's all sorts of rounding
> effects when adjusting these parameters.

Large sizes of the font?  I just tried up to size 200 (chars several cm high),
and the scroll bar stayed (visibly) the same.  (I didn't check the parameter
values.)

> I could experiment further but it's too annoying because my 
> frame always gets larger than my screen.

Try going smaller rather than larger.

>  > My concerns, which I'm sure you understand, are these:
>  >
>  > a. `modify-frame-parameters' should not be changed so that 
>  > it affects future behavior.
> 
> My concern is that it should be changed.

Why should it?  Why should modifying one frame affect all future frames?  That
makes no sense to me.  If you make one frame background light blue, do you
expect all future frames to also have a light blue background?  If so, why?

Much as I could be persuaded wrt whether `modify-frame-parameters' should zoom
the frame size when you zoom the `font' parameter, I do not see any
justification for `modify-frame-parameters' affecting other than the targeted
frame.  That just sounds perverse to me, and I expect it would lead to all kinds
of unwelcome behavior.

>  > b. Changing the `font' parameter of a frame should also 
>  > shrink/enlarge the frame, as it does today.  That is,
>  > shrink/enlarge in terms of screen size (pixels), but not
>  > in terms of number of lines/cols.  IOW, the frame size should
>  > keep the same number of lines/cols.
> 
> I'd prefer the frame + external objects to keep the same 
> number of pixels.

As I said, the choice should be up to the user.  Different users will have
different use cases (and preferences), and the same user will have different use
cases at different times.

>  > Wrt (b):
>  >
>  > 1. Keeping the same number of lines/cols when the `font' 
>  > size changes does not mean that the frame must be an
>  > integral number of lines/cols, AFAIK.  I too want
>  > frames to be sizable in terms of pixels.  All I am saying 
>  > for (b) is that the lines/cols should remain the same when
>  > changing the `font' size, as is the case
>  > now.  Numbers of additional pixels can be different.
> 
> OK
> 
>  > 2. If someone needs/wants to be able to change the `font' 
>  > parameter without changing the frame size, I am not against
>  > providing such an option somehow.  That was apparently what
>  > was done for `set-frame-font' by adding the new
>  > optional parameter KEEP-SIZE.  So presumably this 
>  > want/need has already been satisfied.
> 
> But not for `modify-frame-parameters'.  And that's the problem.

Why is it necessary for `modify-frame-parameters' to behave like
`set-frame-size' with a non-nil (thus non-default) KEEP-SIZE argument, and wrong
for `modify-frame-parameters' to behave like `set-frame-size' with a nil (thus
default) KEEP-SIZE argument?

> When you change the frame size you have to contact your window 
> manager, wait till it gets back to you, and then you have to
> fit all your objects into the space alloted by the window manager.
> Now, obviously you have to do all these things also when you just
> resize the frame.  But in that case you didn't change the font.
> Or if you did, you did it without intending to change the frame
> size with it.

I cannot speak to the implementation concerns.  I'm speaking in user terms.

> An action like changing both frame size and font in some coordinated
> sense is per se complicated and I'd rather do it only when 
> not changing anything else.  And that's why I don't want this
> to be handled by `modify-frame-parameters' where one can change
> any other parameter as well.  There should be one special
> function to change font and frame size in a coordinated manner
> and when people call that function, for example, for zooming,
> they should not set other frame parameters at the
> same time.  And if they do, they might be on their own.

Well stated.  We just disagree, I guess.

>  > My impression is that perhaps in the desire to allow 
>  > better sizing of frames pixelwise you would abandon
>  > the fact that resizing the `font' resizes the frame
>  > accordingly so that the number of displayed lines/cols 
>  > remains the same.
>  >
>  > I don't think that should be necessary.  I understand that 
>  > pixels not directly related to text display might need to
>  > be different for different `font' (hence frame) sizes.
>  > But I think we should be able to keep the same lines/cols
>  > displayed.
> 
> But you probably agree that we should not change the pixel size of a
> maximized frame.

By definition, a maximized frame is outside the notion of zooming a frame, that
is, where zooming includes changing the frame size.  So it is irrelevant to what
I'm talking about.

For the kind of zooming I'm talking about, either zooming larger would no longer
be available once the maximum size is reached or it would be available beyond
the "maximum", which is really just the screen size.  The latter is the case
today, BTW: you can zoom a frame larger than the screen.

> In any case, my concern is to make frame parameter handling
> via `modify-frame-parameters' predictable, in some sense at least.

I think we agree on that.

> Currently, I'm completely lost in a jungle of things that get
> processed in some incomprehensible fashion.

You are no doubt trying to understand a much bigger picture than I'm looking at,
and that is needed here, I recognize.  I would submit that for the use case I'm
talking about, zooming a frame (its size and its font size), things are pretty
straightforward from a user perspective and in terms of appearances.

Yes, I'm not too concerned with other parameters besides `font' wrt this use
case.  I don't really care much what the sizes of fringe and scroll bars are.
Not that they are not important, but they are not very important to my use case.

In the end, you will probably do what you're suggesting, and I will probably end
up using `set-frame-font' instead of `modify-frame-parameters' to continue to
get the effect I want.  (For Emacs 20 & 21 there was no KEEP-SIZE parameter, so
I'll need to use `modify-frame-parameters' for those cases.)

I guess I'm saying that, provided that there is some sensitivity to continuing
to make the behavior I currently take advantage of available, in some way (e.g.
`set-frame-font'), I would probably be OK with your changing
`modify-frame-parameters' along the lines you suggest.

At least I have confidence that you will remain open to reported problems and
you will no doubt DTRT.

As I hinted earlier, I would like, eventually, to see the same kind of
`KEEP-SIZE' behavior available for zooming other things, besides `font'.

For example, when zooming a frame (which for me, again, means shrinking both its
content and its size), if it contains images then I would want to be able to
shrink the images as well (modulo losing resolution, of course), in such a way
that what appears in the frame remains essentially the same (unlike the case of
a web browser, for example).

>  > Now, when embedded images are involved, for example, since 
>  > they are not related to the `font' size, they will not
>  > shrink/enlarge along with the `font' and
>  > frame.  So in that case the lines/cols would not be the 
>  > same.  Likewise for tool bars etc., as is already the case today.
> 
> Are you sure?  What if toolbars have accompanying text?

I meant the toolbar images.

>  > Changing the frame `font' size zooms only the text.
> 
> Not here.

For me, on MS Windows, changing option `tool-bar-style' to include text has no
effect: I never see any text, just images.  And the doc string says this:

  This variable only affects the GTK+ toolkit version of Emacs.

>  > But wrt text display it is important (to me anyway) that 
>  > the frame try to show the same text display, regardless of
>  > its size: same lines/cols, which means also same overall
>  > text appearance.
>  >
>  > If someone wants to zoom the text of a buffer without also 
>  > shrinking the frame, s?he can use `text-scale-adjust'.
> 
> I don't care about the functions for achieving some specific 
> effect.  I care about the basic functionality of
> `modify-frame-parameters'.

OK.  But my concern is that we not lose something that users have today.  Wrt
font zooming also zooming frame size, I guess we won't lose, since we can use
`set-frame-font' with nil `KEEP-SIZE'.

>  > Being able to calculate the pixel size needed to display a 
>  > given buffer portion, which I hope will also be provided by
>  > this bug fix, is something I've been hoping for for a long
>  > time.  But it is independent, I think, of trying to let a
>  > frame keep the same number of displayed lines/cols when 
>  > shrunk/enlarged.
> 
> Mostly so, I hope.

Thanks for your discussion and consideration of my use case.  I have confidence
that in the end things will work out well, since you are working on this.
Seriously.

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

[martin rudalics]

 > But it does not change proportionately wrt the font change.
 >
 > With font size 25 I see fringe of width 15 (ratio: 1.667)
 >                13                        8 (ratio: 1.625)
 >                 9                       10 (ratio: 1.111)
 >
 > And the last two lines really make one wonder.  Anyway, you are correct that the
 > fringe does get resized.  But zooming the font does not zoom the fringe
 > similarly.

All this happens in a routine called compute_fringe_widths in fringe.c.
And it's a real pain because it tries to reconcile things like fixed
fringe widths (encoded via negative values), asymmetric resizing, and
rounding to character widths.  All this is not really harmful per se but
can eventually affect the width of the displayed frame and _when_ that
happens is pretty unpredictable.  Finally, frame fringes have to be
somewhere reconciled with buffer-local and window-local fringes.

 > Anyway, let's not won't worry too much about the fringe behavior, for now.

Well, I do.

 > Large sizes of the font?  I just tried up to size 200 (chars several cm high),
 > and the scroll bar stayed (visibly) the same.  (I didn't check the parameter
 > values.)

Conceptually x_new_font in w32term.c changes fringes and scrollbars
thusly

   compute_fringe_widths (f, 1);

   /* Compute the scroll bar width in character columns.  */
   if (FRAME_CONFIG_SCROLL_BAR_WIDTH (f) > 0)
     {
       int wid = FRAME_COLUMN_WIDTH (f);
       FRAME_CONFIG_SCROLL_BAR_COLS (f)
	= (FRAME_CONFIG_SCROLL_BAR_WIDTH (f) + wid - 1) / wid;
     }
   else
     {
       int wid = FRAME_COLUMN_WIDTH (f);
       FRAME_CONFIG_SCROLL_BAR_COLS (f) = (14 + wid - 1) / wid;
     }

If we don't see an effect, it might be due to some rounding or a missing
request to the window manager.

 >> I could experiment further but it's too annoying because my
 >> frame always gets larger than my screen.
 >
 > Try going smaller rather than larger.

Then I won't see anything any more.

 >>  > My concerns, which I'm sure you understand, are these:
 >>  >
 >>  > a. `modify-frame-parameters' should not be changed so that
 >>  > it affects future behavior.
 >>
 >> My concern is that it should be changed.
 >
 > Why should it?  Why should modifying one frame affect all future frames?  That
 > makes no sense to me.  If you make one frame background light blue, do you
 > expect all future frames to also have a light blue background?  If so, why?

I thought "future behavior" referred to the future behavior of Emacs in
this regard.  And I would like to change that indeed.  But I obviously
agree with you that modifying a specific frame's parameters via
`modify-frame-parameters' should never affect other or future frames.
Whether "setting the default font" via the menu should affect one frame,
all existing frames, or future frames is an issue that should be
discussed separately.

 > Much as I could be persuaded wrt whether `modify-frame-parameters' should zoom
 > the frame size when you zoom the `font' parameter, I do not see any
 > justification for `modify-frame-parameters' affecting other than the targeted
 > frame.  That just sounds perverse to me, and I expect it would lead to all kinds
 > of unwelcome behavior.

Fully agreed.

 >>  > b. Changing the `font' parameter of a frame should also
 >>  > shrink/enlarge the frame, as it does today.  That is,
 >>  > shrink/enlarge in terms of screen size (pixels), but not
 >>  > in terms of number of lines/cols.  IOW, the frame size should
 >>  > keep the same number of lines/cols.
 >>
 >> I'd prefer the frame + external objects to keep the same
 >> number of pixels.
 >
 > As I said, the choice should be up to the user.  Different users will have
 > different use cases (and preferences), and the same user will have different use
 > cases at different times.

Agreed again.

 > Why is it necessary for `modify-frame-parameters' to behave like
 > `set-frame-size' with a non-nil (thus non-default) KEEP-SIZE argument, and wrong
 > for `modify-frame-parameters' to behave like `set-frame-size' with a nil (thus
 > default) KEEP-SIZE argument?

Because it incredibly complicates the implementation of setting a font
on a specific frame.  With emacs 24.3 we conceptually

(1) set the font which changes the appearance of text within the frame
     and the number of pixels used for the display margins,

(2) set the frame size proportionally to the font and rounded which may
     cause resizing the frame,

(3) set the sizes of fringes proportionally to the font and rounded
     which may cause another resizing of the frame, and

(4) set the sizes of the scrollbars proportionally to the font and
     rounded which may cause yet another resizing of the frame.

Now I think that all these steps are really useful to get a nice frame,
after all, a large font does look bad with narrow scrollbars and tiny
fringes.  But the problem is that these steps must be implemented via
recursive calls to `modify-frame-parameters'.  And these cause
conflicts, for example, when a user also issues a request to set the
size of the frame in the same `modify-frame-parameters' call that
changes the font or a request to maximize the frame.

So I think that a separate function should be provided to do such frame
zooming in a pretty and obviously pixelwise fashion where a user should
be also allowed to specify things like a sizing factor (which allows to
resize the frame more/less agressively wrt the font change) and some
upper and lower bounds which guarantee for example that the frame never
exceeds the size of the screen and/or obscurs the taskbar and a separate
options which allows to zoom only text or images as well.

 >> When you change the frame size you have to contact your window
 >> manager, wait till it gets back to you, and then you have to
 >> fit all your objects into the space alloted by the window manager.
 >> Now, obviously you have to do all these things also when you just
 >> resize the frame.  But in that case you didn't change the font.
 >> Or if you did, you did it without intending to change the frame
 >> size with it.
 >
 > I cannot speak to the implementation concerns.  I'm speaking in user terms.

My concerns are implementation concerns only.  We're asking too much
from that function `modify-frame-parameters'

 > For the kind of zooming I'm talking about, either zooming larger would no longer
 > be available once the maximum size is reached or it would be available beyond
 > the "maximum", which is really just the screen size.  The latter is the case
 > today, BTW: you can zoom a frame larger than the screen.

Which is useless IMO.

 > In the end, you will probably do what you're suggesting, and I will probably end
 > up using `set-frame-font' instead of `modify-frame-parameters' to continue to
 > get the effect I want.  (For Emacs 20 & 21 there was no KEEP-SIZE parameter, so
 > I'll need to use `modify-frame-parameters' for those cases.)

I now think we need a more intelligent function than `set-frame-font'
much like the one I sketched above.

 > For example, when zooming a frame (which for me, again, means shrinking both its
 > content and its size), if it contains images then I would want to be able to
 > shrink the images as well (modulo losing resolution, of course), in such a way
 > that what appears in the frame remains essentially the same (unlike the case of
 > a web browser, for example).

A user must be able to choose between text-based zooming and
text+image-based zooming.  But I have no idea how image positions
correlate to text positions so I don't know how zooming affects the
relative positions of text mixed with images.

 >> Are you sure?  What if toolbars have accompanying text?
 >
 > I meant the toolbar images.

Some toolbars can have accompanying text and that text is AFAICT subject
to frame font changes.

 >>  > Changing the frame `font' size zooms only the text.
 >>
 >> Not here.
 >
 > For me, on MS Windows, changing option `tool-bar-style' to include text has no
 > effect: I never see any text, just images.  And the doc string says this:
 >
 >   This variable only affects the GTK+ toolkit version of Emacs.

So the font changing code has to handle that.

 > OK.  But my concern is that we not lose something that users have today.  Wrt
 > font zooming also zooming frame size, I guess we won't lose, since we can use
 > `set-frame-font' with nil `KEEP-SIZE'.

Which as you said should be probably fixed.  But I still find it better
to rewrite such a function from scratch.

martin

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

[Drew Adams]

>  > Try going smaller rather than larger.
> 
> Then I won't see anything any more.

You can still type into the frame, even when you can no longer read its text.
And you can have a larger copy of the same buffer in another frame, for
reference.  Not important; just mentioning it.

>  >>  > a. `modify-frame-parameters' should not be changed so that
>  >>  > it affects future behavior.
>  >>
>  >> My concern is that it should be changed.
>  >
>  > Why should it?  Why should modifying one frame affect all 
>  > future frames?  That makes no sense to me.  If you make
>  > one frame background light blue, do you expect all future
>  > frames to also have a light blue background?  If so, why?
> 
> I thought "future behavior" referred to the future behavior 
> of Emacs in this regard.  And I would like to change that
> indeed.

Dunno what you mean by that, as opposed to what you say next:

> But I obviously agree with you that modifying a specific
> frame's parameters via `modify-frame-parameters' should
> never affect other or future frames.

Including parameter `font'?

> Whether "setting the default font" via the menu should affect 
> one frame, all existing frames, or future frames is an issue
> that should be discussed separately.

Whether by menu or otherwise, setting face `default', which includes the default
font (though I'm not sure there is such a critter, explicitly), is different
from setting the `font' parameter for a specific frame.  

Setting face `default' (and thus the default font) is akin to setting (part of)
`default-frame-alist' - it is expressly intended to determine future frames.

This is the problem (one of them) that we have been discussing: whether future
frames should be affected when you change `font' for one frame (whether by
`modify-frame-parameters' or `set-frame-font').

I'm glad to hear that you agree that they should not be affected.

>  > Much as I could be persuaded wrt whether 
>  > `modify-frame-parameters' should zoom the frame size when
>  > you zoom the `font' parameter, I do not see any justification
>  > for `modify-frame-parameters' affecting other than the targeted
>  > frame.  That just sounds perverse to me, and I expect it 
>  > would lead to all kinds of unwelcome behavior.
> 
> Fully agreed.

Great.

>  >>  > b. Changing the `font' parameter of a frame should also
>  >>  > shrink/enlarge the frame, as it does today.  That is,
>  >>  > shrink/enlarge in terms of screen size (pixels), but not
>  >>  > in terms of number of lines/cols.  IOW, the frame size should
>  >>  > keep the same number of lines/cols.
>  >>
>  >> I'd prefer the frame + external objects to keep the same
>  >> number of pixels.
>  >
>  > As I said, the choice should be up to the user.  Different 
>  > users will have different use cases (and preferences), and
>  > the same user will have different use cases at different times.
> 
> Agreed again.

Good again.

>  > Why is it necessary for `modify-frame-parameters' to behave like
>  > `set-frame-size' with a non-nil (thus non-default) KEEP-SIZE 
>  > argument, and wrong for `modify-frame-parameters' to behave like 
>  > `set-frame-size' with a nil (thus default) KEEP-SIZE argument?
> 
> Because it incredibly complicates the implementation of setting a
> font on a specific frame.  With emacs 24.3 we conceptually
> 
> (1) set the font which changes the appearance of text within the frame
>      and the number of pixels used for the display margins,
> 
> (2) set the frame size proportionally to the font and rounded 
>      which may cause resizing the frame,
> 
> (3) set the sizes of fringes proportionally to the font and rounded
>      which may cause another resizing of the frame, and
> 
> (4) set the sizes of the scrollbars proportionally to the font and
>      rounded which may cause yet another resizing of the frame.
> 
> Now I think that all these steps are really useful to get a 
> nice frame, after all, a large font does look bad with narrow 
> scrollbars and tiny fringes.  But the problem is that these
> steps must be implemented via recursive calls to
> `modify-frame-parameters'.  And these cause conflicts, for
> example, when a user also issues a request to set the
> size of the frame in the same `modify-frame-parameters' call that
> changes the font or a request to maximize the frame.

Yes, I can understand that.

> So I think that a separate function should be provided to do 
> such frame zooming in a pretty and obviously pixelwise
> fashion where a user should be also allowed to specify
> things like a sizing factor (which allows to
> resize the frame more/less agressively wrt the font change)
> and some upper and lower bounds which guarantee for example
> that the frame never exceeds the size of the screen and/or
> obscurs the taskbar and a separate options which allows to
> zoom only text or images as well.

The devil will be in the details.  I don't disagree with what you say in the
abstract.  As long as users (including via Lisp) have equal or more control than
now, and the use is not overly complex, I'll probably be OK with whatever you
come up with.  I do recognize the complications you describe, whether only
potential or real (in practice).

>  >> When you change the frame size you have to contact your window
>  >> manager, wait till it gets back to you, and then you have to
>  >> fit all your objects into the space alloted by the window manager.
>  >> Now, obviously you have to do all these things also when you just
>  >> resize the frame.  But in that case you didn't change the font.
>  >> Or if you did, you did it without intending to change the frame
>  >> size with it.
>  >
>  > I cannot speak to the implementation concerns.  I'm 
>  > speaking in user terms.
> 
> My concerns are implementation concerns only.  We're asking too much
> from that function `modify-frame-parameters'

OK, your arguments about that make sense.  But keep in mind that it has been
around a long time and worked well in general.  Whatever it is replace with
should do at least what it does.

And keep in mind that, regardless of potential problems that you underline, it
has been useful as a general workhorse function, and it is easy to use.

I would particularly not wish to see it replaced only by some incredibly complex
thing, a la what what done wrt buffer display.  Exact, logical, and precise is
good.  But simple use is good too.  Cleanup is good, but let's not throw out the
baby with the bathwater.

>  > For the kind of zooming I'm talking about, either zooming 
>  > larger would no longer be available once the maximum size
>  > is reached or it would be available beyond the "maximum",
>  > which is really just the screen size.  The latter is the
>  > case today, BTW: you can zoom a frame larger than the screen.
> 
> Which is useless IMO.

No, not really.  Whether Emacs or another application, users sometimes do
intentionally move window-mgr windows partly off screen, for various reasons.
The window mgr does the clipping to truncate the off-screen parts - the
application need not bother with that.

But this is generally beside the main points being discussed.

>  > In the end, you will probably do what you're suggesting, 
>  > and I will probably end up using `set-frame-font' instead of 
>  > `modify-frame-parameters' to continue to get the effect
>  > I want.  (For Emacs 20 & 21 there was no KEEP-SIZE parameter,
>  > so I'll need to use `modify-frame-parameters' for those cases.)
> 
> I now think we need a more intelligent function than `set-frame-font'
> much like the one I sketched above.

Please try to also keep a simple-use function (some function), in addition to
providing for cleaner, more exact definition/control.

`modify-frame-parameters' has the advantage that it is simple to use.  And there
is really no more conflict inherent in `modify-frame-parameters', because of
parameter interdependence, than there is inherent in `default-frame-alist': You
can define that option value in a way such that various parameter settings
collide also, I imagine.

>  > For example, when zooming a frame (which for me, again, 
>  > means shrinking both its content and its size), if it
>  > contains images then I would want to be able to
>  > shrink the images as well (modulo losing resolution, of 
>  > course), in such a way that what appears in the frame
>  > remains essentially the same (unlike the case of
>  > a web browser, for example).
> 
> A user must be able to choose between text-based zooming and
> text+image-based zooming.  But I have no idea how image positions
> correlate to text positions so I don't know how zooming affects the
> relative positions of text mixed with images.

I don't know either.  These are things to keep in mind, and perhaps dealt with
later.  Hopefully someone will know or learn more and be able to offer insight.

>  >> Are you sure?  What if toolbars have accompanying text?
>  >
>  > I meant the toolbar images.
> 
> Some toolbars can have accompanying text and that text is 
> AFAICT subject to frame font changes.
> 
>  >>  > Changing the frame `font' size zooms only the text.
>  >>
>  >> Not here.
>  >
>  > For me, on MS Windows, changing option `tool-bar-style' to 
>  > include text has no effect: I never see any text, just
>  > images.  And the doc string says this:
>  >
>  >   This variable only affects the GTK+ toolkit version of Emacs.
> 
> So the font changing code has to handle that.

Not necessarily, or not necessarily in lock step.  A user could want to zoom the
font but not zoom the menu bar or tool bar (or vice versa).

>  > OK.  But my concern is that we not lose something that 
>  > users have today.  Wrt font zooming also zooming frame size,
>  > I guess we won't lose, since we can use `set-frame-font'
>  > with nil `KEEP-SIZE'.
> 
> Which as you said should be probably fixed.  But I still find 
> it better to rewrite such a function from scratch.

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

[martin rudalics]

 >> But I obviously agree with you that modifying a specific
 >> frame's parameters via `modify-frame-parameters' should
 >> never affect other or future frames.
 >
 > Including parameter `font'?

Including parameter `font'.

 > Setting face `default' (and thus the default font) is akin to setting (part of)
 > `default-frame-alist' - it is expressly intended to determine future frames.

That's what I would expect.

 > `modify-frame-parameters' has the advantage that it is simple to use.  And there
 > is really no more conflict inherent in `modify-frame-parameters', because of
 > parameter interdependence, than there is inherent in `default-frame-alist': You
 > can define that option value in a way such that various parameter settings
 > collide also, I imagine.

Yes.  Throughout, I've been using `modify-frame-parameters' only as an
example.  Evaluating `initial-frame-alist' and `default-frame-alist'
runs precisely into the same problems and should be fixed the same way.

 > Not necessarily, or not necessarily in lock step.  A user could want to zoom the
 > font but not zoom the menu bar or tool bar (or vice versa).

So the zooming function should accomodate that.

martin

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

[Drew Adams]

>  >> But I obviously agree with you that modifying a specific
>  >> frame's parameters via `modify-frame-parameters' should
>  >> never affect other or future frames.
>  >
>  > Including parameter `font'?
> 
> Including parameter `font'.
> 
>  > Setting face `default' (and thus the default font) is akin 
>  > to setting (part of) `default-frame-alist' - it is expressly
>  > intended to determine future frames.
> 
> That's what I would expect.
> 
>  > `modify-frame-parameters' has the advantage that it is 
>  > simple to use.  And there is really no more conflict inherent
>  > in `modify-frame-parameters', because of parameter interdependence,
>  > than there is inherent in `default-frame-alist': You can define
>  > that option value in a way such that various parameter settings
>  > collide also, I imagine.
> 
> Yes.  Throughout, I've been using `modify-frame-parameters' only as an
> example.  Evaluating `initial-frame-alist' and `default-frame-alist'
> runs precisely into the same problems and should be fixed the 
> same way.
> 
>  > Not necessarily, or not necessarily in lock step.  A user 
>  > could want to zoom the font but not zoom the menu bar or tool bar
>  > (or vice versa).
> 
> So the zooming function should accomodate that.

Yes to all that you said - we agree.

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

[martin rudalics]

> The limitation makes emacs frames rather clumsy, especially when using
> maximization, or some form of tiling. I'd think there would already be a
> report on it, as the issue shows up periodically on reddit. I couldn't find
> one, so here it is.

This has been fixed in Emacs 24.4.  Closing this bug.

Thanks, martin