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

[Dmitry Gutov <dgutov@yandex.ru>]

On 02/18/2015 02:22 PM, Wedler, Christoph wrote:

> Well, if the indentation calculation in python-mode needs some context
> information which might be outside the visible part of the buffer, it
> must call `widen', right?  Of course, Python does that inside a
> `save-restriction'.

Well, I say it shouldn't, until we have a better `widen'.

>> And/or someone could try and solve the long-standing problem of
>> separating "visibility" narrowing and "functional" narrowing.
>
> To be honest, I do not fully understand what you mean here, or how it
> would solve the problem.

Some `widen' calls mean `don't go beyond this region', and some mean 
`don't show me anything beyond this region'. Indentation code would undo 
the latter kind, and the multi-mode code would use first kind.

> Cross-command-wise, there is one narrowing.  It is used for restricting
> some editing operations ("functional"?) and the visible part of the
> buffer.

Yes, the problem is it does both.

> If we would have two narrowings, then the "functional" should
> always be a subset of the "visible" narrowing (and the "functional"
> should be made somehow detectable for the user by a different background
> color).  Otherwise, things would get very confusing for the user.
>
> Then, for python-mode not to call widen itself, the "functional" region
> must be widened, which would imply a "visible" widen with the condition
> above.  In other words, pyhon users could not use narrowing when they
> want to get a correct indentation.

I believe it will be in reverse. Though many editing commands will have 
to respect the "visible" narrowing, instead of "functional".

>> LEFTMOST-COL, likewise, can by added by the calling function. No need to
>> make the submode's indentation function be aware of it.
>
> As Stefan has mention, it would first require that the mode not just
> indents the line, but also has a function which returns the correct
> indentation.

Not necessarily: you also can adjust the indentation after the submode 
applies it.

> Even if we have this, things are not that easy - we start with the
> non-Python case:
>   - some indent calculation return the correct indentation based on the
>     indentation of previous lines - here, I won't have to add anything
>     (given that I calculate the correct index of the first SUB-line myself,
>     which I can do), except sometimes for top-level constructs
>   - some indent calculation return the correct indentation based on the
>     syntactic context - here, I would have to add LEFTMOST-COL

Currently, I'm using this trick: narrow, then add LEFTMOST-COL at the 
beginning of the region. In the end, remove them.

But using `line-indentation-function' would avoid it, too.