From debbugs-submit-bounces@debbugs.gnu.org Wed May 06 19:39:40 2015 Received: (at submit) by debbugs.gnu.org; 6 May 2015 23:39:40 +0000 Received: from localhost ([127.0.0.1]:36642 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yq8ug-0003JE-T0 for submit@debbugs.gnu.org; Wed, 06 May 2015 19:39:40 -0400 Received: from eggs.gnu.org ([208.118.235.92]:53150) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yq8rZ-0003EL-TK for submit@debbugs.gnu.org; Wed, 06 May 2015 19:36:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yq8rS-0004gb-TH for submit@debbugs.gnu.org; Wed, 06 May 2015 19:36:20 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=5.0 tests=BAYES_50,HTML_MESSAGE, LONGWORDS autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:35218) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yq8rS-0004gX-QE for submit@debbugs.gnu.org; Wed, 06 May 2015 19:36:18 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38418) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yq8rQ-0004iG-O1 for bug-gnu-emacs@gnu.org; Wed, 06 May 2015 19:36:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yq8rN-0004fF-UT for bug-gnu-emacs@gnu.org; Wed, 06 May 2015 19:36:16 -0400 Received: from mail1.bemta8.messagelabs.com ([216.82.243.198]:26081) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yq8rN-0004f9-OW for bug-gnu-emacs@gnu.org; Wed, 06 May 2015 19:36:13 -0400 Received: from [216.82.242.19] by server-6.bemta-8.messagelabs.com id 26/90-20520-B65AA455; Wed, 06 May 2015 23:36:11 +0000 X-Env-Sender: Alan.Morgan@nextlabs.com X-Msg-Ref: server-9.tower-191.messagelabs.com!1430955369!13569917!1 X-Originating-IP: [173.167.112.114] X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=nextlabs.com,-,- X-VirusChecked: Checked Received: (qmail 21098 invoked from network); 6 May 2015 23:36:11 -0000 Received: from customer.nextlabs.com (HELO mail.nextlabs.com) (173.167.112.114) by server-9.tower-191.messagelabs.com with AES128-SHA encrypted SMTP; 6 May 2015 23:36:11 -0000 Received: from NXT-EXCH.nextlabs.com ([169.254.1.117]) by nxt-exchfe02.nextlabs.com ([fe80::7c5d:a47f:a7a8:9685%13]) with mapi; Wed, 6 May 2015 16:35:27 -0700 From: Alan Morgan To: "kifer@cs.stonybrook.edu" , "bug-gnu-emacs@gnu.org" Date: Wed, 6 May 2015 16:35:26 -0700 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 Thread-Topic: 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 Thread-Index: AdCIVUBvoNzrigpkSbqbxEborMw7AQ== Message-ID: <0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E554241@NXT-EXCH.nextlabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E554241NXTEXCHnext_" MIME-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Wed, 06 May 2015 19:39:36 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.2 (--) --_000_0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E554241NXTEXCHnext_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Congratulations! You may have unearthed a bug in Viper! Please mail a concise, accurate summary of the problem to the address abov= e. ------------------------------------------------------------------- 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 imag= ine) 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,=202013 current state: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (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") (t= op + -8) (left + -8) (buried-buffer-list # #) (buffer-list # #= # # # #= # # #> # # # # # #) (unsplittable) (minibuffer . #) (modeline . t) (width . 211) (height . 52) (name . "emacs@MANN") (viper-vi-state-cursor-color . "dodgerblue") (viper-saved-cursor-color-in-replace-mode . "dodgerblu= e") (environment) (cursor-color . "dodgerblue") (background-mode . dark)= (display-type . color) (horizontal-scroll-bars . t) (window-system . w32) (sc= roll-bar-width . 0) (cursor-type . box) (auto-lower) (auto-raise) (icon-ty= pe) (fullscreen . maximized) (title) (buffer-predicate) (tool-bar-lines . 0) (menu-= bar-lines . 1) (alpha) (right-fringe . 9) (left-fringe . 9) (line-spacing) (s= creen-gamma) =20 (border-color . "black") (mouse-color . "green") (background-color . "darkslategrey") (foreground-color= . "white") (vertical-scroll-bars) (bottom-divider-width . 0) (rig= ht-divider-width . 0) (internal-border-width . 0) (border-width . 2) (font . "-outline-Consolas-normal-normal-normal-mono-1= 6-*-*-*-c-*-iso8859-1") (font-backend uniscribe gdi)) minibuffer-vi-face [face unspecified unspecified unspecified unspecified u= nspecified unspecified unspecified unspecified unspecified unspecified uns= pecified unspecified unspecified unspecified unspecified unspecified unspe= cified unspecified] minibuffer-insert-face [face unspecified unspecified unspecified unspecifi= ed unspecified unspecified unspecified unspecified unspecified unspecified= unspecified unspecified unspecified unspecified unspecified unspecified u= nspecified unspecified] minibuffer-emacs-face [face unspecified unspecified unspecified unspecifie= d unspecified unspecified unspecified unspecified unspecified unspecified = unspecified unspecified unspecified unspecified unspecified unspecified un= specified unspecified] ) --------------------------------------------------------------------- STATEMENT OF CONFIDENTIALITY =20 The information contained in this electronic message and any attachments t= o this message are intended for the exclusive use of the addressee(s) and = may contain confidential or privileged information. No representation is m= ade on its accuracy or completeness of the information contained in this e= lectronic message. Certain assumptions may have been made in the preparati= on of this material as at this date, and are subject to change without not= ice. If you are not the intended recipient, you are hereby notified that a= ny dissemination, distribution or copying of this e-mail and any attachmen= t(s) is strictly prohibited. Please reply to the sender at NextLabs Inc an= d destroy all copies of this message and any attachments from your system.= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E554241NXTEXCHnext_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

&= nbsp;

Congratulations! You may have unearthe= d a bug in Viper!

Please mail a concise= , accurate summary of the problem to the address above.

 

---------------= ----------------------------------------------------

 

I don't have a rep= roducible 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 doe= sn't

seem to matter). I have to M-x vip= er-mode manually.

 

=

Up until this point I've focused on set-viper-state-i= n-major-mode. It

looks like viper-curre= nt-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 o= nly set

when in viper-mode), but I can'= t figure out how it's happening.

&= nbsp;

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 2= 015-04-05 on KAEL

Package: Viper versio= n is 3.14.2 of July 4, 2013

 =

current state:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

(setq

viper-vi-minibuffer-mi= nor-mode nil

viper-insert-minibuffer-m= inor-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

vip= er-insert-intercept-minor-mode nil

vip= er-insert-local-user-minor-mode nil

vi= per-insert-kbd-minor-mode nil

viper-in= sert-global-user-minor-mode nil

viper-= insert-state-modifier-minor-mode nil

v= iper-insert-diehard-minor-mode nil

vip= er-insert-basic-minor-mode nil

viper-e= macs-intercept-minor-mode nil

viper-em= acs-local-user-minor-mode nil

viper-em= acs-kbd-minor-mode nil

viper-emacs-glo= bal-user-minor-mode nil

viper-emacs-st= ate-modifier-minor-mode nil

viper-auto= matic-iso-accents nil

viper-special-in= put-method nil

viper-want-emacs-keys-i= n-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 ni= l

viper-vi-style-in-minibuffer t<= /o:p>

viper-vi-state-hook 'viper-restore-cursor-t= ype

viper-insert-state-hook 'viper-set= -insert-cursor-type

viper-replace-stat= e-hook 'viper-restore-cursor-type

vipe= r-emacs-state-hook 'viper-restore-cursor-type

ex-cycle-other-window t

ex-cyc= le-through-non-files nil

viper-expert-= level 2

major-mode 'emacs-lisp-mode

viper-device-type 'w32

color-display-p t

f= rame-parameters '((tool-bar-position . top) (parent-id) (explicit-name) (d= isplay . "w32")

  &= nbsp;           &nb= sp;     (visibility . t) (icon-name) (window-id . &quo= t;132178") (top + -8) (left + -8)

=             &n= bsp;       (buried-buffer-list #<buffer *= Completions*> #<buffer  *viper-ask-level*>)

         &= nbsp;          (buffer-list #= <buffer viper.el> #<buffer  *Minibuf-1*> #<buffer buil= dRelease>

    &n= bsp;           &nbs= p;    #<buffer build_publish.xml> #<buffer *Buffer= List*> #<buffer viper.notes.txt>

           &nbs= p;         #<buffer *Messages*&= gt; #<buffer *grep*> #<buffer configure<main>> #<buff= er main>

    &nb= sp;            = ;    #<buffer build_policies.pl> #<buffer PSRTestP= olicies.xml> #<buffer Engine.java>

           &nb= sp;         #<buffer *GNU Emacs= *> #<buffer *scratch*>)

 =              &= nbsp;     (unsplittable) (minibuffer . #<windo= w 4 on  *Minibuf-0*>) (modeline . t)

           &n= bsp;        (width . 211) (height . 52)= (name . "emacs@MANN")

 =             &n= bsp;      (viper-vi-state-cursor-color . "do= dgerblue")

    = ;            &= nbsp;   (viper-saved-cursor-color-in-replace-mode . "dodger= blue") (environment)

  &= nbsp;           &nb= sp;     (cursor-color . "dodgerblue") (backg= round-mode . dark) (display-type . color)

            = ;        (horizontal-scroll-bars . t) (= window-system . w32) (scroll-bar-width . 0)

            &n= bsp;       (cursor-type . box) (auto-lo= wer) (auto-raise) (icon-type) (fullscreen . maximized)

         &nbs= p;          (title) (buffer-p= redicate) (tool-bar-lines . 0) (menu-bar-lines . 1) (alpha)

=

         = ;           (right-fring= e . 9) (left-fringe . 9) (line-spacing) (screen-gamma)

         &nbs= p;          (border-color . &= quot;black") (mouse-color . "green")

          &= nbsp;         (background-color . = "darkslategrey") (foreground-color . "white")

        = ;            (verti= cal-scroll-bars) (bottom-divider-width . 0) (right-divider-width . 0)=

       &= nbsp;            (i= nternal-border-width . 0) (border-width . 2)

           &n= bsp;        (font . "-outline-Cons= olas-normal-normal-normal-mono-16-*-*-*-c-*-iso8859-1")

        &nbs= p;           (font-backe= nd uniscribe gdi))

minibuffer-vi-face = [face unspecified unspecified unspecified unspecified unspecified unspecif= ied unspecified unspecified unspecified unspecified unspecified unspecifie= d unspecified unspecified unspecified unspecified unspecified unspecified]=

minibuffer-insert-face [face unspecif= ied unspecified unspecified unspecified unspecified unspecified unspecifie= d unspecified unspecified unspecified unspecified unspecified unspecified = unspecified unspecified unspecified unspecified unspecified]

minibuffer-emacs-face [face unspecified unspecified= unspecified unspecified unspecified unspecified unspecified unspecified u= nspecified unspecified unspecified unspecified unspecified unspecified uns= pecified unspecified unspecified unspecified]

)


---------------------------------------------------------------------
= STATEMENT OF CONFIDENTIALITY

The information contained in this electronic message and any attachments t= o this message are intended for the exclusive use of the addressee(s) and = may contain confidential or privileged information. No representation is m= ade on its accuracy or completeness of the information contained in this e= lectronic message. Certain assumptions may have been made in the preparati= on of this material as at this date, and are subject to change without not= ice. If you are not the intended recipient, you are hereby notified that a= ny dissemination, distribution or copying of this e-mail and any attachmen= t(s) is strictly prohibited. Please reply to the sender at NextLabs Inc an= d destroy all copies of this message and any attachments from your system.= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--_000_0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E554241NXTEXCHnext_-- From debbugs-submit-bounces@debbugs.gnu.org Fri May 15 16:39:33 2015 Received: (at 20521) by debbugs.gnu.org; 15 May 2015 20:39:33 +0000 Received: from localhost ([127.0.0.1]:46514 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtMOI-0000Br-Vk for submit@debbugs.gnu.org; Fri, 15 May 2015 16:39:32 -0400 Received: from mail1.bemta12.messagelabs.com ([216.82.251.1]:44286) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtMOE-0000Bh-L3 for 20521@debbugs.gnu.org; Fri, 15 May 2015 16:39:28 -0400 Received: from [216.82.249.35] by server-1.bemta-12.messagelabs.com id AB/17-03033-D7956555; Fri, 15 May 2015 20:39:25 +0000 X-Env-Sender: Alan.Morgan@nextlabs.com X-Msg-Ref: server-14.tower-138.messagelabs.com!1431722364!5550250!1 X-Originating-IP: [50.206.94.99] X-StarScan-Received: X-StarScan-Version: 6.13.15; banners=nextlabs.com,-,- X-VirusChecked: Checked Received: (qmail 10291 invoked from network); 15 May 2015 20:39:25 -0000 Received: from 50-206-94-99-static.hfc.comcastbusiness.net (HELO mail.nextlabs.com) (50.206.94.99) by server-14.tower-138.messagelabs.com with AES128-SHA encrypted SMTP; 15 May 2015 20:39:25 -0000 Received: from NXT-EXCH.nextlabs.com ([169.254.1.117]) by nxt-exchfe02.nextlabs.com ([fe80::7c5d:a47f:a7a8:9685%13]) with mapi; Fri, 15 May 2015 13:39:14 -0700 From: Alan Morgan To: "20521@debbugs.gnu.org" <20521@debbugs.gnu.org> Date: Fri, 15 May 2015 13:39:13 -0700 Subject: Bug 2051 Thread-Topic: Bug 2051 Thread-Index: AdCPTbmkgFdw/Xx6QAiIAuERbjqf/Q== Message-ID: <0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E55476B@NXT-EXCH.nextlabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E55476BNXTEXCHnext_" MIME-Version: 1.0 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 20521 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --_000_0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E55476BNXTEXCHnext_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have more information on this bug, although I still don't have a reprodu= cible case. The problem happens when the *global* value of viper-current-s= tate 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 a= nything 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 inpu= t off (viper-special-input-method (viper-set-input-method t)) ;i= ntl input on (t (viper-set-input-method nil))) (message (concat "Setting viper-current-state from " (prin1-to-string vi= per-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 bu= ffer 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 unco= vered this, I'm not sure what I can do to fix it. Alan --------------------------------------------------------------------- STATEMENT OF CONFIDENTIALITY =20 The information contained in this electronic message and any attachments t= o this message are intended for the exclusive use of the addressee(s) and = may contain confidential or privileged information. No representation is m= ade on its accuracy or completeness of the information contained in this e= lectronic message. Certain assumptions may have been made in the preparati= on of this material as at this date, and are subject to change without not= ice. If you are not the intended recipient, you are hereby notified that a= ny dissemination, distribution or copying of this e-mail and any attachmen= t(s) is strictly prohibited. Please reply to the sender at NextLabs Inc an= d destroy all copies of this message and any attachments from your system.= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E55476BNXTEXCHnext_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have= more information on this bug, although I still don’t have a reprodu= cible case. The problem happens when the *global* value of viper-cu= rrent-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-bindin= gs so anything other than cursor movement keys and a few others will do no= thing. 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-s= et-input-method nil)) ;intl input off

&= nbsp;           &nb= sp;   (viper-special-input-method (viper-set-input-method t)) ;i= ntl input on

    &n= bsp;           (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-v= iper-current-state ()

  (message (= concat "The global value of viper-current-state is " (prin1-to-s= tring (default-value 'viper-current-state)))))

 

Most of the time I see t= he following:

 

Setting viper-current-state from emacs-state to insert-st= ate via setq

The global value of viper-= current-state is emacs-state [2 times]

=  

But then, for no reason that I c= ould see, I saw this:

Setting viper-cur= rent-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-st= ate

 

How on Earth? Perhaps setq is broken. Perhaps we aren’t actua= lly *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 possib= le 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 t= o this message are intended for the exclusive use of the addressee(s) and = may contain confidential or privileged information. No representation is m= ade on its accuracy or completeness of the information contained in this e= lectronic message. Certain assumptions may have been made in the preparati= on of this material as at this date, and are subject to change without not= ice. If you are not the intended recipient, you are hereby notified that a= ny dissemination, distribution or copying of this e-mail and any attachmen= t(s) is strictly prohibited. Please reply to the sender at NextLabs Inc an= d destroy all copies of this message and any attachments from your system.= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--_000_0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E55476BNXTEXCHnext_-- From debbugs-submit-bounces@debbugs.gnu.org Fri May 15 17:08:31 2015 Received: (at 20521) by debbugs.gnu.org; 15 May 2015 21:08:31 +0000 Received: from localhost ([127.0.0.1]:46518 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtMqN-0000uu-4Y for submit@debbugs.gnu.org; Fri, 15 May 2015 17:08:31 -0400 Received: from mail-qk0-f170.google.com ([209.85.220.170]:33380) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtMqK-0000ue-MN for 20521@debbugs.gnu.org; Fri, 15 May 2015 17:08:29 -0400 Received: by qkgv12 with SMTP id v12so4187593qkg.0 for <20521@debbugs.gnu.org>; Fri, 15 May 2015 14:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:to:cc:subject:in-reply-to:date:message-id :mime-version:content-type; bh=IDOjqKx1RR6gASTF0Edco/HWZ6hMWPQ8AUvGN1b8vSo=; b=Y8iD3NkJLAQdA7WXhS69ptGGcu5sOPw/XhEN7qenYyvX/4+hsRj/NLqDAId7/yTT9J KiNX47FPCW8cWyfAXSHe0rZTUJ9PgCiy4JBzFllzJrgUSwtjDspRRWFv8lhvfSHueqVH bDYIRHaNiGfrGLCeMekb+N3eoxdW6p4E9JB86xZ03Oni90+2A15B5O6zgUIJIASCSSqh oPe6xjdAe4N6vzJ/taNnFymuCVJjMw4DmDBwD9VdvMLqUpSPEl2oTIWaMHu6wXZDtylN cAKi0JwQyyxLT0Uw0RSws0ri88fIowxlptccYUiupS3A0Oh5CctVk+LTehCG3WDRR4tH eXEw== X-Received: by 10.140.33.227 with SMTP id j90mr14860044qgj.6.1431724103313; Fri, 15 May 2015 14:08:23 -0700 (PDT) Received: from NAND-LT ([47.19.134.82]) by mx.google.com with ESMTPSA id 187sm1795339qhc.39.2015.05.15.14.08.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 May 2015 14:08:22 -0700 (PDT) References: <0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E554241@NXT-EXCH.nextlabs.com> <0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E55476B@NXT-EXCH.nextlabs.com> From: Nick Andryshak To: Alan Morgan Subject: Re: bug#20521: Bug 2051 In-reply-to: <0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E55476B@NXT-EXCH.nextlabs.com> Date: Fri, 15 May 2015 17:08:22 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20521 Cc: "20521@debbugs.gnu.org" <20521@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > 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 From debbugs-submit-bounces@debbugs.gnu.org Fri May 15 17:42:32 2015 Received: (at 20521) by debbugs.gnu.org; 15 May 2015 21:42:32 +0000 Received: from localhost ([127.0.0.1]:46533 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtNNH-0001mu-UR for submit@debbugs.gnu.org; Fri, 15 May 2015 17:42:32 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:26478) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtNNG-0001mc-2k for 20521@debbugs.gnu.org; Fri, 15 May 2015 17:42:30 -0400 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t4FLgNj2010588 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 May 2015 21:42:24 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t4FLgNQK007539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 15 May 2015 21:42:23 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t4FLgNxj012991; Fri, 15 May 2015 21:42:23 GMT MIME-Version: 1.0 Message-ID: <19f6a4a4-81d6-499f-9f90-d41a1dda9c4c@default> Date: Fri, 15 May 2015 14:42:22 -0700 (PDT) From: Drew Adams To: Nick Andryshak , Alan Morgan Subject: RE: bug#20521: Bug 2051 References: <0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E554241@NXT-EXCH.nextlabs.com> <0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E55476B@NXT-EXCH.nextlabs.com> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0022.oracle.com [156.151.31.74] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 20521 Cc: 20521@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > 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. From debbugs-submit-bounces@debbugs.gnu.org Fri May 15 17:51:33 2015 Received: (at 20521) by debbugs.gnu.org; 15 May 2015 21:51:33 +0000 Received: from localhost ([127.0.0.1]:46541 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtNW0-000222-SP for submit@debbugs.gnu.org; Fri, 15 May 2015 17:51:33 -0400 Received: from mail1.bemta8.messagelabs.com ([216.82.243.209]:57691) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtNVy-00021r-0c for 20521@debbugs.gnu.org; Fri, 15 May 2015 17:51:31 -0400 Received: from [216.82.242.19] by server-17.bemta-8.messagelabs.com id 2B/39-02796-16A66555; Fri, 15 May 2015 21:51:29 +0000 X-Env-Sender: Alan.Morgan@nextlabs.com X-Msg-Ref: server-4.tower-191.messagelabs.com!1431726688!10909755!1 X-Originating-IP: [50.206.94.99] X-StarScan-Received: X-StarScan-Version: 6.13.15; banners=nextlabs.com,-,- X-VirusChecked: Checked Received: (qmail 1242 invoked from network); 15 May 2015 21:51:28 -0000 Received: from 50-206-94-99-static.hfc.comcastbusiness.net (HELO mail.nextlabs.com) (50.206.94.99) by server-4.tower-191.messagelabs.com with AES128-SHA encrypted SMTP; 15 May 2015 21:51:28 -0000 Received: from NXT-EXCH.nextlabs.com ([169.254.1.117]) by nxt-exchfe01.nextlabs.com ([10.187.2.93]) with mapi; Fri, 15 May 2015 14:51:27 -0700 From: Alan Morgan To: Nick Andryshak Date: Fri, 15 May 2015 14:51:25 -0700 Subject: RE: bug#20521: Bug 2051 Thread-Topic: bug#20521: Bug 2051 Thread-Index: AdCPU1JrkQH1FFQUSWSVmb3hMUs0UAABbDNw Message-ID: <0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E554776@NXT-EXCH.nextlabs.com> References: <0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E554241@NXT-EXCH.nextlabs.com> <0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E55476B@NXT-EXCH.nextlabs.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 20521 Cc: "20521@debbugs.gnu.org" <20521@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) I shouldn't have used the term "global". I meant "default". If the variabl= e is buffer-local then setq should set the buffer-local value and *not* th= e default value. In this situation is looks like setq is *sometimes* setting the default va= lue 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@gmail.com]=20 Sent: Friday, May 15, 2015 2:08 PM To: Alan Morgan Cc: 20521@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!=20 > 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=20= > how this is possible and, now that I've uncovered this, I'm not sure=20 > 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 =20 The information contained in this electronic message and any attachments t= o this message are intended for the exclusive use of the addressee(s) and = may contain confidential or privileged information. No representation is m= ade on its accuracy or completeness of the information contained in this e= lectronic message. Certain assumptions may have been made in the preparati= on of this material as at this date, and are subject to change without not= ice. If you are not the intended recipient, you are hereby notified that a= ny dissemination, distribution or copying of this e-mail and any attachmen= t(s) is strictly prohibited. Please reply to the sender=20at NextLabs Inc = and destroy all copies of this message and any attachments from your syste= m. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From debbugs-submit-bounces@debbugs.gnu.org Fri May 15 19:24:46 2015 Received: (at 20521) by debbugs.gnu.org; 15 May 2015 23:24:47 +0000 Received: from localhost ([127.0.0.1]:46566 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtOyE-0004Pw-C9 for submit@debbugs.gnu.org; Fri, 15 May 2015 19:24:46 -0400 Received: from mail-ob0-f176.google.com ([209.85.214.176]:35889) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtOyC-0004Pj-HY for 20521@debbugs.gnu.org; Fri, 15 May 2015 19:24:45 -0400 Received: by obbkp3 with SMTP id kp3so88848729obb.3 for <20521@debbugs.gnu.org>; Fri, 15 May 2015 16:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hG9qDKkkvtR1TMkot8aUoidADKWWSDFdDDg2xFZpWBU=; b=Jcf/bh3QZch95W3U7yobcRCMjYhbkL4X+T80lNEYB0PtFtelVJiuPLkJEP6nmeQ9Em XQ7BnWAXiwuwpax0pkNz9MYusIDQ71OWWkBx6e+RRfGVKTWvsMFp+9u9BOOmY6V0Dl99 f5iVO5zfyb9M5PW04akKLatRPCgxW6AXa6nnbK/0f6hXt23bfjsfG8eMTBK8ZKXjNVuk w+hDrIjKvGAqbEcUJFtFycMFmozSVfLY5wVks6b0mHt9uCF8yqEZS2uEe8etkXups7Hj +A/q5SMpN/6io/Td2CzVcqTjZw4yybNSz1o0Jd7KXRHaSO1NPU63Nnm6GgNw+7XiUzic K1cw== MIME-Version: 1.0 X-Received: by 10.202.69.130 with SMTP id s124mr9837311oia.70.1431732279049; Fri, 15 May 2015 16:24:39 -0700 (PDT) Received: by 10.202.0.12 with HTTP; Fri, 15 May 2015 16:24:38 -0700 (PDT) In-Reply-To: <19f6a4a4-81d6-499f-9f90-d41a1dda9c4c@default> References: <0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E554241@NXT-EXCH.nextlabs.com> <0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E55476B@NXT-EXCH.nextlabs.com> <19f6a4a4-81d6-499f-9f90-d41a1dda9c4c@default> Date: Fri, 15 May 2015 19:24:38 -0400 Message-ID: Subject: Re: bug#20521: Bug 2051 From: Nick Andryshak To: Drew Adams Content-Type: multipart/alternative; boundary=001a113ddd2ee8039105162725e0 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20521 Cc: Alan Morgan , 20521@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a113ddd2ee8039105162725e0 Content-Type: text/plain; charset=UTF-8 Interesting, thanks. I suppose I misunderstand the manual page that I linked. - Nick On Fri, May 15, 2015 at 5:42 PM, Drew Adams 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. > --001a113ddd2ee8039105162725e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Interesting, thanks. I suppose I misunderstand the manual = page that I linked.

- Nick

On Fri, May 15, 2015 at 5:42 PM, Dr= ew Adams <drew.adams@oracle.com> wrote:
> I think you may misunderstand: setq= always sets a global variable.

Since when?

=C2=A0 -- Macro: setq-local variable value
=C2=A0 =C2=A0 =C2=A0This macro creates a buffer-local binding in the curren= t buffer for
=C2=A0 =C2=A0 =C2=A0VARIABLE, and gives it the buffer-local value VALUE.=C2= =A0 It is
=C2=A0 =C2=A0 =C2=A0equivalent to calling `make-local-variable' followe= d by `setq'.
=C2=A0 =C2=A0 =C2=A0VARIABLE should be an unquoted symbol.

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

--001a113ddd2ee8039105162725e0-- From debbugs-submit-bounces@debbugs.gnu.org Wed May 27 12:50:38 2015 Received: (at 20521) by debbugs.gnu.org; 27 May 2015 16:50:38 +0000 Received: from localhost ([127.0.0.1]:58566 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YxeXM-0004h9-BY for submit@debbugs.gnu.org; Wed, 27 May 2015 12:50:38 -0400 Received: from mail1.bemta7.messagelabs.com ([216.82.254.108]:54086) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YxeXH-0004gz-Qi for 20521@debbugs.gnu.org; Wed, 27 May 2015 12:50:33 -0400 Received: from [216.82.254.51] by server-12.bemta-7.messagelabs.com id 6B/D9-16335-6D5F5655; Wed, 27 May 2015 16:50:30 +0000 X-Env-Sender: Alan.Morgan@nextlabs.com X-Msg-Ref: server-11.tower-144.messagelabs.com!1432745429!11386579!1 X-Originating-IP: [173.167.112.114] X-StarScan-Received: X-StarScan-Version: 6.13.15; banners=nextlabs.com,-,- X-VirusChecked: Checked Received: (qmail 12995 invoked from network); 27 May 2015 16:50:30 -0000 Received: from customer.nextlabs.com (HELO mail.nextlabs.com) (173.167.112.114) by server-11.tower-144.messagelabs.com with AES128-SHA encrypted SMTP; 27 May 2015 16:50:30 -0000 Received: from NXT-EXCH.nextlabs.com ([169.254.1.23]) by nxt-exchfe01.nextlabs.com ([10.187.2.93]) with mapi; Wed, 27 May 2015 09:50:29 -0700 From: Alan Morgan To: "20521@debbugs.gnu.org" <20521@debbugs.gnu.org> Date: Wed, 27 May 2015 09:50:28 -0700 Subject: setq-local definitely behaving oddly for viper mode Thread-Topic: setq-local definitely behaving oddly for viper mode Thread-Index: AdCYnJSNkridmpkoTNCdSpagcYUBAA== Message-ID: <0DBA2ACE64E8894F80DEC59F1EB9BE2304A3028A56A1@NXT-EXCH.nextlabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0DBA2ACE64E8894F80DEC59F1EB9BE2304A3028A56A1NXTEXCHnext_" MIME-Version: 1.0 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20521 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --_000_0DBA2ACE64E8894F80DEC59F1EB9BE2304A3028A56A1NXTEXCHnext_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 se= tting the default value of the variable and that really shouldn't be possi= ble. Either I'm nuts or this is an emacs bug. --------------------------------------------------------------------- STATEMENT OF CONFIDENTIALITY =20 The information contained in this electronic message and any attachments t= o this message are intended for the exclusive use of the addressee(s) and = may contain confidential or privileged information. No representation is=20= made on its accuracy or completeness of the information contained in this = electronic message. Certain assumptions may have been made in the preparat= ion of this material as at this date, and are subject to change without no= tice. If you are not the intended recipient, you are hereby notified that = any dissemination, distribution or copying of this e-mail and any attachme= nt(s) is strictly prohibited. Please reply to the sender at NextLabs Inc a= nd destroy all copies of this message and any attachments from your system= . =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_0DBA2ACE64E8894F80DEC59F1EB9BE2304A3028A56A1NXTEXCHnext_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 &= quot;Doomed going in"))

 (se= tq-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 set= ting 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 t= o this message are intended for the exclusive use of the addressee(s) and = may contain confidential or privileged information. No representation is m= ade on its accuracy or completeness of the information contained in this e= lectronic message. Certain assumptions may have been made in the preparati= on of this material as at this date, and are subject to change without not= ice. If you are not the intended recipient, you are hereby notified that a= ny dissemination, distribution or copying of this e-mail and any attachmen= t(s) is strictly prohibited. Please reply to the sender at NextLabs Inc an= d destroy all copies of this message and any attachments from your system.= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--_000_0DBA2ACE64E8894F80DEC59F1EB9BE2304A3028A56A1NXTEXCHnext_-- From debbugs-submit-bounces@debbugs.gnu.org Wed May 27 18:28:54 2015 Received: (at 20521) by debbugs.gnu.org; 27 May 2015 22:28:54 +0000 Received: from localhost ([127.0.0.1]:58707 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yxjoj-0004KU-Be for submit@debbugs.gnu.org; Wed, 27 May 2015 18:28:53 -0400 Received: from smtprelay-b32.telenor.se ([213.150.131.21]:36391) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yxjog-0004KC-0E for 20521@debbugs.gnu.org; Wed, 27 May 2015 18:28:51 -0400 Received: from ipb3.telenor.se (ipb3.telenor.se [195.54.127.166]) by smtprelay-b32.telenor.se (Postfix) with ESMTP id C2B3587F1A for <20521@debbugs.gnu.org>; Thu, 28 May 2015 00:28:43 +0200 (CEST) X-SMTPAUTH-B2: [bocjoh] X-SENDER-IP: [85.229.2.200] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DJBwBERGZVPMgC5VVcgxCBMoMfgy7CcQKBQk0BAQEBAQEHAQEBAUE/hCMBAQMBIzMjBQsLGgIFIQICDwEEGAEMChoTiCUMAa5xpBcBAQEHAQEBAR6BIYoZhFIzB4JogUUFtUaEHTwxgkcBAQE X-IPAS-Result: A2DJBwBERGZVPMgC5VVcgxCBMoMfgy7CcQKBQk0BAQEBAQEHAQEBAUE/hCMBAQMBIzMjBQsLGgIFIQICDwEEGAEMChoTiCUMAa5xpBcBAQEHAQEBAR6BIYoZhFIzB4JogUUFtUaEHTwxgkcBAQE X-IronPort-AV: E=Sophos;i="5.13,507,1427752800"; d="scan'208";a="886782056" Received: from c-c802e555.04-211-6c6b701.cust.bredbandsbolaget.se (HELO muon.localdomain) ([85.229.2.200]) by ipb3.telenor.se with ESMTP; 28 May 2015 00:28:42 +0200 Received: by muon.localdomain (Postfix, from userid 1000) id BED5948421A; Thu, 28 May 2015 00:28:41 +0200 (CEST) From: =?utf-8?Q?Johan_Bockg=C3=A5rd?= To: Alan Morgan Subject: Re: bug#20521: setq-local definitely behaving oddly for viper mode References: <0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E554241@NXT-EXCH.nextlabs.com> <0DBA2ACE64E8894F80DEC59F1EB9BE2304A3028A56A1@NXT-EXCH.nextlabs.com> Mail-Copies-To: never Date: Thu, 28 May 2015 00:28:40 +0200 In-Reply-To: <0DBA2ACE64E8894F80DEC59F1EB9BE2304A3028A56A1@NXT-EXCH.nextlabs.com> (Alan Morgan's message of "Wed, 27 May 2015 09:50:28 -0700") Message-ID: <87zj4pirjb.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20521 Cc: "20521@debbugs.gnu.org" <20521@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) Alan Morgan 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 =E2=80=98make-local-variable=E2=80= =99, 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 =E2=80=98let=E2=80=99 or other binding constructs) does not crea= te a buffer-local binding for it. Only setting the variable (with =E2=80= =98set=E2=80=99 or =E2=80=98setq=E2=80=99), while the variable does not have a =E2=80= =98let=E2=80=99-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)))) =3D> (nil . 1) From debbugs-submit-bounces@debbugs.gnu.org Wed May 27 22:02:42 2015 Received: (at 20521) by debbugs.gnu.org; 28 May 2015 02:02:42 +0000 Received: from localhost ([127.0.0.1]:58764 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yxn9d-0002LJ-Ls for submit@debbugs.gnu.org; Wed, 27 May 2015 22:02:41 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:41173) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yxn9c-0002L4-CY for 20521@debbugs.gnu.org; Wed, 27 May 2015 22:02:40 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AxFgA731xV/9N+3mhcgxCEAoVVu0CHSwQCAoE8OhMBAQEBAQEBgQpBBYNdAQEEViMQCzQSFBgNJIg/zyMBAQEBBgEBAQEeizqFBQeELQEEtQQjhBQigngBAQE X-IPAS-Result: A0AxFgA731xV/9N+3mhcgxCEAoVVu0CHSwQCAoE8OhMBAQEBAQEBgQpBBYNdAQEEViMQCzQSFBgNJIg/zyMBAQEBBgEBAQEeizqFBQeELQEEtQQjhBQigngBAQE X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="122515209" Received: from 104-222-126-211.cpe.teksavvy.com (HELO fmsmemgm.homelinux.net) ([104.222.126.211]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 May 2015 22:02:34 -0400 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 9903CAE0BD; Wed, 27 May 2015 22:02:34 -0400 (EDT) From: Stefan Monnier To: Alan Morgan Subject: Re: bug#20521: setq-local definitely behaving oddly for viper mode Message-ID: References: <0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E554241@NXT-EXCH.nextlabs.com> <0DBA2ACE64E8894F80DEC59F1EB9BE2304A3028A56A1@NXT-EXCH.nextlabs.com> <87zj4pirjb.fsf@gnu.org> Date: Wed, 27 May 2015 22:02:34 -0400 In-Reply-To: <87zj4pirjb.fsf@gnu.org> ("Johan =?windows-1252?Q?Bockg=E5rd?= =?windows-1252?Q?=22's?= message of "Thu, 28 May 2015 00:28:40 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 20521 Cc: "20521@debbugs.gnu.org" <20521@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > (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 From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 29 00:52:50 2016 Received: (at control) by debbugs.gnu.org; 29 Feb 2016 05:52:50 +0000 Received: from localhost ([127.0.0.1]:51644 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aaGlG-0008NK-47 for submit@debbugs.gnu.org; Mon, 29 Feb 2016 00:52:50 -0500 Received: from hermes.netfonds.no ([80.91.224.195]:39538) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aaGlE-0008NC-O3 for control@debbugs.gnu.org; Mon, 29 Feb 2016 00:52:49 -0500 Received: from cpe-60-225-211-161.nsw.bigpond.net.au ([60.225.211.161] helo=mouse) by hermes.netfonds.no with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1aaGks-0003iX-MU for control@debbugs.gnu.org; Mon, 29 Feb 2016 06:52:27 +0100 Date: Mon, 29 Feb 2016 16:52:21 +1100 Message-Id: <871t7wrrl6.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #20521 X-MailScanner-ID: 1aaGks-0003iX-MU X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1457329947.58563@mOR1wnPaGUgRCnzEVOS4wg X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) tags 20521 - moreinfo From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 10 03:12:10 2022 Received: (at 20521) by debbugs.gnu.org; 10 Feb 2022 08:12:10 +0000 Received: from localhost ([127.0.0.1]:53744 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nI4Yk-0007gG-3k for submit@debbugs.gnu.org; Thu, 10 Feb 2022 03:12:10 -0500 Received: from quimby.gnus.org ([95.216.78.240]:45458) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nI4Yi-0007fy-0b for 20521@debbugs.gnu.org; Thu, 10 Feb 2022 03:12:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :In-Reply-To:Date:References:Subject:To:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=w4Jid7Jy1zU8NK5i8S5ZWJDgp+L/FJjbLooq370XKd0=; b=g/3hiLqCdvT2EGNMSC0QIeHtq8 jbR92TSdHnf4RKVY5dwSi+aE/ItfMDKYeIYqDtjX2DvoddoQp3j/iUtdsEMjh35WqWXdl2uLApZqm vSAVqtJg6m40F68snwNoZq1XbS9txyh7Ttjr1uavzVrBIVDx/v7jbe2s9Y4TrRhLsh9w=; Received: from [84.212.220.105] (helo=giant) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nI4YZ-0004MC-BW; Thu, 10 Feb 2022 09:12:01 +0100 From: Lars Ingebrigtsen To: Alan Morgan , "20521@debbugs.gnu.org" <20521@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 References: <0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E554241@NXT-EXCH.nextlabs.com> <0DBA2ACE64E8894F80DEC59F1EB9BE2304A3028A56A1@NXT-EXCH.nextlabs.com> <87zj4pirjb.fsf@gnu.org> X-Now-Playing: Contriva's _If you had stayed..._: "never shown again" Date: Thu, 10 Feb 2022 09:11:57 +0100 In-Reply-To: <87zj4pirjb.fsf@gnu.org> ("Johan =?utf-8?Q?Bockg=C3=A5rd=22's?= message of "Thu, 28 May 2015 00:28:40 +0200") Message-ID: <87h797b0oi.fsf_-_@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Johan Bockgård 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) > [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 20521 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Johan Bockg=C3=A5rd 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)))) > =3D> (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. --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 10 03:12:18 2022 Received: (at control) by debbugs.gnu.org; 10 Feb 2022 08:12:18 +0000 Received: from localhost ([127.0.0.1]:53747 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nI4Ys-0007gi-Cl for submit@debbugs.gnu.org; Thu, 10 Feb 2022 03:12:18 -0500 Received: from quimby.gnus.org ([95.216.78.240]:45474) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nI4Yq-0007gO-P0 for control@debbugs.gnu.org; Thu, 10 Feb 2022 03:12:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=q7sjMtjAs717Z6pMBtY7NTpzto9bjJFu0GUnmCb8Cbs=; b=B1ThV5Ujlt+z720Uj5W3TekeCt pw7uoUn+4w4hluF5PjGlJOKOlF6POXiQKhj/h92+g26zKJBESNChdA9d5qXu/e4XLcjyADDquc2cj DS1V6HcUVNOnigzemIgVnOyd5Tl8TcXpv2Snny5uvKjt5xrcrGLRYsbKIIYguvq+/4Ow=; Received: from [84.212.220.105] (helo=giant) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nI4Yi-0004MQ-8X for control@debbugs.gnu.org; Thu, 10 Feb 2022 09:12:10 +0100 Date: Thu, 10 Feb 2022 09:12:05 +0100 Message-Id: <87fsorb0oa.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #20521 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 20521 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 20521 quit From unknown Sun Jun 22 00:54:46 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 10 Mar 2022 12:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator