emacs-devel
[Top][All Lists]
Advanced

[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 20:04:31 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0

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.



reply via email to

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