TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Beyond Markdown (2018)

125 点作者 unforswearing将近 2 年前

22 条评论

egypturnash将近 2 年前
&gt; 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.<p>I would love to see * gone but I must note that _ is <i>annoyingly</i> hard to type on a screen keyboard.<p>Back in the days of USENET one common choice was using a &#x2F; to delimit &#x2F;emphasis&#x2F; - the usual reading was that this indicated words that would normally be rendered as &#x2F;italics&#x2F;. You&#x27;d often see it used to indicate the titles of books and movies, as well, since the typographical convention was typically that these were italicized as well - note that both &lt;em&gt; and &lt;cite&gt; typically render as italics, for instance. I have <i>always</i> disliked Markdown&#x27;s choice to use * as a delimiter for both italics and bold; &#x2F; always implied italics to me, and * always implied bold.<p>Anyway. I propose that &#x2F; would be a much better delimiter for emphasis than _. On a US keyboard, it can be typed without a shift key. And on a US IOS screen keyboard, it is a simple swipe on B, versus shifting to the numeric entry page and swiping on &amp;.
评论 #36557181 未加载
评论 #36557350 未加载
评论 #36557257 未加载
评论 #36563770 未加载
评论 #36558628 未加载
评论 #36557074 未加载
评论 #36557079 未加载
评论 #36557089 未加载
sqs将近 2 年前
I understand where the author is coming from and respect their contributions to Commonmark.<p>But...<p>There are tons of markup languages for prose that have well-defined specs.<p>So, why did Markdown win?<p>IMO, <i>because</i> it does not have a well-defined spec. It is highly tolerant of formatting errors, inconsistencies, etc. If an author makes a mistake when writing Markdown, you can always look at it in plain text.<p>Whereas a perfectly-spec&#x27;d markup language would probably evolve toward an unreadable-to-humans mess in the committee-driven pursuit of precision.<p>You see this theme in so many places in tech: &quot;less is more&quot;, the Unix philosophy of everything-is-a-file, messy HTML5 over &quot;XHTML&quot;, ML extraction vs. explicit semantic web, etc.
评论 #36558625 未加载
评论 #36556653 未加载
评论 #36556779 未加载
评论 #36557226 未加载
评论 #36561065 未加载
评论 #36559171 未加载
评论 #36556759 未加载
评论 #36558993 未加载
评论 #36559351 未加载
评论 #36556648 未加载
评论 #36559068 未加载
评论 #36563858 未加载
评论 #36560122 未加载
评论 #36559608 未加载
throwawaaarrgh将近 2 年前
&gt; All of these rules lead to unexpected results sometimes, and they make writing a parser for CommonMark a complex affair.<p>&gt; 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?<p>Are you writing this new format to make life easier for the humans using it, or the humans programming it?<p>It&#x27;s sad when programmers don&#x27;t see the forest for the trees.
评论 #36557047 未加载
评论 #36557521 未加载
评论 #36557190 未加载
0cf8612b2e1e将近 2 年前
Weird that he did not reference the djot package[0] which seems like his attempt at implementing this thesis.<p>[0] <a href="https:&#x2F;&#x2F;djot.net&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;djot.net&#x2F;</a>
评论 #36556742 未加载
评论 #36557369 未加载
eslaught将近 2 年前
Needs a 2018 in the title.<p>He actually implemented these ideas: <a href="https:&#x2F;&#x2F;djot.net&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;djot.net&#x2F;</a>
评论 #36559409 未加载
anschwa将近 2 年前
Personally, I would like to see a markdown spec that eliminates parsing ambiguity by restricting the &quot;edge-case&quot; features that HTML is really much better at describing in a standard and structured way.<p>I think we could pick one way to handle emphasis, lists, and code blocks that covers a specific and predictable 80%.<p>Anything that becomes hard to describe without including additional notation to the grammar is probably best suited to be left as HTML, as was the intention behind markdown to begin with.
评论 #36556791 未加载
silvestrov将近 2 年前
One feature which I&#x27;m missing which is very useful for CMS systems etc is a standard syntax for implementation specific callbacks&#x2F;macros.<p>E.g. a macro that returns todays date, todays great offer, etc. Or a &quot;number of days until xxx&quot; for countdowns until some event.<p>His attribute syntax is very close. A posssible macro syntax use {@ as leading marker, e.g.<p><pre><code> {@macroname position=left}</code></pre> or<p><pre><code> There is {@daysuntil date=20230710} days to launch.</code></pre>
lewisjoe将近 2 年前
We are implementing markdown support in Zoho Writer (<a href="https:&#x2F;&#x2F;zoho.com&#x2F;writer" rel="nofollow noreferrer">https:&#x2F;&#x2F;zoho.com&#x2F;writer</a>) and I can confirm how difficult it is to handle bold and italics.<p>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.
dr_kiszonka将近 2 年前
1. Markdown is great.<p>2. The only thing I miss is support for nested numbered lists.<p>2. 1. (The best kind of lists.)
prepend将近 2 年前
I write a lot of markdown. Ive taught lots of people to use it. I’ve never encountered these problems.<p>Markdown is meant to be simple. To represent complex things, use something else.<p>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.<p>I don’t want to diminish anyone’s creativity, but this seems like a lot of work put into something unnecessarily.
评论 #36557398 未加载
评论 #36559259 未加载
JimmyRuska将近 2 年前
I also made my own editor a long time ago, used it for personal use and on the writing site roleplay.cloud. It had lisp-like syntax, custom expansions. It also had some of these ideas, reference links, I would run code snippets with [python ...]. Normal html code would also work, like [br] instead of &lt;br&gt;<p><a href="https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20121017064607&#x2F;http:&#x2F;&#x2F;94.249.190.129&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20121017064607&#x2F;http:&#x2F;&#x2F;94.249.190...</a><p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=4437875">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=4437875</a><p>These days, it would be good to mix&#x2F;match ideas from: pugjs, htmlx, jupyter, dhall
eviks将近 2 年前
Is there any great modern rich document alternative? That wound truly go beyond markdown
评论 #36577198 未加载
评论 #36560758 未加载
mnot将近 2 年前
Making breaking changes to markdown is about as practical as doing it to HTML -- already existing content and mindshare give the current form massive inertia.<p>The is especially the case when it works for the vast majority of use cases (or can be hammered into them); ambigiuities are very visible to implementers and detail-oriented folks, but most people never see these issues, or don&#x27;t care about them.<p>And, while it sucks that it&#x27;s complicated to implement, that burden is on relatively few people. See also: the HTML Priority of Constituencies.
holler将近 2 年前
&gt; Consider, for example *this* text*<p>Oh yes. I made the fun decision to write a markdown parser&#x2F;contenteditable component for <a href="https:&#x2F;&#x2F;sqwok.im" rel="nofollow noreferrer">https:&#x2F;&#x2F;sqwok.im</a> and ended up spending probably a month on it, largely writing endless unit tests and covering odd cases like that.<p>It&#x27;s far from perfect and probably will still break on certain ambiguous inputs. I like his ideas for clarifying the language for the most general audience.
评论 #36561177 未加载
hinkley将近 2 年前
I have been trying to research my way out of having to write a markdown parser that doesn&#x27;t allow inline html because I don&#x27;t want to be a markdown author, but I categorically don&#x27;t want people being able to inject things into the wiki(s) I need to create. In some languages it&#x27;s a flag. In others, there&#x27;s no flag.<p>This is like not using bind variables on your sql library. I just don&#x27;t understand it. I&#x27;m looking at you, Crockford.
Decabytes将近 2 年前
This is why I like the way Racket does this with the Pollen language. You can use Pollen mark up and create your own tags and then decide how they are converted. It all becomes a list of X-expressions that can be manipulated in any form you like. But the tree nature of an X-expression means you don’t get issues like *strong* word*.<p>For example I can write ◊bold{strong* word} and it becomes (bold “strong* word”). It’s very clear how this should be rendered.
wackget将近 2 年前
One feature missing from any Markdown language is vertical table headers (i.e. headers on the left):<p><a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;q&#x2F;60995936&#x2F;1652951" rel="nofollow noreferrer">https:&#x2F;&#x2F;stackoverflow.com&#x2F;q&#x2F;60995936&#x2F;1652951</a>
cratermoon将近 2 年前
Just make it so that literal * has to be escaped, and use a greedy parse.<p>*<i>foo* always means * followed by </i>, and the closing * is missing and would be flagged.<p>&lt;string&gt;&lt;em&gt;foo&lt;&#x2F;em&gt;... uh oh missing a closing *, can&#x27;t parse<p>Oh boy, HN mangled this. I&#x27;m leaving it as an examplar
评论 #36557713 未加载
H8crilA将近 2 年前
This makes parsing and rendering easier, but writing harder. Given the widespread adoption of Markdown I suspect this project to go absolutely nowhere, since it focuses on precisely the opposite thing that makes Markdown popular.
ggm将近 2 年前
I wish more markdowns accepted some notation for keyword bullet lists. Indented lists which mark with a bolded or emphasised term.<p>If you can do this, you can write manual pages for options or flags
评论 #36557733 未加载
评论 #36558674 未加载
yaccz将近 2 年前
reStructuredText is way better format while only slightly more complex than markdown.
ChrisArchitect将近 2 年前
(2018)