Open Andreas-Krebbel opened 2 years ago
Encountered the same error today. Maybe it can be fixed with some quick workaround?
Same error here... Any solution yet?
Same here (again). The issue is obviously racy; it worked for some time, but now it's persistent again. I'm currently circumventing this very crudely, by preserving the compilation buffer even if there's only one match:
diff -u /home/arnez/.emacs.d/elpa/ggtags-20220511.610/ggtags.el\~ /home/arnez/.emacs.d/elpa/ggtags-20220511.610/ggtags.el
--- /home/arnez/.emacs.d/elpa/ggtags-20220511.610/ggtags.el~ 2022-06-01 14:07:40.781288558 +0200
+++ /home/arnez/.emacs.d/elpa/ggtags-20220511.610/ggtags.el 2022-07-20 20:18:20.920608602 +0200
@@ -1668,11 +1668,12 @@
;; - http://debbugs.gnu.org/23987
;; - https://github.com/leoliu/ggtags/issues/89
;;
- (pcase (cl-find 'compilation-auto-jump timer-list :key #'timer--function)
- (`nil )
- (timer (timer-event-handler timer)))
- (ggtags-navigation-mode -1)
- (ggtags-navigation-mode-cleanup buf t)))))
+ ;; (pcase (cl-find 'compilation-auto-jump timer-list :key #'timer--function)
+ ;; (`nil )
+ ;; (timer (timer-event-handler timer)))
+ ;; (ggtags-navigation-mode -1)
+ ;; (ggtags-navigation-mode-cleanup buf t)
+ ))))
(defvar ggtags-global-mode-font-lock-keywords
'(("^Global \\(exited abnormally\\|interrupt\\|killed\\|terminated\\)\\(?:.*with code \\([0-9]+\\)\\)?.*"
I faced this same issue in the past and finally decided to use xref
with ggtags
as a backend to avoid these races.
The xref
backend code section also seems to have a race, but I recently sent PR #224 which seems to fix it.
I faced this same issue in the past and finally decided to use
xref
withggtags
as a backend to avoid these races.The
xref
backend code section also seems to have a race, but I recently sent PR #224 which seems to fix it.
At the end I also decided to use xref
and all the other emacs provided infrastructure for everything (imenu
, completions
, project.el
). And as I also faced issues there I decided to go with my own simpler and clean implementation optimized for tramp support: https://github.com/Ergus/gtags-mode
It is already in elpa btw.
Trying to jump to a definition with one match in a file accessed via ssh using tramp gives me (with emacs 27.2): Error running timer ‘compilation-auto-jump’: (wrong-type-argument stringp nil)
This looks quite similar to #89
Enabling tracing for a few of the involved functions indicates that ggtags-navigation-mode-cleanup gets invoked somewhere in the middle of compilation-find-file. The ggtags buffer is gone afterwards what triggers the problem:
Apparently when tramp waits for the output of the ssh process it tries to do other stuff. It can be prevented to invoke timers by turning the last parameter of accept-process-output to -1 but this does not prevent sentinels from getting called. The "compilation-sentinel" then invokes the cleanup routine which throws away the buffer.
To me it looks like ggtags-navigation-mode-cleanup needs a way to prevent itself from running in parallel to the execution of the compilation-auto-jump code path. ggtags already makes sure to call the compilation-auto-jump synchronously before calling ggtags-navigation-mode-cleanup. So perhaps we can also remove it from the timer list to make sure it doesn't get called another time in parallel?