Subject: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled.

From: Alan Mackenzie <[email-masked]>
Date: Fri, 11 Aug 2023 12:05:34 +0000

Hello, Dmitry.

On Fri, Aug 11, 2023 at 14:18:15 +0300, Dmitry Gutov wrote:
> On 11/08/2023 13:42, Alan Mackenzie wrote:
> > On Fri, Aug 11, 2023 at 03:51:09 +0300, Dmitry Gutov wrote:
> >> On 08/08/2023 18:33, Alan Mackenzie wrote:
> >>>> So I'm still wondering why you think it's a bug.
> >>> Because it violates the definition and basic understanding of equal.
> >>> It's a special case when no special case is needed.

> >> Does 'equal'-ity of strings with and without text properties (or with
> >> different text properties) violate these as well?

> > Maybe, maybe not.  It depends on whether you consider the text
> > properties on a string (or buffer portion) an essential part of the
> > string or not.

> ...or, like, a metadata attached to a value. Which is an approach to 
> have its benefits as well, seeing how we've been living with it for many 
> years.

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

> 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.  Currently,
the working of s-w-p-enabled is inconsistent, and should be fixed, which
is what this bug is about.

-- 
Alan Mackenzie (Nuremberg, Germany).