Les onglets ont été initialement considérés mais largement analysés par l'équipe car cela pourrait causer de la confusion avec les onglets en bas et rendre vscode moins "léger". Si je n'avais pas de raccourcis clavier pour les terminaux focusNext et focusPrevious , je serais très frustré par le manque d'onglets car les listes déroulantes sont pénibles à utiliser.

La vue fractionnée a également été considérée puis dépriorisée car des applications comme tmux peuvent s'exécuter dans le terminal intégré pour obtenir un résultat similaire, j'ai depuis pivoté à partir de cela et je veux vraiment pouvoir diviser le terminal. Je ne veux pas particulièrement apprendre les raccourcis clavier de tmux et une partie de mon flux de travail consiste à afficher plusieurs terminaux à la fois; généralement une commande de surveillance que je surveille pour les erreurs et une commande de construction ou de lancement manuelle. Suivons le fractionnement du terminal dans # 7504

@stevencl @ bgashler1 s'il vous plaît pesez à nouveau sur les onglets en gardant à l'esprit que je n'ai pas pu trouver de raccourcis clavier par défaut raisonnables pour les actions focusNext et focusPrevious du terminal (je lie ctrl + shift + j / k).

Nous devons cependant considérer cela dans le contexte de ce problème: https://github.com/Microsoft/vscode/issues/9659

Je me méfie vraiment des onglets dans la conception des onglets. Nous finirons par utiliser tout l'espace disponible pour afficher les onglets :-)

En pensant à voix haute ici, avons-nous vraiment besoin d'afficher des onglets si nous autorisons le fractionnement du terminal? Serait-ce suffisant si nous exposions simplement des actions pour diviser et réduire le terminal sans avoir à afficher l'onglet réel?

Peut-être que je peux me voir en utilisant 2-3 terminaux séparés sur des onglets / plusieurs terminaux. La gestion des terminaux séparés et des terminaux à onglets deviendrait très déroutante et ne serait probablement guère utilisée en raison du manque de raccourcis clavier.

Si nous ouvrons la porte au fractionnement des terminaux, que signifierait-il pour le fractionnement, par exemple un terminal et un remplacement de débogage? est-ce la même interaction UX?

@bpasero en divisant, je veux dire créer un nouveau terminal sur le côté, donc oui, ce serait la même chose.

Pour simplifier l'interaction, il pourrait y avoir un paramètre pour toujours utiliser _ soit_ la liste déroulante ou diviser les terminaux. De cette façon, toutes les commandes existantes fonctionneraient toujours correctement, vous choisissez simplement d'afficher 1 ou tous les terminaux à tout moment.

La crainte que j'ai avec l'introduction des onglets et le fractionnement dans le terminal est que cela puisse ressembler à un groupe d'éditeurs. Je ne veux pas que les utilisateurs soient déçus de ne pas pouvoir faire glisser les éditeurs dans le terminal ou les terminaux dans les groupes d'éditeurs. * De plus, l'introduction de cela peut être une pente glissante dans la gestion des fenêtres, par exemple pourquoi avons-nous même un horizontal spécial panneau pour des choses comme celle-ci en premier lieu. Pourquoi ne pas simplement laisser un terminal vivre où il le souhaite, au lieu de répliquer autant de fonctionnalités dans une interface utilisateur personnalisée.

* éventuellement, nous pourrions les informer de la limitation en verrouillant le glissement sur l'axe des x et / ou en ayant un curseur désactivé lorsque vous essayez de faire glisser en dehors d'une zone, mais il est difficile d'éviter que les gens s'attendent à ce que cela fonctionne.

Lorsque nous introduisons la division horizontale des groupes d'éditeurs, l'une des contraintes que nous imposons est que les groupes d'éditeurs ne peuvent être divisés horizontalement ou verticalement. Il peut donc être étrange pour les utilisateurs d'avoir un panneau qui ressemble de manière frappante à un groupe d'éditeurs horizontal (mais il ne se comporte pas exactement de la même manière) assis sous des groupes d'éditeurs verticaux.

Nous devrions en parler davantage lors de la synchronisation UX mercredi. Il y a des modèles que je n'ai pas montrés la dernière fois liés aux mises en page horizontales qui sont pertinents à ce sujet

Qu'en est-il de la possibilité d'aligner le terminal avec l'onglet éditeur, afin que le terminal reflète automatiquement la langue du fichier éditeur?

L'ouverture d'un terminal chargerait automatiquement un shell préconfiguré pour la langue de l'éditeur actif (actuellement sélectionné). Plusieurs shells de terminal doivent être pris en charge dans le fichier settings.json.

Peu importe la façon dont les éditeurs sont divisés - le terminal affiche toujours le shell de l'éditeur sélectionné (actif). C'est simple et direct. Avec cette méthode, il n'est pas nécessaire de diviser le terminal, pas besoin de terminaux à onglets. Le terminal continuerait d'apparaître comme il le fait actuellement.

S'il y a plusieurs shells disponibles pour la langue, ou si vous voulez exécuter une configuration comme le node shell et un git shell pour le seul onglet de l'éditeur, alors peut-être que les shells peuvent être sélectionnables dans un seul volet. C'est un peu comme des terminaux à onglets, sauf qu'ils ne sont pas présentés comme des onglets durs, ce qui implique un sous-contexte. Cela ne «semble» pas substantiel comme un onglet. Leur contexte se trouve dans le volet terminal de l'éditeur actuellement sélectionné.

Une simple chaîne hypertexte (une pour chaque shell) située en haut à droite du terminal affichera les shells ouverts (instanciés) pour l'éditeur actuellement sélectionné. Un utilisateur peut simplement cliquer sur une chaîne hypertexte, qui pourrait dire nœud, pour le sélectionner, ou utiliser une liaison de clé pour parcourir. Ceux-ci remplaceront le menu déroulant existant, le + et la poubelle. Les coques pourraient éventuellement être présentées en minuscules.

Soit une simple chaîne hypertexte peut être affichée, soit juste une icône - bien qu'une chaîne puisse être meilleure. Cela remplacerait la liste déroulante encombrante actuellement utilisée dans VSCode et afficherait les shells en un coup d'œil.

Lorsque vous basculez le focus de l'éditeur actuel vers un éditeur avec une autre langue (par exemple, Ruby), le terminal présentera l'instance IRB dans le terminal. Si l'utilisateur souhaite ouvrir une autre instance du shell actuel, il se peut qu'il lui suffise de survoler l'hypertexte de ce shell et de cliquer sur le + qui apparaîtra. Si les chaînes hypertextes sont courtes - comme node, irb, cmd, ps - une autre chaîne peut être créée à côté de la chaîne utilisée pour créer la nouvelle instance. Les chaînes se sépareraient pour faire de la place mais ne seraient pas encombrées car une limite pourrait être fixée (qui va ouvrir plus de trois shells contre un éditeur?).

Le survol d'un shell peut également être en mesure de présenter un pic, qui montre le contenu du shell pour cette chaîne. Cependant, si les utilisateurs utilisent des raccourcis clavier pour basculer / faire un cycle, il pourrait être plus facile de vérifier avec cela.

Si vous vouliez donner à l'utilisateur la possibilité d'ajouter un shell non associé à l'éditeur, comme un shell git, cliquer sur le + pourrait présenter un menu de shells enregistrés dans le fichier settings.json. Le - qui apparaîtrait au survol à côté de chaque chaîne hypertexte ne montrerait bien sûr aucune option. Cela fermerait l'instance actuelle du shell.

Si un utilisateur souhaitait changer le type de shell, il pouvait quitter le shell (pour revenir à la valeur par défaut), puis lancer un nouveau shell en tapant le nom du shell. La chaîne hypertexte représentant le shell changerait pour refléter le nouveau shell.

Dans le cas d'un shell git, il peut être logique d'offrir l'option à l'utilisateur de spécifier qu'un shell git sera toujours ouvert avec le shell de langue de l'éditeur, de sorte que git soit en contexte à cet emplacement de fichier. Si plusieurs fichiers sont ouverts à partir du même emplacement git, toutes les instances git shell de tous les éditeurs refléteront la dernière mise à jour ou commande.

Le fichier settings.json demandera probablement à l'utilisateur de saisir l'extension de langue spécifique (.js, .cs, .rb) pour chaque terminal.internal.shell. entrée pour qu'il y ait une correspondance logique avec un fichier. Un shell par défaut peut être configuré pour tout type de fichier non spécifié dans settings.json.

L'instance de shell chargée pour chaque éditeur dure aussi longtemps que cet éditeur est ouvert. Dès qu'un éditeur (un fichier) est fermé, le ou les shell (s) de terminal associés sont également fermés.

Je pense qu'il s'agit d'une implémentation simple qui rendra également VSCode plus puissant qu'il ne l'est actuellement, tout en étant très intuitif. Lorsque l'utilisateur change de contexte entre les éditeurs de langue, il n'a pas à penser au terminal. Le terminal présentera toujours le shell et le code de la dernière exécution, y compris l'historique associé, etc., qui a été utilisé pour la dernière fois pour l'éditeur sélectionné.

@ nick-walt bien que cela puisse être plus intuitif pour certains, ce n'est pas du tout intuitif pour d'autres. Cela amènerait probablement les gens à être quelque peu désorientés et à se demander où leur coquille est allée. Mes exigences sont également d'avoir 2 coquilles affichées à la fois; un pour une tâche de surveillance dans laquelle je suis en train de suivre les erreurs et un pour une tâche de lancement, git, build, etc.

Plusieurs configurations de terminaux sont déjà apparues auparavant, je ne suis pas sûr que cela vaille la peine de la complexité supplémentaire lorsque la plupart du temps, vous pouvez simplement exécuter le shell dans votre autre shell (ouvre PowerShell, Ruby, node, etc. dans cmd).

@Tyriar
Ce sont de bonnes préoccupations, mais je pense qu'elles peuvent être résolues assez facilement lorsqu'elles sont considérées comme des considérations.

Évitez la désorientation
Dans son état par défaut, dans une nouvelle installation non configurée, le terminal peut se comporter de manière familière. Cela évite la désorientation due à un comportement inattendu.

Fractionner le terminal
Le fractionnement du volet terminal ne change pas le modèle. C'est juste un moyen d'afficher plus d'un shell à la fois dans le volet terminal. Il pourrait être possible de faire glisser le volet hors de la fenêtre principale et de passer en plein écran sur un autre moniteur. Ensuite, l'utilisateur peut dire au terminal de se diviser automatiquement et uniformément entre les coques ouvertes, verticalement ou horizontalement. Un terminal, plusieurs shells - le tout dans le contexte de l'éditeur actuellement sélectionné.

En train de regarder
Si nous ne voulons pas perdre de vue une instance de shell que nous surveillons, pendant que vous passez à un autre éditeur, alors peut-être qu'une fonction de surveillance affichant un nombre configurable de lignes pourrait résoudre ce problème. Si une erreur se produit, elle peut également être affichée sous forme d'icône au cas où l'utilisateur l'aurait manquée en raison d'un défilement rapide. Ceci est déjà fait dans le volet Erreur de VSCode. Un panneau d'observation pourrait être affiché uniquement et le survoler pourrait afficher un échantillon plus grand.

Sophistication sans le fardeau de la complexité
Avec un terminal contextuel, la possibilité d'avoir de nombreux shells sur tous vos éditeurs ne vous semblera pas écrasante ou éprouvante. Avec le bon modèle, les gars UI / UX peuvent le faire fonctionner avec élégance.

Je pense que vos préoccupations pourraient être pleinement prises en compte.

Cela dépend du terminal qui va (supposé) être utilisé. S'il doit être utilisé pour exécuter une commande ponctuelle, plusieurs terminaux sont à peine nécessaires.

Plusieurs terminaux sont nécessaires s'ils doivent être utilisés pour exécuter simultanément plusieurs tâches d'arrière-plan, telles que le service, la construction, la surveillance, les tests, etc.

Donc, dans ce cas, il est viable d'avoir un aperçu rapide des terminaux ouverts et de ce qu'ils fonctionnent (avec vraisemblablement l'état de l'exécution). Je ne sais pas comment cela peut être fait sans onglets nommés / créés .

La vue

Une autre question est l'utilisation coopérative avec Task Runner. Qui est actuellement utilisé pour exécuter une seule tâche à la fois. Mais ce https://github.com/Microsoft/vscode/issues/981 suppose qu'il va prendre en charge plusieurs tâches en arrière-plan - il s'agit donc d'un objectif similaire (je ne dirais pas conflictuel) à celui de plusieurs terminaux.

Jetbrains Webstorm a actuellement de telles capacités - il peut exécuter plusieurs tâches (définies via grunt / gulp / npm) et plusieurs terminaux (avec des onglets nommés). Et vous pouvez également y utiliser une vue fractionnée où d'un côté vous voyez des tâches en cours d'exécution, et de l'autre - terminal. (fixation de l'écran)

@couleur blanche

D'accord, donc si nous listons tous les scénarios et leurs points communs, il devrait être possible de distiller les fonctionnalités requises à l'élégance qui peut répondre à une utilisation diversifiée - sans que VSCode ne devienne trop lourd.

Much'o tabs sans fatigue
Avec un terminal lié au contexte d'un éditeur, la question d'une déconnexion d'utilisabilité (comme les onglets associés à quel éditeur) l'utilisation de `` soft tabs '', alias une chaîne hypertexte nommant le shell dans le contexte du terminal / éditeur, permettra beaucoup plus d'onglets sans obliger l'utilisateur à rechercher des onglets et éviter la fatigue du contexte / association de garder une trace dans sa tête.

Coquilles nommées
Avec l'idée d'une simple chaîne hypertexte montrant le nom d'une instance de shell dans un panneau de terminal vient la possibilité d'une création et d'un nommage alternatifs. Ainsi, un utilisateur a un seul shell configuré dans settings.json, qui peut être «cmd».

Une fois qu'ils sont dans un shell, ils peuvent soit sauter dans un autre shell, comme «powershell» ou «bash», et la chaîne hypertexte nommée «cmd» dans l'en-tête du terminal peut changer pour refléter le shell dans lequel l'utilisateur est passé.

Ou, l'utilisateur peut créer une instance de shell supplémentaire à partir du shell de démarrage 'cmd' peut-être en utilisant une commande que le volet terminal comprend comme créant un "nouveau".

L'idée est d'impliquer dans l'interface utilisateur le fait que les shells nommés ne sont pas des onglets désassociés mais des shells dans l'éditeur parent. J'utilise le terme «onglets» pour désigner un shell désassocié et autonome qui est séparé de tout le reste. Il peut s'agir d'un mode dans lequel les onglets fixes sont globaux et les onglets programmables sont dans un contexte d'éditeur.

Si un mode onglet fixe / onglet logiciel était inclus, alors peut-être que les onglets durs pourraient avoir des internes durs, un peu comme des onglets montrant des éditeurs. Le comportement des noms serait identique à celui des onglets logiciels.

L'essentiel est de maintenir le modèle UI / UX établi. Nous avons tous vu de nombreux cas où les modèles sont répartis entre différentes implémentations d'interface utilisateur au sein d'une seule application. En fait, Microsoft est bon dans ce domaine (et plus récemment, Apple). C'est un cas classique de «conception par comité».
établi

Utilisateur de shell simple et unique
Cependant, si un utilisateur souhaite exécuter simplifié et un seul terminal / shell, il n'y a rien pour y parvenir, et surtout, la configuration est simple. C'est juste un autre scénario d'utilisation dans la matrice de considération.

Si des onglets doivent être ajoutés, j'aimerais avoir une option de configuration pour les désactiver / forcer une seule instance du terminal intégré. Si j'ai besoin de telles fonctionnalités _ avancées_, j'utilise généralement le terminal (externe) de mon choix.

Je considérerais également une chose telle que la division du terminal (division plus avancée) de sorte que toutes les sorties de terminaux importantes en cours d'exécution (peut-être plus de deux) étaient sous les yeux même partiellement.

Que diriez-vous d'afficher les onglets du terminal au même endroit que les onglets de fichiers?
Cela ne poluerait pas l'interface utilisateur et ne serait pas perdu fonctionnellement.

@cescoferraro J'aime cette idée. Mais alors VS Code devrait également prendre en charge les vues à onglets fractionnés verticalement et pas seulement horizontalement. Sinon, cela ne remplirait pas vraiment la condition de voir plusieurs terminaux sans perdre de place.

@Phisherman Ne vous méprenez pas, j'aime le terminal partagé.
Je l'utilise beaucoup sur Intellij avec un grand écran et beaucoup de configuration de mémoire.
Quelle que soit la décision prise, il devrait être enfichable s'il accapare trop de mémoire pour garder VSCode aussi vite que possible.

J'ai écrit une extension avec laquelle vous pouvez sélectionner la tâche npm / gulp, elle lancera le terminal (avec le nom de la tâche) et l'exécutera là-bas, placera également un élément sur la barre d'état sur lequel vous pouvez cliquer à tout moment, ainsi que effectue un suivi de base de l'état du processus en cours d'exécution.

Juste pour montrer l'emplacement des "onglets" possibles, ils pourraient être au bas du teminal.

@whitecolor : open_mouth: cela utilise la nouvelle API de terminal? C'est génial!

@Tyriar Ouais, celui sur lequel vous travaillez: wink:

Comme mentionné par @whitecolor , WebStorm a des onglets pour les terminaux et cela améliore l'accessibilité de l'EDI. En plus de ce WebStorm vous permet de changer le nom de l'onglet qui vous aide à nouveau à identifier visuellement par quoi commencer.

Ce que WebStorm ne fait pas, c'est qu'il n'enregistre pas le nombre d'onglets de terminal ouverts.
Lorsque vous développez, vous avez généralement besoin des mêmes onglets (serveur, observateur, backend ...). Si le nombre d'onglets pouvait être enregistré ainsi que leur nom, ce serait génial.

@whitecolor après

• Lorsque vscode est redémarré, un terminal standard sera créé, vous ne pouvez pas y attacher un élément de barre d'état
• L'extension ne sait pas quand un terminal est supprimé par l'utilisateur, donc l'élément de la barre d'état restera au moins jusqu'à ce que vous cliquiez à nouveau # 10925
• (Bug) La mise au rebut d'un terminal affichera le panneau # 11275
• Également à venir dans la v1.6.0, le terminal sera probablement masqué par défaut, vous devrez donc appeler Terminal.show juste après l'avoir créé # 11384

@Tyriar merci pour le partage, répondra à votre liste:

1) Oui, ce n'est pas si important, mon extension ajoute en fait une commande "Ouvrir un nouveau terminal" et permet d'ouvrir un nouveau terminal nommé , je ferme généralement le standard et j'utilise celui créé, mais ce serait bien s'il y avait un accès à tous les terminaux existants dans le panneau.
2) Oui, l'extension n'est pas au courant de l'état du terminal mais je traque les processus enfants du terminal._id par PID, donc je sais quand le terminal est supprimé par l'utilisateur (les processus enfants vont à 0). Donc, ce que je demanderais de ne pas supprimer cet identifiant de processus à l'avenir, je ne sais pas si cela doit être public). Donc, je surveille même la quantité de processus enfants en cours d'exécution et si le nombre est réduit, cela peut signifier que quelque chose ne va pas ou que des tâches sont terminées, alors je montre ce terminal, très utile.
3) Je n'utilise donc pas actuellement de disposer.

Ce qui manque vraiment, c'est l'accès à la sortie du processus, qui permettrait de faire des analyses plus utiles (par exemple, suivre certaines sorties d'erreur / exceptions) et montrer le terminal à l'utilisateur.

L'extension est en fait prête à être publiée, le fera probablement des jours.

@whitecolor actuellement, il n'y a qu'un accès aux terminaux créés via l'API, c'est un cas assez convaincant pour changer cela.

Sneaky sneaky peeking at terminal._id : wink: cela ne sera probablement pas changé de sitôt, mais dès qu'un événement que vous pouvez écouter est ajouté, vous devriez certainement en tirer parti car ce sera l'API stable officielle. Le suivi et la sortie des processus enfants doivent être explorés dans le # 11422 (vous pouvez suivre les problèmes liés à celui-ci pour certaines discussions sur le sujet).

Avec la commande de terminal nommée, vous fournissez également une solution de contournement pour # 10023: smiley:

Beau travail, j'ai hâte de l'essayer!

@whitecolor FYI, donc j'ai menti et terminal._id changera probablement dans la v1.6 pour être un ID aléatoire, pas le PID. Je suis au milieu d'un énorme refactor afin de séparer davantage le panneau terminal des processus (afin qu'ils puissent exister sans le panneau existant # 11275) et je ne pense pas pouvoir le garder malheureusement.

@whitecolor vous pouvez essayer window.onDidCloseTerminal (# 10925) dans les initiés de demain. Cela devrait être plus facile que de suivre le PID.

J'aime le voir comme InteliJ. En attendant, j'ajoute ce trousseau personnel:

[
    {
        "key": "ctrl+pageup",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },{
        "key": "ctrl+pagedown",
        "command": "workbench.action.terminal.focusPrevious",
        "when": "terminalFocus"
    }
] 

Les mêmes raccourcis clavier pour naviguer entre les onglets, mais si le curseur est focalisé sur le terminal, basculez entre les terminaux.

Une vue fractionnée sur les onglets du terminal serait très utile;

J'essaie actuellement de faire une preuve de concept avec une instance de serveur et d'exécuter des demandes via un autre terminal de console.

Des progrès à ce sujet?

@MeirionHughes
tmux pourrait être une solution mais cela fonctionne mal à l'intérieur du terminal intégré VSCode (enfin dans Windows).

@MeirionHughes voici le problème de cette fonctionnalité https://github.com/Microsoft/vscode/issues/7504. Aucun progrès jusqu'à présent, la dernière fois que j'ai poussé pour cela, j'ai été repoussé par l'équipe. Le plus: +1: sur cette question, mieux c'est.

@Tyriar, vous pourriez dire que ce problème demande également un fractionnement, car dans la troisième image, il le montre explicitement. De plus, ce numéro a 112 👍 :)

@MeirionHughes le premier commentaire (le mien) dit:

Suivons le fractionnement du terminal dans # 7504

La raison en est que les discussions sur 2 fonctionnalités différentes ne créent pas de bruit l'une pour l'autre.

Oh les gars, les pls aident car c'est une fonctionnalité très importante de l'interface utilisateur, parfois cela permet de créer une liste déroulante de poignée crz pour changer de console, merci beaucoup;)

+1 pour les raccourcis clavier cycle terminal .

@whitecolor _darn! _ Je pensais que tmux dans le terminal intégré était ma propre solution de contournement intelligente, mais vous m'avez battu. Fonctionne bien pour moi (pas de mouse mode ) mais les volets fonctionnent bien:

Le mode souris fonctionne très bien pour moi avec tmux.

Dans tous les cas, je pense que c'est un excellent ajout

Je pense que ce serait vraiment utile. Mais je ne pense pas que cela devrait se limiter aux terminaux, mais inclure également les onglets «Problèmes», «Sortie», etc., afin que vous puissiez avoir «Terminal», «Problèmes» et un éditeur ouvert dans une vue.

Je vais également juste +1 sur une liaison de touches pour parcourir les terminaux. Je déteste avoir à utiliser la souris pour cliquer sur ce petit menu déroulant, en particulier sur un ordinateur portable avec un pavé tactile.

Donnez-moi un raccourci clavier pour parcourir les terminaux et je pense que je peux me passer du fractionnement / des tabulations

@ psimoneau22 voici la combinaison de touches que j'utilise pour cela:

{ "key": "ctrl+shift+j",    "command": "workbench.action.terminal.focusNext" },
{ "key": "ctrl+shift+k",    "command": "workbench.action.terminal.focusPrevious" },

Nous allons bientôt envisager de nous séparer.

Je ne peux pas croire à quel point cet éditeur est bon et puissant. Ce sera un ajout super puissant pour simplement ouvrir vscode et rien d'autre pendant une session de codage.

TL, DR; Utilisez quelques heures pour récupérer tmux.

Je suis content de tmux dans mon terminal (le mode souris fonctionne comme un charme). Il m'a fallu une journée pour apprendre. J'ai déjà joué avec ça plusieurs fois, mais j'ai passé hier à l'installer comme un boss. Je viens de faire un tmux -CC dans iTerm - qui lance une fenêtre de terminal. Ensuite, faites un tmux a dans le terminal vscode pour vous connecter à cette session - c'est que j'obtiens des sessions de terminal persistantes afin que je puisse toujours revenir par session lors du redémarrage de vscode (mettre à jour Vscode, installer des extensions). C'est une fonctionnalité bien meilleure pour moi que d'avoir des onglets ou des divisions dans le terminal. Gardez la lumière Vscode s'il vous plaît. Atom est une leçon à tirer (j'en suis venu). TMUX FTW :)

Cette même approche a également fonctionné pour moi dans Mac / cygwin / windows et devrait fonctionner à peu près partout où Vscode fonctionne.

TL, DR;

ce serait bien d'avoir des onglets pour le terminal intégré au lieu de la liste déroulante. Une chance de voir cette fonctionnalité à l'avenir?

Compte tenu du raccourci ctrl + shift + ` et ctrl + ` je pense que ces paramètres ont plus de sens.

  {
        "key": "ctrl+shift+right",
        "command": "workbench.action.terminal.focusNext"
    },
    {
        "key": "ctrl+shift+left",
        "command": "workbench.action.terminal.focusPrevious"
    }

@leocaseiro @Tyriar @ psimoneau22 Sauf si vous utilisez un Mac, il vaut la peine d'ajouter l'option 'quand' à ceux-ci comme ctrl + shift + left et ctrl + shift + right sont utilisés pour sélectionner des morceaux de texte dans l'éditeur.

    {
        "key": "ctrl+shift+j",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },
    {
        "key": "ctrl+shift+k",
        "command": "workbench.action.terminal.focusPrevious",
         "when": "terminalFocus"
    }

ou

    {
        "key": "ctrl+shift+right",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },
    {
        "key": "ctrl+shift+left",
        "command": "workbench.action.terminal.focusPrevious",
         "when": "terminalFocus"
    }

Voici mon 2ct pour cette fonctionnalité très souhaitable (désolé si certains des points ont déjà été mentionnés)

Cas d'utilisation
Les raisons pour lesquelles j'utilise plusieurs terminaux dans le premier cas sont généralement soit:

• J'ai besoin de travailler dans deux répertoires en parallèle et je ne veux pas cd avant et en arrière tout le temps
• J'ai besoin de travailler avec deux terminaux différents (par exemple bash vs powershel vs cmd ou local vs remote / ssh)
• Je souhaite surveiller la sortie de deux programmes différents en parallèle

Notez que seulement dans le troisième cas, j'ai besoin d'une vue partagée du terminal. Dans la plupart des autres cas, je préfère avoir un terminal utilisant autant d'espace que possible.

UI
Pourquoi ne pas étendre les onglets actuels (ex: Débogage, Sortie, Terminal ...) et autoriser un "Terminal1, Terminal2, Terminal3 .... supplémentaire"

Onglets vs liste déroulante

• Vous voyez tous les onglets disponibles
• Il est plus facile (pour moi) de se souvenir quel terminal sert à quel but s'ils sont représentés par des emplacements visuels distincts (par exemple, 3e onglet)

tl; dr

Je suis tout à fait d'accord avec @MikeGitb , j'utilise toujours plus d'un terminal à la fois. La liste déroulante des terminaux dans le code VS actuel est difficile à voir les onglets ouverts. Ce serait vraiment génial d'avoir des onglets pour le terminal intégré. Merci.

Une idée folle: pourquoi ne pas donner au terminal le même statut que les onglets classiques de l'éditeur? Ce serait particulièrement pratique si l'on veut voir plus de deux lignes en même temps.

Une idée folle

Ce n'est pas fou, c'est ainsi que fonctionnent vim / neovim.

Ce n'est pas fou, c'est ainsi que fonctionnent vim / neovim.

Comme beaucoup d'autres IDE;).

Désolé, cette intro était en fait signifiée ironiquement.

@Tyriar existe-t-il une fonctionnalité permettant le panoramique vertical du terminal à côté de votre code ou cela ne sera-t-il pas autorisé?

@ajrator qui est couvert dans https://github.com/Microsoft/vscode/issues/2806

Serait totalement heureux de donner aux terminaux le même statut que les onglets de l'éditeur - ComEmu et HyperTerminal ont tous deux de graves problèmes qui empêchent leur utilisation actuelle (ConEmu a des problèmes de contraste qui ne peuvent pas être résolus car le mainteneur veut conserver le support XP, HyperTerminal ne peut pas le faire Ctrl + C dans PowerShell et autres bases). Avoir vscode comme terminal à onglets fonctionnel serait fantastique.

Je continue également à regarder quand il publiera une vue à onglets du terminal intégré au lieu de la liste déroulante.

Le menu déroulant est un peu inconfortable à utiliser. Avoir plus d'un terminal ouvert serait également génial.

Pour les personnes qui souhaitent essayer tmux en attendant le support des onglets, j'ai créé un élément essentiel pour démarrer l'installation. Il a la prise en charge de la souris activée par défaut et utilise des liaisons simples pour diviser le terminal.
https://gist.github.com/cybertim/e8b42c8cd8a5bebaa3eb8cec17a2746f

Merci @cybertim , super fichier! J'ai déjà utilisé tmux mais ce fichier est pratique.

La raison pour laquelle je serais personnellement très intéressé par plusieurs terminaux à des positions différentes dans la fenêtre est que, espérons-le, cela ouvrirait la voie à la mise en œuvre d'un environnement similaire à RStudio / Jupyter Lab dans VSCode.

Personnellement, j'aimerais que tout soit un onglet et que je puisse ensuite diviser les panneaux à l'infini verticalement et horizontalement. Vous pouvez alors également fournir la possibilité d'épingler des onglets afin de conserver les outils les plus courants tels que Terminal, Explorer et Recherche.

Les éditeurs plus anciens ont les boutons Enregistrer, Annuler, Rétablir le long d'une longue barre d'outils en haut - VSCode ne le fait pas - pourquoi? Parce qu'on s'attend à ce que les gens utilisent le clavier. Nous sommes des programmeurs. Le terminal précédent, le terminal suivant peuvent tous être liés à des touches de raccourci - utilisez-les. Je dis que nous clôturons ce problème et passons à ce qui est important.

Ensuite, vous voulez toujours des onglets? Des volets? Des fractionnements?

Je pense que beaucoup de gens ici demandent une fonctionnalité excessive pour VScode. S'ils voulaient simplement essayer tmux , ils ne le demanderaient pas. Le terminal nous est donné. En utilisant tmux, il prend en charge les onglets. Vous aurez besoin de quelques heures maximum pour apprendre tmux. Il y a des onglets, des fenêtres, des divisions, et plus encore, si vous devez redémarrer VSCode, vous pouvez simplement taper tmux -a après le redémarrage pour revenir directement à votre session tmux. Après avoir basculé en mode souris (une seule ligne dans la configuration), vous pouvez même redimensionner les volets, cliquer sur les onglets pour accéder à cet onglet. Je suis contre cette fonctionnalité dans VSCode. Cela ne fera que ralentir la performance. Gardez VSCode aussi léger que possible - nous ne voulons pas d'un autre Atom. Laissez tmux faire le gros du travail! Comme vous pouvez le voir ci-dessous, j'ai des divisions et aussi si vous regardez de près en bas, j'ai deux onglets - python & fish . Et ouais, en bas à gauche, j'utilise googler dans la ligne de commande de Google: D

@piggyslasher Je ne vois pas comment cette fonctionnalité pourrait ralentir vscode.
Vscode prend déjà en charge plusieurs instances de terminal. Cette fonctionnalité consiste simplement à changer le sélecteur de liste déroulante en une fonctionnalité d'onglet plus agréable à utiliser.

Avec cette fonctionnalité, vous pourrez toujours continuer à utiliser une instance / un onglet de terminal avec tmux, et ne vous attendez pas à un changement de performances par rapport à maintenant.

Vscode est un éditeur multi-plateforme. Dire aux gens d'utiliser tmux restreint ces personnes aux environnements où tmux est disponible. De plus, tmux a une grande courbe d'apprentissage qui est totalement exagérée pour une fonctionnalité aussi simple que celle-ci

La suggestion de @piggyslasher est intéressante si vous y pensez plutôt comme «faites-le à la tmux».

C'est quelque chose auquel je pense depuis longtemps. Tmux a tabs et chaque tab peut être divisé en autant de panes qu'il le souhaite. Les éditeurs en revanche ont panes et ensuite chaque pane peut avoir tabs .

J'aime plutôt la manière tmux parce que c'est comme `` cette disposition des terminaux est liée, puis nous passons à un autre onglet de terminaux associés ''

Pour quelque chose comme le développement react / angular, je pourrais voir cela utile si vous avez un «volet» JS / HTML / CSS / Test ouvert pour chaque composant et un «onglet» pour chaque composant sur lequel vous travaillez.

Je serais intéressé de voir s'il était possible de faire quelque chose comme ça dans un plugin. Origami for Sublime est proche, mais il s'agit toujours de «volets pleins d'onglets» et non de «onglets pleins de volets».

Il y a beaucoup de préoccupations concernant la portée et l'échelle de l'introduction de la gestion de la console via des onglets et d'autres mécanismes d'interface utilisateur et je veux juste souligner que si le problème qui est résolu est défini très clairement, les problèmes de portée et d'échelle et d'attentes des utilisateurs disparaissent. à atténuer en raison de l'élégance de la solution. Définissez le problème très clairement et la solution sera plus claire, et la logique est plus susceptible d'être cohérente dans toute l'interface utilisateur et l'expérience utilisateur. Vous savez, ce sens du "ça marche" que nous aimons tous utiliser et créer.

De plus, il serait bon d'avoir une liste à puces ou numérotée des différentes solutions proposées dans ce fil et de leurs préoccupations identifiées (probablement sous forme de puces / numéros en retrait). Un fil comme celui-ci peut tourner en rond sans que ces éléments soient mis à jour dans un emplacement central et organisé, ou peut-être dans le message initial.

Il me semble que tout le monde convient qu'une certaine forme de gestion de la console est nécessaire, au-delà de ce qui est actuellement en place. Juste une suggestion pour résoudre les problèmes d'échelle: offrez la possibilité à l'utilisateur de connecter les consoles à un éditeur ou à un groupe d'éditeurs. Autorisez également une console à être séparée, mais définissez dans les deux cas une valeur par défaut définie par l'utilisateur. Le fait d'attacher les consoles au contexte de l'éditeur aidera à réduire l'apparition excessive de consoles. De plus, cela permettra aux consoles d'un éditeur d'être masquées lorsqu'un autre éditeur est sélectionné, réduisant ainsi la complexité de l'interface utilisateur. Si les consoles ne sont pas associées aux éditeurs, les choses peuvent devenir incontrôlables et les gens oublieront quelle console fait quoi, etc.

Envisagez d'ajouter un paramètre configurable par l'utilisateur qui permet aux consoles définies pour un éditeur d'être enregistrées dans l'application, en fonction du nom et de l'emplacement du fichier (ou, peut-être en fonction d'un autre identifiant plus fiable et unique dans les propriétés du fichier au niveau de niveau système).

L'argument pourrait être dit que ce niveau de raffinement se rapproche des niveaux de l'IDE, mais les créateurs ont déjà dit que VSCode apporte certaines des bonnes choses d'un IDE dans l'espace de l'éditeur. Il est possible d'introduire une solution console qui ne semble ni lourde ni complexe, qui fonctionne tout en apportant une excellente UX.

Si cela n'a pas de sens, ou si je déclare l'évidence, faites-le moi savoir.

@ nick-walt quand vous dites:

fournir la possibilité à l'utilisateur de joindre les consoles à un éditeur ou à un groupe d'éditeurs.

Proposez-vous une possibilité pour le terminal d'associer des instances de shell à des fichiers ouverts particuliers?

Il me semble que vous compliquez trop les choses. Bien sûr, continuez à sortir des sentiers battus à ce sujet, mais d'après ce que j'ai vu sur des fonctionnalités similaires, l'équipe vscode aime garder l'impact de petites fonctionnalités comme celle-ci assez minime. Je parie donc qu'ils recherchent la solution la plus simple (tout en étant efficace) pour rendre les gens heureux.

Le point le plus fondamental de ce problème est qu'un menu déroulant n'est pas idéal pour basculer entre les choses, et que les onglets sont une très bonne alternative - d'où la plupart des choses utilisent des onglets: éditeurs, IDE, navigateurs, etc. Je pense que tout le monde ici serait d'accord que pratiquement toute forme d'onglets serait préférable à une liste déroulante.

En plus de cette partie la plus élémentaire de la façon dont nous basculons entre les instances de shell, il y a un intérêt à autoriser également un moyen d'avoir plus d'une instance visible en même temps. Soit à travers les volets dans la section terminal en bas, soit en rendant également les onglets de terminal interchangeables avec les onglets de l'éditeur d'une manière ou d'une autre, ou une autre solution. Cette partie est plus compliquée, et il y a probablement moins d'accord sur la voie à suivre. Surtout compte tenu de ce que @sorahn vient de souligner à propos des volets à l'intérieur des onglets et des onglets à l'intérieur des volets.

Personnellement, je pense qu'il y a suffisamment de support pour supprimer la liste déroulante (car ce n'est vraiment pas génial) et la remplacer par des onglets, et s'inquiéter des choses plus avancées par la suite.

Il y a plus d'un an, @ bgashler1 a dit ceci:

La crainte que j'ai avec l'introduction des onglets et le fractionnement dans le terminal est que cela puisse ressembler à un groupe d'éditeurs. Je ne veux pas que les utilisateurs soient déçus de ne pas pouvoir faire glisser les éditeurs dans le terminal ou les terminaux dans les groupes d'éditeurs. * De plus, l'introduction de cela peut être une pente glissante dans la gestion des fenêtres, par exemple pourquoi avons-nous même un horizontal spécial panneau pour des choses comme celle-ci en premier lieu. Pourquoi ne pas simplement laisser un terminal vivre où il le souhaite, au lieu de répliquer autant de fonctionnalités dans une interface utilisateur personnalisée.

Alors peut-être qu'à ce stade, il est préférable de considérer les onglets qui sont visiblement différents des onglets de l'éditeur, indiquant qu'ils ne sont _pas_ interchangeables avec les onglets de l'éditeur, pour éviter toute confusion?

Je suis d'accord, les onglets sont une très bonne solution pour sélectionner différentes consoles.

Je pense que le moyen d'activer la fonctionnalité d'association de consoles avec un éditeur serait simplement de modifier un paramètre utilisateur. Une fois activée, l'ouverture d'une console alors qu'un éditeur est sélectionné peut créer l'association. Aussi simple que cela.

L'interface utilisateur serait très probablement que lorsqu'un nouvel éditeur (fichier) est sélectionné en haut de l'application, les onglets de la console en bas changent à mesure que l'éditeur change. C'est assez simple et intuitif.

Je pense que cela ne deviendrait plus complexe que s'ils ajoutaient la possibilité d'associer des consoles individuelles à plusieurs éditeurs, en fonction d'un contexte utilisateur, tel que:

• emplacement du répertoire
• projet
• type de fichier (peut-être lorsque les fichiers sont au même emplacement)
• regroupement d'éditeurs (défini par l'utilisateur)
• une autre abstraction

Cette expérience serait que la console spécifiée reste la même quel que soit l'éditeur sélectionné dans le contexte (ou reste le même car l'utilisateur souhaite que toutes les consoles soient disponibles pour tous les éditeurs).

La façon dont l'interface utilisateur est présentée est l'endroit où les choses doivent faire preuve de créativité afin d'éviter le sentiment de complexité et de garder une sensation intuitive, rapide et facile à utiliser. Avec une bonne conception de l'interface utilisateur, la complexité n'est là que pour l'équipe qui crée la fonctionnalité :)

Pour renforcer l'association d'un onglet de console avec un éditeur, le volet qui contient les onglets de console serait clairement étiqueté avec le nom de l'éditeur.

Et chaque onglet pourrait afficher automatiquement le type de console chargée, comme Git, Node, CMD, Powershell ... au lieu d'afficher le Terminal 1, le Terminal 2, etc. (comme le montre @Perkovec ). Cela serait automatiquement généré par l'application.

Cela permettra à l'utilisateur de sélectionner directement la console de son choix sans parcourir les onglets à la recherche de cette invite git ou powershell.

L'autre option consiste à fournir le moteur d'onglets de base dans le cœur de l'application et à permettre aux utilisateurs d'ajouter une extension de leur choix pour ajouter plus de fonctionnalités à la gestion de la console. À un moment donné, les fonctionnalités qui sont beaucoup utilisées peuvent être intégrées à l'application principale.

Si je vous comprends bien, je suis strictement contre l'association du terminal avec les fenêtres de l'éditeur. La plupart du temps, je n'ai pas de relation fixe entre les onglets de l'éditeur et les terminaux et quand je le fais, ce n'est certainement pas un mappage 1: 1 (généralement même pas 1: N).

@MikeGitb Je suppose que, selon le poids de la préférence de l'utilisateur, l'association par défaut de l'éditeur avec les paramètres de la console peut être activée ou désactivée.

Certains voudront peut-être mélanger les deux, en fonction de ce qu'ils font et de la console qu'ils utilisent. Ce n'est qu'un raffinement du problème UI / UX que les créateurs devraient résoudre. Identique à tout défi UI / UX.

Le cas d'utilisation de l'éditeur contextuel / console UX va être:

• pas de contexte (pas de console associée à un éditeur particulier)
• contexte mixte (certaines consoles associées, d'autres non)
• tout le contexte (toutes les consoles associées à un éditeur)

BTW, je suggère l'association d'une console avec un éditeur comme option pour minimiser la prolifération des onglets de la console (et la confusion / surcharge indésirable), qui était une préoccupation exprimée par quelques personnes. Avec un éditeur / console contextuel UX, les consoles associées seront très probablement masquées dès qu'un éditeur dans un autre contexte est sélectionné. L'utilisateur ne visualise toujours que ce qui est pertinent pour l'éditeur sélectionné.

Comme d'habitude, l'implémentation de l'interface utilisateur va faire ou défaire ce genre de chose. L'équipe VSCode a déjà fait un travail assez incroyable avec l'interface utilisateur et il n'y a aucune raison de penser qu'ils ne pourraient pas trouver comment mettre en œuvre une expérience de gestion de console plus sophistiquée sans rendre les choses compliquées et surchargées.

Comme nous l'avons tous expérimenté auparavant, et de plus en plus avec des logiciels plus récents, il est très possible d'exposer l'utilisateur à un degré de complexité et de sophistication nettement plus élevé tout en rendant l'expérience plus facile et plus simple.

Juste pour comprendre votre cas d'utilisation: puis-je vous demander quel type d'opérations que vous effectuez sur le terminal, qui sont liées à un fichier spécifique, par opposition au projet / répertoire?

Mes cas d'utilisation typiques sont l'utilisation de git, la compilation de mon projet, l'exécution d'un binaire et l'affichage d'une sortie de trace. Tous sont indépendants du fichier actuellement ouvert, mais je l'utilise principalement pour les projets C ++ ou les modifications de fichiers uniques, de sorte que d'autres domaines peuvent nécessiter des flux de travail différents.

À peu près tout le monde utilise des instances de terminal indépendamment des onglets de l'éditeur. Une telle fonctionnalité serait mieux en tant qu'extension.

Oui, je suis d'accord pour étendre l'expérience de la console avec des extensions. Probablement la meilleure façon d'ouvrir ce domaine au développement.

Créer un moteur de console dans VScode sur lequel tout le monde pourra s'appuyer serait une expérience intéressante.

Voici un extrait du fonctionnement de l' IDE Cloud9 :

Il semble avoir ce que beaucoup d'entre nous semblent rechercher: tout nouvel onglet peut être un éditeur ou un terminal, et n'importe quel onglet peut être déplacé et divisé horizontalement ou verticalement.

@plmrry C'est génial! Quelque chose dans cette direction serait vraiment sympa.

@plmrry la question de savoir si nous allions avoir un système de panneaux très flexible comme celui-ci est toujours ouverte. J'aime personnellement la façon dont le panneau est fixé, cela rend les commandes du terminal très claires ce qui va se passer; le terminal de mise au point ouvrira toujours l'espace du terminal unique et focalisera le terminal actif.

S'il y a plusieurs terminaux dans les onglets de l'éditeur, certains au premier plan, d'autres en arrière-plan, alors la question de savoir ce que font certaines commandes de terminal n'est pas aussi claire et ne sera pas aussi intuitive.

les commandes du terminal peuvent-elles simplement cibler celle qui a été focalisée en dernier? de la même manière que cmd + shift + t ciblera l'onglet qui a été fermé en dernier

@btoo c'est probablement ce qu'il ferait dans un tel monde. C'est un changement très radical dans le fonctionnement de VS Code.

Je viens de PHPstorm et le manque d'onglets de terminal est vraiment frustrant, tous les produits Brainstorm ont des onglets de terminal, c'est une fonctionnalité très utile.

En effet une fonctionnalité utile, je demanderais aux développeurs de l'ajouter, cela rendra la vie plus facile là où il faut surveiller plus de 2 choses en même temps, j'aime beaucoup l'idée @plmrry

+1
les onglets du terminal sont plus conviviaux pour l'UX que select et ne prennent pas beaucoup de place

+1

C'est en partie la raison pour laquelle j'utilise toujours l'écran partagé iterm et cmder car je suis capable d'en voir plus d'un à la fois. Il est logique que vscode puisse actuellement s'exécuter plusieurs à la fois, ce qui ajoute la possibilité d'afficher les deux en même temps (qu'il soit divisé horizontalement ou que les onglets ne devraient pas interférer avec les performances).

S'il y avait un problème de performance avec cela, vscode se figerait également si j'exécutais le serveur npm run dans un onglet et mongod dans un autre (ou quelles que soient les multiples commandes que quelqu'un pourrait avoir besoin d'exécuter).

Petite mise à jour à ce sujet: je suis actuellement occupé à rendre le terminal accessible (https://github.com/Microsoft/vscode/issues/8339), après cela, le prochain élément majeur sur lequel je travaillerai sera probablement le fractionnement du terminal (https://github.com/Microsoft/vscode/issues/7504) qui a été dérivé de ce problème (et est probablement ce que beaucoup de personnes qui votent pour cela veulent vraiment) C'est sur la feuille de route https://github.com/Microsoft/vscode/wiki/Roadmap#terminal

@AnthonyMichaelc il n'y a pas de problème de performances avec l'affichage multiple, le terminal est super rapide après les récentes améliorations .

(scission) est probablement ce que beaucoup de gens qui votent pour cela veulent vraiment

@Tyriar J'ai voté pour les onglets parce que je veux des onglets, pas de division. Je soupçonne que la plupart des autres personnes pensaient aussi ce pour quoi elles ont voté - un terminal vertical ou horizontalement étroit ne le fait pas pour moi.

... Je viens de lire tout cela, et je ne peux pas croire que j'ai raté cette idée:

Pourquoi ne pas ajouter des onglets supplémentaires à la barre d'onglets existante, lorsque de nouveaux terminaux sont ouverts?
Problems | Output | Debug Console | Terminal 1 | Terminal 2 | Terminal 3 ...
... aussi, la console de débogage n'est pas très utile si vous n'utilisez pas réellement le débogueur ... juste un aparté.

(et c'est probablement ce que beaucoup de gens qui votent pour cela veulent vraiment)

Je ne collerai que ceci .... (premier message dans ce sujet)

En plus du commentaire de
Par exemple, lors du débogage d'un serveur, je voudrais observer la sortie d'un autre service ou l'observateur de fichiers construisant mon client sans changer de vue tout le temps, pas même via des raccourcis clavier.
J'accueillerais volontiers les terminaux séparés (également sous Windows;) comme point de départ, mais des onglets flexibles placables dans le panneau gauche / milieu / droit amélioreraient considérablement le "pont d'observation" de vscode sans encombrer l'interface utilisateur.

@PixelT La première image de l'article que vous citez est avec des onglets ajoutés, exactement comme le titre l'indique. Peut-être déposer un PR séparé et le lier ici pour le fractionner?

@mikemaccana s'il vous plaît lisez à nouveau en comprenant mon message, car je vois que vous ne le comprenez pas + Je n'ai rien supprimé:]

@PixelT Vous avez raison, j'ai pensé à tort que vous aviez supprimé une image - désolé. Cela dit: le titre et la première suggestion sont les tabulations plutôt que le fractionnement, et un problème distinct pour le fractionnement serait bon.

@mikemaccana fractionnement: https://github.com/Microsoft/vscode/issues/7504

Pourrions-nous avoir la possibilité d'avoir des onglets mais de les désactiver par défaut?

Un aperçu du fractionnement a atterri dans Insiders , consultez https://github.com/Microsoft/vscode/issues/7504#issuecomment -365683609 pour la mise à jour complète.

Je pense que c'est définitivement un pas dans la bonne direction. Je suis sûr que quelqu'un se plaindra pourquoi je ne peux pas mettre 15 terminaux, mais pour moi, cela serait génial. Si je travaille sur quelque chose comme une pile moyenne, je peux avoir un double terminal uniquement pour le nodemon et les mongos, etc., puis ouvrir une autre paire de terminaux pour exécuter le service ng et générer des commandes.

Maintenant, si la version stable de vscode avait cette option et l'autre fonctionnalité de demande d'avoir une disposition de grille que j'attendais tous les rêves deviendrait vrai haha.

Note latérale: je n'ai remarqué qu'en utilisant pendant quelques minutes si j'essayais de basculer rapidement entre opt / alt + cmd / ctrl, la mise au point semblait être un peu en retard. (Peut-être juste moi)

@AnthonyMichaelc

Je suis sûr que quelqu'un se plaindra pourquoi je ne peux pas mettre 15 terminaux, mais pour moi, cela serait génial.

Le plan est en fait d'en permettre autant que vous le souhaitez, je n'ai résolu le problème que pour n = 2 jusqu'à présent.

disposition de la grille

Nous en discutons activement maintenant, il a même sa place dans le plan d'itération de février https://github.com/Microsoft/vscode/issues/43361

Note latérale: je n'ai remarqué qu'en utilisant pendant quelques minutes si j'essayais de basculer rapidement entre opt / alt + cmd / ctrl, la mise au point semblait être un peu en retard. (Peut-être juste moi)

Je n'ai pas encore vu ça mais je vais surveiller la lenteur.

@AnthonyMichaelc

Si je travaille sur quelque chose comme une pile moyenne, je peux avoir un double terminal uniquement pour le nodemon et les mongos, etc., puis ouvrir une autre paire de terminaux pour exécuter le service ng et générer des commandes.

Avoir plusieurs terminaux et éditeur en même temps est très confortable. Dans ma vie quotidienne, j'ai le premier terminal pour le serveur de développement, le deuxième pour les tests unitaires et parfois le troisième pour git.

Il existe un moyen piraté d'archiver cela dans le terminal cmder pour Windows en ouvrant VSC comme l'un des onglets du terminal (ici) Je ne peux pas attendre la solution native pour Visual Studio Code, car il y a des problèmes avec les raccourcis lors de l'utilisation de VSC et Cmder dans par ici.

@Tyriar comme je peux le voir, ce topis concerne les onglets dans le terminal, pas de fractionnement ...?

@PixelT c'est clairement lié. Beaucoup de gens ont déclaré dans ce numéro de pouvoir voir plusieurs terminaux en même temps que le fractionnement résoudra pour le moment, ils le trouveront donc utile.

Je ne peux pas être d'accord avec vous - ce sujet observe et discute principalement des personnes qui veulent des onglets dans le terminal, pour le fractionnement du terminal, il y a un autre sujet: https://github.com/Microsoft/vscode/issues/7504 que vous avez créé :)

Les onglets et le fractionnement des terminaux sont aujourd'hui des normes dans presque tous les IDE modernes.

Passé à Insiders build pour tester cela, fonctionne à merveille, merci @Tyriar !

toujours rien ne se passe à propos des onglets dans le terminal ... 😕

@PixelT Avez-vous essayé la version d'initié qui a le double terminal? D'après ce qu'ils ont dit, ils prévoient de le faire afin que vous puissiez ouvrir autant de terminaux dans cette mise en page que vous le souhaitez, mais je crois que la version d'initié autorise actuellement 2 avec la commande: cmd / ctrl + d je crois

@Morkowski Je vois ce que vous avez fait Oui, j'ai une fenêtre et un ordinateur portable osx, donc quand je suis sur l'ordinateur Windows, j'utilise cmder comme ça, quand sur l'ordinateur osx j'utilise iterm et crée au moins 2 à 3 dans une grille layout et 4 lorsque vous travaillez dans une application de pile moyenne.

Hey @Tyriar, petit commentaire - lors du redimensionnement de la console à l'aide des boutons Maximize Panel Size ou Restore Panel Size (ou d'un raccourci clavier), la largeur des volets de la console est oubliée et la largeur de chaque volet est remise à un montant égal.

Lors du redimensionnement de la console vers le haut / bas à l'aide de la souris, les largeurs sont mémorisées.

De même, les largeurs sont oubliées lors du masquage ou de l'affichage de la barre latérale gauche.

Enfin, les largeurs sont oubliées lors de l'ajout ou de la suppression d'un volet - bien que ce soit le plus compréhensible.

J'espère que cela t'aides!

@jamesjryan , un problème a été résolu dans le dernier initié pour les 2 premiers que vous mentionnez https://github.com/Microsoft/vscode/issues/45074

De même, les largeurs sont oubliées lors du masquage ou de l'affichage de la barre latérale gauche.

Je ne peux pas reproduire la dernière, veuillez créer un problème si vous le voyez.

Enfin, les largeurs sont oubliées lors de l'ajout ou de la suppression d'un volet - bien que ce soit le plus compréhensible.

Ouais c'est comme prévu 🙂

Quelqu'un écrit sur le terminal fractionné, pas sur les onglets de terminal ici encore. Ce n'est pas ce que nous aimerions voir lors de la réception des notifications de ce ticket :(

7504

@Tyriar mis à jour - fonctionne comme décrit, merci!

@KillyMXI c'est une progression vers l'objectif final, et une implémentation très utile même dans sa forme actuelle.

@isidorn Je me demande si vous avez réfléchi à la manière dont nous soutiendrions initialement quelque chose comme ça. Lorsque j'ai ajouté des onglets dans le terminal juste après l'ajout du terminal, je devais revenir en arrière parce que tout le monde était contre les onglets dans les onglets, que se passerait-il si nous faisions des onglets d'en-têtes de panneaux comme ceci:

Je ne sais pas vraiment comment gérer les titres parfois volumineux et j'ai besoin de dire terminal ici pour le dissocier des autres. Cela dit, ce serait ma configuration typique avec (deux onglets, dont l'un est divisé) et il s'adapte facilement à l'écran de mon ordinateur portable lorsqu'il est maximisé, même sans cacher les autres titres du panneau.

Je pense que le jeu final donne à l'utilisateur la flexibilité de placer les terminaux où il le souhaite, mais peut-être s'agit-il d'une bonne solution provisoire?

@jamesjryan Je ne vois pas la solution du Tyriar comme la progression vers les onglets. Cela me semble complètement orthogonal.

Il y a beaucoup de choses utiles autour, mais elles ont des endroits appropriés. Le bon endroit pour le terminal partagé est un billet différent.

Enfin, nous revenons aux onglets.

Une chose similaire a été proposée ci-dessus, en fait: https://github.com/Microsoft/vscode/issues/10546#issuecomment -359632932
C'est la chose la plus évidente lors du remplacement de la liste déroulante par la liste des terminaux.

J'aurais essayé de

• alignez les languettes des bornes vers la droite;
• ou ajoutez une ligne verticale avant les terminaux;
• ou alignez-vous à droite et affichez une ligne verticale lorsqu'ils se sont rapprochés des éléments sur la gauche.

Je préfère éviter de mettre le mot «Terminal» sur chaque onglet. Il sera assez clair de quoi il s'agit.
Ou peut-être utiliser le mot «Terminaux:» comme une sorte de séparateur visuel.

Problems   Output   Debug Console                  Terminals:  Git   Bash, Bash   +   []   ^

C'est donc un peu le résultat final que j'espère ici:

Tiré de https://atom.io/packages/terminal-tab

C'est simple et facile à comprendre et donne la flexibilité à l'utilisateur final quant à la façon dont il souhaite diviser / structurer son IDE.

Je suis confus. Nous pouvons déjà avoir un terminal en bas, à droite, à gauche ou en plein écran.

Nous pouvons déjà avoir un terminal en bas, à droite, à gauche ou en plein écran.

Nous faisons? Comment créer un terminal sur le côté gauche? Pour le moment, je ne peux voir que le bas ou le côté droit.

Vous ne pouvez pas faire de gauche mais quand même, je suis confus par ce gif. lol

Je ne suis pas sûr du plugin Atom (je ne peux pas dire que je l'ai utilisé), mais je suppose que vous pouvez ouvrir plusieurs terminaux, ils seraient tous traités comme des onglets individuels.

Plus important encore, ils se comportent de la même manière que les onglets normaux de l'éditeur, ils peuvent aller aux mêmes endroits que vous avez votre code. Le Web IDE Cloud9 fait une chose très similaire à cela. Vous pouvez ouvrir autant de terminaux que vous le souhaitez, et vous êtes libre de les placer où vous le souhaitez sur votre espace de travail à l'intérieur de la mise en page écran partagé + onglets.

Peut-être que je comprends mal le problème, mais fondamentalement, les concepteurs UX s'inquiètent de la confusion entre les différents types d'onglets.

Je cacherais juste la barre d'onglets par défaut et aurais 1 "onglet" visible. Gardez la chose déroulante.

Ensuite, une fois qu'un nouveau terminal est lancé, si une option est définie par l'utilisateur, supprimez la liste déroulante et affichez une barre d'onglets.

Est-ce que je manque quelque chose?

Je pense qu'il serait préférable de faire du terminal un onglet comme les autres onglets de l'éditeur, et de laisser simplement l'utilisateur décider de la manière dont il souhaite disposer les fenêtres.

C'est ce que le gif "déroutant" ci-dessus essaie de démontrer.

Oui, désolé si le gif rendait les choses plus déroutantes, mais c'est essentiellement la prémisse à laquelle j'essayais d'arriver.

En ce qui concerne les concepteurs UX qui s'inquiètent de la confusion, je pense que si vous ouvrez un terminal, vous savez probablement ce que vous faites et ce n'est pas du tout déroutant.

En guise de solution de contournement, j'ai configuré les raccourcis clavier suivants:

{
  "key": "cmd+right",
  "command": "workbench.action.terminal.focusNext"
}
{
  "key": "cmd+left",
  "command": "workbench.action.terminal.focusPrevious"
}

Cela me permet de basculer rapidement entre les terminaux sans avoir besoin d'utiliser la souris et ce vilain sélecteur.

@vedmant, vous pouvez affiner cela pour ne fonctionner que lorsque le terminal est concentré si c'est également préférable:

{
  "key": "cmd+right",
  "command": "workbench.action.terminal.focusNext",
  "when": "terminalFocus"
}
{
  "key": "cmd+left",
  "command": "workbench.action.terminal.focusPrevious",
  "when": "terminalFocus"
}

Désolé si quelque chose comme ça a déjà été suggéré (je n'ai fait que parcourir les commentaires) ou peut-être devrais-je en faire un nouveau numéro. Dans tous les cas, faites le moi savoir.

Compte tenu des progrès réalisés avec le numéro 14909. Pourrions-nous avoir une option pour mettre le terminal dans un onglet normal qui est traité du point de vue de l'emplacement de la même manière que n'importe quel autre onglet? Cela donnerait une tonne de flexibilité aux utilisateurs sur la façon dont ils veulent voir leur terminal. Il y a maintenant (ou plutôt bientôt) tellement de flexibilité dans la façon d'afficher et d'organiser les onglets normaux que le terminal est maintenant très limité par comparaison.

@Tyriar workbench.action.terminal.focusPrevious ne semble pas fonctionner

J'ai aussi essayé workbench.action.terminal.focusPreviousPane car c'est ainsi que les Kebindings par défaut l'utilisent, mais cela ne fonctionne pas ( workbench.action.terminal.focuNextPane ne fonctionne pas aussi bien)

donc en bref: seulement workbench.action.terminal.focusNext fonctionne

    {
        "key": "ctrl+pagedown",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },
    {
        "key": "cmd+pageup",
        "command": "workbench.action.terminal.focusPrevious",
        "when": "terminalFocus"
    }

Versions de VSCode

Version 1.24.1
Commit 24f62626b222e9a8313213fb64b10d741a326288
Date 2018-06-13T17:47:35.732Z
Shell 1.7.12
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64

Système d'exploitation: lubuntu 18.04

Testé sans extensions

Éditer

Merci Tyriar, j'ai écrit cmd au lieu de ctrl ci-dessus

@caub, vous devriez créer un nouveau problème si vous voulez de l'aide (cela a toujours bien fonctionné pour moi sur Ubuntu 18 cependant).

Récemment réalisé un problème avec le fait d'avoir le terminal là où il se trouve: il est impossible de voir l'onglet problèmes en même temps.

Je suppose que vous avez un espace de travail avec plusieurs projets. Ce que vous pouvez faire, c'est avoir un terminal par projet, et avoir une extension de focus sur le terminal correspondant en fonction du fichier ciblé dans l'éditeur (et sur le projet auquel il appartient)

Cela ne résout pas votre problème particulier, mais facilite le changement et la détection des problèmes

Je suis d'accord que la sélection du terminal n'est vraiment pas pratique, il n'y a que des chiffres: 1: bash , 2: bash , .. il serait bien mieux d'afficher le nom de base du dossier plutôt

@caub voir https://github.com/Microsoft/vscode/issues/29816

Avec plus de pratique, je me rends compte que cette proposition Tabs est le meilleur moyen: +1:, actuellement j'utilise toujours mes propres terminaux OS indépendamment de VSCode, car la sélection des terminaux le rend pas pratique, même avec de meilleurs noms, ce ne serait toujours pas assez pratique

Je pense aussi que cela pourrait être bien résolu si le terminal pouvait vivre comme une partie de la disposition de la grille, et aurait beaucoup plus de sens du point de vue UX - où tout peut être cassé n'importe où.

@mrmckeb D'accord. Je ne sais pas comment ils pourraient gérer les onglets et les fractionnements, mais c'est faisable. Tmux le fait.

J'espère que nous arriverons aux terminaux d'ancrage également dans les volets de l'éditeur de texte, ce serait déjà très flexible.

Je regarde ce problème depuis un certain temps et j'espère toujours que cela sera implémenté. Je vois que des problèmes similaires sont ouverts assez régulièrement. J'espère pouvoir récapituler exactement ce qui est demandé et pourquoi (du moins de mon point de vue).

Quoi

Fondamentalement, ce que j'espère, c'est qu'un nouveau terminal peut éventuellement être créé en tant que _editor tab_, reproduisant essentiellement le comportement de cette extension Atom (que j'ai chèrement manquée depuis le passage d'Atom à VSCode). Lorsqu'un nouvel onglet de terminal est créé, il est traité de la même manière qu'un onglet d'éditeur et est placé dans un groupe d'éditeurs. Les onglets de terminal sont traités dans l'interface utilisateur de la même manière que les onglets de l'éditeur.

Les onglets des bornes n'ont pas besoin d'être interchangeables avec les bornes du panneau pour démarrer; ils pourraient être créés en tant qu'entités totalement distinctes au départ pour recueillir des commentaires.

Pourquoi

Je vis pratiquement dans le terminal, et avoir des onglets de terminal de cette manière résout tous les problèmes et cas d'utilisation suivants:

• Voir et utiliser plus de deux terminaux simultanément. Facilement fait en organisant trois terminaux ou plus comme je le souhaite sur la grille de l'éditeur.
• Utilisez VSCode comme mon seul émulateur de terminal, en ouvrant une fenêtre VSCode avec uniquement un onglet de terminal.
• Avoir de nombreux terminaux ouverts en même temps, mais je ne veux pas regarder maintenant.

Même dans un monde d'onglets terminaux, je trouverais utile l'existence du panneau distinct des groupes d'éditeurs et je ne préconiserais pas la suppression du panneau. Le panneau a du sens pour placer les informations auxiliaires distinctes du _ contenu principal_ avec lequel je travaille. La clé est que, pour moi, un terminal est généralement un _ contenu de première classe_ avec lequel je travaille, et pas simplement un contenu auxiliaire. Dans cette perspective, il est tout à fait naturel que les terminaux cohabitent avec les éditeurs.

@sagebind Je vois la première étape vers cela comme l'activation des onglets de terminal dans le panneau, essentiellement en remplaçant la liste déroulante par quelque chose de moins horrible. Cela pourrait ensuite être construit de la manière suivante:

1. Permettre au panneau d'être placé de manière plus flexible https://github.com/Microsoft/vscode/issues/57029 , https://github.com/Microsoft/vscode/issues/50984 , https://github.com/Microsoft/ vscode / issues / 37877 , https://github.com/Microsoft/vscode/issues/10121
2. Étudiez pour permettre à des terminaux individuels de "se détacher" du panneau et d'être placés dans la grille de l'éditeur comme vous en parlez (en quelque sorte suivi dans ce numéro). Cela nécessite un peu de travail pour comprendre les impacts sur l'UX, les commandes, les raccourcis clavier et l'API d'extension.

De plus, @sagebind ,

Et si vous êtes un joueur de la vieille école, il a une liste déroulante de style tremblement de terre (Ctrl + ~). Donc, tous mes terminaux restent cachés, jusqu'à ce qu'il soit temps.

Je pense que cette extension montre comment créer des onglets de manière propre.

https://marketplace.visualstudio.com/items?itemName=Tyriar.terminal-tabs

@PauloDanielCarneiro Cette extension est en fait faite par l'un des principaux développeurs de VSCode lui-même (@Tyriar)

Je sais que ce problème est ancien, mais ce serait incroyable

C'est exactement la fonctionnalité manquante qui empêche tous les administrateurs système de passer complètement d'ISE à VSCode.

En tant que SysAdmin, je passe la plupart de mon temps à travailler simultanément sur plusieurs ordinateurs.

Je me connecte à un ordinateur distant avec CTRL + SHIFT + R.
Cela ouvre un nouvel onglet de terminal nommé avec le nom d'ordinateur auquel je suis connecté.
Et chaque onglet de terminal est lié à un ou plusieurs onglets de script ci-dessous.
Je passe des onglets de script à l'onglet terminal et vice-versa avec CTRL + R.

C'est si facile, pratique et puissant à la fois ...

Cette fonctionnalité est-elle envisagée?

Pas un remplacement, mais vous pouvez utiliser cmd-\ pour diviser votre terminal

Merci @ Hum4n01d c'est encore mieux, je ne savais pas à ce sujet.

@ Hum4n01d Dans mon cas, je peux diviser le terminal avec Ctrl+] , ou simplement en cliquant sur l'icône pour diviser le terminal dans le coin supérieur droit de la fenêtre du terminal, à côté de l'option Kill Terminal .

Si je n'ai besoin que de 2 ou 3 terminaux, je considère cette fonctionnalité très utile (encore mieux que les onglets, car je n'ai pas besoin de passer d'un onglet à un autre pour voir le terminal).

Uniquement dans le cas où j'ai besoin de plusieurs terminaux, cela pourrait ne pas être une solution, bien que les onglets ne soient pas non plus (en soi), au lieu de cela, il faudrait quelque chose comme des onglets + des fenêtres flottantes (https://github.com/Microsoft/vscode / issues / 10121).

Je crois toujours que la meilleure approche ici est celle avec laquelle l'équipe Atom a opté pour des terminaux interchangeables avec des onglets de code. De cette façon, les utilisateurs peuvent créer l'espace de travail de leur choix de manière modulaire.

Les onglets dans la zone du terminal seraient cool, mais pourquoi investir dans cela alors que le temps pourrait être passé à autoriser les onglets de code à envelopper les instances de terminal?

Bonjour. Je suis allé chercher un problème que je rencontre et je me suis retrouvé ici.

La seule chose que je souhaite faire est d'utiliser un terminal comme onglet d'éditeur régulier

Mon écran d'ordinateur portable de 15 pouces n'est tout simplement pas assez grand pour jouer avec les petits terminaux entassés dans un panneau de section de sortie de construction. Il fonctionne bien pour les versions, mais il peut être inapproprié pour une utilisation sur terminal.

Si je redimensionne le panneau pour qu'il soit grand pour que je puisse y faire un travail réel, cela n'a soudainement aucun sens que la fenêtre contextuelle de sortie de construction devienne super grande. Et si je le fais petit pour qu'il soit approprié pour la sortie de construction, alors il est inutilisable pour le travail de terminal. Ces concepts d'interface utilisateur ne se mélangent pas et en ajoutant dans la barre d'onglets, il y a plus de folie.

Et si je ne veux littéralement pas que le travail que je fais dans un terminal fasse partie d'un panneau qui bascule entre les onglets lorsque j'exécute des tâches? Ou pop up et down dynamiquement? Pour que chaque fois que je construis, je change maintenant les onglets dans un autre système d'onglets ? Et puis revenir à ce sur quoi je travaillais dans le terminal? Oh, donc la solution est que nous pouvons diviser le panneau ... Cela devient plus fou, et vous avez une reproduction du même système d'interface utilisateur que VSCode a déjà. Cela n'a aucun sens.

Ce serait une mauvaise idée de transformer le Panel en un système d'interface utilisateur parallèle avec des idiomes concurrents. Diverses personnes essaient de le faire avec de mauvais hacks et des solutions de contournement dans les extensions. Ce serait donc bien que Microsoft prenne le contrôle de la situation en résolvant le problème.

@Zyrsha - dans ce cas, pourquoi utilisez-vous VS Code? Il semble que vous obtiendrez plus de valeur en utilisant directement le terminal fourni avec votre système d'exploitation, avec plusieurs onglets. Question honnête / lecteur très confus.

BTW vscode est le premier et le seul IDE où j'utilise un terminal. Sur mon ordinateur portable 13 ", cela fonctionne très bien pour moi. Pour d'autres IDE comme eclipse ou webstorm, je suis très heureux d'utiliser Awesome WM pour commander rapidement des commutateurs et des fenêtres.

Je pense que l'idée d'utiliser le terminal (ou toute autre "fenêtre") comme onglet normal est agréable et cela fonctionne en éclipse. Mais le terminal a un flux de travail légèrement différent, du moins pour moi. J'ai besoin d'une possibilité de basculer rapidement vers le «bon» terminal. Comme d'autres, j'utilise les onglets Terminal pour cela:

ce qui n'est malheureusement pas parfait à cause de problèmes comme celui-ci. De plus, je ne comprends pas pourquoi vsc ne devrait pas avoir un terminal sophistiqué intégré.

@ shane-smith

le terminal réel fourni avec votre système d'exploitation, avec plusieurs onglets.

Eh bien, l'application Console fournie avec Windows ne prend pas en charge les onglets AFAIK. Alors c'est fini. Et Linux ne "vient pas avec" un émulateur de terminal en soi (une distribution pourrait), vous devez en choisir un que vous aimez. Dans ce cas, il semble que @Zyrsha aime être VS Code, s'il peut être amélioré un peu.

@sagebind

Dans ce cas, il semble que @Zyrsha aime être VS Code, s'il peut être amélioré un peu.

Oh, je suis d'accord - le terminal dans VS Code est génial. Et je commente cette question parce que je suis d'accord qu'il y a une marge d'amélioration.

La partie qui me trouble, c'est qu'il semble que l'autre personne veuille utiliser le terminal pour éditer tous ses fichiers - je me demande donc pourquoi ils utiliseraient VS Code, s'ils n'utilisent pas réellement le intégré éditeur de fichiers du tout? En relisant leur commentaire, j'ai peut-être sauté aux conclusions et ils ne veulent éditer que certains fichiers dans le terminal, pas tous.

Bonjour.

La partie qui me trouble, c'est qu'il semble que l'autre personne veuille utiliser le terminal pour éditer tous ses fichiers - je me demande donc pourquoi ils utiliseraient VS Code, s'ils n'utilisent pas réellement le intégré éditeur de fichiers du tout? En relisant leur commentaire, j'ai peut-être sauté aux conclusions et ils ne veulent éditer que certains fichiers dans le terminal, pas tous.

Non, ils veulent juste avoir des onglets de terminal comme des onglets d'éditeur, exactement ce que nous avons sur Cloud9, Atom et certains autres éditeurs (même Vim et Emacs). Pour les personnes qui utilisent Mac ou Linux, il est naturel d'avoir des éditeurs en haut de la fenêtre et des onglets de terminal en bas.

Même Theia-IDE peut avoir plusieurs onglets de terminal et il est basé sur certaines parties de VSCode.

Jetez un œil à ces captures d'écran et vous comprendrez:

https://discourse-cdn-sjc1.com/business5/uploads/trydiscourse4/optimized/2X/a/a6c21ba006e249a65bb0c4c2ecf94296d6daad20_1_666x500.png

https://lh3.googleusercontent.com/eI50dceQrsPJDhqQmM_QMjd4rkORHRRd_Y3rbnD1M6KYbKulXI72PFC-A0y-SDraVJAXhGTFcg=w640-h400-e365

Ok, ignorons le pourquoi pendant un moment et concentrons-nous sur le comment:

Comment cela serait-il mis en œuvre? Y a-t-il une raison architecturale pour laquelle les terminaux sont à leur emplacement actuel?

Serait-il possible de manière efficace qu'un plugin fournisse des terminaux dans des onglets?

      Ok, let's ignore the why for a moment and focus on the how:

Comment cela serait-il mis en œuvre? Y a-t-il une raison architecturale pour laquelle les terminaux sont à leur emplacement actuel?
Serait-il possible de manière efficace qu'un plugin fournisse des terminaux dans des onglets?

Côté architectural:

• VSCode possède de nombreux onglets de script liés à une seule console (console intégrée PowerShell), ce qui est très utile pour tester plusieurs scripts sur une seule machine . Cependant, même lorsque vous ajoutez plus de terminaux, tous les onglets de script restent liés à la même console intégrée PowerShell.
  Au début, VSCode a été écrit par des développeurs pour des développeurs.

• ISE a été construit de la manière opposée: vous pouvez ouvrir plusieurs consoles et à chaque console, vous pouvez lier plusieurs onglets de script (c'est très bon pour travailler simultanément sur plusieurs ordinateurs).
  Nous écrivons et exécutons simultanément plusieurs scripts sur différents ordinateurs .
  Au début, ISE a été conçu pour les administrateurs système.

Fortunatelly, la manière ISE (onglets de script liés aux onglets de la console) fonctionne également pour les développeurs.
Mais la méthode VSCode actuelle (onglets de la console liés à un seul onglet de script) ne convient pas aux administrateurs système.
Si vous ne voulez pas ou ne pouvez pas inverser le chemin (des scripts liés aux consoles aux consoles liées aux scripts) au moins nous devrions être en mesure de choisir à quel onglet de console nous voulons lier chaque onglet de script ...

Je ne sais rien sur ISE, mais je veux vraiment pouvoir avoir le terminal dans son propre onglet ou fenêtre, plutôt que fixé en permanence au bas de l'écran. Je n'aime pas avoir à ajuster la hauteur pour passer d'un fichier de code à un terminal.

De plus, bien que les onglets de terminal ne résolvent pas le problème de vouloir plus d'un terminal actif, d'un point de vue UX, il serait toujours préférable d'avoir les terminaux dans les mêmes onglets que ceux utilisés pour les fichiers. Cela garantit que vous disposez de deux raccourcis clavier standard pour changer d'onglet, au lieu de deux standard et de deux pour les onglets de terminal (sans inclure les raccourcis clavier pour passer à un onglet de terminal spécifique). Le flux de travail pour fractionner l'éditeur à l'aide de ces onglets, ou déplacer des onglets vers d'autres fenêtres VS Code, ou tout ce que vous pouvez faire avec les onglets, serait alors le même et créerait une UX standard. Dans l'état actuel des choses, vous avez deux flux de travail UX différents, et vous ne gagnez pas grand-chose à avoir les deux.

Je comprends pourquoi cela n'a peut-être pas été fait jusqu'à présent, ou pourquoi nous avons des onglets de terminal comme solution de contournement, mais des terminaux dans les onglets / tampons de l'éditeur / tout ce qui est fait dans Emacs, Atom, etc., en standard Expérience UX, que j'aimerais aussi voir dans VS Code.

Maintenant que Nuclide est obsolète, j'aimerais passer à VS Code, mais j'aime vraiment pouvoir lire toute la sortie de construction sur le terminal - ce qui est très difficile avec VS Code. Pourquoi le terminal doit-il être forcé à un endroit spécifique et ne pas être traité de la même manière que tous les autres onglets / fenêtres?

Pour moi, le principal problème est que je ne peux pas voir combien de terminaux j'ai ouverts sans passer par la souris. Et il n'y a aucun moyen de savoir dans quelle direction vous devez vous diriger pour vous rendre à un terminal particulier sans faire de vélo arbitraire. Les onglets ont été ma première pensée, mais je suppose qu'il existe d'autres moyens de résoudre ce problème. Vous pouvez, par exemple, éventuellement afficher les terminaux actifs dans la barre de l'explorateur, avec le terminal actif en surbrillance.

Comment cela serait-il mis en œuvre?

Pour linux, nous pourrions l'implémenter comme un cas particulier d'une approche plus générale: exécutez des commandes définies par l'utilisateur et fournissez-leur un identifiant de fenêtre X du nouvel onglet. Nous pourrions alors lancer xterm … -into $VSCODE_TAB … pour le terminal, mais aussi intégrer d'autres trucs très facilement. Ce serait également bien s'il y avait une commande CLI pour rechercher une instance VSCode par répertoire de projet (par défaut dans le répertoire de travail où la commande a été exécutée), ouvrir un onglet dans cette instance et imprimer l'ID win X sur stdoutet le $DISPLAY VSCode si différent ainsi tous les utils externes pourraient rejoindre l'interface graphique de VSCode.

Edit 2: Je vais ouvrir un nouveau ticket pour cette idée car il ne s'agit pas vraiment de terminaux.

non !!! l'onglet rend l'interface utilisateur mauvaise ....

@ donnisnoni95

non !!! l'onglet rend l'interface utilisateur mauvaise ....

Je suis très optimiste, il sera facile de les désactiver et / ou de les masquer.

Convertissez simplement la liste déroulante en boutons et stylisez-les de la même manière que les onglets de l'éditeur principal.

Juste pour être clair, je voudrais que les onglets soient interchangeables avec tous les autres onglets (par exemple les onglets de code source). Tout comme dans Atom.

Pour être clair, je prendrai les solutions de @floydnoel étant donné que la demande des OP est passée inaperçue depuis 2016

@kitsirota Cela a été remarqué et figure sur la feuille de route de cette année. Ils savent que cela, et un problème connexe pour les fenêtres flottantes, sont les deux fonctionnalités les plus demandées. Je ne sais pas quand il sera commencé ou terminé, mais peut-être que @Tyriar a plus d'informations à ce sujet.

J'espère que cela attirera bientôt l'attention en raison de la demande, je le veux vraiment aussi. De plus, comme @jaxspades l'a mentionné, c'est sur la feuille de route.

En attendant cela et des fenêtres flottantes depuis le premier jour, j'ai commencé à utiliser VSCode. J'utilise actuellement ConEmu. Ce n'est tout simplement pas pratique le terminal connecté et déroulant actuel.

Juste une note (alors que les onglets devraient certainement être ajoutés à vscode) si vous utilisez toujours ConEmu, vous voudrez peut-être essayer Windows Terminal.

J'attends toujours ça :)

Je voudrais juste voir "Output" et "Debug Console" en même temps.

Je n'ai pas nécessairement besoin d'onglets, mais je veux voir les problèmes et le terminal en même temps. Cependant, il peut être difficile de les différencier sans une sorte d'étiquette et, par conséquent, un onglet pourrait être préférable. Je pense donc que le panneau divisé pour le terminal devrait être supprimé et permettre des onglets supplémentaires pour tous les types de panneaux (Problèmes, Sortie, Terminal, etc.) Bien que je ne puisse pas vraiment voir à quel point plusieurs onglets "Sortie" ou "Problème" seraient nécessaires comme les données seraient identiques. Alors peut-être que lors de l'ajout d'un nouvel onglet et de la sélection du type d'ajout, si Problèmes est déjà ouvert, il est grisé et désactivé pour l'ajout d'un deuxième et seul Terminal est autorisé pour plusieurs. Cliquez également sur l'indicateur Problèmes et avertissements dans la barre d'état pour ouvrir automatiquement un nouvel onglet Problèmes en cliquant dessus et s'il est déjà ouvert, il le supprime.

Bien que je ne puisse pas vraiment voir comment plusieurs onglets "Sortie" ou "Problème" seraient nécessaires car les données seraient identiques.

• Constellations multi-utilisateurs créatives au-delà du mappage classique 1: 1 des écrans / claviers / foyers d'entrée aux utilisateurs.
• Un seul utilisateur distribuant les outils utilisés pour résoudre les problèmes sur plusieurs écrans ou régions d'écran. Dans ce cas, il serait utile d'avoir des paramètres de filtre, de position de défilement, etc. indépendants pour chaque panneau Problèmes / Sortie.
• Contournement de bogues exotiques / fonctionnalités manquantes dans votre logiciel de screencasting.

@Tyriar @jaxspades sont 1754: +1: et 187: heart: pas assez? Et 34: fusée :? Combien ça devrait être?

C'est toujours ouvert?!

Cela aiderait-il à financer ce projet? Où dois-je mettre mon argent?

@Bessonov Je veux des onglets de terminal mais je ne suis pas chez Microsoft donc je n'ai rien à dire. Je les veux cependant en tant qu'éditeur, pas dans cette petite fenêtre en bas de l'écran. Donc, la version 1.43 vient d'être livrée avec les éditeurs de recherche, donc j'espère que les terminaux suivront bientôt. @Tyriar , les éditeurs de recherche nous aident-ils à nous rapprocher des onglets / éditeurs de terminaux?

Modifier: Ajout d'un lien vers le problème des éditeurs de recherche.

23931

Encore une fois, c'est sur la feuille de route, cela arrivera à temps. Vous n'avez pas besoin de me le dire, je le veux probablement plus que tout le monde ici et je suis bien conscient que c'est la deuxième question la plus votée. Cependant, ce n'est pas une tâche aussi triviale que cela puisse paraître à première vue. Nous investissons activement dans une disposition d'établi flexible:

• Rechercher dans le panneau
• Rechercher dans l'éditeur
• Toutes les vues de panneau et de viewlet sont interchangeables

Tous ces efforts contribuent à la façon dont ce problème sera finalement résolu et bloquent en grande partie le travail sur le terminal, par exemple, la conception que nous envisageons pour ce dernier élément soulève des questions très importantes sur le fonctionnement des onglets dans le terminal. par opposition aux vues de panneau.

Je les veux cependant en tant qu'éditeur, pas dans cette petite fenêtre en bas de l'écran.

Bien que j'aie essayé de séparer les concepts en questions distinctes il y a longtemps, ce numéro couvre maintenant quelques points; onglets dans le panneau de terminal, onglets de terminal dans l'éditeur et onglets de terminal pouvant être déplacés entre les deux.

Merci pour les mises à jour @Tyriar. Cela semble génial - résoudre tous ces problèmes ensemble a beaucoup de sens. S'il existe des possibilités de test utilisateur, faites-le nous savoir.

Je ne suis pas sûr que cette idée ait été mentionnée, même si j'ai parcouru tous les commentaires:
Nous avons (également) besoin d'onglets de terminal non pas à cause de l'apparence, mais parce qu'actuellement, tous les onglets de l'éditeur sont liés au même terminal.

Actuellement, si je veux sortir la série d'éditeurs dans un autre terminal, je dois ouvrir une nouvelle console VS Code.

Être capable de lier un volet éditeur à un autre terminal est particulièrement utile lorsque vous souhaitez exécuter le code de différents volets éditeur sur différents ordinateurs. Avec ISE, vous pouvez le faire dans la même console.
Actuellement avec VS Code, vous devez ouvrir autant de consoles que d'ordinateurs sur lesquels vous souhaitez exécuter le code de votre éditeur.

@Tyriar ,
En plus de vos notes, j'aimerais aussi pouvoir voir "Problèmes" et une fenêtre "Terminal" en même temps côte à côte. J'espère que c'est également possible.
Merci

@ fullenw1 idée intéressante dont je n'avais pas encore entendu parler, merci!

@ggedde, nous discutons activement de la façon dont cela fonctionnerait dans les réunions UX.

Une fois le problème # 10121 résolu, ce sera plus que jamais une bonne fonctionnalité.

Les panneaux de bornes ont besoin d'un en-tête quelconque.

Il est impossible de savoir quel panneau correspond à quel chemin lorsque vous avez plusieurs observateurs

@IceSentry J'ai eu un problème mais @Tyriar a dit que c'était un double de celui-ci. J'ai supposé que c'était lié parce que @Tyriar a fermé le mien en faveur de cela ... non, je n'ai pas lu 6 ans de dialogue :)

Je ne sais pas si quelqu'un l'a encore signalé, mais les onglets Terminal qui sont interchangeables dans l'interface utilisateur avec les onglets Editor, ainsi qu'une console d'interface utilisateur fixe, sont tous deux des fonctionnalités de l'IDE Cloud9, si vous voulez un exemple de la façon dont je ' Je m'attends à ce que cela fonctionne. Vous n'avez même pas besoin de vous débarrasser de l'ancien volet Terminal - faites-le simplement pouvoir être masqué (tel qu'il est maintenant) et remplaçable par un volet "éditeur" ordinaire contenant des onglets Terminal.

Une autre bonne chose à propos des terminaux dans Cloud9 était qu'ils se connectaient à des instances tmux (IIRC) plutôt qu'à des terminaux directs. Cela a permis au frontend de redimensionner (c'est-à-dire de s'arrêter) sans perdre les processus du terminal, et de se connecter en douceur à un nouveau client (une fonctionnalité qui serait très utile pour les utilisateurs de cloud VS Code), et même de partager des instances de terminal client avec d'autres (hyperviseur -level) utilisateurs.

Il existe des extensions pour le faire pour le VS Code Terminal intégré, mais si vous recherchez une abstraction pour les terminaux, ce serait cool de le regrouper dans dtach ou abduco .

Onglets de terminal interchangeables dans l'interface utilisateur avec les onglets Editeur

C'est tout simplement génial.

Nous pourrions nous débarrasser de la console inférieure et transformer tous ses volets (Problèmes, Sortie, Console de débogage et tous les terminaux) en onglets d'édition réguliers, qui peuvent être ouverts au besoin, chaque type de volet ayant une icône spécifique.

À titre de référence, les pages d'informations sur l'extension, l'interface utilisateur des paramètres, les raccourcis clavier et probablement d'autres choses sont déjà gérées de cette manière, comme des onglets d'éditeur réguliers avec une icône personnalisée.

Cela permettrait aux utilisateurs de diviser et d'organiser leurs terminaux à leur guise, en utilisant les fonctionnalités existantes pour diviser et organiser les onglets de l'éditeur.

Bien sûr, les terminaux devraient continuer à fonctionner en arrière-plan même après la fermeture de l'onglet de l'éditeur respectif, qui pourrait être rouvert si nécessaire. La suggestion supplémentaire d'utiliser tmux ou dtach pour maintenir la session de terminal en cours d'exécution lors des redémarrages de VSCode est également une excellente idée, mais appartient à un problème différent.

Avec la nouvelle API Webview, nous pouvons probablement déjà le faire jusqu'à un certain point.
Mais cela signifie que vous devez écrire vous-même toute la gestion de launch.json, ce qui n'est pas idéal.

Cependant, il y a un avantage à en faire juste un «onglet» d'éditeur, car l'onglet d'éditeur peut avoir des gestionnaires de sérialisation / désérialisation.
Il est ainsi possible de donner au terminal le comportement de sauvegarde et de restauration. (comme, enregistrez l'ID de session tmux et rattachez-le à la restauration)

POC: https://github.com/mmis1000/Vscode-terminal-tab

@ mmis1000, il est certainement possible de construire avec l'API webview maintenant, mais il manquera toutes les intégrations, commandes, fonctionnalités telles que la gestion des liens, l'accès à l'API d'extension et agira simplement comme une chose distincte en général.

La fonctionnalité d'enregistrement et de restauration est suivie dans https://github.com/microsoft/vscode/issues/20013

@Tyriar J'ai en fait Terminal place et à l'utiliser comme instance pty sous-jacente, donc au moins des choses comme l'intégration git fonctionneront (on dirait qu'il faut passer un env au terminal).

Cependant, il s'avère que le vscode api exposé est bien trop limité. Non seulement il n'a pas exposé le processus pty sous-jacent, mais il n'a pas non plus exposé les fonctions stdio et terminaux comme pty resize. Rend totalement impossible son utilisation comme source de pty. J'ai donc été obligé de créer le pty tout seul.

POC: https://github.com/mmis1000/Vscode-terminal-tab

Hey @ mmis1000 pourriez-vous peut-être ajouter des instructions d'installation, ce serait génial. J'aimerais vraiment avoir ça.

@ mmis1000 est limité par la conception car cela devrait faire partie du produit principal, il y a aussi des problèmes de performance avec l'événement window.onDidWriteTerminalData , c'est pourquoi il est bloqué dans proposé. Bien que ce type d'extension puisse être utile en tant que solution temporaire, je m'inquiète de la longue queue potentielle des utilisateurs une fois que les terminaux fonctionnent dans la zone de l'éditeur. Un autre problème que vous pourriez finir par rencontrer est la dépendance à l'égard de node-pty livré dans le cadre de vscode, ce n'est pas une API publique destinée à la consommation et qui cassera probablement votre extension à l'avenir.

@Tyriar En tant qu'utilisateur cloud9 (et être toujours un utilisateur cloud9 maintenant).

Il est plutôt utile d'utiliser n'importe quelle zone d'écran comme terminal et avec une session persistante soutenue par tmux.

J'utilise principalement cloud9 comme terminal Web pour contrôler le VPS. (Et c'est la SEULE raison pour laquelle je l'utilise encore maintenant. Parce que vscode vraiment mal fait sur le terminal. C'est une douleur énorme de perdre le terminal par accident le rouvrir à chaque fois).

Cloud9 affiche toujours la même fenêtre, le même éditeur, le même terminal et la même session au même endroit que vous voyez avant de fermer le navigateur hier. S'il ne parvient pas à trouver la session (peut-être que le serveur a redémarré), il en rouvrira au moins une nouvelle avec le même environnement pour vous.

Si je suis sur l'utilisation d'un autre service d'éditeur en ligne (je veux dire, ouvert dans le navigateur), je m'attendrai à ce qu'il prenne en charge ceux-ci hors de la boîte (ou du moins réalisable par extension), car il est peu probable que vous ne fermiez pas votre navigateur ( intentionnellement ou par accident) du tout.

(Aussi parce que cloud9 l'a fait il y a des années, donc je ne pense pas vraiment que ce soit un problème technique)

Pour être honnête, l'expérience du terminal vscode fournie ne me semble pas vraiment un produit de dernière génération.

@ mmis1000 Pourriez-vous s'il vous plaît ajouter des instructions d'installation?

Le référentiel https://github.com/mmis1000/Vscode-terminal-tab possède son propre outil de suivi des problèmes. Quiconque ressent le besoin de poser des questions sur ce projet, veuillez le demander.

Pour une démonstration sur le terminal que je m'attends à voir sur un ide distant / basé sur un navigateur.
Je m'attendrais à ce qu'il rétablisse simplement la position de l'onglet / session du terminal lorsque je le ferme hier.
Au lieu de It will kill the all the important tasks I am running instantly because I accidentally close the the browser / the browser crashed / the computer BSOD .

C'est un autre problème https://github.com/microsoft/vscode-remote-release/issues/3096 .

@xgdgsc semble probable mais ne l'est pas.

Ce que j'attends, c'est que le terminal persiste soit disponible universellement, même sur une instance de vscode locale. (au moins au point que fait iterm2)
Pourquoi une fonction aussi utile doit-elle être limitée à une connexion à distance?

Et je n'ai pas non plus persisté la connexion ssh, j'ai juste branché un multiplexeur de terminal et j'y ai exécuté des choses.

@ mmis1000 encore https://github.com/microsoft/vscode/issues/20013 , voir ici pour les dernières. Restez sur le sujet car il y a _de nombreuses_ personnes qui sont notifiées lorsque vous commentez ce problème.

Y a-t-il une chance d'avoir cela dans les itérations suivantes?

Ouvrir le terminal en tant qu'onglet de page d'éditeur normal est une idée merveilleuse pour moi, et j'en ai vraiment besoin.