Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Beyond Markdown (2018)

johnmacfarlane.net

Post reply on HN
Print view View original

31–40 of 132 posts

Re: Beyond Markdown (2018)

#31

Post by _gabe_ »

boerseth wrote: post #18
throwawaaarrgh wrote: post #15

> All of these rules lead to unexpected results sometimes, and they make writing a parser for CommonMark a complex affair. > What if we tried to create a light markup syntax [..] revising some of the features that have led to bloat and complexity in the CommonMark spec? Are you writing this new format to make life easier for the humans using it, or the humans programming it? It's sad when programmers don't see the fo…

If the rules are too complicated, then they are a challenge for all parties, both users and implementers. I think it is useful to be able to imagine at least on some higher level what a parser would do to the stuff I write, so everyone benefits from the ease of understanding that comes with simpler rules. The question is just how far we can simplify without reducing usability. The rest of the article frequently takes…

> If the rules are too complicated, then they are a challenge for all parties, both users and implementers

Not necessarily. Generics, and/or C++ templates are a pain to parse because they're context sensitive. But while reading/writing code it's typically obvious whether I'm writing a comparison or a generic/template.

  Foo foo;
  // VS
  Foo
Likewise, in C++ you can end up with:

  unordered_set> mySet;
  // >> is ambiguous here without a symbol table or context around the statement
  Foo >> 5;
I think both of these are fairly obvious as a user of the language, but boy am I glad I don't have to parse that!

Re: Beyond Markdown (2018)

#32

Post by SoftTalker »

qingcharles wrote: post #30
egypturnash wrote: post #16

> To dramatically reduce ambiguities, we can remove the doubled character delimiters for strong emphasis. Instead, use a single _ for regular emphasis, and a single * for strong emphasis. I would love to see * gone but I must note that _ is annoyingly hard to type on a screen keyboard. Back in the days of USENET one common choice was using a / to delimit /emphasis/ - the usual reading was that this indicated words th…

I really like your proposal, but in the days of USENET the // wasn't interpreted by the machine but simply by our minds, just like * for bold. Would there be any extra issues caused by italics being / rather than *? I'm honestly with you on this and I'm in the middle of building a huge Markdown site where I have the freedom to change the syntax now if I want.

I'd like to see

  *this is bold*
  /this is italics/
  _this is underlined_
Beyond simple conventions like this, I'd just as soon drop into HTML as deal with some other markup that ends up being just as complex. We don't need to allow permutations and combinations such as bold and italics, double-weight bold, etc. these never occur in normal prose typesetting and if you need it just use HTML for those rare cases.

Re: Beyond Markdown (2018)

#33

Post by cbarrick »

egypturnash wrote: post #16

> To dramatically reduce ambiguities, we can remove the doubled character delimiters for strong emphasis. Instead, use a single _ for regular emphasis, and a single * for strong emphasis. I would love to see * gone but I must note that _ is annoyingly hard to type on a screen keyboard. Back in the days of USENET one common choice was using a / to delimit /emphasis/ - the usual reading was that this indicated words th…

In IPA, slashes are used for abstract phonemic notation ( pronunciation guides). Converting that to would be annoying for certain communities.

https://en.wikipedia.org/wiki/International_Phonetic_Alphabe...

Re: Beyond Markdown (2018)

#34

Post by SoftTalker »

jitl wrote: post #23
egypturnash wrote: post #16

> To dramatically reduce ambiguities, we can remove the doubled character delimiters for strong emphasis. Instead, use a single _ for regular emphasis, and a single * for strong emphasis. I would love to see * gone but I must note that _ is annoyingly hard to type on a screen keyboard. Back in the days of USENET one common choice was using a / to delimit /emphasis/ - the usual reading was that this indicated words th…

But I like to write paths like /usr/bin/ in my text and don’t want to worry about backtick code quoting them every time

Most people don't write file paths. Only a concern for programmers, who should be fine escaping them by whatever mechanism.

Re: Beyond Markdown (2018)

#36

Post by eduction »

prepend wrote: post #17

I write a lot of markdown. Ive taught lots of people to use it. I’ve never encountered these problems. Markdown is meant to be simple. To represent complex things, use something else. I don’t think I’ll ever use this and if someone tries to make me learn this instead of regular markdown, I’ll probably just not bother. I don’t want to diminish anyone’s creativity, but this seems like a lot of work put into something u…

The article reads very much like a list of problems important to an implementation author rather than a user. Except maybe the nested list thing, which does sound somewhat annoying. But also rare.

Re: Beyond Markdown (2018)

#37

Post by defrost »

SoftTalker wrote: post #32
qingcharles wrote: post #30

Earlier quoted context omitted.

I really like your proposal, but in the days of USENET the // wasn't interpreted by the machine but simply by our minds, just like * for bold. Would there be any extra issues caused by italics being / rather than *? I'm honestly with you on this and I'm in the middle of building a huge Markdown site where I have the freedom to change the syntax now if I want.

I'd like to see *this is bold* /this is italics/ _this is underlined_ Beyond simple conventions like this, I'd just as soon drop into HTML as deal with some other markup that ends up being just as complex. We don't need to allow permutations and combinations such as bold and italics, double-weight bold, etc. these never occur in normal prose typesetting and if you need it just use HTML for those rare cases.

As a point of order;

\* more than 3\/4's of people may not feel that way, particularly those discussing snake\_case Vs CamelCase

Re: Beyond Markdown (2018)

#38

Post by doubleunplussed »

SoftTalker wrote: post #34
jitl wrote: post #23

Earlier quoted context omitted.

But I like to write paths like /usr/bin/ in my text and don’t want to worry about backtick code quoting them every time

Most people don't write file paths. Only a concern for programmers, who should be fine escaping them by whatever mechanism.

And in markdown you chuck them between backticks to indicate they're verbatim text to be rendered in monospace.

Re: Beyond Markdown (2018)

#39

Post by lewisjoe »

We are implementing markdown support in Zoho Writer (https://zoho.com/writer) and I can confirm how difficult it is to handle bold and italics.

It definitely is a weird choice to use *s for both bold and italics. Parsers could be implemented much easier, if both had different delimiters as mentioned in the post.

Re: Beyond Markdown (2018)

#40

Post by ncallaway »

throwawaaarrgh wrote: post #15

> All of these rules lead to unexpected results sometimes, and they make writing a parser for CommonMark a complex affair. > What if we tried to create a light markup syntax [..] revising some of the features that have led to bloat and complexity in the CommonMark spec? Are you writing this new format to make life easier for the humans using it, or the humans programming it? It's sad when programmers don't see the fo…

The problem is when it's too hard for the computers, then it negatively impacts the user experience.

There are cases that are 100% ambiguous in the spec, which means there can be no _right_ answer. Different users will have different (and both reasonable) expectations about what the same input will do. So, in these cases "too hard" for the computer means leads directly to a negative user experience. The language becomes more unpredictable.

I agree that we shouldn't _ever_ lose focus on the end user experience. But sometimes, you have to make the spec less ambiguous to improve the end-user experience.

Post reply on HN