I’ve just restructured a project and am now dealing with this issue. In combination with the “jumping half a chapter down” bug that I’ve complained about previously and still isn’t fixed, this really does make Scrivenings view unusable for me on the Windows version.
Or at least it would without the AutoHotkey script. Thank you to the maker of that!
Popping in after a longer break, to check if there is any hope for this bug being ever fixed.
I’m editing my current book right now and the requirement to use the mouse is getting on my nerves, and on my wrist. Most work I’m doing, actually, is compiling the document and then doing review in Libre Office, because I need to have the capacity to just move through the text without taking my hands off the keyboard.
So… was there any progress on this? Hope? Light at the end of the tunnel that is NOT going “choo choo” at us?
Hey, welcome back!
I’m not sure if it was mentioned explicitly above, but this is a technical limitation rather than a bug. It may have a solution but it would require overriding how PgUp/Dn work at a lower level and it’s always tricky doing that. The problem is that you’re looking at a stack of completely separate text editors, with a skin applied to the editors to make them look less like that. Thus view control shortcuts operate within the text editors, like Home and End, and wouldn’t naturally “escape” the text editor and operate on something outside of it. This is why Ctrl+A stops at the boundary of the section you are editing, and why you can’t drag a selection across these boundaries.
In short there are piles upon piles of things that we could maybe make better, using this model, that would require breaking how behaviour works normally and rebuilding it—at some point though I think the question becomes whether or not it is better to put all of that time fixing Ctrl+A, and PgUp, and the many text formatting and transformation commands that should work universally (and on and on) into maybe making a better model in the first place, that doesn’t have these issues to begin with. That has never been an impossibility, more a problem of time.
Meanwhile though…
Most work I’m doing, actually, is compiling the document and then doing review in Libre Office…
Why not just drop the proofing copy into Scrivener and do the review there in a split? That’s what I do anyway (though more often with PDF given the workflow I use, but the idea is the same). Combine that with the option to add section links on compile to the output, and the proofing copy can open the sections the text came from in the other editor, while you can scroll the proofing copy while working on the text it came from, with the shortcuts for that in Navigate ▸ Editor ▸ Other Editor.
sigh
I think there is again a misunderstanding.
I don’t mind the fact that pdup/dn do not pass the boundary of documents.
What my complain is about is the fact that with a document that’s over a screen long, pgdn drops TO THE END OF THE DOCUMENT. I can live with it being stopped at the boundary, but going 20-30-40 pages down with one accidental pgdown is very, very annoying.
I think we are working in some significantly differing ways. What I have in Scrivener, are scenes. Scenes that I want to review in a possibly smooth, no-mouse-movements, no-interruption, no-weird-navigation, no-clicks way.
Right now, because Scrivener is having abovementioned problems with correctly doing ONE SCREEN DOWN pgdn action, I need to either use my mouse or use downarrow all the time. Very annoying, very disruptive.
So the result is, I am forced to create what you’d probably call ‘proofing copy’ and compile the scenes into a doc, then use Libre Office to do the review, because LO does pg-dn correctly and I can have a nice, no-fuss experience. Then I go back to Scrivener and put in the changes in the right places, or even replace whole scenes with copy from LO, if I can’t be bothered to search for the right section.
However, this is NOT a comfortable way of doing it, because, in effect, it takes about half of my current work out of Scrivener. I would not mind it, if I was for example sharing the text with someone and they had to get back to me. But this is ME getting back to ME, using two tools, because one of them is unable to handle “page down” in a correct fashion.
What my complain is about is the fact that with a document that’s over a screen long, pgdn drops TO THE END OF THE DOCUMENT. I can live with it being stopped at the boundary, but going 20-30-40 pages down with one accidental pgdown is very, very annoying.
Yes, that is how I wrote the bug report. I don’t think there is a misunderstanding here.
The conversation moved on, to other things, including my describing why it is challenging to fix at a higher level. Perhaps this was confused with my saying we shouldn’t fix it, or that I think it isn’t as bad as it is? I don’t know.
So the result is, I am forced to create what you’d probably call ‘proofing copy’ and compile the scenes into a doc, then use Libre Office to do the review, because LO does pg-dn correctly and I can have a nice, no-fuss experience.
Ah okay, I guess with my preference for using PDF to proof with, I’d never really thought about it like that, to put an editable RTF file into the binder for proofing, let alone splitting it up into small sections so that Scrivenings mode is used, and we encounter the bug again. The idea was to try and avoid it, while staying in Scrivener, rather than go out of the way to recreate its conditions.
But for anyone else that doesn’t mind page by page PDF proofing, to a expand a little on what I briefly glossed over in that paragraph, here are some tips and tricks:
Navigate ▸ Editor ▸ Other Editor ▸ Next|Prev Page, which flips to the next whole page of the PDF, once I’m ready to advance, but since that isn’t Scrivenings view, and thus does not have this bug, the normal “remote pgdn” also works in a fashion that is fairly typical for PDF paging, too. (Note I changed the defaults, which I found arcane and hard to use. Normal Other-PgUp/Down are Alt+Up/Down, and Other-Next/Prev Page are Shift+PgUp/Dn).File ▸ Import ▸ Research Files as Shortcuts, so that compiling in place will update the copy you are proofing from, right in the other editor (and it also means you don’t bloat the project with another whole copy of the work). And with the “other editor” commands you can read through while working in the active editor split.So all editing is being done in Scrivener, against a static copy I compiled for review in a dual-split interface.
For me anyway, I find it much easier to find typos and awkward phrases if I completely change how the text looks, anyway. So for myself, I am not really even going out of the way here as I would want to work like this no matter what. I’m just making use of various Scrivener features to make that way of working so much better (than for example using a stand-alone PDF reader and juggling Alt-Tab and searching for phrases to find binder sections, and other inefficiencies).
Ok, maybe it’s just a question of phrasing then. All good 
However, from my point of view, it is something that should be fixed, if not for any other reason, then because it works differently between single and multidocument mode, and is like in no other editor ever, anywhere, in the market.
Also, if I was looking for an editor that is stuck on comfortably editing single scenes… why in the world would I have switched to Scrivener, when yWriter is right there and is free?
I’m not entirely sure what you mean and the description below doesn’t explain it any better, I’m afraid. My flow is:
This way I don’t need to use any multi-key shotcuts (which TERRIBLY throws me out of the “zone”), I am working on the text that I’m reviewing, so reorganisation of bigger chunks and deletions are visible immediately (and being unable to do the same with a PDF would block me in 0,0 seconds), there are no shortcuts to click, no links to follow, no breaks in the text (also throwing me out of the zone) and C&P into Scrivener is on “whatever is between document spacers”, so also no phrase searching.
Also, I work on one full-width document at the time and not against two scrunched-up, half-width, barely-visible (on my laptop at least) documents that I need to somehow switch between and juggle two things, scrolling side by side. Just thinking about it makes me want to scrub my oven rather than do the edit that I need to finish.
If the Scrivenings mode worked well, I would have a flow of:
Wouldn’t it be lovely?