There's much much more to BiDi in terminals than just applying the Unicode BiDi algorithm. For example, if you unconditionally apply the BiDi algorithm on contents, it becomes literally impossible to have proper BiDi-aware text editing experience on that platform.

Resurrecting this thread years later. The issue is still present with current master, using the libs from Ubuntu Cosmic (e.g. eina-1.20.7).

Thanks a lot, it's great to see this feature slowly gaining some popularity.

Geez, that was quick :) Cool!

Thanks for the long response. The fact that you took time to write such a long reply suggests that you probably got offended by my last comment, I'm terribly sorry if that's the case, please rest assured that by no means did I mean to hurt you or criticize the work you're doing, I'm sorry if it went wrong. I purely wanted to express my different opinion while accepting your decision. And indeed, you have many todo items that are more important than this one. Please keep up the good work, and thanks for creating Terminology at the first place :)

Please allow me to put my 2 cents in this.

In the mean time I'm wondering whether mouse stuff should really belong directly to Termpty, rather than to Termstate.

infocmp gives me \177. I have no clue if it's because of an older terminfo, or a distro patch.

I have eina 1.7, I realized that a different code is executed with 1.8, so I changed the conditional (termpty.c:225) to use the first branch, and changed eina_unicode_utf8_next_get() to eina_unicode_utf8_get_next() to make it compile. I couldn't figure out if e…u…u…next_get() and e…u…u…get_next() are the same or not. Now the bug is gone, but studying the code reveals further issues.

Here's a screenshot of mc, you'll often (1 out of 10, or so) get similar result if you resize mc to a bit larger than the default window size.

i would argue that any combinations hat do not have already combined versions in unicode are "not valid". :)

it needs a table of all possible modifier chars and resulting unicode "combined" versions

Fyi: it's also valid to put multiple combining accents over a letter (perhaps with a reasonable safety cap of 10 or so). I'm not sure how xterm and others implement it without significantly increasing memory usage. Gnome-terminal (vte) keeps only one Unicode codepoint per character cell, and starts building up a "palette" mapping unused Unicode code points (above U+1fffff) to sequences of base letter + combining accents, e.g. it says that from now on U+200000 means "a" followed by a U+20D7. Yup strictly speaking it can run out of free slots after a while, and I don't think it ever free()s the sequences that are no longer used, but it works quite well in practice.