From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#65051: internal_equal manipulates symbols with position without checking symbols-with-pos-enabled. Date: Tue, 8 Aug 2023 15:33:32 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9614"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 65051@debbugs.gnu.org, acm@muc.de To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 08 17:34:29 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qTOj6-0002Gl-Vm for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 08 Aug 2023 17:34:28 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qTOik-0002hr-3r; Tue, 08 Aug 2023 11:34:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qTOih-0002h0-IW for bug-gnu-emacs@gnu.org; Tue, 08 Aug 2023 11:34:03 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qTOih-0006WM-76 for bug-gnu-emacs@gnu.org; Tue, 08 Aug 2023 11:34:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qTOig-0001GT-Qz for bug-gnu-emacs@gnu.org; Tue, 08 Aug 2023 11:34:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Aug 2023 15:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65051 X-GNU-PR-Package: emacs Original-Received: via spool by 65051-submit@debbugs.gnu.org id=B65051.16915088214804 (code B ref 65051); Tue, 08 Aug 2023 15:34:02 +0000 Original-Received: (at 65051) by debbugs.gnu.org; 8 Aug 2023 15:33:41 +0000 Original-Received: from localhost ([127.0.0.1]:37553 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qTOiL-0001FQ-Cn for submit@debbugs.gnu.org; Tue, 08 Aug 2023 11:33:41 -0400 Original-Received: from mx3.muc.de ([193.149.48.5]:57264) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qTOiJ-0001F3-MY for 65051@debbugs.gnu.org; Tue, 08 Aug 2023 11:33:40 -0400 Original-Received: (qmail 35992 invoked by uid 3782); 8 Aug 2023 17:33:33 +0200 Original-Received: from acm.muc.de (pd953ac8f.dip0.t-ipconnect.de [217.83.172.143]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 08 Aug 2023 17:33:32 +0200 Original-Received: (qmail 7938 invoked by uid 1000); 8 Aug 2023 15:33:32 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:266970 Archived-At: 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).