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

[Wedler, Christoph]

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

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

Well, if we think that the advantage of a 2nd narrowing is greater then
the disadvantage (complexity) -I am not convinced-, then we should at
least reduce the disadvantage.  In this case, this means that the
"functional" narrowing should be visible - I am not sure how to do it if
the "visible" narrowing is smaller...

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

I do exactly that, but it does not work for python due to its cycling
functionality.  (It is also not ideal buffer-undo-list -wise.)

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

Well, this does not work always.  Let us assume that ANTLR would support
EmacsLisp code generation (there is actually some experimental plugin
somewhere) - in this case, the context of the actions would be some
implicit progn in some function.  A rule would look like

direct_declarator
    :   (   IDENTIFIER
            {
                (when (and (> (len $declaration)
                      (isTypedef $declaration)))
                  (print "define type etc"))
                (do-something)
                (do-something-more)
            }
        |   '(' declarator ')'
        )
        declarator_suffix*
    ;

The action would be only almost correctly indented - but not the last
two actions like (do-something).  Reason: these sexps are top-level in
the code chunk, and Emacs Lisp indents it not relatively to some
previous line, but at column 0.

We could again do some workaround if the indentation of the sub mode
indents at column 0 (that is exactly what I am currently doing), but it
again does not work for Python due to its indentation cycling.

   Christoph