GNU bug report logs - #65051
internal_equal manipulates symbols with position without checking symbols-with-pos-enabled.

Previous Next

Full log

View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 65051 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled.
Date: Fri, 11 Aug 2023 14:04:59 +0000

Hello, Dmitry.

On Fri, Aug 11, 2023 at 16:19:47 +0300, Dmitry Gutov wrote:
> Hi again, Alan,

> On 11/08/2023 15:05, Alan Mackenzie wrote:

> >>> I think it was possibly a design error to have text
> >>> properties conceptually as a part of a string/buffer rather than
> >>> something associated with it, like an overlay.  The fact that equal
> >>> ignores these properties supports this view.

> >> We needed a reference to access the properties from. Overlays are
> >> different because they attach to a buffer. There is nothing else to
> >> attach to when you have a string value.

> > This is arbitrary; overlays _could_ have been made attachable to
> > strings, in which case text properties need not have been.  That would
> > have prevented all the heart searching when considering equal with
> > strings.

> Then we would have some "metadata" that's part of the value, and some 
> that is not part of the value. How would we look those up, though? 
> Through a global registry?

> equal-including-properties is useful enough, by the way. In the tests, 
> at least.

Yes.

> >> Which seems very similar to the situation with symbols, I think.

> > There are practical differences.  Having symbols with position simply
> > handled as their bare symbols would slow down Emacs quite a lot.  That's
> > why we have symbols-with-pos-enabled.  But you know that.

> Does the current impl of 'equal' create worse performance as well? That 
> would be a good argument to change it.

Yes, but unmeasurably so.  The current implementation has two
comparisons, quite complicated, where only one simple one is needed, for
the typical use-case.

>  >  Currently, the working of s-w-p-enabled is inconsistent, and
>  >  should be fixed, which is what this bug is about.

> Inconsistent with what?

With its definition: when s-w-p-enabled is non-nil, SWPs are handled
specially.  When it's nil, they're not (or, at least, shouldn't be).

> If we're talking about the relation between EQUAL and EQ, objects that
> are EQ have to be EQUAL, but those that are EQUAL don't have to be EQ.

I wasn't talking about that relationship, no, but there is no danger to
it in fixing the current bug (or, indeed, in leaving it unfixed).

> Anyway, I'd like to offer a question from a different perspective: 
> should two symbols-with-positions where the positions are different but 
> the symbol is the same, be equal between each other?

Yes, when and only when symbols-with-pos-enabled is non-nil.

> If yes (which is my reading of fns.c:2755), then it makes sense for
> them to be equal-able to symbols without positions as well.

Again, this should be the case when s-w-p-enabled is non-nil and only
then.

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

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