Re: Specifying mode in file variables trouble

["Richard M. Stallman" <rms@gnu.org>]

    >     * If a variable is bound locally by one of the major modes used within
    >     mumamo, or by the mode hooks it runs, then kill it when moving to a
    >     chunk in another major mode.

    Do you mean the third case aboove here?

Yes.

					    I think this is a good idea.
    This is what I have implemented now in the latest sources (and that I
    sent here).

Ok.

    >     * Any other buffer-local variable should survive through motion between
    >     chunks.

    I am not sure about this one, but I think it would be better to use the
    third case for these variables too (and that is what I do now) if not
    their 'permanent-buffer local property is non-nil.

That is surely not right, because it means that almost all minor modes
can get lost when moving between chunks.

I think you should switch to what I proposed.

    > Can you find any use cases where this would not be right?

    Let say that the user for example want to use another indentation step
    for a specific chunk type. Then my comment above would perhaps apply.

How would a user specify variable values for particular chunk types?
Does mumamo have a facility for that?  I think only a special mumamo
facility could make this convenient.

That facility would implement whatever chunk-switching behavior is
most suitable.

So it looks my simple proposal is adequate.

    I am a bit worried by this complexity for the users.  One way to avoid it
    would perhaps to introduce the concept of a new "persistent level"
    between 'permanent-local=t and 'permanent-local=nil. A level that would
    be like 'permanent-local=t but just for the current buffer.

That might be a good idea if we really need it.
But my proposal is simpler:

     * If a variable is bound locally by one of the major modes used within
     mumamo, or by the mode hooks it runs, then kill it when moving to a
     chunk in another major mode.

     * Any other buffer-local variable should survive through motion between
     chunks.

So unless we see a use case for which this isn't right,
why not stick with it?