Add "Search" action

[yanex]

Like in TC but more user-friendly.

[ghost]

there is also find any file which I currently use and like

[yanex]

@monouser7dig Well, it's similar to the functionality Finder provides out of the box, but it's not really easy to use with only a keyboard.

I see two possible alternatives:

1. Implement like it's done in TC (with lots of settings packed inside multiple tabs).
   • + Other file manager users will be familiar with this.
   • + Easy to use both with keyboard (every option has a hotkey) and mouse;
   • - IMO, it contradicts with the Marta philosophy (powerful but simple). It just looks like an old toolbox.
2. Make a query language (possibly on top of the existing language like Lua). Of course, with auto-completion and highlighting.
   • + IMO, it's very easy to use with keyboard.
   • - Hard to use with mouse (but we can add a visual editor).
   • - Steep learning curve.

As a programmer, I'd choose the second variant.

[ghost]

yes sure 2nd would fit better I mostly do simple searches for remaining files of old installations (done without homebrew cask)

[yanex]

For simple searches it would be like:

name = "Foo"

or

name.startsWith("test")
kind = FILE // exclude directories

[ghost]

• Foo => implicitly converted to name = "Foo"
• name = "Foo"; kind = "File" (separated by space or , or ; )
• type = "Pdf" (or filetype:pdf cause that is what google supports, maybe go with : instead of = everywhere?) or maybe even just pdf:html:jpg as a list of filetypes implicitly converted to filetype:pdf:html:jpg
• Content:true (maybe easier to have Content:false be the implicit default and Content == Content:true)
• match: exact/fuzzy/begin/end/contains (each with negation)
• modified:>3days

so a request could look like Foo:!begin:fuzzy; pdf; Content; modified<=3h; size>3GB which means:

• search for "Foo" but does not start with "Foo", match by fuzzy matching in PDF files content that is modified less or equal than 3h ago and bigger than 3GB

[yanex]

Well, the DSL itself is discussible, the design process is not even started :). I don't really like one-liners, though, cause

name = "Foo"
extension = "txt"

looks much more readable to me than name = "Foo"; ext = "txt", even if the latter variant is much shorter.

Most important thing is that we need to provide extensibility here so plugins would be able to add custom filters like insideGitRepo.

[warpkanal]

The "search" action is for me one of the few "really important" missing feature. However I realise that I use it (in my "other" file manager) max once per week only (but then it IS important :) ). Hence I personally would prefer a dialog UI that remembers all settings & entries instead of having only some DSL which I find hard to remember when not using it daily. I noticed for example that I rarely use Marta's Spotlight feature, just because I don't remember it's notation right from the start and most often it's too cumbersome to find the resp. documentation entry (e.g. the spotlight support and its syntax seems to be only documented in https://marta.yanex.org/blog but not in the documentation).

All in all, I tend to prefer non-steep learning curves for everything I don't use daily. I'm fine with steep learning curves for everything I do daily. But maybe you'll manage to have something around the DSL, that helps in intuitively using it without the need to check the documentation too often :)

[muescha]

i would also like to have a search function

PS: somehow i not get the spotlight feature working for me