bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Adam Porter
Subject: bug#69837: 29.2; vtable-update-object only works in visible windows
Date: Thu, 21 Mar 2024 03:36:02 -0500
User-agent: Mozilla Thunderbird

Hi Eli,

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.

Thanks,
Adam

Attachment: example.el
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]