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

[Stefan Monnier]

> OK, I append a patch for prog-mode.el below.

Thanks, see comments below.

>> That requires some cross-knowledge of the two modes.  It's not ideal,
>> but I guess it's OK.
> You are right, it is not ideal.  I do not think it requires cross-knowledge,
> just some knowledge by the outer mode about the inner (bad for me ;-))

That's right.

> What I deduce from your text is that you do not like to have this
> variable "polluted" by some sub-mode specific stuff - and I do agree.

Well, I don't mind about having the info in this particular place, I'm
just worried about needing such knowledge, but indeed in your case you
probably do have that knowledge (ANTLR does specify that the embedded
C code should be a sequence of statements rather than a sequence of
declarations, say).

> Instead, I added a paragraph in the doc string that sub modes can define
> their own `SUB-extra-indentation-context', which would have the
> additional advantage that the variable content is documented.

Since this is a specific to a particular submode and both the inner-mode
and the outer-mode will need to agree on it, there's no need to document
it in the generic part of the interface.

>>> [...] that would require them to create a temporary buffer for the
>>> indent calculation.
>> Not necessarily: the submode can just go to the end of the previous
>> chunk, compute some state at that position and use that state as initial
>> context at MIN.
> ... if scan-lists, mode-specific skip-comments etc are prepared for this.

That's the responsibility of the sub-mode.

> It would also not help me

Indeed, in your case, there's no such "previous chunk" in the current buffer.
I was thinking of other multi-mode cases such as literate programming or
HTML+Javascript.

> as the previous chunks are not part of the ANTLR grammar buffer (but
> of the ANTLR code generation code) - I could just fake some context
> _string_. (Providing the context as a string would be actually the
> easiest for me.)

Hmm.. you mean you'd specify the c-extra-indentation-context as
a "pseudo previous chunk of code"?  That's a nice idea, in that it would
not encode specific knowledge about CC-mode, only specific knowledge
about the C language, so it'd be fairly generic.  So maybe
prog-indentation-context could come with a PREVIOUS value which could
either be a string (so the indentation should pretend that the code was
preceded by this string) or some other value (e.g. a function, or a list
of buffer positions) which gives access to the previous chunks.

> + When a major mode of such a main language decides to propagate the
                                                         ^^^^^^^^^
                                                         delegate

> + indentation of a line/region to the indentation engine of the sub
> + mode, it is supposed to bind this variable to non-nil around the call.
> +
> + The non-nil value looks as follows
> +    ((MIN . MAX) LEFTMOST-COL)
> +
> + MIN to MAX is the region consisting of code of the sub mode.
> + LEFTMOST-COL is the minimum column the indentation engine of the
> + sub mode should choose (instead of 0).

I think (BEG . END) would better match the names we use in other
contexts (on a naive/superficial reading, I assumed MIN/MAX were column
positions).

> + It is the task of the calling main mode to (temporary) set the
                                                ^^^^^^^^^
                                                temporarily

-- Stefan