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

[Wedler, Christoph]

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

> Like you said: "I have avoided that for opascal and ruby via
> `narrow-to-region', but Python's indentation calls `widen'." Then Python 
> should avoid calling `widen'.

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

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

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

Most commands do not do any non-temporarily narrowing, they just use a
temporary narrowing, which is only "functional" anyway.

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

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

In other words, I would have to know the kind of indent calculation (and
Whether the current construct is a top-level one).

In Python, there is more than one correct indentation offset.  And since
the python mode does not want look at the complete syntax context (and
use the indentation offsets of all opening statements and similar), it
simply calculates the most inner valid indentation and cycles up to
column 0 - and in my case it should stop earlier.

Well, if I do the cycling myself, I would of course reject any positions
smaller than LEFTMOST-COL.  But then I am starting to implement SUB-mode
specific indentation code.

>> + If the indentation engine of the sub mode SUB depends on some
>> + global context, it may introduce a variable named
>> + `SUB-extra-indentation-context', which is to be bound like this
>> + variable by the main major mode.  For example, cc-mode might
>> + define `c-extra-indentation-context' which is to be bound to a
>> + list of SYNTACTIC-SYMBOL as explained in `c-offsets-alist'.")

> This, I guess, might be useful. But until many modes intend to use it, 
> what stops you from just keeping a small alist of (MAJOR-MODE . 
> OFFSETS-ALIST-VAR)?

What I mean is that `c-guess-basic-offset' should add some
SYNTACTIC-SYMBOLs at the end of the function.  This function is used
inside the indentation code - no own alist is of help here.

   Christoph