From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel,gmane.emacs.pretest.bugs Subject: Re: 23.0.60; M-x compile gives args out of range 0, 0 Date: Tue, 08 Apr 2008 16:22:23 -0400 Message-ID: References: <47FB4E7D.3020504@swipnet.se> <20080408172227.GA3399@muc.de> <20080408192147.GB3399@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1207688443 19026 80.91.229.12 (8 Apr 2008 21:00:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Apr 2008 21:00:43 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org, Jan DjFFFFFFFFFFFFFFrv To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 08 23:01:15 2008 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 1JjKwJ-0002Sq-O9 for ged-emacs-devel@m.gmane.org; Tue, 08 Apr 2008 23:01:15 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JjKvc-0004oh-31 for ged-emacs-devel@m.gmane.org; Tue, 08 Apr 2008 17:00:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JjKKz-0004IA-SE for emacs-devel@gnu.org; Tue, 08 Apr 2008 16:22:37 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JjKKz-0004Hl-48 for emacs-devel@gnu.org; Tue, 08 Apr 2008 16:22:37 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JjKKy-0004Hf-QU for emacs-devel@gnu.org; Tue, 08 Apr 2008 16:22:36 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JjKKy-00044h-Dl for emacs-devel@gnu.org; Tue, 08 Apr 2008 16:22:36 -0400 Original-Received: from mail.gnu.org ([199.232.76.166] helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1JjKKx-0002LN-S1 for emacs-pretest-bug@gnu.org; Tue, 08 Apr 2008 16:22:35 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1JjKKu-00043f-AR for emacs-pretest-bug@gnu.org; Tue, 08 Apr 2008 16:22:35 -0400 Original-Received: from mercure.iro.umontreal.ca ([132.204.24.67]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JjKKt-00043S-UW for emacs-pretest-bug@gnu.org; Tue, 08 Apr 2008 16:22:32 -0400 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 6DD162CF787; Tue, 8 Apr 2008 16:22:31 -0400 (EDT) Original-Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 21EBE3FE0; Tue, 8 Apr 2008 16:22:24 -0400 (EDT) Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 0E12B3FC8A; Tue, 8 Apr 2008 16:22:24 -0400 (EDT) In-Reply-To: <20080408192147.GB3399@muc.de> (Alan Mackenzie's message of "Tue, 8 Apr 2008 19:21:47 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:94734 gmane.emacs.pretest.bugs:21947 Archived-At: >> I disagree. A major mode should basically *never* change globally >> a defvar, except maybe for its own vars (plus a few exceptions, of >> course). > Well, that's a bit philosophical. In practice, major mode maintainers > _will_ be setting such variables without explicitly localising them, > causing just that little bit extra in debugging, stress, curse words, > and so on. It's not philosophical. It's simply needed so as to avoid undesired interference between unrelated buffers. I know it's a common bug. > There's a category of variables which are _essentially_ buffer local, and > nobody ever explicitly localises them first - things like major-mode, > mark-ring, foo-minor-mode, buffer-undo-list, ..... It's hard to clearly define which ones are "essentially" buffer local and which ones aren't. > fl-e-ac-rf is in this category. In my mind, it's definitely not in the same category as `major-mode' or `buffer-undo-list'. But it doesn't matter anyway. > There are several other variables in font-lock.el which are explicity > buffer-localised, amongst them the similar variable > font-lock-extend-region-functions. So it would promote consistency if we > did the same with fl-extend-ac-region-function. As I said: >> I'm not opposed to make-variable-buffer-local, So feel free to apply your patch (except for the part that changes the docstring, since C-h v will take care of warning the user that the variable is automatically made buffer-local). >> but the bug was clearly in CC-mode, because a major mode should by >> default use (set (make-local-variable ...) ...) rather than setq. > I don't think it's clear at all. The same "bug", if such it be, exists > in font-lock.el itself, L1452: > (setq font-lock-syntactically-fontified end)) As I said "If you happen to know that the variable is "automatically buffer-local", it's OK to use `setq'". >> BTW, why doesn't CC-mode set those vars via font-lock-defaults, as the >> author of font-lock intended? > For portability's sake. font-lock-defaults in XEmacs has a different > format. In particular, it lacks the "other-vars" bit at the end. It's > less hassle just not to use it. Duh! Stefan