Closed seth100 closed 5 years ago
Thanks for your work.
;)
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?
Some devices can barely load a mid-to-high sized textfile ;=). And thats just one.
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:
Community contribution welcome, free to take.
Great good to hear that!
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
Coming in the upcoming release
Hi, and what about by-content search? Any progress? Is there another issue for that?
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.
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.
1296
:partying_face:
For future reference: the merge request has been moved here: https://github.com/gsantner/markor/pull/1337
I agree that search is must have for notes.
General information
Description
In my test I have a subfolder called
Test
and a file calledOne
somewhere in another folder with the following markdown content:Here is my test 1 (search for files and folders):
Test
keyword in search box;test
keyword;My test 2 (search for content):
List
keyword in search box;One
file with content above.Tried to clear app cache and data, uninstall and reinstall it from F-Droid.
Thanks for your work.