bug#20521: setq-local definitely behaving oddly for viper mode

[Johan Bockgård]

Alan Morgan <Alan.Morgan@nextlabs.com> writes:

> I must be going crazy. Here is my latest sanity check code in
> viper-check-state in viper-cmd.el
>
>   (when (eq (default-value 'viper-current-state) 'vi-state)
>     (message "Doomed going in"))
>  (setq-local viper-current-state new-state)
>   (when (eq (default-value 'viper-current-state) 'vi-state)
>     (message "Doomed. viper-current-state is now vi-state"))
>
> The setq-local replaces a simple setq at about line 380. When the
> problem starts I see the "Doomed. Viper-current-state is now
> vi-state", but I do *not* see the "Doomed going in" message. This
> implies that setq-local is setting the default value of the variable
> and that really shouldn't be possible. Either I'm nuts or this is an
> emacs bug.

viper-current-state is defined with make-variable-buffer-local (via
viper-deflocalvar), which makes it an "automatically buffer-local"
variable:

     This function marks VARIABLE (a symbol) automatically buffer-local,
     so that any subsequent attempt to set it will make it local to the
     current buffer at the time.  Unlike ‘make-local-variable’, with
     which it is often confused, this cannot be undone, and affects the
     behavior of the variable in all buffers.

     A peculiar wrinkle of this feature is that binding the variable
     (with ‘let’ or other binding constructs) does not create a
     buffer-local binding for it.  Only setting the variable (with ‘set’
     or ‘setq’), while the variable does not have a ‘let’-style binding
     that was made in the current buffer, does so.

Apparently even an explicit setq-local (make-local-variable) cannot
create a local binding in the situation that the second paragraph talks
about:

(progn
  (make-variable-buffer-local 'x)
  (let ((x 0))
    (setq-local x 1)
    (cons (local-variable-p 'x)
          (default-value 'x))))
 => (nil . 1)