embark
embark copied to clipboard
oantolin
Avoid using 'buffer-local-value' as a generalised variable
Why would they deprecate (setf buffer-local-value)? I don't really like this. Let me read up on the rationale before doing anything about it.
I don't think the deprecation of these variables is a good idea or justified, but whatever. These setters have side effects. cl-letf is not their only use case, but they are only deprecated because of the problematic side effects there, which are not undone after the block. Furthermore the (alist-get) gv also has a bad side effect but is used far too widely to be deprecated. All in all, a bad development...
For now I've refused merging this in packages. :-P
See https://github.com/minad/consult/issues/636#issuecomment-1229481271 where I also complained about this. But I am too lazy to debate with the maintainers. They are stubborn anyway. :-P
I really have no opinion on this matter. All I know is that nothing changes upstream, all users will encounter at least one warning whenever an embark (or vertico, etc.) command is invoked.
I really have no opinion on this matter. All I know is that nothing changes upstream, all users will encounter at least one warning whenever an embark (or vertico, etc.) command is invoked.
No, the warning will only occur during package installation/compilation.
No, the warning will only occur during package installation/compilation.
Just checked again, and you are right. I must have had some uncompiled files lying around?
Reading the mailing list thread linked to by @tarsius in https://github.com/oantolin/embark/pull/546 has made me change my mind.
@oantolin May I ask which argument in the thread convinced you? For (setf (alist-get ...) ...), the corresponding cl-letf will also have side effects if you don't set the REMOVE argument.
(let ((list nil))
(cl-letf (((alist-get 'key list) 123))
nil)
(message "LIST %S" list))
On the other hand if the key/value pair exists, there is no side effect, as in this case if the variable is already buffer-local before the cl-letf. I agree that the semantics are not nice but one could have also solved this differently:
- Check that the pre-condition holds which makes
cl-letfside-effect free. - Extend
gvandcl-letfto store more state which allows fully recovery.
Oh, it's not really the case that some argument convinced me that (setf buffer-local-value) should be removed. What I meant when I said reading the thread made me change my mind is just that I previously did not know there was any reason for deprecating (setf buffer-local-value), and thought it was just arbitrary. Now I know there is at least some problem with it so the deprecation is not arbitrary; and thus it is unlikely to be reversed, which in turn means this change will need to be made eventually.
Personally I'd be in favor of fixing the issue of localness not being restored. I'd be quite happy with your option 2: extend gv and cl-letf to store more state.