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

Previous Next

Full log

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Adam Porter <adam <at> alphapapa.net>, 69837 <at> debbugs.gnu.org
Subject: Re: bug#69837: 29.2;
 vtable-update-object only works in visible windows
Date: Fri, 28 Feb 2025 19:09:29 -0800

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?

Previous Next

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