I have a question about the behaviour of comments and footnotes in the inspector window.
I like how, when I move back and forth between individual documents in “document view”, I’m always returned to the place where I left off (rather than the top of the document). This is very useful when working on several parts of a draft simultaneously. Unfortunately, footnotes and comments in the inspector pane do not behave this way; while the document view will return me to where I left off, the corresponding inspector view will always default to the topmost footnote/comment. Is there any way to change this?
I hope I’ve managed to express myself clearly. Let me know if this needs further elaborating and thanks in advance for any suggestions you may have!
There isn’t a mechanism for that to happen, sorry to say. There are some things you can do to manage the problem though:
- Clicking on a comment highlight in view within the main editor will scroll it to the right spot.
- You can collapse the ones you aren’t actively using at the moment. With the focus in the inspector, you can even use View ▸ Outline ▸ Collapse All or (Cmd-0), but if you’re editing a comment at the moment, it may be easier to Option-click on one of the arrows to hide them all. By only leaving the stuff you’re actively working on opened, unless you have hundreds of them in one chunk of text, it’s unlikely you’ll be far off from where you need to be when using history. Whether a comment is collapsed is a stored state, and will persist from one session to the next.
Many thanks for the reply, Amber, and thank you also for your suggestions.
Collapsing footnotes and comments doesn’t do it for me I’m afraid – there’s too many of them, or perhaps individual chapters are too long (but I don’t want to make changes to my chapter structure at this point).
I guess I shall have to remain minorly inconvenienced
Well that is something to consider, as it is the sort of problem Scrivener was designed to solve elegantly. You don’t have to limit the lengths of your text in strict accordance with the book structure, because you can order things into logical structure that generates that effect. To provide an extreme example, you can have a chapter that is actually several hundred sentence-length glossary entries in the binder. But a more common approach is to break things down by scenes or sections of a chapter (most of our built-in templates even start out with this setup in mind).
The software is designed to become more powerful and useful with small chunks of text—and since that is its design intent, it does explain why there are sometimes blind spots like this. Since the presumption is that a long chapter with many dozens of notes would not physically be stored into one huge file, the need to build elaborate code to store and reset scroll positions across multiple views is much less pressing.