all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: kai.grossjohann@gmx.net (Kai Großjohann)
Cc: emacs-devel@gnu.org
Subject: Re: [MMM] Re: narrow-to-here-document
Date: Tue, 08 Jul 2003 09:19:50 +0200	[thread overview]
Message-ID: <84ptklfpt5.fsf@lucy.is.informatik.uni-duisburg.de> (raw)
In-Reply-To: <20030707234541.GC11786@schilling.ugcs.caltech.edu> (Michael A. Shulman's message of "Mon, 7 Jul 2003 16:45:41 -0700")

"Michael A. Shulman" <shulman@ugcs.caltech.edu> 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
this.

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

Kai
-- 
~/.signature

  reply	other threads:[~2003-07-08  7:19 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-20 13:59 narrow-to-here-document Masatake YAMATO
2003-06-20 14:10 ` narrow-to-here-document Ilya Zakharevich
2003-06-20 16:26   ` narrow-to-here-document Masatake YAMATO
2003-06-21  7:15     ` narrow-to-here-document Stephen J. Turnbull
2003-06-21  8:01       ` narrow-to-here-document David Kastrup
2003-06-21 14:19         ` narrow-to-here-document Ilya Zakharevich
2003-06-21 14:48           ` narrow-to-here-document David Kastrup
2003-06-22  8:33             ` narrow-to-here-document Ilya Zakharevich
2003-06-23 17:10     ` narrow-to-here-document Kevin Rodgers
2003-06-25  6:10       ` narrow-to-here-document Masatake YAMATO
2003-06-25  8:04         ` narrow-to-here-document David Kastrup
2003-06-25  8:21           ` narrow-to-here-document Masatake YAMATO
2003-06-26  0:34             ` narrow-to-here-document Kim F. Storm
2003-06-26  5:30             ` narrow-to-here-document Richard Stallman
2003-06-25 23:18           ` narrow-to-here-document Stefan Daschek
2003-06-26  5:59             ` mmm-mode.el(Re: narrow-to-here-document) Masatake YAMATO
2003-06-26  6:12             ` narrow-to-here-document David Kastrup
2003-06-26 13:00               ` narrow-to-here-document Alan Shutko
2003-06-30  0:34                 ` narrow-to-here-document Miles Bader
2003-06-30  6:13                 ` narrow-to-here-document Kai Großjohann
2003-06-30 17:19                   ` narrow-to-here-document David Kastrup
2003-06-30 20:11                     ` narrow-to-here-document Kai Großjohann
2003-07-04  0:07                       ` narrow-to-here-document Stefan Monnier
2003-07-04  6:46                         ` narrow-to-here-document Kai Großjohann
2003-07-01 15:17                   ` narrow-to-here-document Richard Stallman
2003-07-04  0:32                     ` narrow-to-here-document Stefan Monnier
2003-07-07 23:45                       ` [MMM] narrow-to-here-document Michael A. Shulman
2003-07-08  7:19                         ` Kai Großjohann [this message]
2003-07-10 16:44                           ` Richard Stallman
2003-07-08 14:12                         ` mmm-mode needs (was: narrow-to-here-document) Stefan Monnier
2003-07-08 20:02                         ` [MMM] Re: narrow-to-here-document Richard Stallman
2003-06-25 16:58         ` narrow-to-here-document Kevin Rodgers
     [not found] ` <20030625.143750.116352160.jet@gyve.org>
2003-06-26  5:29   ` narrow-to-here-document Richard Stallman
2003-06-26  7:19     ` narrow-to-here-document Miles Bader
2003-06-26 17:45       ` narrow-to-here-document Tak Ota
2003-06-26 23:10         ` narrow-to-here-document David Kastrup
2003-06-27  2:07         ` narrow-to-here-document Miles Bader
2003-06-27  2:49       ` narrow-to-here-document Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84ptklfpt5.fsf@lucy.is.informatik.uni-duisburg.de \
    --to=kai.grossjohann@gmx.net \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.