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

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

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

Info-mode's buffers (i.e. *.info files) contain several Info pages at
the same time, so when you "go to an Info page" what really happens is
that the mode narrows the buffer to the corresponding chunk in
the buffer.  Clearly this is not scoped inside a `let': the narrowing
will simply be in effect until you jump to another page, at which point
the narrowing will be changed to select another chunk.

> But it's good if widen-function can have normal uses.

Indeed, I don't see any problem there (I was just pointing out that
assuming let-like scoping is a bad idea).

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

I can't remember agreeing to this level of detail, but I'm not
necessarily opposed to that.

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

The issue is simply: how to tell the submode what are the bounds of its chunk.
If you don't do it by passing START/END, then you have to do it via side
channels such as by narrowing.

> While LEFTMOST-COL is quite useful, (START . END) is less so,

The information of the bounds of the chunk is indispensable (the END
part much less so, but the START part very much so).

> modes. And yes, using narrowing.

And I'm firmly opposed to imposing such an API.  I much prefer passing
START/END via dynamically scoped vars or via explicit arguments, and
then let the submode use a little wrapper that sets up narrowing and
calls the "same old" code (if the submode prefers using narrowing).


        Stefan