Save cursor position within the note

Every time I switch between notes, the cursor position is reset to the top of the note.

When working with a few notes simultaneously, this ibehavior is rather tedious. Is there an easy way to save the current cursor position for a note?

Technically the current cursor position could be added/saved/recorded to the metadata section when switching or leaving a note.

7 Likes

Yes that would be useful. The info could simply be saved in memory while Joplin is running.

3 Likes

The info could simply be saved in memory while Joplin is running.

That's true, but it wouldn't be persistent. The meta data approach has another advantage: it makes it even persistent between devices.

What do you think of adding the cursor position to the metadata when switching a note? Or maybe this can be a 2 step solution:

  1. save position in memory
  2. add position to meta data (this is not absolutely necessary, but has its advantages)

I can open a feature request on github and reference this topic.

1 Like

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.

1 Like

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.

1 Like
1 Like

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!

5 Likes

I second this request.

5 Likes

I'd love that too. I often use the web clipper to save article and read them later.
Remember the cursor position via meta-data would be ideal to me.

2 Likes

I'd like to see this as well.

Discovered the issue via Retain Position Within Tab when Switching Between Tabs · Issue #19 · benji300/joplin-note-tabs · GitHub

1 Like

I would love this feature too. Working with long notes without it is painful.

4 Likes

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.

OS: Android 7.0
Joplin: Joplin 1.7.5

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.

Any updates?

1 Like

Hello Everyone. I would suggest to consider this improvement, because it is relatively annoying for long text management.

Regards and ciao

6 Likes

For me as well, this would be a higher priority than most feature requests because it directly affects workflow and efficiency.

4 Likes

I think this should belong to the core function like the tab page. . .

2 Likes

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.

I reviewed the existing forum posts and github issues, e.g. scroll position is not remembered · Issue #4797 · laurent22/joplin · GitHub. The issue is closed by PR#4806. The PR seems right to me, however, it fixes only one cause, and the other causes remain.

If needed, I'll tackle with this problem, after Sync-scroll Pull Request is integrated. How about it?

7 Likes

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!

2 Likes

Finally, Sync-scroll Pull Request is integrated.

Then, I try to solve the problems in the issue, Desktop: Scroll position is not remembered/preserved in Markdown Editor and Viewer · Issue #5708 · laurent22/joplin. And I'll report the progress there.

6 Likes