Edit Scrivenings issue

  1. Create a new Short Story Manuscript, then go to First Scene.
  2. In the editor, press Tab, then type enough text so that it will wrap around.
  3. Press Enter enough times to make the scroll bar on the right to show up.
  4. Highlight the First Page Header folder and First Scene and then Edit Scrivenings.
  5. Go down to the First Scene text. Put the cursor somewhere in the first line (the one with the tab) and press Delete. The cursor will jump 6 spaces backward though it will delete the character the cursor was at before. Typing something after this point will put it at the original spot even though the cursor is back 6 spaces.

Note: In options, I’ve removed the automatic tab in Text Editing


Thanks for the easy-to-follow-and-reproduce bug report - reports like this make my job a lot easier. I was able to reproduce this bug instantly and spent the morning trying to find the cause - I eventually did, but it doesn’t help much, unfortunately. This is actually a Leopard text-system bug rather than a Scrivener bug. It took me a while to discover this because if you copy and paste the text into TextEdit or Bean, you don’t see it. So I assumed it was my code and spent a lot of time tearing out portions to see what it could be. When that failed, I set up a vanilla NSTextView (that is the name of the standard underlying text view on OS X) and pasted the text into that - and saw the bug there. That was tested in a plain OS X text view with no Scrivener code, so I knew the bug was in the OS. Next I checked to see why the bug doesn’t happen in TextEdit or Bean, which was fairly straightforward. In Leopard, a new feature was introduced where text views could have “non-contiguous” layout. All this means is that in order to speed up text layout, if this option is used, the selected or visible area of text will be laid out first so that you can start working on it; if this option isn’t used, text is laid out from top to bottom, meaning that you have to wait for everything above the selection or visible area to get laid out before you can work on it. Scrivener’s main text view doesn’t use this option, simply because a lot of the custom drawing - such as alternating background colours for different sections of text - needs to know about the whole text in order to render properly. TextEdit and Bean do use this option. Sure enough, I found that turning this option on and off made the bug go away and appear again. I’m not sure the NDA means I shouldn’t say this, but Apple seem to have fixed this for Snow Leopard as this bug doesn’t show up on my developer preview. I will look into whether it is possible to use non-contiguous layout in the main text area again, although I know that it didn’t work too well last time I looked into it.

Thanks and all the best,