You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've noticed duplicate tags in files I've edited. They look like this:
# pri kind tag file
1 F f createReportCompetencyModel /home/mg/src/ivija/src/ivija/threesixty/scoringmodel.py
def createReportCompetencyModel(threesixty):
2 F f createReportCompetencyModel src/ivija/threesixty/scoringmodel.py
def createReportCompetencyModel(threesixty):
Steps to reproduce
Generate a tags file externally -- here I used z3c.recipe.tag, which is a horribly complicated solution that ends up invoking exuberant ctags and passing a bunch of absolute directory names to it
Edit a file
:tsel any name in the file you've edited
Share your setup
What OS and version of Vim are you using? Ubuntu 18.10, Vim 8.1.1017
What version of ctags, gtags, or whatever do you have installed? Exuberant Ctags 5.9~svn20110310 from Ubuntu repos
Are you using g:gutentags_cache_dir? No
Post the logs
I would like to skip this step at this point, if you don't mind, because it seems clear what is happening: the tags file contains absolute filenames, but gutentags assumes it will contain relative ones, according to #70 (comment).
Proposal
I have an idea: why not remove all old entries for a file irrespective of whether it used an absolute or a relative filename? Specifically, in plat/unix/update_tags.sh where currently you do
how about matching both relative and absolute path versions of $UPDATED_SOURCE? This can be painful to compute in portable shell, so maybe compute it in vimscript and pass it as an extra option (-a file=, for alternate path)?
That should remove the possibility of mixups without having to rely on guessing about which style is being used in a project. What do you think?
I think I can create a PR implementing this.
The text was updated successfully, but these errors were encountered:
mgedmin
added a commit
to mgedmin/vim-gutentags
that referenced
this issue
Mar 19, 2019
Since we cannot know in every case whether the tags file contains
absolute or relative pathnames, let's remove old tags that use either
version of the pathname.
Fixesludovicchabant#231 for Unix. Unfortunately my Windows scripting skills are
insufficient to update plat/win32/update_tags.cmd
Hi!
I'd rather someone changed z3c.recipe.tag to generate relative paths, since they're a lot nicer to work with than absolute paths... absolute paths get truncated when using Vim in a smaller window or screen.
Do you have a good reason to prefer absolute paths? In which case, another option would be to change Gutentags to optionally generate absolute filenames instead.
To be honest, the idea didn't occur to me. In fact I would prefer relative paths -- and hey, apparently z3c.recipe.tag has a --tag-relative command-line option.
(I still think it would be nice if vim-gutentags could deal with all sorts of tags out of the box, without the users having to research why duplicate tags appear, and how to convince their tag-generating tools to behave differently. Solving the problem for everyone vs solving it for myself kind of thing. I'm rambling, sorry, I'll stop now.)
Describe the bug
I've noticed duplicate tags in files I've edited. They look like this:
Steps to reproduce
tags
file externally -- here I used z3c.recipe.tag, which is a horribly complicated solution that ends up invoking exuberant ctags and passing a bunch of absolute directory names to it:tsel
any name in the file you've editedShare your setup
ctags
,gtags
, or whatever do you have installed? Exuberant Ctags 5.9~svn20110310 from Ubuntu reposg:gutentags_cache_dir
? NoPost the logs
I would like to skip this step at this point, if you don't mind, because it seems clear what is happening: the tags file contains absolute filenames, but gutentags assumes it will contain relative ones, according to #70 (comment).
Proposal
I have an idea: why not remove all old entries for a file irrespective of whether it used an absolute or a relative filename? Specifically, in
plat/unix/update_tags.sh
where currently you dohow about matching both relative and absolute path versions of $UPDATED_SOURCE? This can be painful to compute in portable shell, so maybe compute it in vimscript and pass it as an extra option (-a file=, for alternate path)?
That should remove the possibility of mixups without having to rely on guessing about which style is being used in a project. What do you think?
I think I can create a PR implementing this.
The text was updated successfully, but these errors were encountered: