From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Morgan Newsgroups: gmane.emacs.bugs Subject: bug#20521: Bug 2051 Date: Fri, 15 May 2015 13:39:13 -0700 Message-ID: <0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E55476B@NXT-EXCH.nextlabs.com> References: <0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E554241@NXT-EXCH.nextlabs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E55476BNXTEXCHnext_" X-Trace: ger.gmane.org 1431722434 10282 80.91.229.3 (15 May 2015 20:40:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 May 2015 20:40:34 +0000 (UTC) To: "20521@debbugs.gnu.org" <20521@debbugs.gnu.org> Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri May 15 22:40:17 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YtMP3-0007qw-3W for geb-bug-gnu-emacs@m.gmane.org; Fri, 15 May 2015 22:40:17 +0200 Original-Received: from localhost ([::1]:32968 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YtMP2-0000Br-IE for geb-bug-gnu-emacs@m.gmane.org; Fri, 15 May 2015 16:40:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54478) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YtMOv-0000As-9S for bug-gnu-emacs@gnu.org; Fri, 15 May 2015 16:40:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YtMOq-0005dz-8M for bug-gnu-emacs@gnu.org; Fri, 15 May 2015 16:40:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36539) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YtMOq-0005dl-5L for bug-gnu-emacs@gnu.org; Fri, 15 May 2015 16:40:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YtMOp-0000Cs-E9 for bug-gnu-emacs@gnu.org; Fri, 15 May 2015 16:40:03 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: <0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E554241@NXT-EXCH.nextlabs.com> Resent-From: Alan Morgan Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 May 2015 20:40:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20521 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 20521-submit@debbugs.gnu.org id=B20521.1431722373741 (code B ref 20521); Fri, 15 May 2015 20:40:03 +0000 Original-Received: (at 20521) by debbugs.gnu.org; 15 May 2015 20:39:33 +0000 Original-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 Original-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 Original-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 Original-Received: (qmail 10291 invoked from network); 15 May 2015 20:39:25 -0000 Original-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 Original-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 Thread-Topic: Bug 2051 Thread-Index: AdCPTbmkgFdw/Xx6QAiIAuERbjqf/Q== Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:102843 Archived-At: --_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_--