Hello all.

Firstly, seeing this is my first proper post in these forums, I would like to salute everyone.

Secondly, I wish to congratulate all those involved in the development of Scrivener, both the Mac and the Windows versions. I find it a fine computer program.

For most of my computer-aware life I have used word processors, even since the days of the Sinclair ZX Spectrum. In recent years, I have used OpenOffice and Word, like so many people. All of these were and are very fine for short pieces of text (and some newest versions are even better at manipulating pictures, which I find odd in a word processor). But – and I can say this from my own experience – those programs are at a disadvantage when it comes to long works, as many people here have learnt. Only lately have I found Scrivener and I have been testing it since then. I am now convinced that it will allow me to resume a project I was forced to abandon before, due to the inadequacy of the software I was using. Congratulations, then, for having created such an usable application.

I would however disagree with the philosophy behind Scrivener’s auto-saving mechanics. This works much the same as other application’s similar functions, for instance Microsoft Office’s (in this respect I think Microsoft got it right, so I’ll use MO by the way of example), with the difference that Scrivener auto-saves to the work file (or rather folder, in its case), while MO auto-saves to a back-up file which MO itself manages.

Scrivener allows one to manually save, but this is mostly redundant and better forgotten (see below), specially if the default of auto-saving every two seconds is kept. Additionally, Scrivener has a Backup feature, which creates a copy of the current project to a different location, managed by Scrivener itself. This feature can be left on automatic, but I would prefer either to set it to activate on manual saves (which I would, in that case, use) or preferably disable it altogether and instead create manual backups by means of File/Back Up/Backup Now, when a consistent work state were reached. This is because, for the sake of this comparison, I am considering Scrivener’s Backup function as the equivalent of other applications’ Save function and I wouldn’t want an automated backup overwriting a manual one.

MO too has a Save command. It saves to the work file, but only on a manual basis.

Now, let us consider for a moment the following questions: What are the specific concerns related with not loosing work in any computer application? And how do Scrivener and MO respond to them?

I think those concerns are two. One is the need, due to the possibility of a crash, to have at all times a file containing an exact copy of the project as it stands at any given moment in the running application’s memory — the more frequently this file can be updated, the better, every second if possible. The other concern, due to the possibility of introducing changes to the work which later are deemed undesirable, is to make it possible to determine when a consistent work state has been reached and, at that moment, to manually save that work to a file which will not be overwritten until the next manual save.

How do Scrivener and MO address these two concerns?

Scrivener addresses the first concern by regularly auto-saving to its work files. It addresses the second one (if my reasoning is followed) by means of the Backup function, which writes to backup files and is better used manually when a consistent work state is reached, as suggested above. (The Snapshot function can be used as well, if only one Document was changed.)

MO addresses the first concern by regularly auto-saving to a backup file. It addresses the second one by the normal Save function, which saves to the work file and should be used when a consistent work state is reached.

As can be seen, both systems adequately and similarly respond to the two problems mentioned, but they do it in a reversed manner, one from the other, in what concerns their use of work files and backup files.

Indeed, I cannot help but to feel that Scrivener saves to backup files and backs up to work files.

Also, the fact that Scrivener’s Save command is mostly redundant but is still present doesn’t seem right. And, (using my logic), one has to use Backup at the moments one would normally (in most other programs) use Save.

It is my opinion, therefore, that the way MO deals with files is more logical, more elegant and more intuitive. And I think it is the way most people are used to work.

Of course, I would very much like to know what other people think of this, specially those who have much greater experience than I of using Scrivener. I believe this issue to be the single-most imperfection in an otherwise very good piece of software.

Scrivener probably doesn’t save to a temporary file primarily because it is always saving to lots of little files–it would need to create an entire copy of the project folder to a temporary version, then remember to copy everything over again once it was done. I think it is a lot easier for things to get confused that way, plus it would slow things down a bit.

I agree it is counter-intuitive, but I know from experience that trusting the auto-save in MO is not always going to get you what you need. Here, no matter what else happens, my work is saved after a certain lag in typing, without requiring my memory to do saves.

You can set Scrivener to backup on manual save as well as at open and/or close. Or turn off altogether. Also, you can use the Snapshot feature to set a manual backup point for that particular document (as opposed to the project in its entirety)–this works quite smoothly.

As I use it: I have it set to do a backup to my Dropbox directory on both Project Close/Exit and on Manual Save. I use Snapshots while working to do a quick backup point for a document if I’m doing edits or revisions.

Hope this helps!

FWIW, I’ve lost work in Microsoft Office (both Word and Excel) within the last month. I don’t remember the last time I lost work in Scrivener, if in fact I ever have. So clearly Scrivener is doing something right.


So it would seem MO has bugs in its auto-save routine which lead to data loss. I don’t quite recall whether or not this has happened to me also, but that’s quite possible.

But bugs are bugs – serious as a bug that causes data loss is; I am talking about program design. And still I would feel much more comfortable if Scrivener, on one hand, let me manage my work folder the way I want, allowing me to save my work to it whenever I feel an important landmark has been reached, confident that such good work won’t be overwritten by my own bad work later, without my telling it to save, and, on the other hand, kept auto-saving – backing up – to another folder, which Scrivener itself would manage.

So much more intuitive!

See [url]].

No, actually the auto save routine functioned exactly as intended, as far as I could tell. However:

  • The auto save point was too far in the past. I had done substantial work since the last save point.
  • Because auto save recovery is entirely under MO’s control, I didn’t know when the last save point was, and was therefore only able to guess at what had actually been lost. (This is especially a problem when doing non-sequential work.)
  • In one case, the last auto save point was actually before my last manual save. This made the recovered file obsolete, but since MO didn’t tell me this I could easily have overwritten my “work” file with the auto save file.

But all of that is somewhat beside the point. You asked what others think of Scrivener’s approach. My response is that I have never (as far as I can remember) lost data with Scrivener. I have lost data with MO on multiple occasions. So while MO’s approach may be superior in theory, in practice it doesn’t work as well.

Also beside the point, but worth mentioning, is the relative rarity of Scrivener crashes, and the relative frequency of MO crashes. Scrivener (Mac) doesn’t crash. MO (Mac) crashes often enough to have given me more experience than I would like with its crash recovery features.


I don’t know that it is a bug, but simply how it works. (It’s not a bug, it’s a feature! :slight_smile: ) Someone else in this thread explains it better than I ever could.

It’s only intuitive because you’re used to how Word does it–that doesn’t mean it is the “right” way to do things for all programs, despite what Microsoft says. :slight_smile:

(In fact, I can count on one hand the times that auto-save helped me, in part because I always worked by making manual backups and saving often. I can’t count high enough the times that auto-save didn’t help me because it wasn’t recent enough.)

However, I think you missed some of the points being made already. Yes, Scrivener’s auto-backup is on the main copy of your project, but by using a combination of manual backups (either through setting the auto-backup to save when you tell it to manually save, or though the use of Snapshots), you can get what you want. If you do something that you feel truly messes up an earlier draft, you can pull up the backup or snapshot are replace the working copy. It’s almost exactly the way you would have it be for your working process, even if the mechanics are very different.

I am no Microsoft advocate, and I don’t even particularly like it’s Office. I just like the way it follows the well established doctrine – not only by Microsoft, but by the vast majority of software publishers, large and small – according to which the file one is working on is not to be overwritten at any time by the application itself, with no way of stopping it; the user should always be able to revert to the last saved state, if he messes things up.

On the other hand, auto-save (or back-up) should be done to a different location, as frequently as possible, as I said. I believe you when you say that MO often messes this up, by not doing it frequently enough. But I don’t really care about MO, I was merely providing an example of a well known program that follows the basic overall way of managing files that I think is best. Scrivener needn’t fall in the same trap; it could carry on saving every two seconds, but just not to the work folder. I’m sure that wouldn’t make it start crashing or loosing data – which never happened to me either, while using it.

I also understand that Scrivener already has all the file protection needed – as I said in the original post. It’s just that it implements it in what I feel is an awkward way. But, of course, if almost everybody prefers it the way it is, there’s no point in my keeping at it. I asked for people’s opinions and the people has spoken :slight_smile:

Hello, I am Mike. I’d like to chime in on the subject if I may. :smiley:

In resopnse to the part in bold above, take a snapshot before making questionable changes then it is a ‘snap’ to revert to the fork in the road. If your response is, “well, how can I anticipate a mistake and know when to snapshot? Sometimes they just happen, without anticipating it.” I would say get in the routine of snapping before you start typing or make use of the configurable back up feature. It can be set to back up at file open and close, and done manually anywhere in between.

Overall, your comment is tantamount to saying it is better to having potentially massive amounts of data being stored in volitile memory in the event you’d like to easily undo something. Following well established doctrine does not make it best. I suspect Scrivener succeeds for so many writers because it doesn’t follow established doctrine in many ways.

I’ve used Word over the past couple decades and in a five-year span produced over 250 multi-hundred page technical documents–using Word. Nightmares is the word that comes to mind. Lost work, mysterious quirks, lagging response times as the files grew in size, random crashing; it seems to trip over itself. I’ve had none of that with Scrivener. Word seems a program best used for typing memos and creating fax cover pages and colorful garage sale signs.

Scrivener’s approach to protecting a writer’s work doesn’t assume that you are mostly typing mistakes, it cautiously assumes you want to save the scrivenings you’re working on. I think it is force of habit and industry routine that has people believing it is better to have data dangling on a thin volatile memory string with the only apparent benefit being that, in the rare event a major mistake is made, just the little red “x” needs to be pressed to make it all go away. You can do that in Scrivener too, although, because that is expected to be the exception and not the rule, it takes a few steps more to get back to where you’d like to be (meaning copy/pasting from a snapshot or opening a backup file). Maybe Word works more efficiently in this regard for the writer that is less confident in their work and backtracks frequently. Even then, I still see Scrivener having the better approach.

With Scrivener, I can choose if I want it to autosave and the idle time after which it will do so. That alone makes it better than Word, in my opinion. Scrivener also has manageable auto and manual backup options, Word’s is only automatic and unocnfigurable.

With Word, untold amounts of works are held in volatile memory forcing the writer to remember to save their work under threat of data loss. And if the power fails before having done so, there is the inevitable mystery of, oh my gosh, when did Word last consider it important to save my work?

To me, with regard to saving/protecting my work, it seems Scrivener does everything Word does and more, and better. It is different than established doctrine though. :smiley:

Indeed. Nor can you ignore the ever-present risk of random crashes with Word.

I can only speak for myself. Maybe other writers work differently. But I would say that the occasions when I want to completely undo a significant amount of work are relatively rare. On those occasions, I usually know going in that what I’m about to do is potentially risky, and taking a backup is a matter of seconds. It’s much more likely that I will want to keep whatever I’ve been doing, and will be unhappy if it vanishes. So Scrivener automates the more common circumstance (wanting to save everything) and asks me to handle the less common circumstance manually. That seems like the correct way for an electronic assistant to behave.



1 - As I said, I don’t like Word very much either. I only used it as an example of a program that doesn’t mess with a person’s work file, which is the norm in Windows world. As I suggested at the top of my original post, I also think Word is no good at all for long, serious works. Scrivener is the (much) better software.

2 - Obviously, you didn’t read what I repeatedly said. I don’t want to have “massive amounts of data being stored in volatile memory…”; I wouldn’t trust a program that forced me to “have data dangling on a thin volatile memory string”. As I clearly and repeatedly stated, I want Scrivener to constantly auto-save/backup the whole project in its memory to a folder, every second if possible (the way it already does), just not to the work folder (only I can touch that, by saving manually – that’s the point), but to a separate one. This way, in the event of a crash, I have the option of resuming from the last auto-save or from the last manual save; and in case I just don’t like my latest changes and want to go back to what I last saved manually – which should be a consistent work state – I can do that too. Best of both worlds. And I don’t care if Word, in trying to do this, messes things up; Scrivener can do it properly.

3 - Scrivener (or any other application) shouldn’t assume anything. It should be flexible (it is already in many respects, that’s what I like it so much) and adapt to any way of working and any type of personality, be it someone always sure of themselves or someone who changes their mind often. Therefore, it shouldn’t assume “you want to save the scrivenings you’re working on”: it’s up to the author to decide if he wants to keep them or scrap them – always sure in the knowledge that everything is constantly being backed up somewhere else, anyway.


You shouldn’t make a backup when what you are about to do is potentially risky, but when you reach a consistent state in your work. The problem with the first approach is that sometimes one is just trying to do something very simple and already done dozens of times, but, suddenly, there’s a momentary lapse of reason, or coordination, one slip of the hand or the eye, and it all ends in great sorrow. (Note that this would be the same if Scrivener worked the way I propose.)

fmcpma, my apologies if I came across abrasive. I did not mean to.

Okay, so I think we all agree that Word isn’t really any good and Scrivener is superior in many if not most respects. However, my point would nevertheless seem to apply to which ever program you would have used as an example because you stated yourself that it behaves according to the “norm in Windows world.” I may have sounded like I was trashing Word specifically but as we seem to agree, the collective “norm,” including Word, behaves differently from Scrivener. So substitute “Word” with any of those other software and my point stands.

And by saying “an example of a program that doesn’t mess with your work file” I guess you’re again suggeting frequent saves to duplicate or backup files somewhere else. But you’re ultimately just arguing to have work on the screen that can be undone by pushing the red “x” instead of following a couple of other steps. I think any approach is going to have something that can be argued against by someone. It’s a matter of finding what works best for the majority and I’m thinking that’s the current setup.

I’m not sure if you read what jenb described previously:

I’m thinking likewise. Frequent backups are sluggish and a potential hindrance and would be ludicrous to perform as frequently as Scrivener can perform saves. Second, auto-saves the way you describe would require duplicate or even multiple files which, in some cases, could contain hundreds or thousands of documents each.

Part of what makes Scrivener work better is that it is structured better or at least differently than the “norm in Windows world.” And it seems to work better all-around for large documents (as you agree). That’s not another attack on MS Word or me saying you are advocating using it. That’s me necessarily comparing the two to make the point that your request might be problematic from a programming standpoint. Scrivener’s structure doesn’t come without its pitfalls, I’m sure. But I personally maintain that regardless of the reason, after I acclimated, I think Scrivener has the better approach for reasons repeatedly stated.

Quite honestly, Scrivener doesn’t assume anything. It responds according to how the user defines parameters. The Windows “norm” defines ill-conceived automation and inflexibility while Scrivener, although different, offers users more options. After I got over the strangeness of it not being like the “norm in the Windows world,” I realized it is so much better.

We really are not understanding each other at all. :slight_smile: All I want is that Scrivener auto-saves to a folder other than the work folder! Sorry, but I’ve said this again and again. It has nothing to do with its Back-up function. I repeat: I want Scrivener to do the exact same thing it is already doing now, that is AUTO-SAVING, which it can smoothly do and does every two seconds, if there are any changes and one stops typing. JUST NOT TO THE WORK FOLDER, but to somewhere else. Nothing to do with the existing official “Back-up” system. Sorry if I also used that expression when I was referring to “auto-saving”. (Let us please leave the existing Back-up system out of this discussion.) So it would still be as smooth as it is now. It just wouldn’t mess with one’s work folder, which will always be my point. When it came to manual-saving, which would be infrequent, it would just be a matter of copying the entire auto-save folder to the work folder. (Sorry for the shouting :blush:).

Yes, I agree that Scrivener is structured in a much better way than traditional word processors and it allows for the structuring of one’s own work in a superb way. But that is not to say that it is perfect. We shouldn’t be blinded by its qualities. When I spoke of “the norm in Windows world” I was referring only to file saving, not other characteristics of the software. We should separate the issues: Scrivener can do many things differently from other software and do them all the better for it and still have some little aspects where it should follow the norm – at least its concept, if not its actual implementation. I’m obviously talking about auto-saving and just changing its target folder, as (re-)explained above, shouldn’t be problematic at all.

Well, you said: “it [Scrivener] cautiously assumes you want to save the scrivenings you’re working on”. I also think it shouldn’t assume anything, namely that one wants to keep everything already written, even to the very last word: in reality, one may be just experimenting, for instance. And, truth be told, in this respect, Scrivener is inflexible to the point of not allowing the user to disable auto-saving.

Also, I don’t think the Windows norm defines ill-conceived automation and inflexibility. It just defines that work files, managed by the user, are one thing, and auto-save files, managed by the software, are another. (Doesn’t the Mac norm?) The implementation of the latter may be poor sometimes, as is the case with MS Office. Fortunately, Scrivener does it already much better. All together now: If we could just persuade the developer to do it to some other folder and leave our work folder well alone… :wink:

PS: Running the risk of repeating myself ad nauseam: if you dont’t think Scrivener could be changed the way I propose, please try at least to understand my idea from previous posts: the main thing is keeping the auto-saving system as is but redirect it away from the work folder, to some other folder. Thank you. :smiley:

I realize the parts that you’ve written again and again. Just like responses have been written again and again but you seem to miss the meat of it. Your request is clear. Various angles of wording have been used to explain to you the problems with your idea.

I will leave backups out of the discussion if you will recognize they are part of the answer to your issue; they’re integral to eliminating the fear you have of auto-saves. It’s like you want to keep stating the request over and over but don’t want to listen to or consider that it likely won’t or can’t work with this software.

Based on your instruction to Katherine on when she should or shouldn’t perform backups, I’m discerning your request has a lot to do with your preferred/personal work style. How often do you actually perform large experiments in your work that need undoing anyway? Maybe a lot but it would suck to have Scrivener rewritten to accommodate such an atypical need. Are the experimental changes you do to your writings normal procedure and not the exception? Even if it is the norm for you, I’m sorry for sounding selfish but, I for one am glad that the Scrivener team designed it to treat my work like I mostly intend what I type.

I certainly never said it was perfect and in fact called out that it undoubtedly has pitfalls from its approach. And again, this goes back to you claiming to understand that the structure is different but then going right back to making a request that conflicts with the structure. Word (arbitrarily chosen as the whipping horse again) works with a single file, making the feature you wish for easy to implement. I’m not sure what other words to use to explain that Scrivener’s structure, that you again claim to understand, would be hardly compatible with the same feature.

If all things stay equal, this is the point at which you respond that you recognize Scrivener’s structure is different but that you just want it to save to another file, and our whole cycle begins to repeat itself again. I want this, but this is why it won’t work, I want this, but this is why it won’t work, I want…

That I did say. Let me be more specific: Scrivener appears to be set up, by the programmers and necessity, in a manner to preserve effort that’s been spent at the keyboard; not making allowances for the easiest ways to undo rare but large booboos (the writer has to take some responsibility at a point!).

Hypothetically, if you are about to delete 5k words from your document, as an experiment, click the snapshot or (uh oh, here’s the word) backup button before making the change. Butt is covered. It’s that simple. Or, as I’ve done in the past, copy the entire .scrv file. I’ve got manual archives of the file that I hang onto for weeks or more in seperate locations.

I’m sensing this discussion will continue without end because it will have been reduced to the subjective matter of preference.

I guess what it boils down to is that the Scrivener team will probably not entertain the idea of gutting and rewriting the software so that it can alleviate auto-save fears from people accustomed to working in lesser writing software designed for relatively different purposes.

EDIT: another problem associated with the “norm in Windows world" (including Word) just occurred to me. How many times have you felt the blood chilling horror of accidentally clicking “Don’t Save” when closing out your program? There’s no undo for that! (And it can’t happen in Scrivener.) Because of that stupid little mistake, coupled with the way the “norm in Windows world" doesn’t auto save, I’ve lost unknown amounts of work.

fmcpma, are you referring to Word’s Versions function, where the program saves versions of the document in the Microsoft>Office>UnsavedFiles Folder and you can compare two versions of the document and restore it if necessary? I can understand why you might find that function beneficial, but it seems, for Scrivener, to be not only impractical, but cumbersome. Maybe I’m weird and I save all of my edited out crap (especially significantly large passages) in a OneNote file (aka somewhere where I can retrieve it if I find that I want/need it in later editing stages). But to do that sort of thing for Scrivener just doesn’t make sense to me. I also, personally, find the Versions function impractical for the way I write so I guess, at least for me, I don’t really see how this sort of function would enhance the use of Scrivener.

I’m pretty sure he’s just referring to the fact that nearly all programs do not automatically save your work as Scrivener does. While in the background they might do an auto-save or back up (to a separate location than your working file), unlike Scrivener they will not automatically save your file in a manner equivalent to the File>Save function that is permanent.

For discussion, I’ll call the common aforementioned environment “Environment A.” Moving from Environment A to Scrivener’s is somewhat disconcerting because, in Environment A, a document file is not affected until the user manually chooses to do so by saving it (e.g., ctrl-S, File>Save, or closing the program and clicking prompt to save). Meaning, the user has to willfully make any changes to the actual data file. And, if one chooses “Don’t Save” upon exiting, all the work since the last manual save will be gone, like it never existied. If there is a computer error or power failure, the last manual save is a concrete copy but more recent auto-saves and/or backups might exist. However, those can be unpredictable with regard to useability, from my experience.

In Scrivener, if there is a computer error or power failure, the beauty of auto-saves saves the day because the concrete file is constantly being updated to reflect your work (unless the user has set some obsurdly long delay period). That feature is supported by additional automation (i.e., backups) and manual options (i.e., backups, snapshots and manually copying the .scrv file).

I believe fmcpma has been suggesting Environment A’s approach for Scrivener but to include a modification in that it incorporates Scrivener’s frequent auto-saving feature in a way that it doesn’t affect the work file but a duplicate set. Unfortunately Scrivener’s multi-file structure approach, that elevates it above other programs in so many ways, would make the proposed system (as good as it is in theory) a logistics nightmare. (That is my understanding but please, Scrivener team, correct me if I am wrong.)

Ultimately I really think it’s a matter of breaking a habit. What I consider to be a bad habit. Environment A’s approach may only seem better because it’s all we’ve ever been taught and given to work with. While no approach will be everything to everyone, I really think Scrivener nailed it. It took me quite some time to trust this auto-saving and it had me initially making frequent copies in case I made a mistake and needed to revert (as fmcpma is describing). But between snapshots and backing up, all of those fears have been allayed whilst simultaneously providing greater protection against disaster. :smiley:

I think fmcpma might be happy with one change in Scrivener’s behavior. For fmcpma, and people of a similar conviction, auto-save should be optional. Give the user an option to turn off auto-save and I think fmcpma would be happy. CTRL+S would work just as it does now and auto-save would not overwrite existing files. Overwrites would require explicit user command. It seems a trivial thing to implement, though I don’t think very many existing Scrivener users would knowingly disable auto-save.

Could that work? I mean switching between documents (not files but the docs within the file) without saving. Wouldn’t Scrivener minimally have to (automatically or by prompt) save when switching between documents as though they were essentially being closed and opened? Doesn’t it, regardless of delay/save time, save upon switching because of the manifold structure?

Actually, no, fmcpma would probably not be happy with just that (based on my understanding of what has been said. I have no psychic hotline into fmcpma’s brain). Because fmcpma does (seem) to want auto-save–just that auto-save not be to the main working file.

Given that each document IS a file, I’m not sure how you’d differentiate between them. At any one time, Scrivener does have to have several files open (main document, document notes, synopsis/card, etc). I assume it has to save when you switch documents just because that is a lot of files.

I think, in the end, one must adapt to Scriv’s way of doing things–not necessarily because Scriv has to be this way, but because it is this way by design. I imagine the original L&L folks sat down and said, “The way things have been done until now don’t work well. Let’s do something different.” It isn’t “intuitive,” because that’s the way we’re used to.

I know that for me, the way Word and its ilk work was actually a problem. I had to manually make a backup first, then do my work and save as often as I could remember to because otherwise something would crash and I’d lose something. I never could wait for it to be in a solid state to save, because I could never trust that the auto-saves Word or Word Perfect provided were good enough. I had to make a manual backup if I thought I’d make any inadvertent changes that could screw things up. And heck, it took me a LONG time to make nice with Scriv’s auto-save function because of this. I didn’t trust it anymore than I trusted Word’s, opting to manually save instead. It grew on me as I used it more though, knowing I could trust that it was good, on my actual working copy, and saved so often I never had to think about it again.

Yes, Scrivener is different from what you’re used to. But I seriously doubt you’ll find an application that does what it does and have it work any other way than what it does. It gives you the tools to get exactly what you want out of it, with the amount of protection you want out of it. Only thing is, that you have to adjust your workflow to the way it works. Since Scrivener does a LOT of things different from other applications and their imposed processes, I think it is going to be easier to adjust than you think.

I am not trying to say that we just just accept everything without questioning it. Suggestions and feedback, especially to a responsive group like the L&L development team, are what make products grow. I do think though that trying to understand WHY the product is the way it is, and starting from there, is a better way to affect change. When dealing with stuff that works differently from the norm on purpose, you don’t get far just by saying “but that’s how the other guys do it.” Because they know that and wanted a new approach.

I hope you end up liking the way Scriv does it, and can adapt your process to work with, rather than against, how Scriv is set up. Because I think the software is quite awesome, and it helps me a lot. And I wish such happy writings upon you.

So you’re agreeing that it likely wouldn’t work… right? Your last sentence in the quote is essentially what I was getting at. Wow, it would be really cool to understand how it works because I’m thinking multiple docs must be open for some split screen scenarios and, not least, in Scrivenings mode when it seems to combine docs.

I’ve understood one of Scrivener’s main strengths, in regard to large documents, is how it is designed to have them broken into smaller pieces for manageability (manageability for us or it?). But somehow, it maintains its integrity even when operating similarly to some of the big name software (that is to say, when not broken up). I’m probably revealing too much of my ignorance for one evening. :confused:

However the mechanics of it work behind the scenes, it’s finely crafted in my opinion.