Multiple Major Modes

Multiple Major Modes

[Nordlöw]

Has anyone used any of the MultipleModes (http://www.emacswiki.org/cgi-
bin/wiki/MultipleModes), for example mumamo and mmm-mode, for mixing
text/outline/muse/org-mode (or similar note) with programming modes?

If not can I reuse any code for this purpose; For example what kinds
of prefixes/tags does mumamo react on?


Thanks in advance,
Nordlöw

Re: Multiple Major Modes

[Lennart Borgman (gmail)]

Nordlöw wrote:
> Has anyone used any of the MultipleModes (http://www.emacswiki.org/cgi-
> bin/wiki/MultipleModes), for example mumamo and mmm-mode, for mixing
> text/outline/muse/org-mode (or similar note) with programming modes?
> 
> If not can I reuse any code for this purpose; For example what kinds
> of prefixes/tags does mumamo react on?


Look in mumamo-fun.el to find out how to do it.

Re: Multiple Major Modes

[William Xu]

Nordlöw <per.nordlow@gmail.com> writes:

> Has anyone used any of the MultipleModes (http://www.emacswiki.org/cgi-
> bin/wiki/MultipleModes), for example mumamo and mmm-mode, for mixing
> text/outline/muse/org-mode (or similar note) with programming modes?

I'm using mmm-mode for text-mode embedded with html-mode, works fairly
well.  

-- 
William

http://williamxu.net9.org

There is a time in the tides of men,
Which, taken at its flood, leads on to success.
On the other hand, don't count on it.
- T. K. Lawson

Multiple Major Modes

[Nordlöw]

Does anyone though of an extension the enables a major-mode to exist
only within a part of buffer along with another major-mode. Part is
preferrably delimited by some magic strings.

Thanks in advance,
Nordlöw

Re: Multiple Major Modes

[Pascal J. Bourguignon]

Nordlöw <per.nordlow@gmail.com> writes:

> Does anyone though of an extension the enables a major-mode to exist
> only within a part of buffer along with another major-mode. Part is
> preferrably delimited by some magic strings.

mmm-mode

-- 
__Pascal Bourguignon__

Re: Multiple Major Modes

[Joost Kremers]

Nordlöw wrote:
> Does anyone though of an extension the enables a major-mode to exist
> only within a part of buffer along with another major-mode. Part is
> preferrably delimited by some magic strings.

http://www.emacswiki.org/emacs/MultipleModes


-- 
Joost Kremers                                      joostkremers@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

Re: Multiple Major Modes

[Lennart Borgman]

On Thu, Oct 29, 2009 at 9:04 PM, Joost Kremers <joostkremers@yahoo.com> wrote:
> Nordlöw wrote:
>> Does anyone though of an extension the enables a major-mode to exist
>> only within a part of buffer along with another major-mode. Part is
>> preferrably delimited by some magic strings.
>
> http://www.emacswiki.org/emacs/MultipleModes

Pascal and Bastien, you recommended mmm-mode that is one of the
alternatives on that list. I have for a long time wondered if it works
with Emacs 22/23. Are you using it?

Are there any features in it that you believe are missing in mumamo?

Re: Multiple Major Modes

[Pascal J. Bourguignon]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Thu, Oct 29, 2009 at 9:04 PM, Joost Kremers <joostkremers@yahoo.com> wrote:
>> Nordlöw wrote:
>>> Does anyone though of an extension the enables a major-mode to exist
>>> only within a part of buffer along with another major-mode. Part is
>>> preferrably delimited by some magic strings.
>>
>> http://www.emacswiki.org/emacs/MultipleModes
>
> Pascal and Bastien, you recommended mmm-mode that is one of the
> alternatives on that list. I have for a long time wondered if it works
> with Emacs 22/23. Are you using it?
>
> Are there any features in it that you believe are missing in mumamo?

I don't use any multimode mode.  I suggested mmm-mode because it comes
with standard emacs (22.3) installations.

-- 
__Pascal Bourguignon__

Re: Multiple Major Modes

[Lennart Borgman]

On Fri, Oct 30, 2009 at 12:03 AM, Pascal J. Bourguignon
<pjb@informatimago.com> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> On Thu, Oct 29, 2009 at 9:04 PM, Joost Kremers <joostkremers@yahoo.com> wrote:
>>> Nordlöw wrote:
>>>> Does anyone though of an extension the enables a major-mode to exist
>>>> only within a part of buffer along with another major-mode. Part is
>>>> preferrably delimited by some magic strings.
>>>
>>> http://www.emacswiki.org/emacs/MultipleModes
>>
>> Pascal and Bastien, you recommended mmm-mode that is one of the
>> alternatives on that list. I have for a long time wondered if it works
>> with Emacs 22/23. Are you using it?
>>
>> Are there any features in it that you believe are missing in mumamo?
>
> I don't use any multimode mode.  I suggested mmm-mode because it comes
> with standard emacs (22.3) installations.


Thanks for the clarification.

What standard installations of emacs 22.3 does it come with? mmm-mode
is not part of emacs itself (nor is any other multi major mode
framework).

Re: Multiple Major Modes

[Pascal J. Bourguignon]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Fri, Oct 30, 2009 at 12:03 AM, Pascal J. Bourguignon
> <pjb@informatimago.com> wrote:
>> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>
>>> On Thu, Oct 29, 2009 at 9:04 PM, Joost Kremers <joostkremers@yahoo.com> wrote:
>>>> Nordlöw wrote:
>>>>> Does anyone though of an extension the enables a major-mode to exist
>>>>> only within a part of buffer along with another major-mode. Part is
>>>>> preferrably delimited by some magic strings.
>>>>
>>>> http://www.emacswiki.org/emacs/MultipleModes
>>>
>>> Pascal and Bastien, you recommended mmm-mode that is one of the
>>> alternatives on that list. I have for a long time wondered if it works
>>> with Emacs 22/23. Are you using it?
>>>
>>> Are there any features in it that you believe are missing in mumamo?
>>
>> I don't use any multimode mode.  I suggested mmm-mode because it comes
>> with standard emacs (22.3) installations.
>
>
> Thanks for the clarification.
>
> What standard installations of emacs 22.3 does it come with? mmm-mode
> is not part of emacs itself (nor is any other multi major mode
> framework).

Indeed. Sorry for the confusion.  
mmm-mode is installed as a gentoo package.
gentoo doesn't seem to provide the mumamo package.


-- 
__Pascal Bourguignon__

Re: Multiple Major Modes

[Joseph Brenner]

Lennart Borgman <lennart.borgman@gmail.com> writes:
> Joost Kremers <joostkremers@yahoo.com> wrote:
>> Nordlöw wrote:
>>> Does anyone though of an extension the enables a major-mode to exist
>>> only within a part of buffer along with another major-mode. Part is
>>> preferrably delimited by some magic strings.
>>
>> http://www.emacswiki.org/emacs/MultipleModes
>
> Pascal and Bastien, you recommended mmm-mode that is one of the
> alternatives on that list. I have for a long time wondered if it works
> with Emacs 22/23. Are you using it?

I use mmm-mode sometimes.  It works pretty well for Mason files (perl
code embedded in html-like coding), which is what it was originally
designed for.  I believe it's the oldest and probably most mature
multi-mode package.

> Are there any features in it that you believe are missing in mumamo?

I don't know anything about mumamo: mmm-mode works well enough that I've 
never seen any need to try any of the other ways.  

Re: Multiple Major Modes

[Dave Love]

Nordlöw <per.nordlow@gmail.com> writes:

> Does anyone though of an extension the enables a major-mode to exist
> only within a part of buffer along with another major-mode. Part is
> preferrably delimited by some magic strings.

I think you want more flexibility for delimiting mode chunks in general.

<URL:http://www.loveshack.ukfsn.org/emacs/multi-mode.el> implements
roughly what we intended by the Emacs TODO item on the topic many years
ago (if it's still there).

I'm rather baffled by this nxhtml thing referred to, and its complexity.
It claims to be trying to solve a problem that the indirect buffer
approach doesn't have.  Can someone explain why?

Doing this sort of thing properly really needs support from Emacs, which
was originally meant to be added as necessary.

Re: Multiple Major Modes

[Lennart Borgman]

On Fri, Oct 30, 2009 at 4:28 AM, Joseph Brenner <doom@kzsu.stanford.edu> wrote:
>
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>> Joost Kremers <joostkremers@yahoo.com> wrote:
>>> Nordlöw wrote:
>>>> Does anyone though of an extension the enables a major-mode to exist
>>>> only within a part of buffer along with another major-mode. Part is
>>>> preferrably delimited by some magic strings.
>>>
>>> http://www.emacswiki.org/emacs/MultipleModes
>>
>> Pascal and Bastien, you recommended mmm-mode that is one of the
>> alternatives on that list. I have for a long time wondered if it works
>> with Emacs 22/23. Are you using it?
>
> I use mmm-mode sometimes.  It works pretty well for Mason files (perl
> code embedded in html-like coding), which is what it was originally
> designed for.  I believe it's the oldest and probably most mature
> multi-mode package.
>
>> Are there any features in it that you believe are missing in mumamo?
>
> I don't know anything about mumamo: mmm-mode works well enough that I've
> never seen any need to try any of the other ways.


Thanks for the answer Joseph. I just added some support for Mason
files to mumamo. It is not perfect (surprise! and there is an
indentation bug currently - those are very resistent to treatment),
but I would be glad if you or someone else that have been using
mmm-mode tested it and gave some feedback.

If you want to help with this then download the latest beta of nXhtml here:

  http://ourcomments.org/Emacs/DL/elisp/nxhtml/beta/

That is a zip file which you set up by simply adding one line to .emacs, see

  http://ourcomments.org/Emacs/nXhtml/doc/nxhtml.html#qg

When you are in a Mason file turn do

  M-x mason-html-mumamo-mode

to test it. (BTW, what file extensions do Mason files normally have?)

Re: Multiple Major Modes

[Lennart Borgman]

On Sun, Nov 1, 2009 at 10:24 PM, Dave Love <fx@domain.invalid> wrote:
>
> I'm rather baffled by this nxhtml thing referred to, and its complexity.
> It claims to be trying to solve a problem that the indirect buffer
> approach doesn't have.  Can someone explain why?


Hi Dave,

I guess you mean the complexity of MuMaMo, which is a part of nXhtml?
nXhtml contains much more.

I you have asked some years ago about the indirect buffer thing I
could have answered it quickly, but I have forgotten all details about
why I abondoned that approach. (It was the first approach I tried.) I
am not sure whether to use indirect buffers for just fontification is
useful. It does create problems for other elisp code since they might
be interested in the actual buffer used. Please notice that some minor
modes for example work for a whole buffer and some just within a major
mode. So some buffer local variables should be preserved across chunks
while others should not. (That problem is quite hard to solve with the
current limitations of Emacs though. I have made some suggestions (in
private messages) for how to solve it but they require low level
changes in Emacs and it is quite hard to figure out exactly what is
needed.)


I really think some simplifications can be made to mumamo.el, but
maybe not as much as one might expect without looking closer at the
problems it tries to solve. Some of the complexity comes from my bad
understanding of complex parts of Emacs from the beginning so there
are some left-over code. It should of course be removed later. The
code in mumamo.el is not always pretty and should be simplified in
many cases. It is however hard to do since complicated cases easily
breaks. I have tried to write some unit tests to simplify the
rewriting work.

On the other hand most of the complexity comes from the problems that
mumamo.el tries to solve. Caching of chunk information and state
information is for example essential. You have a comment in
multi-mode.el that it would be hard to implement chunks in chunks if
chunk information was cached. It is rather the opposite since you have
to search the file from the beginning to get chunks right and that is
especially important for chunks in chunks. I did not realize the full
impact of this from the beginning and I have had to rewrite much of
the chunk dividing code because of this. (And there is still
unnecessary complexity from my rather worthless attempts trying to
make chunk dividing stable without always finding them from the start
of the file.)


Looking at the bug database in Launchpad for nXhtml (and also the old
bugs stored on EmacsWiki) will perhaps make it more clear what the
complexity in mumamo.el is about.

I have tried to avoid discussing the complexities with multi major
modes on Emacs devel since it would take too much time and space. I
have tried to do that in some private messages instead. If you are
interested I could send you some of my suggestions.


I would very much prefer merging different approaches to multi major
modes. It is actually very complex (though on the surface it does not
seem so). Having several approaches will waste a lot of time. On the
other hand forgetting good ideas will also do that. Suggestions for
simplifications of mumamo.el are very welcome.



> Doing this sort of thing properly really needs support from Emacs, which
> was originally meant to be added as necessary.


Yes, but it is hard to find out what support is needed without
actually trying to solve the problems first.

Re: Multiple Major Modes

[Richard Riley]

Dave Love <fx@domain.invalid> writes:

> Nordlöw <per.nordlow@gmail.com> writes:
>
>> Does anyone though of an extension the enables a major-mode to exist
>> only within a part of buffer along with another major-mode. Part is
>> preferrably delimited by some magic strings.
>
> I think you want more flexibility for delimiting mode chunks in general.
>
> <URL:http://www.loveshack.ukfsn.org/emacs/multi-mode.el> implements
> roughly what we intended by the Emacs TODO item on the topic many years
> ago (if it's still there).
>
> I'm rather baffled by this nxhtml thing referred to, and its complexity.
> It claims to be trying to solve a problem that the indirect buffer
> approach doesn't have.  Can someone explain why?
>
> Doing this sort of thing properly really needs support from Emacs, which
> was originally meant to be added as necessary.
>

I just tried multi-mode. Very fast and clean. Can it also fontify in the
php sections or am I missing something?

,----
| (require 'html-php)
| (add-to-list 'auto-mode-alist '("\\.php\\'" . html-php-mode)) 
-- 

Re: Multiple Major Modes

[Lennart Borgman]

On Mon, Nov 2, 2009 at 3:01 PM, Richard Riley <rileyrgdev@gmail.com> wrote:
> Dave Love <fx@domain.invalid> writes:
>
>> Nordlöw <per.nordlow@gmail.com> writes:
>>
>>> Does anyone though of an extension the enables a major-mode to exist
>>> only within a part of buffer along with another major-mode. Part is
>>> preferrably delimited by some magic strings.
>>
>> I think you want more flexibility for delimiting mode chunks in general.
>>
>> <URL:http://www.loveshack.ukfsn.org/emacs/multi-mode.el> implements
>> roughly what we intended by the Emacs TODO item on the topic many years
>> ago (if it's still there).
>>
>> I'm rather baffled by this nxhtml thing referred to, and its complexity.
>> It claims to be trying to solve a problem that the indirect buffer
>> approach doesn't have.  Can someone explain why?
>>
>> Doing this sort of thing properly really needs support from Emacs, which
>> was originally meant to be added as necessary.
>>
>
> I just tried multi-mode. Very fast and clean. Can it also fontify in the
> php sections or am I missing something?


Yes, it does. (It is just a bug at startup of it, press some key.)

Re: Multiple Major Modes

[Richard Riley]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Mon, Nov 2, 2009 at 3:01 PM, Richard Riley <rileyrgdev@gmail.com> wrote:
>> Dave Love <fx@domain.invalid> writes:
>>
>>> Nordlöw <per.nordlow@gmail.com> writes:
>>>
>>>> Does anyone though of an extension the enables a major-mode to exist
>>>> only within a part of buffer along with another major-mode. Part is
>>>> preferrably delimited by some magic strings.
>>>
>>> I think you want more flexibility for delimiting mode chunks in general.
>>>
>>> <URL:http://www.loveshack.ukfsn.org/emacs/multi-mode.el> implements
>>> roughly what we intended by the Emacs TODO item on the topic many years
>>> ago (if it's still there).
>>>
>>> I'm rather baffled by this nxhtml thing referred to, and its complexity.
>>> It claims to be trying to solve a problem that the indirect buffer
>>> approach doesn't have.  Can someone explain why?
>>>
>>> Doing this sort of thing properly really needs support from Emacs, which
>>> was originally meant to be added as necessary.
>>>
>>
>> I just tried multi-mode. Very fast and clean. Can it also fontify in the
>> php sections or am I missing something?
>
> Yes, it does. (It is just a bug at startup of it, press some key.)
>

Yes, it also depends if the first line of the php is on the same line as the
<?php tag or not.

flyspell is causing me some grief with it too and am trying to narrow
down why.

 

Re: Multiple Major Modes

[Richard Riley]

Richard Riley <rileyrgdev@gmail.com> writes:

> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> On Mon, Nov 2, 2009 at 3:01 PM, Richard Riley <rileyrgdev@gmail.com> wrote:
>>> Dave Love <fx@domain.invalid> writes:
>>>
>>>> Nordlöw <per.nordlow@gmail.com> writes:
>>>>
>>>>> Does anyone though of an extension the enables a major-mode to exist
>>>>> only within a part of buffer along with another major-mode. Part is
>>>>> preferrably delimited by some magic strings.
>>>>
>>>> I think you want more flexibility for delimiting mode chunks in general.
>>>>
>>>> <URL:http://www.loveshack.ukfsn.org/emacs/multi-mode.el> implements
>>>> roughly what we intended by the Emacs TODO item on the topic many years
>>>> ago (if it's still there).
>>>>
>>>> I'm rather baffled by this nxhtml thing referred to, and its complexity.
>>>> It claims to be trying to solve a problem that the indirect buffer
>>>> approach doesn't have.  Can someone explain why?
>>>>
>>>> Doing this sort of thing properly really needs support from Emacs, which
>>>> was originally meant to be added as necessary.
>>>>
>>>
>>> I just tried multi-mode. Very fast and clean. Can it also fontify in the
>>> php sections or am I missing something?
>>
>> Yes, it does. (It is just a bug at startup of it, press some key.)
>>
>
> Yes, it also depends if the first line of the php is on the same line as the
> <?php tag or not.
>
> flyspell is causing me some grief with it too and am trying to narrow
> down why.
>

With regards to the fontification (and multi-mode) in general it doesn't
work too well in conjunction with saveplace.el : if the cursor is
located inside a php block when you open the file then moving outside of
the block does not trigger xhtml mode again.

 

Re: Multiple Major Modes

[Richard Riley]

Richard Riley <rileyrgdev@gmail.com> writes:

> Dave Love <fx@domain.invalid> writes:
>
>> Nordlöw <per.nordlow@gmail.com> writes:
>>
>>> Does anyone though of an extension the enables a major-mode to exist
>>> only within a part of buffer along with another major-mode. Part is
>>> preferrably delimited by some magic strings.
>>
>> I think you want more flexibility for delimiting mode chunks in general.
>>
>> <URL:http://www.loveshack.ukfsn.org/emacs/multi-mode.el> implements
>> roughly what we intended by the Emacs TODO item on the topic many years
>> ago (if it's still there).
>>
>> I'm rather baffled by this nxhtml thing referred to, and its complexity.
>> It claims to be trying to solve a problem that the indirect buffer
>> approach doesn't have.  Can someone explain why?
>>
>> Doing this sort of thing properly really needs support from Emacs, which
>> was originally meant to be added as necessary.
>>
>
> I just tried multi-mode. Very fast and clean. Can it also fontify in the
> php sections or am I missing something?
>
> ,----
> | (require 'html-php)
> | (add-to-list 'auto-mode-alist '("\\.php\\'" . html-php-mode)) 

What php-mode is recommended for use with multi-mode?

The one I had adds php-mode to the front of the auto-mode-alist for
pho'like extensions meaning all subsequent php file opens put them into
php-mode and not html-php-mode.

Re: Multiple Major Modes

[Joseph Brenner]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> Joseph Brenner <doom@kzsu.stanford.edu> wrote:

>> I don't know anything about mumamo: mmm-mode works well enough that I've
>> never seen any need to try any of the other ways.

Actually, mmm-mode seems to have a lot of problems with cvs emacs
these days.  I was asking Alan Shutko about it, and he offered to
make me the maintainer... I can't see taking on the job myself just
now though (I know nothing about "overlays" except what it says in
the elisp reference manual).

> Thanks for the answer Joseph. I just added some support for Mason
> files to mumamo. It is not perfect (surprise! and there is an
> indentation bug currently - those are very resistent to treatment),

[...]

> When you are in a Mason file turn do
>
>   M-x mason-html-mumamo-mode

I've tried this, and I'm seeing syntax coloring in the HTML sections, but
none in the perl sections.  Is that about what you expected?

> to test it. (BTW, what file extensions do Mason files normally have?)

The currently recommended Mason file extensions are *.mhtml for internal
components, and *.html for external ones:

  http://www.masonhq.com/?FAQ:ServerConfiguration#h-what_filename_extensions_should_i_use_for_mason_components_

That means, of course that the file extension alone gives you no way to
distinguish between a plain html file and a top-level Mason file.

Also there are other, older conventions: I've seen *.mc and *.mas in use
(*.mas was used in the O'Reilly book on Mason).

Re: Multiple Major Modes

[Lennart Borgman]

On Fri, Dec 11, 2009 at 7:19 AM, Joseph Brenner <doom@kzsu.stanford.edu> wrote:
>
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> Thanks for the answer Joseph. I just added some support for Mason
>> files to mumamo. It is not perfect (surprise! and there is an
>> indentation bug currently - those are very resistent to treatment),
>
> [...]
>
>> When you are in a Mason file turn do
>>
>>   M-x mason-html-mumamo-mode
>
> I've tried this, and I'm seeing syntax coloring in the HTML sections, but
> none in the perl sections.  Is that about what you expected?


I always expect some unexpected problems ... ;-)

But, no, it should of course do syntax coloring etc in the perl
sections too. Maybe I have misunderstood something. Can you give me an
example, please?


>> to test it. (BTW, what file extensions do Mason files normally have?)
>
> The currently recommended Mason file extensions are *.mhtml for internal
> components, and *.html for external ones:
>
>  http://www.masonhq.com/?FAQ:ServerConfiguration#h-what_filename_extensions_should_i_use_for_mason_components_
>
> That means, of course that the file extension alone gives you no way to
> distinguish between a plain html file and a top-level Mason file.


Thanks. I am a bit surprised by the second convention.


> Also there are other, older conventions: I've seen *.mc and *.mas in use
> (*.mas was used in the O'Reilly book on Mason).

Re: Multiple Major Modes

[Joe Brenner]

Lennart Borgman <lennart.borgman@gmail.com> wrote:

> On Fri, Dec 11, 2009 at 7:19 AM, Joseph Brenner <doom@kzsu.stanford.edu> wrote:
> >
> > Lennart Borgman <lennart.borgman@gmail.com> writes:
> >
> >> Thanks for the answer Joseph. I just added some support for Mason
> >> files to mumamo. It is not perfect (surprise! and there is an
> >> indentation bug currently - those are very resistent to treatment),
> >
> > [...]
> >
> >> When you are in a Mason file turn do
> >>
> >>   M-x mason-html-mumamo-mode
> >
> > I've tried this, and I'm seeing syntax coloring in the HTML sections, but
> > none in the perl sections.  Is that about what you expected?
>
>
> I always expect some unexpected problems ... ;-)
>
> But, no, it should of course do syntax coloring etc in the perl
> sections too. Maybe I have misunderstood something. Can you give me an
> example, please?

I tried to reproduce it to take a screen shot, but now it's working okay
for me.  Previously I was seeing a perl section in two-tone, with just
the html areas colorized.

So this is a problem that only comes up after my emacs has been running
for awhile (some of my other mumamo experiments have been locking up
emacs, so I've had to do more fresh restarts than I normally would...).

> >> to test it. (BTW, what file extensions do Mason files normally have?)
> >
> > The currently recommended Mason file extensions are *.mhtml for internal
> > components, and *.html for external ones:
> >
> >  http://www.masonhq.com/?FAQ:ServerConfiguration#h-what_filename_extensions_should_i_use_for_mason_components_
> >
> > That means, of course that the file extension alone gives you no way to
> > distinguish between a plain html file and a top-level Mason file.
>
> Thanks. I am a bit surprised by the second convention.

The reasoning seems to be that the client is asking for html, and that's
what you're going to deliver to them... the fact that Mason is used to
generate the html is an internal detail there's no point in bothering
them with.

Re: Multiple Major Modes

[Lennart Borgman]

On Fri, Dec 11, 2009 at 10:57 PM, Joe Brenner <doom@kzsu.stanford.edu> wrote:
>> >
>> > I've tried this, and I'm seeing syntax coloring in the HTML sections, but
>> > none in the perl sections.  Is that about what you expected?
>>
>>
>> I always expect some unexpected problems ... ;-)
>>
>> But, no, it should of course do syntax coloring etc in the perl
>> sections too. Maybe I have misunderstood something. Can you give me an
>> example, please?
>
> I tried to reproduce it to take a screen shot, but now it's working okay
> for me.  Previously I was seeing a perl section in two-tone, with just
> the html areas colorized.
>
> So this is a problem that only comes up after my emacs has been running
> for awhile (some of my other mumamo experiments have been locking up
> emacs, so I've had to do more fresh restarts than I normally would...).


This can happen if some bug in mumamo is hit. Normally you can get it
working again by just calling the multi major mode again.

However when this happens I would be glad for a bug report. Those bugs
are a bit hard to find so any report may help. Please look in the
message buffer and see if there is any information and then report it
as an nXhtml bug.


>> >> to test it. (BTW, what file extensions do Mason files normally have?)
>> >
>> > The currently recommended Mason file extensions are *.mhtml for internal
>> > components, and *.html for external ones:
>> >
>> >  http://www.masonhq.com/?FAQ:ServerConfiguration#h-what_filename_extensions_should_i_use_for_mason_components_
>> >
>> > That means, of course that the file extension alone gives you no way to
>> > distinguish between a plain html file and a top-level Mason file.
>>
>> Thanks. I am a bit surprised by the second convention.
>
> The reasoning seems to be that the client is asking for html, and that's
> what you're going to deliver to them... the fact that Mason is used to
> generate the html is an internal detail there's no point in bothering
> them with.

Hm, I see. It is maybe a pretty good reason on that side. But do
clients really care about the URL "file extension"?

Re: Multiple Major Modes

[Joe Brenner]

Lennart Borgman <lennart.borgman@gmail.com> wrote:

> >> >> to test it. (BTW, what file extensions do Mason files normally have?)
> >> >
> >> > The currently recommended Mason file extensions are *.mhtml for internal
> >> > components, and *.html for external ones:
> >> >
> >> >  http://www.masonhq.com/?FAQ:ServerConfiguration#h-what_filename_extensions_should_i_use_for_mason_components_
> >> >
> >> > That means, of course that the file extension alone gives you no way to
> >> > distinguish between a plain html file and a top-level Mason file.
> >>
> >> Thanks. I am a bit surprised by the second convention.
> >
> > The reasoning seems to be that the client is asking for html, and that's
> > what you're going to deliver to them... the fact that Mason is used to
> > generate the html is an internal detail there's no point in bothering
> > them with.
>
> Hm, I see. It is maybe a pretty good reason on that side. But do
> clients really care about the URL "file extension"?

Well, I do.  If the URL ends in ".asp", I think "oh, no...".

Re: Multiple Major Modes

[Lennart Borgman]

On Sat, Dec 12, 2009 at 3:16 AM, Joe Brenner <doom@kzsu.stanford.edu> wrote:
>
> Lennart Borgman <lennart.borgman@gmail.com> wrote:
>
>> >> >> to test it. (BTW, what file extensions do Mason files normally have?)
>> >> >
>> >> > The currently recommended Mason file extensions are *.mhtml for internal
>> >> > components, and *.html for external ones:
>> >> >
>> >> >  http://www.masonhq.com/?FAQ:ServerConfiguration#h-what_filename_extensions_should_i_use_for_mason_components_
>> >> >
>> >> > That means, of course that the file extension alone gives you no way to
>> >> > distinguish between a plain html file and a top-level Mason file.
>> >>
>> >> Thanks. I am a bit surprised by the second convention.
>> >
>> > The reasoning seems to be that the client is asking for html, and that's
>> > what you're going to deliver to them... the fact that Mason is used to
>> > generate the html is an internal detail there's no point in bothering
>> > them with.
>>
>> Hm, I see. It is maybe a pretty good reason on that side. But do
>> clients really care about the URL "file extension"?
>
> Well, I do.  If the URL ends in ".asp", I think "oh, no...".


Oh, you are not the type of client I was thinking of... I am glad to
hear you care though ;-)

I was more thinking about web browsers.

Re: Multiple Major Modes

[Joe Brenner]

Lennart Borgman <lennart.borgman@gmail.com> wrote:
> Joe Brenner <doom@kzsu.stanford.edu> wrote:
> > Lennart Borgman <lennart.borgman@gmail.com> wrote:

> >> >> >> to test it. (BTW, what file extensions do Mason files normally have?)
> >> >> >
> >> >> > The currently recommended Mason file extensions are *.mhtml for internal
> >> >> > components, and *.html for external ones:
> >> >> >
> >> >> >   http://www.masonhq.com/?FAQ:ServerConfiguration#h-what_filename_extensions_should_i_use_for_mason_components_
> >> >> >
> >> >> > That means, of course that the file extension alone gives you no way to
> >> >> > distinguish between a plain html file and a top-level Mason file.
> >> >>
> >> >> Thanks. I am a bit surprised by the second convention.
> >> >
> >> > The reasoning seems to be that the client is asking for html, and that's
> >> > what you're going to deliver to them... the fact that Mason is used to
> >> > generate the html is an internal detail there's no point in bothering
> >> > them with.
> >>
> >> Hm, I see. It is maybe a pretty good reason on that side. But do
> >> clients really care about the URL "file extension"?
> >
> > Well, I do.  If the URL ends in ".asp", I think "oh, no...".

> Oh, you are not the type of client I was thinking of... I am glad to
> hear you care though ;-)
>
> I was more thinking about web browsers.

No, not web browsers, exactly.  But a common use case for Mason is
re-engineering sites that were developed statically and turned out to be
maintenance nightmares.  There the published interface is URLs ending in
*.html, and changing that because you're changing the back-end wouldn't
make any sense.