#1

Say I am working on a long note, and I am in Edit mode, and when I type Cmd+E the cursor jumps to the top. Typing Cmd+E again I get back to the Edit mode to the point I was before. Then typing Cmd+E the note goes back to Preview with the cursor positioned where I was in Edit mode.

I made a video, unfortunately a Gif would be 13 MB, so I saved it as an mp4 file. This forum does not accept the mp4 format, so you can view the file here.

2 Likes
First switch to preview does not open the document to the right location
#2

Yes, I know what you mean

I think the expected behavior is that a user would preview after completing a note and would prefer to see the whole thing without having to scroll up. I sometimes use it this way

To preview your work as you go, ie to make sure a given line renders properly, open a second linked pane and do ctrl+e on that one. It will match the position of your editing window

#3

Well, that’s not how I work. And to assume that people work like that does not seem right.

In any case, none of the other markdown apps I tried showed this behaviour, and I find it most irritating.

Should I file a bug report?

#4

Related, I think: Saving the scroll location in a document

Implementation of this is tough, though, I suspect. What if a user has the same note open in multiple places? (e.g., as you might if referencing several parts of a long document simultaneously). Remembering and restoring the scroll location of one of those panes as different from others might conflict, so there’d need to be some way to differentiate the panes on both backend and frontend… Point being that it seems like a non-trivial design decision.

Also, WYSIWYG will probably erase the need for this.

Still, feature requests are never a bad thing—feel free to file one!

1 Like
#5

@ryanjamurphy: having the same note open in 2 panes does not mean they are both in the same mode, i.e one can be in Edit mode and the other in Preview mode, and with cursor at different positions in each pane. And that requires remembering 2 different things already.

So, I cannot really see that as an albatross. Still, I am not an expert, so I may well miss the finer aspects of the issue.

WYSIWYG may well solve it, but how far away is that in time? Is it still planned to be implemented before the end of this year, as I have heard/seen stated?

#6

I’m mostly in agreement with you—just trying to think through why this isn’t already built in.

Here’s the scenario I’m imagining: say you’re working on Meganote, which contains a dozen top-level headings. You need to write the sixth section, but that requires referencing info in sections 1, 2, and 4.

So: you have an edit pane focused on Meganote section 6, three preview panes with sections 1, 2, and 4. You don’t want to open a linked preview pane for Meganote section 6 because that’d be way too many headings.

You are editing away in section 6, and the handy new “remember where I was in Edit mode” feature is helping you flicker between edit and preview with reckless abandon.

But then you notice that there’s a minor issue in section 1 you need to edit. You select that pane, switch to edit, fix it, and switch back. How does Obsidian know where to “sync” the scroll position for this pane, versus your other pane focused on section 6?

I suppose the app could cache the current scroll position of every pane’s edit and preview mode, independent of the note, and use that information to keep things aligned… I don’t know enough about the finer aspects, either, to comment on whether that’s easy or not. But I guess my overall point is that this may not be easy.

Either way, though, I think it’d be a valuable improvement in the app editing experience.

I’m afraid I know no more than you on this front!

#7

Interesting… I think this should be a bug report and not a feature request.

I’ve had this behavior happen before (returning to the top of a long document the first time you preview it) and sometimes that was what I wanted to happen, sometimes not. But now that I’m paying attention, I’m finding it doesn’t happen consistently. Just opened or created a dozen markdown files and they kept the same position on the first, second, and third time I switched between edit and preview modes. So am not sure how to reproduce the issue.

In the case where I do want to return to the top of the document to review it all after completing an edit (which is probably the minority use case), ideally I would be able to hit ctrl+e and then home or mash Page Up but I can’t do that. The window isn’t selected until I click on it. So that’s another bug.

Ryan is quite right that cursor/scroll positioning is complicated, and comes with tradeoffs. The top visible line in the pane stays the same when going between edit and preview modes, and normally that’s fine. But what if I’m editing a line below a large embedded image, or transcluded link? In that case, when I switch to preview mode, I can no longer see the line I just edited, because the embedded element has pushed it out of view! And you can’t center the view on the cursor, because there’s no cursor in Preview mode.

2 Likes
#8

I raised a bug report, in which I also mentioned the related feature request mentioned above by @ryanjamurphy.

1 Like