From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Richard M. Stallman" Newsgroups: gmane.emacs.devel Subject: Re: Specifying mode in file variables trouble Date: Fri, 26 Sep 2008 00:45:40 -0400 Message-ID: References: <48D44761.6000809@gmail.com> <87ljxny6n8.fsf@catnip.gol.com> <48D44C79.9020004@gmail.com> <48D63F30.8060102@gmail.com> <48D6E8FB.4070108@gmail.com> <48D79A25.7050000@gmail.com> <48D8BD92.5080403@gmail.com> <48D925EA.3030703@gmail.com> <48D95601.8010703@gmail.com> <48D95FE7.7040807@gmail.com> <48DAB149.9060408@gmail.com> <48DC03FA.7010509@gmail.com> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1222404607 21441 80.91.229.12 (26 Sep 2008 04:50:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Sep 2008 04:50:07 +0000 (UTC) Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: "Lennart Borgman (gmail)" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 26 06:51:04 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 1Kj5IF-0006sk-7z for ged-emacs-devel@m.gmane.org; Fri, 26 Sep 2008 06:51:03 +0200 Original-Received: from localhost ([127.0.0.1]:59341 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kj5HD-0004l1-3F for ged-emacs-devel@m.gmane.org; Fri, 26 Sep 2008 00:49:59 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kj5F6-0003em-Oj for emacs-devel@gnu.org; Fri, 26 Sep 2008 00:47:48 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kj5F6-0003eH-9U for emacs-devel@gnu.org; Fri, 26 Sep 2008 00:47:48 -0400 Original-Received: from [199.232.76.173] (port=39210 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kj5F5-0003e8-U3 for emacs-devel@gnu.org; Fri, 26 Sep 2008 00:47:48 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:40218) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kj5F5-0001fq-Ty for emacs-devel@gnu.org; Fri, 26 Sep 2008 00:47:48 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1Kj5D2-0004uq-3s; Fri, 26 Sep 2008 00:45:40 -0400 In-reply-to: <48DC03FA.7010509@gmail.com> (lennart.borgman@gmail.com) X-detected-operating-system: by monty-python.gnu.org: GNU/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:104169 Archived-At: > * If a variable is bound locally by one of the major modes used within > mumamo, or by the mode hooks it runs, then kill it when moving to a > chunk in another major mode. Do you mean the third case aboove here? Yes. I think this is a good idea. This is what I have implemented now in the latest sources (and that I sent here). Ok. > * Any other buffer-local variable should survive through motion between > chunks. I am not sure about this one, but I think it would be better to use the third case for these variables too (and that is what I do now) if not their 'permanent-buffer local property is non-nil. That is surely not right, because it means that almost all minor modes can get lost when moving between chunks. I think you should switch to what I proposed. > Can you find any use cases where this would not be right? Let say that the user for example want to use another indentation step for a specific chunk type. Then my comment above would perhaps apply. How would a user specify variable values for particular chunk types? Does mumamo have a facility for that? I think only a special mumamo facility could make this convenient. That facility would implement whatever chunk-switching behavior is most suitable. So it looks my simple proposal is adequate. I am a bit worried by this complexity for the users. One way to avoid it would perhaps to introduce the concept of a new "persistent level" between 'permanent-local=t and 'permanent-local=nil. A level that would be like 'permanent-local=t but just for the current buffer. That might be a good idea if we really need it. But my proposal is simpler: * If a variable is bound locally by one of the major modes used within mumamo, or by the mode hooks it runs, then kill it when moving to a chunk in another major mode. * Any other buffer-local variable should survive through motion between chunks. So unless we see a use case for which this isn't right, why not stick with it?