Since implementing toggle note listFeature idea: Hide note list I started using Joplin exclusively with goto anything without any sidebars. I love it, it's like using sublime text / vscode using only the go to file feature
What I miss now is having recently updated notes listed when I use goto anything.
Feature improvement description:
when pressing CTRL+G (goto anything) before even entering any text:
pre-fill the list with the 5 (or 10) recently updated notes
that way, using only the up/down arrow keys, we could quickly switch to any recently edited notes
I could provide a visual example if asked.
I'd use that feature so much because right now I need to type the name of the last note I was editing when working on 2 separate notes at the same time.
However, I think that the Goto Anything algorithm has to be fixed first.
e.g. I have the following Notes with the name test in it:
Test todo
Test note
checkbox test
Test note - Features
network slowdown tests
[snip]
When I use goto anything, and type test or Test, the search bar jumps not to the obvious choice Test todo or Test note, nope, it jumps to network slowdown tests. So something is certainly a bit off here.
And no, I have updated Test todo last, so even if the order was by updated most recently, the search bar should be at Test todo.
I've submitted a simple pull request to pre-fill the Goto Anything dialog list:
I'm going to also look into improving search results. Besides what @tessus mentioned, the search results don't do a good job of sorting by created or updated date. The algorithm determines some useful information about weight and fuzziness, but it ends up only picking the first criteria that differs rather than using a weighted average.
Last Updated is last in that list of terms it checks. Ideally it would also check Last Created (or even Title or Custom Order), depending on which option is selected in "View > Sort notes by".
And yes, I don't know that the BM25 algorithm factors in position of the search terms well.
Ah gotcha, thanks. Do you know if the GSoC code is all merged? I see BM25, fuzzy, and wildcard search in Dev in the last month, but those don't address the issues I mentioned, nor do I see any .
The search enhancement for Last Created is pretty simple, so I might throw up a PR in case it isn't addressed by GSoC changes. If using a weighted average in SearchEngine.processResults_, if I search for "Tony one-on-one", I get results in somewhat reverse chronological order, which is an essential use case for me and I'm assuming for many others as well.
Yes, all the GSoC code has been merged. I didn't check the search code that often, so I do not know how far it reached. @CalebJohn was the mentor and @naviji the student. Both know exactly what went in (and Laurent of course).
I think Naveen was still adding stuff after GSoC was over, so I just mention it that you guys don't work on the same thing and can collaborate in case you are.
Improvements are always welcome. As I said, let's wait for Laurent's input.
Hey all. The WIP PR was rejected for more discussion. Laurent had this feedback:
I've installed the feature and looked again as I couldn't understand how it worked at all, but I see a few problems now:
It relies on the fact that empty search queries returns something. Normally, empty queries are handled at UI level to return nothing. What it returns for empty queries is undefined behaviour and might be changed later on to return nothing.
It relies on the fact that empty queries return all notes sorted by last updated time. As we are making changes to the sorting algorithm, that might change later on.
It's loading all the notes in GotoAnything, it would have to be limited to 10-20 notes.
Finally, while it makes sense to show the last changed notes, it would also make sense to show the last viewed notes. For example, if I look at a note 10 times a day, I might want to see it before some note I modified one week ago.
It works a bit by chance now, and it's not clear to me that we want to see the last modified notes or last viewed ones or a combination of both (there was some discussion about this a while ago to keep track of most viewed notes but it wasn't implemented), so I think the feature would have to be discussed further, better in the forum, and there would be more work to be done.
I agree with this sentiment. While it will take more work, I do think most recently viewed is a better solution than most recently updated. Please feel free to share your preference (@tbergeron do you have a preference?).
Basing it on Views essentially captures Updates and additionally is useful for looking at reference pages.
My only concern is that Views can more easily be false positives. If we base it on any views of the note whatsoever, it often would capture views when browsing, pressing down-arrow to browse through a user's notes. So we would want to make sure the user viewed it for a certain amount of time before counting it as a view, if the view is coming from the notes list.
I gotta agree with you: most recently viewed is the better option in my opinion as it replicates code editor behavior.
The best example is the one you provided (when switching from a reference document to a document you are actively writing) The reference is never edited so it would stay lower in the list, a few more keystrokes away than if that note would be right after in the list. VSCode, Sublime, etc all does this.
Another option would be: using the back and forward editor buttons would kind of do the same without using GoTo. But at the moment, these buttons have no keyboard shortcuts so this needs mouse clicks / more steps.
Cool. Any thoughts about Laurent's suggestion here regarding frequency?
Finally, while it makes sense to show the last changed notes, it would also make sense to show the last viewed notes. For example, if I look at a note 10 times a day, I might want to see it before some note I modified one week ago.
Frequency can be nice in some regards, but not always. In some ways, I'd treat this functionality like Ctrl/Cmd+Tab, and if Mac or Windows sorted based on frequency it wouldn't make it much easier to jump back to the very last item you want to jump to.
It would be more complicated, but it could always do both I suppose: the top X entries are solely last visited, but after that it could be weighted on decaying visit frequency, and possibly other factors that the current search behavior uses.
