[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#65555: 29.1; Please un-obsolete buffer-local-value as a generalized
From: |
Eli Zaretskii |
Subject: |
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@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
>
>
>
>