Xterm.js: Problème avec les emojis / unicode (supposé double largeur?)

Je ne peux pas reproduire cela sur macOS / bash. Je ne m'attendrais pas à ce que cela se produise à moins que nous n'essayions de modifier la largeur de l'emoji (la rendre non-1). Des détails supplémentaires sur les étapes de repro seraient utiles.

Reproduire (OSX, MacOS High Sierra)

• démarrer la démo v3
• coller 😀 plusieurs fois
• appuyez sur la touche fléchée gauche plusieurs fois, voyez comment il saute deux cellules à chaque fois et se heurte aux limites de la cellule.

Êtes-vous déjà sur MacOS High Sierra, parce que je le suis? Peut-être que c'est aussi lié à node-pty - je peux voir que lors de l'insertion d'un emoji dans Terminal.app il ajoute automatiquement un espace après l'emoji, et encore plus, je ne peux pas sélectionner cet espace, c'est comme si High Sierra menacerait en tant que caractère double largeur ...

Terminal.app sur MacOS High Sierra

Cela pourrait être une chose de haute sierra où ils ont essayé de rendre les Emojis meilleurs dans le terminal? Je ne peux pas mettre à jour actuellement car cela gâche le rendu dans les applications Electron.

Je déteste dire que j'ai mis à niveau et maintenant je suis coincé avec des tonnes de problèmes de rendu dans toutes ces applications à base de chrome 😤

Oui, j'ai pris soin de suivre les commentaires avant de mettre à jour car des choses similaires se sont produites avec Sierra, je pense.

Je remarque que Terminal.app a une belle expérience emoji où ils sont traités comme des caractères larges appropriés, nous pouvons probablement le faire s'ils le peuvent 😄

UAX # 11 East Asian Width, la révision 31 a changé l'emoji _East Asian Wide_ (double largeur) et wcswidth dans wchar.h renvoie la largeur des chaînes. Je suppose que macOS High Sierra aurait pris en charge la mise à jour.
Le wcwidth xterm.js dans src/CharWidth.ts ne l'a pas encore pris en charge.

@ mandel59 merci pour l'info!

@ mandel59 Je pense que ce problème est spécifique aux emoji, je pense que les caractères CJK doivent être correctement catégorisés en tant que caractères à double largeur (certains composants peuvent être cassés comme https://github.com/xtermjs/xterm.js/issues/1387)

Référence: https://github.com/gnachman/iTerm2/blob/master/sources/NSCharacterSet+iTerm.m propose également des solutions de cartographie.

Problème de code VS: https://github.com/Microsoft/vscode/issues/59145

Apparemment, la course de flutter démontre ce comportement

Voici une petite repro de Dart pour ce que nous voyons qui ne nécessite pas Flutter (nécessite Dart cependant):

import 'dart:async';

import 'dart:io';

// Windows console font has a limited set of Unicode characters.
final _animation = Platform.isWindows
    ? <String>[r'-', r'\', r'|', r'/']
    : <String>['🌕', '🌖', '🌗', '🌘', '🌑', '🌒', '🌓', '🌔'];
final _backspace = '\b' * _animation[0].length;

main() {
  int ticks = 0;
  void update(Timer timer) {
    if (ticks % 50 == 0) {
      stdout.write('\nDoing thing... ');
    }
    stdout.write('$_backspace${_animation[ticks++ % _animation.length]}');
  }

  new Timer.periodic(const Duration(milliseconds: 100), update);
}

Enregistrez en tant que fichier .dart , puis exécutez-le avec dart xxx.dart . Ce code émet ici deux backspaces pour ce caractère, qui dans un terminal macOS standard supprime correctement le caractère. Cependant, dans le terminal VS Code, il effectuera un retour arrière de l'emoji, puis d'un autre caractère. Si l'emoji était au début de la ligne, cela ne fait rien, mais si ce n'est pas le cas, le rendu se glisse lentement vers la gauche par un caractère (et laisse la moitié droite de l'icône après lui).

Si vous supprimez le * _animation[0].length de l'espace arrière pour qu'il fasse toujours un seul retour arrière, cela fonctionne bien dans le terminal VS Code, mais il n'y a plus assez d'espaces arrière dans le terminal macOS (donc les lunes rampent vers la droite !).

S'applique également à l'hébreu / arabe comme mentionné dans https://github.com/Microsoft/vscode/issues/60470

VSCode 1.31.1 sur Ubuntu 18.04 rencontre ce problème.

Lorsque vous faites défiler l'historique de vos commandes vers le haut ou vers le bas avec les touches fléchées, les artefacts sont capturés de telle sorte que lorsque vous arrivez à une commande que vous souhaitez exécuter, il y a de fortes chances qu'elle soit illisible.

De plus, après avoir récupéré un artefact, la modification de la commande est boguée, car ce qui est affiché est différent de ce qui est en mémoire dans xterm.

Pas:

Ajout d'un emoji à mon invite:

Appuyez une fois sur la flèche vers le haut pour accéder à la commande npm i

Remarquez l'escroc n qui a été ajouté à l'invite.

Supprimez l'emoji de l'invite dans .bashrc et rechargez le terme et le bogue disparaît.

Tout d'abord, je voulais vous remercier pour votre travail incroyable.

VSCode 1.31.1 sur macOS Mojave 10.14.3 connaît la même chose. La chose n mentionnée par @juliusecker m'arrive aussi, exactement comme il l'a décrite.

J'ai le même bug que celui mentionné par @juliusecker.
VSCode Version 1.33.1 (1.33.1) 51b0b28134d51361cf996d2f0a1c698247aeabd8 2019-04-11T08: 14: 39.158Z
Version du système: macOS 10.14.4 (18E226)
zsh 5.7.1 (x86_64-pomme-darwin17.7.0)

Très simple à reproduire en VSCode et Powershell.

emojiterminaltest.ps1

"Emoji Normal"
"😊1😊2😊3😊4"
"Emoji with Padding Spaces - What it should look like"
"😊  1😊  2😊  3😊  4"

Y a-t-il des ressources affectées à cet élément? On dirait que beaucoup de régressions dans d'autres programmes (Hyper, etc.) comme on le voit sur ce fil de discussion.

@jerch est-ce un double de https://github.com/xtermjs/xterm.js/issues/1709?

@Tyriar Oui un peu, c'est juste un exemple où les gens vont probablement y faire face - emojis: smile_cat:

Je suppose que nous allons les garder tous les deux ouverts car cela décrit bien le problème et # 1709 examine davantage la solution, en plus celui-ci a un tas de votes positifs.

Il est réplicable dans Windows 10, la version suivante:

Ce qui précède est ce que je vois dans un terminal intégré de code VS,

ce qui précède est ce que je vois lorsque le même texte dans un fichier texte ouvert en code VS.

Le problème remonte à près de deux ans, une mise à jour?

@jerch veut y arriver bientôt, il a cependant un tas de trucs en cours. L'un des gros obstacles à cela était le nouveau système d'addon qui est maintenant publié.

Clôture en faveur de https://github.com/xtermjs/xterm.js/issues/1709 car ils sont essentiellement la même chose et nous voulons garder notre compte à rebours.