xref-backend-identifier-completion-table, may not using buffer local value for citre-tags

[Trisk3lion]

Hello!

Thanks you for a great package, it one of the most important packages for me to make possible to use Emacs for COBOL development!

I have problem thou; I have been experimenting with using file-specific tags because I can have several cobol files in a project and they can have the same variables with the same name, and sections with the same name but they don't have anything to do with each other.

So right now I'm setting citre-tags-files to a buffer-local value, ".tags/NAME-tag", and then I then the output of the ctags command is also modified.

This first seemed to work great, but then I discovered that I did't get any completions when I didn't have any symbol under point when running xref-find-definitions. From that I can tell it seems that my buffer-local value is not honored when citre-xref--completion-table-cache is created because the :tags-file key is just "path/to/dir/tags".

Is this something that can be fixed, or is there maybe a better way for me to do this?

Then there seems also to be a minor typo in citre-xref--completion-table-cache, :tage-file, instead of :tags-file.

Thanks again for your work!

[AmaiKinono]

Thanks for the report.

Could you run (citre-tags-file-path) in the file, and see if it returns the tags file path you want to use?

I do think your config is somewhat abusing the user option. Citre uses citre--tags-file internally for caching the tags file path, and it's buffer-local, so you may want to use it instead. Though it's an internal variable, it's pretty safe to do this and I can make it public.

Ideally, my suggestion is: if you have several irrelevant program in a directory, they should be small enough so you could read the code by in-buffer search and imenu easily. If a file is too large to do this, you should split it into several files and put them in a separate project. But I don't know if COBOL can do this and you may have reasons to not do this.

[AmaiKinono]

I've found the reason: The function returned by xref-backend-identifier-completion-table is called (by the xref framework, not by Citre) in the minibuffer. I think the minibuffer inherits default-directory of the file buffer so Citre could find a tags file based on that, but your buffer-local variables doesn't exist here.

We need a way to get "the buffer before entering the minibuffer" to fix this.

[Trisk3lion]

Thanks for you answer.

Running (citre-tags-file-path) does indeed return the path i want, "c:/path/to/project/.tags/PGMNAME-tags" in my case. I have hook on cobol-mode:

(setq-local citre-tags-files
            (list (concat ".tags/" (file-name-sans-extension (file-name-nondirectory (buffer-file-name))) "-tags")))

I tried doing the same but with citre--tags-file (but without list) but it didn't help.

Yes that seems resonable, then it reverts back to the default value of citre-tags-files i guess, which for me is ("tags" ".tags").

[AmaiKinono]

Should be fixed, please test.

[Trisk3lion]

I think this only fixes it when the cache is already created.

But when there is no cache, we call citre-get-tags with nil value for the tag, which means we get the same problem again. But it works for me with tagsfile as argument to citre-get-tags.

[AmaiKinono]

Ah, yes, you are right. I've fixed that too, please test.

[Trisk3lion]

Now it works perfectly! Thanks very much for fixing it! 👍

(Still a typo in citre-xref--completion-table-cache thou, :tage-file --> :tags-file :)

[AmaiKinono]

I think I've fixed the typo, and isearch agrees with me ;)

[Trisk3lion]

Indeed you have!

[Trisk3lion]

Hmm maybe it's not as easy.

I'm getting very large slowdowns with the with-minibuffer-selected-window in place. The minibuffer selections pops up pretty fast but then selecting and scrolling through the options is very slow.

Is the function called everytime we scroll or type something? Maybe the constant switching to the "original" buffer windows is causing the slowdowns?

I'm on windows, using selectum for the minibuffer.

[Trisk3lion]

2,524,639,648  99% - command-execute
  2,347,823,354  92%  - list
  2,347,822,298  92%   - xref--read-identifier
  2,347,822,298  92%    - let*
  2,347,821,878  92%     - cond
  2,347,821,878  92%      - let
  2,347,821,878  92%       - completing-read
  2,347,821,878  92%        - selectrum-completing-read
  2,195,723,674  86%         - selectrum--read
  2,139,163,832  84%          - selectrum--update
  2,069,677,952  81%           - selectrum--insert-candidates
  2,069,654,720  81%            - selectrum--vertical-display-style
  2,069,280,040  81%             - selectrum--metadata
  2,069,273,446  81%              - completion-metadata
  2,069,272,390  81%               - #<lambda 0x14a31baa432a1468>
  2,069,271,334  81%                - let*
  2,069,263,970  81%                 - gethash
  2,069,263,970  81%                  - citre-core-tags-file-info
  2,069,216,346  81%                   - citre-core--fetch-tags-file-info
  2,069,215,290  81%                    - citre-core-get-pseudo-tags
  2,069,204,346  81%                     - citre-core--get-lines
         99,958   0%                      + make-process
         33,048   0%                      + sleep-for
          2,112   0%                      + citre-core--strip-text-property-in-list
          1,656   0%                        eval
          6,720   0%                     + mapcar
          9,240   0%                   + file-truename
          6,308   0%                 + let
        122,720   0%             + selectrum--format-candidate

[AmaiKinono]

Is the function called everytime we scroll or type something?

You are right. I'm using vertico (on Linux) and it is called after every command. I didn't encounter any lagging, though.

[Trisk3lion]

I restarted Emacs and now it's smooth as butter again. So forget i said anything! :)