Allow deltadecorations not to merge if next to each other

[colmanhumphrey]

In theory this could be a bug, but perhaps a feature request makes more sense.

Current Situation

Building off the "Line and Inline decorations" example here, if you add this to the CSS file:

.myLineBackground {
    background-color: aquamarine;
    border-radius: 0.5rem;
    box-shadow: 0 0 0 1px black;
}

And change the decorations to use this:

var decorations = editor.deltaDecorations([], [
	{ range: new monaco.Range(7,1,7,24), options: { className: 'myLineBackground' }},
]);

You get:

Not too bad (although I wish the editor didn't chop off the left edge).

But now if you add two decorations next to one another, e.g.:

var decorations = editor.deltaDecorations([], [
	{ range: new monaco.Range(7,1,7,5), options: { className: 'myLineBackground' }},
       { range: new monaco.Range(7,5,7,9), options: { className: 'myLineBackground' }},
]);

You get:

That is, the two decorations merged, so the "rounded middle" that could (should?) occur doesn't happen - that is, a rounding around Pers and then around on.p

Why is this not a bug?

Because in normal editing, decorations can move around. So I figured that merging might make sense in that context. So for this to work, it probably should be a setting within the decorations options? It may already be possible, but I couldn't get it to work.

Thanks!

[alexdima]

This was more of a very early design decision. When rendering squiggles, multiple squiggles would overlap and cause the underlines to look odd / overlapped. So we decided to simply merge adjacent decorations with the same class name just before rendering.

As a workaround, you can try using distinct class names.

[colmanhumphrey]

This was more of a very early design decision. When rendering squiggles, multiple squiggles would overlap and cause the underlines to look odd / overlapped. So we decided to simply merge adjacent decorations with the same class name just before rendering.

As a workaround, you can try using distinct class names.

I see where you're coming from, and I think probably the default behaviour of the join does make sense.

Indeed distinct class names is what I ended up using. Slightly less than ideal: because it's all programmatically generated in my code, I had to use a switching boolean to generate one of two class names (so that adjacent blocks would get different classes but without having to use a single classname per decoration). And with many different types of decoration, indeed that's two per actual style. Not the end of the world of course!