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

From: Stéphane Marks <[email-masked]>
Date: Wed, 16 Jul 2025 17:03:31 -0400

On Wed, Jul 16, 2025 at 4:52 PM Spencer Baugh <[email-masked]> wrote:

> Kristoffer Balintona <[email-masked]> writes:
>
> > 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.
>
> That is a very relatable use case, because it's something that I want as
> well.  I also had to create my own command which saves the object before
> running vtable-revert-command, and I would like to get rid of it.
>
> But, do we really need to use object-equal everywhere to do this?  I
> think it would be better to focus on just fixing vtable-revert-command.
>
> I suggest we should instead add a customizable function, maybe called
> new-object-after-update.  vtable-revert-command would pass the old
> object and the new object list to this function, and the function would
> return a new object to move point to.
>
> This would be more powerful, in a way that is important for my vtables:
> When an object has been removed from the list after a
> vtable-revert-command, I would prefer to move point to the "next" object
> in the list (where next is defined by an id embedded in the objects)
> rather than move it back to the start.  That behavior can't be achieved
> with object-equal.
>

I believe the revised vtable-revert-command that I shared with you off line
does that without using an id.  It aims to keep point "stable" visually.
Using an id isn't an idea you shared when we were discussing that revert
point-stability feature.  Those features will come in another patch once we
can get past this discussion.