Re: antlr-mode.el - need some support by python.el

[Stefan Monnier]

>> Maybe we should simply document that it's valid&expected for the inner
>> mode to add text-properties to the string.
> Which string?

IIUC we were talking about the case where PREVIOUS-CHUNKS is a string.
So: *the* string.

> Suppose an inner chunk A is followed by an "external" region,
> and then an inner chunk B. When we work on the contents of the chunk A, the
> new variable clearly won't include the contents of that chunk in the
> PREVIOUS-CHUNKS field.

What new variable?  You mean prog-indentation-context?

I think in the case you describe, the outer mode wouldn't pass a string
in PREVIOUS-CHUNKS but would instead pass a function that gives access
to the chunk A.

> Thus, it's not possible for the code working in A to
> cache some state in a way accessible to the chunk B (to anny code running
> when it's current).

The inner mode can keep track of its state via text-properties applied
to the actual buffer text.  So while working on chunk A, it could add
properties there, and while working on chunk B it would get access to
those properties via the region-bounds returned by the
PREVIOUS-CHUNKS function.

> Making PREVIOUS-CHUNKS store a list of position pairs (regions), or making
> it function, both sound better to me.

The intended use case where PREVIOUS-CHUNKS is a string is when this
"context" is a fixed short string, e.g. in a tool like yacc/bison, each
C chunk would use a PREVIOUS-CHUNKS along the lines of "void
pseudofunction () {" so as to make it clear that the chunk's content is
expected to be a function body rather than a top-level declaration.


        Stefan