Re: C Mode: acceleration in brace deserts.

[Lennart Borgman <lennart.borgman@gmail.com>]

Hi Alan,

On Thu, Dec 3, 2009 at 8:39 PM, Alan Mackenzie <acm@muc.de> wrote:
> Hi, Lennart!
>
> The state of this cache is held entirely in the variables (all of them
> buffer local) initialised thusly:
>
> (defun c-state-cache-init ()
>  (setq c-state-cache nil
>        c-state-cache-good-pos 1
>        c-state-nonlit-pos-cache nil
>        c-state-nonlit-pos-cache-limit 1
>        c-state-brace-pair-desert nil
>        c-state-point-min 1
>        c-state-point-min-lit-type nil
>        c-state-point-min-lit-start nil
>        c-state-min-scan-pos 1
>        c-state-old-cpp-beg nil
>        c-state-old-cpp-end nil)
>  (c-state-mark-point-min-literal))
>
> , 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.


>> In the current situation I can only try to do that since the different
>> major modes may stamp on each other (I need some more Emacs support to
>> avoid that). But I can try. In some situations it is needed (for
>> example php may be split up in several parts (which html code between)
>> where the indentation in the next part should be aligned to that in
>> the prev part).
>
>> If you store it in a buffer local variable I am happy since all I have
>> to do then is to make that survive major mode switching. If you store
>> it in text properties I will be a bit more sad.
>
> Ah, yes.  I use text properties, too.  On each C macro, #if, etc., I set
> a category property on the "#" and one on (usually) the newline that
> terminates it.  I also put category properties on "<" and ">" to mark
> them as C++ template or Java generic delimiters.  Does this cause you
> problems at all?


If they are properly named so that no other modes uses them then I do
not think there is any problem.