GNU bug report logs - #24585
25.1; avoid hack in ggtags.el to run compilation-auto-jump timer

Previous Next

Package: emacs;

Reported by: Leo Liu <sdl.web <at> gmail.com>

Date: Sun, 2 Oct 2016 04:58:02 UTC

Severity: normal

Tags: moreinfo

Found in version 25.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #65 received at 24585 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 24585 <at> debbugs.gnu.org
Subject: Re: bug#24585: 25.1;
 avoid hack in ggtags.el to run compilation-auto-jump timer
Date: Fri, 07 Oct 2016 14:10:53 -0400
>> Not sure what you mean by "fired", but in any case, no: font-lock is not
>> used for that (tho it has been used at some point before
>> compilation-auto-jump was introduced, IIRC).  Instead, it's done via
>> syntax-propertize (which can be triggered in all kinds of ways,
>> including font-lock).
>
> This
>
> (defun compilation-mode-font-lock-keywords ()
>   "Return expressions to highlight in Compilation mode."
>   (append
>    '((compilation--ensure-parse))
>    compilation-mode-font-lock-keywords))
>
> and the only place in compile.el that mentions syntax-propertize is in a
> comment.

Duh!  Indeed, sorry, I mis-remembered.  Indeed, after first (ab)using
syntax-propertize I changed it to use the same approach but without
using syntax-propertize.

The point is the same, tho: the parse can be triggered by other things
than font-lock.  That's important because font-lock may be turned off.

>> How 'bout something like the following:
>>
>> - Add a new var compilation-pending-auto-jump set buffer-locally to
>> non-nil when compilation-error-properties calls run-with-timer.
>> - in compilation-auto-jump, check this var before doing anything and set
>> it back to nil.
>> - in ggtags, call compilation-auto-jump to make sure this timer is run
>> before yours.
> I think the issue is compilation-error-properties can happen after
> compilation-finish-functions. And calling compilation--ensure-parse in
> ggtags-global-handle-exit doesn't seem to help.

Hmm... calling compilation--ensure-parse *should* help.
More specifically, if you call compilation--ensure-parse up to point-max
from compilation-finish-functions, I can't think of any reason why
compilation-error-properties should be called afterwards.  If you can
get a backtrace of when that happens, it would help.

E.g. set a buffer-local var from compilation-finish-functions after
calling compilation--ensure-parse, and then add an assert in
compilation-error-properties to check that that var is not set yes.


        Stefan




This bug report was last modified 4 years and 227 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.