Michael Heerdegen <michael_heerdegen@web.de> schrieb am So., 18. Juni 2017
um 06:17 Uhr:

> Philipp Stephani <p.stephani2@gmail.com> writes:
>
> > It's possible to fix this (see attached patch), but at the expense of
> > breaking other valid use cases such as (cl-incf (buffer-local-value
> > ...)). Not sure whether the bug can be fixed at all without breaking
> > other stuff.
>
> I have no solution, but some thoughts.
>
> The more I think about it, the more I come to the conclusion that
> `buffer-local-value' does not have a well defined according place.
>
> The function `buffer-local-value' is not injective: it maps different
> states to the same value because it can't express whether the VARIABLE's
> binding is buffer-local or not.  But we need this information because we
> need to undo creating a buffer local binding in the setter when closing
> the `letf'.
>
> And the setter, accepting only a value for the binding, isn't
> surjective, because the argument doesn't hold any information of
> buffer-localness.  Moreover, we want the setter to always create a
> buffer-local binding in one situation (setf), but this isn't true for
> the setter we need to use for `cl-letf'.
>
> We could widen the semantics of `cl-letf' to do what we want in this
> case, but I'm not sure if it's worth the trouble.  Not if there are more
> cases like this.
>
>
Thanks for this great analysis. Given this, it seems that the place
definition for `buffer-local-value' should be removed from gv.el.