On Wed, Jul 16, 2025 at 5:05 PM Spencer Baugh wrote: > > > On Wed, Jul 16, 2025, 5:03 PM Stéphane Marks wrote: > >> On Wed, Jul 16, 2025 at 4:52 PM Spencer Baugh >> wrote: >> >>> Kristoffer Balintona writes: >>> >>> > On Tue, Jul 15 2025, Spencer Baugh wrote: >>> > >>> >> Stéphane Marks writes: >>> >> >>> >>> On Tue, Jul 15, 2025 at 11:41 AM Visuwesh >>> wrote: >>> >>> >>> >>> [செவ்வாய் ஜூலை 15, 2025] Stéphane Marks wrote: >>> >>> >>> >>> > On Mon, Jul 14, 2025 at 3:54 PM Spencer Baugh < >>> sbaugh@janestreet.com> wrote: >>> >>> > >>> >>> >> Stéphane Marks writes: >>> >>> >> > On Sun, Jul 13, 2025 at 2:16 PM Stéphane Marks < >>> shipmints@gmail.com> >>> >>> >> 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=uLAwJoTGQ5cLSjFQ@mail.gmail.com >>> >>> >>> >>> 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. >> > > I think you're confused about the feature I'm describing, but anyway if > that's the case then we don't need to add object equality here at all, > because it has no use case besides this. > Entirely possible. Taking a quick look at your proposed patch, it mixes eq and equal semantics which adds to a bit of confusion over identity vs. value equality. vtable-update-object says compared with `equal' in the docstring. In the code, it uses eq to locate the object yet equal to search the cache. vtable-remove-object uses eq semantics via assq rather than assoc to locate the cache entry. vtable-insert-object also relies on eq. My patch is self consistent as far as I can tell. Once we decide on if we leave equal semantics to the caller, for example, vtable-goto-object call site first locating an object on its own, then relying on eq semantics to move point, or allow users to define -object-equal, the rest of my related changes (coming shortly after we conclude this part of the discussion) have more cache items repaired, not just these. We can debate simplifying the cache in a new cache-related patch, yes?