Re: some additional thoughts on NEARNESS SORT option
Gautam Thaker <[email protected]>
| Newsgroups | gmane.comp.gnu.global.bugs |
|---|---|
| Message-ID | <[email protected]> |
Yes, I agree that we should first get the capabilities already incorporated as "-N" out the door, and get some user experience w/ it. And yes, if ideas 1a) thru 1d) are eventually deemed useful, and not very difficult, we can visit them again. Thanks for all the support of the "nearness" concept. Gautam On 6/7/2015 10:18 PM, Shigio YAMAGUCHI wrote: > Hi Gautam, > > 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. > > b) 2nd highest would be other entries from other files at this > directory level. > > c) 3rd highest would be any entries in subdirectory/subdirectories(?) > > 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. > > It's a interesting idea. > However, we need to release a simple nearness sort version at first. > The current > nearness sort is complicated enough. I would like to advance slowly > with users. > Happily, your new idea seems to be upper compatible with the current spec. > What do you think? > > 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