Sb2 : UI : minor : Joining annotations, visual inconsistency

This may very well be a peculiarity of the way annotations are displayed in the editor. If you have two annotations separated by one or more carriage returns, and wish to join them, you can place the cursor at the beginning of the second one, and backspace until the border around them both becomes one (assuming they are the same colour, of course). At this point, visually they would appear to be joined. However, if you were to insert a carriage return at this point (say, to maintain prior paragraph distinction), they would become split again.

This contradiction behaviour exhibited when entering an annotation, where as you are typing, pressing the key simply inserts white space into the current annotation. And indeed, the way to do so with recently joined annotations is to use the arrow keys right and left one character, and then press the enter key.

This same sort of dance is required if you wish to insert carriage returns into the beginning of an annotation. Which probably means it is because the cursor is actually technically outside of the annotation the whole time, even though it appears to be inside after joining (yes, that makes no sense, I do realise). So, I am guessing there is no easy fix.

There is another example of odd behavior, if you bring two differently coloured annotations together, with the intent of removing white space between them for export reasons, the above arrow trick has weird results. Even if you move the arrow into the second annotation first, leading you to believe that the cursor is definitely inside the second annotation, then left back to the carriage return point – the carriage returns will be suffixed to the first annotation, which does not solve the white space problem since there is still a rogue carriage return at the end of the first annotation.

To correctly carry out this sort of operation, you have to press the key to remove the first character of the second annotation, press to enter the desired number of carriage returns, and then re-enter the deleted character.

This same trick is required if you wish to simply insert carriage returns into the beginning of a single annotation (to set it between exported text, for example).

Apologies if this post is a mess. It was created over time.

Hi Amber,

All of this is normal behaviour, and actually beyond my control. Annotations and footnotes are no more than text attributes whilst they are in Scrivener, and they thus act like all other text attributes. The cursor point in a Cocoa text view has “typing attributes” which are taken from the current selection point’s attributes, which is why you are seeing this behaviour.

Try everything you have described using the bold attribute instead of the annotation attribute, and you will see that the behaviour is identical - because it is built into the Cocoa text system.


I had a feeling that was the case. Often with things like bold it is less important if some white space characters in between lines are technically bold. I think the reason why it stood out to me is that where the white space is located is more important, as it can make your export look funky if you have things set up the wrong way.

Fortunately, you do have a pretty good set of tools for adding footnotes and annotations from within Scrivener, and I think that once I start generating writings from within it, these issues will be less annoying. This is more of a hassle when taking a file from Ulysses or something and trying to turn it into a Scrivener file.

I shall just have to deal – or adjust my conversion script to do the dirty work for me.