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: Tue, 23 Sep 2008 01:11:53 +0200 Message-ID: <48D82639.2040602@gmail.com> 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> 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 1222125140 21652 80.91.229.12 (22 Sep 2008 23:12:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 22 Sep 2008 23:12:20 +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 Tue Sep 23 01:13:16 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 1Khuah-0004Gi-F7 for ged-emacs-devel@m.gmane.org; Tue, 23 Sep 2008 01:13:15 +0200 Original-Received: from localhost ([127.0.0.1]:57426 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KhuZf-0008RJ-KJ for ged-emacs-devel@m.gmane.org; Mon, 22 Sep 2008 19:12:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KhuZZ-0008RE-Tl for emacs-devel@gnu.org; Mon, 22 Sep 2008 19:12:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KhuZY-0008R2-AI for emacs-devel@gnu.org; Mon, 22 Sep 2008 19:12:04 -0400 Original-Received: from [199.232.76.173] (port=44645 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KhuZY-0008Qz-4x for emacs-devel@gnu.org; Mon, 22 Sep 2008 19:12:04 -0400 Original-Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]:47646) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KhuZS-00023v-VL; Mon, 22 Sep 2008 19:11:59 -0400 Original-Received: from c83-254-151-87.bredband.comhem.se ([83.254.151.87]:65143 helo=[127.0.0.1]) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1KhuZQ-00041B-87; Tue, 23 Sep 2008 01:11:57 +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: <48D79A25.7050000@gmail.com> X-Enigmail-Version: 0.95.7 X-Antivirus: avast! (VPS 080922-0, 2008-09-22), Outbound message X-Antivirus-Status: Clean X-Originating-IP: 83.254.151.87 X-Scan-Result: No virus found in message 1KhuZQ-00041B-87. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1KhuZQ-00041B-87 89edd2d8e9d28a1c17036b243abc968d 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:104047 Archived-At: Lennart Borgman (gmail) wrote: > 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 ... Here is something along the line of the last idea just above here: (defun mumamo-save-buffer-locals (major) "Save some local variables for major mode MAJOR. This should be called before switching to a new chunks major mode." (let ((locals (buffer-local-variables))) (setq locals (mapcar (lambda (local) (unless (or (memq (car local) mumamo-buffer-locals-dont-set) (memq (car local) mumamo-survive) (get (car local) 'permanent-local) ))) locals)) (setq locals (delq nil locals)) (setq mumamo-buffer-locals-per-major (assq-delete-all major mumamo-buffer-locals-per-major)) (setq mumamo-buffer-locals-per-major (cons (cons major-mode locals) mumamo-buffer-locals-per-major)))) ;; (benchmark 1000 '(mumamo-save-buffer-locals major-mode)) ;; (benchmark 1000 '(mumamo-restore-buffer-locals major-mode)) (defun mumamo-restore-buffer-locals (major) "Restore some local variables for major mode MAJOR. This should be called after switching to a new chunks major mode." (let ((locals (cdr (assq major mumamo-buffer-locals-per-major))) var perm) (dolist (rec locals) (setq var (car rec)) (setq perm (get var 'permanent-local)) (unless (or perm (memq var mumamo-buffer-locals-dont-set)) (setq var (cdr rec))))))