I’ve been working with MarkDown in VSCode/VSCodium editors for a while and had no real issues after learning a few helpful rules like double spacing to do a line break. Of course these apps are meant to be code editors and use a monospace font by default, so there are no issues with anything being misaligned that shouldn’t be, especially in tables and indented MD “code” blocks that would also be monospace or otherwise forcibly aligned in the rendered preview.
Obsidian, on the other hand… has been pretty frustrating so far. It seems to want the editor view to be some sort of hybrid between being “raw” MD text and a fully rendered WYSIWYG. Lots of misalignment where I’m not used to there being any issue.
Some googling shows I’m not the only one who wishes the editor view (and ONLY the editor view) could be forced with a simple switch to use only monospace fonts, and behave more like a true code editor. There is apparently no super simple way to do this, other than messing with theme CSS files.
But even if that were fixed, there is another problem, and I’m looking for feedback on whether this could be considered a bug by the Obsidian developers, or if there is some plugin or setting that could stop this from happening.
Any line with a Grave character ( ` ) will take on a different appearance, as if it is some kind of “code” line. There’s nothing on that line surrounded by Grave (backtick) characters, there’s only one Grave. But everything after the Grave to the end of the line ends up having different spacing and highlighting.
The VSCode variations don’t care about this character when it’s alone, and don’t change the way that line is rendered in the editor view. They will of course change the syntax highlighting if you actually surround something with two Graves, as they should. But they ignore a lone Grave character.
I can bypass the issue by putting a backslash in front of the Grave character. But this introduces ugliness in an otherwise perfectly aligned MD table. And it’s unnecessary in VSCode variants.
A similar problem happens when placing a Left_Brace ( [ ) or Right_Brace ( ] )character by itself on a line, with a space after them. The VSCodes ignore them. Obsidian’s editor has a pretty bad spacing issue after the Left_Brace, and on another line treats the text differently before the Right_Brace. It seems to be changing the font when these characters are encountered.
You might ask, why would I be putting these characters on a line by themselves, without wanting to pair them with a second one? They are part of a document listing keyboard shortcuts, which includes the Grave and Braces keys. There isn’t room in the MD table to spell out the name of the keys, so I just use the character.
Again, this has not caused any kind of problem when editing MarkDown in VSCode-based apps. And the rendered preview comes out fine in Obsidian whether I bother to escape these characters with backslashes or not. The editor view just ends up being really ugly in Obsidian, even when I try to use the same fixed-width font for the editor view as well as for the specific “Monospace Font” setting. Even though they are the same font, one seems to get shown in a different size, screwing up the raw text of the MD tables they are inside of.
If there is a plugin that can solve all this, I haven’t found it yet. I could submit a bug report, but the question is if anyone else, especially the developers, would agree that these are “bugs” just because it isn’t behaving as cleanly as VSCode in the editor view when I use some unusual characters that aren’t typically used by themselves.
Any thoughts, solutions or observations are welcome. I want to use Obsidian but it’s feeling very awkward compared to how I’ve been using MarkDown outside of Obsidian.
Looks like this comment editor supports MD tables, so here’s an example of the lines that are going screwy in Obsidian.
| –– Keys –– | ––––––––––– Description ––––––––––– | –– Unicode –– | –– Alt Code –– |
|---|---|---|---|
| Opt+` | This line gets a darker background | {U+000} | n/a |
| Opt+A | This line is fine | {U+000} | n/a |
| Opt+[ | This line is messed up after the [ | {U+000} | n/a |
| Opt+B | This line is fine | {U+000} | n/a |
| Opt+] | This line is messed up before the ] | {U+000} | n/a |
