Giant insertion point in Mac Sonoma update 3.3.2

In novel manuscript format, double-spaced text, the double spacing causes the new insertion point to lengthen and span two lines of text. This is distracting, but especially so as it then randomly shrinks in length to cover just one line as I scroll along a line of text. Is there a workaround for this?


Yes, the giant cursor is what Apple feels it should look like, as you can see below, from TextEdit (why, who knows, I don’t know anyone that likes how this looks):

As you can see, there is an attempt being made to make that a little more reasonable in Scrivener, but it is very difficult to do, and there are indeed some issues with how it can lose its shorter size and look like TextEdit for a bit. Seems to happen most often when crossing between lines of different line-heights—as depicted in the sample text.

We’ll have to see if we can get it refined further. In the meanwhile unless you have a strong visual preference for this look, you can always save double-spacing for the compiler and use a more moderate line-height while writing.

Thanks for your Reply.

Yes, it’s a strange decision. I find it changes size from one letter to the next within the same word while line spacing is set to 2.0 It can change size six or seven times when scrolling along one line. Very distracting.

To make it less bothersome I’ve softened the colour of the bar which was a suggestion I saw elsewhere to reduce the prominence of the flashing. It’s slightly less annoying, but not sure I’ll exactly get used to it! Fingers crossed they’ll eventually see sense…

In fact, Apple’s TextKit has always had a stupidly large text cursor. This isn’t new to Sonoma - TextEdit always used a giant cursor that spans the spacing between text as well as the text itself. This is something I complained to Apple about fifteen years ago.

What’s changed in Sonoma is that Apple has introduced a whole new way the cursor is created. The strange decision I that, even after completely changing the cursor code, Apple has kept it enormous in TextKit rather than improving the size. This is completely baffling to me.

Anyway, this all means that, to reduce the size of the cursor, I have to override Apple’s code. I have always had to do this, but now I have to do it in a different way. It sounds as though the override isn’t always working, though.

Could you please post a sample project or RTF file export that shows the issue, or a video? I’m not seeing the same problem on my machines.

When you say that it changes size as you scroll, I assume you mean moving the arrow keys? For me the cursor stays the same (smaller) size and I’m not seeing it leap about.


1 Like

Hi Keith

Thanks for your reply. Here are a couple of screegrabs of the cursor switching randomly between letters within a word. You’re right, I mean this happens when I move the insertion point along the line with the arrow keys. I would take a video if I had tme but for now here are a couple of screenshots. It shows this behaviour (enlarging and shrinking back down) throughout the whole project where lines are set to 2.0

I hope these help, but if you need something more please shout and I’ll see if I can send you something more substantial.

Cheers, Andy


Thanks - could you please attach a sample project showing the issue? I’m not seeing this, so I suspect it’s being triggered by the combination of fonts and formatting you are using. Or, instead of a sample project, just create some sample text in your project that reproduces the issue, and then use File > Export to export that text to RTF, and attach the RTF file. That way I can import it into my project and hopefully reproduce it.

All the best,

Andy, if you try dropping your editor magnification to 100%, does the problem vanish for you? I could not reproduce this either, until I started messing with that setting.

Hey Amber, yes, that’s what it is! If I set magnification at 100% it goes away. It appears as soon as I increase the magnification over that by any amount. My native monitor resolution is 3840x2160, so at 100% the text far too small to read - I have to increase magnification for the editor window to be practical.

Keith - I assume this answers the question of how to replicate the issue, but if you still need an RTF please let me know.

all the best

Yep, I can reproduce it now, thanks. Please try this build and let me know if it fixes the issue:


All the best,

The build I posted above (now deleted) had some problems in page layout mode and elsewhere. Please try this build instead:

[Deleted - preparing for release.]

All the best,

Please update to Scrivener 3.3.3, which was just released on our site and has been submitted to the App Store.

All the best,


Seems to fix the “ruler bug” and the cursor height. :+1: (Although a bit too much if you ask me, sitting quite low now compared to a “pipe” character.)

Great! As for the position and size, it’s exactly the same size and position as it was in previous versions of Scrivener - its position on the line and such will depend on the font and line spacing settings used and thus the line fragment rectangles returned by Apple’s code and may not necessarily match the pipe.

All the best,

To illustrate what I mean (upper image: double line height after the bugfix, lower image: my usual 1.25 x line height):

Try it in 3.2.1 and compare.

I too just updated to Sonoma and have a huge unwieldy cursor out of the blue. This is not the same size as before the update and it does not change with magnification or the 3.3.3 update. I have looked at all accessibility options in System and nothing seems to change it and this is ONLY in Scrivener not Word, Pages, or other word processing. I have a screenshot of just how large this is.

@KB You’re right, it’s the same in 3.3.1. Weird.

Thanks Keith, this fixes the cursor issue for me.

@AGWA: Great, glad it’s working now!

@November_Sierra: It comes down to how it’s fixed. All I can do is take the original size of Apple’s cursor and try to fix it up so that it’s not as huge - there’s no way of replacing it completely with my own. And, strange as it may seem, there’s no good way of getting the exact rectangle of the text on the line; instead, the line rectangles always include the line spacing. So to fix it up, I essentially have to grab the original rectangle and remove the amount of line spacing in the paragraph from it. It’s not pretty! For the most part this works very well, though. I’m not seeing the misalignment you’re seeing, but as I say, I suspect it’s down to the specific font and line spacing. As long as it’s working as well as in previous versions, I’m happy. :slight_smile:

1 Like

Thanks for your in-depth reply! I wrongly assumed that this was a result of the bug fix (never really used double line spacing before, because it makes so little sense on a screen). It’s so bizarre that Apple appears to be unable or unwilling to fix this mess, since they know how to get it right (e.g. in Pages, different text engine).