GNU bug report logs -
#69837
29.2; vtable-update-object only works in visible windows
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
On Thu, Jun 19, 2025 at 6:02 PM Spencer Baugh <sbaugh <at> janestreet.com> wrote:
> Stéphane Marks <shipmints <at> 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 <at> gnu.org> wrote:
> >
> > Stefan Kangas <stefankangas <at> gmail.com> writes:
> >
> > > Eli Zaretskii <eliz <at> gnu.org> writes:
> > >
> > >>> Date: Thu, 21 Mar 2024 03:36:02 -0500
> > >>> Cc: 69837 <at> debbugs.gnu.org
> > >>> From: Adam Porter <adam <at> 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.
>
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
[Message part 2 (text/html, inline)]
This bug report was last modified 50 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.