Navigating to other GTAGS project fails

[daghub]

• GNU Emacs, Windows 8.1, ggtags 0.8.6
• I have set up GTAGSLIBPATH to point at some library include directories
• I lookup a class that is declared in a header in the library include directories using ggtags-find-tag-dwim from a different GTAGS project.
• I get matches in the ggtags-global buffer. When I try to open one of the files, it fails because a relative path is attempted, which does not lead the right file.

If I do this change --path-style=shorter to -a it works because absolute paths are used. The drawback is that long absolute paths are shown even fot the current project.

[leoliu]

Hi @daghub,

Thanks for the report. I have a project that has GTAGSLIBPATH=$HOME/perl5/lib and it is working nicely so there is hope. BTW, you must run gtags in the directory where you set GTAGSLIBPATH to. Is this the case?

Sorry I can't gather from the description where the problem is. Could you provide steps (with a minimal sample project if possible) to reproduce the problem? Thanks.

Leo

[daghub]

Hi Leo, I have run gtags in the library directory too, and I find that global is run successfully to find thouse tags. In the result buffer ggtags-global I see the results, but when I hit enter to open a file, a relative path is used. The relative path is relative to the wrong location, probably relative to the library location, rather than the current project. When I try to open, emacs offers me to navigate to the directory where the relevant header is located. If i do, then it opens the correct file, according to the search result.

If i modify ggtags-global-build-command, changing --path-style=shorter to -a it works.

I have global 6.3.1 on Windows.

After the clarifications, do you need a reproducer?

Thank you for a great package by the way.

[leoliu]

Hi @daghub,

Let's see if we can get this sorted without a way to reproduce.

Does this happen if you start with emacs -Q? so that we know for sure either ggtags or global is at fault.

Could you give me the value of variable default-directory and ggtags-project-root in ggtags-global buffer and an example of a match, something like ../perl5/lib/perl5/darwin-thread-multi-2level/Scalar/Util.pm:9:package Scalar::Util;

Thanks for the kind words, Leo

[daghub]

If I run with emacs -Q I get the same result, with the only difference in that Emacs automatically brings up a Windows File selection dialog. In my config I have this disabled, so file selection is performed in the minibuffer.

This is how my global buffer looks

-- mode: ggtags-global; default-directory: "c:/ma/source/" -- Global started at Tue Oct 7 12:32:06

"global" -v --result=grep --color=always --path-style=shorter --from-here=105:"ma.hpp" "IMediaP" ../../mediam.h:60:typedef struct IMediaP IMediaPl; ../../mediam.h:1359: struct IMediaP ../../mediam/mediam.h:60:typedef struct IMediaP IMediaP; ../../mediam/mediam.h:1359: struct IMediaP 4 objects located (using 'C:\ma\build\an\libs\lms\include\debug\GTAGS').

Global found 4 matches at Tue Oct 7 12:32:07

The file dialog brings up the current project's base directory (not the library) and has the caption: "Find this match in (default ../../mediam.h)" Two steps up from that directory is not the location of mediam.h, though.

Here are the requested variable values:

default-directory is a variable defined in `C source code'. Its value is "c:/ma/source/" Local in buffer ggtags-global; global value is nil

ggtags-project-root is a variable defined in `ggtags.el'. Its value is "c:/ma/source/" Local in buffer ggtags-global; global value is unset

Thank you for your continued support!

[daghub]

And with the change in ggtags.el I mentioned, I get full paths in the search result, and then the files are found. So it seems the problem is related to calculating the full path based on the relative paths.

[leoliu]

So your GTAGSLIBPATH is pointed to C:\ma\build\an\libs\lms\include\debug but the output path is ../../mediam.h while in directory c:/ma/source/ and they are combined to produce the file path C:\mediam.h and emacs cannot find it. This might be a bug in global with its --path-style=shorter option.

Do you have a *nix system to try and see if the bug occurs there? Could you provide a way to reproduce? BTW, the latest global is 6.3.2 so the bug might be fixed already.

Thanks, Leo

[daghub]

Hi,

So your GTAGSLIBPATH is pointed to C:\ma\build\an\libs\lms\include\debug but the output path is ../../mediam.h while in directory c:/ma/source/ and they are combined to produce the file path C:\mediam.h and emacs cannot find it.

Correct!

The latest binary build available for Windows is 6.3.1, unfortunately. I can easily reproduce this by running global on command line on Windows.

Would would be the expected output for "global" -v --result=grep --color=always --path-style=shorter --from-here=105:"ma.hpp" "IMediaP"

in this case?

I will try to find some time and check on Linux.

Thanks, Dag

[leoliu]

Hi @daghub,

Maybe try some of the 6.2.x binaries for windows if there are any? I seem to remember someone came between 6.2.10 and 6.3.x to propose some changes to the path and the patch might need some releases to stabilise. I am just guessing though. Sadly I don't have a windows system to try it out.

HTH, Leo

[daghub]

Hi, Great idea, I will try the earlier versions too and see if it makes a difference. I'll let you know.

Thanks!

[daghub]

Hi, here are the results of running GNU global version 6.2.2:

$ global --version global - GNU GLOBAL 6.2.2 Copyright (c) 2012 Tama Communications Corporation License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. This is also commercial (for-profit) software based on BOKIN model. Please see the donation page http://www.gnu.org/software/global/donation.html.

Looks like the --color options is nor recognized:

$ "global" -v --result=grep --color=always --path-style=shorter --from-here=105:"ma.hpp" "IMediaP" c:\Program Files (x86)\GnuWin32\bin\global.exe: unrecognized option '--color=always' Usage: global [-adGilnqrstTvx][-e] pattern global -c[diIoOPrsT] prefix global -f[adlnqrstvx][-L file-list] files global -g[aGilnoOqtvVx][-L file-list][-e] pattern [files] global -I[ailnqtvx][-e] pattern global -P[aGilnoOqtvVx][-e] pattern global -p[qrv] global -u[qv]

nor the --path-stye option: $ "global" -v --result=grep --path-style=shorter --from-here=105:"ma.hpp" "IMediaP" c:\Program Files (x86)\GnuWin32\bin\global.exe: unrecognized option '--path-style=shorter' Usage: global [-adGilnqrstTvx][-e] pattern global -c[diIoOPrsT] prefix global -f[adlnqrstvx][-L file-list] files global -g[aGilnoOqtvVx][-L file-list][-e] pattern [files] global -I[ailnqtvx][-e] pattern global -P[aGilnoOqtvVx][-e] pattern global -p[qrv] global -u[qv]

Without those options I get: "global" -v --result=grep --from-here=105:"ma.hpp" "IMediaP" ../../mediam.h:60:typedef struct IMediaP IMediaP; ../../mediam.h:1359: struct IMediaP ../../mediamgr/mediam.h:60:typedef struct IMediaP IMediaP; ../../mediamgr/mediam.h:1359: struct IMediaP 4 objects located (using 'C:\ma\build\an\libs\lms\include\debug\GTAGS').

which is the same result as with 6.3.x

I think for now, I will have to use the workaround of modifying ggtags.el to supply the -a option (and remove the --path-style=shorter option).

[daghub]

Or, rather use --path-style="absolute".

[leoliu]

Hi @daghub,

Some of those new options are proposed by me and upstream implemented them ;)

Could you show me the output of running in windows shell (is it still cmd.exe) the command "global" -v --result=grep --color=always --path-style=shorter --from-here=105:"ma.hpp" "IMediaP" in the root of your project? Let's see if it is ggtags.el fault.

Please use the workaround i.e. by changing ggtags.el to use --path-style="absolute" for now. I might be able to test the bug on windows this weekend. I will try my best to fix it if I can ;)

Cheers, Leo

[daghub]

Hi, here is the output when running the command in a CMD prompt:

C:\ma\source>"global" -v --result=grep --color=always --path-style=shorter --from-here=105:"ma.hpp" "IMediaP" ../../mediam.h:60:typedef struct IMediaP IMediaP; ../../mediam.h:1359: struct IMediaP ../../mediam/mediam.h:60:typedef struct IMediaP IMediaP; ../../mediam/mediam.h:1359: struct IMediaP 4 objects located (using 'C:\ma\build\an\libs\lms\include\debug\GTAGS').

Brilliant, I look forward to the results, if you would be able test on Windows!

Regards, Dag

[leoliu]

From the CMD output, it looks like a bug in global itself. There is new build of global 6.3.2 for windows which might have fixed this issue ;)

[ghost]

Hi, I'm using global version 6.5.6 on Fedora 25 and I have the same problem.

[leoliu]

what are the symptoms?

[ghost]

When I'm on a project with generated tags and look up a function, I see matches, but when I try to navigate to a match, I'm presented with an option to choose a tag file, rather than automatically being taken to the matched file.

Here is my setup:

1. I have the following environment variables set:

   export GTAGSLIBPATH=~/obj/usr/include/                                       
   export MAKEOBJDIRPREFIX=~/obj

2. I went to /usr/include and ran gtags --objdir -v. I saw that tags files were generated in ~/obj/usr/include.
3. In Emacs, when I execute ggtags-find-tag-dwim, I see a couple of options in the mini buffer. When I try opening one of the matches, I'm asked to choose the location of the tags file. The default location is ~/obj/usr/include/, but the pre-filled location is the current working directory.

[leoliu]

Are these env vars GTAGSLIBPATH and MAKEOBJDIRPREFIX visible to emacs? Check process-environmentto find out.

[ghost]

Yes, both are visible, although, the absolute values are used.