GNU bug report logs - #69837
29.2; vtable-update-object only works in visible windows

Previous Next

Full log

Message #20 received at 69837 <at> debbugs.gnu.org (full text, mbox):

From: Adam Porter <adam <at> alphapapa.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 69837 <at> debbugs.gnu.org
Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible
 windows
Date: Thu, 21 Mar 2024 03:36:02 -0500

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

Hi Eli,

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.

Thanks,
Adam

[example.el (text/x-emacs-lisp, attachment)]

Previous Next

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