Aaron Jensen <aaronjensen@gmail.com> writes:

Could you please try if the attached change works for you (without your patch)?

I was just about to send you log output that showed seemingly random values in glyph::frame. You beat me to it.

👍

This patch appears to fix the problem for me, thank you.

Thanks.

Is this the only place that they need to be initialized? Was it more than glyph::frame that was uninitialized (and was that problematic)?

adjust_glyph_matrix is the only place where these glyph allocations happen, for window-systems. For completeness, let be just say that glyphs matrices on ttys function differently. And the whole struct glyphs in a glyph row were uninitialized because they are allocated via C's realloc. I don't think this being uninitialized was a problem before, the problem was only the combination with my assumption that the memory was zeroed. Don't know where that assumption came from. Maybe I've misread them, or maybe it's just that I hate leaving memory uninitialized in general and assumed I wouldn't have done it there. No idea.

For my own edification, while logging GLYPH_EQUAL_P, I noticed that it's invoked frequently for windows/buffers that are not visible. As in, while a hidden vterm buffer is accumulating log output and I only have a single stationary buffer visible, I see a flood of log messages. Is this expected? It may very well be, I just don't know much about the rendering pipeline.

That sounds suspicious. So you have one window W displaying some innocuous buffer B, and another vterm buffer V that is not displayed anywhere. The shell in V runs something producing output. That does not change B, and also not something visible in W, including mode-line or such or maybe frame title. And that leads to some redisplay of W?

Does that also happen when you use something else than vterm, say M-x shell or M-x eshell?