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

[Wedler, Christoph]

>> First of all, we've already agreed (I think?) to move LEFTMOST-COL from that
>> variable to an argument of the indent-calculate function.

> I can't remember agreeing to this level of detail, but I'm not
> necessarily opposed to that.

I just remember the following: if we would introduce a
prog-indent-calculate-function, we could as well pass that value as
argument to that function (with a benefit that the value will be more
likely be respected).

But this would not be enough: we need to do something similar to
`indent-region-function', i.e. the different indent region functions
should also respect LEFTMOST-COL.

In my opinion, this would only worth the trouble if we can get
completely rid of `prog-indentation-context'.

>> While LEFTMOST-COL is quite useful, (START . END) is less so,

> The information of the bounds of the chunk is indispensable (the END
> part much less so, but the START part very much so).

I fully agree (END is just necessary for the theoretical case that the
indentation calculation checks lines after the current one).

>> modes. And yes, using narrowing.

> And I'm firmly opposed to imposing such an API.  I much prefer passing
> START/END via dynamically scoped vars or via explicit arguments, and
> then let the submode use a little wrapper that sets up narrowing and
> calls the "same old" code (if the submode prefers using narrowing).

I agree.  If we do the START/END boundaries via narrowing, we probably
induce too much work in major modes.  As I wrote earlier: all
functions which are called by the indent calculation must not call widen
anymore - with the dynamically scoped variable, they can just replace
(widen) by a call of a widen-like function which respects START/END - we
could actually introduce a function `prog-widen' in prog-mode.el which
does that.

In summary: as we do not get rid of `prog-indentation-context', we could
as well stick to the original proposal.