Philipp Stephani schrieb am So., 2. Juli 2017 um 18:53 Uhr: > Michael Heerdegen schrieb am So., 18. Juni > 2017 um 06:17 Uhr: > >> Philipp Stephani 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. > Here's a patch that does just that.