Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Commander: few optimizations for better user experience #153

Closed
wants to merge 1 commit into from

Conversation

scriptum
Copy link
Member

@scriptum scriptum commented Sep 6, 2014

Here are two little changes to make commander search better:

  1. Get more score for exact match. E.g. you have file named
    "editor.c" and type "edi" - editor.c going to be first. With
    current scoring system you may find "editor.c" document on 10th
    line or deeper.
  2. Remove path for documents. Usually you don't want to type full
    path to file to find document in list. This makes fast document
    searching possible with fixing fixed length address bug  #1 optimization.
    img

Here are two little changes to make commander search better:
1. Get more score for exact match. E.g. you have file named
"editor.c" and type "edi" - editor.c going to be first. With
current scoring system you may find "editor.c" document on 10th
line or deeper.
2. Remove path for documents. Usually you don't want to type full
path to file to find document in list. This makes fast document
searching possible with #1 optimization.
@b4n
Copy link
Member

b4n commented Sep 10, 2014

  1. yes this is a problem, but your solution really only solves one particular case: when matching the very start of the haystack. This is rarely the case, and without your second change I can't think of any actual and convenient use case. I believe the real fix here would be to give higher weight to contiguous match (e.g abc would have a higher score against abcd ef than against a b cd ef because it matches more contiguous input on the same word).
  2. Well, yes and no. Your solution will make it impossible to filter different files with the same name under different paths (e.g. two Makefiles). A better (but less trivial) solution for this would be to give higher score when the match is near the end (e.g. with parts separated with "/" or "→"), as indeed in most cases one will want to match near the end. A possible alternative workaround could be adding a new prefix to match only the basename (fb: or b: maybe).

More generally though the algorithm would benefit from being much better, like allowing garbage in the pattern and the like; but unfortunately good results seemed to mostly depend on fine tweaking.

Anyway, I tried to work on something improving first point, and although not ready yet it shows promising results.

@scriptum
Copy link
Member Author

Well that worked fine for me but I'm also using Russian locale, so there are many problems with translated menu items.

Maybe I could provide better algorithm in the future.

@b4n
Copy link
Member

b4n commented Sep 10, 2014

I believe #154 should fix the issues you were facing, and be a generic solution to the problem.

@b4n b4n closed this Sep 10, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants