4 ms·

What do you mean not designed for Korean? It's just unicode. If there's some situation where RST isn't parsing inline markup, you can write the role explicitly

What do you mean not designed for Korean? It's just unicode. If there's some situation where RST isn't parsing inline markup, you can write the role explicitly like this: this is **bold** text this is :strong:`bold` text

rune-space 1y ago
But you can’t say: thisis:strong:`bold`text Whereas the equivalent is perfectly fine in markdown. Falsehoods programmers believe about written language: whitespace is used to separate atomic sequences of runes.
- thaumasiotes 1y ago
  > Falsehoods programmers believe about written language: whitespace is used to separate atomic sequences of runes. Really? That isn't just untrue of written language in general. It's untrue of every individual written language in specific. You can't even clearly define what an "atomic sequence of glyphs" is.
  - matja 1y ago
    > You can't even clearly define what an "atomic sequence of glyphs" is. Kinda. Grapheme cluster breaks are defined in Unicode, but they have all the baggage and edge-cases you'd expect from human languages evolving over time, so they can be encoded in as a few as a thousand rules : https://github.com/unicode-org/icu/tree/main/icu4c/source/data/brkitr/rules https://github.com/unicode-org/icu/tree/main/icu4c/source/da...
  - rune-space 1y ago
    Which makes one wonder why REST puts so much weight on them being divided by WS!
lifthrasiir 1y ago
reST inline syntaxes are pretty much word-based, which doesn't work very well with agglutinative languages. For example if you want to apply a markup to "이 페이지" in "이 페이지는 ..." (lit. This page in This page is ...), you need to do `*이 페이지*\ 는 ...` AFAIK. That would happen every single time affixes are used, and affixes are extremely frequent in such languages.
- do_not_redeem 1y ago
  Oh I see, you're talking about this: thisis\ **bold**\ text thisis\ :strong:`bold`\ text It's possible, but you're right, definitely more awkward than markdown.

rune-space 1y ago

But you can’t say: thisis:strong:`bold`text Whereas the equivalent is perfectly fine in markdown. Falsehoods programmers believe about written language: whitespace is used to separate atomic sequences of runes.

thaumasiotes 1y ago
> Falsehoods programmers believe about written language: whitespace is used to separate atomic sequences of runes. Really? That isn't just untrue of written language in general. It's untrue of every individual written language in specific. You can't even clearly define what an "atomic sequence of glyphs" is.
- matja 1y ago
  > You can't even clearly define what an "atomic sequence of glyphs" is. Kinda. Grapheme cluster breaks are defined in Unicode, but they have all the baggage and edge-cases you'd expect from human languages evolving over time, so they can be encoded in as a few as a thousand rules : https://github.com/unicode-org/icu/tree/main/icu4c/source/data/brkitr/rules https://github.com/unicode-org/icu/tree/main/icu4c/source/da...
- rune-space 1y ago
  Which makes one wonder why REST puts so much weight on them being divided by WS!

lifthrasiir 1y ago

reST inline syntaxes are pretty much word-based, which doesn't work very well with agglutinative languages. For example if you want to apply a markup to "이 페이지" in "이 페이지는 ..." (lit. This page in This page is ...), you need to do `*이 페이지*\ 는 ...` AFAIK. That would happen every single time affixes are used, and affixes are extremely frequent in such languages.

do_not_redeem 1y ago
Oh I see, you're talking about this: thisis\ **bold**\ text thisis\ :strong:`bold`\ text It's possible, but you're right, definitely more awkward than markdown.