GNU bug report logs - #65555
29.1; Please un-obsolete buffer-local-value as a generalized variable

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 65555 in the body.
You can then email your comments to 65555 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: Adam Porter <adam <at> alphapapa.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.1; Please un-obsolete buffer-local-value as a generalized variable
Date: Sat, 26 Aug 2023 16:09:33 -0500

Hi,

In 915efbff9833ea36aeb364e032a639391516912d the BUFFER-LOCAL-VALUE
function's generalized variable forms were marked as obsolete.  The
discussion happened over a few years in bug #26624.  After a delay of
4-5 years, the obsolescence was finally marked in the aforementioned
commit.

I understand that there were some non-obvious side effects in edge
cases.  However, in common cases, the generalized variable form is very
helpful for writing more concise code.  For example:

  (setf (buffer-local-value 'ement-notifications-retro-loading buffer) nil)

...is more concise than:

  (with-current-buffer buffer
    (setq-local ement-notifications-retro-loading nil))

It also expresses its intent more directly, as it's clear that the only
purpose of the form is to set a variable in the buffer rather than
anything else that could happen when the current buffer is changed (i.e.
in context of more code, the benefit is more obvious than in this
minimal example).

As far as I can tell, the objections to the generalized variable
(i.e. the edge cases with non-obvious behavior) were theoretical in
nature, without any concrete problems being noted in real code (that is,
the report was not of a bug encountered in actual use).  In
contrast, in several places in Emacs's own code, forms were rewritten to
be more awkward as a result of this change, without solving any
problems in the changed code.  And as I've noted, there is Elisp outside
of emacs.git that uses (and would like to continue using) this idiom.

As was mentioned in the discussion on #26624, rather than obsoleting the
code and removing a useful feature from Elisp, the rare, non-obvious
behavior related to using CL-LETF could be documented as an
idiosyncrasy, like other rarely encountered rough edges in Elisp.

As well, late last year I asked on emacs-devel that the
mass-obsolescence of several generalized variables be reverted, and I
was asked to individually request specific ones to be un-obsoleted.
<https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01406.html>
I can't say that I will be able to find the time to make such a
comprehensive defense of all the ones I would like to keep using, but
please consider this to be at least one of my responses to that request.

Thanks for your consideration, and your work on Emacs.

Adam

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Adam Porter <adam <at> alphapapa.net>, Stefan Kangas <stefankangas <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 65555 <at> debbugs.gnu.org
Subject: Re: bug#65555: 29.1;
 Please un-obsolete buffer-local-value as a generalized variable
Date: Thu, 31 Aug 2023 10:22:06 +0300

Stefan and Stefan, any comments to the below?

> Date: Sat, 26 Aug 2023 16:09:33 -0500
> From: Adam Porter <adam <at> alphapapa.net>
> 
> Hi,
> 
> In 915efbff9833ea36aeb364e032a639391516912d the BUFFER-LOCAL-VALUE
> function's generalized variable forms were marked as obsolete.  The
> discussion happened over a few years in bug #26624.  After a delay of
> 4-5 years, the obsolescence was finally marked in the aforementioned
> commit.
> 
> I understand that there were some non-obvious side effects in edge
> cases.  However, in common cases, the generalized variable form is very
> helpful for writing more concise code.  For example:
> 
>    (setf (buffer-local-value 'ement-notifications-retro-loading buffer) nil)
> 
> ...is more concise than:
> 
>    (with-current-buffer buffer
>      (setq-local ement-notifications-retro-loading nil))
> 
> It also expresses its intent more directly, as it's clear that the only
> purpose of the form is to set a variable in the buffer rather than
> anything else that could happen when the current buffer is changed (i.e.
> in context of more code, the benefit is more obvious than in this
> minimal example).
> 
> As far as I can tell, the objections to the generalized variable
> (i.e. the edge cases with non-obvious behavior) were theoretical in
> nature, without any concrete problems being noted in real code (that is,
> the report was not of a bug encountered in actual use).  In
> contrast, in several places in Emacs's own code, forms were rewritten to
> be more awkward as a result of this change, without solving any
> problems in the changed code.  And as I've noted, there is Elisp outside
> of emacs.git that uses (and would like to continue using) this idiom.
> 
> As was mentioned in the discussion on #26624, rather than obsoleting the
> code and removing a useful feature from Elisp, the rare, non-obvious
> behavior related to using CL-LETF could be documented as an
> idiosyncrasy, like other rarely encountered rough edges in Elisp.
> 
> As well, late last year I asked on emacs-devel that the
> mass-obsolescence of several generalized variables be reverted, and I
> was asked to individually request specific ones to be un-obsoleted.
> <https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01406.html>
> I can't say that I will be able to find the time to make such a
> comprehensive defense of all the ones I would like to keep using, but
> please consider this to be at least one of my responses to that request.
> 
> Thanks for your consideration, and your work on Emacs.
> 
> Adam
> 
> 
> 
> 

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Adam Porter <adam <at> alphapapa.net>, Stefan Kangas <stefankangas <at> gmail.com>,
 65555 <at> debbugs.gnu.org
Subject: Re: bug#65555: 29.1; Please un-obsolete buffer-local-value as a
 generalized variable
Date: Thu, 31 Aug 2023 13:32:19 -0400

I'm OK with un0obsoleting it.
`cl-letf` is a source of problems for many generalized variables, and
maybe the better answer would be to allow generalized vars to provide
specific support for `cl-letf` (such as declare themselves as being
incompatible with it ;-).


        Stefan

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Adam Porter <adam <at> alphapapa.net>, Eli Zaretskii <eliz <at> gnu.org>,
 65555 <at> debbugs.gnu.org
Subject: Re: bug#65555: 29.1; Please un-obsolete buffer-local-value as a
 generalized variable
Date: Thu, 31 Aug 2023 21:27:41 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> I'm OK with un0obsoleting it.

Fine with me too.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: adam <at> alphapapa.net, monnier <at> iro.umontreal.ca, 65555-done <at> debbugs.gnu.org
Subject: Re: bug#65555: 29.1; Please un-obsolete buffer-local-value as a
 generalized variable
Date: Sat, 02 Sep 2023 10:46:13 +0300

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Thu, 31 Aug 2023 21:27:41 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Adam Porter <adam <at> alphapapa.net>, 65555 <at> debbugs.gnu.org
> 
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> 
> > I'm OK with un0obsoleting it.
> 
> Fine with me too.

Done one the emacs-29 branch, and closing the bug.

Previous Next

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