Closed matthiasbeyer closed 7 years ago
I'm sorry, but I've pretty much zero interest going back to the pre cargo metadata
state, where I had to inspect the cargo project by myself.
I honestly also don't quite see the point, because the current approach keeps the tags for each cargo project as minimal as possible, which reduces the possible number of collisions.
Maybe I missing something, but doesn't that make rusty-tags almost useless in a workspace project?
What do you mean by manual inspection? Evidently the containing crates are found, as each gets its own tags file. Would it be much work to add an option to keep this in a single file?
I would also be interested in this feature.
Maybe I missing something, but doesn't that make rusty-tags almost useless in a workspace project?
Very cargo project in the workspace gets tags for all of its dependencies. A dependency might also be another cargo project in the workspace. What would be more useful?
Ah, I did not realize that dependencies are included. Maybe I can solve my problems on a different level. But at least out of the box, counsel-etags does not find the separate tag files.
But at least out of the box, counsel-etags does not find the separate tag files.
I can‘t see why there should be any difference to a non workspace cargo project. Tools are searching for a tags file in the directory of the source and above.
As far as I can tell, counsel-etags indeed finds the local TAGS file, as you say, but it cannot find tags in a dependency. I took a look inside the TAGS file and found some lines at the bottom that look like this:
C:\Users\me\.rusty-tags\cache\base-634785015357407805.emacs,include
. Maybe this include functionality is not supported in counsel-etags. I will continue my investigation.
I'm having trouble finding a description of the include mechanism. Do you know a spec or something where I could read more about it? As of now, counsel-etags does not support it, but the author might be interested.
I don‘t know of a documentation of the whole etags file format.
But handling the „include“ seems quite straight forward. Get all tags files for reading by recursively finding all „include“ lines. And then read in the tags from all files in the same way.
I'm working on a workspace project, where the root Cargo.toml only contains the workspace section.
I would love if tags would be generated in one file rather than one
rusty-tags.vi
file for each crate in the workspace.