Re: some additional thoughts on NEARNESS SORT option

Hi Shigio:

To the degree I understand things I agree with below (see comments please):


On 6/25/2015 5:36 AM, Shigio YAMAGUCHI wrote:
> Hi,
> Since GLOBAL-6.5 already includes 'nearness sort',
> GLOBAL users can understand this concept now.
> Let's do continuation.
>
> Gautam wrote:
> > I had one more thought on this.
> >
> > 1) the highest priority is to find definitions in current directory
> > or below this directory. But it seems we can do a little better. How 
> about:
> >
> > a) highest prio is if the definition appears in the same file as 
> where M-. is being done.
>
> I agree. How about also accepting a file name as well as a directory name?
>
> --nearness[=start]start may be a file or a directory
>
> [0] If 'start' is a file, output of local search in 'start' file, else 
> nothing.<= ADDED
> [1] Output of local search in 'start' directory or the directory part 
> of 'start'<= CHANGED
>     except for [0].

I agree w/ [0] and [1] with caveat that in [1], when we are searching 
not in current directory, priorit should be first to tags at this 
directory level, and they to sub-directories (if any exists). After that 
moving up one level the process repeats. If any changes get commited 
regarding any of this beyond 6.5 release please let me know and I will 
be happy to test things out.

> [2] Output of local search in the parent directory except for [1].
> [3] Output of local search in the grandparent directory except for 
> [1]-[2].
> (repeat until the project root directory)
> [n] Output of local search in the project root directory except for 
> [1]-[n-1].
>
> > b) 2nd highest would be other entries from other files at this 
> directory level.
> > c) 3rd highest would be any entries in subdirectory/subdirectories(?)
>
> What is the merit of separating b) and c)?
>
> > d) start to move up on directory at a time as per rules prev. given 
> for -N option.
> >
> > 2) And here is yet another "wild" idea. suppose you are looking for 
> definition
> > of method "foo()". THe "which-func-mode" can tell you that you are 
> sitting
> > in Class A::method bar(). In this case it seems that first choice 
> would be
> > if there is a Class A::method foo() since that is one most likely is 
> being sought.
> > However, this gets into having to deal w/ which-func-mode to learn 
> more about
> > where the point is.  I think 1a) above may get us this indirectly.
>
> I believe this should be argued in other threads.
OK, I will start another thread for this.

>
> Regards,
> Shigio
> -- 
> Shigio YAMAGUCHI <[email protected] <mailto:[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