With typewriter scrolling on, if you insert a new line immediately before the last line of the document by hitting return, it causes the final line of the doc to disappear until something prompts a redraw of the screen such as typing, or scrolling the screen. It feels like the typewriter scrolling is getting in a pickle with the new line, and scrolling it over the last, or scrolling all the window up instead of scrolling in opposite directions either side of the newly inserted line. It’s not a bug with the underlying text, because it gets redrawn properly as soon as something else prompts it to update.
This only happens when you insert a line immediately before the last one; inserting a line anywhere else or adding to the end of the document doesn’t cause this. It doesn’t happen every time you do this, but it seems to get stuck doing it, and then something unsticks it (not sure what !) and then it gets stuck doing it again.
It’s purely cosmetic as far as bugs go, but it is a bit disconcerting that you go to insert a thought and it appears to overwrite content.
I’m using dark mode, if that makes any difference.
What version of Scrivener are you using, and does this happen on both your windows and mac platforms? Which version of mac & windows are you running? This will help with a diagnosis.
I can’t help with an answer, but I seem to remember seeing a (bug?) that was fixed that had to do with a specific os/scrivener combo.
I’ve only started seeing it on my Mac scrivener since upgrading my Mac last month from something pre-BigSur and a similar vintage copy of Scrivener (~2019?).
macOS 13 to a lesser extent, and 14 have been a real mess when it comes to text editor performance and cosmetic reliability—spell check drawing its markers incorrectly or not pulling up the menu options when it should, has also been a huge pain. These are not problems exclusive to Scrivener (I have even seen text redraw errors in TextExit, which is so basic most programmers could make most of it in an hour or so). For the most part we just have to hope Apple fixes them at some point. There are lots of symptoms of this problem, the one you found seems to be one of them. I have seen it happen in the middle of the screen as well, with no typewriter scrolling.
In the meanwhile, we have discovered that turning on the current line highlight setting in Appearance (for all of the text editors you use frequently: Main Editor, Quick Reference and Composition) can in our testing cause the problem to vanish. Perhaps this feature involves redraw the text more aggressively to insert such a graphical element into it, and this negates the problems that the more economical and resource-friendly approaches exhibit.
If you don’t like the look of it, go into Appearance: General and switch off the option to draw a border around the line highlight, then for each editing mode you use, visit its Color tab, click on the picker for the current line highlight, and set its opacity to 0%. Even invisible, the extra drawing this setting entails seems to improve things.
We’ll be taking a look at it to see if there is anything we can do to fix it. Maybe slowing everyone down a small bit by having this setting always on, but invisible if the settings are off, is a rough and dirty way to fix it.
When I select some text, say a few sentences or a paragraph, and then press the delete key, I run into a strange visual glitch. A large chunk of the text will remain on the page, still selected, and looking like it hasn’t been deleted. When I hit any key after that, the glitch disappears and all of the text I tried to delete at the outset is gone.
Not sure what setting could cause this or if it’s just a strange bug, but I was hoping someone could help me out.
Just chiming in to say that I have the same bug as 1000Vultures. Text remains in the editor after deletion until pressing other keys in the same editor window triggers a redraw. Very distracting, especially when working across split editor setups. The bug doesn’t happen in any other macOS apps.
Are you using Page View in either split? That can increase the chances of seeing it, probably because there is a lot more by way of drawing complexity involved.
This isn’t a straightforward bug, because in reality Scrivener is not even remotely operating at a level where it is drawing text. That’s up to the Mac text engine itself. Now we put stuff “on top of it”, like split views, fixed width, or page view, line numbering, styles, etc., and somewhere in all of that fancy stuff it increases the likelihood of causing the text engine to glitch. But you can see why truly fixing a problem like that, what is technically a bug in the Mac itself, can be difficult. We don’t even know what is wrong, and so fixing it can be a bit like waving a wand around and hoping for the best.
We’ve made adjustments in 3.4 that should clean up the majority of cases where this happens—at least all of the test data we got was clean in it. But I doubt it’s possible to fix all cases, because as I noted above, I have observed this happening in vanilla TextEdit as well, now and then (not as often, true, but it’s there), and if that triggers the bug, then there’s no hope in fixing all cases because TextEdit is just about the simplest expression of the text engine that is possible. Even if we removed all of Scrivener there is still a chance it would happen.
Thanks for the reply. I’m in the normal editor view, not using page view. Most of the text I am working with is in Japanese (when you say “fixed width”, do you mean fixed width characters?).
It’s not a workflow-breaking issue; this bug has been around for a while now, and I’ve learned to work around it. Just working on a very large project at the moment and seeing it multiple times an hour when and pasting chunks of text across split panes, so I came by the forums to see if anyone else had mentioned it.
By fixed width, I mean the default editor setting that makes it so the lines wrap at a readable width, if you extend the editor pane wider than that point, and also by default it centre-aligns the block of text. A text editor that doesn’t do that (like TextEdit) would create lines as wide as the editor, potentially all the way across the screen.
You could try turning that off, in the Appearance: Main Editor: Options tab and see if it improves. Especially if you use splits, and maybe never even see this mode do what it is intended to do, it might be needless complexity.
Are you using vertical writing mode, with Japanese? Obviously you probably wouldn’t want to turn that off, if you are, but I bet that also increases drawing complexity.
…and seeing it multiple times an hour when and pasting chunks of text across split panes, so I came by the forums to see if anyone else had mentioned it.
Yeah, and come to think of it, pasting is when I most often saw TextEdit glitch as well.