41–50 of 132 posts
*foo* always means * followed by , and the closing * is missing and would be flagged.
foo... uh oh missing a closing *, can't parse
Oh boy, HN mangled this. I'm leaving it as an examplar
Earlier quoted context omitted.
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
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.
Earlier quoted context omitted.
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
dis~/cuss/~ing
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.
Earlier quoted context omitted.
As a point of order; \* more than 3\/4's of people may not feel that way, particularly those discussing snake\_case Vs CamelCase
New rule needs ~ when * or _ is used inside words, so your example wouldn't need escaping. E.g., dis~/cuss/~ing
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.
He actually implemented these ideas: https://djot.net/
Earlier quoted context omitted.
As a point of order; \* more than 3\/4's of people may not feel that way, particularly those discussing snake\_case Vs CamelCase
That’s PascalCase, camelCase does not capitalize the first word.
https://en.wikipedia.org/wiki/Camel_case
FWIW I use the same nomenclature as you, but that doesn't make it universal.