On the other hand, now I can use any search and editing utility I want, not just whatever my CMS provides. A good example is adding a space after the § character, which I use a lot. It would take five seconds to fix it across the website.
A good text editor theme makes a big difference. I fine-tuned an existing Markdown theme for Sublime Text to better highlight the markup, especially headings.
weird that broken search basics are not an issue, you extol the virtues of site search in your blog, that engine is capable of matching "shcfua" to "Schufa". Markdown, on the other hand, fails in search long before getting to fuzziness
> § character, which I use a lot. It would take five seconds to fix it across the website
True, and then forever to hunt down those few instances where § was used in a quote or something and should not have been fixed
> I fine-tuned an existing Markdown theme for Sublime Text to better highlight the markup, especially headings.
I "highlighted" most of text markup to make it invisible, a bold text is already visualy bold even in Sublime, why woud I need an extra __indicator__? And heading size is also the best highlighter, which plain text editors don't do
But yeah, I wish there were Sublime-level tool for rich text so you wouldn't have to compromize like that...
I see the diff in Sublime Merge before committing, so I'm far less likely to break something. I used to make so many errors because the WYSIWYG editor caught a random keypress.
Personally, I want those indicators to be there. I'm editing the text and the formatting. I want both to be on the screen.
Frankly I don't need to convince you that this is better. I work with this 40 hours a week and it's better for me. Feel free to take a different approach, but also accept that this approach is tested and true for me.
Also, formatting is there on the screen - in the form of formatting!
So do you change text font size in CSS separate from the content or within markdown since it's part of text and has no value when separated?
> It's part of the diff
it doesn't have to be part of the same diff. In your current workflow you can't separate it by design
> I'm not sure I understand what you're getting at.
It's pretty simple - content diffs are very valuable, markdown pollutes it
Can't you use regex?
_[^_\n\r]+_
edit: I think double underscores are easier, you should be able to use __.+__ and there's no reason to have to avoid matching single_underscore words.