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.
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.
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.
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<<}
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.
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:
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 @ryanjamurphyplays well with it (albeit with some caveats for the YAML metadata).
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.
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.
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}