Xterm.js: Gestion Unicode dans xterm.js

Je pense que quelque chose comme ça pourrait être plus accessible:

interface IUnicodeProvider {
  getVersion(): string;
  wcwidth(ucs: number): number;
  getStringCellWidth(s: string): number;
  ... // more to come with support of other unicode features
}

Avec quelque chose comme un UnicodeProviderFactory.v11 serait un peu plus agréable au moment du codage, mais cela a du sens pour moi de toute façon.

@dnfield Ouais dans les deux cas, cela fonctionnera. Je ne sais pas si nous aurons besoin des informations de type au niveau de la version.

Mon idée était de créer une interface, qui peut faire de manière transparente les changements de version au moment de l'exécution comme ceci :

// terminal ctor - create the provider
this.unicodeProvider = new UnicodeProvider();
...
// some code that knows whether to switch unicode versions
this.unicodeProvider.setVersion(xy);
...
// some unicode consumer - does not care about versions at all, just gets the right method
this.unicodeProvider.wcwidth(...)

De cette façon, this.unicodeProvider peut être transporté sans qu'il soit nécessaire de le rattacher après un changement de version ou d'utiliser une propriété coûteuse sur l'instance du terminal.

Ce que j'obtiens de la discussion au #1707 :

• Nous voulons livrer deux versions de table wcwidth pour l'instant, l'ancienne et la nouvelle créée par @dnfield.
• Les caractères ambigus ne valent pas la peine, comme l'a souligné @gnachman . Ils sont gérés à mi-largeur par la plupart des applications, nous pouvons donc faire de même (déjà fait dans l'ancienne table, doit être testé avec la nouvelle table).
• Créez une nouvelle option globale pour la version unicode. L'option devrait être définie par les intégrateurs ou proposée aux utilisateurs pour les modifications d'exécution.
• Différer la création d'une nouvelle séquence d'échappement pour définir la version unicode, car une interface pour enregistrer les séquences non standard n'est pas encore établie.
• Pas de devineur magique de version unicode pour le moment. Une fois que nous ferons un tel outil à l'avenir, il sera de toute façon en dehors de xterm.js (peut-être qu'il pourrait vivre dans l'organisation en tant que package séparé).
• À l'avenir, nous devrons peut-être proposer des modules complémentaires Unicode pour maintenir la taille du package de xterm,js petite.

Des preneurs pour intégrer cela dans le code TS?

A fait une première incarnation possible en #1714. Copié le nouveau tableau à partir de # 1707, j'espère que ça va (@dnfield).

Aucun problème!

https://github.com/xtermjs/xterm.js/pull/1714 est une bonne référence pour cela, mais le plan est d'expédier plusieurs addons après le nouveau modèle d'addon (https://github.com/xtermjs/xterm. js/issues/1128) se trouve, puis laissez l'intégrateur choisir la bonne version.

Veuillez corriger dès que possible, la mise à jour de Windows a récemment semblé casser cela pour moi. J'essaie de prendre en charge une bibliothèque Node.js qui emoji'fie certains aspects de la journalisation pour une lisibilité plus facile (cela semble beaucoup plus maladroit qu'il ne l'est).

Nouvelle tentative dans https://github.com/xtermjs/xterm.js/pull/2568 , j'espère que nous pourrons le déployer avec la prochaine version.

@jerch pouvons-nous appeler cela fermé avec la fusion de # 2568 ?

@Tyriar Yepp, il y a aussi déjà un suivi :smile_cat: --> #2668