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

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 20521 in the body.
You can then email your comments to 20521 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alan Morgan <Alan.Morgan <at> nextlabs.com>
To: "kifer <at> cs.stonybrook.edu" <kifer <at> cs.stonybrook.edu>,
 "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 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
Date: Wed, 6 May 2015 16:35:26 -0700

[Message part 1 (text/plain, inline)]

Congratulations! You may have unearthed a bug in Viper!
Please mail a concise, accurate summary of the problem to the address above.

-------------------------------------------------------------------

I don't have a reproducible case (sorry) and am working on debugging
this myself, but it's hard to reproduce. I have emacs up all the time
and I've noticed that after "a few hours" viper-mode won't be entered in
automatically for new buffers (loaded with C-x C-f or :r. It doesn't
seem to matter). I have to M-x viper-mode manually.

Up until this point I've focused on set-viper-state-in-major-mode. It
looks like viper-current-state is set to vi-state even though I'm not in
viper-mode. This seems wrong to me (I'm assuming this state is only set
when in viper-mode), but I can't figure out how it's happening.

Googling has not been productive yet, hence this (rather unhelpful, I imagine) bug report.

Emacs  : GNU Emacs 24.5.1 (x86_64-w64-mingw32)
of 2015-04-05 on KAEL
Package: Viper version is 3.14.2 of July 4, 2013

current state:
==============
(setq
viper-vi-minibuffer-minor-mode nil
viper-insert-minibuffer-minor-mode nil
viper-vi-intercept-minor-mode t
viper-vi-local-user-minor-mode t
viper-vi-kbd-minor-mode t
viper-vi-global-user-minor-mode t
viper-vi-state-modifier-minor-mode t
viper-vi-diehard-minor-mode nil
viper-vi-basic-minor-mode t
viper-replace-minor-mode nil
viper-insert-intercept-minor-mode nil
viper-insert-local-user-minor-mode nil
viper-insert-kbd-minor-mode nil
viper-insert-global-user-minor-mode nil
viper-insert-state-modifier-minor-mode nil
viper-insert-diehard-minor-mode nil
viper-insert-basic-minor-mode nil
viper-emacs-intercept-minor-mode nil
viper-emacs-local-user-minor-mode nil
viper-emacs-kbd-minor-mode nil
viper-emacs-global-user-minor-mode nil
viper-emacs-state-modifier-minor-mode nil
viper-automatic-iso-accents nil
viper-special-input-method nil
viper-want-emacs-keys-in-insert nil
viper-want-emacs-keys-in-vi t
viper-keep-point-on-undo nil
viper-no-multiple-ESC nil
viper-electric-mode t
viper-ESC-key [escape]
viper-want-ctl-h-help nil
viper-ex-style-editing t
viper-delete-backwards-in-replace nil
viper-vi-style-in-minibuffer t
viper-vi-state-hook 'viper-restore-cursor-type
viper-insert-state-hook 'viper-set-insert-cursor-type
viper-replace-state-hook 'viper-restore-cursor-type
viper-emacs-state-hook 'viper-restore-cursor-type
ex-cycle-other-window t
ex-cycle-through-non-files nil
viper-expert-level 2
major-mode 'emacs-lisp-mode
viper-device-type 'w32
color-display-p t
frame-parameters '((tool-bar-position . top) (parent-id) (explicit-name) (display . "w32")
                    (visibility . t) (icon-name) (window-id . "132178") (top + -8) (left + -8)
                    (buried-buffer-list #<buffer *Completions*> #<buffer  *viper-ask-level*>)
                    (buffer-list #<buffer viper.el> #<buffer  *Minibuf-1*> #<buffer buildRelease>
                     #<buffer build_publish.xml> #<buffer *Buffer List*> #<buffer viper.notes.txt>
                     #<buffer *Messages*> #<buffer *grep*> #<buffer configure<main>> #<buffer main>
                     #<buffer build_policies.pl> #<buffer PSRTestPolicies.xml> #<buffer Engine.java>
                     #<buffer *GNU Emacs*> #<buffer *scratch*>)
                    (unsplittable) (minibuffer . #<window 4 on  *Minibuf-0*>) (modeline . t)
                    (width . 211) (height . 52) (name . "emacs <at> MANN")
                    (viper-vi-state-cursor-color . "dodgerblue")
                    (viper-saved-cursor-color-in-replace-mode . "dodgerblue") (environment)
                    (cursor-color . "dodgerblue") (background-mode . dark) (display-type . color)
                    (horizontal-scroll-bars . t) (window-system . w32) (scroll-bar-width . 0)
                    (cursor-type . box) (auto-lower) (auto-raise) (icon-type) (fullscreen . maximized)
                    (title) (buffer-predicate) (tool-bar-lines . 0) (menu-bar-lines . 1) (alpha)
                    (right-fringe . 9) (left-fringe . 9) (line-spacing) (screen-gamma)
                    (border-color . "black") (mouse-color . "green")
                    (background-color . "darkslategrey") (foreground-color . "white")
                    (vertical-scroll-bars) (bottom-divider-width . 0) (right-divider-width . 0)
                    (internal-border-width . 0) (border-width . 2)
                    (font . "-outline-Consolas-normal-normal-normal-mono-16-*-*-*-c-*-iso8859-1")
                    (font-backend uniscribe gdi))
minibuffer-vi-face [face unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified]
minibuffer-insert-face [face unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified]
minibuffer-emacs-face [face unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified]
)

 ---------------------------------------------------------------------
STATEMENT OF CONFIDENTIALITY
 
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. No representation is made on its accuracy or completeness of the information contained in this electronic message. Certain assumptions may have been made in the preparation of this material as at this date, and are subject to change without notice. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. Please reply to the sender at NextLabs Inc and destroy all copies of this message and any attachments from your system. ======================================================================

[Message part 2 (text/html, inline)]

Message #8 received at 20521 <at> debbugs.gnu.org (full text, mbox):

From: Alan Morgan <Alan.Morgan <at> nextlabs.com>
To: "20521 <at> debbugs.gnu.org" <20521 <at> debbugs.gnu.org>
Subject: Bug 2051
Date: Fri, 15 May 2015 13:39:13 -0700

[Message part 1 (text/plain, inline)]

I have more information on this bug, although I still don't have a reproducible case. The problem happens when the *global* value of viper-current-state is changed from emacs-state to vi-state. Once this happens we are in trouble, because new buffers will not be assigned the vi key-bindings so anything other than cursor movement keys and a few others will do nothing. I made the following changes to viper-cmd.el in the function viper-change-state:

  ;; Always turn off quail mode in vi state
  (cond ((eq new-state 'vi-state) (viper-set-input-method nil)) ;intl input off
                (viper-special-input-method (viper-set-input-method t)) ;intl input on
                (t (viper-set-input-method nil)))

  (message (concat "Setting viper-current-state from " (prin1-to-string viper-current-state) " to " (prin1-to-string new-state) " via setq"))
  (global-viper-current-state)
  (setq viper-current-state new-state)
  (global-viper-current-state)

Global-viper-current-state is defined as follows:

(defun global-viper-current-state ()
  (message (concat "The global value of viper-current-state is " (prin1-to-string (default-value 'viper-current-state)))))

Most of the time I see the following:

Setting viper-current-state from emacs-state to insert-state via setq
The global value of viper-current-state is emacs-state [2 times]

But then, for no reason that I could see, I saw this:
Setting viper-current-state from emacs-state to vi-state via setq
The global value of viper-current-state is emacs-state
The global value of viper-current-state is vi-state

How on Earth? Perhaps setq is broken. Perhaps we aren't actually *in* a buffer when setq is called (is that possible?) and thus the global value is being set. I don't understand how this is possible and, now that I've uncovered this, I'm not sure what I can do to fix it.

Alan


 ---------------------------------------------------------------------
STATEMENT OF CONFIDENTIALITY
 
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. No representation is made on its accuracy or completeness of the information contained in this electronic message. Certain assumptions may have been made in the preparation of this material as at this date, and are subject to change without notice. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. Please reply to the sender at NextLabs Inc and destroy all copies of this message and any attachments from your system. ======================================================================

[Message part 2 (text/html, inline)]

Message #11 received at 20521 <at> debbugs.gnu.org (full text, mbox):

From: Nick Andryshak <nandryshak <at> gmail.com>
To: Alan Morgan <Alan.Morgan <at> nextlabs.com>
Cc: "20521 <at> debbugs.gnu.org" <20521 <at> debbugs.gnu.org>
Subject: Re: bug#20521: Bug 2051
Date: Fri, 15 May 2015 17:08:22 -0400

> How on Earth? Perhaps setq is broken.

That's really not something you should say lightly! 

> Perhaps we aren't actually *in* a buffer when setq is called (is that
> possible?) and thus the global value is being set. I don't understand
> how this is possible and, now that I've uncovered this, I'm not sure
> what I can do to fix it.

I think you may misunderstand: setq always sets a global variable.
Perhaps you want to use setq-local?

See:

http://www.gnu.org/software/emacs/manual/html_node/elisp/Global-Variables.html

- Nick

Message #14 received at 20521 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Nick Andryshak <nandryshak <at> gmail.com>, Alan Morgan
 <Alan.Morgan <at> nextlabs.com>
Cc: 20521 <at> debbugs.gnu.org
Subject: RE: bug#20521: Bug 2051
Date: Fri, 15 May 2015 14:42:22 -0700 (PDT)

> I think you may misunderstand: setq always sets a global variable.

Since when?

  -- Macro: setq-local variable value
     This macro creates a buffer-local binding in the current buffer for
     VARIABLE, and gives it the buffer-local value VALUE.  It is
     equivalent to calling `make-local-variable' followed by `setq'.
     VARIABLE should be an unquoted symbol.

Note the last sentence, which points out that `setq' does not always
set a global variable.  If it did, then so would `setq-local',
according to that text.

Message #17 received at 20521 <at> debbugs.gnu.org (full text, mbox):

From: Alan Morgan <Alan.Morgan <at> nextlabs.com>
To: Nick Andryshak <nandryshak <at> gmail.com>
Cc: "20521 <at> debbugs.gnu.org" <20521 <at> debbugs.gnu.org>
Subject: RE: bug#20521: Bug 2051
Date: Fri, 15 May 2015 14:51:25 -0700

I shouldn't have used the term "global". I meant "default". If the variable is buffer-local then setq should set the buffer-local value and *not* the default value.

In this situation is looks like setq is *sometimes* setting the default value of a buffer local variable.

setq-local is the same as calling make-local-variable followed by setq

Alan

-----Original Message-----
From: Nick Andryshak [mailto:nandryshak <at> gmail.com] 
Sent: Friday, May 15, 2015 2:08 PM
To: Alan Morgan
Cc: 20521 <at> debbugs.gnu.org
Subject: Re: bug#20521: Bug 2051

> How on Earth? Perhaps setq is broken.

That's really not something you should say lightly! 

> Perhaps we aren't actually *in* a buffer when setq is called (is that
> possible?) and thus the global value is being set. I don't understand 
> how this is possible and, now that I've uncovered this, I'm not sure 
> what I can do to fix it.

I think you may misunderstand: setq always sets a global variable.
Perhaps you want to use setq-local?

See:

http://www.gnu.org/software/emacs/manual/html_node/elisp/Global-Variables.html

- Nick

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________

 ---------------------------------------------------------------------
STATEMENT OF CONFIDENTIALITY
 
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. No representation is made on its accuracy or completeness of the information contained in this electronic message. Certain assumptions may have been made in the preparation of this material as at this date, and are subject to change without notice. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. Please reply to the sender at NextLabs Inc and destroy all copies of this message and any attachments from your system. ======================================================================

Message #20 received at 20521 <at> debbugs.gnu.org (full text, mbox):

From: Nick Andryshak <nandryshak <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Alan Morgan <Alan.Morgan <at> nextlabs.com>, 20521 <at> debbugs.gnu.org
Subject: Re: bug#20521: Bug 2051
Date: Fri, 15 May 2015 19:24:38 -0400

[Message part 1 (text/plain, inline)]

Interesting, thanks. I suppose I misunderstand the manual page that I
linked.

- Nick

On Fri, May 15, 2015 at 5:42 PM, Drew Adams <drew.adams <at> oracle.com> wrote:

> > I think you may misunderstand: setq always sets a global variable.
>
> Since when?
>
>   -- Macro: setq-local variable value
>      This macro creates a buffer-local binding in the current buffer for
>      VARIABLE, and gives it the buffer-local value VALUE.  It is
>      equivalent to calling `make-local-variable' followed by `setq'.
>      VARIABLE should be an unquoted symbol.
>
> Note the last sentence, which points out that `setq' does not always
> set a global variable.  If it did, then so would `setq-local',
> according to that text.
>

[Message part 2 (text/html, inline)]

Message #23 received at 20521 <at> debbugs.gnu.org (full text, mbox):

From: Alan Morgan <Alan.Morgan <at> nextlabs.com>
To: "20521 <at> debbugs.gnu.org" <20521 <at> debbugs.gnu.org>
Subject: setq-local definitely behaving oddly for viper mode
Date: Wed, 27 May 2015 09:50:28 -0700

[Message part 1 (text/plain, inline)]

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.


 ---------------------------------------------------------------------
STATEMENT OF CONFIDENTIALITY
 
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. No representation is made on its accuracy or completeness of the information contained in this electronic message. Certain assumptions may have been made in the preparation of this material as at this date, and are subject to change without notice. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. Please reply to the sender at NextLabs Inc and destroy all copies of this message and any attachments from your system. ======================================================================

[Message part 2 (text/html, inline)]

Message #26 received at 20521 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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)

Message #29 received at 20521 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alan Morgan <Alan.Morgan <at> nextlabs.com>
Cc: "20521 <at> debbugs.gnu.org" <20521 <at> debbugs.gnu.org>
Subject: Re: bug#20521: setq-local definitely behaving oddly for viper mode
Date: Wed, 27 May 2015 22:02:34 -0400

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

I think that's a bug.
setq-local uses make-local-variable and that *should* create
a buffer-local binding, even if the variable is currently let-bound.
The fact that the variable is `make-variable-buffer-local' is no excuse.


        Stefan

Message #34 received at 20521 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Alan Morgan <Alan.Morgan <at> nextlabs.com>,  "20521 <at> debbugs.gnu.org"
 <20521 <at> debbugs.gnu.org>
Subject: Re: bug#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
Date: Thu, 10 Feb 2022 09:11:57 +0100

Johan Bockgård <bojohan <at> gnu.org> writes:

> 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)

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

It looks like this has been fixed in the years since it was reported --
this form evaluates to (t) in Emacs 29, so I'm closing this bug report.
If there's more to be done here, please respond to the debbugs address
and we'll reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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