Yes please open an issue with it and it would indeed be useful. I have no objection for the first step but the second one I’m not so keen as it feels more like app state. I think the issue is that it means every time you read a note, you will also modify it and it then will need to be synced.
This is partly correct. Every time you edit a note (or change the cursor position) a sync would be required. But since you already sync after every key stroke, this wouldn't be much of an overhead.
Just reading the note itself should not change the cursor position (unless the note is opened on a different device and the cursor position is not the same).
Anyway, I do understand your reluctance. The first step is sufficient for most cases. It's just that the cursor postions would be lost after restarting the app.
Any chance we can get another look at this issue? I note that it’s open in github, was queued up for the hackathon this past Halloween and then dropped.
I generally write very long notes (think of multi-month projects) and having to scroll all the way to the bottom every time I open a note is painful!
This feature would be useful for me as well. Although I notice some people were saying the cursor defaults to the top. On my device (details below), the cursor actually starts at the bottom of the note upon opening.
I realize asking here may not be useful, but I'm wondering if there has been any progress on this. It looked like, from the initial posts, this would be an easy problem to solve. I've also read through the github issue, but it seems that it hasn't moved forward.
Through reviewing UX & UI of Joplin as a newly-coming user, I found some problems and am trying to solve some of them. One of the remaining is "scroll position is not remembered" discussed here.
The problem consists of two strongly related sub-problems:
(A) Scroll position is not remembered, when a selected note changes.
(B) Scroll position is not preserved, when the editor layout (Editor/Viewer/Split) changes.
I examined them using Joplin desktop app 2.4.9 and summarize here.
First, WYSIWYG editor has no problem. So, I talk about Markdown Editor and Viewer.
For (A) Note Change:
Layout
Result (preserved)
Result (moved to)
Viewer
Always
-
Editor
-
Always, top (mostly), middle/bottom (sometimes)
Split
Sometimes
Otherwise, as above
For (B) Layout Change:
From
To
Result (preserved)
Result (moved to)
Viewer
Editor
Always, with a little gap
-
Editor
Viewer
Sometimes, with a little gap
Otherwise, bottom
Split
Editor
Sometimes, with a gap
Otherwise, bottom
Editor
Split
Sometimes, with a gap
Otherwise, bottom
Split
Viewer
Always, with a little gap
-
Viewer
Split
Always, with a gap
-
Since most results are the mixture of preserved and not, it is difficult to examine them. To complicate matters, if a position looked preserved, it would be nothing more than moved to somewhere near the right place. This is the reason that many reports conflict (the problem occurs or not, and it can be reproduced or not).
Anyway, the problem is still alive and not solved.
Looks like there is decent pressure to get this fixed and you're already working in this space so I think you'll do a good job. I'm looking forward to seeing what you come up with!