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

From: Stéphane Marks <shipmints <at> gmail.com>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: Adam Porter <adam <at> alphapapa.net>, 69837 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Stefan Kangas <stefankangas <at> gmail.com>
Subject: bug#69837: 29.2; vtable-update-object only works in visible windows
Date: Thu, 19 Jun 2025 17:41:03 -0400

[Message part 1 (text/plain, inline)]

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?

-Stéphane

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.