Xterm.js: Manejo de Unicode en xterm.js

Creo que algo como esto podría ser más accesible:

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

Con algo como UnicodeProviderFactory.v11 sería un poco mejor en el momento de la codificación, pero esto tiene sentido para mí de cualquier manera.

@dnfield Sí, de cualquier manera funcionará. Sin embargo, no estoy seguro de si necesitaremos la información de tipo en el nivel de versión.

Mi idea era crear una interfaz que pudiera cambiar de forma transparente la versión en tiempo de ejecución de esta manera:

// 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 esta manera this.unicodeProvider puede transportarse sin necesidad de volver a adjuntarlo después de un cambio de versión o usar una propiedad costosa en la instancia de la terminal.

Lo que obtengo de la discusión en # 1707:

• Queremos entregar dos versiones de la tabla wcwidth por ahora, la anterior y la nueva creada por @dnfield.
• Los caracteres ambiguos no valen la pena, como señaló @gnachman . La mayoría de las aplicaciones los manejan a la mitad del ancho, por lo que podemos hacer lo mismo (ya se hizo en la tabla heredada, debe probarse con la nueva tabla).
• Cree una nueva opción global para la versión Unicode. Los integradores tendrían que establecer la opción u ofrecerla a los usuarios para cambios en el tiempo de ejecución.
• Posponer la creación de una nueva secuencia de escape para configurar la versión Unicode, ya que aún no se ha establecido una interfaz para registrar secuencias no estándar.
• No hay adivinanzas mágicas de la versión Unicode por ahora. Una vez que hagamos una herramienta de este tipo en el futuro, estaría fuera de xterm.js de todos modos (tal vez podría vivir en la organización como un paquete separado).
• En el futuro, es posible que tengamos que crear complementos Unicode para mantener pequeño el tamaño del paquete de xterm,js.

¿Algún interesado en convertir eso en código TS?

Hizo una primera encarnación posible en el #1714. Copié la nueva tabla desde el n. ° 1707, espero que esté bien (@dnfield).

¡No hay problema!

https://github.com/xtermjs/xterm.js/pull/1714 es una buena referencia para esto, pero el plan es enviar varios complementos después del nuevo modelo de complemento (https://github.com/xtermjs/xterm. js/issues/1128), luego permita que el integrador elija la versión correcta.

Solucione lo antes posible, la actualización de Windows recientemente pareció romper esto para mí. Estoy intentando admitir una biblioteca Node.js que emoji'fie algunos aspectos del registro para facilitar la lectura (suena mucho más tonto de lo que es).

Nuevo intento en https://github.com/xtermjs/xterm.js/pull/2568 , con suerte podemos implementar esto con el próximo lanzamiento.

@jerch , ¿podemos llamar a esto cerrado con la fusión de #2568?

@Tyriar Yepp, ya hay un seguimiento :smile_cat: --> #2668