Hi, it’s been a while since I got around to continuing anything more on my Scrivener reaction time experience.
When I click on a binder’s folder (with any files w/in), the unrelated file I have open in QR loses its displayed comments/footnotes, showing instead “No Text Loaded”.
Switching back to the QR window, then to footnotes, does not restore them. Switching to the file’s Bookmarks (which worked), then back to footnotes, does not restore the footnotes. …
Switching then from that binder’s folder to a single file (diff. from the QR file), the QR file’s footnotes were restored.
The same effect happens to an unrelated file displayed in an editor window that has footnotes/comments. Even when the Inspector view is locked or the fns are not displayed, eg, when bookmarks are displayed during the operation. (When the file has a great many fns, → 80-90, they are first redisplayed as one-line placeholders.)
The fns get unloaded, not when the folder is clicked, but when its file list is displayed in the editor window. The fns get reloaded, not on the single binder file’s selection, but on its display.
Testing the RC/context effect mentioned elsewhere earlier today, Scrivener’s reaction is the same, w/ nuance.
RC’g the folder, the context menu takes a while coming up, and when it does, it comes up alone, the editor-displayed list doesn’t come up til after a bit. (The delays are likely tied to the number of files in the “folder”.) When the file list does come up, the fns go to their “no text loaded” state.
RC’g the file, the menu and the effect come up and happen pretty quickly.
I’ll admit my naivety about how Scrivener works behind the scene, but this all (RC action as well) seems as we’ve suggested earlier that there is (way?) too much connection between accessing the binder and Scrivener’s other processes (and memory?).
(Clicking the folders open/close caret does not affect the fn view.)