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

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

[Adam Porter]

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

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

[Eli Zaretskii]

Stefan and Stefan, any comments to the below?

> Date: Sat, 26 Aug 2023 16:09:33 -0500
> From: Adam Porter <adam@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
> 
> 
> 
> 

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

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

[Stefan Kangas]

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

> I'm OK with un0obsoleting it.

Fine with me too.

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

[Eli Zaretskii]

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

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