Strange behaviour with gtags.el when using vertico

[punitagrawal]

I recently enabled vertico (+ orderless, consult) in my emacs configuration following the suggestions from the README.org. Since then I am seeing strange interaction with gtags.el which I use for code navigation. gtags.el is part of Gnu Global a source code cross-referencing utility similar to ctags, etags, etc.

Now looking for tag using gtags-find-tag (via M-.) takes a really long time and if I wait to see the result, it shows completions which seem to be a list of all possible combinations of the alphabet. See attached picture.

Things I have tried so far -

• Deleted and reinstalled vertico
• Switched from emacs 29.4 to 30.1
• Reproduced the problem on multiple machines

Has anybody seem something similar? Also let me know if you have any suggestions for debugging.

Configuration snippets for both vertico and gtags below

;; Enable Vertico.
(use-package vertico
  :custom
  ;; (vertico-scroll-margin 0) ;; Different scroll margin
  (vertico-count 20) ;; Show more candidates
  (vertico-resize t) ;; Grow and shrink the Vertico minibuffer
  ;; (vertico-cycle t) ;; Enable cycling for `vertico-next/previous'
  :init
  (vertico-mode))

;; Configure directory extension.
(use-package vertico-directory
  :after vertico
  :ensure nil
  ;; More convenient directory navigation commands
  :bind (:map vertico-map
              ("RET" . vertico-directory-enter)
              ("DEL" . vertico-directory-delete-char)
              ("M-DEL" . vertico-directory-delete-word))
  ;; Tidy shadowed file names
  :hook (rfn-eshadow-update-overlay . vertico-directory-tidy))

;; gtags.el
(autoload 'gtags-mode "gtags" "" t)
(setq gtags-suggested-key-mapping t)
(add-hook 'gtags-select-mode-hook
  '(lambda ()
     (setq hl-line-face 'underline)
     (hl-line-mode 1)
))
(add-hook 'c-mode-common-hook '(lambda() (gtags-mode t)))
(add-hook 'asm-mode-hook '(lambda() (gtags-mode t)))
(add-hook 'magit-revision-mode-hook '(lambda() (gtags-mode t)))

[minad]

Hi, I am not familiar with gtags. The issue is likely not due to Vertico, since Vertico only displays the completion candidates provided by the completion table. Check the default completion UI for comparison.

[punitagrawal]

Thank you very much for the reply.

Check the default completion UI for comparison.

If I disable vertico by commenting out the above snippets, gtags-find-tag works fine. I am assuming this is what you meant by default completion UI.

Not having done any elisp debugging, I will see if there is an easy way to debug what's happening when gtags-find-tag is invoked with and without vertico. I don't think it's a vertico issue - rather some unexpected interaction between the two packages.

[minad]

Maybe it is just the sorting in Vertico, see vertico-sort-function.

[punitagrawal]

Apologies for the delay in getting back. I spent sometime staring at the code and tracing it with the debugger.
Thanks to your hint, I think I understand the problem.

Below is the screenshot when vertico is not enabled.

The key point in the non-vertico scenario I was missing is that the completions are not requested by default. When vertico is enabled, completions are requested before the minibuffer is shown.

The project I was looking at is quite big (~3.6M symbols). This size causes long delay in gtags.el to return the list. And sorting (in vertico) probably adds some overhead too.

There are two options going forward -

1. Disable completion in gtags.el when looking up symbols - I have never used this feature.
2. I didn't know completions are possible during symbol lookup. It's looks like a useful search feature during development. If performance can be improved, it'll be good to enable it.

Hope the above makes sense. Writing the findings here in case somebody else hits a similar issue.