PageUp/PageDn Don't Work Right in Scrivenings Mode

John, I’ve never done anything like that. For better and for worse, I’m a Windows guy.

That said, I’m pretty sure it can be done, although I may be confusing running Windows O/S under Mac versus running Mac O/S under Windows. There have definitely been posts by people who do this sort of thing. Perhaps one of them will chime in.


There are many issues in my text I only found when I compiled it to Word and had a look at it as a whole - probably the Scrivenings mode would have been the correct solution here. Alas, it’s next to useless for me, since I’m a very keyboard person and if I can’t navigate “normally” with keys, I will not use the functionality. PgDn has meant “one screen down” in all the tools I used until not and I’m not going to unlearn it just for Scrivener.
(which sucks, because I feel like I’ve payed for a piece of software that’s just incompatible with some parts of my brain)



MacOS is not Linux. WSL is specifically geared to the Linux kernel – you can’t use it for FreeBSD, OpenBSD, or any of the other *nix-like OSs, which includes MacOS.

You can’t run MacOS under WSL. You can, in theory, run a Hackintosh as a virtual machine under Windows, but Apple asserts that doing so is a violation of their licensing agreement (license to run MacOS is tied to the Mac hardware it runs on) so if someone wants to go down that route they have to do so on their own.

Likewise, you can run Windows under MacOS via Parallels, VMware Desktop, or some other virtualization software, or run Windows natively on Intel Macs via Boot Camp. Although I don’t know how well the M1 Macs do at virtualizing Windows, since that’s an architecture shift and becomes a matter of using an emulator rather than a hypervisor (an emulator translates between different processor architectures, often with a loss of performance; a hypervisor runs on the same processor architecture and simply keeps multiple separate installations thinking they’re running solo on the hardware.)

EDIT: It looks like Apple says there will be no Boot Camp for M1 Macs; you need an Intel Mac to take advantage of that functionality. Windows running on Mac M1 hardware will be through emulation like Parallels.


That statement cuts to the heart of why this defect in Windows Scrivenings is such an insidious thing.

As you’ve said, it discourages you from using Scrivenings.

In my opinion, when users are discouraged from using Scrivenings, that undercuts some of the key assumptions L&L made when they designed their feature set.

“Smaller+more documents is a better way to structure your binder than larger+fewer documents”. Better because more discrete text elements create more opportunities to utilize metadata, doc links, bookmarks, all those powerful features that Scrivener offers, and “there’s no downside to creating smaller+more documents”.

But with the Windows Scrivenings defect, there is a downside, because there’s no way to view these text elements as part of the larger whole. (Yes, the feature exists, but it doesn’t work.)

I discussed that in more detail in this post from April 2020, which was a response to Kathrine of L&L wondering “what need intra-document links address that cannot be met by the more ‘Scrivener-like’ method of splitting a document and using document-to-document links.” Unfortunately my admittedly verbose post received no reply from L&L.



While undesirable, this is less a bug and more a technical limitation. They did their best to figure out a way of getting all of the pieces of text into one single editor, separated by immutable markers between underlying binder items, but the programming kit just doesn’t have a way of doing that. Thus they’ve had to stick with the approach of stacking multiple discrete editors one after the other in a large scroll view. That is why Ctrl+A only selects one chunk at a time, why PgUp stops once it gets to the top of a section, why Ctrl+Home doesn’t scroll to the very top, etc.

Attempts were made to fake it, but this introduced fragility and too many bugs. So the decision was made to keep it the way it was in v1 and continue waiting for the right parts to arrive to make it work the way it is intended to. It was not an easy decision to make, and it was disappointing to have to make it, but some things aren’t feasible to do—particularly when a project is already running late in a public fashion.

As a staunch proponent of outline-based writing methods, and using Scrivener in that fashion: I do heartily agree with that, and it is unfortunate. We have some of the same friction on iOS as well, which also lacks the capability to stream multiple text files into one single editor instance—but even more so where there is no proper Scrivenings at all (just a read-only navigator, where you can scroll through seamlessly, and tap to jump to a section alone).

That all said…

But with the Windows Scrivenings defect, there is a downside, because there’s no way to view these text elements as part of the larger whole. (Yes, the feature exists, but it doesn’t work.)

That feels like a bit of an exaggeration to me. While I use Scrivener the way it is intended, and while there are occasions where these limitations get in my way, it doesn’t often reach into my awareness. So to say it doesn’t work feels a bit over the top.

I am sure there are factors that will make it more or less annoying for different people. I’ve never been much of a PgUp/Dn user given how it works on the Mac. On the Mac it simply manipulates the scroll bar without moving the cursor, making it purely a reference tool. Thus I have no habit built up for using these keys. The other thing I do a lot of is Ctrl+3 / Ctrl+1 style navigation, with the arrow keys being used to select the section I want to jump to, or when I want to move in a linear fashion, Shift+Alt+Up/DownArrow. To me, essentially collapsing the view to headlines and jumping to the spot I wish to navigate to is leagues more efficient than scrolling—whether by mouse or keyboard. Add on top of that being a Markdown writer that doesn’t generally need to format text, the boundary issue where you cannot format across section lines also doesn’t matter much to me.

To address the query of why it isn’t talked of more, some of what I described above could be involved, but there are probably more mouse users out there than you’re thinking of. So many people depend heavily upon the mouse for everything they do—and if that is how you interface with a text editor, then most of this stuff you’re talking about that makes Scrivenings “not work” simply don’t exist.

Well, that’s probably the Mac-oriented thing - since pgdn/up work in all other Windows applications in exactly the same fashion (Word, Wordpad, notepad, Libre Office, yWriter - you name it; I’m pretty sure Microsoft Write from Windows 3.1 was handling them the same), low-mouse Windows users will expect the same functionality if they see a block of text.
These other key combinations? I’ve never used them in any other tool. I understand having to learn new keyboard shortcuts for the menu in a new tool, but not having to re-learn text navigation.

And it does work OK on a single document in Scrivener, too, so that’s even more jarring. If it didn’t work on a single document as such, I’d have deleted Scrivener sometime around 30 minutes after installing it, I suppose.

The fact that there aren’t that many voices about it? Maybe some were like me - tried, got annoyed, went “meh, probably some Higher Logic I’m Not Going To Understand” and gave up.
My thinking was that since the Scrivenings mode is useless for mass format correction (you have to do it from the outline - OK, not very intuitive, but works), equally useless for C&P of bigger chunks of text across documents (need to export/compile for that), so why should I expect it to be useful for comfortable text review.
As it is, its main function for me now is checking whether I’ve resolved all comments on a particular list of documents, but in order to make any bigger edits I always drop to single document view.

1 Like

Oh wait, I misread part of what was being said, and was thinking only of how it gets “stuck” in sections when there is a long sequence of short ones (never mind getting stuck on each title if you have them enabled). That it acts like Ctrl+Home/End as well (visible in longer sections) is something that is hopefully easier to fix than it not getting stuck.

We do in fact already have an open ticket on this, along with numerous other refinements to Scrivenings that should be doable without making it a pure single-editor view. I’ve added this conversation to it for reference. Honestly it’s a bit crazy that this hasn’t been fixed yet.

Oh sure, and on the Mac (and Linux, and DOS and everything) it works similarly—about 4/5ths of a view’s worth of text scrolled at a time. The only difference, and what makes it something I don’t habitually use in text editors, is the lack of cursor placement, meaning the moment you move the cursor or start typing it snaps all the way back from where you started. You thus need a mouse to use PgUp/Dn anyway (for cursor placement), and therefore you might as well just scrollwheel or trackpad scroll.

As it is, its main function for me now is checking whether I’ve resolved all comments on a particular list of documents, but in order to make any bigger edits I always drop to single document view.

Yeah, I can see that if you want to use it for copy paste, formatting and other such things. For myself I use it constantly, I’m hardly ever not using it in fact, since I break things down into such small pieces. But given my habits I don’t have the same friction toward using it. Hence, why I raise my eyebrow at the statement that it flat out doesn’t work.

THIS (getting stuck) is kind of actually what I’d expect - since the mode if very “separated” by documents (select all works on one etc), getting stuck on the last line is not comfy, but somewhat expected.
Getting suddenly dropped 4-5 screens down on one page-down? Not what I’d call reasonable. Good to know that this could potentially be solved at some point! :slight_smile:

My wrists whined in pain at the thought.

It works, yes. Just… it’s much less of use than it potentially could be? If it’s not useful for mass-editing multiple documents (sigh, but OK) AND it’s annoying when navigating inside ONE of them… Than it’s not that useful in general. I understand that people who use mouse in general would not notice this, but when you get a user who is very used to speedy keyboard navigation, the result will not be pretty.

1 Like

I am curious why they couldn’t have simply computed the jump and then moved the scrollbar and set the new carat position programatically?

(This may be a naïve question, but I’d be interested in the answer)


In my situation, I’ve used Scrivenings mode on occasion, but generally am making small changes so PgUp/Dn (or issues with same) don’t have much chance to bubble up from annoyance to awareness. I didn’t really experience the issue in its fullest until I pulled in a whole bunch of documents to edit together, and was moving back and forth quite extensively within the collection.

I’m not sure why they can’t just move the scrollbar. I think (knowing the “problem”) that I could even live with the carat being slightly off-- knowing the problem. It’s a gigantic pain-in-the-butt to be editing a whole collection of 2-3k documents each (multipage documents), and find yourself having to back up and use the mouse or the arrow keys to figure out where you are. Takes me COMPLETELY OUT of “being in the moment” to futzing with the editor.

For me, it’s not enough to make me want to toss Scrivener out completely, but it’s definitely enough to make me want to stare at it a lot and give it dirty looks :slight_smile:

(Though admittedly, 95% of the time, I’m working at the single document level, so it’s not THAT big of an issue… until it is)


Can you talk more about that? And when you say “Headlines”-- could this be construed as “Milestones” ??



I’m not deeply involved in what all was tried, but off the top of my head, I would consider all of the ramifications of that—knowing how many pixels are involved in that computation when you don’t normally have that information, when zoom settings can complicate matters, Scrivenings titles as well, add additional metrics to be calculated around, margin padding that may or may not be applicable depending on cursor position before and after, when you’re sometimes hijacking an editor behaviour that is normally entirely self-contained, etc.

Can you talk more about that? And when you say “Headlines”-- could this be construed as “Milestones” ??

Ctrl+3 enables Outliner mode, so when you’re in a Scrivenings session and press that shortcut, it highlights the section you were in. If you highlight another section and press Ctrl+1 you switch back to Scrivenings mode, scrolled to the section you selected. So by combining that with arrow keys you can swiftly get around in a long session. That should all be working properly now—if not it’ll be in the next update.

Yes, if I understand you correctly, this is the only aspect that’s annoying me. I can live with document boundary restrictions / issues (and, in fact, would understand completely w/o further complaint). I’m simply editing a collection of documents that are each multiple pages and am being frustrated that I can’t pageUp/Dn within a single document in the collection, but rather am being jumped from document to document in a manner similar to CTRL-HOME/END.

1 Like

Is there a Linux version available?


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 :slight_smile:

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!


Oh. But it would still be the Windows version, and have the same limitations, I presume.


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 :slight_smile:

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! :slight_smile: