bug#3467: 23.0.94; let + make-local-variable => let value made global

[Lennart Borgman]

On Thu, Jun 4, 2009 at 11:14 PM, Lennart
Borgman<lennart.borgman@gmail.com> wrote:
> If you eval these lines
>
>  (defvar w14 "global")
>  (defvar w15 "global")
>  (let ((w14 "let")
>        (w15 "let"))
>    (set (make-local-variable 'w14) "local")
>    (message "w14 maybe let: in buffer=%S, global=%S" w14 (default-value 'w14))
>    (message "w15 maybe let: in buffer=%S, global=%S" w15 (default-value 
> 'w15)))
>  (message "w14 top level: in buffer=%S, global=%S" w14 (default-value 'w14))
>  (message "w15 top level: in buffer=%S, global=%S" w15 (default-value 'w15))
>
> the output will be
>
>  w14 maybe let: in buffer="local", global="let"
>  w15 maybe let: in buffer="let", global="let"
>  w14 top level: in buffer="global", global="let"
>  w15 top level: in buffer="global", global="global"
>
> All values here except w14 global value on next last line are arguably
> correct. The last value of w14 should be "global", not "let".
>
> It looks like perhaps the call to (make-local-variable w14) does not
> mark the "global let" value of w14 as let bound (or removes that
> mark).


I think the semantics of let, make-variable-buffer-local and buffer
local variables must be examined a bit to clarify this:

I think let should preserve "buffer localness" otherwise it might do
something quite different from what a user probably expect.

Fortunately this as far as I can see requires only a change in Flet.
After Fprogn and before calling unbound_to the variable values must be
reset to those matching the buffer and frame localness before let.

spec_bind has saved the buffer and frame localness just before Fprogn
so I guess one can compare with what is saved there.


However no one would want me to write the C code for this... ;-) -
Someone who is better than me at that should preferrably do it.


(BTW: gmail does not automatically enter the reply address when I make
a reply to the original bug mail. Is that a bug in gmail?)