Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Duplicate entries in tags file (one with absolute path, one with relative path) #231

Open
mgedmin opened this issue Mar 19, 2019 · 2 comments · May be fixed by #232
Open

Duplicate entries in tags file (one with absolute path, one with relative path) #231

mgedmin opened this issue Mar 19, 2019 · 2 comments · May be fixed by #232

Comments

@mgedmin
Copy link

mgedmin commented Mar 19, 2019

Describe the bug

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

  1. 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
  2. Edit a file
  3. :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

    cmd="grep --text -Ev '^[^$tab]+$tab$UPDATED_SOURCE$tab' '$TAGS_FILE' > '$TAGS_FILE.temp'"

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.

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.

Fixes ludovicchabant#231 for Unix.  Unfortunately my Windows scripting skills are
insufficient to update plat/win32/update_tags.cmd
@mgedmin mgedmin linked a pull request Mar 19, 2019 that will close this issue
@ludovicchabant
Copy link
Owner

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.

@mgedmin
Copy link
Author

mgedmin commented Mar 20, 2019

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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants