Sometimes Scrivener adds a carriage return between documents, sometimes it doesn't. No consistency. Why?

I don’t use separators between scenes. I use a single blank carriage returns, averaging 3 scenes per chapter. I’d like to have each scene in a separate document in the binder. Sometimes, for structural organization, I may want parts of scenes in separate documents in the binder (IOW, no carriage return betweens them).

But Scrivener will not allow this, because sometimes it adds a carriage return between documents inside a folder automatically, and sometimes it doesn’t. I can’t for the life of me understand why.

So since I can’t trust Scrivener to behave consistently, and I can’t find a way to NOT have it put extra carriage returns between documents inside a folder, I am limited to having one document per chapter and managing the extra line carriage returns between scene breaks manually. That is really cumbersome and inconvenient. If I could trust Scrivener to never put a carriage return between documents, that would solve this problem.

I can’t even imagine why anyone would want an automatic carriage return added between documents, and I certainly can’t imagine anyone wanting Scrivener to do that randomly and inconsistently.

Note that I am not speaking about an issue in compiling, I am speaking of an issue in the editor. I want the editor to reflect accurately where these carriage returns are, I would also like to see the compiling reflect that accurately,

So far, I have not been sucessful in getting Scrivener to behave consistently in this regard,

Do any of you gurus have a suggestion?

If I understand correctly, you are talking about an effect you are seeing in Scrivener’s editor (presumably when viewing multiple docs in Scrivenings mode) – rather than something in compiled output. And I take it you have Scriv set not to show you any mark of your doc breaks.

Just to leave no stone unturned two things come to mind that could cause non-uniform breaks: i) trailing carriage returns at the end of some docs, ii) there are folders or container docs (that do not have textual content of their own) in the scope of the scrivenings session.


Actually, that is the exact opposite problem. It is not evident in the editor, only when compiled for ePub or mobi. That is exactly what makes it a problem, its invisibility.

I have the standard single solid line divider set that I think is the default prefs choice for indicating a successive document in the editor.

I am very careful to not allow multiple carriage returns, including having the ‘invisibles’ turned on to show if they are there or not.

This problem manifests between successive docs (all of which contain text) inside a folder, each representing a scene or a beat, and not all of these should have a scene break (extra line) after them. If I want an extra line added, I will add that manually, but it does me no favor when it starts to put extra lines in between documents that I do not want to have extra lines between in the compile, randomly.

I am trying to use the Folder as a chapter holder, and the documents inside it as scene or beat holders. I prefer to manage scene breaks without separators and with a single carriage return instead. What I do not want is carriage returns or extra lines added randomly between these scenes in the compile, and especially if there is no indication that this will occur during compile, based on what is visible in the editor.

I think I’ve found a clue. It may not be random, but it still is unexplained behavior.

Assume two consecutive docs. Turn on ‘show invisibles’. Select each separately in the binder. There is no carriage return (or anything else) after the last period in the last sentence of the first doc. There is no carriage return (or anything else) before the first word of the first line of the second doc.

But when you select both docs together in the binder, now a carriage return magically appears after the period in the last line of the first doc, and another carriage return appears ABOVE the first word of the first line in the second doc.

That alone seems ridiculous.

Yes, it is inferred that the second doc does imply a single carriage return (or else it would continue on the same line as the ending line of the first doc, without even a space between those two lines). But that is not what the invisibles indicate. They indicate two separate carriage returns, neither of which were added by the author.

Now, what happens when you merge those two documents (which must be done by selecting them together in the binder)?

Two carriage returns.

I do not WANT two carriage returns between successive docs, and I do not want two carriage returns added automatically when I merge consecutive docs, I did not place them there, and if I did want them there, I would place them there, myself.

No, Scrivener placed them there. Why would anyone want that?

And now, compiling places two carriage returns in the compiled output. WTF?

This means we can not have multiple docs inside a folder and then merge the docs without Scrivener adding extra carriage returns, because merging docs screws up the formatting and the compiling.

That is the textbook definition of a bug. Software behaving differently than it is designed to. Or is it a bug? Is it just a design flaw? Either way, it significantly devalues the product, and it is behavior that could, and probably should, be fixed.

It’s really very simple. If consecutive docs do not have extra carriage returns between them (placed there by the author), then extra carriage returns should not be added indiscriminately by Scrivener when they are merged. Also, two carriage return symbols (in the invisibles) should not appear in the editor when selecting those documents together in the binder. That’s a no-brainer if I ever saw one.

Hi Jack Daniel,

If I’m understanding you correctly, what you’ve done with the above is put the documents into Scrivenings mode. IMHO that’s a red herring, as what you see in Scrivenings mode does not correspond at all with compiled output.

I’m on Windows v1.9, and compile has changed significantly in Mac v3, so I’m afraid I can’t give you specific guidance. That said, have you checked your compile Separators settings? This is what tells the compiler what to add between docs, and would be the first place I’d look if you were on Windows. The Windows version looks like this:

Hopefully you see a clue in the Separators settings that helps you figure this out.


JimRac is right on both counts.

  1. What you see in Scrivenings mode just represents what the editor is doing to show you what it does there. Those fantom carriage returns are not being added to your docs nor used in compile.

  2. I also think you issue is in your Compile settings. Here are some screenshots directing you to the same place that JimRac is pointing you, but on Scriv 3 for Mac.

FIRST: Open the Compile dialog, make sure the Compile Format you use is picked. Click on Assign Layouts.

SECOND: In the Assign Layouts, we want to find out what Layout your Text files are being mapped to. Click on Text in the left column. The layout that darken on the right is the Layout Format you want to remember, Close this dialog box,

THIRD: Back at the Compile dialog, choose Edit Format (under the gear icon at bottom left). If it is not editable, you will need to duplicate it and edit the duplicate (which you could also do for safety, if you want).

FOURTH: In the Compile Format settings make sure the output format you care about it picked at the upper left (e.g. pdf). There are two things to check in the settings here (bother under Separators), but I am betting on the second one being the source of your problem.

First check under under text files that the between-section separator is set to Single Return (not Empty Line). You may or may not want the before-sections set the same way – this would apply to the first text file in a folder and could be set to add an empty line before it.

Second, in the same area, click Text Section (or whatever was the name of the Layout we determined earlier in step two). Here too we want to make sure the between-sections separator is set to Single Return, not Empty Line. (I suspect it is not so set.)

You should be able to close the settings dialog and get back to the Compile dialog box and see if these changes worked.

If so, then the answer is that you are using a Compile Format that was designed for a different workflow than yours – one that imagined that someone would be making one scene per doc and wanting line breaks between them.* And if that is right, the behaviour wasn’t really so ridiculous at all!

If I were you I would duplicate that Compile Format and let this tweak be the beginning of making it your own, so it works the way you work.

I hope this helps.


  • I would not want to be tied to this either! But before Scriv 3 came out, L&L spent time surveying how people work in Scrivener with the idea of providing compile formats that would make things easier for new users. Apparently, it turns out a look of people (for prose fiction) use simple folder hierarchies for Parts and Chapters and with one scene per doc within that!

P.S. Going forward, if I may suggest, I think you don’t need to work so hard making a case that a bug needs to be fixed or that the trouble you are having is something you need help with. L&L is very responsive and definitely wants to fix bugs! Explaining what is the problem your having is usually enough.

What JimRac and gr have said about the relationship between Scrivenings Mode and Compile, but if you wish to have vertically accurate scrivening dividers in the Editor: Preferences > Appearances > Scrivenings > Options > Scrivening Separators > (for a standard text document) Normal : > (dropdown) Corners

See specifically Sec. 15.10.4 of the manual and there’s other good info in 15.10 about editing multiple documents. A general search for Scrivenings Mode will add even more.

For merge separators the setting is at: Preferences > General > Separators > Text Separators > Merged documents > Separator > (rather than Empty Line, choose) Single Return
See Sec. 15.4, Splitting and Merging Documents, in the manual.

Beyond that, there’s ways to clean up returns such as usingText Tidying located in the Edit menu, and of course much can be done at Compile, as gr has explained.

Thanks so much for your input, Jim. I appreciate it much.
You are correct, I am reporting what appears in Scrivenings mode in the editor (multiple docs selected). But I am puzzled why insrutable software would want to be inscrutable, and allow ‘red herrings’. That seems counter-intuitive. Regardless, what I am seeing is that compiling does indeed correspond directly with the editor. What I mean is when the editor shows one carriage return (noted by the little paragraph symbol ‘invisible’), there is then one blank line representing that in the compiled output. When there are two, there are two. When there are three, there are three. It seems to correspond very closely.

This is certainly the place to begin, I agree. But I also find this inscrutable, as well. What is the difference between an ‘empty line’ and a ‘single return’? Does not a ‘single return’ yield an ‘empty line’? And what is ‘custom’? That appears to be also an extra line that allows for a custom separator. What seems to not be available is the option for no line or no carriage return.

Of course it is assumed that docs end at the end of paragraphs and begin at the beginning of paragraphs, and not in the middle of paragraphs, so of course there is an implied return between documents. But it makes no sense that there is not a setting that will not allow two carriage returns between consecutive docs.

I apologize, but I am yet to be convinced of this. If Scrivenings indicates what should happen in compile (which it should), then what it shows should end up faithfully in the compile. And, it does. If I see two carriage rerturn ‘invisibles’ in the editor, then there are two corresponding blank lines in the compile. So they are not ‘phantom’ at all, and they do indeed correspond with each other. I’m OK with that. I think what is shown in the editor should absolutely correspond to what is shown in compile. And it seems to. So I have no issue there.

Ah, so Single Return does not imply an empty line. I feel that this is not at all intuitive, and confusing, since a ‘return’ automatically creates an ‘empty line’, when typing. Good to know. And yes, I have already followed all of these steps, but I may be missing something, so I will try again.

Neither Scrivenings mode nor the Editor generally necessarily corresponds to the final Compiled document, Being able to change almost all aspects of formatting separately from the writing process is the entire point of the Compile command.

To test this, change your Compile settings to put a page break between sections and observe what happens to the Scrivenings view.


Gosh, I was so sure the thing in the compile settings was going to sort things out. I’m sorry that didn’t pan out. Now, I guess I am stumped. Maybe you should get over to L&L support and ask them to have a look – you can send them a little sample project that exhibits this behavior. I’m sure they can help.


P.S. Extra-curricular notes:

A single return does not automatically make an empty line. If you type some text, hit return once and then continue typing you get two paragraphs one right after the other with no empty line between them. To get an empty line, you need two consecutive returns! (Of course, paragraph formatting can create padding space before/after a paragraph, but such whitespace is not the same as an empty line in the relevant sense.)

Katherine has the right of it on this. Scrivenings view is not intended as a “compile preview” and you should not expect it to function that way. I think Scrivenings mode does not check in with your compile settings at all to determine how it should behave. Scrivenings mode is a facility meant to enhance your writing environment, not to assess your output formatting. Even the “page view” facility that scriptwriters use is not meant to be a faithful representation of their compiled output, but a rough and ready guide to pagination – something scriptwriters need because of certain standards that prevail in the industry.

The document text includes whatever whitespace you put at the end of the document. The Compile command will not eliminate any pre-existing text. Rather, it will add whatever Separator you specify after the end of that text. So if you put five paragraph returns in one document and three in the next, that’s exactly what you’ll see in the output. Followed by whatever the Compile command specifies.

A single return is a single return. Hit return, start typing on the next line. This is what you would use when the break is only for your own use and you don’t want the reader to see it.

An empty line is two returns, creating a blank line. A scene break, for instance.

A Custom separator is ‘#’ or ‘***’ or whatever you put in the box.


I’ve understood these concepts all along.

But in my layout assignment, I have ‘documents’, which are in my binder representative of scenes or beats within scenes (and nested into folders representing ‘chapters’), and they are assigned as ‘Section Text’, meaning the bare text as it exists in the document as it apears in Scrivenings without line breaks, page breaks, or anything extraneous.

What that means is that how they appear in Scrivenings does indeed faithfully represent what is manifested during the compile process. They are equivalent to ‘what you see is what you get’. So I do expect that concept to work, at least for the structure of these documents (all else is of course at the mercy of the compile settings and may not be WYSIWYG at all). Of course to make this actually faithful I had to change the separator settings, as some have suggested.

So while I understand the concept of compile not being WYSIWYG, I have leveraged this portion of it to be that. And that works. (I did have a brief love affair with iBooks Author, which has a one-button preview feature that is absolutely WYSIWYG, but it is not as sophisticated as Scrivener and won’t provide mobi files without importing an epub into KindleGen).

So as wonderful, useful, and sophisticated as the compile process might be, I think it also has two tragic flaws: One is that it is not WYSIWYG, which is ironic since Macintosh is based on that concept as its basic religion (and it’s a terrific concept to embrace and is extremely useful). The other is the level of inscrutability. The more something is made to cover more and more bases, the exponentially more inscrutable it becomes.

This is not to say Scrivener has taken the wrong path. Quite the contrary. But I expect it will not become ‘non-inscrutable’ until possibly Scrivener 5 at the current rate. But there is certainly an understandable mutual exclusivity between a compile
process this sophisticated and intuitiveness or WYSIWYG, so I will just have to make peace with that.

But, that said (and accepted), there is a way (or should be a way) to ameliorate this, which would be to have an instant preview feature. IOW, click one menu command or shortcut kestroke, and a representation of what it will look like after compiling appears (at least for whatever elements are currently selected in the binder), yet without the encumberance of waiting for the compile process to churn away and then having to then manually open the doc in a 3rd-party app like iBooks or Kindle Previewer to see what it actually will look like. The ‘Test’ button is a step in that direction.

That is a dream feature, but not an unrealistic request. Apple found a way to do this. If they can do it (iBooks Author), then Scrivener should be able to do it, and I think it would raise the level of Scrivener well above all competitors.

The good news here, for me, is that changing from ‘Empty Line’ to ‘Single Return’ has solved my issue, so I am deeply grateful to all of you for helping me along my way, even if some might have used this as an excuse to admonish me (Ahem!)

The only remaining issue that I see is this:

If I merge consecutive split docs from the binder, even if they had no extra empty line or secondary carriage return between them, Scrivener is not yet smart enough to remember that these documents did not have this extra empty line before they were split, and then places an empty line there. IOW, split a doc at a paragraph heading, then merge those two docs later, and there is magically a new blank line placed there that was not intended by the author.

It seems like that could be addressed.

Apple with its billions and army of coders vs Keith, one person … Scrivener on Mac and iOS and Scapple …



Am so glad to hear this actually worked out. Problem solved!


p.s. Not so much an excuse. Rather more like a mission! :wink:

Exactly correct. Scrivenings is a writing tool. The Compile functions, by design, affect only the output document they create. They have zero effect on the writing environment.


Not being WYSIWYG was an explicit design decision, and many people see it as a feature, not a flaw.

It is a useful concept for layout and publishing purposes. Scrivener does not pretend to replace any of the excellent layout and publishing tools that exist.