Ctrl+Enter line breaks disappear after closing/reopening project

I’m having an issue with Ctrl+Enter in Scrivener. When I’m editing, I can press Ctrl+Enter to insert a line break and it works fine. But after I close Scrivener and reopen the project, all those line breaks are gone — the lines that were separated now combine together.

I need Ctrl+Enter to create a new line within a list item, not to start a new list item (which is what pressing Enter alone does). Without being able to preserve these line breaks, my lists get messed up.

Has anyone else experienced this? Is there a setting I’m missing, or is this a bug?

Thanks for any help.

Somewhere in the far past I had that problem and I called for help from Google on this and I discovered that the keys OPTION-COMMAND-ENTER works to enter a line break. Muscle memory ever since has show it works all the time. I might be mis-remembering, but I recall CTRL-ENTER used to work, but now the OPTION-COMMAND-ENTER works. I think something changed in macOS along the way.

Ah … now remember this from June 2025 discussed here (found from search):

1 Like

It’s worth checking whether or not that shortcut is actually inserting a line break:

  1. Check the shortcut you are actually using in Insert ▸ Break ▸ Line Break. The default for Scrivener is ⌥⌘⏎, as noted above. It may have been ⌃⏎ for a while in the past, but that shortcut is no good to use any longer. A recent macOS update took it over as a default shortcut to pull up the contextual menu with the keyboard (same as right-clicking would do).

    Of course it is possible to change shortcuts around, which is why it is worth checking.

  2. Next, toggle the View ▸ Text Editing ▸ Show Invisibles menu toggle, and examine what is actually being inserted after the line, when using this shortcut. What you want to see (on the first line):

4 Likes

Thank you! I tried Option+Command+Enter — it inserts the same line break, but it isn’t preserved either T T

I do not know know what you mean by “isn’t preserved T T”. Could you please post screen shots and/or movie, showing the invisible characters, what you see as an issue. will help us immensely.

I tried Option+Command+Enter. The line break mark can be inserted (as with Control+Enter), but my problem is that it isn’t preserved after reopening the file.

And occasionally I found that if I set the character style to ‘code span’, the line breaks within that style chunk are preserved.

I attached a screenshot. version 3.5.1(17446)

I posted a screenshot above

Questions no one has asked:

  • Which version of MacOS?
  • Which version of Scrivener?

:slight_smile:
Mark

1 Like

I’ve never seen anything like that before (I used to use these a lot, back when I had Scrivener convert lists to Markdown). I see you are running 3.5.1, but yes, the macOS version would be good to know as well. Perhaps if it is an older version, there is a bug that only impacts it from newer versions of Scrivener. These older systems often don’t get nearly as much testing, either from us or the community at large.

Here are some diagnostic style checks I would run to try and narrow down the problem further:

  1. Copy and paste this “compressed” text into TextEdit. Does it show up normally there?

    • If so, if you ⌘F and then search for line breaks (insert with ⌥Return)
  2. Try using a different font, both:

    • by selecting what you have and changing it, then reloading.
    • Secondly, in a document with a different font to start with (I would change the test project’s default formatting in Project ▸ Project Settings...).
  3. And of course, try a preferences reset, and then reproducing with vanilla settings (which will also try a different font, but I wanted to see that difference specifically).

1 Like

I’m on an older macOS version (Ventura 13.7.8), using my old laptop for writing.

1. I tried copying the compressed text into TextEdit, and no marks showed up. But weirdly, I also tried copying the original text (with line break marks) into TextEdit, and still nothing appeared.

2. The font change worked! I switched to Arial and the line breaks stayed.

So it seems like no Chinese fonts (like Pingfang SC) can keep line breaks on my Mac. But on Windows Scrivener 3.1.6, Chinese fonts work just fine.

The weirdest part is this:

If I save a file on Windows and open it on my Mac, the old line breaks stay. But when I continue typing and add new line breaks (without changing the font), then close and reopen the file — my new line breaks disappear, while the old ones remain.

Also, when I paste the text into TextEdit, it looks like line breaks were never actually entered on my Mac in the first place.

I also tried inserting line breaks directly in TextEdit, then copying that text into Scrivener. Still no line breaks showing up in Scrivener either.

So maybe something on macOS Ventura just isn’t registering line breaks correctly when using Chinese fonts? Really appreciate you helping me troubleshoot this!

1 Like

Okay, now that I am testing with a Chinese font (with PingFang SC as well), I see the problem system-wide. It looks like a Mac issue in general (at least with native software). You don’t need to use Scrivener at all to see it, you can save an RTF file in TextEdit, close it, and then open it, and they will be gone on all operating systems and text editors. That’s because the fault is in how it writes RTF.

So in taking a look at how the text engine writes the raw RTF to the disk (the below is TextEdit, but Scrivener is basically the same), we see the following (in excerpt):

\f0\fs24 \cf0 Line one
Line two
Line three\
\

\f1 Line one\uc0\u8232 Line two\u8232 Line three}

The first sample is in PingFang SC, and the second example is in a Latin-oriented fixed width font. You can clearly see the difference in output, where the Unicode character for a line break is being properly inserted after lines one and two, but in the first sample… nothing. The backslash at the end of a line is RTF shorthand for a newline, a paragraph break. As with HTML and many other markup languages, raw newlines in the file do not translate to the output. Without any kind of break in between these lines, they get glued together when loaded in an RTF reader.

Ultimately, because the Mac RTF writer is deleting any meaningful break characters from the output, there is nothing for Scrivener to even try to work with when reloading the file.

Best we can probably do is file it to Apple, and I would encourage likewise. Incidentally, this was all tested on macOS 26.5, so don’t bother considering upgrading from what you’re using, in the hopes it will be fixed.

Otherwise, the best hope I can think of is to keep trying different fonts, maybe something will work. I had slightly better luck with Noto Sans CJK SC, but not enough to call it reliable, which is why I speculate there might be something out there that is reliable.