GNU bug report logs - #69684
Functionality of Fbare_symbol has been lost.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 69684 in the body.
You can then email your comments to 69684 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: bug-gnu-emacs <at> gnu.org
Cc: acm <at> muc.de
Subject: Functionality of Fbare_symbol has been lost.
Date: Sat, 9 Mar 2024 23:23:50 +0000

Hello Paul, hello Emacs.

Since a recent commit, Fbare_symbol (in src/data.c) no longer works on a
symbol with position when symbols-with-pos-enabled is nil, instead
signalling an error.

This is due to the new CHECK_SYMBOL (sym); statement in Fbare_symbol,
which wasn't there before.

Since I merged master into my development branch, I can no longer build
it because of this change.  A rapid reversion to the previous
functionality would be appreciated.  :-)

Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #8 received at 69684 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: eggert <at> cs.ucla.edu, 69684 <at> debbugs.gnu.org
Subject: Re: bug#69684: Functionality of Fbare_symbol has been lost.
Date: Sun, 10 Mar 2024 07:57:26 +0200

> Cc: acm <at> muc.de, Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 9 Mar 2024 23:23:50 +0000
> From: Alan Mackenzie <acm <at> muc.de>
> 
> Hello Paul, hello Emacs.
> 
> Since a recent commit, Fbare_symbol (in src/data.c) no longer works on a
> symbol with position when symbols-with-pos-enabled is nil, instead
> signalling an error.
> 
> This is due to the new CHECK_SYMBOL (sym); statement in Fbare_symbol,
> which wasn't there before.
> 
> Since I merged master into my development branch, I can no longer build
> it because of this change.  A rapid reversion to the previous
> functionality would be appreciated.  :-)

Couldn't you fix this on your branch by (what sounds like a trivial)
change in Fbare_symbol?

Btw, why is your branch special in this regard?

Message #11 received at 69684 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 69684 <at> debbugs.gnu.org
Subject: Re: bug#69684: Functionality of Fbare_symbol has been lost.
Date: Sun, 10 Mar 2024 09:21:15 +0000

Hello, Eli.

On Sun, Mar 10, 2024 at 07:57:26 +0200, Eli Zaretskii wrote:
> > Cc: acm <at> muc.de, Paul Eggert <eggert <at> cs.ucla.edu>
> > Date: Sat, 9 Mar 2024 23:23:50 +0000
> > From: Alan Mackenzie <acm <at> muc.de>

> > Hello Paul, hello Emacs.

> > Since a recent commit, Fbare_symbol (in src/data.c) no longer works on a
> > symbol with position when symbols-with-pos-enabled is nil, instead
> > signalling an error.

> > This is due to the new CHECK_SYMBOL (sym); statement in Fbare_symbol,
> > which wasn't there before.

> > Since I merged master into my development branch, I can no longer build
> > it because of this change.  A rapid reversion to the previous
> > functionality would be appreciated.  :-)

> Couldn't you fix this on your branch by (what sounds like a trivial)
> change in Fbare_symbol?

I've done that already here, of course.  But I was wanting to make a
commit yesterday evening, which of course I can't with this bug
unresolved.  Paul is quite particular over the exact formulation of these
macros and inline functions, which have an important influence on Emacs's
speed.  So I thought I would give him a chance to fix it neatly first.

> Btw, why is your branch special in this regard?

It's the branch where I'm implementing position information in doc
strings, using symbols with position to get this information.  This is
bug #67455.  Progress is pretty much at the stage where we can start
discussing the exact presentation of the information in backtraces, etc.

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #14 received at 69684 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: eggert <at> cs.ucla.edu, 69684 <at> debbugs.gnu.org
Subject: Re: bug#69684: Functionality of Fbare_symbol has been lost.
Date: Sun, 10 Mar 2024 12:39:55 +0200

> Date: Sun, 10 Mar 2024 09:21:15 +0000
> Cc: 69684 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > > Since I merged master into my development branch, I can no longer build
> > > it because of this change.  A rapid reversion to the previous
> > > functionality would be appreciated.  :-)
> 
> > Couldn't you fix this on your branch by (what sounds like a trivial)
> > change in Fbare_symbol?
> 
> I've done that already here, of course.  But I was wanting to make a
> commit yesterday evening, which of course I can't with this bug
> unresolved.  Paul is quite particular over the exact formulation of these
> macros and inline functions, which have an important influence on Emacs's
> speed.  So I thought I would give him a chance to fix it neatly first.

OK, so let's wait for Paul to chime in.

Message #17 received at 69684 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, Alan Mackenzie <acm <at> muc.de>
Cc: 69684 <at> debbugs.gnu.org
Subject: Re: bug#69684: Functionality of Fbare_symbol has been lost.
Date: Mon, 11 Mar 2024 00:38:39 -0700

[Message part 1 (text/plain, inline)]

On 2024-03-10 03:39, Eli Zaretskii wrote:
> OK, so let's wait for Paul to chime in.

The problem was that I mistakenly believed the documentation when it 
said that a symbol with position behaves like its bare symbol when 
symbols-with-position-enabled is t. Unfortunately it appears that this 
part of the doc wasn't intended to apply to bare-symbol, so when I fixed 
something else involving bare-symbol I got the semantics wrong.

As penance I installed the attached, which makes a simple code change 
along the lines that you suggested and adds a regression test to help 
prevent this bug from happening again.

The hardest part of writing this patch was adjusting the documentation 
to match what I think was the intent of the behavior. Alan, if you find 
mistakes in that please let me know.

A couple of other things.

Currently (position-symbol 'x -1) creates a symbol with position where 
the position is negative; is that intended? The documentation says 
positions are nonnegative.

Also, more test cases of the symbols with position primitives would not 
go amiss. I'm not a good person to write them, though, as I easily get 
confused by symbols with position.

[0001-Change-bare-symbol-back-to-match-intent.patch (text/x-patch, attachment)]

Message #20 received at 69684 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: acm <at> muc.de, Eli Zaretskii <eliz <at> gnu.org>, 69684 <at> debbugs.gnu.org
Subject: Re: bug#69684: Functionality of Fbare_symbol has been lost.
Date: Mon, 11 Mar 2024 20:01:06 +0000

Hello Paul.

On Mon, Mar 11, 2024 at 00:38:39 -0700, Paul Eggert wrote:
> On 2024-03-10 03:39, Eli Zaretskii wrote:
> > OK, so let's wait for Paul to chime in.

> The problem was that I mistakenly believed the documentation when it 
> said that a symbol with position behaves like its bare symbol when 
> symbols-with-position-enabled is t. Unfortunately it appears that this 
> part of the doc wasn't intended to apply to bare-symbol, so when I fixed 
> something else involving bare-symbol I got the semantics wrong.

I think the doc and doc strings were somewhat unclear when it came to
the less obvious cases.

> As penance I installed the attached, which makes a simple code change 
> along the lines that you suggested and adds a regression test to help 
> prevent this bug from happening again.

Thanks!

> The hardest part of writing this patch was adjusting the documentation 
> to match what I think was the intent of the behavior. Alan, if you find 
> mistakes in that please let me know.

That might take a little tine.  I've broken my right arm, which makes
doing Emacs strenuous work.  But I'm sure the patch  will work.

It's also worth pointing out that the uses of SWPs are expanding (see
bug #67455), something I've got mixed feelings about, even though I'm
doing the implementation.

> A couple of other things.

> Currently (position-symbol 'x -1) creates a symbol with position where 
> the position is negative; is that intended? The documentation says 
> positions are nonnegative.

Yes.  I think that back when it was being done, there was no convenient
way to exclude -ve numbers.

> Also, more test cases of the symbols with position primitives would not 
> go amiss. I'm not a good person to write them, though, as I easily get 
> confused by symbols with position.

Yes, I agree here, too.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany)

Message #25 received at 69684-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>,
 69684-done <at> debbugs.gnu.org
Subject: Re: bug#69684: Functionality of Fbare_symbol has been lost.
Date: Fri, 28 Feb 2025 19:13:55 -0800

Alan Mackenzie <acm <at> muc.de> writes:

>> As penance I installed the attached, which makes a simple code change
>> along the lines that you suggested and adds a regression test to help
>> prevent this bug from happening again.
>
> Thanks!

It seems like this issue was resolved, so I'm closing this bug report.

Previous Next

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