Minor display bug in Scrivenings Mode

I am finding that the divider keeps overlapping the last line of a document in Scrivenings mode. I can make it happen reliably when the last line is a bulletted list, but I think it happens other times.

I attach the document, so that the bug can be (hopefully) replicated.

test project.scriv.zip (80.5 KB)

Great, thanks for this - I’ve seen this myself but have never been able to get it to happen consistently. I’ll download and look at this as soon as I get chance, but in the meantime can you describe exactly how to reproduce it from scratch (was it just adding bullets in scrivenings mode, or did it appear like this on entering E.S. mode)? Also, do the lines go with the text when you open it in regular mode (I’ve seen this happen once or twice - again, on the list).

This bug is more subtle than I thought.

I opened the posted database, and the display was correct. However, if I typed a carriage return (starting a 3d bulletted line), then hit backspace (getting rid of the bullet), the display bug reasserted itself and continued as I added more lines.

So I tried to replicate from scratch—I think you can follow this recipe

New Blank Project, New Folder, New Document, New Document
Click on “New Folder” in Binder.
And again, New Folder, New Document, New Document
Click on top document in Binder (outside of folder), command-delete.
Now your outline looks like

-New Folder
-New Folder

Click on Draft and edit in Scrivenings mode. Put insertion point into first document.

Type some words, new line. Type some words, new line.
Click on bullet pop-up menu (next to line spacing pop-up menu), and choose a bullet style.

And Bob’s your uncle.


I’ve had the same problem but only when grouping multiple screenplay documents. While the bug seems to happen randomly, I’ve noticed that it most often occurs when moving in and out of fullscreen mode.

Hope that helps.


I’m looking into this at the moment but I can’t get it to happen at all - even following the instructions above to the letter. I have seen it myself a couple of times, so I know the bug is lurking somewhere, but I’m having problems finding a reproducible case at the moment, which makes it hard to find and fix. If anyone is seeing this and can post more instructions that trigger this bug every time, that would be really helpful.


All the best,

I followed my recipe, and it replicated the bug perfectly. I’ll do a safe boot sometime and see if there is some interaction with some piece of software on my computer (but I can’t think what it would be).


It won’t have anything to do with anything else on the system - but I followed your recipe and everything worked fine. Odd…

This reproduces for me, using the described setup. I tried with my own preferences first, and then default preferences with identical results.

I also noticed, while doing this, that playing with the paragraph spacing in the Formatting pane will adjust the divider line positions in an existing session. Try this:

  1. Default preferences
  2. New blank project
  3. Create four untitled documents
  4. Group them into two folders (same as above layout from alanterra)
  5. Select draft; cmd-1
  6. Turn ruler on
  7. Now just go down the items adding a single line of text to each

On the last file, you should note another bug. The last document will acquire the divider line format settings which have no indent, and a bunch of tab stops instead of the default ruler with first-line indent and one tab stop.

[size=80]Incorrect indenting on final file[/size]

  1. Open up Preferences:Formatting again
  2. Select [b]Spacing...[/b] from drop-down menu
  3. Change Paragraph spacing before to 0.0pt and hit return

Note that all divider lines in the editor will jump up and overlap their rows immediately, even before OK is clicked.

[size=80]Divider overlap after changing paragraph spacing[/size]

Given that it might be likely that the list code is adjusting line-spacing, this might be a clue as to what is causing the problem.

A-ha. I was testing this on the first release of 2.0 and also on my current build. If I test using build 6218, I can see the bug too. So it seems that this is something I broke and then fixed again. :slight_smile: I did make some changes to scrivenings, and a few days ago I fixed a few more scrivening-divider-related bugs, so that seems to have done the trick.

The thing with formatting changing in blank lines that Ioa mentions is a different thing altogether though. That’s never going to be perfect simply because dividers use different formatting to the text (because otherwise, if you have double-spaced text, dividers would take up too much room), so the Cocoa text system always wants to use the divider formatting when you click into a blank document immediately following a divider. Scrivener tries to intercept this where possible, and I’ve just made some more improvements there, but I doubt that will ever be 100% perfect for blank documents.

Like I say, though, that’s a separate issue to the one Alan reported.

Thanks and all the best,