Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
6 posts
|
I’ve been using plain-Unicode text for lists, e.g.: Project Changelog ================= Release 4 (2013-07-02) • Connect the sanafratz to the grepsling • Hypercharge the whizding Release 3 (1988-05-04) • Check for loose wires in the kugelator Release 2 (1988-04-01) • Collect runaway monkeys • Clean up ketchup spill Release 1 (1987-12-15) • Launch satellite This almost translates to AsciiDoc, except I need to downgrade the source from using real bullet points (U+2022 •) to ASCII asterisks. ☹ May I request that AsciiDoctor be extended to recognize Unicode bullets as input for un-ordered lists? (This is in a way the converse to ‹https://github.com/asciidoctor/asciidoctor/issues/957›.) |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Administrator
2681 posts
|
On Thu, Oct 23, 2014 at 12:31 PM, jcsalomon [via Asciidoctor :: Discussion] <[hidden email]> wrote: May I request that AsciiDoctor be extended to recognize Unicode bullets as input for un-ordered lists? I think this goes against the spirit of being able to describe the formatting using the ascii code range (or course, it still supports UTF-8 content). I suppose we could consider adding one unicode character to be used as an alternative to the asterisk. Is the bullet the character you would prefer over all others? Is that pretty universal? In order words, can you find other cases of it being used this way? |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
6 posts
|
Depends on how that spirit is understood, I suppose: If it’s “AsciiDoc is ASCII (but UTF8-safe),” then this is in direct opposition; OTOH, if it’s “Pure ASCII source is supported,” then that leaves itself open to compatibility extensions using Unicode.
It’s kinda hard to search for “•”, so I have no idea how prevalent this is. I know I’m not the only one with such a preference; I’ve found a parallel discussion on the Commonmark discussion site. This is very much a ‘camel’s nose’ feature, though. I use U+2022 (•) because there’s an easy Windows keyboard shortcut for it (Alt+0149) and almost all fonts have a glyph for it, but I could definitely see a follow-up request for U+2023 (‣), or the other bullets, or the heart or fleuron or ballot-mark characters. So while I’m proposing this feature and could really use it, I’m not whole-heartedly advocating it. I can still make a case that it’s useful to allow input characters that do not have other meanings within AsciiDoc: i.e., I’m not proposing that “ —Joel |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Administrator
2681 posts
|
Joel, I read the discussion on the commonmark list. It's clear to me that both sides have good arguments. If we do add another unordered list marker, then I would say we would only add the bullet character (unicode U+2022) and not others. The reason is, U+2022 seems to be the only character being requested and it's primary purpose seems to be for designating list items (for as much as you can read into the Unicode specification :)) Understand that the downside of supporting U+2022 for lists is the matching overhead that's incurred. Because of the rules of the AsciiDoc syntax, the list item regex {1} has to be run on nearly every line in the AsciiDoc document (except for preformatted regions). If we determine the overhead is minimal (or, even better, negligible), then we can consider adding this character. Can you file an issue report {2} so we can track it? > I use U+2022 (•) because there’s an easy Windows keyboard shortcut for it (Alt+0149) I agree we could simplify a lot of the syntax (and make it more deterministic) by using dedicated unicode characters. I've started to advocate for this practice on the migration page for 1.5.0 {3} by recommending the use of curved quotes. At the same time, I recognize that typing these characters isn't yet "mainstream" and must remain an optional (call it an expert) feature for now. Cheers, -Dan On Wed, Oct 29, 2014 at 12:37 PM, jcsalomon [via Asciidoctor :: Discussion] <[hidden email]> wrote:
... [show rest of quote] Dan Allen | http://google.com/profiles/dan.j.allen |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
6 posts
|
Filed as asciidoctor/asciidoctor#1177, including a suggested implementation. —Joel |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Administrator
2681 posts
|
Thanks Joel! -Dan On Mon, Nov 3, 2014 at 2:10 PM, jcsalomon [via Asciidoctor :: Discussion] <[hidden email]> wrote:
... [show rest of quote] Dan Allen | http://google.com/profiles/dan.j.allen |
Free forum by Nabble | Edit this page |