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

[Eli Zaretskii <eliz@gnu.org>]

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
> 
> 
> 
>