Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch

[Stefan Monnier]

> E.g., what you suggest would require a serious surgery on the design
> of the display engine,

Not just the display engine: you'd also have to figure out how to handle
the load&save of this, how to get things like next-line or
rectangle-mark-mode to handle it properly, ...

It might be an interesting idea that could be occasionally attractive
(maybe for Gnus's rendering of attachments?), but for mmm-mode, it
sounds like adding problems rather than providing a solution.

> So I really think we should define the requirements first.

To me, the requirements look like:
- font-lock and syntax-propertize, each sub-part according to its own
  mode and according to its context which can depend on the immediately
  preceding chunk (even tho it's in a different mode) as well as on some
  earlier chunk in the same mode.
- indentation is done according to the mode to which BOL belongs, I think.
- there can be nesting relationships between chunks, e.g. with two major
  modes A and B, a sequence of chunks of "A1, B1, A2, B2, A3" could
  represent "(A1 (B1) A2 (B2) A3)" or "(A1 (B1 (A2) B2) A3)", where
  indentation of A3 could depend on A1 in the second case but on A2 in
  the first.
- some minor modes might be specific to "chunks in major mode A", while
  others are "global to the whole buffer".
- key-bindings should probably be looked up according to the "mode at
  point".
- navigation should ideally understand the overall structure of the
  buffer, so forward-sexp knows how to jump over a "sub-chunk" written
  in another mode.
- M-; and many other such commands should use the "mode at point".
- not sure whether imenu should combine the list of definitions of all
  chunks in the buffer.
- commands which are mode-agnostic (such as next-line or
  rectangle-mark-mode) should be unaffected.
Not sure if it's the kind of requirements you were thinking about.


        Stefan