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

[Dmitry Gutov]

On 03/02/2015 06:48 PM, Stefan Monnier wrote:
> > Maybe we can say that code inside narrowing is only allowed to call
> > `generic' features, which may or may not perform widening themselves.
>
> I'm not sure what that buys us.

The multi-mode facilities can override the generic features via 
variables and/or advices, and disable widening, or make it somehow smarter.

> > The uses of `syntax-ppss' are harder to classify, but for font-lock we at
> > least have font-lock-dont-widen.
>
> But that's very crude.  It only accounts for those (rather rare) cases
> where narrowing is used to focus on a "sub-buffer" (i.e. Info mode, and
> old Rmail).  If something uses narrowing in those modes, then the result
> is plain breakage.

Indeed. But a multi-mode font-lock-fontify-region-function could perform 
the "smarter" widening, which wouldn't suffer from this exact problem.

> Most uses of narrowing should be widened, so the rule goes rather in
> the opposite direction (which is why font-lock-dont-widen defaults to
> nil, for example).

That wouldn't be my preference, but either way, there could be a way to 
disable or alter the behavior of `widen'.

While `widen-function' should be enough for this, maybe it's too 
flexible after all: that variable would never be used (correctly) with a 
buffer-local value. Only with local dynamic binding.

> Right, that's basically attacking the problem of distinguishing between
> different kinds of narrowing.
>
> But in any case, I think that relying on narrowing for the multi-mode
> support is a bad idea.

Maybe it's unfortunate that the main approaches to multi-mode 
implementation ended up using one of the two bad ideas (indirect buffers 
and narrowing), but they did, and we still don't have a good model from 
implementing the needed features in a different way.

> It's OK if the API *allows* the use of
> narrowing, but requiring it would be a mistake.

I don't think any version of the API requires it. But in the multi-mode 
context, I indeed expect it to be used.

Anyway, I think doing `widen' in prog-indent-line and prohibiting (in 
the docstring) prog-indent-calculate-functions from doing that should 
work just as well as prog-indentation-context (and better, from my 
standpoint).

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.