Stéphane Marks <shipmints@gmail.com> 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
> <bug-gnu-emacs@gnu.org> wrote:
>
>  Stefan Kangas <stefankangas@gmail.com> writes:
>
>  > Eli Zaretskii <eliz@gnu.org> writes:
>  >
>  >>> 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.
>  >
>  > 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.