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

[Wedler, Christoph]

>> To get support by the authors of potential sub-modes, I would really
>> like to keep the effort for the sub-modes small.
>> Given that the indentation code of many prog-modes is probably the most
>> complex part, I would understand if the authors do not want to change it
>> considerably just to support some special-topic major mode.

> But it's not like there are many other options.  The options are either:
> - the submode doesn't know how to use previous chunks, so it doesn't
>   work correctly when the code is split into related chunks.
> - the submode does know how to parse and connect the various chunks.

That is not the difference we have:
 - You want to connect the chunks on-the-fly during the indent
   calculation.

 - I want to first connect the chunks and then do the indent
   calculation, or to be more exact:
   I want to first connect the previous chunks, get the parse state at
   the end of these chunks, and use this parse state as the initial one
   when indenting the current chunk.

This is exactly the difference between 5 (yours) and 4 (mine) below - and
the nice thing is that the submode can decide for itself whether to do it
like 4 or 5.

>>  4. SUB provides a function which creates a valid value for
>>     `SUB-extra-indentation-context' - valid arguments for that function
>>     would either be a string, or a list of buffer ranges.

>>     For C (assuming that a valid value for `c-extra-indentation-context'
>>     would look like the return value of `c-guess-basic-syntax'), this
>>     function could simply put the string / buffer chunks into a
>>     temporary buffer and call `c-guess-basic-syntax' at eob.

>>     In my use case, I would run this function once - in the literate
>>     programming case, you would run it whenever you delegate the
>>     indentation to the sub mode.

>>  5. If SUB decides that it can support the "multi-chunk case" directly
>>     in the indentation code (e.g. for performance improvements), it can
>>     do so without any change in the call by the main mode - the function
>>     introduced in stage 4 would then simply return the buffer-positions.

> I don't see much difference between 4 and 5: basically, the difference
> is between putting the code in the outer-mode or in the submode, but
> it'll be the same code.

Actually not.  In both cases, the submode provides the code.

In 4, the sub mode provides a function to compute the initial parse
state given the string / chunks.  It can do that quite simply by
inserting it/them into a temporary buffer and using a function which
computes the syntactic context at the end of that buffer - most major
mode already have such a function.  In other words: the effort for the
submode is small.

In 5, they follow your idea:
>>>>>> [...] 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.

To me, that seems to be more work.  And it would not be enough for me,
as my previous chunk is not part of the buffer, but provided by a
string.
Performance-wise, this could be better in the literate programming use
case, but not in my use case.

> In any case your patch looks good, feel free to install it.

If I might come back to your offer from last month (concerning
antlr-mode.el, actually) - it would be excellent if you could apply the
prog-mode.el.patch to the Emacs repository...

        Christoph