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

[Stefan Monnier]

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

> It's hard for the "inner" code to know whether it's allowed to widen,
> so when in doubt, it probably shouldn't.

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

> But to keep the current code everywhere more or less unchanged, we can come
> from the other side and use an extra-flexible solution: introduce
> `widen-function' or `widen-bounds'.

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.  It's OK if the API *allows* the use of
narrowing, but requiring it would be a mistake.


        Stefan