> 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 <[email protected]>: > > On February 24, 2017 at 6:06 AM Mohammed Sadiq <[email protected]> > wrote: > > <snip> > > > > 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 <[email protected]> PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3
_______________________________________________ Bug-global mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-global
