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

[Dmitry Gutov]

On 03/02/2015 08:51 PM, Stefan Monnier wrote:

> Actually, for Info-mode, it wouldn't be "scoped", so it would need to be
> buffer-local (and even if it's scoped, it needs to say to which buffer
> it applies).

Sorry, can't follow you here. Not really familiar with Info-mode (even 
though I've tried to get into it a few times). But it's good if 
widen-function can have normal uses.

> IIUC, you want to remove the (START . END) data:
>
>     > + The non-nil value looks as follows
>     > +    ((START . END) LEFTMOST-COL)
>     The first element tries to re-implement what's currently being handled with
>     narrowing, successfully. Why?
>
> I understood this as saying you want to enforce the use of narrowing to
> pass to the sub-mode to bounds of its chunk.

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

Thus, removing (START . END) will amount to not introducing the 
aforementioned variable. Maybe never, maybe not just yet.

While LEFTMOST-COL is quite useful, (START . END) is less so, since it 
would replace what already works in e.g. mmm-mode is doing it now, *and* 
it would require more changes to existing modes.

> > It doesn't require any changes to the narrowing/widening logic, so the
> > question of whether narrowing is a good approach can again be deferred
> > until later.
>
> If you remove (START . END), then you decide that narrowing is the only
> way to go.

It can be added later, although I don't see a lot of value in it.

Honestly, if we had such variable, after we have prog-indent-line 
delegating to indent-calculate functions, I'd be very tempted to 
implement its support in prog-indent-line itself, instead of leaving it 
up to individual modes. And yes, using narrowing.