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

From: Kristoffer Balintona <[email-masked]>
Date: Wed, 16 Jul 2025 13:26:46 -0700

On Tue, Jul 15 2025, Spencer Baugh wrote:

> Stéphane Marks <[email-masked]> writes:
>
>> On Tue, Jul 15, 2025 at 11:41 AM Visuwesh <[email-masked]> wrote:
>>
>>  [செவ்வாய் ஜூலை 15, 2025] Stéphane Marks wrote:
>>
>>  > On Mon, Jul 14, 2025 at 3:54 PM Spencer Baugh <[email-masked]> wrote:
>>  >
>>  >> Stéphane Marks <[email-masked]> writes:
>>  >> > On Sun, Jul 13, 2025 at 2:16 PM Stéphane Marks <[email-masked]>
>>  >> wrote:
>>  >> > I've updated the broader vtable update in the referenced 78843 bug to
>>  >> check out if interested.
>>  >> >
>>  >> > I've removed support for the duplicate-object feature.  After careful
>>  >> consideration, it was half baked and I think better for vtable
>>  >> > programmers to handle their own objects.  I will be sure the
>>  >> documentation stresses to avoid duplicate objects as vtable's design is
>>  >> > predicated on unique objects (or race conditions ensue among duplicate
>>  >> object references).
>>  >>
>>  >> Thank you, this was going to be my first bit of feedback.
>>  >>
>>  >> Folowup question: What is the motivation for adding customizable object
>>  >> equality?  Could the need for that be avoided by some changes specific
>>  >> to vtable-update-object?
>>  >>
>>  >
>>  > It's really a policy question and future proofing.  I believe Lars
>>  > originated this idea and probably has use cases for this in his vtable code.
>>
>>  This question came up in emacs-devel once before:
>>  https://yhetil.org/emacs-devel/CANVbq5kjPpCKwMBSYfHHLMFXAX7vAgy+D=[email-masked]
>>
>> What does the group have to say about Kristoffer's use case?  He's one of the people that's helped test the larger vtable.el
>> changes and influenced some new features and some fixes beyond object-equal.
>
> There's no actual concrete use case listed in that email.
>
> And the example shown in that email can be handled straightforwardly:
> simply search vtable-objects for the object using whatever equality
> function you want, then do vtable-goto-object.  This is more efficient
> anyway.
>
> So this email does not provide any real motivation for object-equal.

Hi, I am Kristoffer, the user mentioned and the writer of the email
linked. I'd like to try and express why I find the new :object-equal
slot useful. Ship Mints has shared with me versions of the patch that
include :object-equal for several months now and I've been happy with
the addition this entire time.

vtable-goto-object was important to me primarily because of reverting
the vtable. When reverting a vtable, the point is intended to be return
to the same object it was on prior to reverting. This was handled with
vtable-goto-object, which used eq at the time. But for my vtable uses,
eq was not appropriate for equality. Without the proposed :object-equal
slot, I had to create my own command that saves the object at point,
reverts the vtable, then places the point on the object in the new
vtable that I considered equal to the saved object -- much more
convoluted than simply setting :object-equal.

There may have been one or two additional reasons I had for supporting
:object-equal, but I've been using it for several months now so I might
have forgotten them by now if there were some. If I remember any other
concrete use cases then I will chime in again to mention them.

P.S. In a reply to the very same thread Ship Mints linked, Adam Porter,
a user of vtable, also expressed support for (or, at least wasn't
against) adding something like :object-equal:
https://yhetil.org/emacs-devel/[email-masked]/.
He hinted at a potential use case there.

-- 
Kind regards,
Kristoffer