GNU bug report logs - #79009
[PATCH] Improve 'vtable' object handling, cache handling, messages

Previous Next

Full log

View this message in rfc822 format

From: sbaugh <at> catern.com
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: Spencer Baugh <sbaugh <at> janestreet.com>, Kristoffer Balintona <krisbalintona <at> gmail.com>, Joost Kremers <joostkremers <at> fastmail.fm>, 79009 <at> debbugs.gnu.org, Visuwesh <visuweshm <at> gmail.com>, Adam Porter <adam <at> alphapapa.net>, Lars Ingebrigtsen <larsi <at> gnus.org>, Augusto Stoffel <arstoffel <at> gmail.com>, ijqq <at> protonmail.com
Subject: bug#79009: [PATCH] Improve 'vtable' object handling, cache handling, messages
Date: Wed, 16 Jul 2025 22:02:56 +0000 (UTC)

Stéphane Marks <shipmints <at> gmail.com> writes:

> On Wed, Jul 16, 2025 at 5:05 PM Spencer Baugh <sbaugh <at> janestreet.com> wrote:
>
>  On Wed, Jul 16, 2025, 5:03 PM Stéphane Marks <shipmints <at> gmail.com> wrote:
>
>  On Wed, Jul 16, 2025 at 4:52 PM Spencer Baugh <sbaugh <at> janestreet.com> wrote:
>
>  Kristoffer Balintona <krisbalintona <at> gmail.com> writes:
>
>  > On Tue, Jul 15 2025, Spencer Baugh wrote:
>  >
>  >> Stéphane Marks <shipmints <at> gmail.com> writes:
>  >>
>  >>> On Tue, Jul 15, 2025 at 11:41 AM Visuwesh <visuweshm <at> gmail.com> wrote:
>  >>>
>  >>>  [செவ்வாய் ஜூலை 15, 2025] Stéphane Marks wrote:
>  >>>
>  >>>  > On Mon, Jul 14, 2025 at 3:54 PM Spencer Baugh <sbaugh <at> janestreet.com> wrote:
>  >>>  >
>  >>>  >> Stéphane Marks <shipmints <at> gmail.com> writes:
>  >>>  >> > On Sun, Jul 13, 2025 at 2:16 PM Stéphane Marks <shipmints <at> 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 <at> 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.

No it doesn't.  My patch doesn't change equality semantics it all.  It
changes nothing related to that.

I'm confused why you're talking about my patch now, because it has
nothing to do with this sub-thread of the conversation; this sub-thread
is about object equality, not the cache, and my patch only changes the
cache.  (I suggest using debbugs to track bug discussions rather than
gmail, it will help keep the threads clearer, and make it easier for
people to have discussions with you)

> vtable-update-object says compared with `equal' in the docstring.

That's pre-existing (wrong) text in the docstring, which was not changed
by my patch.  Note that the same bug exists after your patch.

Part of the point of making small patches is not fixing random other
unrelated bugs.

> 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.

Yes.  They all use eq to find objects.  None of that was changed at all
in my patch, becuase my patch has nothing to do with how objects are
compared.

> 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?

Sure.  If we debate it in a new patch, then don't change the cache in
this patch.  If you want to change the cache in this patch, then we have
to debate it now.

Previous Next

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