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

[martin rudalics <rudalics@gmx.at>]

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