From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Lennart Borgman (gmail)" Newsgroups: gmane.emacs.devel Subject: Re: Specifying mode in file variables trouble Date: Mon, 22 Sep 2008 15:14:13 +0200 Message-ID: <48D79A25.7050000@gmail.com> References: <48D44761.6000809@gmail.com> <87ljxny6n8.fsf@catnip.gol.com> <48D44C79.9020004@gmail.com> <48D63F30.8060102@gmail.com> <48D6E8FB.4070108@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1222089300 26773 80.91.229.12 (22 Sep 2008 13:15:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 22 Sep 2008 13:15:00 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 22 15:15:54 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 1KhlGL-0002fb-LX for ged-emacs-devel@m.gmane.org; Mon, 22 Sep 2008 15:15:38 +0200 Original-Received: from localhost ([127.0.0.1]:36691 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KhlFJ-00038u-9H for ged-emacs-devel@m.gmane.org; Mon, 22 Sep 2008 09:14:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KhlFB-00037A-Vg for emacs-devel@gnu.org; Mon, 22 Sep 2008 09:14:26 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KhlFA-00036K-8F for emacs-devel@gnu.org; Mon, 22 Sep 2008 09:14:25 -0400 Original-Received: from [199.232.76.173] (port=55437 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KhlF9-00036E-T3 for emacs-devel@gnu.org; Mon, 22 Sep 2008 09:14:23 -0400 Original-Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]:53252) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KhlF2-0005di-Rq; Mon, 22 Sep 2008 09:14:17 -0400 Original-Received: from c83-254-151-87.bredband.comhem.se ([83.254.151.87]:59715 helo=[127.0.0.1]) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1KhlF0-0006z7-9B; Mon, 22 Sep 2008 15:14:15 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 In-Reply-To: X-Enigmail-Version: 0.95.7 X-Antivirus: avast! (VPS 080921-0, 2008-09-21), Outbound message X-Antivirus-Status: Clean X-Originating-IP: 83.254.151.87 X-Scan-Result: No virus found in message 1KhlF0-0006z7-9B. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1KhlF0-0006z7-9B 1a1120f8da3ea2b55972a246a169ffad X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6? (barebone, rare!) 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:104032 Archived-At: Richard M. Stallman wrote: > Maybe, but I think most oftenly that will create name clashes. > > It will cause name clashes is you choose names of existing major modes, > but you can easily avoid using those. > > Here's what I suggest: > > If there is a customary name (say, `foo' for a kind of file which mixes > a few ordinary major modes, call the command `foo-mode'. > > Otherwise, if you want a command for the combination of two modes `a' > and `b', call it `a-b-mode'. > > Or we could use `a+b-mode' for such cases. I like the idea of using "+" here, that is a good mnemonic. For web template files (like PHP, JSP, Genshi etc) there are however often several major mode chunks involved. In for example a php file there may be chunks with these major modes - nxhtml-mode / html-mode - php-mode - css-mode - javascript-mode I currently use the name nxhtml-mumamo-mode (or html-mumamo-mode) for the multi major mode, which is of course not that very descriptive. The name begins with "nxhtml-" because that is the main major mode (there are only two levels allowed sofar, main major mode and sub chunks major modes). Along with your suggestion nxhtml+php-mode would be the most natural. This name does not tell the whole truth, but is perhaps still less cryptic than nxhtml-mumamo-mode. I am not quite sure. > (There are still good reasons to tell > that it is a multi major mode. The most difficult thing is support of > minor modes turn on/off and finding reasonable structures for that. Time > will tell I think.) > > Let's talk about this problem; maybe I can suggest a general solution > for it. There might be several problem, but the bug report I just recieved for Imenu illustrates one principal problem: https://bugs.launchpad.net/bugs/272526 I have not looked into the details, but the problem reports says that Imenu does not work as expected when moving between chunks (with different major modes). The principal problem here is probably that Imenu should work across all chunks with the same major modes and preserve its chunk specifric values when moving between those chunks. So I am thinking about saving those values in a variable, something like this (make-variable-buffer-local 'mumamo-survive-minor-modes) (put 'mumamo-survive-minor-modes 'permanent-local t) (defvar mumamo-survive-minor-modes nil "Hold local minor mode variables specific major modes. Those values are saved when leaving a chunk with a certain major mode and restored when entering a chunk with the same major mode again. The value of this variable is an associative list where the key is a list with \(MAJOR-MODE MINOR-MODE) and the value is a stored value for the minor mode.") For storing the values I am thinking about using the code that does something similar for visual-line-mode where state variable values are stored in visual-line--saved-state. However the drawback is that this has to be implemented for every minor mode of this kind, but I can't see any way around it currently. ... eh, maybe another way to do it could be to save all buffer local variables this way and make exceptions for some ...