bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20146: font-lock-extend-jit-lock-region-after-change: results are di


From: Alan Mackenzie
Subject: bug#20146: font-lock-extend-jit-lock-region-after-change: results are discarded instead of being returned.
Date: Fri, 20 Mar 2015 16:07:44 +0000
User-agent: Mutt/1.5.23 (2014-03-12)

Hello, Stefan.

On Fri, Mar 20, 2015 at 10:20:24AM -0400, Stefan Monnier wrote:
> > In font-lock-extend-jit-lock-region-after-change in font-lock.el, the
> > new fontification region is calculated by funcalling
> > font-lock-extend-after-change-region-function.  The result of this
> > funcall is assigned to internal variables beg and end.

> > To return these values to the caller, they should be written to the
> > dynamically bound variables jit-lock-start and jit-lock-end.  This is
> > only done in the case

> >     (memq 'font-lock-extend-region-wholelines
> >            font-lock-extend-region-functions)

> > .  It should be done in all cases.

> I'm thinking of removing font-lock-extend-after-change-region-function
> altogether anyway: cc-mode is the only user and it has a workaround in
> place for when the "feature" is absent, so it's really just useless.

Well, I've fixed it anyhow.

I don't think you should remove f-l-exent-a-c-region-function.  The only
alternative is, as you say, a workaround, one that involves advising
functions.  Back in 2006 when the facility was implemented, the need to
use advice was taken to be a deficiency in Emacs, a bug to be fixed.
This particular bug was fixed.  Also, the fact the only one package uses
something is not a good reason to remove features.  If it were, Emacs
might well be a lot slimmer than it is.

Right at the moment I am plagued by Font/Jit Lock's messing around with
the font-lock region's start position.  Despite CC Mode quite definitely
setting this region (via the said
font-lock-extend-after-change-region-function), Font/Jit Lock insists on
starting at a different place, one with a different syntactic context.

Perhaps we could implement the convention that when a major mode has
positively set the font-lock region's start and end points, these should
be accepted by F/J-lock, but when not, F/J-lock should be free to alter
them (as it typically does now).  The existence of
font-lock-extend-after-change-region-function makes this distinction
possible.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

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