Re: cc-mode and mmm-mode

[Alan S. <at...@ac...>]

(Copying both lists here for better discussion.  It might be best to
move this to the mmm-mode list eventually.)

> The most common case I know of such a mix is with C extensions that
> integrate SQL statements in the C code.

This hasn't hit me as much as the reverse.  When this happens, does it
usually follow C syntax (ie, in strings or something) or not?  And do
the submodes (sql-mode) have as intelligent indentation as C mode?

Most of the submodes I've used so far don't have as intelligent a mode
as submode, and won't get as confused.  cc-mode can get tremendously
confused when it's embedded into something, and in most cases, it's
hard to get it back on track.  So mmm-mode would do OK at managing
things where the sql was in some syntacticly correct C, without any
help from cc-mode.  Of course, if that isn't the case, cc-mode would
need help.  (As would any other modes.)

> I think a good (probably necessary) solution is to extend them on the
> C level so that they can jump over overlays in a similar way, based on
> certain properties in them. That should also make forward-comment work
> right away.

Currently, mmm-mode doesn't put the "top-level" mode in an overlay
(which would be required for embedded C to skip over yacc), but it
could.  

> As I said above, this is interesting. Like many other people, I've had
> plans in the same direction myself, but nothing has come out of that.
> If you'd like to propose an API to make major modes operate nicely
> together, I'd be happy to comment on it and (if it's good enough) add
> support for it.

Well, I think that right now, mmm-mode was structured to do the best
it can without support from anything else.  That would lead something
that works faster, because it would take a while for something to
become part of (X)Emacs.  But I know _I've_ been running into problems
doing things this way....

Michael Abraham Shulman <sh...@ca...> is the lead developer on
mmm-mode, btw.  Michael, you've been thinking about this longer than I
have: do you have ideas on the best general API, if we were to assume
that it could go into Emacs' core and most modes were to support it
(hopefully without much work, unless they were really intelligent
about their subject matter... I could see psgml, auctex, and cc-mode
requiring more work than others, for instance).

-- 
Alan Shutko <at...@ac...> - In a variety of flavors!
The most important things, each person must do for himself.