In my opinion, Joplin really has a strange way of searching.
I have a bunch of notes, and I often want a quick search. I use F6 or CTRL+P. In this way, the Joplin only finds notes where keywords are. Why doesn't Joplin highlight findings on the right and focus on the first one? And then have an option to jump to the second, third ... and back if the user wants to.
If a note is longer than one page and the user uses Find (and Replace), then Joplin selects/highlights the keyword, BUT the focus is still on the top of the note!! The user has to move and search with the slider/mouse/keyboard instead. Joplin should (besides highlighting the search string) jump to the search string.
But, if I want to edit (or read) on desired position, I press X to close the Search window. Now, the Joplin jumps again on the top and the position is lost.
Oh, now I see what you mean. @kacnje now you explained it well. @personalizedrefriger , do you think it would be an improvement? Can you add it to the backlog?
Tnx for an idea. I tried searching with "/ccent" and it found a note that includes the word(s) "accent". So far so good, but after that, I have to use "Search inside note - Ctrl+F" - as in the first issue.
Regarding point 2, yes I've noticed that when using the Rich text editor, the global search does not highlight the matches. I don't think this has ever been supported though, so adding it would be a feature enhancement. It does work how you would expect if you use the markdown editor though
Tnx for an idea. I tried searching with "/ccent" and it found a note that includes the word(s) "accent". So far so good, but after that, I have to use "Search inside note - Ctrl+F"
Even if matching from the global search did work on the rich text editor, it still would not match, because the inline search works differently and considers / as part of the search term, so you will unfortunately need to amend the search term in the inline search to not include that slash, which is a bit annoying
come'on, it's a completely different issue. And it's not a problem, so don't call it a problem. It's a feature enhancement idea.
There is an actual problem mentioned in point 5, though it's not a new issue. My assertion of the issue being related to the issue which 15297 fixes was just a guess at the time.
I expected the global search to highlight the matches. I see no reason why the Rich Text Editor is not supported. Searching is a frequently used feature; almost every user searches through the notebook and wants matches to appear as quickly as possible. I hope this will improve in the future. Search is very important in that kind of software.
There's no logical reason why RTE isn't supported. The reason why there could be some flaws in the RTE is historical. RTE was experimental for the first 3 or 4 years and we primarily used the CME editor (the one that mirrors the preview). Because it was experimental for such a long time, it's not as polished as the CME. They don't share as much codebase as you would maybe expect. But it should be consistent and should be fixed nevertheless. Thanks for noticing it.
If the follow were implemented, it would be a good start.
Do a global search (F6 or Ctrl+P) and get to the note.
Do a find/replace (Ctrl+f) and have the data from the global search automatically be in the find box.
As it is now, you end up typing the same search term twice in order to get to the location in the note.
@rqk It does do that for both the markdown editor and rich text editor on mobile, and the markdown editor on desktop. It's only the rich text editor on desktop which does not support this
@mrjo118 I see that now on the mobile (don't do much searching on mobile.) I also see it now on the desktop. Too bad it isn't consistent with the different editors/views. Thanks for the info.
