From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Johan =?UTF-8?Q?Bockg=C3=A5rd?= Newsgroups: gmane.emacs.bugs Subject: bug#20521: setq-local definitely behaving oddly for viper mode Date: Thu, 28 May 2015 00:28:40 +0200 Message-ID: <87zj4pirjb.fsf@gnu.org> References: <0DBA2ACE64E8894F80DEC59F1EB9BE23048E1E554241@NXT-EXCH.nextlabs.com> <0DBA2ACE64E8894F80DEC59F1EB9BE2304A3028A56A1@NXT-EXCH.nextlabs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1432765767 1454 80.91.229.3 (27 May 2015 22:29:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 May 2015 22:29:27 +0000 (UTC) Cc: "20521@debbugs.gnu.org" <20521@debbugs.gnu.org> To: Alan Morgan Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 28 00:29:11 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 1Yxjp0-000354-F0 for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 May 2015 00:29:10 +0200 Original-Received: from localhost ([::1]:55643 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yxjoz-0007QG-MO for geb-bug-gnu-emacs@m.gmane.org; Wed, 27 May 2015 18:29:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57555) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yxjow-0007QB-KK for bug-gnu-emacs@gnu.org; Wed, 27 May 2015 18:29:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yxjos-0007Y5-Db for bug-gnu-emacs@gnu.org; Wed, 27 May 2015 18:29:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:48732) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yxjos-0007Xy-B0 for bug-gnu-emacs@gnu.org; Wed, 27 May 2015 18:29:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Yxjos-0004Kq-0s for bug-gnu-emacs@gnu.org; Wed, 27 May 2015 18:29:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Johan =?UTF-8?Q?Bockg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 27 May 2015 22:29:01 +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.143276573416651 (code B ref 20521); Wed, 27 May 2015 22:29:01 +0000 Original-Received: (at 20521) by debbugs.gnu.org; 27 May 2015 22:28:54 +0000 Original-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 Original-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 Original-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" Original-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 Original-Received: by muon.localdomain (Postfix, from userid 1000) id BED5948421A; Thu, 28 May 2015 00:28:41 +0200 (CEST) Mail-Copies-To: never In-Reply-To: <0DBA2ACE64E8894F80DEC59F1EB9BE2304A3028A56A1@NXT-EXCH.nextlabs.com> (Alan Morgan's message of "Wed, 27 May 2015 09:50:28 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) 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:103239 Archived-At: 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)