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

[Dmitry Gutov]

On 02/18/2015 06:10 PM, Wedler, Christoph wrote:

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

I believe, if this distinction will sometime come into life, the 
"functional" kind will only be applied programmatically, and won't stay 
on between commands. So there'll be nothing to highlight.

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

I don't know about cycling. Sounds like something that could be handled 
in a different way.

buffer-undo-list should be fine: several changes performed by one 
command invocation will be treated as one by undo.

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

Yes, sorry. I'm actually doing the same as you: 0 column means top-level 
(and top-level means add N columns). The whitespace-padding is only 
performed in a certain, special case.

Looking at `python-indent-line-function', it seems like it's going to 
cycle only under certain conditions (this-command is the same as 
last-command, and it's in the special list). From what I understand, it 
might even be what the user expects. If not, why not bind `this-command' 
to some odd value?