Re: C Mode: acceleration in brace deserts.

[Lennart Borgman]

On Fri, Dec 4, 2009 at 2:54 PM, Alan Mackenzie <address@hidden> wrote:
> 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?


Several. Some of them are trivial changes that should go into Emacs
core like put (put var 'permanent-local t) on major mode independent
variables, for example those on editor emulation minor modes. (Those
are no-doubts, but may need a bit of works for turning off these
modes.)

Others are non-trivial trying to fill semantic gaps in variable
locality. (Local in major mode, local in chunk etc.) I am unsure which
ones I have implemented at the momented. MuMaMo has been much of a
testing adventure.



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


Yes. This is what MuMaMo is about of course. (Even though it started
out with more special cases and much of it is not thought out yet.)


> 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?


For parsers: No.

I thought about it, but come to the conclusion that the only
reasonable approach is changing the low level buffer reading
primitives.

Too much is otherwise difficult to implement in the parsers. At least
that is what I believe. I could implement structures in MuMaMo that
are lists of buffer chunks in special modes (I started to do that),
but it have to be accessed at low level parts of the code and that
essentially means that code similar to what I suggested needs to
partly written in every parser (or in the low level reading
primitives).

Without the low level changes also all the old parsers have to be rewritten.


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