Re: size hints and tiling window managers

[Eli Zaretskii]

> From: James Cloos <address@hidden>
> Date: Fri, 07 Dec 2012 20:42:00 -0500
> Cc: martin rudalics <address@hidden>, Jonas Bernoulli <address@hidden>
> 
> >>>>> "mr" == martin rudalics <address@hidden> writes:
> 
> mr> Eli said that he can provide arbitrary frame pixel sizes at any time.
> 
> 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?

If you are asking me, I don't think I understand the problem well
enough to answer.  For starters, I don't understand how the "extra
space" you were talking about in your original report came into
being.  Specifically, what did Emacs ask for and what did the window
manager do instead?

> Something like the (as yet untested, and X-only) code below?

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?  Emacs
_does_ want its frame size be a multiple of FRAME_COLUMN_WIDTH; if we
don't ask the wm to do that, won't that produce bad display on _all_
window managers, instead of just some that ignore the hints?  And when
a wm is involved that doesn't honor the increment hints, what will
happen if we don't set those members of the XSizeHints structure?

> If so, I presume that it should be configurable, yes?

I'd prefer we fix this particular problem:

> Emacs does the same thing: it paints the extra space using the
> background color of the default face.  The problem is that Emacs frames
> may also have fringes which usually don't have the same background
> color.  As a result Emacs draws a "line" with the same color as *the*
> background color to the right of the right fringe (and below the echo
> area).

Can you show a screenshot of this?  Also, what would be a good
solution to this problem? make the right fringe wider? something else?

> 2. However I think it would be better if Emacs would just use any window
>    size without having to paint some extra space to the right and below
>    of the "actual" content.  One way of doing that could be to
>    dynamically adjust the width of the fringes (and the height of the
>    minibuffer/echo area).

Changing the width of the fringes dynamically is easy, actually,
because we already do so, albeit triggered by user commands.  Echo are
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?

> Since buffers can contain text that have a different width than that
> of the default face relying on size hints does not guarantee that
> text is never cut of in the middle of a character.

That is true (and Emacs already supports these situations, as you
probably know), but that's not the reason for the issue at hand.

The reason is that Emacs redisplay works in 2 distinct stages.  In the
first stage, a device-independent part of the display engine generates
a structure, called "glyph matrix", which holds, for each character
that is visible in an Emacs window, a structure called "glyph" with
sufficient information to draw that character.  Each window has its
own glyph matrix.  In the second stage, the glyph matrix is handed to
the device-dependent part of the display engine, which actually draws
the glyphs.

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.