Xterm.js: zsh / oh-my-zsh - pas de défilement

Merci d'avoir signalé @wallverb. Je n'ai pas accès à zsh pour le moment, je ne peux donc pas le tester.

Pourriez-vous s'il vous plaît jeter un oeil à votre console dans les outils de développement de votre navigateur et nous fournir les erreurs / journaux qui pourraient apparaître lors d'une tentative de défilement en zsh avec oh-my-zsh?

@parisk - lorsque zsh / oh-my-zsh exécute cette commande echoti smkx les données suivantes sont envoyées à Terminal.prototype.write = function(data) :

[?1l>
xterm.js:1467 


xterm.js:1467 ]2;echoti smkx
xterm.js:1467 ]1;echoti[?1h=[1m[7m%[m[1m[m    

ce qui semble que = char est à l'origine de ceci:

 // ESC = Application Keypad (DECPAM).
              case '=':
                this.log('Serial port requested application keypad.');
                this.applicationKeypad = true;
                this.state = normal;
                break;

et puis this.applicationKeypad = true; provoque un retour dans le code de défilement:

      on(el, wheelEvent, function(ev) {
        if (self.mouseEvents) return;
        if (self.applicationKeypad) return;

@parisk , un mouvement pour résoudre ce

@richarddavenport, malheureusement, je n'ai pas eu le temps de m'occuper de cela et je ne

Ce serait extrêmement utile si nous pouvions obtenir une contribution externe à ce sujet et je peux certainement aider n'importe qui à comprendre les éléments internes de xterm.js.

@parisk J'adorerais vous aider! Y a-t-il de la documentation quelque part, ou pourriez-vous m'aider à commencer le débogage? Y a-t-il un éditeur ou un IDE qui fonctionne le mieux? VS Code / Webstorm / Chrome Dev Tools? Merci!

@richarddavenport n'importe quel éditeur fonctionne bien. Tout le code est en ./src/xterm.js et les instructions pour exécuter la démo sont ici .

@richarddavenport Je pense que @Tyriar a raison. Tout éditeur prenant en charge JavaScript fonctionne, alors n'hésitez pas à choisir celui qui vous convient le mieux.

Cependant, une opinion personnelle serait de choisir un éditeur ou un IDE qui utilise xterm.js lui-même, afin de le dogfood également (utilisez xterm.js lors du développement de xterm.js). Les deux solutions que je connais actuellement sont:

• SourceLair qui fonctionne complètement dans le navigateur; il suffit de visiter https://lair.io/sourcelair/xterm et de suivre les instructions
• Visual Studio Code , téléchargez-le, clonez le dépôt, exécutez npm install et vous êtes prêt

Le débogage avec Chrome / Firefox DevTools est le meilleur moyen d'accéder à l'OMI.

Compte tenu de la documentation, il n'y a pas de site Web public pour le moment, mais vous devriez vous y attendre dans la semaine. Jusque-là, exécutez simplement npm run build:docs dans votre terminal et vous pourrez ensuite parcourir la référence de l'API au format HTML, dans le répertoire docs .

N'hésitez pas à demander plus d'aide au cas où ce qui précède ne suffit pas.

@richarddavenport J'ai publié une version

Vous pouvez consulter http://docs.xtermjs.org/. J'espère que ça aide 😊.

Wow! C'est vraiment génial! @wallverb a raison à propos de la commande echoti smkx dans oh my zsh . Cette commande met le terminal en mode Application, ce qui (je suppose ici) est lié à la propriété applicationKeypad . Cela vous semble-t-il correct? Je n'ai aucune idée de ce qu'est le mode d'application, mais cela semble important. La ligne 1144 , si elle est commentée, tout fonctionne, mais je ne suis pas sûr des conséquences ou de la raison pour laquelle cette ligne est là. Savez-vous à quoi ça sert?

Oui, j'hésite un peu à le toucher car je ne sais pas non plus ce qu'il fait.

Ce document de référence que nous utilisons l'a mentionné ici:

Le clavier de l'application transmet les séquences d'échappement suivantes en fonction:
sur le mode spécifié via les séquences d'échappement DECKPNM et DECKPAM.
Utilisez la touche Verr Num pour remplacer le mode d'application.

Le code mentionne également:

              // ESC = Application Keypad (DECPAM).
              case '=':
                this.log('Serial port requested application keypad.');
                this.applicationKeypad = true;
                this.state = normal;
                break;

              // ESC > Normal Keypad (DECPNM).
              case '>':
                this.log('Switching back to normal keypad.');
                this.applicationKeypad = false;
                this.state = normal;
                break;

Examiner ce que DECPAM et DECPNM nous amènera probablement à une réponse. Aussi s'il y a une différence avec DEC K PAM et DEC K PNM.

Le défilement de Xterm.js avec oh my zsh fonctionne maintenant, avec cette branche

Salut. J'ai trouvé ce fil à partir du bogue associé sur Oh My Zsh.

Examiner ce que DECPAM et DECPNM nous amènera probablement à une réponse. Aussi s'il y a une différence avec DECKPAM et DECKPNM.

Je pense que DECPAM et DECPNM ne sont que des fautes de frappe pour DECKPAM et DECKPNM. Les mnémoniques sont "DEC KeyPad Application Mode" et "DEC KeyPad Normal Mode".

Les modes du clavier d'application modifient les séquences de caractères que le clavier du curseur et / ou les touches du pavé numérique envoient en réponse aux pressions sur les touches. Il existe deux (ou plus) modes de clavier distincts qui peuvent être réglés sur «application» ou «normal»: le pavé numérique et le pavé numérique du curseur. Les propriétés applicationKeypad et applicationCursor modifient les séquences envoyées par certaines clés , ce qui semble approprié.

Il me semble cependant qu'il y a peut-être un bogue avec les touches Début et Fin. Leur comportement est modifié par la propriété applicationKeypad . Mais xterm considère Home et End comme des touches de curseur, contrôlées par DECCKM au lieu de DECKPAM / DECKPNM. (Voir la section "Touches de fonction de style PC" dans ce document de référence xterm .) Je pense que cela signifie qu'elles devraient être contrôlées par applicationCursor au lieu de applicationKeypad .

Quoi qu'il en soit, je suis surpris que le mode clavier affecte le comportement de la molette de défilement de la souris. (C'est le défilement dont OP parle, n'est-ce pas?) Peut-être que le correctif est aussi simple que de supprimer ce if (self.applicationKeypad) return; chèque du gestionnaire de molette de défilement de la souris.

Je n'ai pas accès à zsh pour le moment, je ne peux donc pas le tester.

Vous pouvez tester ce comportement sous bash ou d'autres shells en faisant tput smkx . C'est équivalent au echoti de zsh. Mais sachez que dans la plupart des définitions de terminfo, smkx envoie les séquences pour les modes clavier du curseur d'application et pavé numérique d'application, donc vous ne les testez pas indépendamment si vous le faites de cette façon. Pour les tester indépendamment (par exemple, si vous vouliez vérifier quel mode contrôlait le comportement Home / End), vous auriez besoin de faire écho à ces séquences d'échappement séparément. (Je ne me souviens pas comment faire ça de ma tête.)

Je pense que c'est la même cause fondamentale que la raison pour laquelle le défilement ne fonctionne pas dans vim qui définit également DECKPAM .

Suivant les spécifications de la souris de xterm, les actions de la souris ne sont pas modifiées par DECKPAM ou DECKPNM. Est-ce que quelqu'un sait pourquoi nous avons le if (self.applicationKeypad) return; dans le gestionnaire de défilement de la souris?

@jerch ouais, je commence à penser que moi aussi, il y a un tas de lectures que je veux faire dans # 194 pour enfin résoudre ce genre de problèmes.

Je pense que j'ai d'autres commentaires à apporter ici.

Peut-être que le correctif est aussi simple que de supprimer si (self.applicationKeypad) return; vérifier à partir du gestionnaire de molette de défilement de la souris.
@apjanke cela ne fonctionnera pas et ne devrait pas fonctionner réellement. Ce gestionnaire d'événements particulier est là pour permettre le défilement dans des applications en mode texte simples comme bash, qui ont applicationKeypad défini sur false (btw. Semble assez utile pour mieux documenter cela).

De plus, même si nous supprimions cela, cela entraînerait un appel term.scrollDisp(1) , qui ne ferait rien lorsqu'une application comme vim est ouverte, où term.ydisp et term.ybase valent tous les deux 0 .

Cela devrait probablement être géré dans le gestionnaire d'événements précédent.

Le défilement de Xterm.js avec oh my zsh fonctionne maintenant, avec cette branche

@richarddavenport a- t-il fonctionné sans aucun changement sur xterm.js?

@parisk Oui, cela fonctionne sans aucune modification de xterm.js.

Peut-être que le correctif est aussi simple que de supprimer ce if (self.applicationKeypad) return; du gestionnaire de molette de défilement de la souris.
@apjanke cela ne fonctionnera pas et ne devrait pas fonctionner réellement. Ce gestionnaire d'événements particulier est là pour permettre le défilement dans des applications en mode texte simples comme bash, qui ont applicationKeypad défini sur false (btw. Semble assez utile pour mieux documenter cela).

Ce comportement ne devrait-il pas être uniquement fonction du mode de suivi de la souris, des modes d’écran alternatif et de défilement alternatif, et non des modes du clavier d’application numérique / curseur? OP utilise zsh , qui ressemble plus à bash qu'à vim : c'est une simple application de texte qui utilise l'écran principal et qui ne fournit pas son propre support de défilement, donc il s'appuie sur le terminal pour faire le défilement. Mais certains de ces programmes de texte simples, en particulier zsh , peuvent toujours activer le mode Clavier d'application afin de pouvoir effectuer une liaison de clé portable en utilisant des définitions terminfo , qui n'incluent généralement que les séquences de caractères du mode application.

@parisk Je seconde ce que dit apjanke - pourquoi les paramètres du mode clavier devraient-ils interférer du tout avec le comportement de la souris? La spécification officielle de xterm ne mentionne rien de tout cela, par conséquent, l'implémentation d'un modèle compatible xterm peut ne pas avoir une telle limitation. Peut-être que quelque chose me manque ici.
Les applications de terminal "de haut niveau" comme midnight commander enregistreront un suivi explicite de la souris - pour ceux-ci, xterm désactive simplement le gestionnaire par défaut et les événements sont gérés par l'application du terminal elle-même (ce qui peut entraîner la désactivation du défilement - cela dépend de l'application).

En outre, le commutateur d'écran alternatif (DECSET 1047) est utilisé pour indiquer un comportement de terminal différent - le tampon d'écran normal (1047 bas) est livré avec le tampon de défilement tandis que l'autre (1047 haut) n'en a pas. Ce dernier est utilisé par toutes les applications curses, vim, emacs et autres applications de terminal plus sophistiquées utilisant le terminal comme canevas (la plupart des applications reposant fortement sur terminfo). Pour ces applications, il n'y a pas de défilement du terminal. Vous pouvez le tester vous-même en exécutant vim ou emacs dans xterm - vous ne pouvez pas revenir au contenu du terminal précédent. Après la fermeture de l'application et le retour à l'interface normale du shell, le défilement du terminal est à nouveau "activé".
Techniquement, xterm maintient 2 tampons d'écran séparés pour y parvenir. Le DECSET 1047 bascule simplement entre eux.

Il existe également des applications qui font des dessins plus avancés sur l'écran normal (par exemple, homme, en haut) et n'enregistrent pas le suivi de la souris. xterm est toujours scrollable pour ceux-ci et leur contenu se trouve juste à la fin du tampon de sortie.

Quelle est la "solution de contournement" la plus simple disponible avant que cela ne soit traité d'une manière plus verbeuse?

@ksnyde, c'est probablement le plus simple: https://github.com/Microsoft/vscode/issues/7817#issuecomment -229069151. Cependant, je ne l'ai pas essayé personnellement.

c'est probablement le plus simple: Microsoft / vscode # 7817 (commentaire). Cependant, je ne l'ai pas essayé personnellement.

Malheureusement, cela cassera d'autres raccourcis clavier qui dépendent de zle_line_init . Vous pouvez ou non utiliser ces raccourcis clavier, donc cela peut ou non vous intéresser.

Il y a un OMZ PR ouvert que j'ai mis en place pour supprimer la dépendance zle_line_init / [sr]mkx et rester en mode clavier normal , et qui semble probablement accepté. Si vous l'exécutez localement ou si vous le faites voter pour qu'il soit fusionné dans la ligne principale OMZ, vous pouvez l'utiliser comme solution de contournement qui évite ce problème de défilement (en évitant complètement le mode clavier de l'application) et maintient toutes les liaisons de touches OMZ fonctionnelles.

Autrement dit, si vous utilisez Oh My Zsh. Si vous utilisez l'une des distributions Linux qui configurent zle_line_init pour utiliser [sr]mkx dans leurs fichiers de configuration système, vous devrez redéfinir zle_line_init dans votre propre ~/.zshrc config comme un fichier à ne rien faire.

function zle-line-linit() {
  # NOP
}

(Cela peut encore interrompre d'autres raccourcis clavier qui dépendent du mode clavier de l'application.)

Pour ces applications, il n'y a pas de défilement du terminal. Vous pouvez le tester vous-même en exécutant vim ou emacs dans xterm - vous ne pouvez pas revenir au contenu du terminal précédent.

Différence mineure, mais ce n'est pas tout à fait vrai: dans xterm, au moins certaines versions de celui-ci, si vous exécutez vim , il passe à l'écran alternatif, mais vous pouvez toujours faire défiler en arrière et voir le contenu antérieur du tampon (tant que le tampon a plus d'un écran de contenu), tant que vous n'avez pas activé la gestion des événements de souris dans vim . Si vous :set mouse=a dans vim , alors il recevra les événements de souris, et le terminal ne défilera pas en réponse à eux. La plupart des utilisateurs ne voient probablement pas l'ancien comportement car ils ont configuré leur .vimrc pour activer automatiquement la gestion des événements de la souris. Je pense que cela suggère que le comportement de défilement des widgets au niveau du terminal est contrôlé par la gestion des événements de la souris, et non par le mode d'écran alternatif.

Merci pour la clarification @apjanke - pour imiter pleinement le comportement de xterm, la gestion du tampon de défilement et du DECSET 1047 doit être examinée d'abord IMO.

@Tyriar , apprenez-moi pourquoi 1b886a44 est nécessaire.
vous voulez simplement masquer une barre de défilement verticale?
J'ai observé le comportement de xterm sur Linux pendant un petit moment, j'ai pensé que 1b886a44 devrait être abandonné.

@ayapi ce commit est https://github.com/sourcelair/xterm.js/pull/287

Cela fera apparaître la barre de défilement mais le terminal ne réagira pas à la molette de la souris.

FWIW, je pense que c'est un cas de Xterm.js s'écartant du comportement normal de xterm, et ce n'est pas le problème d'Oh My Zsh, et ce bogue devrait être fermé. Si OMZ fournit un shim de compatibilité pour cela, il doit être confiné à un plugin.

@apjanke donc vous êtes d'accord avec le PR que je viens de mettre en place? # 289

Oui, je suis d'accord avec https://github.com/sourcelair/xterm.js/pull/289. Le "mode Application", comme indiqué ici, n'est qu'un commutateur de mode clavier; le comportement de la souris ne doit pas être affecté par celui-ci, les événements de roue doivent donc être autorisés.