GNU bug report logs - #20521
Viper version is 3.14.2 of July 4, 2013; After some hours of use I don't enter viper mode automatically on new files

Previous Next

Full log

View this message in rfc822 format

From: Johan Bockgård <bojohan <at> gnu.org>
To: Alan Morgan <Alan.Morgan <at> nextlabs.com>
Cc: "20521 <at> debbugs.gnu.org" <20521 <at> debbugs.gnu.org>
Subject: bug#20521: setq-local definitely behaving oddly for viper mode
Date: Thu, 28 May 2015 00:28:40 +0200

Alan Morgan <Alan.Morgan <at> 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)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.