I’m a historian starting to move my notes into Obsidian. I work with a lot of documents that are very old and in difficult handwriting. In my existing transcriptions, I wrote legible text in plain text, and I indicated passages where I was unsure of my reading [in single brackets] and passages with damage (or, if the damage is too extensive to guess, like this <>). The angle brackets, obviously, break Obsidian. I’m not sure if the square brackets break it, too, or if it’s just that having the color change on one ambiguous let[t]er is not ideal.
I can probably mass replace my existing system with a new one without much fuss, but I can’t figure out what I could possibly replace them with, so I’ve come here for help.
Features I’m looking for:
Quick to apply down to the single-letter level
Does not have an existing function in my or Obsidian’s system (so e.g. italics are out because I use them for something else)
Marks the beginning and end of the unclear or damaged passage, so I don’t prefer !a solution like this!, because it’s too easy for me to lose track of whether each one is the beginning or the end of the damage. Highlighting or a text format feature I don’t use for something else would be okay, though.
If using characters per se, the characters must never appear in the documents I’m working with, which eliminates () and any variety of dash.
I have to have these two categories marked out somehow. What would you suggest?
I don’t know whether I’d use it or not, but the editing toolbar plugin allows you to easily apply different coloured highlights or text. All you have to do is decide what colours to use and what meaning to give those colours.
It uses HTML tags to give these non-markdown colours, but they’re hidden in use.
You can mark the angle brackets as plain text by preceding them with a backslash to “escape” them. I think you only need to do it to the opening bracket. \<
The square brackets don’t break anything — it’s just an unfortunate quirk of Live Preview’s renderer. In Reading View they look as you’d expect. Here’s a CSS snippet to (mostly) fix the square bracket problem (they may still show styling when you hover the pointer over them):
/*
Obsidian highlights text in single brackets because it might be a Commonmark link, which annoyingly affects bracketed text in quotes, etc. This snippets stops that (but still leaves proper links highlighted).
Courtesy of trainbuffer #8798. https://discord.com/channels/686053708261228577/694233507500916796/1040011911229612135
*/
.cm-s-obsidian .cm-link.cm-hmd-barelink {
color: var(--text-normal);
}
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.
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.
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:
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.
I am not that good with Obsidian yet, so it’s taking me some time to work through some of these—but wow, what a nice forum! Thanks so much, I’m enjoying experimenting with these.
Hello! It feels like it took one hundred years, but I have settled on a solution to use for now, largely based on @holroy’s advice. I also appreciated @ariehen’s tip to use Wrap with shortcuts, which for this purpose I found a little faster than Templater.
I was unable to use the elegant combination of fields and distinct characters holroy suggested. Although I liked the styling options using both would have provided, I’m never going to query “damaged sections”: I have thousands, many of which are only one or two characters long. Moreover, it turned out that I underplayed the complexity of my data, and I had something else I really needed the inline fields for in the same sections where I would’ve been using the characters. (I believe I understand that fields do not, generally speaking, nest?)
Here’s my new transcription character key, which now seems so simple I should have figured it out in many fewer days:
While the documents I work with are pretty much entirely in Spanish, I also have mixed-language audio recordings to work with, where it is important to my research to note which language is being used, when. So I sacrificed the nice formatting on the brackets and, instead, dedicated my Dataview inline fields for transcription notes to which languages are being spoken, like so:
I did not view it as possible to use language fields for audio transcriptions and quality fields for document transcriptions because some recordings are from environments like, say, a politician’s speech: a baby crying in the crowd might knock out a couple of words, a case where I wanted to use the same “damage” notation. Because of the problems with field nesting, I chose to keep the same symbol key through my transcriptions, no matter the format of the original data.
Here’s a couple lines of a document transcription using the new key (colors would have been nice, but this works fine):
This passage currently looks like nothing much in reading mode, because I haven’t yet figured out how to code the fields so that each language “type” has its own color. (I haven’t done this much coding since high school!) I’ll figure that out later—I hadn’t even imagined being able to search for “all passages in x language,” but that’s going to be a really useful feature for me. At least one of my professors is jealous and wants to learn how to do this.
Normally I’m all for using the normal parentheses to hide the field name when in reading view, however, if you use the square brackets, the elements include the field name for the first element.
This allows for custom CSS to hide the name again, and use the selector for the name element + the value element to style the value element on its own. Does that make sense for you? Take a look in the Developers Tool, and you’ll hopefully see the difference.
If not, I can try to write it up, but I’m on mobile for some days now, so it’s not as easy to produce and test proper code.
