From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#9469: buffer-local variables seem to remember previous values Date: Sat, 10 Sep 2011 10:44:19 -0700 Message-ID: <70AD30BE45C847BE828A3E8A71280A8E@us.oracle.com> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1315676703 15933 80.91.229.12 (10 Sep 2011 17:45:03 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 10 Sep 2011 17:45:03 +0000 (UTC) To: "'Le Wang'" , <9469@debbugs.gnu.org> Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 10 19:44:58 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1R2Rbs-0007Pb-MC for geb-bug-gnu-emacs@m.gmane.org; Sat, 10 Sep 2011 19:44:56 +0200 Original-Received: from localhost ([::1]:52700 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R2Rbs-0006Fr-8a for geb-bug-gnu-emacs@m.gmane.org; Sat, 10 Sep 2011 13:44:56 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:33782) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R2Rbp-0006Fa-1P for bug-gnu-emacs@gnu.org; Sat, 10 Sep 2011 13:44:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R2Rbn-00073x-UL for bug-gnu-emacs@gnu.org; Sat, 10 Sep 2011 13:44:52 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:32835) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R2Rbn-00073t-Sf for bug-gnu-emacs@gnu.org; Sat, 10 Sep 2011 13:44:51 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1R2Rfq-0004in-Bu; Sat, 10 Sep 2011 13:49:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Sep 2011 17:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9469 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9469-submit@debbugs.gnu.org id=B9469.131567691918121 (code B ref 9469); Sat, 10 Sep 2011 17:49:02 +0000 Original-Received: (at 9469) by debbugs.gnu.org; 10 Sep 2011 17:48:39 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R2RfS-0004iD-Vr for submit@debbugs.gnu.org; Sat, 10 Sep 2011 13:48:39 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R2RfQ-0004i6-Uu for 9469@debbugs.gnu.org; Sat, 10 Sep 2011 13:48:37 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8AHiNU7019630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 10 Sep 2011 17:44:25 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8AHiMej007405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Sep 2011 17:44:22 GMT Original-Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8AHiGRa002713; Sat, 10 Sep 2011 12:44:16 -0500 Original-Received: from dradamslap1 (/10.159.63.205) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 10 Sep 2011 10:44:16 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acxv3DY3Ot3Q20JTTm2bIIorMPtRGwAAsQnA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4E6BA1F9.0052:SCFMA922111,ss=1,re=-4.000,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sat, 10 Sep 2011 13:49:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) 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:50784 Archived-At: > 1. emacs -Q > 2. eval this region: > (setq buf-a (create-file-buffer "a")) > (setq foo nil) > (make-variable-buffer-local 'foo) > (defun test1 () > (interactive) > (let (alist) > (push '(:var . 0) alist) > (with-current-buffer buf-a > (setq foo alist)))) > (defun test2 () > (interactive) > (with-current-buffer buf-a > (setcdr (assq :var foo) 20))) > (defun show () > (interactive) > (with-current-buffer buf-a > (format " ; foo in 'a' is %s" foo))) > (defun test3 () > (interactive) > (let (alist) > (push `(:var . ,(+ 0)) alist) > (with-current-buffer buf-a > (setq foo alist)))) > > (test1) > (test2) > (test1) > (insert (show)) > (test3) > (insert (show)) > > Note results on both `insert' lines should be identical but the first > insert some how remembers a previous value. I find it surprising that > no one has ever come across this before. No, they should not be identical. This is a classic Lisp gotcha. (test1) sets buffer-local var `foo' to a new alist ((:var . 0)). (test2) sets the cdr of the single element of that alist to 20. That means that `foo' in buf-a is now ((:var . 20)). (test1) then creates a new alist and pushes the _same_ cons, (:var . 20) onto it. And it sets `foo' to this new alist. If you were to use (cons :var 0) instead of '(:var . 0) then you would not be reusing the same cons cell. Note that different Lisps (and different implementations of the same Lisp) can treat a sexp such as '(a b) differently - they might or might not create a new list each time it is read or eval'd. To be sure to get what you expect in situations like this, do not use '(...). Use `cons' or `list' or equivalent backquote syntax. Do not expect '(...) to create new list structure each time it is read/eval'd.