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

[Wedler, Christoph]

>> 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

> How is it "too much work"? I've written my share of indentation code, 
> and the only related function that I found useful were 
> `save-restriction' and `narrow-to-region'.

save-restriction: sure, every use of narrow/widen in indentation code
should be in a save-restriction.

narrow-to-region: for indentation code, this is probably only multi-mode
related

widen: If you grep for `widen' in EMACS/lisp/progmodes, you find quite a
few matches.  Probably half of them are in indentation functions or
functions which are used by indentation functions.

And actually, they uses are _correct_, as the indentation commands
should also work when the user has used narrowing (via C-x n n and
friends).
(As I wrote earlier, quite a few major modes do not work correctly
or at least strange with intra-defun narrowing: C++, EmacsLisp, ...).


If we do the START/END boundaries only via narrowing, only the outer
indentation command should use widen (which the multi-mode code won't
call), all called function are not allowed to use widen anymore.  In
other words, the widen calls must be moved to the outer commands.

If we do the START/END boundaries via the dynamically scoped variable,
the major modes just have to replace their (widen) call by (prog-widen),
a widen function which respects prog-indentation-context.
If the multi-mode indentation function additionally narrows to
START/END, our approach also works for sub modes which do not call widen.

Yes, relying on dynamically scoped variable is not completely nice, but
there had been no programming guideline that indentation code should
only call widen only once directly at the beginning (as I said before:
inside save-restriction, of course).
I would not introduce such a guideline after decades...