bug-global
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: this appears to be a bug in the "nearness" processing...


From: Shigio YAMAGUCHI
Subject: Re: this appears to be a bug in the "nearness" processing...
Date: Sun, 3 Dec 2017 16:38:10 +0900

Hello,
You need to add '=b.c' to the --nearness option.
The --from-here option has nothing to do with it.

$ global --result=grep --nearness=b.c --from-here=9:b.c foo
b.c:1:static int  foo() {
a.c:1:static int  foo() {

Regards
Shigio


2017-12-03 1:00 GMT+09:00 Gautam Thaker <address@hidden>:
I have two files in a single directory, a.c and b.c each with a function "foo". If in emacs I am looking at file b.c and search for tag "foo", it goes to the definition of "foo" in file a.c. This is not what I believe is expected given from man mage:

"    [0] If the start is a file, output of local search in the file."

And indeed, this is confirmed by:

$ global -v --result=grep --color=always --nearness --path-style=shorter --from-here=9:b.c foo
a.c:1:static int  foo() {
b.c:1:static int  foo() {
2 objects located (using '/home/gthaker/ggtags-testing/GTAGS').

I expected that from b.c it would find definition in file b.c above the one in a.c (but in lexical sorting a.c comes before b.c so it is going there.)

files are as below:

:::::::::::::
a.c
::::::::::::::
static int  foo() {
  return 3;
}


main() {
  int x;

  x = foo();
}
::::::::::::::
b.c
::::::::::::::
static int  foo() {
  return 3;
}


main() {
  int x;

  x = foo();
}


_______________________________________________
Bug-global mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/bug-global




--
Shigio YAMAGUCHI <address@hidden>
PGP fingerprint: 
26F6 31B4 3D62 4A92 7E6F  1C33 969C 3BE3 89DD A6EB

reply via email to

[Prev in Thread] Current Thread [Next in Thread]