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

From: Stéphane Marks <[email-masked]>
Date: Thu, 19 Jun 2025 18:06:40 -0400

On Thu, Jun 19, 2025 at 6:02 PM Spencer Baugh <[email-masked]> wrote:

> Stéphane Marks <[email-masked]> 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
> > <[email-masked]> wrote:
> >
> >  Stefan Kangas <[email-masked]> writes:
> >
> >  > Eli Zaretskii <[email-masked]> writes:
> >  >
> >  >>> Date: Thu, 21 Mar 2024 03:36:02 -0500
> >  >>> Cc: [email-masked]
> >  >>> From: Adam Porter <[email-masked]>
> >  >>>
> >  >>> 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