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

["Wedler, Christoph" <christoph.wedler@sap.com>]

>> Could be.  But using `widen' is a simple solution to those problems
>> (until you bump into problematic cases like Rmail and Info where
>> `widen' ends up widening too much).

It might be a good idea to disallow widen and narrw-xxx in these modes.

> Maybe, whenever `widen' is required, the original caller is doing 
> something wrong. The only valid use for `widen' is to undo the "visual" 
> sort of narrowing, enacted by the user interactively. If that feature 
> ever gets removed, I won't shed a tear.

I tend to agree, now that many commands like query-replace also work on
the highlighted region.  Non-friends of transient-mark-mode probably
won't agree.

>> Not really. The leftmost-col avoidance scheme I described further on would
>> deal with latex as submode just fine.
>
> Still: why do you want to avoid LEFTMOST-COL at all?

> I don't mind it that much, rather I'd like to avoid the variable
> submode-indentation-context.  If prog-indent-calculate-function gets
> passed LEFTMOST-COL instead of nothing, that can work well.

I would be happy with it.  Additionally to that function (and its
parameter LEFTMOST-COL), necessary changes would be:

 1. indent-for-tab-command and friends must call widen (inside a
    save-restriction of course) to allow the indentation of all modes
    work correctly with visible narrowing.

    (BTW, it could be even made that indentation of the modes work
    correctly with intra-defun narrowing - currently, EmacsLisp mode
    indents at col 0 here, C++ mode dumps, ...)

 2. prog-indent-calculate-function (or whatever it is called) AND ALL
    CALLED FUNCTIONS must not call widen (in order to work in the
    multi-mode case).  This could actually induce a bit more work than
    the change induced by submode-indentation-context.

> Benefits:

> - Since the value is passed to the function, the implementors are more 
> likely to pay attention and include it in the calculation.

True

> - It's somewhat more likely that they get it right. That nil is returned 
>  in all top-level places, is much harder to test interactively.

If LEFTMOST-COL is passed to the function in
prog-indent-calculate-function (and respected), there is no need to
distinguish between 0 (indentation offset calculated relatively to some
previous line) and nil (indentation offset calculated absolutely,
e.g. because the language construct is top-level).

     Christoph