From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 65051@debbugs.gnu.org, acm@muc.de
Subject: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled.
Date: Tue, 8 Aug 2023 15:33:32 +0000 [thread overview]
Message-ID: <ZNJgTH6e6713-Q0H@ACM> (raw)
In-Reply-To: <jwvh6paxndx.fsf-monnier+emacs@gnu.org>
Hello, Stefan.
On Mon, Aug 07, 2023 at 22:56:31 -0400, Stefan Monnier wrote:
> >> Could you explain why you think it's a bug?
> > When symbols-with-pos-enabled is non-nil, the two arguments to that
> > equal call are equal. That is the point of s-w-p-e.
> AFAIK the point of the `symbols-with-pos-enabled` is to try and keep the
> performance impact of sympos under control, and that matters only for
> `eq`, so I don't think there's a strong reason here for `equal` to pay
> attention to it.
Which is like saying you're happy for it to be undefined. In the code
at the moment, the result of `equal' on symbols with position is
undefined, i.e. it returns a random value.
> > When s-w-p-e is nil, and the "magic" is thus switched off, the two lisp
> > objects have different type (the first is a symbol, the second is a
> > pseudovector), thus cannot be equal.
> "cannot" is obviously not the correct word here, since currently they
> are considered `equal`, so clearly they *can* be considered `equal`:
> it's easy to implement, and experience shows that "it works".
> 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.
> AFAICT whether sympos should be `equal` to others and/or to bare symbols
> is something we pretty much get to choose freely based on convenience:
No we don't. They have to be chosen to be as consistent as possible
with the rest of Emacs.
> either the current behavior or the one you now advocate are perfectly
> acceptable and not bugs.
The current behaviour is a bug. It was me that coded up that amendment
to equal, and I can remember simply not taking into account the scenario
we're talking about.
> As I said elsewhere, I'm not sure which choice is best, but at least we
> have some experience with the current choice ....
I rather doubt that. When have SWPs, when symbols-with-pos-enabled is
nil, been tested by equal, apart from in tests, maybe?
> .... and I haven't seen any clear problem with it yet, so I'd tend to
> lean towards keeping the current behavior.
I'm wondering why you're making such a big thing out of it. It's a
small change which will increase consistency and predictability in
Emacs in a small way, without any negative effects.
> What would be the concrete advantages of the new behavior compared to
> the current one?
There are no "concrete" advantages, aside from an insignificant increase
in speed for Emacs when not byte compiling. The code and the
documentation currently don't match. Fixing the code, by removing a
special case, is easier and more satisfying than documenting that
special case in the Elisp manual.
> Stefan
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2023-08-08 15:33 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-04 14:00 bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled Alan Mackenzie
2023-08-04 14:32 ` Eli Zaretskii
2023-08-04 14:59 ` Alan Mackenzie
2023-08-04 15:27 ` Eli Zaretskii
2023-08-04 17:06 ` Alan Mackenzie
2023-08-04 18:01 ` Eli Zaretskii
2023-08-05 10:45 ` Alan Mackenzie
2023-08-05 10:57 ` Eli Zaretskii
2023-08-05 11:52 ` Alan Mackenzie
2023-08-05 12:13 ` Eli Zaretskii
2023-08-05 13:04 ` Alan Mackenzie
2023-08-05 13:13 ` Eli Zaretskii
2023-08-13 16:14 ` Alan Mackenzie
2023-08-05 14:40 ` Mattias Engdegård
2023-08-05 16:59 ` Alan Mackenzie
2023-08-05 17:02 ` Mattias Engdegård
2023-08-05 21:07 ` Alan Mackenzie
2023-08-06 13:37 ` Mattias Engdegård
2023-08-06 15:02 ` Alan Mackenzie
2023-08-07 8:58 ` Mattias Engdegård
2023-08-07 9:44 ` Alan Mackenzie
2023-08-09 18:45 ` Mattias Engdegård
2023-08-07 3:30 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-07 9:20 ` Alan Mackenzie
2023-08-08 2:56 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-08 15:33 ` Alan Mackenzie [this message]
2023-08-10 3:28 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-10 9:14 ` Alan Mackenzie
2023-08-10 14:28 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-10 18:35 ` Alan Mackenzie
2023-08-12 5:36 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-12 6:10 ` Eli Zaretskii
2023-08-12 18:46 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-12 19:10 ` Eli Zaretskii
2023-08-13 15:27 ` Alan Mackenzie
2023-08-12 10:41 ` Alan Mackenzie
2023-08-12 18:07 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-13 13:52 ` Alan Mackenzie
2023-08-12 21:59 ` Alan Mackenzie
2023-08-11 0:51 ` Dmitry Gutov
2023-08-11 10:42 ` Alan Mackenzie
2023-08-11 11:18 ` Dmitry Gutov
2023-08-11 12:05 ` Alan Mackenzie
2023-08-11 13:19 ` Dmitry Gutov
2023-08-11 14:04 ` Alan Mackenzie
2023-08-11 18:15 ` Dmitry Gutov
[not found] ` <handler.65051.B.169115764532326.ack@debbugs.gnu.org>
2023-09-04 12:57 ` bug#65051: Acknowledgement (internal_equal manipulates symbols with position without checking symbols-with-pos-enabled.) Alan Mackenzie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZNJgTH6e6713-Q0H@ACM \
--to=acm@muc.de \
--cc=65051@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).