bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#65209: 30.0.50; Unexpected behaviour of setq-local


From: Gerd Möllmann
Subject: bug#65209: 30.0.50; Unexpected behaviour of setq-local
Date: Fri, 11 Aug 2023 06:56:01 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.14.0

On 11.08.23 02:17, Michael Heerdegen wrote:
Gerd Möllmann <gerd.moellmann@gmail.com> writes:

Evaluate the following

(progn
   (defvar my-var :default-value)
   (make-variable-buffer-local 'my-var)
   (let ((my-var :let-value))
     (setq-local my-var :buffer-local-new))
   my-var)
=> :default-value

(progn
   (defvar my-var1 :default-value)
   (make-variable-buffer-local 'my-var1)
   (setq my-var1 :buffer-local)
   (let ((my-var1 :let-value))
     (setq-local my-var1 :buffer-local-new))
   my-var1)
=> :buffer-local

In both cases, setq-local has no effect.

But isn't it expected that `let' restores the value that was present
before entering `let'?
That's right, but here's what the docs say about setq-local:

 -- Macro: setq-local &rest pairs
     PAIRS is a list of variable and value pairs.  This macro creates a
     buffer-local binding in the current buffer for each of the
     variables, and gives them a buffer-local value.  It is equivalent
     to calling ‘make-local-variable’ followed by ‘setq’ for each of the
     variables.

In my first example, setq-local doesn't create a buffer-local binding. In the second example, it doesn't set a buffer-local value. So setq-local doesn't what the first sentence of the doc says it does.

The second sentence of the doc says something quite different than the first sentence because setq in the presence of a let-binding of course sets the value of the let-binding.

What's the right thing to do here I find hard to tell.

I think I'd personally prefer if setq-local did what the first sentence says. Just to make things in general easier to understand, I guess. I mean, the let-binding which changes the behaviour of lisp-interaction-mode in my case could be anywhere. It's kind of like a spooky action at a distance. Good luck debugging something like that.

But that's just my 2 cents.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]