Multiple Major Modes

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

[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

[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.

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 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.

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

Should nXML be included

[Leo]

Dear all,

I wonder if nXML¹ can be included.

Footnotes: 
¹  http://www.thaiopensource.com/nxml-mode/
-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

Re: Should nXML be included

[Lennart Borgman (gmail)]

Leo wrote:
> Dear all,
> 
> I wonder if nXML¹ can be included.
> 
> Footnotes: 
> ¹  http://www.thaiopensource.com/nxml-mode/

nXml is very good and I hope it will be included in Emacs. However there 
are reasons to break it up. I think the parsing code somehow should be 
broken up so that it can work for cases where the buffer is divided into 
multiple major modes.

This is however not a simple job.

For a comment on this see

http://sourceforge.net/mailarchive/forum.php?thread_name=4638A428.9010408%40pareto.nl&forum_name=cedet-devel

Re: Should nXML be included

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> nXml is very good and I hope it will be included in Emacs. However
> there are reasons to break it up. I think the parsing code somehow
> should be broken up so that it can work for cases where the buffer is
> divided into multiple major modes.

I think what you really mean is that you want to use nxml-mode to edit
non-xml files. Is that right? The problem I see with this is that the
power of nxml-mode compared to psgml and sgml modes is that it deals
with strict xml, and deals with it well. As soon as you start ripping
out features to support non-XML documents, you're back to a general SGML
mode and the compromises that brings.

If you really want to create PHP in an XML file, you need to use CDATA
blocks to tell the XML parser to ignore the invalid tags in that block.

Re: Should nXML be included

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>> nXml is very good and I hope it will be included in Emacs. However
>> there are reasons to break it up. I think the parsing code somehow
>> should be broken up so that it can work for cases where the buffer is
>> divided into multiple major modes.
> 
> I think what you really mean is that you want to use nxml-mode to edit
> non-xml files. Is that right? The problem I see with this is that the
> power of nxml-mode compared to psgml and sgml modes is that it deals
> with strict xml, and deals with it well. As soon as you start ripping
> out features to support non-XML documents, you're back to a general SGML
> mode and the compromises that brings.

Yes, you are right, I want to edit non-xml files.

But I think the power of nxml-mode can still be used. The parser 
provides to things: Validation and completion.

Validation of course loose most of its meanings, but not all. Completion 
can still be used. In fact that is what I do in nXhtml with nxhtml-mode 
+ mumamo-mode. To be able to make it more cleanly than currently the 
parser must be broken out.

> If you really want to create PHP in an XML file, you need to use CDATA
> blocks to tell the XML parser to ignore the invalid tags in that block.
> 
> 

Re: Should nXML be included

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> Validation of course loose most of its meanings, but not all.
> Completion can still be used.

The completion in nxml-mode is only as good as it is because the
validation tells it what is valid in that context. You can't have one
without the other. Like I said, as soon as you start trying to make nxml
a general SGML mode, you introduce compromises.

Multiple major mode support is a separate issue from nxml, and something
that should be addressed without imposing restrictions on specialized
major modes.

Multiple major modes (was: Should nXML be included)

[Stefan Monnier]

> Multiple major mode support is a separate issue from nxml,

100% agreement, obviously.

> and something that should be addressed without imposing restrictions on
> specialized major modes.

Actually, I think that in order to address it well, we will need to impose
restrictions on major modes (though only on the ones involved in
multiple-major-mode buffers) and maybe also on minor modes.


        Stefan

Re: Multiple major modes

[Leo]

----- Stefan Monnier (2007-06-12) wrote:-----

>> and something that should be addressed without imposing restrictions
>> on specialized major modes.
>
> Actually, I think that in order to address it well, we will need to
> impose restrictions on major modes (though only on the ones involved
> in multiple-major-mode buffers) and maybe also on minor modes.

There seems to be a few multi mode implementation, what is the
preference from Emacs developers?

-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

Re: Multiple major modes

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>> Multiple major mode support is a separate issue from nxml,
> 
> 100% agreement, obviously.

Of course. I just thought it was a good time to mention it.

>> and something that should be addressed without imposing restrictions on
>> specialized major modes.
> 
> Actually, I think that in order to address it well, we will need to impose
> restrictions on major modes (though only on the ones involved in
> multiple-major-mode buffers) and maybe also on minor modes.


I think so to. I have seen some areas where some form of coherence is 
necessary:

- fontification
- indentation
- parsing

I think nxml-mode is a very good candidate for those that can be used in 
a multiple-major-mode buffers, since a mix of for example XHTML and PHP 
is common.

This might seem impossible, since such code could not be valid XHTML. 
Actually it is not, the rng parser used in nxhtml-mode is quite good on 
guessing an apropriate state for completion. (But do not ask me what the 
rng parser does, I do not understand it.)

Re[2]: Multiple major modes

[Eric M. Ludlam]

  [ ... ]
>>> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> seems to think that:
>Stefan Monnier wrote:
>>> and something that should be addressed without imposing restrictions on
>>> specialized major modes.
>> 
>> Actually, I think that in order to address it well, we will need to impose
>> restrictions on major modes (though only on the ones involved in
>> multiple-major-mode buffers) and maybe also on minor modes.

My parsing tool (semantic, referenced earlier) solved some problems w/
lots of mode-specific configurations via 'mode-local' variables and
methods.  David Ponce wrote this, and suggested it here once before.
I don't recall what the end resolution was on it.

A multi-mode style thing would likely be simplified if key behaviors
were all defined via mode-local configurations, as that would allow
the multi-mode manager to get a complete query list of all
configuration differences without running the major-mode function.

http://cedet.cvs.sourceforge.net/cedet/cedet/common/mode-local.el?view=log

This tools has a spiff macro `with-mode-local', which lets you run a
bunch of code as if some other mode were active.  This is used in our
grammar file so we can operate on grammar syntax w/ lisp syntax mixed
in.  We can also operate on tags from other buffers by momentarily
using features of the originating major-mode.

Enjoy
Eric


>I think so to. I have seen some areas where some form of coherence is 
>necessary:
>
>- fontification
>- indentation
>- parsing
>
>I think nxml-mode is a very good candidate for those that can be used in 
>a multiple-major-mode buffers, since a mix of for example XHTML and PHP 
>is common.
>
>This might seem impossible, since such code could not be valid XHTML. 
>Actually it is not, the rng parser used in nxhtml-mode is quite good on 
>guessing an apropriate state for completion. (But do not ask me what the 
>rng parser does, I do not understand it.)
>

-- 
          Eric Ludlam:                 zappo@gnu.org, eric@siege-engine.com
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org

Re: Multiple major modes

[Lennart Borgman (gmail)]

Eric M. Ludlam wrote:
>   [ ... ]
>>>> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> seems to think that:
>> Stefan Monnier wrote:
>>>> and something that should be addressed without imposing restrictions on
>>>> specialized major modes.
>>> Actually, I think that in order to address it well, we will need to impose
>>> restrictions on major modes (though only on the ones involved in
>>> multiple-major-mode buffers) and maybe also on minor modes.
> 
> My parsing tool (semantic, referenced earlier) solved some problems w/
> lots of mode-specific configurations via 'mode-local' variables and
> methods.  David Ponce wrote this, and suggested it here once before.
> I don't recall what the end resolution was on it.
> 
> A multi-mode style thing would likely be simplified if key behaviors
> were all defined via mode-local configurations, as that would allow
> the multi-mode manager to get a complete query list of all
> configuration differences without running the major-mode function.
> 
> http://cedet.cvs.sourceforge.net/cedet/cedet/common/mode-local.el?view=log

Would it be possible to catch all local bindings by setting the major 
mode in a temporary buffer and then save them for later use? This would 
avoid having to change major modes, perhaps.

> This tools has a spiff macro `with-mode-local', which lets you run a
> bunch of code as if some other mode were active.  This is used in our
> grammar file so we can operate on grammar syntax w/ lisp syntax mixed
> in.  We can also operate on tags from other buffers by momentarily
> using features of the originating major-mode.
> 
> Enjoy
> Eric

Re: Multiple major modes

[Stefan Monnier]

> Would it be possible to catch all local bindings by setting the major mode
> in a temporary buffer and then save them for later use? This would avoid
> having to change major modes, perhaps.

This could be a default heuristic to be compatible with major modes which
have not been adapted, but better provide a more robust solution as well, so
that this hack can be phased out little by little.


        Stefan

Re: Multiple major modes

[Richard Stallman]

MuMaMo, which was discussed here a few months ago, seems to be basically
a good way of handling multiple major modes.  If people are discussing
other ways, I suggest comparing them with MuMaMo.

Re: Multiple major modes

[Richard Stallman]

    This tools has a spiff macro `with-mode-local', which lets you run a
    bunch of code as if some other mode were active.

Can you explain, in a nutshell, how the mechanism works?

Re[2]: Multiple major modes

[Eric M. Ludlam]

>>> Richard Stallman <rms@gnu.org> seems to think that:
>    This tools has a spiff macro `with-mode-local', which lets you run a
>    bunch of code as if some other mode were active.
>
>Can you explain, in a nutshell, how the mechanism works?
>

The mode-local system ignores all variables set for the mode outside
the scope of mode-local.

Step 1:

  Define all your variables with `defvar-mode-local'.
  If changing a default value, use `setq-mode-local'

Step 2:

  For a program, use `define-overload' to specify a function that
  can have a mode specific override.  Supply a default body for modes
  that accept the default.


Step 3:

  The mode-local system will automatically assign buffer-local values
  to mode-local defined variables.

  If a function is called created with `define-overload', then a mode
  specific behavior will be run.


Ok, now if you use `with-mode-local', it will just substitute the old
local variables defined in the current mode with those from the new
mode, deleting any that don't exist in the new mode.

When exiting body (from with-mode-local macro) then it will just
reverse the process.


This is a key piece of abstraction for my semantic tool which provides
language independent access to tagging information, which needs
mode-specific values for parser information and many other functions.

http://cedet.sourceforge.net/semantic.shtml


Enjoy
Eric

-- 
          Eric Ludlam:                 zappo@gnu.org, eric@siege-engine.com
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org

Re: Multiple major modes

[Richard Stallman]

      Define all your variables with `defvar-mode-local'.
      If changing a default value, use `setq-mode-local'

Does this mean we would have to go thru all of Emacs and put in
such definitions for all the variables that major modes can change?

Currently, the idea is that major modes can make any global variable
buffer-local.  Are you suggesting we divide all variables into two
classes, those that can be and those that can't be?  If so, what is
the benefit of that?

Would it make sense for `defvar' itself to do whatever you want
`defvar-mode-local' to do?

      For a program, use `define-overload' to specify a function that
      can have a mode specific override.  Supply a default body for modes
      that accept the default.

Since multiple major modes work (in different buffers) without this
feature, why would we need to add this feature merely to support
multiple major modes in one buffer?

      The mode-local system will automatically assign buffer-local values
      to mode-local defined variables.

I don't understand.  Does this mean that everything defined with
`defvar-mode-local' gets buffer-local in all buffers?  If so,
how is that different from `make-variable-buffer-local'?

I guess there must be parts of this explanation that are missing.

Re[2]: Multiple major modes

[Eric M. Ludlam]

Hi,

>>> Richard Stallman <rms@gnu.org> seems to think that:
>      Define all your variables with `defvar-mode-local'.
>      If changing a default value, use `setq-mode-local'
>
>Does this mean we would have to go thru all of Emacs and put in
>such definitions for all the variables that major modes can change?

First, I'd like to be clear that I did not concoct the mode-local
program so that I could write a cheap multi-major-mode type program.
For semantic, which is a parser-generator, and has many minor modes,
it allows someone to write mode-specific code and variable values in a
way that is declarative, instead of in a giant hook function.  It
makes it very easy to write a tool (like semantic) that can work in
many major modes, and where the differences between major modes is
very small.

Another advantage is that it allows each mode to add documentation
specific to its needs.

As for adopting it for all modes, I expect it is optional.  It would
replace the big block in most mode functions that create and set
buffer-local values for tools that are not specific to that
major-mode.

>Currently, the idea is that major modes can make any global variable
>buffer-local.  Are you suggesting we divide all variables into two
>classes, those that can be and those that can't be?  If so, what is
>the benefit of that?

There would be two classes.  There would be values that are specific
to the major mode, and variables that are local to just some buffer.
The buffer local value would trump the mode-specific value, and any
mode-specific value would trump the global value.

>Would it make sense for `defvar' itself to do whatever you want
>`defvar-mode-local' to do?

That could simplify things greatly, though I haven't though too hard
on this idea.

>      For a program, use `define-overload' to specify a function that
>      can have a mode specific override.  Supply a default body for modes
>      that accept the default.
>
>Since multiple major modes work (in different buffers) without this
>feature, why would we need to add this feature merely to support
>multiple major modes in one buffer?

The function overload mechanism is also a feature I use in semantic.
Most features that work in multiple major modes today provide a
variable where you can put a symbol that is a function that would then
provide some mode-specific functionality.

My semantic tool has hundreds of these functions, so I abstracted the
concept up so that the implementations could be declarative, instead
of programmatic.  It also makes it easy to make most functions
overridable, which helps avoid forcing users to use advice when
customizing my tool.

As for the multi-major-mode case, if the technique of a variable w/ a
symbol in it is used, then you are correct, this already works.


>      The mode-local system will automatically assign buffer-local values
>      to mode-local defined variables.
>
>I don't understand.  Does this mean that everything defined with
>`defvar-mode-local' gets buffer-local in all buffers?  If so,
>how is that different from `make-variable-buffer-local'?
>
>I guess there must be parts of this explanation that are missing.

The mode-local feature I wrote (with a lot of help from David Ponce)
works in all versions of Emacs commonly used today.  It does this work
by modifying the buffer-local values for different major-modes.  It
provides the concept of what a mode-local variable might be.  Ideally
it would not operate this way, and instead have built-in support for
real mode-local values and method tables.

In summary, the mode-local tool is useful (to me at least) because it
lets me write more declarative code while setting up values for a
major mode.

For the multi-major-mode case, it would allow a multi-major-mode tool
to operate on predefined lists of variables and it would know the
difference between a variable that is specific to that major mode (and
thus must be swapped in and out) and a variable that is buffer local
for some other reason, such as a minor-mode.  A side effect is that
you could have minor modes that operate across both major modes in a
single buffer, and that minor mode won't get tromped.

I used this technique for semantic's grammar mode which swaps between
the grammar syntax, and Emacs Lisp which is the grammar
implementation.


It is obvious that if a mode-local type tool or syntax were adopted
into Emacs, that it would be a big effort to transition everything to
it.  I also don't recommend that David's mode-local implementation be
taken as a sole implementation.  The real advantage would come if the
concepts were built into Emacs and the help system which could then
show chains of values (For C-h v) or chains of function doc (for C-h f)
based on mode.  The readability of my code increased greatly when I
transitioned to a more declarative way of setting up deltas to
different major-modes.  It also made the grammar mode easy to
implement, and that's why I suggest it here.

Thanks
Eric

Re: Multiple major modes

[Richard Stallman]

Please forgive my delay in studying your message and responding.

    >Currently, the idea is that major modes can make any global variable
    >buffer-local.  Are you suggesting we divide all variables into two
    >classes, those that can be and those that can't be?  If so, what is
    >the benefit of that?

    There would be two classes.

I don't entirely follow.  Two classes of what?  Two classes of variables?

If so, could you describe each of the two classes?

				 There would be values that are specific
    to the major mode, and variables that are local to just some buffer.
    The buffer local value would trump the mode-specific value, and any
    mode-specific value would trump the global value.

That part makes sense to me; but can't we make all kinds of bindings
possible for every variable?

    The mode-local feature I wrote (with a lot of help from David Ponce)
    works in all versions of Emacs commonly used today.  It does this work
    by modifying the buffer-local values for different major-modes.  It
    provides the concept of what a mode-local variable might be.  Ideally
    it would not operate this way, and instead have built-in support for
    real mode-local values and method tables.

That makes sense.  We could implement mode-local bindings at the low
level if that is what we want.

What should their semantics be?

      A side effect is that
    you could have minor modes that operate across both major modes in a
    single buffer, and that minor mode won't get tromped.

How would this work?

    It is obvious that if a mode-local type tool or syntax were adopted
    into Emacs, that it would be a big effort to transition everything to
    it.

I hope we can design the mechanism to avoid the need for pervasive
changes in the code of major modes.  Perhaps we would need to change
some of the current calls to make-local-variable to call some new
primitive, make-mode-variable, instead.  But even that would be a pain
if every major mode HAD to do it.

      The real advantage would come if the
    concepts were built into Emacs and the help system which could then
    show chains of values (For C-h v) or chains of function doc (for C-h f)
    based on mode.

I agree, that would be good to do.

Re[2]: Multiple major modes

[Eric M. Ludlam]

>>> Richard Stallman <rms@gnu.org> seems to think that:
>Please forgive my delay in studying your message and responding.
>
>    >Currently, the idea is that major modes can make any global variable
>    >buffer-local.  Are you suggesting we divide all variables into two
>    >classes, those that can be and those that can't be?  If so, what is
>    >the benefit of that?
>
>    There would be two classes.
>
>I don't entirely follow.  Two classes of what?  Two classes of variables?
>
>If so, could you describe each of the two classes?

Sorry for being vague.  There would be "buffer-local variables", and
"mode-local variables".  I was distinguishing those two from "global
variables". In reading the "Elisp" manual to check my phrases, I see
there are also "frame-local variables", and many other ways to bind
variables, so I am just wrong in saying there are only two classes of
variables.

>				 There would be values that are specific
>    to the major mode, and variables that are local to just some buffer.
>    The buffer local value would trump the mode-specific value, and any
>    mode-specific value would trump the global value.
>
>That part makes sense to me; but can't we make all kinds of bindings
>possible for every variable?

Correct.  When trying to resolve the value of some symbol, mode-local
values would fit into the current scheme of determining the value in
some way, and I am suggesting that buffer local values would be used
before mode-local values.

>    The mode-local feature I wrote (with a lot of help from David Ponce)
>    works in all versions of Emacs commonly used today.  It does this work
>    by modifying the buffer-local values for different major-modes.  It
>    provides the concept of what a mode-local variable might be.  Ideally
>    it would not operate this way, and instead have built-in support for
>    real mode-local values and method tables.
>
>That makes sense.  We could implement mode-local bindings at the low
>level if that is what we want.
>
>What should their semantics be?

If you have a variable defined:

(defvar my-var nil)

and then set a mode-local value for a mojor mode:

;; programmatic
(setq-mode-local 'c-mode my-var t)
;; or declarative
(defvar-mode-local c-mode my-var t "Description about C value")
;; or a constant for that mode, if `defconst' was used instead of `defvar'.
(defconst-mode-local c-mode my-var t "Description here...")

then all buffers in c-mode would get the new value of my-var.

If any of those buffers have a buffer-local version of my-var, then
that value would be used instead.  I'm not sure about frame-local
variables.

If a c-mode buffer switched to fundamental-mode, then the value of
my-var would go back to nil, (the default value).

>      A side effect is that
>    you could have minor modes that operate across both major modes in a
>    single buffer, and that minor mode won't get tromped.
>
>How would this work?

A minor mode which works in an HTML buffer with embedded php in it
could use `mode-local-symbol-value' to get the value of some HTML
variable when inside a PHP block for, perhaps, fill-column, or other
variable even though the effective major mode is PHP.

Basically, any code could be written to be aware of the combination of
two modes for a specific case, and have access to both sets of
mode-local variable bindings, regardless of cursor position.

>    It is obvious that if a mode-local type tool or syntax were adopted
>    into Emacs, that it would be a big effort to transition everything to
>    it.
>
>I hope we can design the mechanism to avoid the need for pervasive
>changes in the code of major modes.  Perhaps we would need to change
>some of the current calls to make-local-variable to call some new
>primitive, make-mode-variable, instead.  But even that would be a pain
>if every major mode HAD to do it.

I think it can be completely optional.  Whichever multiple major-mode
tool that is chosen could take advantage of mode-local variables, and
major modes would adopt the use of them because of performance and
usage enhancement.

If a multi-major-mode tool knows a particular major-mode doesn't use
buffer-local variables, then it would not need to run the major-mode
function (which could call `kill-all-local-variables') for every
section switch and lots of work needed to save and restore
buffer-local values that may or may not be mode-specific would be
saved.


I like providing the mode-local values in a declarative way outside of
the mode function.  It provides a place to add documentation and talk
about the change.  That alone, I think, is worthwhile.

Eric

-- 
          Eric Ludlam:                 zappo@gnu.org, eric@siege-engine.com
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org

Re: Multiple major modes

[Richard Stallman]

    Sorry for being vague.  There would be "buffer-local variables", and
    "mode-local variables".

I think you really mean two classes of bindings, right?

    ;; programmatic
    (setq-mode-local 'c-mode my-var t)

    then all buffers in c-mode would get the new value of my-var.

Ok.  What happens if you do (setq my-var 69) in a buffer in C mode?
Does it change the value to 69 for all C mode buffers?

    If a multi-major-mode tool knows a particular major-mode doesn't use
    buffer-local variables, then it would not need to run the major-mode
    function (which could call `kill-all-local-variables') for every
    section switch and lots of work needed to save and restore
    buffer-local values that may or may not be mode-specific would be
    saved.

That's true, if we only consider local variables.  But major modes
set other things too: local keymap, syntax table, abbrev table.
We would need a new way to handle them too, right?

Here is another idea: `run-mode-hooks' could record all local bindings
made by a certain major mode, as mode-local bindings.  This way,
nearly all major modes would "just work" with the new mechanism; we
would not have to change their code.  Of course, `delay-mode-hooks'
would need to cooperate.

Re: Multiple major modes

[Richard Stallman]

    The function overload mechanism is also a feature I use in semantic.
    Most features that work in multiple major modes today provide a
    variable where you can put a symbol that is a function that would then
    provide some mode-specific functionality.

    My semantic tool has hundreds of these functions, so I abstracted the
    concept up so that the implementations could be declarative, instead
    of programmatic. 

I really don't like the idea of function overloads.  This mechanism
shares the drawbacks of advice: that a function doesn't do what its
definition says.

		      It also makes it easy to make most functions
    overridable, which helps avoid forcing users to use advice when
    customizing my tool.

It is easy to replace advising with another similar mechanism,
but it doesn't solve the problem.

It seems to me that there is no need for this.  Calling a variable
with funcall should do the same job.  That way, the call _shows_
that the function isn't fixed.

Re: Multiple major modes

[T. V. Raman]

For the record, advice does update the function documentation,
assuming one documents the advice.


>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:
    Richard>     The function overload mechanism is also a
    Richard> feature I use in semantic.  Most features that work
    Richard> in multiple major modes today provide a variable
    Richard> where you can put a symbol that is a function that
    Richard> would then provide some mode-specific functionality.
    Richard> 
    Richard>     My semantic tool has hundreds of these
    Richard> functions, so I abstracted the concept up so that
    Richard> the implementations could be declarative, instead of
    Richard> programmatic.
    Richard> 
    Richard> I really don't like the idea of function overloads.
    Richard> This mechanism shares the drawbacks of advice: that
    Richard> a function doesn't do what its definition says.
    Richard> 
    Richard> 		      It also makes it easy to make most
    Richard> functions overridable, which helps avoid forcing
    Richard> users to use advice when customizing my tool.
    Richard> 
    Richard> It is easy to replace advising with another similar
    Richard> mechanism, but it doesn't solve the problem.
    Richard> 
    Richard> It seems to me that there is no need for this.
    Richard> Calling a variable with funcall should do the same
    Richard> job.  That way, the call _shows_ that the function
    Richard> isn't fixed.
    Richard> 
    Richard> 
    Richard> _______________________________________________
    Richard> Emacs-devel mailing list Emacs-devel@gnu.org
    Richard> http://lists.gnu.org/mailman/listinfo/emacs-devel

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: Multiple major modes

[David Kastrup]

"T. V. Raman" <raman@users.sf.net> writes:

> For the record, advice does update the function documentation,
> assuming one documents the advice.

Once the advice is loaded and applied.

Now it just needs to update the more extensive documentation in the
manual, and we are all set.

Except that it is hard to guess the cumulative effects of multiple
pieces of advice.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multiple major modes

[Richard Stallman]

    For the record, advice does update the function documentation,
    assuming one documents the advice.

It doesn't update the source code of the function definition,
which is the main thing that someone debugging will look at.

This suggests an idea to me.  Maybe Emacs could highlight the function
definition somehow, to indicate that the function has been advised.

That might solve the problem that makes advising bad for debugging.
Would someone like to try it?

To be sure whether it solves that problem, we would have to try it for
a while, and see the results.  We can't assume this a priori.

Re: Multiple major modes

[Stefan Monnier]

> That might solve the problem that makes advising bad for debugging.
> Would someone like to try it?

I don't find advising difficult for debugging.

Actually, the problem with defadvice (for me) is not when the advice is
enabled, but when it's not because then there's no trace anywhere that the
function you're looking at has a special relationship to some other piece of
code elsewhere.

So whenever I change a function (i.e. whenever I change some piece of code
in Emacs) I may potentially break an advice.  So if I don't want to break
other advices (or should I say "pieces of advice") I'd have to constantly
grep the code to see if the function I'm changing happens to be
advised somewhere.

When the advice is outside Emacs, I don't care so much about breaking it,
but if it's inside Emacs it's a more serious problem,


        Stefan

Re: Multiple major modes

[Richard Stallman]

    I don't find advising difficult for debugging.

I am surprised.  Why not?

    Actually, the problem with defadvice (for me) is not when the advice is
    enabled, but when it's not because then there's no trace anywhere that the
    function you're looking at has a special relationship to some other piece of
    code elsewhere.

They are two different problems.  Enabled advice can cause confusion
in debugging, because the function may not do what its source code
says; that can cause confusion in debugging.  Separately, changing the
function can break code in advice of that function.

Both of them can be real.  I'm surprised that you think that only the
latter one is important.

When you change a function, often you would search for its callers
to make sure you don't break them.  That search would find advice
for the function, as well as callers.  Thus, I tend to think that
the second problem won't be so bad.

However, when debugging you are likely to need to look
at lots of functions, and it would be a pain to have to search
for advice for each of these functions.

Re: Multiple major modes

[Stephen J. Turnbull]

Richard Stallman writes:

 >     I don't find advising difficult for debugging.
 > 
 > I am surprised.  Why not?

I can't speak for Stefan, but I can say why I rarely have a problem
with it.  Once I've localized to a function (usually via a backtrace),
the first thing I normally do is `describe-function', and then jump to
the source via find-function from the help buffer.

Re: Multiple major modes

[Richard Stallman]

      Once I've localized to a function (usually via a backtrace),
    the first thing I normally do is `describe-function', and then jump to
    the source via find-function from the help buffer.

I often do that, but I don't read carefully thru the buffer thaht
`describe-function' displays.  If it said something about advice, I
wouldn't even notice, unless I read carefully thru the buffer to look
for such.  And I am in too much of a hurry to make a practice
of always reading that text carefully.

Maybe this is a consequence of getting older.

Re: Multiple major modes

[Lennart Borgman (gmail)]

Richard Stallman wrote:
>       Once I've localized to a function (usually via a backtrace),
>     the first thing I normally do is `describe-function', and then jump to
>     the source via find-function from the help buffer.
> 
> I often do that, but I don't read carefully thru the buffer thaht
> `describe-function' displays.  If it said something about advice, I
> wouldn't even notice, unless I read carefully thru the buffer to look
> for such.  And I am in too much of a hurry to make a practice
> of always reading that text carefully.

Did someone already say "highlight the advice info" in the help buffer?

> Maybe this is a consequence of getting older.

Yes, of course. There is still just as much to do in life and less time 
left.

Re: Multiple major modes

[Richard Stallman]

    > I often do that, but I don't read carefully thru the buffer thaht
    > `describe-function' displays.  If it said something about advice, I
    > wouldn't even notice, unless I read carefully thru the buffer to look
    > for such.  And I am in too much of a hurry to make a practice
    > of always reading that text carefully.

    Did someone already say "highlight the advice info" in the help buffer?

I have doubts that it will help that much, but it can't hurt.  Would
someone please implement it?

Moving that advice info closer to the top might also be useful
if it is not already close to the top.

Re: Multiple major modes

[Stephen J. Turnbull]

Richard Stallman writes:

 >       Once I've localized to a function (usually via a backtrace),
 >     the first thing I normally do is `describe-function', and then jump to
 >     the source via find-function from the help buffer.
 > 
 > I often do that, but I don't read carefully thru the buffer thaht
 > `describe-function' displays.

Aha.  It would be a good idea to put the "this function is advised"
notice first.  That way at least it would less often catch you by
surprise.

Re: Multiple major modes

[Stefan Monnier]

>     I don't find advising difficult for debugging.
> I am surprised.  Why not?

No idea, but I just can't remember a single case where it has bothered me.

> When you change a function, often you would search for its callers
> to make sure you don't break them.

In most cases the function is "internal" so I only search with C-s.


        Stefan

RE: Multiple major modes

[Drew Adams]

> >     I don't find advising difficult for debugging.
> > I am surprised.  Why not?
>
> No idea, but I just can't remember a single case where it has bothered me.

FWIW -

Perhaps it also depends on how one debugs? I tend not to use edebug; I use
`debug-on-entry' and `(debug)'. Advice bothers me during debugging because
the steps followed include a lot of advice stuff that muddies the waters,
for me.

Re: Multiple major modes

[Richard Stallman]

    Perhaps it also depends on how one debugs? I tend not to use edebug; I use
    `debug-on-entry' and `(debug)'. Advice bothers me during debugging because
    the steps followed include a lot of advice stuff that muddies the waters,
    for me.

That is also how I do debugging.

Re: Multiple major modes

[Stephen J. Turnbull]

Richard Stallman writes:

 >     Perhaps it also depends on how one debugs? I tend not to use
 >     edebug; I use `debug-on-entry' and `(debug)'. Advice bothers me
 >     during debugging because the steps followed include a lot of
 >     advice stuff that muddies the waters, for me.

 > That is also how I do debugging.

Which suggests adding a feature to the debugger (or to advice) to skip
over advice when debugging.  (This is a "by the way2 suggestion to
improve debugging in the presence of advice one happens to encounter,
not intended as an argument that "advice is OK".)

No, I don't have time (or sufficient knowledge of the debugger and
advice, for that matter) to do it. :-(

Re: Multiple major modes

[Richard Stallman]

    Which suggests adding a feature to the debugger (or to advice) to skip
    over advice when debugging.

I don't follow.  What would that feature do?

Re: Multiple major modes

[Stephen J. Turnbull]

Richard Stallman writes:

 >     Which suggests adding a feature to the debugger (or to advice) to skip
 >     over advice when debugging.
 > 
 > I don't follow.  What would that feature do?

When you step through a function, you can either step into or step
across function calls.  By analogy, when you are stepping through an
advised function, it should be technically possible to step across any
advice code or infrastructure to the point of the (ad-do-it) call.
This might help keep the view of the function that you see in the
source and the view of the function that you get from stepping more
coherent.

Re: Multiple major modes

[Richard Stallman]

    When you step through a function, you can either step into or step
    across function calls.  By analogy, when you are stepping through an
    advised function, it should be technically possible to step across any
    advice code or infrastructure to the point of the (ad-do-it) call.

To pretend that the advice is not there is counterproductive.
That would only exacerbate the problem caused by advice -- which is
that it runs and you don't notice.

When you do know about the advice, you might sometimes want to run
across it in the debugger without stopping.  A command to do that
could be useful on those special occasions, so I would be happy to
have it installed for that purpose.

Re: Multiple major modes

[Johan Bockgård]

Richard Stallman <rms@gnu.org> writes:

> This suggests an idea to me.  Maybe Emacs could highlight the function
> definition somehow, to indicate that the function has been advised.

FWIW, there is already an entry in TODO

    ** Emacs Lisp mode could put an overlay on the defun for every
      function that has advice.  The overlay could have `after-text'
      like " [Function has advice]".  It might look like (defun foo
      [Function has advice] (x y) The overlay could also be a button
      that you could use to view the advice.

> That might solve the problem that makes advising bad for debugging.

Here's an example where advice can be really confusing:

;; See ad-default-compilation-action
(require 'bytecomp)

(defun foo (x y)
  (+ x y))

(defadvice foo (before bar activate)
  (car x))

(foo 1 2)
  =>

Debugger entered--Lisp error: (wrong-type-argument listp 1)
  foo(1 2)
  eval((foo 1 2))
  eval-last-sexp-1(nil)
  eval-last-sexp(nil)
  call-interactively(eval-last-sexp)


(If the advice is not compiled "car(1)" is present in the backtrace.)

-- 
Johan Bockgård

Re[2]: Multiple major modes

[Eric M. Ludlam]

>>> Richard Stallman <rms@gnu.org> seems to think that:
>    The function overload mechanism is also a feature I use in semantic.
>    Most features that work in multiple major modes today provide a
>    variable where you can put a symbol that is a function that would then
>    provide some mode-specific functionality.
>
>    My semantic tool has hundreds of these functions, so I abstracted the
>    concept up so that the implementations could be declarative, instead
>    of programmatic. 
>
>I really don't like the idea of function overloads.  This mechanism
>shares the drawbacks of advice: that a function doesn't do what its
>definition says.
>
>		      It also makes it easy to make most functions
>    overridable, which helps avoid forcing users to use advice when
>    customizing my tool.
>
>It is easy to replace advising with another similar mechanism,
>but it doesn't solve the problem.
>
>It seems to me that there is no need for this.  Calling a variable
>with funcall should do the same job.  That way, the call _shows_
>that the function isn't fixed.

The use syntax of an overloadable function is similar to programs that
call `indent-for-tab-command', or `indent-according-to-mode', but
there is no restriction forcing `according-to-mode' as part of the
function name.

The difference between writing an `indent-according-to-mode'
function and an overload function is that you don't have to write the
body of the function or, in the specific case of
`indent-according-to-mode', you could write a body that wraps up an
:overload token similar to the way `indent-according-to-mode' wraps
the `funcall'.

Anyway, I think these overload functions are more like methods which
dispatch on major mode instead of advice.  You can advise any
function, but you can only overload something created with
`define-overload', so it is known via syntactic sugar instead of a
funcall call.

When it comes right down to it though, this is not needed for multiple
major modes where one of the concerns is buffer-local vs mode-local
variables, and I don't want to imply that I think it is needed.  It is
only a feature which I feel has enhanced the maintainability of my
code, and has helped others understand and discover how to extend my
tools for different modes.

Eric

-- 
          Eric Ludlam:                 zappo@gnu.org, eric@siege-engine.com
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org

Re: Multiple major modes

[Richard Stallman]

    The use syntax of an overloadable function is similar to programs that
    call `indent-for-tab-command', or `indent-according-to-mode', but
    there is no restriction forcing `according-to-mode' as part of the
    function name.

I understand the similarity, but I see the difference too.
The source code of `indent-according-to-mode' shows that it
calls something that can be set differently by different modes.

That's why I prefer using a variable.

However, you didn't show precisely what this feature looks like.
Perhaps I got the wrong idea of the feature.  Can you show me
what it looks like?

Re[2]: Multiple major modes

[Eric M. Ludlam]

>>> Richard Stallman <rms@gnu.org> seems to think that:
>    The use syntax of an overloadable function is similar to programs that
>    call `indent-for-tab-command', or `indent-according-to-mode', but
>    there is no restriction forcing `according-to-mode' as part of the
>    function name.
>
>I understand the similarity, but I see the difference too.
>The source code of `indent-according-to-mode' shows that it
>calls something that can be set differently by different modes.
>
>That's why I prefer using a variable.
>
>However, you didn't show precisely what this feature looks like.
>Perhaps I got the wrong idea of the feature.  Can you show me
>what it looks like?

Hi,

  Here is a use case from semantic, my parsing tool.  This is a
function that would take a name as found in sources, and split it so
that namespaces (if any) and the name are returned.  In many
languages there is nothing special to do, but in C++, it needs to do
something special.  Instead of putting c++ code in the first file, it
is instead placed in a C specific file that contains many C specific
differences.  Of course, the doc string talks about C++, but only as
an example.

  I picked this case because it's very short.


semantic-analyze.el:
--------------------
(define-overload semantic-analyze-split-name (name)
  "Split a tag NAME into a sequence.
Sometimes NAMES are gathered from the parser that are compounded,
such as in C++ where foo::bar means:
  \"The class BAR in the namespace FOO.\"
Return the string NAME for no change, or a list if it needs to be split.")

(defun semantic-analyze-split-name-default (name)
  "Don't split up NAME by default."
  name)
--------------------

As you can see, there is no implementation at the initial
declaration.  In this example, the `-default' is a separate function,
because a body could be given to the original that would wrap either
the `-default' of a mode specific implementation.


semantic-c.el:
--------------
(define-mode-local-override semantic-analyze-split-name c-mode (name)
  "Split up tag names on colon (:) boundaries."
  (let ((ans (split-string name ":")))
    (if (= (length ans) 1)
	name
      (delete "" ans))))
--------------

If you use "C-h f semantic-analyze-split-name RET" you get:

---------------
semantic-analyze-split-name is a compiled Lisp function in `semantic-analyze.el'.
(semantic-analyze-split-name name)

This function can be overloaded (see `define-mode-local-override' for details).

Split a tag name into a sequence.
Sometimes NAMES are gathered from the parser that are compounded,
such as in C++ where foo::bar means:
  "The class BAR in the namespace FOO."
Return the string name for no change, or a list if it needs to be split.

[back]
---------------

which would be improved if the doc for individual overloads could be
specified, though I haven't done that yet.  Doing so would make it
much easier to find the implementation actually being run in a
particular case.

I hope this helps.
Eric

-- 
          Eric Ludlam:                 zappo@gnu.org, eric@siege-engine.com
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org

Re: Multiple major modes

[Richard Stallman]

I now see that my previous concerns were misguided.
(I had misunderstood what the feature does.)
This feature doesn't cause a problem like that of advice.
It seems like basically a good idea.

I do have a criticism of one part of the API, though.

    (defun semantic-analyze-split-name-default (name)
      "Don't split up NAME by default."
      name)

It seems like a mistake to make the API depend on manipulating symbol
names.  I'd rather have a separate construct to define the default
meaning, giving the standard name, here `semantic-analyze-split-name'.

How does it actually work?