Hide content in curly brackets

Use case or problem

I recently started using the obsidian-enhancing-export plugin which uses pandoc to convert markdown notes to ms word, pdf (rendered by latex), html or other file formates.

As a scientist I regularly need numbered figures and tables and citation references. This can be accomplished by pandoc-crossref but requires some additional information in curly brackets to be added after the link to the figure.

According to standard markdown curly brackets are reserved characters (although they are currently not used) and should be escaped with a backslash. Content in curly brackets, which are not escaped, should therefore not be rendered. However, this is currently not the case in Obsidian. Obsidian renders curly brackets and the content therein even in reading mode, what makes document containing additional formatting information for pandoc not very nice to read.

Proposed solution

Obsidians preprocessor should identify content in curly brackets and treat them like other markdown formatting symbols. That means ideally they are only displayed even in editing mode when the cursor is placed in the line containing them. As some users may prefer to have content in curly brackets rendered even if they are not escaped, this could be added as an editor option.

Alternatively/additionally content in curly brackets should just be placed in its own html <span> tag and have a class assigned to it, so that the appearance can be styled with some custom css snippet.

Current workaround (optional)

Currently there is no work around.

Where did you get this from?

Are you sure about this?

Can’t find any mention to what you are talking about here https://spec.commonmark.org/0.30/

I came across this in this post Why is { a special character in Markdown? - Meta Stack Exchange

But it is also mentioned in the github markdown guide that curly brackets are reserved special characters and should be escaped with a backslash Markdown text for GitHub from HTML – Index

Neither is an official source.

That‘s true. But I don’t know if there is really any official agency that defines what is part of the standard markdown syntax like there is for html and css.

Instead there seem to be many markdown implementations that do or do not support certain formatting features.

All I can say is that based on my google research there seem to be several markdown editors/implementations that do treat curly bracket as special characters.

Anyway this discussion is becoming a way academic. There are usecases as mentioned in my initial post where treating curly brackets as special characters makes sense. So it would be nice if obsidian would support this as least as an option.

In particular since this currently the only way to export obsidian markdown notes into pdfs with active links. Obsidian Tutorial for Academic Writing | by Leonardo Castorina | Better Humans

By the way, this was my first post to the obsidian forum and I filed this as “Feature request”.

Could you explain me why it was moved to the Help section as this is definitely not a help topic?

First I wanted to understand where this curly brackets for comments was coming from.

Since it’s not part of the commonmark spec that we follow (not any other I am familiar with), we are not going to do it. I am going to move this to plugin ideas.

That’s a pity. I think this could be easily supported be injecting a { what ever content } before and after a curly bracket, which should be fairly easy to implement.

For a normal user this would have no effect, but with a small snippet of css the display mode could the set to hidden in reading mode and grayed out in editing.

Creating an extra plugin just for this purpose seems to me a bit of overkill. But if there is no other way. Maybe eventually I will find some time to learn how to write an obsidian plugin and realize it myself.

You’ve indirectly hit the nail on the head here. Most people don’t need this functionality, so doing it via plugin is the smartest way so that the core app stays lean and fast for the majority of users.

It does sound like a great project for learning how to create a plugin. Once you get started you might find you’re unable to stop - I’m at 6 plugins and counting…!

If you do decide to give it a go, I think you’ll be wanting to create an editor extension which are the extensions to the live preview mode. Here’s the docs for that: