[do_not_redeem]

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]

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]

> 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]

> 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/da...

[rune-space]

Which makes one wonder why REST puts so much weight on them being divided by WS!

[lifthrasiir]

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]

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.