Subject: Re: bug#79009: [PATCH] Improve 'vtable' object handling, cache handling, messages, [PATCH] Improve 'vtable' object handling, cache handling, messages

From: Spencer Baugh <[email-masked]>
Date: Tue, 15 Jul 2025 14:07:35 -0400

Stéphane Marks <[email-masked]> writes:
> On Tue, Jul 15, 2025 at 10:02 AM Spencer Baugh <[email-masked]> wrote:
>  Anyway, my patch to vtable--cache follows.  I think we should apply this
>  first before your changes, because I believe it's a better approach.
>
> The patch addresses some of the cache issues but not all of them.  I was planning on addressing cache issues later and starting
> with the previous patch to get us going.

Then you should drop the cache changes from this small patch, since IMO
they are wrong, they don't go in the right long-term direction.

> With regard to the cache, one thing that puzzles me about it, and Lars, if he's reading can chime in, is that the vtable buffer itself
> can hold only one formatter representation at a time, munged from cache entries plus formatters/displayers, and if the buffer is
> displayed in more than one sized window, it can't hold both widths at the same time.  On table updates, via -insert-object, -
> remove-object, -update-object, -revert-command only the "current" cache is updated and the others considered stale.  You can see
> in the bigger vtable update I shared, that only one cache entry at a time is rebuilt as needed when the assigned vtable buffer's
> window size changes upon selection, and the others considered stale--so why bother with more than one.  So, if we're gonna redo
> the cache (and let's assume it's an internal vtable feature that won't impact users if we change it), we should consider doing away
> with the multi-width cache and keys and just use the ambient aka most recently-displayed cache entries anyway.  I didn't muck
> with the cache further to simplify it assuming Lars had a good reason to implement it that way.

The sole benefit of the cache is when there are two different
windows/frames which are displaying a buffer containing a vtable.  It
provides better performance for this case, when the user is repeatedly
reverting the vtable in different windows/frames.

But IMO this use case doesn't matter, and I'd be in favor of dropping
the current cache complexity, if no-one objects.  I suggest using my
patch as a starting point for that.