Is there a Linux version available?
JWhitten
I meant that is how PgDn works everywhere, not that Scrivener is available everywhere. But yes, so long as you don’t mind running it through WINE. It works quite well, even faster than through Windows on the same hardware, for some reason.
I would think all of that would be handled at a much lower-level, and the rest could be determined by noting the size of the viewport and applying an equation to compute the offsets. The font size is presumably known, the level of zoom is presumably known, and presumably, you’re working within a viewport that’s going to clip anything outside of it anyway. And, you know where the previous (currently displayed) block was located (start/end bounds), so why would it present a problem in retrieving the next (or previous) block?
Again, I’ve got a naive perspective here. Not meaning really to take anybody to task, just curious about the problem is all.
As a potential workaround to “fix” the problem, why not do something like this… The user selects the documents to edit (by whatever method), and then instead of using “stacked invisible editors”, read them into a new editor and simply make note of where the individual documents begin and end? You’re really doing this anyway, if you think about it, when you put the visible line between the documents in the scrivenings view. I understand that you’re doing it via another method, but there’s no reason you couldn’t do the same thing for another reason. Then the user could edit the entire collection in a single editor, and then you can update the original documents as needed behind the scenes as the changes occur. From a functional standpoint it’s nearly the same thing you’re already doing. From the user’s standpoint, s/he sees it as one collective document being edited, and the editor treats it as such.
Just spitballin’… y’all are a lot smarter and more knowledgeable about the issue than I am 
I will have to look into that. I would LOVE to have a “Milestones” feature. I submitted a Wish request for it the other day. While I’d like to have it fully implemented, I would also be interested in any improvements I could make to my current methods in the meantime.
As always, thanks for your time, and interesting perspectives!
John
Oh. But it would still be the Windows version, and have the same limitations, I presume.
John
Well you know, like I say I wasn’t involved in what was tried and what failed, so it’s all speculation on my part as well. All I know is that they put months of effort into trying to make Scrivenings more seamless and nothing was better than what we have at the moment. It all remains under an umbrella of things we really want to do, but have hands tied by the limitations of the system. But that’s all more about getting stuck in sections, particularly with Ctrl+Home/End, Ctrl+A, etc., than this awkward malfunction of the scroll feature.
Oh. But it would still be the Windows version, and have the same limitations, I presume.
Precisely so.
Fair enough
But would you be willing to run my workaround suggestion to the devs? If it was practical to do, it would sidestep the entire issue and present a single editor face to the user for all of the collected (selected) documents, and at a cost of simply injecting a “document delimiter token” into the editing stream (for each document in the list) and keeping track of them during the edit. Then you would be able to know exactly which “real” document to update as changes occur. When the editing session is over, simply toss away the editor-- as the changes should have already been made to the underlying documents.
When I say this is similar to what you’re doing now (functionally), I’m pointing out that you’re just stacking editors and putting a visible line between them. Same difference, just more (obvious) hassle on the front-end for the user.
Anyway-- you can have the final word. I’m just trying to be helpful!
John
Amber,
First, I wanted to thank you for acknowledging and responding to this issue.
Not to me.
From August 2014, when I first bought Scriv v1, to July 2020, when I finally broke down and bought a trackball mouse with a scroll wheel, due to the PageUp/Dn defect, I almost never used Scrivenings mode. There were periods of a few weeks here and there over those 6 years where I really tried to make it work, but a lifetime of muscle memory could not be overcome.
With the purchase of a scroll wheel, as I mentioned upthread, the Scrivenings defect has become less of an issue for me.
But I still don’t use Scrivenings mode when I would most want to. I’d love to be able to stitch together a completed draft of multiple scenes or chapters, and review and revise them while scrolling through using PageUp/Dn in Composition Mode. But I can’t, because I don’t want to have to take my hands off the keyboard when I’m editing. So in the review & revise scenario, I must continue to resort to editing single documents at a time in Comp Mode, and navigate the binder using Alt-Shift-Arrow.
So even with the scroll wheel, there are still use cases where Windows Scrivenings doesn’t work for me.
Yes, because your navigation approach is different than mine. If I must adopt your approach for it to work, is it really working?
Best,
Jim
1 Like
That isn’t what I said at all, and I went out of my way to stress otherwise. If a plate works for holding salad but doesn’t work for holding soup, would we say that plates don’t work? Of course not, nor would we say that one should stop eating soup entirely and only eat salad. My response was that I tend to eat salad, so for me a plate works fine, and I’ve never really noticed major issues with using it—hence saying plates are nonfunctional, as a blanket statement, is false. This is additionally a statement that does not deny that many people might want to eat soup, and are frustrated that all they have are plates.
1 Like
The way I look at it is that Mac and Windows folks have been handed a plate and a soup bowl, but the Windows bowl has got a couple of holes in it. 
Which is incidentally perfect if you want to drain the water out of the pasta! 
Seriously though, I get it—and I’ve bumped the ticket so it hopefully gets looked at again.
2 Likes
Hi Jim,
If I’ve understood the problem correctly, you can’t use Page Up/Down in Scrivenings mode (which as a confirmed mouse-avoider, I would hate too…)
If this was on the Mac, I’d simply rebind a different key to a Keyboard Maestro macro to repeat the down/up arrows X times. It flickers more than a proper scroll does, so it’s a bit rough and ready, but it works well enough.
You use AutoHotkey don’t you? Does that have something similar?
Regards,
David
Good idea! I suspect the arrow will get stuck at the document boundaries, but I’ll give it a try later when I’m back at my PC.
Ah, I can’t test that because the Mac version doesn’t get stuck… (which is the whole problem I suppose 
).
I suppose you could put a trap in the macro (if can't complete, do next document and continue going down sort of thing…), I don’t have AutoHotKey to test (and I’m not on the iMac with the Parallels anyway…)
Good luck…
2 Likes
Brookter, I need to play around with it more, but it works far better than I expected.
One issue will be finding a balance between PagingUp/Down in the Editor vs. the Outliner or Corkboard views, but maybe I’ll incorporate an additional key with the Page keys to differentiate those scenarios.
Thank you for thinking outside the box!!!
@jwhitten and anyone else willing to try this, change the arrow count to suit your editor setup and preferences.
#NoEnv ; Recommended for performance and compatibility with future AutoHotkey releases.
#Warn ; Enable warnings to assist with detecting common errors.
SendMode Input ; Recommended for new scripts due to its superior speed and reliability.
SetWorkingDir %A_ScriptDir% ; Ensures a consistent starting directory.
;--------------------------------------------------------------------------
SetTitleMatchMode, 2
#IfWinActive ahk_class Qt5153QWindowIcon
;--------------------------------------------------------------------------
PgDn::
Send {Down 26}
return
PgUp::
Send {Up 26}
return
1 Like
Hah! I am really chuffed[^1] that it worked!
[^1]: may not translate outside Northern England . Trust me, it’s a good thing….
1 Like
Actually, when using this combination, how do you refocus back on the editor window? I find that I anyway must click it with the mouse, which is most annoying.
Actually, coming back to this one - in single document mode Scrivener doesn’t do it 4/5 of text. It goes 100% + 2 lines. Which is… Well, not intuitive and not what other tools do, either. If I have my document open and the cursor is in line 1, one pg-dn:
- moves focus full screen of text down
- makes the top line slightly chopped off
- moves the cursor to the second visible (first fully visible) line
Like this:
If I press pgdn again, I get:
But at least it’s easily solvable with one “up” arrowpress for each pgdn.
And with small pieces, this is probably much less visible, while I have documents even up to 5,7k (checked my current project), which with my current screen setup is 30 screens. Faulty pagedown is much more annoying in this situation 
Good that it works for you, I’ll wait for the actual solution (considering I’d need to change this setting every time I switch between documents due to the font size/zoom level).
That’s a widespread issue that goes all the way back to the beginning. Most (if not all?) forms of navigation cause a loss of editor focus. I find it easier to cycle focus around though (shortcut is in Navigate ▸ Move Focus To as the top entry—I use the old Ctrl+Tab shortcut). It drives me nuts as well, since I navigate almost exclusively with the keyboard.
I’ve logged the overscroll issue as well, thanks.
1 Like
In that scenario I use Win+[ or Win+] to move focus to Left or to Right editor.
In other scenarios, will use Win+Alt+E to move focus from Binder to Left Editor to Right Editor to Binder.
Does that help?
Best,
Jim
1 Like