Xterm.js: API pour vérifier si un autre écran est actif

@Eugeny pourquoi en avez-vous besoin par curiosité?

J'ai une "détection de progression" automatique dans Terminus qui recherche des chaînes de pourcentage dans la sortie du terminal. Cependant, si un éditeur de texte comme vi ou nano est ouvert (généralement en mode écran alternatif) et que le texte contient "12%" ou similaire, il est redessiné par l'application encore et encore, déclenchant à nouveau le code de détection de progression.

Je cherche simplement à le désactiver tant que l'écran alternatif est actif

Je peux également voir de nombreux scénarios où cela est utile. Des choses comme les algorithmes de détection de ligne rapide ont généralement besoin de ce type d'informations.

Peut-être que l'ajout de isNormalBuffer et isAltBuffer à IBuffer serait suffisant?

Ce serait aussi bien d'avoir un événement comme terminal.onBufferActivate((buffer: IBuffer) => void ) pour réagir dynamiquement aux changements de tampon.

Peut-être devrions-nous également profiter de cette opportunité pour tamponner l'espace de noms comme nous l'avons fait avec l'analyseur, quelque chose comme ça?

interface buffer {
  normal: IBuffer
  alt: IBuffer
  active: IBuffer
  onDidChangeBuffer: IEvent<IBuffer>
}

@Tyriar Oui, ça sonne bien. Donc, vérifier si le tampon normal est actif serait une expression comme terminal.buffer.active === terminal.buffer.normal ? Ou devrions-nous également introduire une méthode pratique pour cela sur l'interface buffer ou IBuffer ?

Je suppose qu'avoir un IBuffer.type: 'normal' | 'alt' serait le meilleur des deux mondes?

Juste un avertissement mineur - nous devrions faire attention à offrir trop d'introspection d'état synchrone pour une raison simple - ppl finira par essayer de faire les choses en fonction de cela mais ignorera principalement l'état actuel du tampon d'entrée, ce qui pourrait changer les choses à tout moment. ( @Tyriar Vous vous souvenez de ce problème concernant quelqu'un essayant d'écrire une interface lisp locale? Il en résultera des problèmes de désynchronisation très difficiles à détecter.)

Ou peut-être devrions-nous être plus clairs à ce sujet dans le document de l'API, quelle partie est sync / async ...

@jerch Je suppose qu'une note sur write aiderait à résoudre ces problèmes. Essayer de résoudre ce problème avec des documents serait mieux que de ne pas proposer quelque chose comme ça.

Ouverts aux PR, nous voudrons peut-être modifier un peu la dénomination, mais je pense que la forme de base de l'API est là.

@Tyriar serialize-addon a également besoin d'un moyen de lire un tampon alternatif. Sinon, il est très difficile de mettre en œuvre un lecteur de lecture de session de terminal, même un outil de partage de session de terminal qui permet à tout le monde de se joindre à tout moment (j'ai trouvé que le partage en direct de vscode prend déjà en charge le partage de terminal, je ne sais pas comment cela fonctionne au lieu d'envoyer toute la sortie du terminal depuis le début)

@ JavaCS3 Est-ce vraiment un problème? À mon avis, le sérialiseur obtiendrait toujours le même tampon que l'utilisateur voit comme sortie d'écran au moment de la sérialisation. De plus, les applications utilisent généralement DECSET 1049 de nos jours, ce qui nettoierait toujours l'altbuffer. Ainsi, même si l'altbuffer contient toujours des données, il serait considéré comme un reste d'une session d'altbuffer précédente.

Imho, le sérialiseur n'a besoin de se soucier que d'un tampon à un moment donné. Notez que la lecture réelle ne sera pas possible avec le plugin serialize, pour cela vous devrez enregistrer les données d'entrée. (Serialize plugin - instantané à un moment donné, lecture - restauration des états au fil du temps; grande différence).

Edit (offtopic): Désolé de se moquer de l'idée de lecture avec le plugin serialize, j'ai toujours le sentiment qu'il y a une idée fausse. Le plugin serialize peut prendre un instantané du tampon du terminal à un moment donné. Pour une lecture fluide, ce n'est pas suffisant, car il ne vous donne que des instantanés isolés. Ce dont vous avez besoin pour une lecture réelle, ce sont des "différences incrémentielles" d'un instantané à l'autre. Pour vous faire économiser du travail - vous n'avez pas à calculer vous-même les différences incrémentielles à partir de deux instantanés, il est déjà là sous une belle forme condensée - ce sont les données d'entrée depuis le premier instantané. Prenez simplement un instantané, puis commencez à enregistrer les données d'entrée. Notez que vous devrez enregistrer quelques états internes supplémentaires avec l'instantané initial pour le rejouer correctement plus tard. Au moins, vous avez besoin de toutes les options, des indicateurs privés DEC, des paramètres de tampon / onglet, de redimensionnement d'interception, etc.

@jerch Pour moi, le cas d'utilisation est l'inverse. Je souhaite uniquement sérialiser le tampon normal, donc lors de la restauration d'un terminal après le redémarrage de l'application, je souhaite uniquement restaurer l'historique du tampon normal. Pour le moment, j'utilise un hack en appelant terminal._core.buffers.activateNormalBuffer() juste avant d'exécuter l'addon serialize. Il serait certainement préférable d'avoir une API publique pour cela.

@mofux Vous voulez donc donner à serialize le tampon comme argument? Mais n'est-ce pas déjà possible avec la proposition @Tyriar ci-dessus (après avoir étendu la sérialisation de cette façon)? Peut-être que je rate un moment ...

Edit (encore légèrement hors-sujet): Je pense que nous avons des idées différentes sur ce qui doit / peut être sérialisé atm. Telle qu'elle est implémentée maintenant, sérialiser est "seulement" un outil de capture instantanée de l'état actuel de la mémoire tampon. Ofc cela ne suffit pas pour obtenir une rediffusion complète à partir d'un certain moment dans une session de terminal. Peut-être devrions-nous d'abord discuter des fonctionnalités de sérialisation plus avancées nécessaires (peut-être dans un autre problème).

@jerch L'idée de base du lecteur de lecture de terminal est comme ce que vous dites, (créez un instantané un par un et remplissez le vide entre les instantanés avec des différences incrémentielles) Mais il y a un problème si le moment de création de l'instantané est pendant l'alternative est active et ensuite Les différences incrémentielles suivantes contiennent DEC 1049 (Use Normal Screen Buffer and restore cursor) . Il y aura un désordre car le tampon normal n'est pas encore sérialisé. c'est mon point. Sinon, je dois m'assurer que la création de l'instantané est juste avant DECSET 1049 . Mais je pense qu'il serait utile que je puisse accéder directement à la fois au tampon normal et au tampon alternatif.

(hors sujet)
J'utiliserai asciinema pour m'aider à enregistrer le tampon du terminal au lieu d'ajouter un nouvel addon dans xterm.js. Le fichier d'enregistrement d'asciinema est comme

[0.031006, "o", "\u001b]0;mat@mat-mint: ~/Documents/term-tris\u0007\u001b[01;32mmat@mat-mint\u001b[00m:\u001b[01;34m~/Documents/term-tris\u001b[00m$ "]
[0.739447, "o", "s"]
[0.843387, "o", "u"]
[0.939383, "o", "d"]
[1.051685, "o", "o"]
[1.147569, "o", " "]
[1.291866, "o", "p"]
[1.419392, "o", "y"]
[1.578995, "o", "t"]
[1.635077, "o", "h"]
[1.699073, "o", "o"]
[1.810955, "o", "n"]
[1.891268, "o", "3"]
[1.962887, "o", " "]
[2.083119, "o", "m"]
[2.202915, "o", "a"]
[2.315119, "o", "i"]
[2.394943, "o", "n"]
[2.603245, "o", "."]
[2.810757, "o", "p"]
[2.906992, "o", "y"]
[3.034495, "o", "\r\n"]
[3.04091, "o", "[sudo] password for mat: "]
[5.266162, "o", "\r\n"]
[5.369433, "o", "\u001b[?1049h\u001b[22;0;0t\u001b[1;24r\u001b(B\u001b[m\u001b[4l\u001b[?7h\u001b[?1h\u001b="]
[5.402342, "o", "\u001b[39;49m\u001b[?1h\u001b=\u001b[?25l"]
[5.402543, "o", "\u001b[?1000h\u001b[39;49m\u001b[37m\u001b[40m\u001b[H\u001b[2J"]

Le but de la création d'un lecteur de lecture de terminal est que le lecteur de terminal de l'asciinema est écrit en ClojureScript, ce que je pense qu'il est difficile pour les gens de contribuer. J'ai donc décidé d'écrire ma propre version avec xterm.js

Mais je pense qu'il serait utile que je puisse accéder directement à la fois au tampon normal et au tampon alternatif.

Mais c'est en quoi consiste la suggestion de

Il semble qu'asciinema effectue un chronogramme de la sortie pty. Yepp, à mon humble avis, le seul moyen d'obtenir une relecture correcte. L'avantage du plugin serialize ici serait que vous pouvez démarrer la relecture à partir de n'importe quel instantané en omettant l'ancienne sortie pty. Btw, vous pouvez créer une telle chronologie assez facilement vous-même, schématiquement:

let recording = false;
const recordedData = [];
function overloadedWrite(chunk, cb) {
  term.write(chunk, () => {
    if (recording) recordedData.push([Date.now(), 'input', chunk]);
    if (cb) cb();
  });
}
// replace term.write invocation with overloaded function
...
// initial snapshot, also activate recording
const initialData = addon.serialize(normal_buffer_as_arg);
// maybe 2nd call with altbuffer (if thats the active atm)
recording = true;
// more states need to be serialized here, like initial DEC private flags
const internalStates = ...
...
// stop recording
recording = false;

// --> final replay from snapshot is initialData + internalStates + recordedData

Ce n'est que l'idée approximative, ses bits encore manquants comme l'enregistrement de redimensionnement. Et si vous répétez l'instantané entre les deux et collectez l'enregistrement sous un instantané, vous obtenez essentiellement des "images de synchronisation" comme dans les codecs mpeg, ce qui permet plus tard de sauter / rechercher.

@jerch Je pense que ma première réponse https://github.com/xtermjs/xterm.js/issues/2694#issuecomment -584537861 est un peu trompeuse. La suggestion de @ Tyriar peut également résoudre mon problème. Je veux expliquer pourquoi nous avons besoin d'accéder à un tampon alternatif dans mon cas utilisateur. Désolé pour ma pauvre expression.

@ JavaCS3 Tout va bien, pas besoin de s'excuser. Je pense que nous devrions discuter davantage des idées sérialisées dans un autre fil. Il semble que @mofux ait également besoin de quelque chose de similaire au truc de relecture (lecture entre ses lignes).

@jerch Je suppose qu'il y a eu un malentendu 🤗 Tout ce dont j'ai besoin est un moyen propre de dire à l'addon de sérialisation quel tampon sérialiser. Je pense que l'API proposée par @Tyriar lui fournira l'API nécessaire pour le faire.

Tout ce dont j'ai besoin est un moyen propre de dire à l'addon sérialiser quel tampon sérialiser.

C'est ce que je veux finalement aussi, considérez le scénario suivant:

1. Code VS ouvert
2. Ouvrez un terminal
3. Ouvrir vim
4. Redémarrez VS Code
5. Un terminal s'ouvre, restaurant les tampons normal et alt

Je sais qu'il existe d'autres états / modes dans le terminal qui peuvent causer des problèmes avec cette restauration, mais cela devrait couvrir la plupart des cas pour le moment et nous pouvons toujours nous améliorer si nécessaire plus tard.

Je viens de proposer mon propre cas d'utilisation pour vérifier si le tampon alt est actif: https://github.com/microsoft/vscode/issues/90838

Je peux déjà être atteint par ce code terminal.buffer.active.type ou je rate quelque chose?

Je peux déjà être atteint par ce code terminal.buffer.active.type ou je rate quelque chose?

C'est parce que # 2713 a été fusionné

Merci pour la bosse 🙂