Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

final message interpreted as a match #226

Open
p-m opened this issue Oct 3, 2023 · 2 comments
Open

final message interpreted as a match #226

p-m opened this issue Oct 3, 2023 · 2 comments

Comments

@p-m
Copy link

p-m commented Oct 3, 2023

Hi,

When using latest ggtags.el (master) and latest emacs (also from
master), the last message in the compilation buffer is interpreted
as a match. Example:

-*- mode: ggtags-global; default-directory: "~/.../" -*-
Global started at Mon Oct  2 17:23:19

global -v --result=grep --color=always --path-style=shorter
--from-here=66:Src/Appli.c -- main
Src/Hex.c:57:    main();
Src/crt0.s:96:          call  _main              ; call user's main()
Src/crt0.s:273:        call    _main           ; call the user's main()
3 objects located (using '/home/peter/.../GRTAGS').

G found 3 references at Mon Oct  2 17:23:19, duration 0.03 s

The part "G found 3 references at Mon Oct 2 17" is green and the
"23" is blue. So when invoking "next-error", instead of stopping after
the 3rd match with "Moved past last match", I get a question like
"Find this match in (default Global found 3 references at Mon Oct 2 17): ..."

How could I avoid this situation please?

Also, the counters in the mode-line are wrong: I get "7 0 0" instead of "3 0 0".

(With emacs-27.2, there is no problem, but the counters are "6 0 0".)

TIA for any hints, Peter

@leoliu
Copy link
Owner

leoliu commented Oct 3, 2023

Hi @p-m,

Upstream may have changed something.

See the definition of (define-compilation-mode ggtags-global-mode... which overrides a bunch of compilation-mode variables. In particular, check compilation-error-regexp-alist is correctly set and in ggtags-global-error-regexp-alist-alist.

What I find really useful in dealing with similar situation is get a copy of compile.el from 27 and master and diff them to find suspicious changes.

@p-m
Copy link
Author

p-m commented Oct 3, 2023

In particular, check compilation-error-regexp-alist is correctly set and in ggtags-global-error-regexp-alist-alist.

Thanks. Indeed, after removing line 1685, it works.
(The count is still wrong, but it's not really important.)

What I find really useful in dealing with similar situation is get a copy of compile.el from 27 and master and diff them to find suspicious changes.

Please find attached the diff.
compile.el.diff.txt

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants