add support for GNU Global? #191

linusboyle · 2018-07-26T03:12:18Z

g:Lf_Ctags doesn't work for gtags,no matter what I set it to be,gtags or global or gtags-cscope.It seems only ctags is supported right now. Anyway,I can use cscope and just lack some fuzzy and regex things,but maybe you can enhance this great plugin?

The text was updated successfully, but these errors were encountered:

kgfly · 2018-10-26T17:38:55Z

+1

renchili · 2019-01-30T03:54:04Z

+1

xaljer · 2019-02-23T05:06:51Z

I think fuzzy find symbol reference of gtags (or some other provider) is also very useful feature.

linusboyle · 2019-02-23T07:23:43Z

Well, it's not difficult to script myself if #144 is implemented. Likewise the ctags support will be unnecessary then

kgfly · 2019-02-24T07:23:25Z

GNU Global support is great. But I think ctags support is a fundamental need though~

add support for GNU Global

Yggdroot · 2019-04-18T07:42:47Z

Leaderf gtags -h:

usage: 
Leaderf[!] gtags [-h] [--remove] [--recall]
Leaderf[!] gtags --update [--gtagsconf <FILE>] [--gtagslabel <LABEL>] [--accept-dotfiles]
                 [--skip-unreadable] [--skip-symlink [<TYPE>]] [--gtagslibpath <PATH> [<PATH> ...]]
Leaderf[!] gtags [--current-buffer | --all-buffers | --all] [--result <FORMAT>] [COMMON_OPTIONS]
Leaderf[!] gtags -d <PATTERN> [--auto-jump [<TYPE>]] [-i] [--literal] [--path-style <FORMAT>] [-S <DIR>]
                 [--append] [--match-path] [--gtagsconf <FILE>] [--gtagslabel <LABEL>] [COMMON_OPTIONS]
Leaderf[!] gtags -r <PATTERN> [--auto-jump [<TYPE>]] [-i] [--literal] [--path-style <FORMAT>] [-S <DIR>]
                 [--append] [--match-path] [--gtagsconf <FILE>] [--gtagslabel <LABEL>] [COMMON_OPTIONS]
Leaderf[!] gtags -s <PATTERN> [-i] [--literal] [--path-style <FORMAT>] [-S <DIR>] [--append]
                 [--match-path] [--gtagsconf <FILE>] [--gtagslabel <LABEL>] [COMMON_OPTIONS]
Leaderf[!] gtags -g <PATTERN> [-i] [--literal] [--path-style <FORMAT>] [-S <DIR>] [--append]
                 [--match-path] [--gtagsconf <FILE>] [--gtagslabel <LABEL>] [COMMON_OPTIONS]
Leaderf[!] gtags --by-context [-i] [--literal] [--path-style <FORMAT>] [-S <DIR>] [--append]
                 [--match-path] [--gtagsconf <FILE>] [--gtagslabel <LABEL>] [COMMON_OPTIONS]

[COMMON_OPTIONS]: [--reverse] [--stayOpen] [--input <INPUT> | --cword]
                  [--top | --bottom | --left | --right | --belowright | --aboveleft | --fullScreen]
                  [--nameOnly | --fullPath | --fuzzy | --regexMode] [--nowrap]
 

optional arguments:
  -h, --help            show this help message and exit

specific arguments:
  --update              Create tag files if tag files do not exist, update the tag files otherwise.
  --remove              Remove the tag files generated.
  --accept-dotfiles     Accept files and directories whose names begin with a dot. By default, gtags
                        ignores them.
  --skip-unreadable     Skip unreadable files.
  --gtagsconf <FILE>    Set environment variable GTAGSCONF to <FILE>.
  --gtagslabel <LABEL>  Set environment variable GTAGSLABEL to <LABEL>.
  --skip-symlink [<TYPE>]
                        Skip symbolic links. If type is 'f' then skip only symbolic links for file, else
                        if 'd' then skip only symbolic links for directory. The default value of type is
                        'a' (all symbolic links).
  --gtagslibpath <PATH> [<PATH> ...]
                        Specify the paths to search for library functions.
  -d <PATTERN>, --definition <PATTERN>
                        Show locations of definitions.
  -r <PATTERN>, --reference <PATTERN>
                        Show reference to a symbol which has definitions.
  -s <PATTERN>, --symbol <PATTERN>
                        Show reference to a symbol which has no definition.
  -g <PATTERN>, --grep <PATTERN>
                        Show all lines which match to the <PATTERN>.
  --by-context          Decide tag type by context at cursor position. If the context is a definition of
                        the pattern then use -r, else if there is at least one definition of the pattern
                        then use -d, else use -s. Regular expression is not allowed for pattern.
  -i, --ignore-case     Ignore case distinctions in the pattern.
  --literal             Execute literal search instead of regular expression search.
  --path-style <FORMAT>
                        Show path names using <FORMAT>, which may be one of: `relative`, `absolute`,
                        `shorter`, `abslib` or `through`. `relative` means relative path. `absolute`
                        means absolute path. `shorter` means the shorter one of relative and absolute
                        path. `abslib` means absolute path for libraries (GTAGSLIBPATH) and relative path
                        for the rest. `through` means the relative path from the project root directory
                        (internal format of GPATH). The default is `relative`.
  -S <DIR>, --scope <DIR>
                        Show only tags which exist under <DIR> directory.
  --recall              Recall last search. If the result window is closed, reopen it.
  --match-path          Match the file path when fuzzy searching.
  --append              Append to the previous search results.
  --current-buffer      Show tags in current buffer.
  --all-buffers         Show tags in all listed buffers.
  --all                 Show tags in the whole project.
  --result <FORMAT>     Show result using format, which may be one of: `ctags`(default), `ctags-x`,
                        `ctags-mod`.
  --auto-jump [<TYPE>]  Jump to the tag directly when there is only one match. <TYPE> can be 'h', 'v' or
                        't', which mean jump to a horizontally, vertically split window, or a new tabpage
                        respectively. If <TYPE> is omitted, jump to a position in current window.

common arguments:
  --reverse             show results in bottom-up order
  --stayOpen            don't quit LeaderF after accepting an entry
  --input <INPUT>       specifies INPUT as the pattern inputted in advance
  --cword               current word under cursor is inputted in advance
  --top                 the LeaderF window is at the top of the screen
  --bottom              the LeaderF window is at the bottom of the screen
  --left                the LeaderF window is at the left of the screen
  --right               the LeaderF window is at the right of the screen
  --belowright          the LeaderF window is at the belowright of the screen
  --aboveleft           the LeaderF window is at the aboveleft of the screen
  --fullScreen          the LeaderF window takes up the full screen
  --nameOnly            LeaderF is in NameOnly mode by default
  --fullPath            LeaderF is in FullPath mode by default
  --fuzzy               LeaderF is in Fuzzy mode by default
  --regexMode           LeaderF is in Regex mode by default
  --nowrap              long lines in the LeaderF window won't wrap
  --next                Jump to the next result.
  --previous            Jump to the previous result.

If [!] is given, enter normal mode directly.

linusboyle · 2019-04-18T14:46:39Z

@Yggdroot Thanks for implementing this feature.
I think maybe I should take time to have a test of it, but at least the major problem is solved.Closed

xaljer · 2019-04-19T01:41:08Z

Can Leaderf gtags use exist gtags files managed by other vim plugin like gen_tags.vim?

Yggdroot · 2019-04-19T01:44:07Z

@xaljer No. LeaderF can manage the gtags files very well.

xaljer · 2019-04-19T14:48:03Z

so Leaderf can auto update tags when file is changed? that sounds great. I do not find an option to specify location of tag file. where are gtags files, and can i change it?

linusboyle · 2019-04-19T16:23:30Z

where are gtags files, and can i change it?

@xaljer the tag file is in the cache folder you set and of course you can change it.

So far my experience with gtags feature is excellent. Despite the lack of several other cscope interface query methods such as include hierarchy, leaderf functions even better than gutentags. Haven't test and don't know if leaderf can update the database on writeout, but otherwise a single line vimscript can achieve this.

Yggdroot · 2019-04-20T02:04:02Z

@xaljer Yes, tags can be updated automatically when a file is changed if g:Lf_GtagsAutoGenerate is 1. g:Lf_GtagsAutoGenerate is 0 by default.
The location of tag files is at $HOME/.LfCache/gtags/%PATH%OF%YOUR%PROJECT/, %PATH%OF%YOUR%PROJECT is generated by replacing the seperator \ or / in the path of your project with %. But I don't think you need to change the tag files.

@linusboyle Some features of cscope will be implemented in the future.

xaljer · 2019-04-20T09:36:18Z

I think it would be more convenient for definition to jump directly if there is only one result. May be you can provide an option to do that. @Yggdroot .

Jump to the tag directly when there is only one match.

Yggdroot · 2019-04-29T07:51:21Z

@xaljer Now you can add --auto-jump to jump to the tag directly when there is only one match.

linusboyle · 2019-04-29T08:01:09Z

@xaljer Now you can add --auto-jump to jump to the tag directly when there is only one match.

@Yggdroot BTW, Now that LeaderF has evolved into a powerful tag management tool, I'm wondering if it's possible to simulate the quickfix list. As leaderf stores the location info and it would be nice to have something like :leaderfnext and leaderfprevious, especially dealing with tags.

xaljer · 2019-04-29T15:47:38Z

@Yggdroot , Thank you:-)

Yggdroot · 2019-04-30T01:56:54Z

@Yggdroot BTW, Now that LeaderF has evolved into a powerful tag management tool, I'm wondering if it's possible to simulate the quickfix list. As leaderf stores the location info and it would be nice to have something like :leaderfnext and leaderfprevious, especially dealing with tags.

In normal mode, you can use j, k to navigate the result, I don't think :leaderfnext and leaderfprevious are necessary.

linusboyle · 2019-04-30T03:09:39Z

I think it's not so convenient to navigate to the leaderf window and use jk to jump. If the window is closed I will have to open it manually, which is annoying. If leaderf can provide a mean to jump without opening the window it would be nice Yggdroot <[email protected]> 于 2019年4月30日周二上午9:56写道：

…

@Yggdroot <https://github.com/Yggdroot> BTW, Now that LeaderF has evolved into a powerful tag management tool, I'm wondering if it's possible to simulate the quickfix list. As leaderf stores the location info and it would be nice to have something like :leaderfnext and leaderfprevious, especially dealing with tags. In normal mode, you can use j, k to navigate the result, I don't think :leaderfnext and leaderfprevious are necessary. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#191 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH74VQILYDDZ27PMFZXSCOTPS6RORANCNFSM4FMEN4RQ> .

Yggdroot · 2019-05-05T08:48:14Z

@linusboyle Now --next and --previous are available for your requirement.
You can use it like this:

:Leaderf gtags --next
:Leaderf gtags --previous

Leaderf <category> [--next | --previous] , category can be any subcommand supported.

haihualuo · 2019-09-20T00:58:15Z

I'm having an issue to navigate to code in a different location (as library).

Assume my username is 'john' and I have two directories with their respective GTAGS file

~/foo/one.c with gtags generated in ~/.LfCache/gtags/%home%john%foo
~/bar/two.c with gtags generated in ~/.LfCache/gtags/%home%john%bar

I wrote a small script to produce $GTAGSLIBPATH. So, "echo $GTAGSLIBPATH" on my machine outputs "/home/john/.LfCache/gtags/%home%john%foo:/home/john/.LfCache/gtags/%home%john%bar"

Now, when I'm in "foo/" and look up symbols in foo, everything works beautifully. But when I tried looking up symbol in "bar/", path in result is wrong. Let me explain:

I opened foo/one.c in VIM, move my cursor over a symbol that I knew is defined in bar/two.c. Then issue the command:

:<C-U><C-R>=printf("Leaderf! gtags -d %s --auto-jump", expand("<cword>"))<CR><CR>

The result says path to destination source file is:

/home/john/.LfCache/gtags/%john%bar%/two.c

The part "%john%bar%/two.c" seems correct. The line number in "two.c" is also correct. But
the complete path "/home/john/.LfCache/gtags/%john%bar%/two.c" doesn't help - in fact no file exists there, thus selecting the result makes VIM open an empty buffer for new file.

Yggdroot · 2019-09-20T03:10:00Z

@haihualuo I think you have misunderstood the meaning of $GTAGSLIBPATH, as described in https://www.gnu.org/software/global/globaldoc_toc.html.

If you want to locate symbols that are not defined in the source tree, then you can specify library directories with GTAGSLIBPATH environment variable.
You should execute gtags(1) at each directory in the GTAGSLIBPATH. If GTAGS is not found there, global ignores such directories.

    $ pwd
    /develop/src/mh                 # this is a source project
    $ gtags
    $ ls G*TAGS
    GRTAGS  GTAGS
    $ global mhl
    uip/mhlsbr.c                    # mhl() is found
    $ global strlen                 # strlen() is not found
    $ (cd /usr/src/lib; gtags)      # library source
    $ (cd /usr/src/sys; gtags)      # kernel source
    $ export GTAGSLIBPATH=/usr/src/lib:/usr/src/sys
    $ global strlen
    ../../../usr/src/lib/libc/string/strlen.c  # found in library
    $ global access
    ../../../usr/src/sys/kern/vfs_syscalls.c   # found in kernel

If you use LeaderF, you don't have to manage gtags by yourself, LeaderF can help to do it.
So

I opened foo/one.c in VIM, move my cursor over a symbol that I knew is defined in bar/two.c. Then issue the command:

All what you need to do is:

Leaderf gtags --update --gtagslibpath ~/bar to generate the gtags for both ~/foo and ~/bar.
:<C-U><C-R>=printf("Leaderf! gtags -d %s --auto-jump", expand("<cword>"))<CR><CR>

haihualuo · 2019-09-20T03:47:58Z

I think you have misunderstood the meaning of $GTAGSLIBPATH, as described in https://www.gnu.org/software/global/globaldoc_toc.html.
If you want to locate symbols that are not defined in the source tree, then you can specify library directories with GTAGSLIBPATH environment variable.
You should execute gtags(1) at each directory in the GTAGSLIBPATH. If GTAGS is not found there, global ignores such directories.

The description appears to align with my understanding. My operations are as follows:

Go to foo, open one.c. Witness "gtags successful" msg in VIM
Go to bar, open two.c. Witness the same message in VIM

After that, I could see two sets of gtag files under appropriate .LfCache/gtags subdirectories.

$ pwd
/develop/src/mh                 # this is a source project
$ gtags
$ ls G*TAGS
GRTAGS  GTAGS
$ global mhl
uip/mhlsbr.c                    # mhl() is found
$ global strlen                 # strlen() is not found
$ (cd /usr/src/lib; gtags)      # library source
$ (cd /usr/src/sys; gtags)      # kernel source
$ export GTAGSLIBPATH=/usr/src/lib:/usr/src/sys
$ global strlen
../../../usr/src/lib/libc/string/strlen.c  # found in library
$ global access
../../../usr/src/sys/kern/vfs_syscalls.c   # found in kernel


If you use LeaderF, you don't have to manage gtags by yourself, LeaderF can help to do it.
So

> I opened foo/one.c in VIM, move my cursor over a symbol that I knew is defined in bar/two.c. Then issue the command:

All what you need to do is:

1. `Leaderf gtags --update --gtagslibpath ~/bar` to generate the gtags for both `~/foo` and `~/bar`.
2. `:<C-U><C-R>=printf("Leaderf! gtags -d %s --auto-jump", expand("<cword>"))<CR><CR>`

I actually have many source trees, not just foo, bar in the example. It is more convenient for me to generate respective gtags files by going to each individual source trees, then point GTAGSLIBPATH to those trees. I expect the environment variable would be picked up by gtags and in turn by Leaderf that uses gtags, so I could locate symbol/references in any tree from anywhere.

What is the difference between specifying all the source trees in GTABSLIBPATH vs. having them specified in multiple "--gtagslibpath x", "--gtagslibpath y", "--gtagslibpath z" ... fashion?

Another observation is that finding symbols in tree B while I'm in tree A kind of works already, Leaderf did return the "semi-correct" path, but it is escaped with % and appended to the cache directory.

haihualuo · 2019-09-20T03:50:51Z

I think you have misunderstood the meaning of $GTAGSLIBPATH, as described in https://www.gnu.org/software/global/globaldoc_toc.html.

Given source tree A, B and C, is it required that while in tree A, lib points to only {B, C}, while in tree B, lib points only to {A, C} and so forth? I previously tried gutentags / gutentags_plus with exporting {A, B, C} as gtagslibpath (i.e. no matter which tree I'm in, the lib value is always {A, B, C}) and it worked for me, i.e. in any tree, I can always precisely locate symbols/references in the other 2 trees.

Yggdroot · 2019-09-20T05:21:00Z

@haihualuo

The description appears to align with my understanding.

$GTAGSLIBPATH is a global environment variable, LeaderF does not use or read it. However gtags will respect the value of it. $GTAGSLIBPATH indicates the paths of the source code, so there is

$ export GTAGSLIBPATH=/usr/src/lib:/usr/src/sys
$ global strlen
../../../usr/src/lib/libc/string/strlen.c  # found in library

libc/string/strlen.c is in the directory /usr/src/lib. You said

"echo $GTAGSLIBPATH" on my machine outputs "/home/john/.LfCache/gtags/%home%john%foo:/home/john/.LfCache/gtags/%home%john%bar"

/home/john/.LfCache/gtags/%home%john%foo is actually where LeaderF stores the gtags, not the directory of source code. If you use $GTAGSLIBPATH, the gtags database files are supposed to be generated in the directory pointed by $GTAGSLIBPATH. So, as per your example, you should generate gtags database file in ~/bar/ and export GTAGSLIBPATH=~/bar/. Is that clear about $GTAGSLIBPATH?

What is the difference between specifying all the source trees in GTABSLIBPATH vs. having them specified in multiple "--gtagslibpath x", "--gtagslibpath y", "--gtagslibpath z" ... fashion?

To specify multiple paths, the usage is --gtagslibpath x y z ....
The difference is that LeaderF can manage the gtags database files for all the paths x, y, z... if use --gtagslibpath x y z ..., if use $GTAGSLIBPATH, the gtags database files have to be put in x, y, z... respectively. Another advantage is that LeaderF can handle such a scenario: source tree A, libpath of A is D, E. source tree B, libpath of B is F, G. If you use $GTAGSLIBPATH, you have to specify export GTAGSLIBPATH=D:E:F:G, suppose a symbol foo is defined in all the D, E, F, G, so if you search the definition of foo in source tree A, the definitions in F, G are also listed.

Given source tree A, B and C, is it required that while in tree A, lib points to only {B, C}, while in tree B, lib points only to {A, C} and so forth? I previously tried gutentags / gutentags_plus with exporting {A, B, C} as gtagslibpath (i.e. no matter which tree I'm in, the lib value is always {A, B, C}) and it worked for me, i.e. in any tree, I can always precisely locate symbols/references in the other 2 trees.

I find I have already answered this question.

PS: If you have run Leaderf gtags --update --gtagslibpath B C in A, you have to also run Leaderf gtags --update --gtagslibpath A C in B.

haihualuo · 2019-09-20T05:35:51Z

If you use $GTAGSLIBPATH, the gtags database files are supposed to be generated in the directory pointed by $GTAGSLIBPATH. So, as per your example, you should generate gtags database file in ~/bar/ and export GTAGSLIBPATH=~/bar/. Is that clear about $GTAGSLIBPATH?

Understand. But one major benefit of Leaderf+gtags / gutentags / gutentags_plus is that the G*TAGS files are located centrally at a different location, away from source tree. In Leaderf, I have:

let g:Lf_CacheDirectory = expand('~/.cache/leaderf')

So all the GTAGS files are there. AFAIK, GTAGSLIBPATH must points to directories that contains these GTAGS file. It is not required that such location is part of source tree (otherwise the major benefit would not be possible).

Therefore, I set the value of GTAGSLIBPATH to "~/.cache/leaderf/gtags/%some_tree%" - that is my real config vs. "foo/bar" are just examples in my previous comment.

Btw, I found Leaderf superior to gutentags/gutentags_plus. But when using gutentags/gutentags_plus, I set up my GTAGSLIBPATH exactly the same way - it points to ~/.cache/tags/my_source_tree[1234..], while I have following:

let g:gutentags_cache_dir = expand('~/.cache/tags')

... and my source trees are in /my/source/tree[1234...] (gutentags uses "_" vs. "%")

What is the difference between specifying all the source trees in GTABSLIBPATH vs. having them specified in multiple "--gtagslibpath x", "--gtagslibpath y", "--gtagslibpath z" ... fashion?

To specify multiple paths, the usage is --gtagslibpath x y z ....
The difference is that LeaderF can manage the gtags database files for all the paths x, y, z... if use --gtagslibpath x y z ...,

if use $GTAGSLIBPATH, the gtags database files have to be put in x, y, z... respectively.

As described above, it is not the case for gutentags/gutentags_plus.

Another advantage is that LeaderF can handle such a scenario: source tree A, libpath of A is D, E. source tree B, libpath of B is F, G. If you use $GTAGSLIBPATH, you have to specify export GTAGSLIBPATH=D:E:F:G, suppose a symbol foo is defined in all the D, E, F, G, so if you search the definition of foo in source tree A, the definitions in F, G are also listed.

That is a good point.

Yggdroot · 2019-09-20T06:10:50Z

@haihualuo

AFAIK, GTAGSLIBPATH must points to directories that contains these GTAGS file. It is not required that such location is part of source tree (otherwise the major benefit would not be possible).

I don't think so. You can try $GTAGSLIBPATH in command line(run gtags command in command line).
The benefit is because there are many codes to handle the logic to wrok as expected, we can call it as workaround.

But when using gutentags/gutentags_plus, I set up my GTAGSLIBPATH exactly the same way

Because LeaderF does not have any logic to specifically handle $GTAGSLIBPATH, just leave it as it is. So the error demonstrates GTAGSLIBPATH must points to directories that contains these GTAGS file. It is not required that such location is part of source tree is wrong.
Maybe gutentags has special handle of $GTAGSLIBPATH.

haihualuo · 2019-09-20T06:14:45Z

@haihualuo

AFAIK, GTAGSLIBPATH must points to directories that contains these GTAGS file. It is not required that such location is part of source tree (otherwise the major benefit would not be possible).

I don't think so. You can try $GTAGSLIBPATH in command line(run gtags command in command line).

I did an experiment - I simply updated my script to point GTAGSLIBPATH to 'foo' and 'bar', which are 2 different source trees. Notice that there are no GTAGS file there; those GTAGS files are saved in ~/.LfCache/gtags/%some_path% per 'g:Lf_CacheDirectory' config.

The experiment failed - in tree A, Leaderf + gtags cannot locate symbols from tree B. I verified the respective GTAGS are fine - I can locate everything in A from tree A and everything in B from tree B.

I think this experiment is fairly reproducible, but if it works for you, I'd like to learn the differences in our steps ...

The benefit is because there are many codes to handle the logic to wrok as expected, we can call it as workaround.

But when using gutentags/gutentags_plus, I set up my GTAGSLIBPATH exactly the same way

Because LeaderF does not have any logic to specifically handle $GTAGSLIBPATH, just leave it as it is. So the error demonstrates GTAGSLIBPATH must points to directories that contains these GTAGS file. It is not required that such location is part of source tree is wrong.

"Is wrong" meaning? The entry in GTAGSLIBPATH must contain both GTAGS file and source code?

Maybe gutentags has special handle of $GTAGSLIBPATH.

That I am not sure.

Yggdroot · 2019-09-20T06:28:23Z

@haihualuo

"Is wrong" meaning? The entry in GTAGSLIBPATH must contain both GTAGS file and source code?

Yes.
If you try to understand GTAGSLIBPATH, please do not use LeaderF or gutentags, just experiment in the command line. I think you will catch what I mean.

haihualuo · 2019-09-20T06:59:03Z

@haihualuo

"Is wrong" meaning? The entry in GTAGSLIBPATH must contain both GTAGS file and source code?

Yes.
If you try to understand GTAGSLIBPATH, please do not use LeaderF or gutentags, just experiment in the command line. I think you will catch what I mean.

Thanks. You are partially correct. I could use GTAGSLIBPATH to locate library symbols without GTAGS in the library directory. The following works:

gtags in foo to generate GTAGS files
gtags in bar to generate GTAGS files
move all foo's GTAGS files to a new directory called "lib_foo" (previously empty, no source)
export GTAGSLIBPATH="lib_foo"
Using 'global' from bar (with bar's GTAGS file), we can locate symbols from foo. After unsetting GTAGSLIBPATH, we cannot. In this case, library source and GTAGS file are in different locations.

I have no intention to drag on the environment variable. The main reason I brought it up is it seems to work with gutentags (with GTAGS file and source code completely separate), so I was hoping the same setup can work under Leaderf ... I will check "--gtagslibpath". The main challenge there is "x y z" could be different when we clone the same repo to different physical directories (sometimes necessary & faster than switching between branches in the same place).

Yggdroot · 2019-09-20T07:43:18Z

@haihualuo

gtags in foo to generate GTAGS files

gtags in bar to generate GTAGS files

move all foo's GTAGS files to a new directory called "lib_foo" (previously empty, no source)

export GTAGSLIBPATH="lib_foo"

Using 'global' from bar (with bar's GTAGS file), we can locate symbols from foo. After unsetting GTAGSLIBPATH, we cannot. In this case, library source and GTAGS file are in different locations.

Suppose the full path of foo, bar and lib_foo are /foo, /bar and /lib_foo respectively,
and the 4th step is export GTAGSLIBPATH=/lib_foo, and a function called fun() is defined in /foo/foo.c.
Run global -d fun in bar, the output will be /lib_foo/foo.c but not /foo/foo.c, this is not correct, I don't know why you said we can locate symbols from foo.

haihualuo · 2019-09-20T08:39:34Z

@haihualuo

gtags in foo to generate GTAGS files

gtags in bar to generate GTAGS files

move all foo's GTAGS files to a new directory called "lib_foo" (previously empty, no source)

export GTAGSLIBPATH="lib_foo"

Using 'global' from bar (with bar's GTAGS file), we can locate symbols from foo. After unsetting GTAGSLIBPATH, we cannot. In this case, library source and GTAGS file are in different locations.

Suppose the full path of foo, bar and lib_foo are /foo, /bar and /lib_foo respectively,
and the 4th step is export GTAGSLIBPATH=/lib_foo, and a function called fun() is defined in /foo/foo.c.
Run global -d fun in bar, the output will be /lib_foo/foo.c but not /foo/foo.c, this is not correct, I don't know why you said we can locate symbols from foo.

Stand corrected. I checked again. One use case for separating source tree and related GTAGS file is you may not have write permission to source tree. This is achieved via https://lists.gnu.org/archive/html/help-global/2015-07/msg00001.html. But this seems convoluted and my original purpose is not to separate GTAGS and source tree, mainly to take advantage of that as offered by the tool.

Yggdroot added the feature request label Jul 26, 2018

bearzyj mentioned this issue Sep 8, 2018

ImportError: cannot import name _remove_dead_weakref #214

Closed

6 tasks

Yggdroot added a commit that referenced this issue Apr 18, 2019

fix issue #191

b9cc519

add support for GNU Global

linusboyle closed this as completed Apr 18, 2019

Yggdroot added a commit that referenced this issue Apr 28, 2019

add --auto-jump for Leaderf gtags as requirement in issue #191

0697936

Jump to the tag directly when there is only one match.

Yggdroot added a commit that referenced this issue Apr 29, 2019

add --auto-jump for Leaderf gtags as requirement in issue #191

cbf8df2

Jump to the tag directly when there is only one match.

hanxi added a commit to hanxi/dotfiles that referenced this issue Apr 29, 2019

#Yggdroot/LeaderF#191 牛逼的LeaderF又干掉一个插件了

9a36d37

Yggdroot pinned this issue May 6, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

add support for GNU Global? #191

add support for GNU Global? #191

linusboyle commented Jul 26, 2018

kgfly commented Oct 26, 2018

renchili commented Jan 30, 2019

xaljer commented Feb 23, 2019

linusboyle commented Feb 23, 2019

kgfly commented Feb 24, 2019

Yggdroot commented Apr 18, 2019 •

edited

Loading

linusboyle commented Apr 18, 2019

xaljer commented Apr 19, 2019

Yggdroot commented Apr 19, 2019

xaljer commented Apr 19, 2019

linusboyle commented Apr 19, 2019 •

edited

Loading

Yggdroot commented Apr 20, 2019

xaljer commented Apr 20, 2019

Yggdroot commented Apr 29, 2019

linusboyle commented Apr 29, 2019

xaljer commented Apr 29, 2019

Yggdroot commented Apr 30, 2019

linusboyle commented Apr 30, 2019 via email

Yggdroot commented May 5, 2019

haihualuo commented Sep 20, 2019 •

edited by Yggdroot

Loading

Yggdroot commented Sep 20, 2019 •

edited

Loading

haihualuo commented Sep 20, 2019 •

edited

Loading

haihualuo commented Sep 20, 2019 •

edited

Loading

Yggdroot commented Sep 20, 2019 •

edited

Loading

haihualuo commented Sep 20, 2019 •

edited

Loading

Yggdroot commented Sep 20, 2019

haihualuo commented Sep 20, 2019 •

edited

Loading

Yggdroot commented Sep 20, 2019

haihualuo commented Sep 20, 2019 •

edited

Loading

Yggdroot commented Sep 20, 2019 •

edited

Loading

haihualuo commented Sep 20, 2019 •

edited

Loading

add support for GNU Global? #191

add support for GNU Global? #191

Comments

linusboyle commented Jul 26, 2018

kgfly commented Oct 26, 2018

renchili commented Jan 30, 2019

xaljer commented Feb 23, 2019

linusboyle commented Feb 23, 2019

kgfly commented Feb 24, 2019

Yggdroot commented Apr 18, 2019 • edited Loading

linusboyle commented Apr 18, 2019

xaljer commented Apr 19, 2019

Yggdroot commented Apr 19, 2019

xaljer commented Apr 19, 2019

linusboyle commented Apr 19, 2019 • edited Loading

Yggdroot commented Apr 20, 2019

xaljer commented Apr 20, 2019

Yggdroot commented Apr 29, 2019

linusboyle commented Apr 29, 2019

xaljer commented Apr 29, 2019

Yggdroot commented Apr 30, 2019

linusboyle commented Apr 30, 2019 via email

Yggdroot commented May 5, 2019

haihualuo commented Sep 20, 2019 • edited by Yggdroot Loading

Yggdroot commented Sep 20, 2019 • edited Loading

haihualuo commented Sep 20, 2019 • edited Loading

haihualuo commented Sep 20, 2019 • edited Loading

Yggdroot commented Sep 20, 2019 • edited Loading

haihualuo commented Sep 20, 2019 • edited Loading

Yggdroot commented Sep 20, 2019

haihualuo commented Sep 20, 2019 • edited Loading

Yggdroot commented Sep 20, 2019

haihualuo commented Sep 20, 2019 • edited Loading

Yggdroot commented Sep 20, 2019 • edited Loading

haihualuo commented Sep 20, 2019 • edited Loading

Yggdroot commented Apr 18, 2019 •

edited

Loading

linusboyle commented Apr 19, 2019 •

edited

Loading

haihualuo commented Sep 20, 2019 •

edited by Yggdroot

Loading

Yggdroot commented Sep 20, 2019 •

edited

Loading

haihualuo commented Sep 20, 2019 •

edited

Loading

haihualuo commented Sep 20, 2019 •

edited

Loading

Yggdroot commented Sep 20, 2019 •

edited

Loading

haihualuo commented Sep 20, 2019 •

edited

Loading

haihualuo commented Sep 20, 2019 •

edited

Loading

haihualuo commented Sep 20, 2019 •

edited

Loading

Yggdroot commented Sep 20, 2019 •

edited

Loading

haihualuo commented Sep 20, 2019 •

edited

Loading