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

[Dmitry Gutov]

On 03/03/2015 06:32 PM, Stefan Monnier wrote:

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

That is interesting. Thanks. But considering this, we're unlikely to 
have `Info-mode' as a submode somewhere.

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

If widen-function is technically feasible, I'd rather go in this 
direction rather than introduce a variable everyone can ignore.

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

That is true. However, as long as we don't have solutions for the hard 
problems in the multiple-mode space, we might as well hold of on making 
the change that only solves the relatively easy one (and let 
multiple-mode solutions use `widen' for the time being).

It doesn't seem to me like it moves toward solutions for the hard 
problems, in any way.

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

Do you have a submode in mind that will benefit from this distinction 
(external vs internal narrowing) in practice, right now?