[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs 24.5 second release candidate
From: |
Alan Mackenzie |
Subject: |
Re: Emacs 24.5 second release candidate |
Date: |
Fri, 3 Apr 2015 11:06:15 +0000 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
Hello, Eli.
On Thu, Apr 02, 2015 at 08:22:50PM +0300, Eli Zaretskii wrote:
> > Date: Thu, 2 Apr 2015 16:12:56 +0000
> > From: Alan Mackenzie <address@hidden>
> > Cc: address@hidden, address@hidden, address@hidden,
> > address@hidden
> > > Do you have an estimation of how much time you will need?
> > Perhaps this evening, perhaps tomorrow morning. It's one of these nasty
> > little bugs which looks totally wierd and random until one stumbles upon
> > the cause, after which it takes 2 minutes to fix.
> > > Also, was this bug caused by a recent commit, and if so, which one?
> > No, I don't think it was. I think it was "unmasked" by a recent bug
> > "fix", d69e9f1c24f37f36af33b0468c5a4e100dbb09b6 from 2015-02-01. Oleh
> > Krehel, the OP of the pertinent bug #20245, says that with that change
> > reversed, the bug symptoms don't manifest themselves. I haven't checked
> > this yet, but it sounds plausible. That fix is actually incomplete,
> > requiring Monday/yesterday's fix to make it complete.
> > I'm beginning to come round to the view that perhaps it might be best
> > just to take d69e9f1c24f37f36af33b0468c5a4e100dbb09b6 out of Emacs 24.5,
> > as Oleh Krehel has explicitly suggested.
> Sounds plausible. Please share your opinions after you study the
> issue.
I now understand precisely what the problem is. Sorry it's taken me a
little longer than "perhaps tomorrow morning".
The problem is in `c-fl-decl-start', a routine called (indirectly) from
every `jit-lock-fontify-now'. It attempts to check whether `start' is
within a declaration.
It does this by calling `c-beginning-of-decl-1' with a 500 byte search
limit. c-b-o-d-1 wrongly returns the same value for "hit search limit"
as "found beginning of declaration".
So CC Mode's fontification is directed to start 500 bytes back, in the
middle of a #include directive. This is not immediately apparent, only
becoming visible at the next redisplay.
This is indeed an old bug, unmasked by the d69e.... change rather than
caused by it.
I don't want to try to fix this in a few hours; a few days would be more
realistic.
--
Alan Mackenzie (Nuremberg, Germany).
- Re: Emacs 24.5 second release candidate, (continued)
- Re: Emacs 24.5 second release candidate, Stefan Monnier, 2015/04/02
- Re: Emacs 24.5 second release candidate, Eli Zaretskii, 2015/04/02
- Re: Emacs 24.5 second release candidate, Alan Mackenzie, 2015/04/02
- Re: Emacs 24.5 second release candidate, Eli Zaretskii, 2015/04/02
- Re: Emacs 24.5 second release candidate, Alan Mackenzie, 2015/04/02
- Re: Emacs 24.5 second release candidate, Stefan Monnier, 2015/04/02
- Re: Emacs 24.5 second release candidate, Eli Zaretskii, 2015/04/02
- Re: Emacs 24.5 second release candidate, Alan Mackenzie, 2015/04/02
- Re: Emacs 24.5 second release candidate, Eli Zaretskii, 2015/04/02
- Re: Emacs 24.5 second release candidate, Alan Mackenzie, 2015/04/02
- Re: Emacs 24.5 second release candidate,
Alan Mackenzie <=
- Re: Emacs 24.5 second release candidate, Eli Zaretskii, 2015/04/03
- Re: Emacs 24.5 second release candidate, Alan Mackenzie, 2015/04/03
- Re: Emacs 24.5 second release candidate, Eli Zaretskii, 2015/04/03
- Re: Emacs 24.5 second release candidate, Alan Mackenzie, 2015/04/03
- Re: Emacs 24.5 second release candidate, Eli Zaretskii, 2015/04/03
- Re: Emacs 24.5 second release candidate, Eli Zaretskii, 2015/04/04
- Re: Emacs 24.5 second release candidate, Nicolas Petton, 2015/04/04
- RE: Emacs 24.5 second release candidate, Drew Adams, 2015/04/04
- Re: Emacs 24.5 second release candidate, Nicolas Petton, 2015/04/05
- Re: Emacs 24.5 second release candidate, Eli Zaretskii, 2015/04/05