Re: size hints and tiling window managers

[Eli Zaretskii <eliz@gnu.org>]

> From: Jonas Bernoulli <jonas@bernoul.li>
> Cc: "James Cloos" <cloos@jhcloos.com>, emacs-devel@gnu.org, rudalics@gmx.at
> Date: Sun, 09 Dec 2012 20:23:30 +0100
> 
> I have attached a screenshot that shows parts of four Emacs frames.  The
> green areas are the X11 window borders and window titles drawn by the
> window manager.  The cyan areas are the fringes.  In the upper left
> window I have marked what I have called the "extra space" in my initial
> report.

Thanks.  I wanted to be sure I understand the problem.

> > Changing the width of the fringes dynamically is easy, actually,
> > because we already do so, albeit triggered by user commands.
> 
> I actually tried that approach.  I calculated the width of (a) and then
> adjusted the width of the fringes accordingly.
> 
> ,----
> | (let ((d (- (frame-pixel-width)
> |             (* (frame-width)
> |                (frame-char-width)))))
> |   (set-frame-parameter (selected-frame) 'left-fringe
> |                        (/ d 2))
> |   (set-frame-parameter (selected-frame) 'right-fringe
> |                        (+ (/ d 2) (% d 2))))
> `----
> 
> The result were wider fringes but the "extra space" did not go away, it
> just changed it's width.

This cannot be done from Lisp, only from C.  Sorry, I should have made
myself clear.

> > Echo area is harder, because it's just a window, so its size must
> > currently be a multiple of the default font's size.  Perhaps we could
> > modify the mode-line width instead, by changing the line-with
> > attribute of the mode-line face.  Can you try that?
> 
> Adjusting the mode-line height would very likely result in the same
> problem as adjusting the fringe width.

Maybe so, but did you actually try that?  The display engine surprised
me more than once.

> > It should be clear that the device-independent stage _must_ produce a
> > glyph for every character, even if that character is only partially
> > visible.  And since the number of glyphs is always integer, you get
> > the limitation of the integral multiple of frame font's size.  IOW,
> > the issue here is _not_ that we cannot draw partially visible
> > character -- we can -- but that the glyph matrix _dimensions_ must be
> > integers.  The current limitation exists because asking the wm to
> > observe the same restrictions was the easiest way of reconciling an
> > internal requirement of integer dimensions of the glyph matrices with
> > the fact that GUI frames are drawn and sized in pixels.
> 
> I understand why the width of the text area has to be an integer and am
> aware that it partially visible characters can be drawn; and why that is
> a good thing.

Actually, the above was written in the hope to make clear that the
width of the text area does _not_ have to be an integer number of
frame font's width units.  The dimensions of the glyph matrix must be
inger, of course, but the last glyph can be only partially visible.
IOW, the matrix dimensions should be computed as the round-up of the
result of dividing the window width by the width of the default font.

> >> From: James Cloos <cloos@jhcloos.com>
> >> Doesn't it just require not setting the .width_inc and .height_inc
> >> members of the size_hints struct in src/xterm.c and src/gtkutil.c,
> >> and editing the .min_width and .min_height code to account for that?
> 
> > Maybe I'm missing something, but all your changes do is refrain from
> > setting the width_inc and height_inc members of the XSizeHints
> > structure.  Can you explain how does this solve the problem?
> 
> It seems that you think the above was written by the same person as the
> original report.

No, I don't think I did.  (Why does that matter, anyway?)

> I agree with you that all this does is to not provide size hints and
> that as a result the display problems that are now limited to wms that
> ignore size hints would instead affect all wms.

OK, so we are in violent agreement.