* Specifying mode in file variables trouble @ 2008-09-20 0:44 Lennart Borgman (gmail) 2008-09-20 0:48 ` Lennart Borgman (gmail) ` (2 more replies) 0 siblings, 3 replies; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-20 0:44 UTC (permalink / raw To: Emacs Devel I got a question about specifying a multi major mode in a file like this <?php // -*- mode: nxhtml-mumamo -*- This fails with Ignoring unknown mode `nxhtml-mumamo-mode' Could we please compensate for this optimization ... ;-) In other words: Emacs adds "-mode". That is frustrating, but can of course not be changed. However if Emacs finds that this fails, can it then check for just the given "symbol"? That would allow the example above to work, and it would also help all users that fail to notice this little twist in the manual. (I know I was hit by this myself when I tried setting the mode this way.) ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-20 0:44 Specifying mode in file variables trouble Lennart Borgman (gmail) @ 2008-09-20 0:48 ` Lennart Borgman (gmail) 2008-09-20 0:59 ` Miles Bader 2008-09-20 19:03 ` Stefan Monnier 2 siblings, 0 replies; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-20 0:48 UTC (permalink / raw To: Emacs Devel Lennart Borgman (gmail) wrote: > I got a question about specifying a multi major mode in a file like this > > <?php // -*- mode: nxhtml-mumamo -*- > > This fails with > > Ignoring unknown mode `nxhtml-mumamo-mode' > > Could we please compensate for this optimization ... ;-) > > In other words: Emacs adds "-mode". That is frustrating, but can of > course not be changed. However if Emacs finds that this fails, can it > then check for just the given "symbol"? > > That would allow the example above to work, and it would also help all > users that fail to notice this little twist in the manual. (I know I was > hit by this myself when I tried setting the mode this way.) Forgot to add a link to the question I recieved: https://answers.launchpad.net/nxhtml/+question/45721 ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-20 0:44 Specifying mode in file variables trouble Lennart Borgman (gmail) 2008-09-20 0:48 ` Lennart Borgman (gmail) @ 2008-09-20 0:59 ` Miles Bader 2008-09-20 1:06 ` Lennart Borgman (gmail) 2008-09-20 19:03 ` Stefan Monnier 2 siblings, 1 reply; 68+ messages in thread From: Miles Bader @ 2008-09-20 0:59 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: Emacs Devel "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes: > Ignoring unknown mode `nxhtml-mumamo-mode' > > Could we please compensate for this optimization ... ;-) Of course, it would be much simpler just to add a `nxhtml-mumamo-mode' alias, which would also have the benefit of making nxhtml-mumamo mode more consistent with the rest of emacs. -Miles -- Cabbage, n. A familiar kitchen-garden vegetable about as large and wise as a man's head. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-20 0:59 ` Miles Bader @ 2008-09-20 1:06 ` Lennart Borgman (gmail) 2008-09-21 6:32 ` Richard M. Stallman 0 siblings, 1 reply; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-20 1:06 UTC (permalink / raw To: Miles Bader; +Cc: Emacs Devel Miles Bader wrote: > "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes: >> Ignoring unknown mode `nxhtml-mumamo-mode' >> >> Could we please compensate for this optimization ... ;-) > > Of course, it would be much simpler just to add a `nxhtml-mumamo-mode' > alias, which would also have the benefit of making nxhtml-mumamo mode > more consistent with the rest of emacs. Hi Miles, But it is not a major mode, that is why it does not end in "-mode". It ends in "-mumamo" which stands for "multi major mode" here. Maybe it should still end in "-mode", but I think it could be more confusing than helping actually. Beside that it does not help in the second case above. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-20 1:06 ` Lennart Borgman (gmail) @ 2008-09-21 6:32 ` Richard M. Stallman 2008-09-21 12:33 ` Lennart Borgman (gmail) 0 siblings, 1 reply; 68+ messages in thread From: Richard M. Stallman @ 2008-09-21 6:32 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: emacs-devel, miles But it is not a major mode, that is why it does not end in "-mode". It ends in "-mumamo" which stands for "multi major mode" here. Maybe it should still end in "-mode", but I think it could be more confusing than helping actually. Why do you think it is not a major mode? A major mode is simply a command that specifies the overall way to handle the contents of a buffer. I think this command qualifies. So its name should end in `-mode'. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-21 6:32 ` Richard M. Stallman @ 2008-09-21 12:33 ` Lennart Borgman (gmail) 2008-09-21 23:34 ` Richard M. Stallman 0 siblings, 1 reply; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-21 12:33 UTC (permalink / raw To: rms; +Cc: Stefan Monnier, emacs-devel Richard M. Stallman wrote: > But it is not a major mode, that is why it does not end in "-mode". It > ends in "-mumamo" which stands for "multi major mode" here. > > Maybe it should still end in "-mode", but I think it could be more > confusing than helping actually. > > Why do you think it is not a major mode? A major mode is simply a > command that specifies the overall way to handle the contents of a > buffer. I think this command qualifies. > > So its name should end in `-mode'. Ok, I am convinced. I have changed the name convention so that multi major modes now ends in "-mumamo-mode" (instead of the old "-mumamo"). ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-21 12:33 ` Lennart Borgman (gmail) @ 2008-09-21 23:34 ` Richard M. Stallman 2008-09-22 0:38 ` Lennart Borgman (gmail) 0 siblings, 1 reply; 68+ messages in thread From: Richard M. Stallman @ 2008-09-21 23:34 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: monnier, emacs-devel Ok, I am convinced. I have changed the name convention so that multi major modes now ends in "-mumamo-mode" (instead of the old "-mumamo"). That is good. However, I would like to suggest that in some cases there is no need to put `-mumamo' in these names. If this is the right mode for a certain language or type of file, known as FOO, then this command should be called FOO-mode. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-21 23:34 ` Richard M. Stallman @ 2008-09-22 0:38 ` Lennart Borgman (gmail) 2008-09-22 4:39 ` Richard M. Stallman 0 siblings, 1 reply; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-22 0:38 UTC (permalink / raw To: rms; +Cc: monnier, emacs-devel Richard M. Stallman wrote: > Ok, I am convinced. I have changed the name convention so that multi > major modes now ends in "-mumamo-mode" (instead of the old "-mumamo"). > > That is good. However, I would like to suggest that in some cases > there is no need to put `-mumamo' in these names. If this is the > right mode for a certain language or type of file, known as FOO, > then this command should be called FOO-mode. Maybe, but I think most oftenly that will create name clashes. I think that using "-mumamo-mode" is a good way to prevent this and also to tell that it is a multi major modes. (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.) ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-22 0:38 ` Lennart Borgman (gmail) @ 2008-09-22 4:39 ` Richard M. Stallman 2008-09-22 13:14 ` Lennart Borgman (gmail) 0 siblings, 1 reply; 68+ messages in thread From: Richard M. Stallman @ 2008-09-22 4:39 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: monnier, emacs-devel 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. (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. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-22 4:39 ` Richard M. Stallman @ 2008-09-22 13:14 ` Lennart Borgman (gmail) 2008-09-22 14:12 ` Stefan Monnier ` (3 more replies) 0 siblings, 4 replies; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-22 13:14 UTC (permalink / raw To: rms; +Cc: monnier, emacs-devel 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 ... ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-22 13:14 ` Lennart Borgman (gmail) @ 2008-09-22 14:12 ` Stefan Monnier 2008-09-22 14:26 ` Lennart Borgman (gmail) 2008-09-22 23:11 ` Lennart Borgman (gmail) ` (2 subsequent siblings) 3 siblings, 1 reply; 68+ messages in thread From: Stefan Monnier @ 2008-09-22 14:12 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: rms, emacs-devel > 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). Why not web-template-mode? Stefan ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-22 14:12 ` Stefan Monnier @ 2008-09-22 14:26 ` Lennart Borgman (gmail) 2008-09-23 4:40 ` Richard M. Stallman 0 siblings, 1 reply; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-22 14:26 UTC (permalink / raw To: Stefan Monnier; +Cc: rms, emacs-devel Stefan Monnier wrote: >> 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). > > Why not web-template-mode? There are many kind of web templates, for example smarty genshi embperl eruby mako php django mjt jsp noweb ... For each of them I have one with html-mode as main mode and one with nxhtml-mode as main mode. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-22 14:26 ` Lennart Borgman (gmail) @ 2008-09-23 4:40 ` Richard M. Stallman 2008-09-23 9:29 ` Lennart Borgman (gmail) 0 siblings, 1 reply; 68+ messages in thread From: Richard M. Stallman @ 2008-09-23 4:40 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: monnier, emacs-devel For each of them I have one with html-mode as main mode and one with nxhtml-mode as main mode. Why is it necessary to have both? ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-23 4:40 ` Richard M. Stallman @ 2008-09-23 9:29 ` Lennart Borgman (gmail) 2008-09-23 19:47 ` Richard M. Stallman 0 siblings, 1 reply; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-23 9:29 UTC (permalink / raw To: rms; +Cc: monnier, emacs-devel Richard M. Stallman wrote: > For each of them I have one with html-mode as main mode and one with > nxhtml-mode as main mode. > > Why is it necessary to have both? There are currently to different major modes for handling XHTML files in Emacs: html-mode: This is based on sgml-mode. This is a "normal" major mode where everything works ok with MuMaMo. nxml-mode: This is James Clark's nXml mode which has DTD based validation and completion for XML files. (DTD=Document Type Definition, this describes what XML tags and attributes are allowed and where etc.) nxhtml-mode is based on nxml-mode. I have added some more convenient completion functions for XHTML files there. This is not part of Emacs. I distribute it in the nXhtml package together with MuMaMo. There are still some problems with the nxml-mode parser and multi major modes. Most of the time it works well, but it is not perfect. So there are two reasons: - html-mode is included in Emacs, but nxhtml-mode is not. - html-mode works ok with multi major modes, while there are some minor (from a users perspective) glitches with how nxhtml-mode works with multi major modes. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-23 9:29 ` Lennart Borgman (gmail) @ 2008-09-23 19:47 ` Richard M. Stallman 0 siblings, 0 replies; 68+ messages in thread From: Richard M. Stallman @ 2008-09-23 19:47 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: monnier, emacs-devel nxhtml-mode is based on nxml-mode. I have added some more convenient completion functions for XHTML files there. This is not part of Emacs. I distribute it in the nXhtml package together with MuMaMo. When we install MuMaMo, I guess we can install this too. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-22 13:14 ` Lennart Borgman (gmail) 2008-09-22 14:12 ` Stefan Monnier @ 2008-09-22 23:11 ` Lennart Borgman (gmail) 2008-09-23 4:40 ` Richard M. Stallman 2008-09-23 4:40 ` Richard M. Stallman 3 siblings, 0 replies; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-22 23:11 UTC (permalink / raw To: rms; +Cc: monnier, emacs-devel 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)))))) ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-22 13:14 ` Lennart Borgman (gmail) 2008-09-22 14:12 ` Stefan Monnier 2008-09-22 23:11 ` Lennart Borgman (gmail) @ 2008-09-23 4:40 ` Richard M. Stallman 2008-09-23 9:47 ` Lennart Borgman (gmail) 2008-09-23 4:40 ` Richard M. Stallman 3 siblings, 1 reply; 68+ messages in thread From: Richard M. Stallman @ 2008-09-23 4:40 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: monnier, emacs-devel 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 It seems to me that if PHP files are likely to contain these other things, it is good for Emacs to handle them automatically in PHP files. Here's one way: rename the basic PHP mode to `php-only-mode', and define `php-mode' as the mumamo mode to handle all of these. What do you think? Another variant is to make `php-mode' check for other languages, and call either `php-only-mode' or `php-mumamo-mode'. Or perhaps it could select among a larger variety of modes, depending on what combinations of languages are actually used in one file. If we don't do this, users can cope by adding explicit -*- specs. But that is inconvenient, so why not do this automatically? ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-23 4:40 ` Richard M. Stallman @ 2008-09-23 9:47 ` Lennart Borgman (gmail) 2008-09-23 19:47 ` Richard M. Stallman 2008-09-23 19:47 ` Richard M. Stallman 0 siblings, 2 replies; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-23 9:47 UTC (permalink / raw To: rms; +Cc: David House, monnier, Aaron Hawley, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1631 bytes --] Richard M. Stallman wrote: > 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 > > It seems to me that if PHP files are likely to contain these other > things, it is good for Emacs to handle them automatically in PHP files. Yes, I agree. > Here's one way: rename the basic PHP mode to `php-only-mode', and > define `php-mode' as the mumamo mode to handle all of these. What do > you think? I am not sure. I liked html+php-mode better. Maybe using the name php-mode would also create confusion since the name is already in use. However php-only-mode may be a good choice. BTW, php-mode.el (or some version of it) is still not in Emacs. I am distributing it as part of nXhtml (and it can also be found on Emacs Wiki). > Another variant is to make `php-mode' check for other languages, and > call either `php-only-mode' or `php-mumamo-mode'. Or perhaps it could > select among a larger variety of modes, depending on what combinations > of languages are actually used in one file. > > If we don't do this, users can cope by adding explicit -*- specs. But > that is inconvenient, so why not do this automatically? I have suggested a different solution to this quite general problem. I think a list of major mode priorities would be better. I have implemented that in majmodpri.el which I am resending here. (I think I might have made some changes since last time I sent it.) [-- Attachment #2: majmodpri.el --] [-- Type: text/plain, Size: 10746 bytes --] ;;; majmodpri.el --- Major mode priorities handling ;; ;; Author: Lennart Borgman (lennart O borgman A gmail O com) ;; Created: 2008-08-26 (defconst majmodpri:version "0.6") ;;Version: ;; Last-Updated: 2008-08-26T19:21:00+0200 Tue ;; URL: ;; Keywords: ;; Compatibility: ;; ;; Features that might be required by this library: ;; ;; None ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;;; Commentary: ;; ;; Different elisp libraries may try to handle the same type of files. ;; They normally do that by entering their major mode for a file type ;; in `auto-mode-alist' or the other lists affecting `normal-mode'. ;; Since the libraries may be loaded in different orders in different ;; Emacs sessions this can lead to rather stochastic choices of major ;; mode. ;; ;; This library tries to give the control of which major modes will be ;; used back to the user. It does that by letting the user set up ;; priorities among the major modes. This priorities are used to sort ;; the lists used by `normal-mode'. ;; ;; To setup this libray and get more information do ;; ;; M-x customize-group RET majmodpri RET ;; ;; Or, see the commands `majmodpri-sort-lists'. ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;;; Change log: ;; ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; This program is free software; you can redistribute it and/or ;; modify it under the terms of the GNU General Public License as ;; published by the Free Software Foundation; either version 2, or ;; (at your option) any later version. ;; ;; This program is distributed in the hope that it will be useful, ;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU ;; General Public License for more details. ;; ;; You should have received a copy of the GNU General Public License ;; along with this program; see the file COPYING. If not, write to ;; the Free Software Foundation, Inc., 51 Franklin Street, Fifth ;; Floor, Boston, MA 02110-1301, USA. ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;;; Code: ;;;; Idle sorting (defvar majmodpri-idle-sort-timer nil) (defun majmodpri-cancel-idle-sort () "Cancel idle sorting request." (when majmodpri-idle-sort-timer (cancel-timer majmodpri-idle-sort-timer) (setq majmodpri-idle-sort-timer nil))) (defun majmodpri-start-idle-sort () "Request idle sorting." (majmodpri-cancel-idle-sort) (setq majmodpri-idle-sort-timer (run-with-idle-timer 0 nil 'majmodpri-sort-lists-in-timer))) (defun majmodpri-sort-lists-in-timer () (condition-case err (majmodpri-sort-lists) (error (message "(majmodpri-sort-lists): %s" err)))) ;;;; Custom (defgroup majmodpri nil "Customization group for majmodpri.el" :group 'nxhml ) (defcustom majmodpri-sort-after-load nil "Sort major mode lists after loading elisp libraries. Sorting is not done immediately. Instead it runs in an idle timer. This means that if several elisp libraries are loaded in a command then the sorting will only be done once, after the command has finished. See `majmodpri-sort-lists' for more information." :type '(choice (const :tag "Never" nil) (const :tag "After loading any elisp library" t) (repeat :tag "After loading specified libraries" symbol)) :set (lambda (sym val) (set-default sym val) ;; Clean up `after-load-alist' first. (setq after-load-alist (delq nil (mapcar (lambda (rec) (unless (equal (cadr rec) '(majmodpri-start-idle-sort)) rec)) after-load-alist))) (when val (if (not (listp val)) (add-to-list 'after-load-alist '(".*" (majmodpri-start-idle-sort))) (dolist (feat val) (unless (featurep feat) (eval-after-load feat '(majmodpri-start-idle-sort))))) (majmodpri-start-idle-sort))) :group 'majmodpri) (defcustom majmodpri-lists-to-sort '(magic-mode-alist auto-mode-alist magic-fallback-mode-alist) ;;nil "Which major mode lists to sort. See `majmodpri-sort-lists' for more information." :type '(set (const magic-mode-alist) (const auto-mode-alist) (const magic-fallback-mode-alist)) :set (lambda (sym val) (set-default sym val) (when majmodpri-sort-after-load (majmodpri-start-idle-sort))) :group 'majmodpri) (defcustom majmodpri-mode-priorities '( cperl-mumamo-mode csound-sgml-mumamo-mode django-nxhtml-mumamo-mode django-html-mumamo-mode embperl-nxhtml-mumamo-mode embperl-html-mumamo-mode eruby-nxhtml-mumamo-mode eruby-html-mumamo-mode genshi-nxhtml-mumamo-mode genshi-html-mumamo-mode jsp-nxhtml-mumamo-mode jsp-html-mumamo-mode laszlo-nxml-mumamo-mode metapost-mumamo-mode mjt-nxhtml-mumamo-mode mjt-html-mumamo-mode noweb2-mumamo-mode ;;org-mumamo-mode perl-mumamo-mode smarty-nxhtml-mumamo-mode smarty-html-mumamo-mode ;;tt-html-mumamo-mode nxhtml-mumamo-mode html-mumamo-mode nxml-mumamo-mode nxml-mode rhtml-mode ) "Priority list for major modes. Modes that comes first have higher priority. See `majmodpri-sort-lists' for more information." :type '(repeat symbol) :set (lambda (sym val) (set-default sym val) (when majmodpri-sort-after-load (majmodpri-start-idle-sort))) :group 'majmodpri) ;;;; Sorting (defvar majmodpri-schwarzian-ordnum nil) (defun majmodpri-schwarzian-in (rec) "Transform REC before sorting." (setq majmodpri-schwarzian-ordnum (1+ majmodpri-schwarzian-ordnum)) (let ((mode (cdr rec))) (list (list mode majmodpri-schwarzian-ordnum) rec))) (defun majmodpri-schwarzian-out (rec) "Get original value of REC after sorting." (cadr rec)) (defsubst majmodpri-priority (mode) "Return major mode MODE priority." (length (memq mode majmodpri-mode-priorities))) (defun majmodpri-compare-auto-modes (rec1 rec2) "Compare record REC1 and record REC2. Comparision: - First check `majmodpri-mode-priorities'. - Then use old order in list." (let* ((schw1 (car rec1)) (schw2 (car rec2)) (mod1 (nth 0 schw1)) (mod2 (nth 0 schw2)) (ord1 (nth 1 schw1)) (ord2 (nth 1 schw2)) (pri1 (majmodpri-priority mod1)) (pri2 (majmodpri-priority mod2))) (cond ((/= pri1 pri2) (> pri1 pri2)) (t (> ord1 ord2))))) ;;(benchmark 100 (quote (majmodpri-sort-lists))) ;;(defvar my-auto-mode-alist nil) (defun majmodpri-sort-auto-mode-alist () "Sort `auto-mode-alist' after users priorities." (setq majmodpri-schwarzian-ordnum 0) ;; Do not reorder function part, but put it first. (let (fun-list mod-list) (dolist (rec auto-mode-alist) (if (listp (cdr rec)) (setq fun-list (cons rec fun-list)) (setq mod-list (cons rec mod-list)))) (setq fun-list (nreverse fun-list)) (setq auto-mode-alist (append fun-list (mapcar 'majmodpri-schwarzian-out (sort (mapcar 'majmodpri-schwarzian-in mod-list) 'majmodpri-compare-auto-modes)))))) (defun majmodpri-sort-magic-list (magic-mode-list-sym) "Sort list MAGIC-MODE-LIST-SYM after users priorities." (let ((orig-ordnum 0)) (set magic-mode-list-sym ;; S out (mapcar (lambda (rec) (cadr rec)) ;; Sort (sort ;; S in (mapcar (lambda (rec) (setq orig-ordnum (1+ orig-ordnum)) (let ((mode (cdr rec))) (list (list mode orig-ordnum) rec))) (symbol-value magic-mode-list-sym)) (lambda (rec1 rec2) (let* ((schw1 (car rec1)) (schw2 (car rec2)) (mod1 (nth 0 schw1)) (mod2 (nth 0 schw2)) (ord1 (nth 1 schw1)) (ord2 (nth 1 schw2)) (pri1 (majmodpri-priority mod1)) (pri2 (majmodpri-priority mod2))) (cond ((/= pri1 pri2) (> pri1 pri2)) (t (> ord1 ord2)))))))))) (defun majmodpri-sort-lists () "Sort the list used when selecting major mode. Only sort those lists choosen in `majmodpri-lists-to-sort'. Sort according to priorities in `majmodpri-mode-priorities'. Keep the old order in the list otherwise. The lists can be sorted when loading elisp libraries, see `majmodpri-sort-after-load'. See also `majmodpri-apply-priorities'." (interactive) (message "majmodpri-sort-lists running ...") (majmodpri-cancel-idle-sort) (when (memq 'magic-mode-alist majmodpri-lists-to-sort) (majmodpri-sort-magic-list 'magic-mode-alist)) (when (memq 'auto-mode-alist majmodpri-lists-to-sort) (majmodpri-sort-auto-mode-alist)) (when (memq 'magic-fallback-mode-alist majmodpri-lists-to-sort) (majmodpri-sort-magic-list 'magic-fallback-mode-alist))) (defun majmodpri-apply-priorities (change-modes) "Apply major mode priorities. First run `majmodpri-sort-lists' and then if CHANGE-MODES is non-nil apply to existing file buffers. If interactive ask before applying." (interactive '(nil)) (majmodpri-sort-lists) (when (or change-modes (called-interactively-p)) (let (file-buffers) (dolist (buffer (buffer-list)) (with-current-buffer buffer (let ((name (buffer-name)) (file buffer-file-name)) (or (string= (substring name 0 1) " ") ;; Internal (not file) (setq file-buffers (cons buffer file-buffers)))))) (if (not file-buffers) (when change-modes (message "No file buffers to change modes in")) (when (called-interactively-p) (setq change-modes (y-or-n-p "Check major mode in all file visiting buffers? "))) (when change-modes (dolist (buffer file-buffers) (with-current-buffer buffer (normal-mode)))))))) (provide 'majmodpri) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; majmodpri.el ends here ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-23 9:47 ` Lennart Borgman (gmail) @ 2008-09-23 19:47 ` Richard M. Stallman 2008-09-23 20:43 ` Lennart Borgman (gmail) 2008-09-23 19:47 ` Richard M. Stallman 1 sibling, 1 reply; 68+ messages in thread From: Richard M. Stallman @ 2008-09-23 19:47 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: dmhouse, emacs-devel, monnier, aaron.s.hawley I am not sure. I liked html+php-mode better. Maybe using the name php-mode would also create confusion since the name is already in use. I don't see the problem. Would anyone now in the habit of running `pho-mode' be disappointed after this change? I have suggested a different solution to this quite general problem. I think a list of major mode priorities would be better. I have implemented that in majmodpri.el which I am resending here. I do not see how majmodpri would help solve this problem. It does not seem relevant. Here's the scenario: the user visits a file called foo.php which contains code in various languages. How do you propose for Emacs to pick the right major mode? I proposed two solutions: * Always call `php-mode', and define `php-mode' using mumamo to handle all the languages that can be in a PHP file. * Always call `php-mode', and define `php-mode' to handle all the languages that are found in this PHP file. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-23 19:47 ` Richard M. Stallman @ 2008-09-23 20:43 ` Lennart Borgman (gmail) 2008-09-24 13:47 ` Richard M. Stallman 2008-09-24 13:47 ` Richard M. Stallman 0 siblings, 2 replies; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-23 20:43 UTC (permalink / raw To: rms; +Cc: dmhouse, emacs-devel, monnier, aaron.s.hawley Richard M. Stallman wrote: > I am not sure. I liked html+php-mode better. > > Maybe using the name php-mode would also create confusion since the name > is already in use. > > I don't see the problem. Would anyone now in the habit of running > `php-mode' be disappointed after this change? I don't know for sure, but some people seem to want to use just php-mode instead of the solution with mumamo. It is not clear to me why and if some people still prefer that. It might be that they find mumamo complex or that they do not want the whole of nXhtml. It might also be because some php files actually contains only php code. > I have suggested a different solution to this quite general problem. I > think a list of major mode priorities would be better. I have > implemented that in majmodpri.el which I am resending here. > > I do not see how majmodpri would help solve this problem. > It does not seem relevant. Again, as in my previous message (to your other message), I think the commentary in majmodpri explains why majmodpri.el is relevant. > Here's the scenario: the user visits a file called foo.php which > contains code in various languages. How do you propose for Emacs > to pick the right major mode? I propose that Emacs uses the same mechanism as today. That means that the order of the entries in `auto-mode-alist' is used. But I want to give the user control over the order in `auto-mode-alist'. That is what majmodpri.el is for. > I proposed two solutions: > > * Always call `php-mode', and define `php-mode' using mumamo to handle > all the languages that can be in a PHP file. > > * Always call `php-mode', and define `php-mode' to handle all the > languages that are found in this PHP file. I think the only reasonable way to do it is to use mumamo. (Maybe CEDET can change that in the future, but I rather think that CEDET and mumamo should cooperate.) ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-23 20:43 ` Lennart Borgman (gmail) @ 2008-09-24 13:47 ` Richard M. Stallman 2008-09-24 13:47 ` Richard M. Stallman 1 sibling, 0 replies; 68+ messages in thread From: Richard M. Stallman @ 2008-09-24 13:47 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: dmhouse, monnier, aaron.s.hawley, emacs-devel > Here's the scenario: the user visits a file called foo.php which > contains code in various languages. How do you propose for Emacs > to pick the right major mode? I propose that Emacs uses the same mechanism as today. That means that the order of the entries in `auto-mode-alist' is used. Sorry, that is just a part of the answer. If you propose to do this using auto-mode-alist, what are the items you think should be in auto-mode-alist? And in what order? But I want to give the user control over the order in `auto-mode-alist'. When we figure out precisely what we would DO with `auto-mode-alist', we could begin to think about whether such control is useful. > * Always call `php-mode', and define `php-mode' using mumamo to handle > all the languages that can be in a PHP file. > > * Always call `php-mode', and define `php-mode' to handle all the > languages that are found in this PHP file. I think the only reasonable way to do it is to use mumamo. (Maybe CEDET can change that in the future, but I rather think that CEDET and mumamo should cooperate.) If that means using the first of my proposals, that only requires one item in `auto-mode-alist', so there is no issue about the order of them. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-23 20:43 ` Lennart Borgman (gmail) 2008-09-24 13:47 ` Richard M. Stallman @ 2008-09-24 13:47 ` Richard M. Stallman 2008-09-24 17:21 ` Lennart Borgman (gmail) 1 sibling, 1 reply; 68+ messages in thread From: Richard M. Stallman @ 2008-09-24 13:47 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: dmhouse, monnier, aaron.s.hawley, emacs-devel I don't know for sure, but some people seem to want to use just php-mode instead of the solution with mumamo. It is not clear to me why and if some people still prefer that. Please ask them. That answer is the most important of all! ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-24 13:47 ` Richard M. Stallman @ 2008-09-24 17:21 ` Lennart Borgman (gmail) 2008-09-25 5:49 ` Richard M. Stallman 0 siblings, 1 reply; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-24 17:21 UTC (permalink / raw To: rms; +Cc: dmhouse, monnier, aaron.s.hawley, emacs-devel Richard M. Stallman wrote: > I don't know for sure, but some people seem to want to use just php-mode > instead of the solution with mumamo. It is not clear to me why and if > some people still prefer that. > > Please ask them. That answer is the most important of all! I have done that, but a while ago. It seems like the arguments were something like: - They think using MuMaMo means that they have to learn more. - MuMaMo is more complicated and that may mean more trouble - Some believe that they might loose control. - There is also more code to download since nXhtml is rather large. I can't say these arguments are invalid. I have however tried to simplify things as much as possible on the user level and I do not know for sure what people think now. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-24 17:21 ` Lennart Borgman (gmail) @ 2008-09-25 5:49 ` Richard M. Stallman 2008-09-25 6:28 ` tomas 0 siblings, 1 reply; 68+ messages in thread From: Richard M. Stallman @ 2008-09-25 5:49 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: dmhouse, emacs-devel, monnier, aaron.s.hawley - They think using MuMaMo means that they have to learn more. - MuMaMo is more complicated and that may mean more trouble - Some believe that they might loose control. - There is also more code to download since nXhtml is rather large. These are just worries, imaginary problems. I don't think we should be very concerned about them. When people can really try this, then we can see if there are real problems. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-25 5:49 ` Richard M. Stallman @ 2008-09-25 6:28 ` tomas 2008-09-25 6:41 ` Paul R 2008-09-27 4:39 ` Richard M. Stallman 0 siblings, 2 replies; 68+ messages in thread From: tomas @ 2008-09-25 6:28 UTC (permalink / raw To: Richard M. Stallman Cc: dmhouse, Lennart Borgman (gmail), monnier, aaron.s.hawley, emacs-devel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Sep 25, 2008 at 01:49:19AM -0400, Richard M. Stallman wrote: > - They think using MuMaMo means that they have to learn more. > - MuMaMo is more complicated and that may mean more trouble > - Some believe that they might loose control. > - There is also more code to download since nXhtml is rather large. > > These are just worries, imaginary problems. > I don't think we should be very concerned about them. I don't program PHP -- so take this with a grain of salt. But I would be wary of pulling in a full-fledged XML machinery just to edit (pure) PHP source just because it is sometimes embedded in (X)HTML templates. And I would be --uh-- rather uneasy being told this to be "imaginary problems". As an analogy, I'm regularly irked by reglar GNU/Linux distros installing Avahi-this or Evolution-that just because I want a music player or a task calendar. I try to avoid those packages which pull in half-a-world of stuff I don't need. Just (half) a data point. Regards - -- tomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI2y+dBcgs9XrR2kYRAiDHAJ4zczkVQ0NW4AVv7HuOeD2D7DagwgCfYMhH YnyzQ//XMKPSc16Ss0KNyBw= =aIVG -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-25 6:28 ` tomas @ 2008-09-25 6:41 ` Paul R 2008-09-25 7:55 ` tomas 2008-09-27 4:39 ` Richard M. Stallman 1 sibling, 1 reply; 68+ messages in thread From: Paul R @ 2008-09-25 6:41 UTC (permalink / raw To: tomas Cc: Richard M. Stallman, Lennart Borgman (gmail), emacs-devel, aaron.s.hawley, dmhouse, monnier Hello Thomas, On Thu, 25 Sep 2008 08:28:45 +0200, tomas@tuxteam.de said: tomas> But I would be wary of pulling in a full-fledged XML machinery tomas> just to edit (pure) PHP source just because it is sometimes tomas> embedded in (X)HTML templates. And I would be --uh-- rather tomas> uneasy being told this to be "imaginary problems". The line has to be drawn at a point. We probably all agree that emacs memory consumption is sufficiently low with respect to current hardware. So I beleive this should not drive out features that make emacs DTRT when visiting a file. tomas> As an analogy, I'm regularly irked by reglar GNU/Linux distros tomas> installing Avahi-this or Evolution-that just because I want tomas> a music player or a task calendar. I try to avoid those tomas> packages which pull in half-a-world of stuff I don't need. I think this a different kind of problem (persistent storage consumption). And some distros offer you to choose dependency at build time, through build flags. Distros you are talking about are probably designed for ease of use and least surprise, and I bet they perform very well in this field. Aren't they ? BTW, I hope we can get emacs distribution more modular during next cycle, so that you would not have to download and build a complex php mode if you never edit php. -- Paul ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-25 6:41 ` Paul R @ 2008-09-25 7:55 ` tomas 2008-09-25 8:35 ` Paul R 0 siblings, 1 reply; 68+ messages in thread From: tomas @ 2008-09-25 7:55 UTC (permalink / raw To: Paul R Cc: Richard M. Stallman, Lennart Borgman (gmail), emacs-devel, aaron.s.hawley, dmhouse, monnier -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Sep 25, 2008 at 08:41:22AM +0200, Paul R wrote: > Hello Thomas, > > On Thu, 25 Sep 2008 08:28:45 +0200, tomas@tuxteam.de said: > > tomas> But I would be wary of pulling in a full-fledged XML machinery > tomas> just to edit (pure) PHP source [...] > The line has to be drawn at a point. We probably all agree that emacs > memory consumption is sufficiently low with respect to current > hardware. So I beleive this should not drive out features that make > emacs DTRT when visiting a file. It's only partially the computer's resources I am worried about. It's my limited brain. I like the feeling I understand the tools I use (to some extent). > tomas> As an analogy, I'm regularly irked by reglar GNU/Linux distros > tomas> installing Avahi-this or Evolution-that [...] > I think this a different kind of problem (persistent storage > consumption). And some distros offer you to choose dependency at build > time, through build flags. Distros you are talking about are probably > designed for ease of use and least surprise, and I bet they perform > very well in this field. Aren't they ? They do now, but you see a growing tendency of everything-depending-on- everything-else, which is a pity, really. Because this modularity was a strength of the UNIX-like systems. > BTW, I hope we can get emacs distribution more modular during next > cycle, so that you would not have to download and build a complex php > mode if you never edit php. This is a goal in itself, but the point I was trying to make is: if I was a PHP programmer, I probably wouldn't like to have the whole XML/HTML kaboodle in that as well *unless I needed it*. It was a plea to make the mumamo approach itself more modular (I do applaud the multiple major modes work very strongly!). Regards - -- tomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI20QABcgs9XrR2kYRAnlwAJsG/qcwlfbCBC32qVX2bJYOf1z0mwCfUpWq rI0jBNIOLva0XI1cbte/TJQ= =j/S4 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-25 7:55 ` tomas @ 2008-09-25 8:35 ` Paul R 2008-09-25 16:42 ` Lennart Borgman 0 siblings, 1 reply; 68+ messages in thread From: Paul R @ 2008-09-25 8:35 UTC (permalink / raw To: tomas Cc: Richard M. Stallman, Lennart Borgman (gmail), emacs-devel, monnier, dmhouse, aaron.s.hawley On Thu, 25 Sep 2008 09:55:44 +0200, tomas@tuxteam.de said: tomas> [snip] I probably wouldn't like to have tomas> the whole XML/HTML kaboodle in that as well *unless I needed tomas> it*. I guess it would not be triggered unless the point is inside an XML region. IOW, you would not see the whole XML kaboodle unless you actually need it. Lennart, can you confirm ? -- Paul ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-25 8:35 ` Paul R @ 2008-09-25 16:42 ` Lennart Borgman 0 siblings, 0 replies; 68+ messages in thread From: Lennart Borgman @ 2008-09-25 16:42 UTC (permalink / raw To: Paul R Cc: Richard M. Stallman, emacs-devel, tomas, monnier, dmhouse, aaron.s.hawley On Thu, Sep 25, 2008 at 10:35 AM, Paul R <paul.r.ml@gmail.com> wrote: > On Thu, 25 Sep 2008 09:55:44 +0200, tomas@tuxteam.de said: > tomas> [snip] I probably wouldn't like to have > tomas> the whole XML/HTML kaboodle in that as well *unless I needed > tomas> it*. > > I guess it would not be triggered unless the point is inside an XML > region. IOW, you would not see the whole XML kaboodle unless you > actually need it. Lennart, can you confirm ? Thanks for asking, Paul. Actually I did a load a bit more than I think is necessary for cases like files consisting of just PHP code and no XHTML code. I just removed it. I don't think it is needed any more. The heavy things should be autoloaded. Possibly I missed something. If you find out please tell me. When it comes to editing a PHP file there is actually three possibilities 1) Just using php-mode from php-mode.el. 2) html-mumamo-mode, which is 1 + mumamo + html-mode. 3) nxhtml-mumamo-mode, which is 1 + mumamo + nxhtml-mode Number 2 here may perhaps be a good choice for those that does not care about completion and validation in the XHTML parts. It is possibly a bit smaller than 3 since html-mode is smaller than nxhtml-mode (at least that is what I believe). And of course a little bit less complicated since it does not offer the more accurate completion in the XHTML parts that nxml-mode (nxhtml-mode) offers. Personally I think 3 is the best, but then I of course knows about the complexities. (Note that the multi major mode names are not the ones used in the released version of nXhtml.) ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-25 6:28 ` tomas 2008-09-25 6:41 ` Paul R @ 2008-09-27 4:39 ` Richard M. Stallman 2008-10-21 19:16 ` Lennart Borgman (gmail) 1 sibling, 1 reply; 68+ messages in thread From: Richard M. Stallman @ 2008-09-27 4:39 UTC (permalink / raw To: tomas; +Cc: dmhouse, emacs-devel, lennart.borgman, monnier, aaron.s.hawley But I would be wary of pulling in a full-fledged XML machinery just to edit (pure) PHP source just because it is sometimes embedded in (X)HTML templates. That would be a problem, but we can easily avoid it. Here are two ways. * Make `php-mode' check whether there is HTML or XML in the file and choose the mode accordingly. * Arrange for mumamo not to call `nxml-mode' unless/until you move point into an HTML chunk. You're worried about a hypothetical problem in the detail of the implementation. That problem might happen, and if it does, we will fix it. So there is no point worrying about it now. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-27 4:39 ` Richard M. Stallman @ 2008-10-21 19:16 ` Lennart Borgman (gmail) 2008-10-22 5:21 ` tomas 2008-10-22 6:21 ` Richard M. Stallman 0 siblings, 2 replies; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-10-21 19:16 UTC (permalink / raw To: rms; +Cc: dmhouse, tomas, emacs-devel, monnier, aaron.s.hawley Richard M. Stallman wrote: > But I would be wary of pulling in a full-fledged XML machinery just to > edit (pure) PHP source just because it is sometimes embedded in (X)HTML > templates. > > That would be a problem, but we can easily avoid it. Here are two > ways. > > * Make `php-mode' check whether there is HTML or XML in the file > and choose the mode accordingly. > > * Arrange for mumamo not to call `nxml-mode' unless/until you move > point into an HTML chunk. This is the way I have implemented it now, a major mode is not loaded by mumamo until you move into a chunk where this major mode is used. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-10-21 19:16 ` Lennart Borgman (gmail) @ 2008-10-22 5:21 ` tomas 2008-10-22 6:21 ` Richard M. Stallman 1 sibling, 0 replies; 68+ messages in thread From: tomas @ 2008-10-22 5:21 UTC (permalink / raw To: Lennart Borgman (gmail) Cc: rms, emacs-devel, tomas, aaron.s.hawley, dmhouse, monnier -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Oct 21, 2008 at 09:16:49PM +0200, Lennart Borgman (gmail) wrote: [...] > This is the way I have implemented it now, a major mode is not loaded by > mumamo until you move into a chunk where this major mode is used. Thanks, sounds great :-) Regards - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI/rhKBcgs9XrR2kYRAmNyAJ9bvKdvWFyJ1m3Xl0Azqzo1jmqUzwCfW7rA VlE0zEi3TmNyUeYStxxM40w= =1Isi -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-10-21 19:16 ` Lennart Borgman (gmail) 2008-10-22 5:21 ` tomas @ 2008-10-22 6:21 ` Richard M. Stallman 1 sibling, 0 replies; 68+ messages in thread From: Richard M. Stallman @ 2008-10-22 6:21 UTC (permalink / raw To: Lennart Borgman (gmail) Cc: dmhouse, tomas, monnier, aaron.s.hawley, emacs-devel > * Arrange for mumamo not to call `nxml-mode' unless/until you move > point into an HTML chunk. This is the way I have implemented it now, a major mode is not loaded by mumamo until you move into a chunk where this major mode is used. That is good. So it is fine if php-mode always sets up to use mumamo. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-23 9:47 ` Lennart Borgman (gmail) 2008-09-23 19:47 ` Richard M. Stallman @ 2008-09-23 19:47 ` Richard M. Stallman 2008-09-23 20:37 ` Lennart Borgman (gmail) 2008-09-24 23:09 ` Lennart Borgman (gmail) 1 sibling, 2 replies; 68+ messages in thread From: Richard M. Stallman @ 2008-09-23 19:47 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: dmhouse, emacs-devel, monnier, aaron.s.hawley The "idle sorting" mechanism in majmodpri.el is asking for trouble. Loading a file should _fully_ install the code in that file. To leave _anything_ for later is unreliable. I'm not sure whether majmodpri is a useful feature, because I am not convinced there is a real problem to be solved. What is a real case of the problem, and is there another solution? But if we want such a facility, we should implement it right. The right way is to insert these elements in the proper position the first time. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-23 19:47 ` Richard M. Stallman @ 2008-09-23 20:37 ` Lennart Borgman (gmail) 2008-09-24 13:47 ` Richard M. Stallman 2008-09-24 23:09 ` Lennart Borgman (gmail) 1 sibling, 1 reply; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-23 20:37 UTC (permalink / raw To: rms; +Cc: dmhouse, emacs-devel, monnier, aaron.s.hawley Richard M. Stallman wrote: > The "idle sorting" mechanism in majmodpri.el is asking for trouble. > Loading a file should _fully_ install the code in that file. To leave > _anything_ for later is unreliable. The "idle sorting" is there to avoid unnecessary sorting. It has a delay of 0 so for most interactive use there will be no problems. However I agree with your general point. If this is integrated in Emacs I hope it will be quite easy to find some points where sorting most be started if not done before. (This can perhaps be in addition to the "idle sorting".) > I'm not sure whether majmodpri is a useful feature, because I am not > convinced there is a real problem to be solved. What is a real case > of the problem, and is there another solution? I tried to describe the problem in the comment in majmodpri.el. Is that comment not clear? > But if we want such a facility, we should implement it right. The > right way is to insert these elements in the proper position the first > time. Unfortunately that can't be done. Please see the comment above. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-23 20:37 ` Lennart Borgman (gmail) @ 2008-09-24 13:47 ` Richard M. Stallman 2008-09-24 16:23 ` Lennart Borgman (gmail) 0 siblings, 1 reply; 68+ messages in thread From: Richard M. Stallman @ 2008-09-24 13:47 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: dmhouse, monnier, aaron.s.hawley, emacs-devel > I'm not sure whether majmodpri is a useful feature, because I am not > convinced there is a real problem to be solved. What is a real case > of the problem, and is there another solution? I tried to describe the problem in the comment in majmodpri.el. Is that comment not clear? I can see what feature the file implements, for controlling the order of `auto-mode-alist' and a few other variables. I do not see that the feature is useful. If you show me a REAL case in which this is useful, that might convice me. I am not impressed by imaginary hypothetical cases. > But if we want such a facility, we should implement it right. The > right way is to insert these elements in the proper position the first > time. Unfortunately that can't be done. Please see the comment above. Of course it can be done. It is easy to write a function that would add an item to `auto-mode-alist' and choose where to put it based on whatever criteria we like. It could take four three arguments, one being the major mode that the elements are for, and the other three being elements to add to the three variables that majmodpri sorts. And it could insert them in the proper order. I don't know if it is useful, but it is not hard. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-24 13:47 ` Richard M. Stallman @ 2008-09-24 16:23 ` Lennart Borgman (gmail) 2008-09-25 5:50 ` Richard M. Stallman 0 siblings, 1 reply; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-24 16:23 UTC (permalink / raw To: rms; +Cc: dmhouse, monnier, aaron.s.hawley, emacs-devel Richard M. Stallman wrote: > > I'm not sure whether majmodpri is a useful feature, because I am not > > convinced there is a real problem to be solved. What is a real case > > of the problem, and is there another solution? > > I tried to describe the problem in the comment in majmodpri.el. Is that > comment not clear? > > I can see what feature the file implements, for controlling the order > of `auto-mode-alist' and a few other variables. I do not see that the > feature is useful. > > If you show me a REAL case in which this is useful, that might convice me. When I wrote the majmodpri.el I had third party elisp files in mind. For files inside Emacs we can perhaps use a simpler mechanism. It is quite common that third party files adds themselves to auto-mode-alist when they are loaded. At least some of the php-mode.el varianst that are available does that; they bind .php to the php-mode the supply. This will then be the default major mode for .php files. We can of course say that should not have this side effect, but that does not help all times. (We have already done that.) This problem actually exists inside Emacs too. Today there are two major modes for editing XML files. majmodpri.el offers a way to solve this type of problem through custom (though it may of course need some changes). > I am not impressed by imaginary hypothetical cases. > > > But if we want such a facility, we should implement it right. The > > right way is to insert these elements in the proper position the first > > time. > > Unfortunately that can't be done. Please see the comment above. > > Of course it can be done. Yes, but this is a misunderstanding. I was thinking of the problems I wrote about above. > It is easy to write a function that would > add an item to `auto-mode-alist' and choose where to put it based on > whatever criteria we like. It could take four three arguments, one > being the major mode that the elements are for, and the other three > being elements to add to the three variables that majmodpri sorts. > And it could insert them in the proper order. > > I don't know if it is useful, but it is not hard. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-24 16:23 ` Lennart Borgman (gmail) @ 2008-09-25 5:50 ` Richard M. Stallman 0 siblings, 0 replies; 68+ messages in thread From: Richard M. Stallman @ 2008-09-25 5:50 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: dmhouse, emacs-devel, monnier, aaron.s.hawley > If you show me a REAL case in which this is useful, that might convice me. When I wrote the majmodpri.el I had third party elisp files in mind. If show us a real case involving third party Elisp files, we can look at whether there is a problem, and if so what solutions may be possible. My hunch is that this is not the best solution for any case, but until I see the cases, I cannot be sure. At least some of the php-mode.el varianst that are available does that; they bind .php to the php-mode the supply. This will then be the default major mode for .php files. When we have a builtin php-mode (perhaps one that uses mumamo), we will of course tell people they should modify those packages or stop using them. This problem actually exists inside Emacs too. Today there are two major modes for editing XML files. Why are both present? Please say more about that situation, so I can think about what best to do. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-23 19:47 ` Richard M. Stallman 2008-09-23 20:37 ` Lennart Borgman (gmail) @ 2008-09-24 23:09 ` Lennart Borgman (gmail) 1 sibling, 0 replies; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-24 23:09 UTC (permalink / raw To: rms; +Cc: dmhouse, emacs-devel, monnier, aaron.s.hawley Richard M. Stallman wrote: > The "idle sorting" mechanism in majmodpri.el is asking for trouble. > Loading a file should _fully_ install the code in that file. To leave > _anything_ for later is unreliable. > > I'm not sure whether majmodpri is a useful feature, because I am not > convinced there is a real problem to be solved. What is a real case > of the problem, and is there another solution? > > But if we want such a facility, we should implement it right. The > right way is to insert these elements in the proper position the first > time. I think I am beeing a bit stupid here. I should have said before that the implementation in majmodpri.el is for the case that this feature is not included in Emacs. If it is included in Emacs it can be done much more simple. What majmodpri.el does is effectively that it implements a priority list beside the lists used by `normal-mode'. (And it makes this list customizable.) If we include this in Emacs I would suggest something similar to what I have used in mumamo in `mumamo-major-modes'. This is for a different purpose but the structure of the problem is sufficiently similar. That list is used for converting what I call major mode specifiers to major modes. Major modes are used when definiing multi major modes. An example is the major mode specifier for javascript. I call this javascript-mode. In mumamo-major-modes this is used as a key to find the major mode to use: (defcustom mumamo-major-modes '( (javascript-mode javascript-mode js2-fl-mode ecmascript-mode) (java-mode jde-mode java-mode) ) If a multi major mode has a major mode specifier for a chunk that is javascript-mode this will result in a lookup in this list and give the result (javascript-mode js2-fl-mode ecmasript-mode). These three are major modes ordered in priority order. If javascript-mode is available that will be used, else js2-fl-mode etc. A similar implementation can be used for major mode priorities for normal-mode. Then there is no need at all to change the lists normal-mode uses (but I have to do that in majmodpri.el because I can't change the way normal-mode behaves). ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-22 13:14 ` Lennart Borgman (gmail) ` (2 preceding siblings ...) 2008-09-23 4:40 ` Richard M. Stallman @ 2008-09-23 4:40 ` Richard M. Stallman 2008-09-23 9:57 ` Lennart Borgman (gmail) 3 siblings, 1 reply; 68+ messages in thread From: Richard M. Stallman @ 2008-09-23 4:40 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: monnier, emacs-devel 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. Imenu is much more complex than a typical minor mode. I think it would be useful to first look at simple cases such as Auto Fill mode. Does Auto Fill mode work ok with mumamo now? We should first look for a solution that enables Mumamo to DTRT automatically with most minor modes. If that is not possible, than let's look for way to make minor mode definitions specify the info that mumamo needs. Let's design this for maximum simplicity and cleanness of the minor mode definitions, rather than for maximum power and flexibility. I'd rather see a feature that does only what most minor modes need and is very simple. If Imenu needs something more complex, we could also have a second feature which is more complex and less clean, and Imenu could use that. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-23 4:40 ` Richard M. Stallman @ 2008-09-23 9:57 ` Lennart Borgman (gmail) 2008-09-23 16:03 ` Stefan Monnier 2008-09-23 19:47 ` Specifying mode in file variables trouble Richard M. Stallman 0 siblings, 2 replies; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-23 9:57 UTC (permalink / raw To: rms; +Cc: monnier, emacs-devel Richard M. Stallman wrote: > 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. > > Imenu is much more complex than a typical minor mode. I think it > would be useful to first look at simple cases such as Auto Fill mode. > Does Auto Fill mode work ok with mumamo now? > > We should first look for a solution that enables Mumamo to DTRT > automatically with most minor modes. > > If that is not possible, than let's look for way to make minor > mode definitions specify the info that mumamo needs. > > Let's design this for maximum simplicity and cleanness of the minor > mode definitions, rather than for maximum power and flexibility. > I'd rather see a feature that does only what most minor modes need > and is very simple. How about the solutin I sent with mumamo-save-buffer-locals and dito restore? I suggested something like this (mumamo-save-buffer-locals major-mode) (funcall new-major-mode) (mumamo-restore-buffer-locals new-major-mode) There is however a problem with this and the major mode hook. Things in this hook might want to change some buffer local variables. I think putting the restore part first in the mode solves some part of the problem. For this to work however delay-mode-hooks must be temporary set to nil (see the sources for `run-mode-hooks'). I have no idea what delayed-mode-hooks is used for so I do not know if setting delay-mode-hooks to nil may cause problems here. > If Imenu needs something more complex, we could also have a second > feature which is more complex and less clean, and Imenu could use > that. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-23 9:57 ` Lennart Borgman (gmail) @ 2008-09-23 16:03 ` Stefan Monnier 2008-09-23 17:22 ` Lennart Borgman (gmail) 2008-09-23 19:47 ` Specifying mode in file variables trouble Richard M. Stallman 1 sibling, 1 reply; 68+ messages in thread From: Stefan Monnier @ 2008-09-23 16:03 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: rms, emacs-devel > set to nil (see the sources for `run-mode-hooks'). I have no idea what > delayed-mode-hooks is used for so I do not know if setting It is used so that the parent mode hook is run at the end of the (child) major mode, so that the user's hook functions (placed on the parent hook) can take into account the variable values set by the child. Stefan ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-23 16:03 ` Stefan Monnier @ 2008-09-23 17:22 ` Lennart Borgman (gmail) 2008-09-23 20:33 ` Stefan Monnier 0 siblings, 1 reply; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-23 17:22 UTC (permalink / raw To: Stefan Monnier; +Cc: rms, emacs-devel Stefan Monnier wrote: >> set to nil (see the sources for `run-mode-hooks'). I have no idea what >> delayed-mode-hooks is used for so I do not know if setting > > It is used so that the parent mode hook is run at the end of the (child) > major mode, so that the user's hook functions (placed on the parent > hook) can take into account the variable values set by the child. Thanks. I might be beginning to understand. From what you wrote above and the somewhat scarse documentation I draw the conclusion that in normal case the child major modes mode hook is run before the parent major modes mode hook. So the order of running the hooks is childs local mode hook which also include running childs global hook (at the `t') parents' mode hooks If this is correct then I think that adding the call to mumamo-restore-most-buffer-locals first in the childs local mode hook would be the best. The values thus restored can then be changed by things coming later in the mode hooks. Since it looks like delay-mode-hook is something that we should not touch in case we are not the macro delay-mode-hook this is nothing we have to care about. So this is what I have got now: ;; Save local variables before switching major (mumamo-save-most-buffer-locals major-mode) ;; Restore local variables after switching, but do it in the mode ;; hook: (let ((mode-hook (intern-soft (concat (symbol-name major) "-hook"))) (restore-fun (lambda () (mumamo-restore-most-buffer-locals major)))) (when mode-hook ;; Put first in local hook to run it first: (add-hook mode-hook restore-fun nil t)) (funcall major) ;; <------- This is the major mode change (if (not mode-hook) (mumamo-restore-most-buffer-locals major) (remove-hook mode-hook restore-fun t))) ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-23 17:22 ` Lennart Borgman (gmail) @ 2008-09-23 20:33 ` Stefan Monnier 2008-09-23 20:48 ` Lennart Borgman (gmail) 0 siblings, 1 reply; 68+ messages in thread From: Stefan Monnier @ 2008-09-23 20:33 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: rms, emacs-devel > So the order of running the hooks is > childs local mode hook > which also include running childs global hook (at the `t') > parents' mode hooks No. Without the delay-mode-hooks thingy, the way it works is: <parent-mode code>; <parent-mode hook, which also includes global ones>; <child-mode code>; <child-mode hook, which also includes global ones>; while the delay-mode-hooks trick changes it to: <parent-mode code>; <child-mode code>; <parent-mode hook, which also includes global ones>; <child-mode hook, which also includes global ones>; > If this is correct then I think that adding the call to > mumamo-restore-most-buffer-locals first in the childs local mode hook > would be the best. It sounds like you want it first in the parent's mode hook. Stefan ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-23 20:33 ` Stefan Monnier @ 2008-09-23 20:48 ` Lennart Borgman (gmail) 2008-09-23 21:27 ` Stefan Monnier 0 siblings, 1 reply; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-23 20:48 UTC (permalink / raw To: Stefan Monnier; +Cc: rms, emacs-devel Stefan Monnier wrote: >> So the order of running the hooks is > >> childs local mode hook >> which also include running childs global hook (at the `t') >> parents' mode hooks > > No. Without the delay-mode-hooks thingy, the way it works is: > > <parent-mode code>; > <parent-mode hook, which also includes global ones>; > <child-mode code>; > <child-mode hook, which also includes global ones>; > > while the delay-mode-hooks trick changes it to: > > <parent-mode code>; > <child-mode code>; > <parent-mode hook, which also includes global ones>; > <child-mode hook, which also includes global ones>; Ehm. Yes, thanks. >> If this is correct then I think that adding the call to >> mumamo-restore-most-buffer-locals first in the childs local mode hook >> would be the best. > > It sounds like you want it first in the parent's mode hook. Yes, I think I fall for wishfull thinking there. That is some more lines to implement ;-) ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-23 20:48 ` Lennart Borgman (gmail) @ 2008-09-23 21:27 ` Stefan Monnier 2008-09-23 21:30 ` Lennart Borgman (gmail) 0 siblings, 1 reply; 68+ messages in thread From: Stefan Monnier @ 2008-09-23 21:27 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: rms, emacs-devel >> It sounds like you want it first in the parent's mode hook. > Yes, I think I fall for wishfull thinking there. > That is some more lines to implement ;-) If you can arrange for all the relevant modes to derive from some new `universal-parent-mode', then you just need to make it be first on `universal-parent-mode-hook'. Stefan ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-23 21:27 ` Stefan Monnier @ 2008-09-23 21:30 ` Lennart Borgman (gmail) 2008-09-24 20:57 ` Richard M. Stallman 0 siblings, 1 reply; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-23 21:30 UTC (permalink / raw To: Stefan Monnier; +Cc: rms, emacs-devel Stefan Monnier wrote: >>> It sounds like you want it first in the parent's mode hook. >> Yes, I think I fall for wishfull thinking there. >> That is some more lines to implement ;-) > > If you can arrange for all the relevant modes to derive from some new > `universal-parent-mode', then you just need to make it be first on > `universal-parent-mode-hook'. But I do not write most of the major modes. They come from all over the world ... I just implemented the code: ;; Save local variables before switching major (mumamo-save-most-buffer-locals major-mode) ;; Restore local variables after switching, but do it in the ;; greatest ancestor's mode hook (see `run-mode-hooks'): (let (ancestor-hook-sym parent-hook-sym (parent major-mode) (restore-fun (lambda () (mumamo-restore-most-buffer-locals major)))) ;; We want the greatest ancestor's mode hook: (setq parent-hook-sym (intern-soft (concat (symbol-name parent) "-hook"))) (when parent-hook-sym (setq ancestor-hook-sym parent-hook-sym)) (while (get parent 'derived-mode-parent) (setq parent (get parent 'derived-mode-parent)) (setq parent-hook-sym (intern-soft (concat (symbol-name parent) "-hook"))) (when parent-hook-sym (setq ancestor-hook-sym parent-hook-sym))) (when ancestor-hook-sym ;; Put first in local hook to run it first: (add-hook ancestor-hook-sym restore-fun nil t)) (funcall major) ;; <-------------- Change major mode here (if (not ancestor-hook-sym) (mumamo-restore-most-buffer-locals major) (remove-hook ancestor-hook-sym restore-fun t))) ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-23 21:30 ` Lennart Borgman (gmail) @ 2008-09-24 20:57 ` Richard M. Stallman 2008-09-24 21:29 ` Lennart Borgman (gmail) 0 siblings, 1 reply; 68+ messages in thread From: Richard M. Stallman @ 2008-09-24 20:57 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: monnier, emacs-devel But I do not write most of the major modes. They come from all over the world ... If we want all major modes to do something different, we can change the functions `kill-all-local-variables' and `run-hooks'. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-24 20:57 ` Richard M. Stallman @ 2008-09-24 21:29 ` Lennart Borgman (gmail) 2008-09-25 17:46 ` Richard M. Stallman 2008-09-25 17:46 ` Selecting mumamo modes Richard M. Stallman 0 siblings, 2 replies; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-24 21:29 UTC (permalink / raw To: rms; +Cc: monnier, emacs-devel Richard M. Stallman wrote: > But I do not write most of the major modes. They come from all over the > world ... > > If we want all major modes to do something different, we can change > the functions `kill-all-local-variables' and `run-hooks'. Yes, that could be a way, but I think we first have to think about how, when and which buffer local variables should survive moving between chunks with different major modes. I have thought about three different cases: - Buffer local variables that should never survive moving between chunks with different major modes. - Those that always should survive (but be killed when switching major modes when mumamo is not used). - Those that will be killed when moving to a chunk with a different major mode, but will be resurrected when point again reaches a chunk with the same major mode. (They are what I call "per major mode".) ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-24 21:29 ` Lennart Borgman (gmail) @ 2008-09-25 17:46 ` Richard M. Stallman 2008-09-25 21:34 ` Lennart Borgman (gmail) 2008-09-25 17:46 ` Selecting mumamo modes Richard M. Stallman 1 sibling, 1 reply; 68+ messages in thread From: Richard M. Stallman @ 2008-09-25 17:46 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: monnier, emacs-devel > If we want all major modes to do something different, we can change > the functions `kill-all-local-variables' and `run-hooks'. Yes, that could be a way, but I think we first have to think about how, when and which buffer local variables should survive moving between chunks with different major modes. Yes, exactly. Before proposing mechanisms, the first step is to look at what the cases are and see what behavior we want. I have thought about three different cases: - Buffer local variables that should never survive moving between chunks with different major modes. - Those that always should survive (but be killed when switching major modes when mumamo is not used). - Those that will be killed when moving to a chunk with a different major mode, but will be resurrected when point again reaches a chunk with the same major mode. (They are what I call "per major mode".) I agree that these three behaviors should suffice. (We also want variables that survive all changes in major mode, and that's what `permanent-local' does now.) Do we need all these behaviors? I doubt that the first behavior is needed, except for a few variables used specially in the implementation of mumamo. Mumamo can easily implement that behavior for those few variables. Can you find any other use cases for which the first behavior is needed? If not, let's forget it. I think the second and third behaviors are both useful. So the next step is to design conditions under which each one should happen. To do that, we need to see the _pattern_ of when each behavior is desired. So please collect use cases for them. Here's a proposal that came to me, suggested by what I know about use-case patterns. * 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. Can you find any use cases where this would not be right? ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-25 17:46 ` Richard M. Stallman @ 2008-09-25 21:34 ` Lennart Borgman (gmail) 2008-09-26 4:45 ` Richard M. Stallman 2008-09-26 4:45 ` Richard M. Stallman 0 siblings, 2 replies; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-25 21:34 UTC (permalink / raw To: rms; +Cc: monnier, emacs-devel Richard M. Stallman wrote: > I have thought about three different > cases: > > - Buffer local variables that should never survive moving between chunks > with different major modes. > > - Those that always should survive (but be killed when switching major > modes when mumamo is not used). > > - Those that will be killed when moving to a chunk with a different > major mode, but will be resurrected when point again reaches a chunk > with the same major mode. (They are what I call "per major mode".) > > I agree that these three behaviors should suffice. (We also want > variables that survive all changes in major mode, and that's what > `permanent-local' does now.) > > Do we need all these behaviors? > > I doubt that the first behavior is needed, except for a few variables > used specially in the implementation of mumamo. Mumamo can easily > implement that behavior for those few variables. Maybe it would be meaningful for a parser that is supporting completion in the chunk? > Can you find any other use cases for which the first behavior is needed? > If not, let's forget it. > > I think the second and third behaviors are both useful. So the next step > is to design conditions under which each one should happen. > > To do that, we need to see the _pattern_ of when each behavior is > desired. So please collect use cases for them. > > Here's a proposal that came to me, suggested by what I know about > use-case patterns. > > * 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? I think this is a good idea. This is what I have implemented now in the latest sources (and that I sent here). > * 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. > 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. But you may of course say instead that such cases should be handled by adding this to the major mode hook. --- 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. Maybe permanent-local could take the current buffer as a value for this level? ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-25 21:34 ` Lennart Borgman (gmail) @ 2008-09-26 4:45 ` Richard M. Stallman 2008-09-26 4:45 ` Richard M. Stallman 1 sibling, 0 replies; 68+ messages in thread From: Richard M. Stallman @ 2008-09-26 4:45 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: monnier, emacs-devel > - Buffer local variables that should never survive moving between chunks > with different major modes. > I doubt that the first behavior is needed, except for a few variables > used specially in the implementation of mumamo. Mumamo can easily > implement that behavior for those few variables. Maybe it would be meaningful for a parser that is supporting completion in the chunk? I don't understand what that means. Would you please be more specific? Anyway, it sounds like something very specialized and very closely related to mumamo. It would be easy enough to add a special feature to do this, if and when it is really wanted. Which means that, for now, we can forget about this. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-25 21:34 ` Lennart Borgman (gmail) 2008-09-26 4:45 ` Richard M. Stallman @ 2008-09-26 4:45 ` Richard M. Stallman 1 sibling, 0 replies; 68+ messages in thread From: Richard M. Stallman @ 2008-09-26 4:45 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: monnier, emacs-devel > * 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? ^ permalink raw reply [flat|nested] 68+ messages in thread
* Selecting mumamo modes 2008-09-24 21:29 ` Lennart Borgman (gmail) 2008-09-25 17:46 ` Richard M. Stallman @ 2008-09-25 17:46 ` Richard M. Stallman 2008-09-25 21:12 ` Lennart Borgman (gmail) 1 sibling, 1 reply; 68+ messages in thread From: Richard M. Stallman @ 2008-09-25 17:46 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: monnier, emacs-devel Here's an idea. Suppose that `normal-mode' sees that a file specifies a major mode of the form `A+B'. If there is no function `A+B-mode', it could create one using mumamo, based on `A-mode' and `B-mode', and then call it. That is safe because it only lets a file call `A-mode' and `B-mode', which files can already do individually. Naturally the feature should handle cases of more than two modes in a similar way. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Selecting mumamo modes 2008-09-25 17:46 ` Selecting mumamo modes Richard M. Stallman @ 2008-09-25 21:12 ` Lennart Borgman (gmail) 2008-09-26 4:45 ` Richard M. Stallman 0 siblings, 1 reply; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-25 21:12 UTC (permalink / raw To: rms; +Cc: monnier, emacs-devel Richard M. Stallman wrote: > Here's an idea. Suppose that `normal-mode' sees that a file specifies > a major mode of the form `A+B'. If there is no function `A+B-mode', > it could create one using mumamo, based on `A-mode' and `B-mode', and > then call it. Let me see if I understand how you think here ;-) The structural unit needed are those for defining the chunks. They must contain info like: a) B can contain A b) a chunk dividing function for B in A c) the major mode specifier A d) the major mode specifier B and maybe also e) order relative to other such structural units; for chunk dividing. If units like that are available then maybe something like you propose can be done, yes. But this is actually rather similar to what is done today in the defmacro define-mumamo-multi-major-mode, isn't it? I can still see that it may be useful, of course, but I do not find it necessary now. Internally I think the structure above will be needed to allow sub-chunks in sub-chunks. I am still in doubt about how to implement that however. * Some notes about sub-chunks in sub-chunks: I think the best way to do sub-chunks in sub-chunks will be to always do the chunk dividing from beginning of the file to the end of the file. (And we could also require that the information about the sub-chunk major mode should be in the beginning border.) I have been hesitating to implement this because it might take to long time if the user for example starts by jumping to the end of the file. A way to solve that problem is perhaps to first guess the chunk from the information at the buffer contents close to point and then just change the chunk if needed when the chunk dividing running from beginning of the file to the end has come to the chunk containing point. > That is safe because it only lets a file call `A-mode' and `B-mode', > which files can already do individually. > > Naturally the feature should handle cases of more than two modes in a > similar way. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Selecting mumamo modes 2008-09-25 21:12 ` Lennart Borgman (gmail) @ 2008-09-26 4:45 ` Richard M. Stallman 2008-10-21 19:20 ` Lennart Borgman (gmail) 0 siblings, 1 reply; 68+ messages in thread From: Richard M. Stallman @ 2008-09-26 4:45 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: monnier, emacs-devel > Here's an idea. Suppose that `normal-mode' sees that a file specifies > a major mode of the form `A+B'. If there is no function `A+B-mode', > it could create one using mumamo, based on `A-mode' and `B-mode', and > then call it. Let me see if I understand how you think here ;-) The structural unit needed are those for defining the chunks. They must contain info like: Are you saying that a list of major modes is not sufficient for defining the mumamo mode to combine them. If so, I guess my idea won't work. Oh well. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Selecting mumamo modes 2008-09-26 4:45 ` Richard M. Stallman @ 2008-10-21 19:20 ` Lennart Borgman (gmail) 0 siblings, 0 replies; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-10-21 19:20 UTC (permalink / raw To: rms; +Cc: monnier, emacs-devel Richard M. Stallman wrote: > > Here's an idea. Suppose that `normal-mode' sees that a file specifies > > a major mode of the form `A+B'. If there is no function `A+B-mode', > > it could create one using mumamo, based on `A-mode' and `B-mode', and > > then call it. > > Let me see if I understand how you think here ;-) > > The structural unit needed are those for defining the chunks. They must > contain info like: > > Are you saying that a list of major modes is not sufficient > for defining the mumamo mode to combine them. Yes. > If so, I guess my idea won't work. Oh well. > ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-23 9:57 ` Lennart Borgman (gmail) 2008-09-23 16:03 ` Stefan Monnier @ 2008-09-23 19:47 ` Richard M. Stallman 2008-09-23 20:26 ` Lennart Borgman (gmail) 1 sibling, 1 reply; 68+ messages in thread From: Richard M. Stallman @ 2008-09-23 19:47 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: monnier, emacs-devel How about the solutin I sent with mumamo-save-buffer-locals and dito restore? I suggested something like this That is a proposed _mechanism_. Another mechanism which might be to put properties on the variables that control minor modes. Or perhaps just on per-buffer minor modes (the ones that are not normally global). By scanning buffer-local-variables and checking for that property, you could find all the minor modes that are set in a given buffer. The mechanism is just part of this. We also need an interface. There are lots of minor mode definitions, and we want them to be simple and clean. So please propose a change in minor mode definitions so as to do the job. Then we can evaluate it and maybe propose better alternatives. I have no idea what delayed-mode-hooks is used for so I do not know if setting delay-mode-hooks to nil may cause problems here. Please read the doc of the macro `delay-mode-hooks' to learn what this does. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-23 19:47 ` Specifying mode in file variables trouble Richard M. Stallman @ 2008-09-23 20:26 ` Lennart Borgman (gmail) 2008-09-24 20:56 ` Richard M. Stallman 2008-09-24 20:57 ` Richard M. Stallman 0 siblings, 2 replies; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-23 20:26 UTC (permalink / raw To: rms; +Cc: monnier, emacs-devel Richard M. Stallman wrote: > How about the solutin I sent with mumamo-save-buffer-locals and dito > restore? I suggested something like this > > That is a proposed _mechanism_. Mm. Yes. It is clearly not the whole solution. > Another mechanism which might be to put properties on the variables > that control minor modes. Or perhaps just on per-buffer minor modes > (the ones that are not normally global). There are three main scopes (maybe there are more) for minor modes: - Global - Per buffer - Per major mode Global minor modes are not a problem here. I have suggested long ago using the existing mechanism for distinguishing between local variables that are per buffer and those that are per major mode. In other words: the minor modes that are per buffer should use (put 'PER-BUFFER-VARIABLE 'permanent-local t) on their buffer local variables. (I do that now in mumamo.el for some of the most important.) > By scanning buffer-local-variables and checking for that property, > you could find all the minor modes that are set in a given buffer. I believe I can see what you mean. It might however be better to do it the other way round: mark those buffer local variables that are not used by the type of minor modes we are talking about here. The advantage is of course that minor mode authors most often will not have to know about this. I have implemented such a list in mumamo.el now. This is the variable mumamo-buffer-locals-dont-set. > The mechanism is just part of this. We also need an interface. There > are lots of minor mode definitions, and we want them to be simple and > clean. > > So please propose a change in minor mode definitions so as to do the > job. Then we can evaluate it and maybe propose better alternatives. I think the suggestions above may be sufficient, but that might be just because of lack of imagination/knowledge of Emacs ;-) > I have no idea what > delayed-mode-hooks is used for so I do not know if setting > delay-mode-hooks to nil may cause problems here. > > Please read the doc of the macro `delay-mode-hooks' to learn what this > does. Thanks. I did that after Stefan's reply. I think the doc strings for delay-mode-hooks and the variable delayed-mode-hooks need a bit enhancements, at least pointers to the macro. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-23 20:26 ` Lennart Borgman (gmail) @ 2008-09-24 20:56 ` Richard M. Stallman 2008-09-24 21:21 ` Lennart Borgman (gmail) 2008-09-24 20:57 ` Richard M. Stallman 1 sibling, 1 reply; 68+ messages in thread From: Richard M. Stallman @ 2008-09-24 20:56 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: monnier, emacs-devel There are three main scopes (maybe there are more) for minor modes: - Global - Per buffer I think I know what those two mean. - Per major mode What does that mean? I don't know of that. Global minor modes are not a problem here. Usually they are not; but if a minor mode is itself global, you can make a buffer-local binding for the variable. Perhaps when you speak of "global" and "per buffer" you mean how the variable is bound, rather than how the mode normally works. I have suggested long ago using the existing mechanism for distinguishing between local variables that are per buffer and those that are per major mode. I don't understand that distinction, but I know that just about any variable in Emacs _can_ be given a buffer-local binding by a major mode command. So is the distinction meaningful? In other words: the minor modes that are per buffer should use (put 'PER-BUFFER-VARIABLE 'permanent-local t) on their buffer local variables. (I do that now in mumamo.el for some of the most important.) I am not sure that change is correct. When the variable is not marked as permanent-local, that could mean we want major mode commands to reset this minor mode. Of course, moving between chunks in mumamo should not reset it. Can you tell us some of the variables for which you added that property? Perhaps we want to have a different value for the `permanent-local' property that applies only to mumamo. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-24 20:56 ` Richard M. Stallman @ 2008-09-24 21:21 ` Lennart Borgman (gmail) 2008-09-25 17:46 ` Richard M. Stallman 0 siblings, 1 reply; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-24 21:21 UTC (permalink / raw To: rms; +Cc: monnier, emacs-devel Richard M. Stallman wrote: > There are three main scopes (maybe there are more) for minor modes: > > - Global > - Per buffer > > I think I know what those two mean. > > - Per major mode > > What does that mean? I don't know of that. I mean minor modes that are used with specific major modes. Or any minor mode that is turned on in a major mode hook. > Global minor modes are not a problem here. > > Usually they are not; but if a minor mode is itself global, > you can make a buffer-local binding for the variable. > > Perhaps when you speak of "global" and "per buffer" > you mean how the variable is bound, rather than how the mode > normally works. In this case, yes. > I have suggested long ago using the existing mechanism for > distinguishing between local variables that are per buffer and those > that are per major mode. > > I don't understand that distinction, but I know that just about any > variable in Emacs _can_ be given a buffer-local binding by a major > mode command. So is the distinction meaningful? I think so. For example flymake works on the file regardless of the major mode. If mumamo is used in the buffer then flymake should still work on the file - which is in a sense the same as the whole buffer here. > In other words: the minor modes that are per > buffer should use > > (put 'PER-BUFFER-VARIABLE 'permanent-local t) > > on their buffer local variables. (I do that now in mumamo.el for some of > the most important.) > > I am not sure that change is correct. When the variable is not marked > as permanent-local, that could mean we want major mode commands to > reset this minor mode. Of course, moving between chunks in mumamo > should not reset it. For cases like flymake we know that the minor mode is per buffer/file. I think that will be true for many parsers (but we will have to help them over "bad" chunks, ie chunks they do not expect to see). The same is also true for emulators like viper. For the cases above I think using (put 'PER-BUF-VAR 'permanent-local t) is the right thing. In other cases we can't do even if we want the minor modes (buffer local variables) to survive when point is moved to a new chunk. For that case I have implemented mumamo-survive, a list of variable symbols that should survive when moving between chunks. Of course that is a rather rough approximation. To refine it a bit I have now also added save/restore of buffer local variables per major modes (see earlier messages in this thread). > Can you tell us some of the variables for which you added that property? > > Perhaps we want to have a different value for the `permanent-local' property > that applies only to mumamo. Yes, perhaps. I think however we should first consider the structures above and see if they are enough. (Then we can maybe implement them using specific properties instead.) ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-24 21:21 ` Lennart Borgman (gmail) @ 2008-09-25 17:46 ` Richard M. Stallman 2008-09-25 21:36 ` Lennart Borgman (gmail) 0 siblings, 1 reply; 68+ messages in thread From: Richard M. Stallman @ 2008-09-25 17:46 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: monnier, emacs-devel I mean minor modes that are used with specific major modes. Can you cite some examples so I can see what that means? ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-25 17:46 ` Richard M. Stallman @ 2008-09-25 21:36 ` Lennart Borgman (gmail) 2008-09-26 4:45 ` Richard M. Stallman 0 siblings, 1 reply; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-25 21:36 UTC (permalink / raw To: rms; +Cc: monnier, emacs-devel Richard M. Stallman wrote: > I mean minor modes that are used with specific major modes. > > Can you cite some examples so I can see what that means? Ehm. I am not sure. I think people sometimes write such minor modes as enhancements to major mode. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-25 21:36 ` Lennart Borgman (gmail) @ 2008-09-26 4:45 ` Richard M. Stallman 0 siblings, 0 replies; 68+ messages in thread From: Richard M. Stallman @ 2008-09-26 4:45 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: monnier, emacs-devel Ehm. I am not sure. I think people sometimes write such minor modes as enhancements to major mode. I think there are such minormodes for C mode. Please take a look at them and see what behavior is right for them. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-23 20:26 ` Lennart Borgman (gmail) 2008-09-24 20:56 ` Richard M. Stallman @ 2008-09-24 20:57 ` Richard M. Stallman 2008-09-24 21:45 ` Lennart Borgman (gmail) 1 sibling, 1 reply; 68+ messages in thread From: Richard M. Stallman @ 2008-09-24 20:57 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: monnier, emacs-devel > The mechanism is just part of this. We also need an interface. There > are lots of minor mode definitions, and we want them to be simple and > clean. > > So please propose a change in minor mode definitions so as to do the > job. Then we can evaluate it and maybe propose better alternatives. I think the suggestions above may be sufficient, but that might be just because of lack of imagination/knowledge of Emacs ;-) Please show how you would change a few of the existing minor mode definitions to specify what to do here. ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-24 20:57 ` Richard M. Stallman @ 2008-09-24 21:45 ` Lennart Borgman (gmail) 0 siblings, 0 replies; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-24 21:45 UTC (permalink / raw To: rms; +Cc: monnier, emacs-devel Richard M. Stallman wrote: > > The mechanism is just part of this. We also need an interface. There > > are lots of minor mode definitions, and we want them to be simple and > > clean. > > > > So please propose a change in minor mode definitions so as to do the > > job. Then we can evaluate it and maybe propose better alternatives. > > I think the suggestions above may be sufficient, but that might be just > because of lack of imagination/knowledge of Emacs ;-) > > Please show how you would change a few of the existing minor mode definitions > to specify what to do here. Good question. I am however not sure about it. What I am trying to do is discuss the structures needed - though I sometimes gives them as implementation examples. The only thing I am quite sure about is that for what I call "per buffer variables" we can use (put 'PER-BUF-VAR 'permanent-local t). But when it comes to "per major modes" I am a bit confused. I just realize that I made a mistake in my last post. I have (implicitly) spoken about two different types of "per major modes" variables; those that are reset every time a major mode function is called and those that should be resurrected when point comes to a major mode with the same major mode. I have tried to make this distinction because the user may want to set some buffer local variable for a major mode even in mumamo. I am not sure this is a good distinction however. I can see two ways to resolve it: either say that all such variables should be set in major mode hooks. Or just resurrect all buffer local variables (with some necessary exceptions) when arriving to a chunk with the same major mode. If switching to a new major mode just where setting some local variables this could be used instead of calling the major mode function when moving between chunks (after the major mode has been called once in the buffer and the buffer local values have been saved), but it is not clear to me whether this would work. What do you think? ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-20 0:44 Specifying mode in file variables trouble Lennart Borgman (gmail) 2008-09-20 0:48 ` Lennart Borgman (gmail) 2008-09-20 0:59 ` Miles Bader @ 2008-09-20 19:03 ` Stefan Monnier 2008-09-20 23:34 ` Lennart Borgman (gmail) 2 siblings, 1 reply; 68+ messages in thread From: Stefan Monnier @ 2008-09-20 19:03 UTC (permalink / raw To: Lennart Borgman (gmail); +Cc: Emacs Devel > In other words: Emacs adds "-mode". That is frustrating, but can of > course not be changed. However if Emacs finds that this fails, can it > then check for just the given "symbol"? That'd be a security hole, since opening some random file might then call any arbitrary function. Stefan ^ permalink raw reply [flat|nested] 68+ messages in thread
* Re: Specifying mode in file variables trouble 2008-09-20 19:03 ` Stefan Monnier @ 2008-09-20 23:34 ` Lennart Borgman (gmail) 0 siblings, 0 replies; 68+ messages in thread From: Lennart Borgman (gmail) @ 2008-09-20 23:34 UTC (permalink / raw To: Stefan Monnier; +Cc: Emacs Devel Stefan Monnier wrote: >> In other words: Emacs adds "-mode". That is frustrating, but can of >> course not be changed. However if Emacs finds that this fails, can it >> then check for just the given "symbol"? > > That'd be a security hole, since opening some random file might then > call any arbitrary function. Hm. Good point. I guess there is nothing to do about it then. ^ permalink raw reply [flat|nested] 68+ messages in thread
end of thread, other threads:[~2008-10-22 6:21 UTC | newest] Thread overview: 68+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-09-20 0:44 Specifying mode in file variables trouble Lennart Borgman (gmail) 2008-09-20 0:48 ` Lennart Borgman (gmail) 2008-09-20 0:59 ` Miles Bader 2008-09-20 1:06 ` Lennart Borgman (gmail) 2008-09-21 6:32 ` Richard M. Stallman 2008-09-21 12:33 ` Lennart Borgman (gmail) 2008-09-21 23:34 ` Richard M. Stallman 2008-09-22 0:38 ` Lennart Borgman (gmail) 2008-09-22 4:39 ` Richard M. Stallman 2008-09-22 13:14 ` Lennart Borgman (gmail) 2008-09-22 14:12 ` Stefan Monnier 2008-09-22 14:26 ` Lennart Borgman (gmail) 2008-09-23 4:40 ` Richard M. Stallman 2008-09-23 9:29 ` Lennart Borgman (gmail) 2008-09-23 19:47 ` Richard M. Stallman 2008-09-22 23:11 ` Lennart Borgman (gmail) 2008-09-23 4:40 ` Richard M. Stallman 2008-09-23 9:47 ` Lennart Borgman (gmail) 2008-09-23 19:47 ` Richard M. Stallman 2008-09-23 20:43 ` Lennart Borgman (gmail) 2008-09-24 13:47 ` Richard M. Stallman 2008-09-24 13:47 ` Richard M. Stallman 2008-09-24 17:21 ` Lennart Borgman (gmail) 2008-09-25 5:49 ` Richard M. Stallman 2008-09-25 6:28 ` tomas 2008-09-25 6:41 ` Paul R 2008-09-25 7:55 ` tomas 2008-09-25 8:35 ` Paul R 2008-09-25 16:42 ` Lennart Borgman 2008-09-27 4:39 ` Richard M. Stallman 2008-10-21 19:16 ` Lennart Borgman (gmail) 2008-10-22 5:21 ` tomas 2008-10-22 6:21 ` Richard M. Stallman 2008-09-23 19:47 ` Richard M. Stallman 2008-09-23 20:37 ` Lennart Borgman (gmail) 2008-09-24 13:47 ` Richard M. Stallman 2008-09-24 16:23 ` Lennart Borgman (gmail) 2008-09-25 5:50 ` Richard M. Stallman 2008-09-24 23:09 ` Lennart Borgman (gmail) 2008-09-23 4:40 ` Richard M. Stallman 2008-09-23 9:57 ` Lennart Borgman (gmail) 2008-09-23 16:03 ` Stefan Monnier 2008-09-23 17:22 ` Lennart Borgman (gmail) 2008-09-23 20:33 ` Stefan Monnier 2008-09-23 20:48 ` Lennart Borgman (gmail) 2008-09-23 21:27 ` Stefan Monnier 2008-09-23 21:30 ` Lennart Borgman (gmail) 2008-09-24 20:57 ` Richard M. Stallman 2008-09-24 21:29 ` Lennart Borgman (gmail) 2008-09-25 17:46 ` Richard M. Stallman 2008-09-25 21:34 ` Lennart Borgman (gmail) 2008-09-26 4:45 ` Richard M. Stallman 2008-09-26 4:45 ` Richard M. Stallman 2008-09-25 17:46 ` Selecting mumamo modes Richard M. Stallman 2008-09-25 21:12 ` Lennart Borgman (gmail) 2008-09-26 4:45 ` Richard M. Stallman 2008-10-21 19:20 ` Lennart Borgman (gmail) 2008-09-23 19:47 ` Specifying mode in file variables trouble Richard M. Stallman 2008-09-23 20:26 ` Lennart Borgman (gmail) 2008-09-24 20:56 ` Richard M. Stallman 2008-09-24 21:21 ` Lennart Borgman (gmail) 2008-09-25 17:46 ` Richard M. Stallman 2008-09-25 21:36 ` Lennart Borgman (gmail) 2008-09-26 4:45 ` Richard M. Stallman 2008-09-24 20:57 ` Richard M. Stallman 2008-09-24 21:45 ` Lennart Borgman (gmail) 2008-09-20 19:03 ` Stefan Monnier 2008-09-20 23:34 ` Lennart Borgman (gmail)
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.