[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MMM] Re: narrow-to-here-document

From: Kai Großjohann
Subject: Re: [MMM] Re: narrow-to-here-document
Date: Tue, 08 Jul 2003 09:19:50 +0200
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux)

"Michael A. Shulman" <address@hidden> writes:

> 3. Better support in the syntax parsing routines allowing the caller
> to specify starting and ending positions and states.  One of
> our biggest problems is that submodes end up trying to parse their
> syntax beyond the beginning of their region and getting confused, so
> ideally we would be able to tell them where to start their parsing,
> and what state to start parsing in.  Sometimes the start state needs
> to be a continuation of the end state of the previous region in that
> mode (as with some literate programming, PHP, etc.), but sometimes
> it ought to be an independent start for each region.

Maybe it is sufficient to just allow for ignoring parts of the
buffer.  Let's say you are mixing modes A and B.  Let's further say
that each A chunk needs to be considered separately, and all the B
chunks should be considered to be concatenated (as in the literate
programming case).  Then you would arrange things so that when point
is in an A region all the rest of the buffer is ignored.  And when
point is in a B region then all A regions are ignored, but the other
B regions are not ignored.

The above is based on having a big buffer and to ignore some parts of
it, depending on the state we're in.

The complementary approach is to have many small buffers and do the
editing there, but have one big buffer which serves as a view into
the many small buffers.  This approach has been suggested by
Richard.  I feel that it is promising -- it avoids having to tweak
the individual modes.

The user does C-x C-f mixedfile RET.  Then mmm-mode divides the buffer
into chunks and puts each chunk into its own buffer.  The mixedfile
buffer is set up such that all keys are bound to forwarding functions.
That is, when you hit a key, mmm-mode figures out which buffer to go
to.  Then it goes to that chunk-buffer and executes the corresponding
command.  Then it looks at the changes in the chunk-buffer and
propagates them back to the mixedfile buffer.

That way, no troubles with syntax, no troubles with font-lock, no
trouble with parsing states.

When you want to start a new chunk, that might be a bit difficult.
But mmm-mode could offer a command mmm-split-chunk or something like

In the above I've used the term mmm-mode somewhat generically for the
desired feature; I didn't mean the current implementation


reply via email to

[Prev in Thread] Current Thread [Next in Thread]