Picking up where @ariehen left off, here is a page showing various possibilities for brackets which come in pairs, aka having both an opening and closing bracket as you indicated you wanted.
http://xahlee.info/comp/unicode_matching_brackets.html
or
Where the latter shows a multitude of various ways to gather such lists. In short, I think there should exist some pair of brackets which shouldn’t have any meaning within Obsidian besides the visual meaning you’ll give them. Some of the alternatives which I kind of like at a first glance:
« » # { LEFT-POINTING, RIGHT-POINTING } DOUBLE ANGLE QUOTATION MARK
⸨ ⸩ # { LEFT, RIGHT } DOUBLE PARENTHESIS
⨭ ⨮ # PLUS SIGN IN { LEFT, RIGHT } HALF CIRCLE
⨴ ⨵ # MULTIPLICATION SIGN IN { LEFT, RIGHT } HALF CIRCLE
⋉ ⋊ # { LEFT, RIGHT } NORMAL FACTOR SEMIDIRECT PRODUCT
⌈ ⌉ # { LEFT, RIGHT } CEILING
⌊ ⌋ # { LEFT, RIGHT } FLOOR
--- some wider variants below. Look nice, but they're wide ---
【 】 # { LEFT, RIGHT } BLACK LENTICULAR BRACKET
〖 〗 # { LEFT, RIGHT } WHITE LENTICULAR BRACKET
〔 〕 # { LEFT, RIGHT } TORTOISE SHELL BRACKET
〘 〙 # { LEFT, RIGHT } WHITE TORTOISE SHELL BRACKET
﹝ ﹞ # SMALL { LEFT, RIGHT } TORTOISE SHELL BRACKET
Of course visual preference depends on the eye of the beholder. The main point is that various alternatives for brackets do exist. And to use these I would either use a plugin like the suggested Wrap with shortcuts, or possibly just having Templater templates for the wanted left or right combination, assigned to hotkeys so that you can insert them at will wherever you want them.
Showing part of your text using some of the math characters:
... of my reading ⨭in single brackets⨮,
and ⨴passages with damage⨵ (or,
if ⋉the damage is too extensive⋊ to guess ...
And same passage as ordinary text: … of my reading ⨭in single brackets⨮, and ⨴passages with damage⨵ (or, if ⋉the damage is too extensive⋊ to guess …
Side note related to square brackets (and plain brackets)
Using Dataview you can define inline fields using syntax like: [fieldName:: field value] or (anotherField:: anotherValue), where the first variant will show the field name, and the second will not show the field name. You might want to consider changing your notation for unsure/damaged parts to use inline fields, so that your text could look like:
... of my reading [unsure:: in single brackets],
and [damage:: passages with damage (or,
if (to_damaged:: the damage is too extensive) to guess ...
The advantage of such a scheme would be that you could then query and get the precise parts which you have annotated using this method.
Another advantage of using field definitions is that they would allow you to style them using CSS, to make them standout when you review your documents.
Another way to put this: Square and plain brackets can hold a meaning within Obsidian as field definitions, which would allow for them to be queried or styled later on. The plain angular brackets (or less/larger than signs), are used for HTML markup, and not so readily available, as you’ve already understood.
Similar result could however be found in more general search based methods (at a slightly higher cost) for specific characters, like those above. But then you’ll not be able to style them without using some plugin or similar.
Or maybe even a combination?
After looking through the examples I’ve given, I kind of like the idea of using fields both for the query options, but also for the styling option it gives. At the same time the distinct character could be both intrusive and non-intrusive at the same time. I reckon you’ll want these sub-texts to stand out somewhat in your document.
So I tried another variant using both of these:
CSS to style this variant
To get it to look this I added a CSS snippet, with the following content:
/* Remove the field definition, to avoid copy */
.inline-field-key[data-dv-key="⨭"],
.inline-field-key[data-dv-key="⨴"],
.inline-field-key[data-dv-key="⋉"] {
display: none;
}
/* Neutral backgrund color */
.inline-field-key[data-dv-key="⨭"] + .inline-field-value,
.inline-field-key[data-dv-key="⨴"] + .inline-field-value,
.inline-field-key[data-dv-key="⋉"] + .inline-field-value {
background-color: inherit;
}
/* Unclear? */
.inline-field-key[data-dv-key="⨭"] + .inline-field-value::before {
content: "⨭";
padding-right: 2px;
color: var(--color-orange);
}
.inline-field-key[data-dv-key="⨭"] + .inline-field-value::after {
content: "⨮";
padding-left: 2px;
color: var(--color-orange);
}
/* Damaged */
.inline-field-key[data-dv-key="⨴"] + .inline-field-value::before {
content: "⨴";
padding-right: 2px;
color: var(--color-purple);
}
.inline-field-key[data-dv-key="⨴"] + .inline-field-value::after {
content: "⨵";
padding-left: 2px;
color: var(--color-purple);
}
/* Too damaged */
.inline-field-key[data-dv-key="⋉"] + .inline-field-value::before {
content: "⋉";
padding-right: 2px;
color: var(--color-red);
}
.inline-field-key[data-dv-key="⋉"] + .inline-field-value::after {
content: "⋊";
padding-left: 2px;
color: var(--color-red);
}
This of course is just a template or starting point, and you might like the background color to change for each of these segments, or use other characters or colors. One nice advantage of doing something like this, is that if you select and copy the text from reading (or live-preview) the markup around the text doesn’t follow since they’re either hidden or added back again using ::before and ::after, and those doesn’t get copied (or selected).
One nice advantage of doing something like this, is that if you select and copy the text from reading (or live-preview) the markup around the text doesn’t follow since they’re either hidden or added back again using ::before and ::after, and those doesn’t get copied (or selected).
And finally, here is a rudimentary query to show some of the examples I worked with in my test vault:
```dataview
LIST
list("⨭ " + join(row["⨭"], "<br />⨭ "),
"⨴ " + join(row["⨴"], "<br />⨴ "),
"⋉ " + join(row["⋉"], "<br />⋉ "))
```
Which displayed the following:
In summary, your options provided are indeed plentiful, and I would consider taking the extra step to add some extra markup to help you style and query your markup when you’re in this process anyways.
In either case, you’ve got the options to use either templates (or plugins) later on when adding new cases in new documents, and either variant should be reasonably easy to replace into your current documents.