Comment behavior problems [when attempting to overlap them]

I’m having issues with overlapping comments. When I select text that includes a smaller selection that already has a comment attached to it, the newer comment overwrites and erases the first comment. But when I create the comment on the larger selection first, and then select a single word within, I can add a second comment fine. However, doing that cuts the first comment into two selections, so when I delete the larger comment, only the first part of the selection is un-tagged, up to the point where the single word is still highlighted. The text coding after the single world remains, with no comment attached to it.

Is there any solution to this? How are nested comments supposed to work?


Yes, it sounds to me as though you are attempting to do something that comments cannot do (overlap each other). Think of them more like formatting, or a link. If you add a link to some text that already contains a smaller link within it, only one will win. If you add a link to half of an existing link, the first part will go to the original location while the second part will go to the new location.

This is in part a text engine limitation (in fact we are using hyperlinks to achieve this ability, it’s special kind of link that directs the target to a box in the sidebar), but also an export limitation as well, as the conversion processes do not support overlapping links either. Hence, if you try to get around this by using an inline annotation with a comment within the annotation, you’ll find the command disabled.

My suggestion would be to find another approach, such as sequencing comments to a series of words, and using colours to help signify their purposes. For example if five different things need to be said about a paragraph, shorter highlights can be used, and they can all together use the same colour to suggest they are meant to be read together.

That part in particular should be improved. I’ll make sure that is on the list of things to fix. What should happen here is that it refuses to let you put a note in the middle of an existing one, and instead triggers what would be a mouse click otherwise, thus making this a way of getting into the inspector and editing the comment text from the keyboard alone.

1 Like

By the way, the behavior is 100% similar when mixing inline footnotes (or anchored footnotes – or both – this much I can’t remember) and comments.

To make matters worse for someone who doesn’t know, it looks like it is supposed to work.
Things only go south at the very last moment.
I can easily picture someone trying over and over repeatedly.

Yes, these are all based on the same technology and subject to the same technical limitations, such that even combinations that would make good sense to provide the ability to do (a comment on a footnote) aren’t allowed (or in the case of this Windows bug, can cause malfunctions or weird results).

1 Like

Thanks for the reply. It’s a lot easier to accept the limitation knowing the technical aspects of it, so thanks for spelling that out.


1 Like