Xterm.js: Prise en charge des langues RTL

C'est en fait beaucoup plus compliqué et comprend l'état et même la mise en miroir de certains personnages. Je dirais que c'est une science à part entière. (Et j'ai le plus profond respect pour les personnes qui ont écrit des bibliothèques de rendu de texte robustes qui gèrent correctement tous les problèmes de BiDi, donc je n'ai pas à m'embrouiller avec ça, pour être honnête.)

Voir également:
https://en.wikipedia.org/wiki/Bi-directionnel_text (bon aperçu)
https://www.w3.org/International/articles/inline-bidi-markup/uba-basics
https://www.w3.org/International/tutorials/svg-tiny-bidi/ (le postulat initial n'est pas lié mais il explique certaines choses mieux que le lien précédent)
https://github.com/fevangelou/doctype-mirror/tree/master/bidihowto/bidi-support-in-a-ui

EDIT : Je pense que le fonctionnement de la nouvelle sélection peut en fait être inattendu car il va se comporter différemment de VSCode lui-même. Par exemple, étant donné le texte « La chanson מדינת קומבינה me fait réfléchir », lorsque je commence à sélectionner à « La » et termine entre les deux mots hébreux, j'aurai sélectionné « La chanson מדינת », alors que dans la console j'aurai sélectionné "La chanson ".

Voir exemple :

Cependant, ce sera toujours mieux que la façon dont Sublime Text "fonctionne" la dernière fois que j'ai vérifié, car vous y verrez une chose sélectionnée mais en copierez une autre, ce qui est très ennuyeux.

@Tyriar
Tout d'abord, je vais vous donner une très brève perspective de la langue arabe et persane, peut-être que cela vous aidera (je ne sais pas si l'hébreu est le même).
Dans les langues arabe et persane, les alphabets sont comme "آ" "ب" "س" et ainsi de suite. Et les mots sont faits par ces alphabets (évidemment) avec une règle très différente par rapport à l'anglais par exemple.
La différence est que nous avons plus d'une forme pour certains alphabets comme "س". La première forme est "س" et la seconde est " سـ ", l'autre est " " et la dernière est " ـس ". Et à quoi servent ces formes ? En fonction de l'endroit où l'alphabet dans un mot apparaît, la forme de l'alphabet que nous utilisons varie. Par exemple, pour l'alphabet mentionné "س", nous utilisons la forme "سـ" lorsqu'un mot commence par cet alphabet comme "سلام". Voici le problème et en fait la différence entre une langue comme l'anglais et le persan ou l'arabe. Nous générons des mots dans ces langues en enchaînant les différentes formes de ces alphabets (nous les assemblons dans certains cas). Encore une fois, je souligne cette règle : nous générons ces mots en concassant les formes et non les alphabets (ce qui est toujours la concaténation des alphabets en anglais), vous pouvez voir quelques exemples ci-dessous :
nous avons des alphabets "ک" "ن" "ا" "د" "ی"
Je fais ces mots par les alphabets juste mentionnés : نادان , یاد,دکان
Donc, pour conclure et vous donner une idée de ce qui s'est passé dans les captures d'écran que j'ai postées, le terminal décompose les mots en alphabets et les inverse. (Il ne s'agit donc pas seulement d'inverser). Jetez un œil aux mots que j'ai créés et aux alphabets que j'ai mentionnés auparavant. Maintenant, le terminal VS les montre "séparés" et "inversés".

Format correct : نادان Terminal : ن ا د ا ن
Format correct : یاد Terminal : د ا ی
Format correct : دکان Terminal : ن ا ک د

Maintenant tes questions :
Où les chaînes doivent-elles être inversées. Pour l'hébreu/arabe/persan, dois-je inverser des séquences continues entières de caractères entre les caractères ascii ?
Je n'ai aucune idée de l'hébreu, mais en arabe et en persan, les séquences de caractères devraient basculer lorsqu'elles rencontrent un caractère espace (le séparateur de mots est un espace) comme ceci :" من در حال نوشتن هستم" mais il devrait quand même garder le "formes" et l'adhérence nécessaire.

Comment les caractères sont-ils censés interagir avec des caractères comme 0-9 ou la ponctuation ?
À propos des chiffres et de la ponctuation, les règles sont les mêmes qu'en anglais et les chiffres et les signes de ponctuation suivent les caractères. comme ça:
? ال " " ا .
ال "1369" ا آمدم.
En fait, une séquence de caractères contenant des caractères RTL et non RTL est une toute autre histoire et si vous avez besoin de plus d'informations, je peux développer cela.

PS 1 :
Ce lien ici est un code source qui est écrit pour résoudre le même problème en PHP (bien sûr les anciennes versions) vous pouvez jeter un oeil
https://github.com/slashmili/php-gd-persian/blob/master/phpgd/fagd.php

PS 2:
Voici une ressource sur wikipedia sur les caractères persans
https://en.wikipedia.org/wiki/Persian_alphabet

PS 3:
Encore une fois, je dois mentionner que dans la version précédente de VS Code, tout allait bien.

PS 4:
À propos du problème de sélection d'un mot contenant un caractère LTR comme
<p>اینجا را بخوانید</p> que @CherryDT a mentionné, il y a quelques bugs mineurs avec lesquels je n'ai pas de problème et j'ai trouvé des solutions rapides pour eux. (Mais si vous avez besoin d'explications à ce sujet, faites-le moi savoir)

Après avoir mis à jour mon vscode, tout est inversé, c'est très mauvais, veuillez résoudre ce problème
Je veux rétrograder, la version Witch est OK ?

@mostafa69d assez heureusement en hébreu qui existe à peine. Les lettres hébraïques restent pour la plupart les mêmes dans n'importe quelle position à l'intérieur d'un mot, à part quelques lettres qui sont כ qui se transforme en ך, puis מ qui se transforme en , puis נ qui se transforme en , puis פ qui se transforme en ף et enfin צ qui se transforme en . Cela rend l'hébreu plus facile à formater, je suppose.

Cependant, ce sont toujours des caractères séparés (en termes d'encodage de caractères) et affichent toujours les mêmes. Ils ne changent pas d'apparence lorsqu'ils sont déplacés. (C'est le travail de l'écrivain d'utiliser la bonne lettre - sofit ou non - à la bonne position.)

Le problème avec les caractères de fractionnement est que lorsqu'ils sont enveloppés dans une étendue un par un, il faudra une connexion et il manquera de représenter la forme (lettres arabes).

Pour résoudre le problème, ces caractères doivent être dans une plage ou ne pas les envelopper du tout.

La liste de l'unicode toutes ces lettres sont
Arabe (0600–06FF, 255 caractères)
Supplément arabe (0750–077F, 48 caractères)
Arabe étendu-A (08A0–08FF, 73 caractères)
Formes de présentation en arabe-A (FB50-FDFF, 611 caractères)
Formulaires de présentation en arabe-B (FE70–FEFF, 141 caractères)
Symboles numériques Rumi (10E60–10E7F, 31 caractères)
Symboles alphabétiques mathématiques arabes (1EE00—1EEFF, 143 caractères)

lecture obligatoire : https://opensource.com/life/16/3/twisted-road-right-left-language-support

de https://github.com/Microsoft/vscode/issues/28571#issuecomment -307991443

avez-vous un exemple d'un autre terminal qui gère bien cela?

mlterm semble être meilleur que le terminal moyen (non basé sur le Web).

Il est cursif mais dans certains cas coupé, je pense que cela peut être résolu en changeant la police, ce paragraphe a été copié de Wikipedia, les caractères bleus sont la marque RTL, c'est ainsi que vim les affiche et mlterm les rend en bleu.

L'API de menuiserie de caractères pourrait être en mesure de résoudre ce problème, nous pourrions probablement créer tous les éléments adjacents en arabe/hébreu/etc. les caractères Unicode se joignent et sont dessinés dans le même glyphe.

Pour ce que ça vaut, la console de débogage fonctionne bien avec les textes RTL. Voilà ce que j'ai essayé :

Et voici la sortie sur la console de débogage :

Mais le terminal est toujours le même :

J'utilise VS Code - Insiders v1.31.0.

@babakks Pour autant que je sache, seuls deux terminaux du système Linux peuvent générer correctement RTL, konsole et mlterm , ils sont disponibles dans toutes les distributions.

@elieobeid7 @babakks Le terminal Mac OS

Émettez un PR pour résoudre ce problème, si quelqu'un veut tester la branche qui serait utile car je ne parle pas ces langues. https://github.com/xtermjs/xterm.js/pull/1899

Tester:

git clone https://github.com/Tyriar/xterm.js
cd xterm.js
git checkout 701_rtl_support
yarn
yarn watch

# another terminals
yarn start

Vous devrez peut-être installer certaines dépendances https://github.com/Microsoft/node-pty#dependencies

Veuillez patienter un peu :)

J'ai récemment travaillé sur l'étude, l'évaluation de la documentation existante et des implémentations de RTL dans les terminaux, et j'ai proposé une (ébauche) de recommandation. Je vais le sortir très bientôt maintenant.

C'est bien plus compliqué qu'on ne le pense au premier abord. Un peu de spoil : si vous commencez à mélanger les caractères selon l'algorithme BiDi, il devient littéralement, mathématiquement impossible d'avoir une expérience d'édition et de visualisation de texte compatible avec BiDi (par exemple, vim, emacs...) sur cette plate-forme . (Et pour répondre aux quelques commentaires précédents : non, konsole, mlterm et macOS Terminal ne font pas les choses correctement non plus.)

@egmontkob est-ce que cela prend en compte le fait que nous pouvons tirer parti de la prise en charge bidi du navigateur ? Tout ce que ma modification fait, c'est de forcer les séquences Unicode liées à être rassemblées et non comme des caractères séparés. C'est probablement faux lorsque le curseur est sur le caractère, mais cela semble fonctionner autrement.

@Tyriar Désolé Tyriar, mais c'est toujours faux. J'ai commenté sous la pull request.
https://github.com/xtermjs/xterm.js/pull/1899#issuecomment -455333377

La spécification définit à quoi doit ressembler le canevas, après avoir reçu des données. La spécification ne se soucie pas de ce qu'est le backend de l'émulateur de terminal (par exemple un canevas graphique, ou un navigateur (HTML DOM), ou un autre émulateur de terminal (tmux)), c'est la tâche de l'émulateur de terminal d'implémenter le comportement spécifié par quelque moyen que ce soit .

Et un aspect du comportement spécifié est que dans certaines circonstances, les cellules de caractères doivent être mélangées selon l'algorithme BiDi (à des fins d'affichage uniquement, sans affecter le stockage réel), car c'est le seul moyen raisonnable d'obtenir des utilitaires simples comme "cat " produire le résultat souhaité ; et dans d'autres circonstances, les cellules ne doivent pas être réorganisées, car c'est la seule façon pour vim/emacs/quiconque de faire leur propre BiDi. Il existe des séquences d'échappement contrôlant ce comportement. Et l'histoire est bien plus que cela.

Veuillez consulter le projet de spécification BiDi publié sur https://terminal-wg.pages.freedesktop.org/bidi/ . Les commentaires, idées d'amélioration, etc. sont les bienvenus là-bas dans son outil de suivi des problèmes.