Re: global doesn't respect functions declared as static

[Shigio YAMAGUCHI]

> I re-read the --nearness documentation. As I understand, it is simply a
sorting
> method.
> And a second parse won't be required. Right? So configuring --nearness to

You are right.

> accept files
> shall be enough for me (and probably would benefit IDEs too).

OK. I will add this plan to the TODO list.
Thank you for the valuable suggestion.

Regards,
Shigio


2017-02-24 14:34 GMT+09:00 Mohammed Sadiq :

> > On February 24, 2017 at 6:06 AM Mohammed Sadiq 
> wrote:
>
> 
>
> > > Does this meet your requirements?
> >
> > Right now, what ggtags does is find all references and visit the
> location of the
> > first reference returned by global. This would be what most editors (or
> IDEs) would do.
> > Because checking for '--nearness' with some file and then doing
> '--frome-here'
> > if --nearness fails would be twice as slow, especially for very large
> codebase.
> >
> > The simpler one what IDEs would benefit shall be, list the matches from
> the same file
> > first. Then the rest (when --from-here is given).
>
> I re-read the --nearness documentation. As I understand, it is simply a
> sorting method.
> And a second parse won't be required. Right? So configuring --nearness to
> accept files
> shall be enough for me (and probably would benefit IDEs too). In OOP based
> languages,
> my suggestion may get more wrong to guess the right definition. So, you
> are probably
> right on this.
>
> Sorry for the mis-understanding.
>
> Thanks
>



-- 
Shigio YAMAGUCHI 
PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3
___
Bug-global mailing list
Bug-global@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-global

Re: global doesn't respect functions declared as static

[Mohammed Sadiq]

> On February 23, 2017 at 3:57 PM Shigio YAMAGUCHI  wrote:
> 
> Hi,
> 
Hi

> Sorry but --from-here is not such option. Normally it is not used on the 
> command line.
> I am sorry that the description of the online manual is inadequate.
> 
I just pasted the output of what ggtags.el would run inside GNU Emacs. I simply 
ran those
in command line to see why it was happening. And reported.

> > Alternatly, if it is hard to track the return type of functions, the result
> > can be sorted that the first item shown is from the same file (when there 
> > is a
> > match).
> > 
> > Ie, The result then would be:
> > src/my-source.c
> > src/my-first-source.c
> 
> Rather, --nearness option has a close meaning to your suggestion.
> The --nearness option displays tags closer to the current position first.
> However, at present, only directory can be specified as an argument.
> 
> Present specification: --nearness=
> 
> How about changing the spec to accept a file as an argument of it?
Good enough. Though It might not help everybody, but just me.
> 
> New specification: --nearness=
> 
> If a file is specified, global gives it the highest priority.
> 
> Does this meet your requirements?

Right now, what ggtags does is find all references and visit the location of the
first reference returned by global. This would be what most editors (or IDEs) 
would do. 
Because checking for '--nearness' with some file and then doing '--frome-here' 
if --nearness fails would be twice as slow, especially for very large codebase.

The simpler one what IDEs would benefit shall be, list the matches from the 
same file
first. Then the rest (when --from-here is given).

Hope you can understand.
Thanks

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

Re: global doesn't respect functions declared as static

[Shigio YAMAGUCHI]

Hi,
> As I have given --from-here argument, it should be showing only the
definition
> from the same file (as the function is declared static).
>
> Expected result:
> src/my-source.c

Sorry but --from-here is not such option. Normally it is not used on the
command line.
I am sorry that the description of the online manual is inadequate.

> Alternatly, if it is hard to track the return type of functions, the
result
> can be sorted that the first item shown is from the same file (when there
is a
> match).
>
> Ie, The result then would be:
> src/my-source.c
> src/my-first-source.c

Rather, --nearness option has a close meaning to your suggestion.
The --nearness option displays tags closer to the current position first.
However, at present, only directory can be specified as an argument.

Present specification: --nearness=

How about changing the spec to accept a file as an argument of it?

New specification: --nearness=

If a file is specified, global gives it the highest priority.

Does this meet your requirements?

Regards,
Shigio

2017-02-23 14:37 GMT+09:00 Mohammed Sadiq :

>
> In C source, I have defined two static functions in separate files. When I
> search for definition of one of these, I sometimes get the wrong location.
>
> What I did:
> global -d my_func --from-here "133:/path/to/src/my-source.c"
>
> Result I got:
> src/my-first-source.c
> src/my-source.c
>
> As I have given --from-here argument, it should be showing only the
> definition
> from the same file (as the function is declared static).
>
> Expected result:
> src/my-source.c
>
>
> Alternatly, if it is hard to track the return type of functions, the result
> can be sorted that the first item shown is from the same file (when there
> is a
> match).
>
> Ie, The result then would be:
> src/my-source.c
> src/my-first-source.c
>
>
> Note: I have been using ggtags in GNU Emacs. Looking into source, I see
> this is
> ggtags is doing. So I think, the first result is what that matters the
> most.
>
> Thanks
>
> ___
> Bug-global mailing list
> Bug-global@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-global
>



-- 
Shigio YAMAGUCHI 
PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3
___
Bug-global mailing list
Bug-global@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-global