This beta attempts to address the issue of Display scrolling when switching between the Edit and Display tabs, especially for longer Notes. When going from Edit to Display repeatedly, the Display tab should now retain its previous scroll position when returning to Display.
Please let me know how this works for you! Looking forward to feedback.
This beta version is no longer available. Look for a later beta release or the most recent Mac App Store release.
I changed the application name to Notenik beta to not conflict with Notenik (so I get the App Store notification when the new version is released).
But when I launched the beta, none of the Collections I opened would display anything in the Display pane. Edit still had the text.
@ThePrinter reported a similar problem with an earlier beta, with this post. But it turned out that he had too many beta versions in his download folder, and the problem went away when he cleaned things up. See this post. So it may be a problem with renaming the app? I generally keep the beta in my downloads folder, or replace my regular install with the beta, and neither of those approaches seems to produce this particular problem.
Ah, that helps. Launching from Downloads shows the Display and Edit data as expected.
Scroll position seems maintained but not insertion point.
The switching seems not to work when the Text Format is set to Plain Text
Yes, as I explained over here, this beta only attempts to address the issue of restoring the scroll position on the Display tab, instead of always going back to the top.
“Bird by bird” is the only way I know how to do it.
Could you clarify? I just tested it with some notes with the Text Format set to Plain Text and it seemed to work for me.
One general clarification: I’m only restoring the Display scroll position when the user is coming directly from the Edit tab for the same Note. If you go to a second note, and then back to the first, then the Display scroll position will go back to the top.
Got it.
So what I see is that the scroll positions in the two panes are independent, not linked. So if I’m reading Display about halfway down and switch to Edit, I’m not at the equivalent Display scroll position but the last (or initial) Edit position.
Switching back to Display does maintain the original Display position but not the Edit equivalent.
So that bird is done.
Yes, that’s right. (And I was wondering if this issue of linking the two scroll positions would come up at some point…)
Linking the two is both tricky and problematic. iA Writer offers something like this as an option. But scroll positions are expressed as distances (in pixels, or equivalent units) from the top of the content, and there is no easy way to correlate the distance from the top of a Markdown text block to the distance from the top of the equivalent HTML.
So the only way to try to do this in a reasonable way is to try to equate scroll positions as percentages of the entire content. So if you’re halfway down in the Markdown, then position the Display scroller halfway down.
But there are issues here…
For example, if you use reference style links in your Markdown, and place a bunch of links at the bottom of your Markdown document, then that takes up space at the bottom of the Markdown document – even though the links end up being embedded somewhere in the middle of the HTML. So any attempt to get the scroll position of the HTML to match the scroll position of the Markdown is bound to be off and therefore upsetting to the user.
With Notenik, this is even more fraught with issues, considering the scroller on the Edit tab is only for the contents of the Body field, while the scroller on the Display tab is for the entire Note, including other fields.
So I will be content with restoring the previous position of the scroller on the Display tab since this is at least easily explained and reliably performed, and presumably at least better than always putting the user back at the top of the Display tab.
Yes, I can see they really are two different documents. So what’s the equivalent Display position would be hard to calculate in the Edit pane using the scroll position.
Just to make it more complicated, though, the insertion point itself only exists in Edit mode. And I lose that when I switch to Display and return to Edit mode. The Title is highlighted in Edit. And I can’t search to my previous position.
So here’s a couple more birds:
Save the last Edit insertion point and restore it when switching back from Display
Enable Search (which only searches Display) in Edit
So if scroll position was nearly equivalent switching between the two and the last insertion point in Edit was restored, one could switch over to Display to check formatting and back to Edit to continue without losing one’s place.
Of course, there’s no connection between where you go in Display and Edit’s insertion point, so if you move around in Display, you end up back at the last insertion point when you return to Edit. But if you’re just checking formatting in Display and pop back, it’s as if everything has been synced.
Sorry for my late response.
I had misunderstood how you intended it to work.
I appreciate the difficulties in syncing the HTML and markdown text file. I would actually be quite happy with a percentage-based guess. Although it won’t always do one wants, it seems to be preferable to being sent back to where you were previously.
There are some issues here that are somewhat coming up against some of the elements of the Notenik Product Vision, which I have just gotten out of my head and into a first draft form.
In particular, I have never intended Notenik to become a full-fledged Markdown editor, and I have always been careful to allow users to make use of other apps to edit Notenik notes.
In terms of my personal usage, for example, I almost always edit Notes outside of Markdown if they are at all lengthy – using something like BBEdit, or iA Writer, or something of that nature.
So, for example, if I need to search within a Note as part of an edit operation, I almost always do that in BBEdit.
Of course, Notenik has no knowledge of your last insertion point within a BBEdit session, so trying to sync up the display with the last edit is a moot point.
My recent Notenik change, currently in beta, to reposition the Display to its last point when flipping back and forth between Edit and Display, seemed like something that would be broadly useful and intuitive – and turned out not to be too difficult, once I figured out the appropriate APIs to use.
And I’m not at the point where I want to say I will never take on any of the sorts of requests being discussed here.
On the other hand these other things do not seem particularly easy or straightforward for me to implement, and they don’t strike me as things that fall squarely into the product vision.
So they are things that I will probably continue to mull over for a while.
It makes sense not to develop a full-fledged Markdown editor in Notenik. I also normally fire up another app when editing.
For your background information: here is the situation I find a little frustrating. When I’m reading a note (in one of my Notenik knowledge bases) and I want to make a minor change, I then do that in Notenik. That’s the situation when the scrolling issue can be a bit annoying 
That’s helpful background info! Thanks for the clarification.
I found 11. Some Text Editing Is Likely and marimba’s comment above illuminating.
My inclination is to stay on the reservation when using an application. So the thought of using BBEdit, say, to edit a note I’m displaying in Notenik didn’t suggest itself (although I’ve used text files generated by other applications like InDesign with Notenik).
The availability of an Edit mode, rather, encouraged me to edit in Notenik. And I’m not complaining but I see now it might be wiser to use BBEdit for heavy content editing with Notenik’s Display pane to check Markdown formatting.
(Although I hasten to add maintaining the insertion point in Edit and enabling Search in Edit would mitigate my use of BBEdit.)