Edit location in scrivening lost on re-open

[Julian_M1]

v3.1.5.0, Win-10 64-bit

Proofing the novel by parts as scrivenings (~100 docs) I find that, whereas the last edit location/insertion point is saved for individual documents, when the project is reopened the edit location of the scrivening is reset to the top.

The inconsistency suggests this may be a bug, but it could just be incomplete functionality as remembering the edit location in a scrivening probably requires remembering the document and the location of the edit point.

[AmberV]

This post was a troubleshooting response that goes into other things, but it also describes intended behaviour and limitations:

Returning to same position in document when navigating

Hmm, that should be working just fine, especially with the history function. There is one limitation with storing the cursor position in a Scrivenings session1—since that represent an entity that only exists while you are looking at it. There is nowhere to store the precise information cursor position reliably in that case. However, when using the history buttons, the cursor position is stored into the history “buffer”, so in a sense it does exist beyond the point when you are looking at it. Le…

[Julian_M1]

Thanks; I understand it is working as intended.

(Would be nice if it could come to work per user naïve expectation, one day )

[aleph]

Hi -
I love Scrivener, but haven’t used it for a while and have just upgraded to Version 3 for Mac.

Frankly, the lack of this basic functionality is disappointing. I’m saying this because I am sure that it is possible to code this feature into the app. If you keep a history of the sets of binder items a user views in Scrivenings mode, you can store the edit location along with it. When the user later returns to viewing a stored Scrivenings set, you can recall and apply that location.

Would you be so kind as to explain what the reason for not implementing this is? Is it on the coding side or is it because this feature is not considered as important as I think it is or maybe something else?

Thank you for your work.

[AmberV]

It is more the former than anything else, along with some practical things to consider that would fall under the latter. There are conceptual design issues with storing this in a permanent fashion, within a largely volatile environment.

You can see the side-effects of that even in the part that does work, in the history queue. As a test throw five single-paragraph items into a Multiple Selection scrivenings session. Put the cursor into the 3rd, selecting a few words, and use the Highlight function to mark it for future reference—leave the selection untouched, and click on the second item alone in the binder. Paste in a few thousand words of junk text. Lastly, press the Back button in the browser to return to your scrivenings session.

Oops! The selection is technically right where you left it, n number of characters from the start, and y number of characters long. Only now it’s in the beginning of the second item, which now extends down quite a ways before we get to the highlighted text we marked in the third item.

So that’s something that can happen even in history, but we figured that the chances of that happening in a way that is confusing or frustrating will be greatly minimised by the fact that most people don’t use history beyond the present tense. The chances of you making dramatic edits to components within the session are much lower. This “error” can be encountered for other reasons too, such as shuffling the order of things in the binder, deleting sections, etc.

You can perhaps see now where these problems would become much more obvious, much more confusing, and much more frustrating, when you’re storing the cursor position forever on elements that will almost certainly gradually become dramatically different than the last time you viewed them in scrivenings (maybe years ago), given the nature of the software being a writing program and all.

I think it is fair to say that over time, this would eventually start to feel random, and that there is a sensible temporal limit on how long that data would be useful—one where we already kind of a have a kind of temporal limited and has an implementation created: history.

In summary: I do not see any practical problem with our current suggestion for workflow. If we accept that stored offsets will degrade over time, and accept that they will only remain useful in recently worked within sessions, then the suggestion to use History to return to these sessions, instead of repeatedly navigating to them fresh (bloating the history and making it less useful), is not an imposition or workaround: it’s just good use of the software’s existing capabilities and tapping into its strengths, to get the result you’re looking for.