[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
example.el
Description: Text Data