62 lines
2.6 KiB
Plaintext
62 lines
2.6 KiB
Plaintext
|
|
Hey Emacs, this is a -*-text-*- file!
|
||
|
|
|
||
|
|
To Do List for MMM Mode
|
||
|
|
=======================
|
||
|
|
|
||
|
|
Custom mode functions like `mason-mode'.
|
||
|
|
|
||
|
|
Make Mason work a little better with PSGML. The fix I've found works,
|
||
|
|
but it would be nifty if MMM could do it automatically. Maybe the
|
||
|
|
custom-mode thing could set the variables, or a hook somewhere.
|
||
|
|
|
||
|
|
Apostrophes mess up Perl parsing in XEmacs but not Emacs. I thought
|
||
|
|
it was because XEmacs sets `font-lock-beginning-of-syntax-function'
|
||
|
|
after MMM does, but changing that that didn't fix it.
|
||
|
|
|
||
|
|
Support for: ASP
|
||
|
|
|
||
|
|
DEB and/or RPM packages would be nice.
|
||
|
|
|
||
|
|
The local-variables improvements can probably be used to set minor
|
||
|
|
modes locally to submode regions. This could replace tmmofl,
|
||
|
|
especially if we search for regions other than by regexps, say by
|
||
|
|
syntax properties.
|
||
|
|
|
||
|
|
Trap paragraph motion commands to stop at submode boundaries?
|
||
|
|
|
||
|
|
It would be nice if C-j ended a Mason one-liner and began a new one on
|
||
|
|
the next line. This is a rather Mason-specific thing, but other
|
||
|
|
classes might have similar single-line regions. Add a new submode
|
||
|
|
class argument, such as KEYMAP, or even ONE-LINE?
|
||
|
|
|
||
|
|
Allow a submode class to specify its allowable "parent" submode
|
||
|
|
classes. This could also be used to implement htp.p, by first
|
||
|
|
scanning for the function calls as a major-mode submode region, then
|
||
|
|
requiring that parent type for the HTML mode class. Nested submodes
|
||
|
|
alternate highlight colors, say with `mmm-secondary-submode-face'.
|
||
|
|
|
||
|
|
Ought %text in Mason to be a non-submode, since any Mason tags inside
|
||
|
|
it will probably be /edited/ as Perl (being, say, code examples)?
|
||
|
|
Only problem is it might confuse the programmer into thinking that
|
||
|
|
code will get executed. Maybe use a different face. Could do that
|
||
|
|
with another grouping class, say uneval-mason, that overrides the
|
||
|
|
faces of mason and has :parent mason-text, and allow a mode to specify
|
||
|
|
what about it changes depending on its parent, or a parent to specify
|
||
|
|
changes to its children, or a group to specify changes to its members.
|
||
|
|
|
||
|
|
Port or generalize the relevant bits from ERB indentation code to similar
|
||
|
|
packages for other languages.
|
||
|
|
|
||
|
|
Make re-parsing the buffer into regions incremental: take the position
|
||
|
|
of the most early change, see the submodes nesting there, and resume
|
||
|
|
parsing with that data. Shouldn't be too hard, conceptually. Maybe
|
||
|
|
even ignore the nesting, backtrack to a position where there are no
|
||
|
|
overlays, and re-parse from there (see mmm-parse-apply as a starting
|
||
|
|
point). Remember to handle delimiter inclusion and offsets as best
|
||
|
|
possible.
|
||
|
|
|
||
|
|
Thus, make re-parsing automatic (from syntax-propertize-function,
|
||
|
|
probably), making manual control unnecessary.
|
||
|
|
|
||
|
|
Remove XEmacs stuff?
|