On 16/01/2023 12:03, martin rudalics wrote:
>  > OK, I have recompiled to Lucid, reproduced the problem
> 
> Thanks.  This shows that we have to deal with an increasing number of
> window managers that pay more attention to size hints than we have
> bargained for.  If Emacs doesn't keep pace with that development,
> leaving 'frame-resize-pixelwise' at nil will become an obsolete option
> soon.
> 
>  > I did get a segfault once when testing this, but wasn't able to
>  > replicate it so far. Could be unrelated.
> 
> Did this happen with emacs -Q?  An optimized build probably?  Also the
> line numbers do not really correspond to neither emacs-29 nor master as
> I can check from here via savannah.  In either case, dumping traces to a
> buffer can produce all sorts of problems, although I try hard to do that
> in "safe" places only.  So it might be related.

'emacs -Q', a build from master with your patch applied.

>  > Not sure if you need the contents of *foo* from me, but attaching it
>  > anyway (from a different session), because it might show something
>  > different with 2x scaled display.
> 
> Now I'm confused.  How on earth do we scale with Lucid?

Apparently, we do scale with Lucid. Even the scroll bar probably 
(although that one is harder to tell).

> If we do, then
> please show me how Lucid handles the Inconsolata scenario.

The InconsolataLGC problem doesn't reproduce on current master with 
Lucid, without any extra patches.

> And please
> try also the Inconsolata scenario with a GTK build and the new code.  I
> doubt that the code can handle it out of the box but maybe we can tweak
> it sufficiently.

x_rest.diff?

It doesn't seem to make any effect on the problem behavior.

Attaching *foo* after 2 evaluation, then resizing the frame with a 
mouse, then 2 evaluations again.