Hi Gregg,
I am not an Emacs developer, and I don't plan to work on this issue right now. I also don't believe that you have brought up new arguments to change the decisions about how this is to done in Emacs in the future. I do think that an occasional check of these ideas is a good thing, though. So this exchange is mostly about: "Would I personally find useful software that worked along the lines hat you suggest." Gregg Reynolds writes: > Two things. One is, directionality a design choice, not a > reflection of some kind of objective reality. The fact that Arabic and other scripts are written and read from right to left is a design feature of the script that we can't just ignore when we implement it in computers, we have to deal with it at some level. The question is at *which* level. > There is no necessary relationship between the IO model implemented > by an application and the corresponding textual representation, Exactly. Which is why Unicode put the complicated parts into the IO model (for human IO) with BIDI reordering, while any software module that doesn't have human IO can completely ignore the issue. The same goes for most software that directly implements human IO but uses pre-fabricated building blocks for it (using e.g. GTK or Qt). If OTOH you use visual ordering in the encoding you make life easier for a few primitive versions of the IO and complicated for all the rest of the software. Not to mention that it makes it even more complicated for more advanced - read: user-friendly - versions of IO. There is a third possibility in our case, using visual order within Emacs and only storing the text in logical order. That is possible in a simple text editor (and I am sure there are some of those around). But Emacs does a lot more, of course. Every module in Emacs that needs to look at the logical order would have to make the reordering anyway. And as Emacs is about text processing that would probably be a lot of modules. That's the choice. I personally prefer the first way of doing it. > More important is that RTL has no necessary relationship to mixed > content or bidi reordering. If you only ever write documents in > Arabic (Hebrew, Persian, Pashto, whatever) then why do you need > bidi? A large part (maybe still a majority) of the people that write Arabic and Hebrew on computers write in more than just one language. This is even if you discount numbers and trademarks. > To be clear: monolingual Arabic text is not mixed content, whether > it contains digit strings or not. So why should an Arabic user pay > the Unicode tax of bidi support? A large part of the user base right now does need mixed content. So you would get the tax of supporting several versions of software, the software for people that don't need mixed content and another version for people that do. Even if the first version on its own might be cheaper, on the whole this will get more costly. Not to mention that it would end up in a system where the "natives" get the "stupid" mono-lingual software and the "experts" and the westerners can afford the "intelligent" software for the mixed content. benny _______________________________________________ emacs-bidi mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-bidi
