On Thu, Jun 19, 2025 at 6:02 PM Spencer Baugh wrote: > Stéphane Marks writes: > > 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? > > Certainly I can wait. Cc me when you send the patch. > > Though if your patch is very large, maybe this relatively small patch > should land first. > > (Also, I hope that you're adding tests in your very large patch?) > > BTW, an updated version of my patch is attached, just fixing a silly bug > that was in the first version. > Your patch doesn't address several other intertwined issues that my bigger patch addresses. I've been testing it for ages now and with other vtable users. I can send a new vtable.el and vtable.texi to you off line if you'd like a look before I finish writing the long changelog. -Stéphane