[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dmitry Gutov
Subject: Re: antlr-mode.el - need some support by python.el
Date: Wed, 18 Feb 2015 17:29:41 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0

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

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

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]