Closed Trisk3lion closed 2 years ago
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.
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.
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")
.
Should be fixed, please test.
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
.
Ah, yes, you are right. I've fixed that too, please test.
Now it works perfectly! Thanks very much for fixing it! 👍
(Still a typo in citre-xref--completion-table-cache
thou, :tage-file
--> :tags-file
:)
I think I've fixed the typo, and isearch agrees with me ;)
Indeed you have!
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.
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
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.
I restarted Emacs and now it's smooth as butter again. So forget i said anything! :)
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 whencitre-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!