Recursive file search and/or search by content

[seth100]

General information

• App version: 0.3.10 (24) from F-Droid
• System: Android 7.1.2 LineageOS

Description

In my test I have a subfolder called Test and a file called One somewhere in another folder with the following markdown content:

[List](www.google.com)

Here is my test 1 (search for files and folders):

• Start typing the Test keyword in search box;
• I can see the filtered found folder (actually sometimes it fails in finding and I see just empty results);
• Start typing the test keyword;
• It finds nothing (is it case-sensitive? It would be nice to have an option to make it case-insensitive)

My test 2 (search for content):

• Start typing the List keyword in search box;
• It finds nothing, I was expecting to see the One file with content above.

Tried to clear app cache and data, uninstall and reinstall it from F-Droid.

Thanks for your work.

[gsantner]

• Content search is not implemented (and probably won't ever due ressource limits on most device)
  • Content search while being in document only, see #155
• Recursive file search is neither currently, but thats something that would be an option todo
• Current folder search insensitve: have to check, if so, yes insensitive it should be

Thanks for your work.

;)

[seth100]

Ok thanks for the answer. Anyway, other apps like Joplin, StandardNotes, OmniNotes do implement content search in all documents from root folder. Does it really consume so much resources so that it won't be able to be implemented ever?

[gsantner]

Some devices can barely load a mid-to-high sized textfile ;=). And thats just one.

[gsantner]

I thought about this, and I'm now saying okay both to recursive file search and to by-content search.

Important points for implementing this:

• Go for recursive file search first
• For content search - maybe take a look if there is some efficient+lightweight library available. Probably not good to work this out self, has surely done by somebody already.
• Use file search by default. Have a non-saving-toggle for enabling content search. Searching content takes time, and it must be explictly in users will, for common cases user don't want to wait long, and thats only possible with file-only search.
• Go for backend first. If you get an array of files/strings from a given search string thats already a huge step.

Community contribution welcome, free to take.

[seth100]

Great good to hear that!

[gsantner]

while this is not the whole "search" feature, the upcoming v1.2 Markor update will have context-aware-search for @projects and +contexts. Comes when long pressing the @/tag button. https://github.com/gsantner/markor/commit/fadf2715677383fcb98f00de4531810042502be4

[gsantner]

Coming in the upcoming release

[jnizniowski]

Hi, and what about by-content search? Any progress? Is there another issue for that?

[gsantner]

Content search will not come at Markor. Markor is a lightweight app and should stay as such.

Search by content means either duplicating all content in cache or database (nogo) or fully reading all files at search time.

I don't want to have any of both. There are specialized search apps, like agrep that you can use for this.

[brunetton]

Hi, I found this feature request as I was on the point to open one for content search.

Content search will not come at Markor. There are specialized search apps, like agrep that you can use for this.

Indeed, but this is a super heavy and annoying process having to open a third-party app to find and remember the name of the file that contains the words we're searching for, then coming back to Markor and searching for this same file (probably implies to change sort order for alphabetic sorting, then browsing folders and subfolders for a while, then searching again for the same string in the opened note).

Markor is a lightweight app and should stay as such.

I totally agree with this statement ! Markor shouldn't have an internal DB for quicker word-searching. But I disagree that fully reading all notes while searching would make this app "heavier". I think that all users would find it okay to wait 5 seconds while searching for a string in 10k of text notes; I don't see any problem here. Of course the implementation is probably not super easy, as a seperate thread would be required to prevent main UI from freezing while searching, and a "cancel" button would be required to stop the process if user thinks that it's taking too much time.

In my personal use case this is a must-have feature as I have quite long notes with many information inside and notes names can't help me quickly find information (this is due to the fact that I migrated my notes from Zim and Zim offers a content-search function, and the projects I'm working).

Noteless implements this search function and I tested it on my personal and pro notes (1300 files / 1.7Mb). It took less than 3 seconds to grep strings and be able to navigate through results. I didn't look closer but I'm pretty sure Noteless is not caching or indexing anything. This is not what I call a heavy CPU process nor a long time to wait.

@gsantner any chance that you could change your mind on this ? Accepting PRs ? I don't think content search should be available by default, but we could add a toggle on the search activity: "also search in notes content"

Unfortunately I'm not a Java dev anymore so I'd not be the right man for this one, but I can support dev.

[gsantner]

1296

[brunetton]

1296

:partying_face:

[brunetton]

For future reference: the merge request has been moved here: https://github.com/gsantner/markor/pull/1337

[ostatok]

I agree that search is must have for notes.