It's a good example of "pave the path" design philosophy, where you do what users are already doing rather than trying to impose some platonic ideal of what the world should be like. And it works quite well at that.
It's a good example of "pave the path" design philosophy, where you do what users are already doing rather than trying to impose some platonic ideal of what the world should be like. And it works quite well at that.
For those of you who weren't there:
*bold*
_underline_
~strikethrough~
/italics/
> Quotation
- list
- list
- list
I've been using these for almost half a century. They're much easier and more intuitive than Markdown. I see no compelling reason to change.Strikethrough and bold are doubled to avoid common ambiguities. Your underline should technically work, but it comes out as an <em> (emphasis) tag, which is rendered as italics in most browsers.
* I had to escape all of these asterisks.
** I see this happen fairly often to people's comments here.
The bullet point problem is fixed by only bolding when the asterisks are on either end of word characters.
This is just terrible UI, why do you need garbage marks when you already have bold? And you can edit "as normal" if you like, but that only requires displaying asterisks during that tiny % of time you edit the word, not all the time when you read it or edit something else.
But you're not editing that text! You're editing some other text and see a bunch of asterisks all over the place. And this is especially bad in nested styles - try some colored bold word in a table cell - without hiding the markup you'll basically lose most of visibility into the text/table layout
> to reduce ambiguity
it does the opposite, you can't easily distinguish between an asterisk and an asterisk, which is... ambiguity
> can't distinguish between adding more bold text to currently bold text or adding non-bold text immediately
Sure you can. In a well-designed editor you'll see the style indicator right near your caret is so it's always obvious whether and how your typed text is styled or not.
In a not-so-well-designed editor you'll get that indicator far away from your caret or just get asterisks appearing when you need them.
In a not-designed editor you'll see them all the time even when they don't serve any purpose.
This might be why I also liked LaTeX. The markup itself is semantic and meant to help me understand what I am editing. It isn't just some keyboard-shortcut to inject a styling command. It is part of the document structure.
Only for the 3 primitive styles that were supported? 3 table cells of RedBold GreenLowerCaps BlueUnderlineItalic isn't easy anymore
But also - there wasn't a single app in the 80s with a different easy approach, right? So removing noise had a downside.
> styling command. It is part of the document structure.
Not for the most used markdown markers, where styling = semantic.
But yeah, this tension you are describing is also where other concepts like "paragraph styles" bothered me in later editors. I think I want/expect "span styles" so it is always a container of characters with a semantic label, which I could then adjust later in the definitions.
Decades later, it still repulses me how the paragraph styles devolve into a bunch of undisciplined characters with custom styling when I have to work on shared documents. At some point, the only sane recourse is to strip all custom styling and then go back and selectively apply things like emphasis again, hoping you didn't miss any.
And... I preferred WordPerfect's separate "reveal codes" pane, which reduced the opportunity for ambiguity. WP 5.1 has never been equalled as a general-purpose word processor.
edit: HN automatically finds this example and puts in escapes to make it work. From elsewhere in the discussion I just want AsciiDoc.
https://docs.asciidoctor.org/asciidoc/latest/asciidoc-vs-mar...
Or italics can be //double slash// to avoid ambiguities with file paths. That still leaves the windows style //some/file/path as ambiguous But I’ll never accept single * as natural for italics.
*bold* and _italic_ would have been better.
As for /slashes/, which would visually be perfect for italics, the only reason they conflict between italics and filepaths is the fact that in both cases they are expected to be used at the beginning and end of a word. Maybe using an unnatural placement of )parentheses( could have worked as a non-conflicting indicator of italics.
Markdown was created in an era before the web had easily used components for structural syntax highlighting (tree-sitter) and where reliance on regex-based approaches was more common.
Using different delimiter for opening and closing is a good idea on its own, too. I think it makes parsing simpler and unambiguous wrt nesting.
I've imagined something like this:
`(monospace)
_(underline)
/(italics)
~(overstrike)
Probably looks a bit more distracting, though.O, c'mon! That is clearly a giant heading in a display font, squeezed in the middle and wider at the top and bottom. (-;
- Superscript with hat symbol (^)
- Hidden content (also known as spoiler tags, content warnings, click-to-reveal, etc...) with two pipe symbols (||) at start and end of hidden content. Interact with the content to show the content inside.
- Table syntax to show tabular data and align content with pipe, hyphen, colon symbols
---
After that, I'd look at the extensions that are only useful for the use-case you're targeting:
- Subscripting with tilde symbol (~)
- IDs, Classes and Attributes
- Task lists
- Sections / Containers
- Language labels for code blocks
- Math Support (mathml, latex, katex, etc...)
- Table of Contents / Footnotes
- Definition lists
- etc...