Matching, scoring and sorting.

[asmodeus812]

This is probably not a bug, rather something to think about. Consider the following java class which has a getter method which has a very long name but follows the pattern get{long-constant-prefix}PstCode coming from an auto generated structure from xml. This class has many other getters/setters which all have this same long constant prefix, and let's say we are looking for that getter for post code (typing out the getter name like so classInstance.pstcode|. Assume that this class also has fields, with the same constant prefix, but instead ending in other key words, such as StopCode, TypeCode, PostalCode. As you can see all of those contain the same letters that PstCode contains, in the same order, but only PstCode contains them in the correct proper sequence which was typed in the query / in insert mode (see above). What nvim-cmp however does, is not respecting that fact. And it would actually show matches such as StopCode or TypeCode etc. with greater weight than PstCode. Sometimes, if the property we are looking for or getter/setter is short, and contains common letters, it would not even be in the list (for someone like me using pumheight with values no greater than 10). It would be great if we consider / calculate the rank or weight of the fuzzy match accordingly, accounting for consecutive matches in the name, and ranking it higher.

Not sure if something like that is possible with the current sorters, as i am using default configuration and the default comparators/sorters seem reasonable to me, they should maybe handle this case as it is, but do not.