-
-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple representations of thematic break contradicts goal 11 #59
Comments
I just read the specification and this immediately caught my eye. I'm also voting for |
The infinite lookahead point is a good one, so I think we need at least some change. Of course, we could avoid infinite lookahead while retaining more possibilities for thematic breaks by putting an upper bound on the length of the thematic break. One advantage of |
That's fair. I don't have a strong opinion between I also want to add that the example code (with spaces) looks too similar to crontab syntax, where
So at the first glance, this may look like they sleep one/every minute, and especially set a cron job alarm as a joke. 🤔 |
An advantage of |
As far as old typescripts go, well that could be true for |
Well various asterisk based things were used in printed books long before typewriters, including three asterisks with space between them, albeit usually a wider space. |
Aside, it would be nice if djot users could easily get a centered If djot had a syntax for centered text, I'd use that when I wanted the centered Regardless, to reduce any potential ambiguity, I think it's a good idea to require the interstitial spaces in |
@uvtc Perhaps I read it wrong, but what does centering and rendering have to do with Djot (syntax)? The renderer (be it HTML or other) is responsible for interpreting and styling it. No? |
@uvtc Since in djot even thematic breaks can take attributes you could easily use something like |
@bpj actually the thematic break is a block element, so attributes have to come before (+ blank lines around):
Whereas (Same with |
Thanks, all. Yes, as also pointed out to me in #205 , I see that I could do
and have some css to center that. |
The syntax spec says,
We already enforced canonical representation for headings or code blocks. I don't see any rationale to keep both
***
and---
for<hr>
.Allowing arbitrary length >= 3 and spacing inside seem also unnecessarily complicate the syntax, since they require infinite-lookahead in the parser (though still linear), in case of
-----------
and-----------text
. Since this mark can only appears as an individual block, there's no real need to extend the length to "align with some other texts".Personally I always use
---
(exactly 3 characters) in markdown because it's more like the rendered horizontal line (hr).The text was updated successfully, but these errors were encountered: