[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: Mon, 02 Mar 2015 21:31:31 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0

On 03/02/2015 08:51 PM, Stefan Monnier wrote:

Actually, for Info-mode, it wouldn't be "scoped", so it would need to be
buffer-local (and even if it's scoped, it needs to say to which buffer
it applies).

Sorry, can't follow you here. Not really familiar with Info-mode (even though I've tried to get into it a few times). But it's good if widen-function can have normal uses.

IIUC, you want to remove the (START . END) data:

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

I understood this as saying you want to enforce the use of narrowing to
pass to the sub-mode to bounds of its chunk.

First of all, we've already agreed (I think?) to move LEFTMOST-COL from that variable to an argument of the indent-calculate function.

Thus, removing (START . END) will amount to not introducing the aforementioned variable. Maybe never, maybe not just yet.

While LEFTMOST-COL is quite useful, (START . END) is less so, since it would replace what already works in e.g. mmm-mode is doing it now, *and* it would require more changes to existing modes.

It doesn't require any changes to the narrowing/widening logic, so the
question of whether narrowing is a good approach can again be deferred
until later.

If you remove (START . END), then you decide that narrowing is the only
way to go.

It can be added later, although I don't see a lot of value in it.

Honestly, if we had such variable, after we have prog-indent-line delegating to indent-calculate functions, I'd be very tempted to implement its support in prog-indent-line itself, instead of leaving it up to individual modes. And yes, using narrowing.

reply via email to

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