emacs-devel
[Top][All Lists]
Advanced

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

Re: C Mode: acceleration in brace deserts.


From: Alan Mackenzie
Subject: Re: C Mode: acceleration in brace deserts.
Date: Fri, 4 Dec 2009 13:54:44 +0000
User-agent: Mutt/1.5.9i

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).




reply via email to

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