The current line I'm editing defaults to the screen centre

The attached project exhibits this behaviour.

Typewriter scrolling, which is off, is always middle of editor, regardless of preferences in these cases.

Scrivener: 3.1.5
macOS: 10.15.7

Just to make sure we’re on the same page, this test project you sent actually has typewriter scrolling turned on. So are you saying then, that what happens is this setting spontaneously turns on, so you can see a checkbox beside it in the View ▸ Text Editing ▸ submenu, at 110%?

That’s a new one to me, not even like the original problem (which wasn’t really typewriter scrolling, but an overapplication of the native behaviour that scrolls offscreen cursor activity and typing into the middle of the view in a beneficial way).

Thanks for the sample project - I was able to reproduce the problem (typewriter scrolling was jerky and turning off typewriter scrolling resulted in the phantom scroll issue). I’ve changed the workaround - hopefully the new one will be more reliable.

I believe the underlying bug is caused by the expected TextKit behaviour of scrolling the edited line to the centre when you type and the edited line is off screen. When the size of the text view changes because of an edit, Apple’s code (I believe) checks to see if the edited line is outside the visible area and if so, jumps it to the centre. I can only surmise that Apple’s code does not take scrolling into account, and that at certain text scales and in certain configurations, this code can make the line jump to the centre even when it’s already visible.

My new fix is to remember the scroll position before a size change, check to see if the edited line in visible on screen, check that the visible area is still valid after the resize, and restore the scroll position if so. A rather horrible and hacky workaround, but it seems to work. This is in 3.2.1, which will be released later today, so please let me know if it addresses the issue for you.

All the best,

That makes sense. It’s definitely something that seems to only occur on larger, though not particularly large, documents.


Just tested this and it’s working so far.

You have no idea how much frustration this has caused over the years, so I’m delighted it’s now behaving as I would expect. I’m still hesitant because I’m so used to waiting for the moment for it to… suddenly jump.

Yeah, I’m not 100% confident of the fix but it should work in theory since it’s resetting it immediately after Apple’s code moves it as long as it would have been on screen anyway. I thought it was fixed before, but the new fix is done in the very method where Apple scrolls the text, whereas the old one was done in only one of the methods that could invoke it (which I didn’t realise - I thought that was the only place it could happen until I saw your project).

Fingers crossed, but I’m glad it’s good so far!

All the best,

I encounter this occasionally (every couple years or so), and my fix is to shut down Scriv, copy all .plist and styles from Scriv’s Library folder to my desktop, delete the library folder, restart Scriv so it recreates its Library folder, shut down Scriv, copy styles and .plists over there, restart Scriv.
I guess it’s too much of a hassle if you frequently change zoom and trigger the problem, but if it’s just something that happens randomly, it’s an easy fix.