Feature Request: Comment Formatting

[Grey]

I don’t love it, but I can make it work.

Thank you for your help.

[ryanjamurphy]

Another not-exactly-lovable idea comes from a Stack Overflow discussion on the matter.

[//]: # (Write a comment here)

Basically, a line after a blank line starting with some character between two square brackets, a colon, space-octothorpe-space, and then the comment in parentheses will not display on preview. Easy, right?

This syntax is the standard Markdown formatting for reference-style link labels, but since [//] doesn’t point to a real link, the content will not be rendered.

A benefit to this approach is that this content will not be in any output at all if you convert from Markdown to another format. (HTML <!-- comments will still exist in converted outputs.)

Also note that at the top of a page, you can use

---
Some YAML content
---

to hide YAML-style metadata.

But I agree, a more markdown-y comment syntax would be lovely.

[Licat]

Since Markdown doesn’t seem to have comments, whatever we come up is likely going to show up if you switch to any other markdown renderer.

Right now the only thing specific to Obsidian is [[wiki link]] and ![[wiki embed]]. Perhaps also ==highlight==, but it seems like wikilinks are getting wide adoption across many markdown app.

We could possibly add a comment syntax, and if a user’s requirement is markdown compatibility then they can just not use the format.

[Licat]

Anyway, I’d vote for /* comment */. I can’t believe none of the proposals I searched up on the internet proposed this syntax.

Benefits are:

• It’s a very common syntax in programming (almost all C-like languages).
• It works well both inline and multi-line.
• It’s not easy to “run into” unintentionally with regular text.

Disadvantages:

• Not easy to type without numpad.

[death.au]

Whether creating our own comment syntax or sticking with HTML comments, I’d suggest adding a hotkey to wrap selected text (or current block) with the comment syntax.
As a programmer myself, ctrl+/ seems like a pretty general default for this.

[msteffens]

Instead of creating yet another custom syntax, I‘d suggest to support CriticMarkup. CriticMarkup is supported already by quite a few apps, and it‘s well designed & thought thru (so that it doesn‘t clash with any other syntax, yet is still easily recognizable).

With CriticMarkup syntax,

{==this would be highlighted text==}
{>>this would be a comment which would be left out in preview<<}

Here‘s a somewhat contrived example:

[jjosoriof]

Some other people have shown their solution, but additionally, if you are just working in obsidian, if you use the LaTeX format for commenting, it also hides it from the preview mode.

For example: $% this is a comment$

I think it works as you wish, the only thing you have to pay attention is that the last letter should attached to the second “$” sign.

[Dor]

@msteffens

I‘d suggest to support CriticMarkup

It’s quite convoluted. Ideally there wouldn’t be more than 4 symbols (2 before, 2 after - or 3 before 1 closing).

[msteffens]

@Dor

It’s quite convoluted.

Personally, I don’t think so. On the contrary, I think that by choosing a three-character markup this greatly increases chances that there’s no clashes with any other use case. And, at the same time, this allows to choose semantically meaningful characters (like ++ or -- for additions/deletions etc) which helps to memorize/recognize them.

In addition, if the app supports adding highlight/comment markup via a keyboard/menu command and subdues the markup visually via appropriate syntax coloring, then there shouldn’t be an issue with this.

Here’s another (more real-world) example how this could look:

[argentum]

Another thing to consider is how this might impact publish and export (e.g. to PDF). I don’t think tools like pandoc can deal with the CriticMarkup syntax in particular, but it seems that the one suggested by @ryanjamurphy plays well with it (albeit with some caveats for the YAML metadata).

[santi]

Is anyone aware of any current comment format that works for putting a [[llinked note]] while still being able to click on it.

My main purpose is to be able to embed notes in other notes, without [[links]] showing in embed preview

I tried the following:

/* [[new note]] */
<!-- [[new note]] -->
$% [[new note]]$
[//]: # ([[new note]])

None of them seem to succesfully comment out while still making it clickable.

I suspect this might not be possible

The perfect solution to this problem is in here:

Remove Yaml Front Matter from embeds

Meta Post - Common CSS Hacks

unfortuntaly it doesn’t work with v.0.9.3 anymore

[ryanjamurphy]

Interesting challenge. If you don’t usually use code (backticks) or highlight (equals signs) syntaxes in your markdown, you could probably achieve this with some custom CSS. Hide the unused syntax in preview (display: none;) and it should remain clickable in edit but hidden in preview.

[santi]

That’s a nice solution, what would it look like if I where to use (equal signs) for instance?

how do I determine == (equal signs) in combination with { display: none; } ?

Thanks, I think this might be what I’m looking for

[ryanjamurphy]

In Obsidian, this markdown ==some text== becomes this HTML <mark>some text</mark>; i.e., highlighted text.

If you don’t use <mark> normally, you should be able to add something like this to obsidian.css to hide <mark>’d text in Preview:

mark {
    display: none;
}

[santi]

got you, that makes sense, I’ll be playing with it! I appreciate the help!

[ishgunacar]

Nothing to add but I just want to say I love these forums bc it feels like I snuck into a super secret club of really smart people and content creators for free.

I clicked on this link, gained a cool insight about commenting (something I had wondered before). And it turns out… CGPgrey is here, casually asking a question. Also saw Curtis Mccale the other day who is another one of my fav content creators.

I love it

[0x4A]

If Obsidian Publish is to one day allow users to utilize their own custom CSS, then it may make sense that Obsidian adopt the ability to specify a CSS class for a block elements like many Markdown flavors already do.

Given that, rather than introduce another Obsidian-specific markup, one could turn any block element into a ‘comment’ simply by adding a CSS class to it that included display: none;.

This entire paragraph could be visible in the editor and hidden in preview mode, without adding whitespace, and without creating new markup, just by adding a class.{.my-hidden-class}

[santi]

Super happy with this community as well, @ishgunacar by far my favorite community online, you comment made my day!

[santi]

@0x4A I don’t know why I didn’t think of that, that’s a genius approach!
I understand obsidian publish doesn’t allow for custom css yet, but is this approach already possible in a local vault by specifiying this in obsidian.css?
Or is this something that’s not possible yet?

[0x4A]

Currently only using the method @ryanjamurphy described above, by hijacking an already existing markup.

There’s a decent argument for it eventually being included though, as it already has an adopted syntax in Pandoc and at least two Markdown flavors, maybe more.