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.
Alan
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).
Thanks!
Keith
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
Draft
-New Folder
–Untitled
–Untitled
-New Folder
–Untitled
–Untitled
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.
A
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.
Hi,
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.
Thanks!
All the best,
Keith
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).
A
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:
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]
[b]Spacing...[/b] from drop-down menuNote 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. 
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,
Keith