dumb-jump-go prefers file outside of repo

[fleutot]

trafficstars

This file structure:

$ ls
mycode.c  other_file.c
$ git init
Initialized empty Git repository in /home/gauthier/tmp/dumb/.git/
$ git add mycode.c && git commit -m"Init"
[master (root-commit) 5271e5a] Init
 1 file changed, 15 insertions(+)
 create mode 100644 mycode.c

mycode.c:

typedef int my_type_t;

my_type_t a;
my_type_t my_function(my_type_t in);
int main(void)
{
    my_type_t b;
    a = my_function(b);
    return 0;
}

my_type_t my_function(my_type_t in)
{
    return (my_type_t) 0;
}

other_file.c:

typedef struct {
    int x;
} my_type_t;

With nothing else dumb-jump related than (dumb-jump-mode t) in my init file, going C-M-g with cursor on my_type_t in mycode.c, dumb-jump jumps to the struct definition in other_file.c

I would have expected dumb-jump to prefer:

• definition in the same file
• definition in the git repo (other_file.c is in the directory, but not tracked by git)

Incidentally, manually setting ag as searcher with (setq dumb-jump-force-searcher 'ag) changes this behavior: a popup comes up (although the readme mentions it should use git-grep anyway, since in a git repo).

[jacktasia]

Thanks for reporting this! I'll try to reproduce this after work tonight and see if I can figure out what's happening here.

[jacktasia]

@fleutot Thanks for providing an example! To look into this I turned on debug mode with (setq dumb-jump-debug t) and followed your instructions to here:

With nothing else dumb-jump related than (dumb-jump-mode t) in my init file, going C-M-g with cursor on my_type_t in mycode.c, dumb-jump jumps to the struct definition in other_file.c

Here's what I got from debug mode when I jumped from my_type_t on line 14 of mycode.c:

-----
DUMB JUMP DEBUG ‘dumb-jump-run-command‘ START
-----

cmd:
	git grep --color=never --line-number --untracked -E \\bmy_type_t\(\\s\|\\\)\)\*\\\(\(\\w\|\[\,\&\*.\<\>\]\|\\s\)\*\(\\\)\)\\s\*\(const\|-\>\|\\\{\|\$\)\|typedef\\s\+\(\\w\|\[\(\*\]\|\\s\)\+my_type_t\(\\\)\|\\s\)\*\\\(\|\\b\(class\|struct\|enum\|union\)\\b\\s\*my_type_t\\b\\s\*\(final\\s\*\)\?\(\:\(\(\\s\*\\w\+\\s\*\:\:\)\*\\s\*\\w\*\\s\*\<\?\(\\s\*\\w\+\\s\*\:\:\)\*\\w\+\>\?\\s\*\,\*\)\+\)\?\(\(\\\{\|\$\)\)\|\}\\s\*my_type_t\\b\\s\*\; -- /tmp/dj213/\*.c /tmp/dj213/\*.h /tmp/dj213/\*.C /tmp/dj213/\*.H /tmp/dj213/\*.tpp /tmp/dj213/\*.cpp /tmp/dj213/\*.hpp /tmp/dj213/\*.cxx /tmp/dj213/\*.hxx /tmp/dj213/\*.cc /tmp/dj213/\*.hh /tmp/dj213/\*.c\+\+ /tmp/dj213/\*.h\+\+

raw results:

	other_file.c:3:} my_type_t;


-----
DUMB JUMP DEBUG ‘dumb-jump-run-command‘ END
-----

This seems to match what you said, but to answer your questions/expectations:

[I would have expected dumb-jump to prefer:] definition in the same file

If you look at the C/C++ rules

You'll see that they don't support all searchers. I don't personally use C/C++ nor did I write these specific rules, but you'll notice ag has an extra rule. This is basically what I would have expected based on the rules that are there.

But if I do (setq dumb-jump-force-searcher 'ag) with debug still on and jump from the same location I get:

-----
DUMB JUMP DEBUG ‘dumb-jump-run-command‘ START
-----

cmd:
	ag --nocolor --nogroup --cc --cpp \\bmy_type_t\(\\s\|\\\)\)\*\\\(\(\\w\|\[\,\&\*.\<\>\]\|\\s\)\*\(\\\)\)\\s\*\(const\|-\>\|\\\{\|\$\)\|typedef\\s\+\(\\w\|\[\(\*\]\|\\s\)\+my_type_t\(\\\)\|\\s\)\*\\\(\|\\b\(\?\!\(class\\b\|struct\\b\|return\\b\|else\\b\|delete\\b\)\)\(\\w\+\|\[\,\>\]\)\(\[\*\&\]\|\\s\)\+my_type_t\\s\*\(\\\[\(\\d\|\\s\)\*\\\]\)\*\\s\*\(\[\=\,\(\)\{\;\]\|\:\\s\*\\d\)\|\#define\\s\+my_type_t\\b\|\\b\(class\|struct\|enum\|union\)\\b\\s\*my_type_t\\b\\s\*\(final\\s\*\)\?\(\:\(\(\\s\*\\w\+\\s\*\:\:\)\*\\s\*\\w\*\\s\*\<\?\(\\s\*\\w\+\\s\*\:\:\)\*\\w\+\>\?\\s\*\,\*\)\+\)\?\(\(\\\{\|\$\)\)\|\}\\s\*my_type_t\\b\\s\*\; /tmp/dj213

raw results:

	/tmp/dj213/other_file.c:3:} my_type_t;
/tmp/dj213/mycode.c:1:typedef int my_type_t;


-----
DUMB JUMP DEBUG ‘dumb-jump-run-command‘ END
-----

This matches my expectations with the extra rule ag has. I am happy to accept PRs if you'd like to improve any c/c++ rules, but in practice I think this will still do a pretty good job since in most languages I program in it's rare for me to share a variable/function name at all (let alone across types especially on something I'll want to jump to)

[I would have expected dumb-jump to prefer:] definition in the git repo (other_file.c is in the directory, but not tracked by git)

As you can see in the debug output for git-grep we pass --untracked to git-grep by default.

If you don't like it you can add (setq dumb-jump-git-grep-search-untracked nil) to your config.

Incidentally, manually setting ag as searcher with (setq dumb-jump-force-searcher 'ag) changes this behavior: a popup comes up

This is expected since ag has the extra rule mentioned above.

(although the readme mentions it should use git-grep anyway, since in a git repo).

I am confused where the README says this? This is how dumb-jump-force-searcher is described:

force the search program Dumb Jump should use. It will always use this searcher.
 If not set (nil) Dumb Jump will use git-grep if it's a git project and if not will try searchers
 in the following order ag, rg, grep (first installed wins).

Thanks again for taking the time to make your issues easily reproducible. I hope this helps explain what you're seeing. In practice, I don't see any real bugs just imperfect rules which I don't think are easily improved and I am happy with what I can get since, as I said, c/c++ is not a language I use.

You may want to read the README again and tweak dumb-jump settings to your liking for each language. I am happy to discuss further improvements or accept any PRs! :slightly_smiling_face:

[fleutot]

Thanks for the thorough answer! I wasn't expecting the - -untracked option as default for git-grep, that's what confused me (I assumed dumb-jump in a git repo would ignore untracked files).

Thank you for search-untracked, I had missed that. Will set to nil.

Sorry about the confusion, I wrote "force-searcher" but meant "prefer-searcher".

I'll look at the rules and see if I can make them fit my needs better. In that case and if I feel others could benefit from it, I'll work on a PR.