Hacker News Reader

Comment by decasia | Hacker News Reader

OK I have to say I have never thought about what should happen if you try to select a sequence of text that mixes rtl and ltr languages. It's deeply in my mental zone of "undefined behavior, I don't even have an intuition about what to do."

One of the more fun programming projects I ever worked on was a custom text editor. Mainly it supported rich annotations that could be applied to any chosen term or stretch of text. It used Mobiledoc[1] which already provided pretty well-developed primitives for rich text editing on the web, and it was still a complicated project, even with a solid framework.

[1] https://github.com/bustle/mobiledoc-kit

View on HN

> I have never thought about what should happen if you try to select a sequence of text that mixes rtl and ltr languages.

I would expect it to go all the same direction across the text, regardless of which are rtl and ltr characters. If swiping left to right, ltrs would be selected forward, and rtls would be selected backwards (the same as if you just swiped ltrs from right to left).

Same here. In the same way as if I were to physically cut text from a piece of paper using scissors, I’d expect a visually contiguous region to be selected for copy/cut/paste (both when using mouse and keyboard). Even though that might not be a contiguous part of the text buffer, nor a contiguous part of how the words would be spoken, I think that behavior is least confusing.

With why would you expect tthis instead of semantic selection? After all, you don't select for visual fun, but to do something with the text, like copy& paste it, so where would you need to select words in their logical order in ltr and illogical order in rtl?

I tried to write "Hello" on the demo page on my mobile phone, but it rendered "elloH". After hitting the H, the caret went back to the start of the line and then acted normal (stayed after each of the other letters).

Edit: video - https://we.tl/t-hAWomZ9DvT

Reply on news.ycombinator.com