all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Lennart Borgman <lennart.borgman@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: C Mode: acceleration in brace deserts.
Date: Fri, 4 Dec 2009 13:54:44 +0000	[thread overview]
Message-ID: <20091204135444.GC1456@muc.de> (raw)
In-Reply-To: <e01d8a50912040234m76173f2cjaecdb54b89a2989@mail.gmail.com>

Hi again, Lennart!

On Fri, Dec 04, 2009 at 11:34:11AM +0100, Lennart Borgman wrote:
> Hi again Alan,

> >> , where `c-state-mark-point-min-literal' merely sets 3 variables already
> >> named.  I don't honestly see a way MuMaMo could disturb this state by
> >> accident.

> > Thanks. Mumamo needs to know because it switches major mode and that
> > normally kills buffer local variables.

OK.  But the buffer local variables c-parse-state and
c-parse-state-good-pos have existed since shortly after 4004 BC anyway.
Does MuMaMo have a list of such variables it handles specially?

> I have a bit trouble with this. I believe there is a simple solution,
> but it requires some low level changes to Emacs. Your changes here
> illustrates very well why such a change may be desireable to support
> mult major modes.

Yes.  MuMaMo (or something like it) should go to the core of Emacs.  It
could enable a gross simplification of CC Mode if there were to be some
automatic switchover to "C preprocessor mode".  I think there should be
a special type of overlay ("extent" in XEmacs) which is a "syntactic
island" to the syntax routines, and possibly (say, by binding some
variable to non-nil) for movement commands too, i.e. these routines
would "simply" jump over the island.  Such an island could have its own
syntax table, keymaps and (even) major mode.  There would, of course, be
numerous details to sort out.  Given how common mixed modes are (C
preprocessor stuff, "literate programming", here documents in shell
scripts, all sorts of things embedded in HTML pages, ....), it's a
wonder we don't already have the tools in the Emacs core.

> You are parsing the buffer from the beginning to find a state at a
> point (this state is here "in literal or not"). This of course breaks
> if there are chunks with different major modes in the buffer.

Yes.  Sorry.

> All parsers naturally behave like this (unless they are not
> specifically taught about multi major modes and its implementation).
> js2, semantic, font-lock are other examples.

Is there a set of guidelines anywhere as to how to make a mode
MuMaMoable?

> I think the easiest cure for this is to let them just see the parts of
> the buffers that are in the programming language they know of at the
> moment. (This is perhaps not enough but a good start that covers most
> possibilities - and can be used for all parsers.)

> This must however be implemented on a low level.

"Must be implemented" is in the passive.  ;-)  It's a pity programming
in C is such a dreary business.

> All C primitives reading the buffer must know about it. It is probably
> in most cases straightforward to implement it. A level between the
> buffer reading primitives and the buffer content is needed.  This
> hides the parts that should not be seen.

Agreed.

> It is probably possible to support your changes in MuMaMo now, but it
> is not easy while it will perhaps break easily instead. I have done
> something similar to syntax-ppss. I wish we could have the low level
> change instead.

Me too!

-- 
Alan Mackenzie (Nuremberg, Germany).




  parent reply	other threads:[~2009-12-04 13:54 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-03 16:21 C Mode: acceleration in brace deserts Alan Mackenzie
2009-12-03 16:26 ` Lennart Borgman
2009-12-03 16:59   ` Alan Mackenzie
2009-12-03 17:22     ` Lennart Borgman
2009-12-03 19:39       ` Alan Mackenzie
2009-12-03 19:57         ` Lennart Borgman
2009-12-04 10:34           ` Lennart Borgman
2009-12-04 11:03             ` Lennart Borgman
2009-12-04 11:56               ` Alan Mackenzie
2009-12-04 12:03                 ` Lennart Borgman
2009-12-04 12:18                   ` Lennart Borgman
2009-12-04 13:54             ` Alan Mackenzie [this message]
2009-12-04 19:03               ` Lennart Borgman
2009-12-05  2:11                 ` Lennart Borgman
2009-12-05  4:49                   ` Stefan Monnier
2009-12-04  5:31     ` Richard Stallman
2009-12-04 11:37       ` Alan Mackenzie
2009-12-05  6:50         ` Richard Stallman
2009-12-03 17:09 ` Stefan Monnier

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=20091204135444.GC1456@muc.de \
    --to=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=lennart.borgman@gmail.com \
    /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.