On Thu, Jun 19, 2025 at 5:37 PM Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: > Stefan Kangas writes: > > > Eli Zaretskii writes: > > > >>> Date: Thu, 21 Mar 2024 03:36:02 -0500 > >>> Cc: 69837@debbugs.gnu.org > >>> From: Adam Porter > >>> > >>> 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? > > I ran into this same problem. I think Adam's workaround is on the right > track, but the issue is present in a number of other functions in > vtable.el, not just vtable-update-object. > > The root of the issue is that when we're interacting with the text of an > inserted vtable, we should use the "cache" object that was last used to > insert that vtable, rather than one based on the current selected window > and terminal. Otherwise we will experience various inconsistencies, > e.g. inserting a new line that has different column widths from the rest > of the vtable text. > > My attached patch solves this by saving the "cache" object in a text > property on the vtable text, and updating all the relevant vtable > functions to access the cache via that text property rather than by > computing a cache key from the current selected window/terminal. > > Adam, could you check that this solves the problem for your use case? > I have a very big patch coming for vtable under https://debbugs.gnu.org/cgi/bugreport.cgi?bug=78843 which addresses this issue, and a ton of other bugs (and features). That's coming in the next day or so, if you can wait? -Stéphane