When reading/reviewing a selection of multiple documents (i.e., all the scenes in a chapter), Scrivener will automatically leap to the end of an individual document once it scrolls onto screen. I presume this is because the cursor was last left at the end of the document, but it makes reading through a selection of scenes very difficult because you keep getting interrupted and having to scroll back up.
That doesnât sound like the typical behaviour for this scenario. Just to clarify, when you say in descriptive terms that you are viewing âa selection of multiple documentsâ, do you mean:
- In the binder, Shift-click between two text items to select a range, or Ctrl-click to select a scattering of items, or click on a single group to view it and all of its descendent items.
- Press Ctrl1 to switch to Scrivenings mode, or use the
View ⸠Scriveningsmenu command to view them together in the editor.
If that is what you are doing, then at that point, how would you procedurally, in terms of how the mouse is being manipulated, or keyboard shortcuts used, cause a section to scroll onto the screen?
For me, for example, if I use the mouse wheel to scroll through a scrivenings session, it does so seamlessly and like you would expect scrolling to work through any long range of text. There is no jumping around.
Here is a link to an existing report that is in the relative vicinity of what you are describing, whereby point-to-point navigation travels to the wrong spot slightly; nowhere near the end of the section though, at least in our awareness of the problem.
1 Like
hey Iâve had the same issue!
I use folders, with texts inside for each chapter, and when I open the folder to view the entire set of chapters at once (which is apparently the scrivenings mode) and use my mouse wheel to scroll down, when I get too close to the bottom of one text, it snaps my view down to wherever Iâd previously left off in the next chapter. This doesnât happen Every time though, and unfortunately I canât identify whatâs different about when it Does.
Iâve found that if I hold the âdownâ key to move my place marker down one line at a time, it doesnât do this, but i recognize that thatâs not the smoothest reading experience.
Iâm sorry I donât have a solution, but i can confirm youâre not the only one this happens to!
2 Likes
Clicking on sequential items via the Binder will result in this behaviour, but thatâs what I expect Scrivener to doâto take me to a cursor point, not the first line of the next document, last line of the prior document.
Check whether you are indeed in Scrivenings mode scrolling from Binder doc to Binder doc via the Editor.
1 Like
To clarify one design point: scrivenings mode deliberately does not save your cursor position (nor should it be doing anything with it). That is only used when editing chunks of text individually. The overall session itself is considered âone thingâ (a âchapterâ in your case), even if technically it is a bunch of little things that go into making it. So if it were to save the cursor anywhere, it would be one single save point for the entire session (we donât do that though for several good reasons).
Letâs try this then, to see first if there are any conditions that may be required to see it happen on your end, or if it can happen from a fairly stock state:
- Use the
Help ⸠Reset Tutorialmenu command, if you already have one saved, or create a new copy of it otherwise. - Click on âThe Binderâ, toward the top, then go down the list of around half a dozen items, repeating the following for each:
3. CtrlEnd in editor to drop the cursor to the end.
4. Click the down arrow button in the top right editor header bar, to flip to the Next Document. - Verify that the cursor is saved in these items by clicking through a few of them.[1]
- Now select âGet Orientedâ and switch to Scrivenings mode.
- Hover the mouse over the editor, and use the scroll wheel to scroll.
That test will help determine with the problem is coming from your project settings. If the tutorial works fine, we can conclude itâs probably something to do with how you have the project set up, and can go from there.
Youâll note there are bugs with how it doesnât actually scroll all the way far enough, these are probably related to the linked thread I already sharedâbut so long as it doesnât scroll to the top we know it saved anyway. âŠď¸
2 Likes
I donât have time just now to do any testing (sorry), but Iâve been encountering this baffling behavior, too. Iâm following this thread with interest.
1 Like
Interesting, I have never seen this. I wonder if hardware and Win version might be worth getting a roll call on.
For me it itâs Windows 10 or Linux/Wine, and a wired Logitech G502 mouse with a physical wheel. No trackpad scrolling, no roller ball, nothing fancy, just the kind that âclicksâ when you rotate it (it does have a decoupler for flywheel scrolling, which would be more like a roller ball on one axis, and I do use that for longer texts, but Iâve never noticed glitching with it).
1 Like
Sure:
- Windows 11
- Kensington Expert Wireless Trackball Mouse
1 Like
Iâm Windows 11, with a Tecknet Wireless mouse.
Iâve tried the testing you suggested and even after a few rounds I havenât experienced the same problem, but I will note that my chapters are usually at least a thousand words, and often much much longer. I donât know if having more text might somehow be the cause? If it matters, i also read at 200% magnification, though I tried changing the zoom in the tutorial and the jumping still didnât occur.
I wish I were more readily able to recreate the issue, but sometimes it seems to happen with every chapter and sometimes I donât notice an issue more than once or twice while iâm reading.
2 Likes
I canât get the behavior to repeat in the tutorial document. But as someone mentioned, those individual text documents are much shorter than my novel scenes. When I scroll in my novel, I notice it most when I click somewhere in a document while scrolling through it (with the mouse wheel). Then when I reach the next document, it shortly leaps forward in the document, forcing me to scroll back up and search for my place.
2 Likes
The idea that this skipping behavior occurs with longer documents rings a bell.
My chapters run about 4,500 words, each composed of many scenes of a few hundred words.
I donât think I have encountered this behavior with smaller scenes/documents, now that I think about it. However, I wonder if the skipping behavior occurred on the few scenes/documents that are particularly long, aka 3,000 or more words. I donât have the personal bandwidth to test just now. However, the next time it happens, Iâll post about the behavior with more specificity, if possible.
2 Likes
Well that hypothesis would certainly explain why I never see it in my daily usage. 
If I ever had a section that long I would have had it chopped up into tiny pieces a few seconds after I found it!
All right, so making a copy of a sample project I use for book-length testing, and throwing together all the 3k+ subsections it has into one extremely long , novella-length"chapter", I am able to encounter some jumpinessâmaybe 25% of the time or so? Itâs hard to say since it takes so much scrolling in between sections; the sample pool is very small, but that seems about right.
Itâs enough to go on anyway, and get a ticket written up for it. Thanks for the investigation!
4 Likes
It definitely happens with scenes that are shorter than 3k words - I just observed it happening after scrolling from a 1249-word scene to a 925-word scene. I am operating with the Binder and Notes sidebars open, though, and at 175% zoom. I think the scene just needs to be longer than can be fully displayed for the jumpiness to occur.
Windows 11
Logitech G502 Hero
Yes, I think that is the key as well (taller-than-screen-sections), itâs just that longer chunks of text make it easier and more frequent to encounter.
3 Likes