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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 21 Mar 2024 03:36:02 -0500
> Cc: 69837@debbugs.gnu.org
> From: Adam Porter <adam@alphapapa.net>
> 
> 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.