Xterm.js: Unicode-Handhabung in xterm.js

Ich denke, so etwas könnte zugänglicher sein:

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

Mit so etwas wie einem UnicodeProviderFactory.v11 wäre es beim Codieren etwas schöner, aber das macht für mich so oder so Sinn.

@dnfield Ja, so oder so wird funktionieren. Ich bin mir jedoch nicht sicher, ob wir die Typinformationen auf Versionsebene benötigen.

Meine Idee war es, eine Schnittstelle zu erstellen, die die Versionswechsel zur Laufzeit transparent wie folgt durchführen kann:

// 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(...)

Auf diese Weise kann this.unicodeProvider herumgetragen werden, ohne dass es nach einem Versionswechsel neu angefügt werden muss oder eine kostspielige Eigenschaft auf der Terminalinstanz verwendet wird.

Was ich aus der Diskussion in #1707 bekomme:

• Wir wollen vorerst zwei wcwidth-Tabellenversionen ausliefern, die alte und die neue von @dnfield.
• Mehrdeutige Zeichen sind die Mühe nicht wert, wie @gnachman betonte. Sie werden von den meisten Apps in halber Breite behandelt, also können wir dasselbe tun (bereits in der Legacy-Tabelle, muss mit der neuen Tabelle getestet werden).
• Erstellen Sie eine neue globale Option für die Unicode-Version. Die Option müsste von Integratoren eingestellt oder Benutzern für Laufzeitänderungen angeboten werden.
• Verschieben Sie die Erstellung einer neuen Escape-Sequenz, um die Unicode-Version festzulegen, da eine Schnittstelle zum Registrieren von Nicht-Standard-Sequenzen noch nicht eingerichtet ist.
• Vorerst kein magischer Unicode-Versionsratgeber. Sobald wir in Zukunft ein solches Tool erstellen, wäre es sowieso außerhalb von xterm.js (vielleicht könnte es als separates Paket in der Org existieren).
• In Zukunft müssen wir möglicherweise Unicode-Addons entwickeln, um die Paketgröße von xterm,js klein zu halten.

Irgendwelche Abnehmer, um das in den TS-Code zu bekommen?

Hatte eine erste mögliche Inkarnation in #1714. Habe die neue Tabelle von #1707 kopiert, hoffe das ist ok (@dnfield).

Kein Problem!

https://github.com/xtermjs/xterm.js/pull/1714 ist dafür eine gute Referenz, aber es ist geplant, mehrere Addons nach dem neuen Addon-Modell auszuliefern (https://github.com/xtermjs/xterm. js/issues/1128) ist, dann lassen Sie den Einbetter die richtige Version auswählen.

Bitte beheben Sie so schnell wie möglich, die Aktualisierung von Windows schien dies kürzlich für mich zu brechen. Ich versuche, eine Node.js-Bibliothek zu unterstützen, die einige Aspekte der Protokollierung für eine einfachere Lesbarkeit emojiisiert (es klingt viel doofer als es ist).

Neuer Versuch in https://github.com/xtermjs/xterm.js/pull/2568 , hoffentlich können wir dies mit der nächsten Version einführen.

@jerch können wir das als geschlossen bezeichnen, wenn # 2568 zusammengeführt wird?

@Tyriar Yepp, es gibt auch schon ein Follow-up :smile_cat: --> #2668