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

[Dmitry Gutov]

On 03/05/2015 11:46 AM, Wedler, Christoph wrote:

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

Yeah, maybe. The old indentation engine uses it in one place, but that's 
probably just a bad decision.

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

True. But I'd expect this to change, after either of the proposed 
schemes is implemented.

Even if the major mode indentation function does the widening itself, 
that should happen in one place, right? Or otherwise centralized, as you 
suggest below.

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

Right. In this case, indent-according-to-mode (for instance) could call 
`widen'. It's a rather straightforward change.

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

That sounds good to me too, but then we should call it something like 
`prog-submode-widen', right? And then maybe introduce 
`prog-submode-narrow-to-region' and `prog-submode-save-restriction'.

Et voilà, we now have a "new kind of narrowing", an approach Stefan, 
AFAICT, is still on the fence about.

The above is also a bit less flexible than having a `widen-function'.

> If the multi-mode indentation function additionally narrows to
> START/END, our approach also works for sub modes which do not call widen.

Yes, that's a nice bonus either way.

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

I believe it's totally fine to introduce. It's not like the currently 
written modes will suddenly break. Only if they don't follow the 
guideline, they'll work worse in a multi-mode context.

Note that your `prog-widen' suggestion (as well as 
`prog-indentation-context') also requires changes in those modes' 
implementations.