From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Ami Fischman" Newsgroups: gmane.emacs.devel Subject: crazy interaction between buffer-locality and function-locality of variables Date: Sat, 1 Nov 2008 20:34:07 -0700 Message-ID: <9aa0cfde0811012034h30c79d6cxa66f6ee0754e027d@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_50824_26712734.1225596847311" X-Trace: ger.gmane.org 1225596870 26848 80.91.229.12 (2 Nov 2008 03:34:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Nov 2008 03:34:30 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 02 04:35:31 2008 connect(): Connection refused Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KwTkM-0008N2-S8 for ged-emacs-devel@m.gmane.org; Sun, 02 Nov 2008 04:35:27 +0100 Original-Received: from localhost ([127.0.0.1]:58838 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KwTjF-0004GN-Pl for ged-emacs-devel@m.gmane.org; Sat, 01 Nov 2008 23:34:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KwTjA-0004F9-97 for emacs-devel@gnu.org; Sat, 01 Nov 2008 23:34:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KwTj9-0004Er-7A for emacs-devel@gnu.org; Sat, 01 Nov 2008 23:34:11 -0400 Original-Received: from [199.232.76.173] (port=45829 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KwTj9-0004Eo-2n for emacs-devel@gnu.org; Sat, 01 Nov 2008 23:34:11 -0400 Original-Received: from wf-out-1314.google.com ([209.85.200.170]:46644) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KwTj8-0000pr-Ml for emacs-devel@gnu.org; Sat, 01 Nov 2008 23:34:11 -0400 Original-Received: by wf-out-1314.google.com with SMTP id 28so1993123wfc.24 for ; Sat, 01 Nov 2008 20:34:08 -0700 (PDT) Original-Received: by 10.142.224.5 with SMTP id w5mr6369809wfg.288.1225596847323; Sat, 01 Nov 2008 20:34:07 -0700 (PDT) Original-Received: by 10.143.11.8 with HTTP; Sat, 1 Nov 2008 20:34:07 -0700 (PDT) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:105256 Archived-At: ------=_Part_50824_26712734.1225596847311 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This snippet: (make-local-variable 'ami-wcb-bug-foo) (defun ami-wcb-bug (ami-wcb-bug-foo) (with-temp-buffer ami-wcb-bug-foo)) (ami-wcb-bug 'bar) eval'd in a *scratch* buffer results in this error: (void-variable ami-wcb-bug-foo) because ami-wcb-bug-foo is not bound in the temporary buffer, because the same name has been declared local in *scratch*, and the function-call binding happens in that buffer. A similar situation for let-binding is described in elisp.info's "11.10.1 Introduction to Buffer-Local Variables". This happens in 22.1.1 and in CVS HEAD. Is the behavior of binding function arguments variables subject to the locality of the current buffer at function call time intentional? It makes writing functions that respond to asynchronous events require using local variables with names that are globally unique (prefixed with package name, presumably), which is a PITA. An example of where this bit me: gnus makes 'timestamp buffer-local in *Summary* buffers, and emacs-jabber has a function that uses "timestamp" as the name of one of its arguments and then calls with-temp-buffer inside that function. So most of the time receiving jabber messages works just fine, but if the user happens to have point in a *Summary* buffer then message reciept triggers a void-variable error. It seems to me that this behavior is broken, but if it's to be kept there needs to be strong guidance against making variables whose names /aren't/ prefixed with the package name buffer-local. Cheers, -Ami ------=_Part_50824_26712734.1225596847311 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This snippet:

(make-local-variable 'ami-wcb-bug-foo)
(defun ami-wcb-bug (ami-wcb-bug-foo)
  (with-temp-buffer
    ami-wcb-bug-foo))
(ami-wcb-bug 'bar)

eval'd in a *scratch* buffer results in this error: (void-variable ami-wcb-bug-foo)
because ami-wcb-bug-foo is not bound in the temporary buffer, because the same name has been declared local in *scratch*, and the function-call binding happens in that buffer.  A similar situation for let-binding is described in elisp.info's "11.10.1 Introduction to Buffer-Local Variables".  This happens in 22.1.1 and in CVS HEAD.

Is the behavior of binding function arguments variables subject to the locality of the current buffer at function call time intentional?  It makes writing functions that respond to asynchronous events require using local variables with names that are globally unique (prefixed with package name, presumably), which is a PITA.  An example of where this bit me: gnus makes 'timestamp buffer-local in *Summary* buffers, and emacs-jabber has a function that uses "timestamp" as the name of one of its arguments and then calls with-temp-buffer inside that function.  So most of the time receiving jabber messages works just fine, but if the user happens to have point in a *Summary* buffer then message reciept triggers a void-variable error.

It seems to me that this behavior is broken, but if it's to be kept there needs to be strong guidance against making variables whose names /aren't/ prefixed with the package name buffer-local.

Cheers,
-Ami
------=_Part_50824_26712734.1225596847311--