Subject: bug#69837: 29.2; vtable-update-object only works in visible windows

From: Stefan Kangas <[email-masked]>
Date: Fri, 28 Feb 2025 19:09:29 -0800

Eli Zaretskii <[email-masked]> writes:

>> Date: Thu, 21 Mar 2024 03:36:02 -0500
>> Cc: [email-masked]
>> From: Adam Porter <[email-masked]>
>>
>> FWIW, I did some hacking on listen.el attempting to further understand
>> and work around this problem, and I've found what seems to be a usable
>> workaround (for my purposes, anyway).
>>
>> The attached code defines a macro within which I call
>> `listen-queue--vtable-update-object' (which merely incorporates the fix
>> to `vtable-update-object' from bug#69664).  As well, I wrap
>> `make-vtable' in a function that also sets two buffer-local variables to
>> the values of `frame-terminal' and `window-width' at the time of the
>> vtable's creation.  The macro locally overrides the functions
>> `frame-terminal' and `window-width' to return those saved values.
>>
>> This allows the cache key to match unconditionally, which allows the
>> vtable's objects to be updated even when its buffer is not visible.
>>
>> In my limited testing, it seems to work fine.  In my estimation, the
>> consequences of doing this in the worst case would be that the rows for
>> the updated objects might be drawn with some columns at a slightly
>> incorrect width, which is easily rectified by reverting the table
>> (usually bound to "g").  As well, that worst case (e.g. imagining a
>> vtable whose buffer might be initially displayed on one terminal/monitor
>> and later on another with different characteristics) would seem to be
>> relatively rare (so for my project, it seems like an obviously good
>> thing to do).
>>
>> For Emacs itself, I'm not sure what the best fix would be.  I suppose a
>> workaround like this could be implemented as a fallback in case the
>> cache key misses; it would seem better to update the object potentially
>> sub-optimally than to error and not update it at all.
>>
>> Another possibility would be to ignore the frame-terminal and
>> window-width in the cache key altogether (i.e. so they would always be
>> assumed to be the same), but I'm sure that Lars did it this way for a
>> reason, so that would seem unwise.
>>
>> Let me know how you'd like me to proceed.
>
> I think you should install your workaround.  I don't see how it could
> be worse than what we have now.
>
> P.S. And sorry for a long silence.

Adam, could you please install the workaround?  Or maybe you did
already?