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

Filter as you type to default to *str* instead of str* #512

Closed
oskretc opened this issue Sep 13, 2018 · 28 comments
Closed

Filter as you type to default to *str* instead of str* #512

oskretc opened this issue Sep 13, 2018 · 28 comments

Comments

@oskretc
Copy link

@oskretc oskretc commented Sep 13, 2018

I found it to be more convenient for the filter to match the string anywhere in the file name.

Maybe make it a bit smart by having the results matching str* at the top and str following that

@mherrmann
Copy link
Contributor

@mherrmann mherrmann commented Sep 13, 2018

Thank you for the suggestion. What would be an example where matching anywhere in the file name is better?

@oskretc
Copy link
Author

@oskretc oskretc commented Sep 13, 2018

TC_CHAR_MeasureVoltageInDC.xml
TC_CHAR_MeasureVoltageInLDO.xml
TC_CHAR_MeasureCurrent.xml
TC_CHAR_MeasureResistance.xml
TC_CHAR_VoltageControl.xml
TC_CHAR_FrequencyControl.xml
ManyMore files...

Use cases.

"Voltage" will display 3 files
"MeasureVoltage" will display 2 files
"Measure" will display only files related to measurements

It's quite common to have a naming standard that goes from Generic to specific, that means that files will start with the same string and only differ further in the rest of the name and many times that is the interesting part.

Maybe an option to decide what filter strategy to use as default

@mherrmann
Copy link
Contributor

@mherrmann mherrmann commented Sep 13, 2018

I see, thank you for the examples. For you, how common is this case in comparison to prefix search?

@mherrmann
Copy link
Contributor

@mherrmann mherrmann commented Sep 14, 2018

Another user, Kyle, also just told me via email that he strongy prefers *str* over fman's current str* match. He pointed to XYplorer.

@oskretc
Copy link
Author

@oskretc oskretc commented Sep 14, 2018

For me, the above example is every day at work. but also, is really common that I remember a files name partially and a keyword that not necessarily is on the beginning of the files name. You know how Google has changed our brains to memorize queries instead of facts.

@mherrmann
Copy link
Contributor

@mherrmann mherrmann commented Sep 14, 2018

Is it more common for you than prefix matches?

@oskretc
Copy link
Author

@oskretc oskretc commented Sep 14, 2018

yes

@mherrmann
Copy link
Contributor

@mherrmann mherrmann commented Sep 14, 2018

I see. Maybe I'll just make it configurable.

@fman-issues-bot fman-issues-bot bot added the 1 vote label Sep 15, 2018
@kalons7
Copy link

@kalons7 kalons7 commented Sep 15, 2018

For me, it's much more natural to not have to think about where in the filename the match will be, and just start typing what I know is relevant. Quite often, many files will start the same and differentiate toward the end. For instance:

CompanyName.ProjectName.Integration.abc.dll
CompanyName.ProjectName.Integration.abc.pdb
CompanyName.ProjectName.Integration.def.dll
CompanyName.ProjectName.Integration.def.pdb
(dozens more here)
CompanyName.ProjectName.Integration.xyz.dll
CompanyName.ProjectName.Integration.xyz.pdb

I could type xyz to filter down to just the matching dll/pdb pair, or .dll to filter to all dll files, etc.

@mherrmann
Copy link
Contributor

@mherrmann mherrmann commented Sep 17, 2018

Okay, now another question: Is the behaviour you (both?) want *str* or *s*t*r*?

@kalons7
Copy link

@kalons7 kalons7 commented Sep 17, 2018

str

@kalons7
Copy link

@kalons7 kalons7 commented Sep 17, 2018

that didn't come through very well -- star str star

@oskretc
Copy link
Author

@oskretc oskretc commented Sep 18, 2018

Agree, str is the more natural, but I have used and implemented something similar to st*r but that should be specified in the query e.g. Measure_DC will match only one file in my example above.

@raguay
Copy link
Collaborator

@raguay raguay commented Sep 18, 2018

@mherrmann
Copy link
Contributor

@mherrmann mherrmann commented Sep 21, 2018

@raguay I think regular expressions would be somewhat too heavy-weight. I believe that for the vast majority of typical uses, * is enough. By the way, I'd be curious: The filter feature is quite a shift from fman's behaviour so far. What do you think of it?

I just commented in #511 that my ideal solution would be to display first files matching str*, then those matching *str*, and finally those matching *s*t*r*. Unfortunately, this is not easy to implement because it requires changing the order of the displayed files.

@raguay
Copy link
Collaborator

@raguay raguay commented Sep 21, 2018

I like the filter, but I would like it more if the up/down arrow keys were usable during it. But, I've gotten used to hitting to browse the list. But, I'm very flexible.

I think doing the three different matches might be too process intensive. I think only one would be needed, but have it be something user configurable. You could call it "first search" (str*), "last search" (str), and "each search" (str*).

But, I still like a regular expression option 😄. Maybe you could open an API to allow plugins to change the type of search. Have it call a function like filterFileList(list) which takes an array of strings (or whatever you are keeping the information in) and the function would return the array of items to show. That would enable other to implement the scheme they like and install the plugin they want to use. It would be nice for the plugin function to get all files (invisibles also) and filter them. That way you could filter for invisibles without having to toggle hidden, search, and then toggle hidden again. I only need hidden visible while trying to find a specific file (like the .zshrc file).

@mherrmann
Copy link
Contributor

@mherrmann mherrmann commented Sep 21, 2018

I like the filter, but I would like it more if the up/down arrow keys were usable during it.

Okay, I'm glad to hear that. I'll implement up/down in #514.

Maybe you could open an API to allow plugins to change the type of search.

I've thought about this. I believe the filter bar is very specialised and it would be overkill to offer an API specifically for it. But that doesn't mean that there can't be other places for an API / regular expressions. I'm thinking for instance of file search (#29). Or of an API that lets you add arbitrary filters for the current list of files. This is already used by the Core plugin to filter out hidden files. The difference is that it is independent of the filter bar. (Note that the API isn't public yet, as the preceding underscore in _add_filter indicates.)

@raguay
Copy link
Collaborator

@raguay raguay commented Sep 21, 2018

There again, in the _add_filter method you would have to turn it on and off. But, having it as part of the search bar would not interfere with normal usage. But, that's my take on it.

BTW: My example function before should have the search string from the search bar as well. Therefore, it would be filterFileList(list,search). This is much different than how _add_filter works.

@mherrmann
Copy link
Contributor

@mherrmann mherrmann commented Sep 21, 2018

You're right you'd have to turn it on and off. The reason for my stance above is/was that I believe that regular expressions are something most people will not use, especially not in the filter bar.

Also, thank you for your open attitude ("But, that's my take on it.")!

@mherrmann
Copy link
Contributor

@mherrmann mherrmann commented Sep 27, 2018

I implemented *str* instead of str* matches now in fman 1.3.2. This is now the default behavior (non-configurable). Let's see how it goes.

@mherrmann mherrmann closed this Sep 27, 2018
@mherrmann mherrmann removed the in progress label Sep 27, 2018
@kalons7
Copy link

@kalons7 kalons7 commented Sep 27, 2018

Home run! This is perfect.

BTW, it did not auto-update to 1.3.2, it was still 1.3.1 and I had to manually download/install.

@mherrmann
Copy link
Contributor

@mherrmann mherrmann commented Sep 27, 2018

Happy to hear you like it :-) Depending on your OS, it may take up to 24 hours for the update to be installed.

@igor-krupenja
Copy link

@igor-krupenja igor-krupenja commented Oct 1, 2018

@mherrmann But can we actually make this behaviour configurable if possible? I would somewhat prefer the str* matching myself.

One use case for me would be opening Dropbox folder inside Linux home folder with hidden files enabled. With *str* matching, I get the following when I type e.g. drop:

.dropbox
.dropbox-dist
Dropbox

And now I have to press the down arrow two times to get to Dropbox folder. This would not be necessary if I could configure str* matching.

Another similar case is typing doc inside Linux home folder to get to Documents:

.digidocpp (this is config folder for Estonian ID card)
Documents

Obviously, if implemented, this should only be a config option with *str* staying the default behaviour as this is what most users expect I guess :)

@mherrmann
Copy link
Contributor

@mherrmann mherrmann commented Oct 8, 2018

Thanks @CoenraadS. The problem is not the "knowing how to do it". It's knowing what to do.

@CoenraadS
Copy link

@CoenraadS CoenraadS commented Oct 8, 2018

@mherrmann

Example of VSCode scorer:

image

image

image

image

@mherrmann
Copy link
Contributor

@mherrmann mherrmann commented Oct 8, 2018

I get it. fman's GoTo feature has a similar "smart" matching. But filtering files in a directory is different. These files already have an ordering (eg. by Modified date). What you are suggesting would mean to change this order.

@kalons7
Copy link

@kalons7 kalons7 commented Oct 8, 2018

VS Code does this.

shot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.