Having "bold" mean some semantics, e.g., important.

Then they merge. Alice does not consider it important, Bob does -> render both. E.g., Bob's "importance" expressed as bold, Alices "not important" as grayed text.

E.g.,

"Ny is a great city."

Alice removes "great".

Bob wonts to replace it with "gorgeous", by removing "reat" and adding "orgeous".

Having merged:

"Ny is a orgeous city."

Begs for semantic intent preservation, such as "reword great to gorgeous".

Uhh, I'd imagine "remove" would refer to "bold" annotation.

Otherwise, there can be another "bold" with t < 20, that would be accidentally removed.

Syntactic intent is not preserved.

That would be better for user to decide.

I think a good default is to express semantics explicitly.

I.e., for Bob to not automatically state his utterance as important just because it's atop of Alice's, that she considers important.

If Bob tries to reword - ok. If Bob want to add - no.

Given Bold, Italic, Colored are syntactic representation of semantics that we do capture - they can overlap.

Moreover, in Bob's user-defined mapping from semantics to syntax, Bob's "important" can be bold, while Alice's "important" can be italic.

Again, let them capture semantics.

Say, "Alice considers "The fox jumped"" as important. Alice changes mind, only "The" is important. Bob considers "jumped" as important.

Result: Alice considers "The" important. Bob considers "jumped" important.

Color is meant to convey some semantics. Like "accent", or "important". These semantics can coexist, just like italic and bold.

So a solution may be to: 1. Let users express semantics of their annotations 2. Give user-customizable defaults of how they are to be rendered.

Ensuring, that semantics's render is composable. I.e., it conveys originally asigned semantics.

Good remark of syntactic vs semantic intent preservation.

Semantics are in the head of a person, that conveys them as syntactic ops. I.e., semantics get specified down to ops.

Merging syntactically may not always preserve semantics. I.e., one wants to "make defs easier to read by converting them to CamelCase", another wants the same but via snake-case. Having merged them syntactically, we get Camel-Snake-Case-Hybrid, which does not preserve any semantic intent. The semantics intent here are not conflict-free in the first case, though.

Make defs readable | | as CamelCase as Snake Case | | modify to CC modify to SC They diverged at this point, even before getting to syntactic changes.

The best solution would be to solve original problem in a different way - let defs be user-specific. But that's blue sky thinking. Although done in Unison, we do have syntactic systems around.

So staying in a syntactic land, the best we could do is to capture the original intent: "Make defs readable".

Then we need a smart agent, human or an AI, specify it further.

I.e., let's capture user's intent as ops, not their result.