Las pestañas se consideraron originalmente, pero el equipo las examinó ampliamente, ya que podría causar confusión al tener pestañas en la parte inferior y hacer que vscode se sienta menos "liviano". Si no tuviera combinaciones de teclas para los terminales focusNext y focusPrevious , me sentiría muy frustrado por la falta de pestañas, ya que los menús desplegables son difíciles de usar.

También se consideró la vista dividida y luego se despriorizó, ya que aplicaciones como tmux pueden ejecutarse en la terminal integrada para lograr un resultado similar, desde entonces he girado a partir de esto y realmente quiero poder dividir la terminal. En particular, no quiero aprender las combinaciones de teclas de tmux y parte de mi flujo de trabajo es tener múltiples terminales que se muestran a la vez; normalmente un comando de vigilancia que superviso en busca de errores y un comando de ejecución o compilación manual. Hagamos un seguimiento de la división de la terminal en # 7504

@stevencl @ bgashler1, por favor, focusNext y focusPrevious del terminal (ato ctrl + shift + j / k).

Sin embargo, debemos considerar esto en el contexto de este problema: https://github.com/Microsoft/vscode/issues/9659

Soy muy cauteloso con las pestañas dentro del diseño de pestañas. Terminaremos usando todo el espacio disponible para mostrar pestañas :-)

Solo pensando en voz alta aquí, ¿realmente necesitamos mostrar pestañas si permitimos dividir la terminal? ¿Sería suficiente si solo expusiéramos acciones para dividir y colapsar el terminal pero no tuviéramos que mostrar la pestaña real?

Tal vez, puedo verme usando 2-3 terminales divididos sobre pestañas / terminales múltiples. Administrar terminales divididos y terminales de pestañas se volvería muy confuso y probablemente apenas tendría uso debido a la falta de combinaciones de teclas.

Si abrimos la puerta para dividir terminales, ¿qué significaría dividir, por ejemplo, un terminal y una respuesta de depuración? ¿Es la misma interacción UX?

@bpasero al dividir me refiero a crear una nueva terminal al lado, así que sí sería lo mismo.

Para simplificar la interacción, podría haber una configuración para usar siempre _ ya sea_ el menú desplegable o dividir los terminales. De esa manera, todos los comandos existentes seguirían funcionando bien, solo elige mostrar 1 o todos los terminales en cualquier momento.

El miedo que tengo al introducir pestañas y dividir la terminal es que pueda parecer un grupo de editores. No quiero que los usuarios se sientan decepcionados por no poder arrastrar editores a la terminal o terminales a los grupos de editores. * Además, introducir esto puede ser una pendiente resbaladiza en la gestión de ventanas, por ejemplo, ¿por qué tenemos una horizontal especial panel para cosas como esta en primer lugar. ¿Por qué no dejar que un terminal viva donde quiera, en lugar de replicar tanta funcionalidad en una interfaz de usuario personalizada?

* posiblemente podríamos informarles de la limitación bloqueando el arrastre en el eje x y / o teniendo un cursor deshabilitado al intentar arrastrar fuera de un área, pero es difícil evitar que la gente espere que esto funcione.

Cuando introducimos la división horizontal de grupos de editores, una de las limitaciones que estamos imponiendo es que los grupos de editores solo pueden dividirse horizontalmente o verticalmente. Por lo tanto, puede ser extraño para los usuarios tener un panel que se parece sorprendentemente a un grupo de editores horizontales (pero no se comporta exactamente de la misma manera) ubicado debajo de los grupos de editores verticales.

Deberíamos hablar más sobre esto durante la sincronización de UX el miércoles. Hay algunos diseños que no mostré la última vez relacionados con diseños horizontales que son relevantes para esto

¿Qué pasa con la opción de alinear el terminal con la pestaña del editor, para que el terminal refleje automáticamente el idioma del archivo del editor?

La apertura de una terminal cargaría automáticamente un shell preconfigurado para el idioma del editor activo (actualmente seleccionado). Se deben admitir varios shells de terminal en el archivo settings.json.

No importa cómo se dividan los editores: el terminal siempre muestra el shell del editor seleccionado (activo). Esto es simple y sencillo. Con este método no es necesario dividir el terminal, no hay necesidad de terminales con pestañas. La terminal seguiría apareciendo como lo hace ahora.

Si hay varios shells disponibles para el idioma, o si desea ejecutar una configuración como el nodo shell y un git shell para la pestaña del editor, entonces quizás los shells se puedan seleccionar dentro de un panel. Esto es un poco como terminales con pestañas, excepto que no se presentan como pestañas duras, lo que implica un subcontexto. Esto no se "siente" sustancial como una pestaña. Su contexto está dentro del panel de terminal para el editor seleccionado actualmente.

Una cadena de hipertexto simple (una para cada shell) ubicada en la parte superior derecha de la terminal mostrará los shells abiertos (instanciados) para el editor seleccionado actualmente. Un usuario puede simplemente hacer clic en una cadena de hipertexto, que podría decir nodo, para seleccionarla, o usar una combinación de teclas para recorrerla. Estos reemplazarán el menú desplegable existente, el + y la papelera. Las conchas posiblemente podrían presentarse en minúsculas.

Se puede mostrar una cadena de hipertexto simple o simplemente un icono, aunque una cadena puede ser mejor. Esto reemplazaría la engorrosa lista desplegable que se usa actualmente en VSCode y mostraría los shells de un vistazo.

Cuando cambia el enfoque del editor actual a un editor con otro idioma (por ejemplo, Ruby), el terminal presentará la instancia de IRB en el terminal. Si el usuario desea abrir otra instancia del shell actual, es posible que solo tenga que desplazarse sobre el hipertexto de ese shell y hacer clic en el + que aparecerá. Si las cadenas de hipertexto son cortas, como nodo, irb, cmd, ps, se puede crear otra cadena junto a la cadena utilizada para crear la nueva instancia. Las cadenas se separarían para hacer espacio, pero no se abarrotarían porque se podría establecer un límite (¿quién va a abrir más de tres shells contra un editor?).

Pasar el cursor sobre un caparazón también puede presentar un pico, que muestra el contenido de la capa para esa cadena. Sin embargo, si los usuarios están usando combinaciones de teclas para cambiar / ciclo, podría ser más fácil verificarlo.

Si quisiera darle al usuario la opción de agregar un shell no asociado con el editor, como un shell git, al hacer clic en + se podría presentar un menú de shells registrados en el archivo settings.json. El - que aparecería al pasar el cursor junto a cada cadena de hipertexto, por supuesto, no mostraría ninguna opción. Cerraría la instancia de shell actual.

Si un usuario quisiera cambiar el tipo de shell, podría salir del shell (para volver al predeterminado) y luego lanzar un nuevo shell escribiendo el nombre del shell. La cadena de hipertexto que representa el shell cambiaría para reflejar el nuevo shell.

En el caso de un shell de git, podría ser lógico ofrecer la opción para que el usuario especifique que un shell de git siempre se abrirá con el shell de idioma del editor, de modo que git esté en contexto con la ubicación de ese archivo. Si hay varios archivos abiertos desde la misma ubicación de git, todas las instancias de shell de git en todos los editores reflejarán la última actualización o comando.

Es probable que el archivo settings.json requiera que el usuario ingrese la extensión de idioma específica (.js, .cs, .rb) en cada terminal.internal.shell. entrada para que haya una coincidencia lógica con un archivo. Se puede configurar un shell predeterminado para cualquier tipo de archivo no especificado en settings.json.

La instancia de shell cargada para cada editor dura mientras ese editor esté abierto. Tan pronto como se cierra un editor (un archivo), también se cierran los shell (s) de terminal asociados.

Creo que esta es una implementación simple que también hará que VSCode sea más poderoso de lo que es actualmente, además de ser muy intuitivo. Cuando el usuario cambia de contexto entre los editores de idiomas, no tiene que pensar en la terminal. El terminal siempre presentará el shell y el código que se ejecutó por última vez, incluido el historial asociado, etc., que se utilizó por última vez para el editor seleccionado.

@ nick-walt, si bien puede ser más intuitivo para algunos, no lo es en absoluto para otros. Es probable que las personas se desorienten un poco y se pregunten dónde fue su caparazón. También mis requisitos son tener 2 proyectiles a la vez; uno para una tarea de vigilancia en la que estoy rastreando errores y otro para una tarea de inicio, git, compilación, etc.

Han surgido múltiples configuraciones de terminal antes, no estoy tan seguro de que valga la pena la complejidad adicional, aunque cuando la mayoría de las veces puede ejecutar el shell en su otro shell (abre powershell, ruby, node, etc.dentro de cmd).

@Tyriar
Esas son buenas preocupaciones, pero creo que pueden resolverse con bastante facilidad cuando se toman como consideraciones.

Evita la desorientación
En su estado predeterminado, en una nueva instalación no configurada, el terminal puede comportarse de una manera familiar. Esto evita la desorientación por un comportamiento inesperado.

Dividiendo la terminal
Dividir el panel de la terminal no cambia el modelo. Es solo una forma de ver más de un shell en el panel de terminal a la vez. Podría ser posible arrastrar el panel fuera de la ventana principal e ir a pantalla completa en otro monitor. Luego, el usuario puede decirle al terminal que se divida de manera automática y uniforme entre las carcasas abiertas, vertical u horizontalmente. Un terminal, varios shells, todo en contexto con el editor seleccionado actualmente.

Acecho
Si no queremos perder de vista una instancia de shell que estamos viendo, mientras cambia a otro editor, entonces quizás una función de vigilancia que muestre un número configurable de líneas podría resolver este problema. Si se produce un error, también se puede mostrar como un icono en caso de que el usuario lo haya perdido debido al desplazamiento rápido. Esto ya está hecho en el panel Error de VSCode. Un panel de observadores solo se puede mostrar y al pasar el mouse sobre él se puede mostrar una muestra más grande.

Sofisticación sin la carga de la complejidad
Con una terminal contextual, la capacidad de tener muchos shells en todos sus editores no se sentirá abrumadora ni abrumadora. Con el modelo correcto, los chicos de UI / UX pueden hacer que funcione con elegancia.

Creo que sus inquietudes podrían abordarse por completo.

Depende de qué terminal se va (supuestamente) a usar. Si se va a utilizar para ejecutar algún comando de una sola vez, casi no se necesitan múltiples terminales de ninguna manera.

Se necesitan múltiples terminales si se van a usar para ejecutar simultáneamente múltiples tareas en segundo plano, como servir, construir, ver, probar, etc.

Entonces, en este caso, es viable tener una visión general rápida de qué terminales están abiertos y qué están ejecutando (presumiblemente con el estado de ejecución). No estoy seguro de cómo se puede hacer sin pestañas con nombre / marca .

La vista

Una pregunta más es el uso cooperativo con Task Runner. Que se usa actualmente para ejecutar solo una tarea a la vez. Pero este https://github.com/Microsoft/vscode/issues/981 asume que admitirá múltiples tareas en segundo plano, por lo que es un propósito similar (no diría contradictorio) en cuanto a múltiples terminales.

Jetbrains Webstorm actualmente tiene tales capacidades: puede ejecutar múltiples tareas (definidas a través de grunt / gulp / npm) y múltiples terminales (con pestañas con nombre). Y también puede usar allí una vista dividida donde en un lado ve las tareas en ejecución y en el otro, el terminal. (adjuntando la pantalla)

@el color blanco

Bien, entonces si enumeramos todos los escenarios y sus puntos en común, debería ser posible destilar la funcionalidad requerida a la elegancia que pueda abordar el uso diverso, sin que VSCode se vuelva demasiado pesado.

Much'o pestañas sin fatiga
Con un terminal vinculado al contexto de un editor, el problema de una desconexión de usabilidad (como qué pestañas se asocian a qué editor), el uso de 'pestañas blandas', también conocido como una cadena de hipertexto que nombra el shell dentro del contexto del terminal / editor, permitirá muchas más pestañas sin hacer que el usuario vaya a buscar pestañas y evitar la fatiga de contexto / asociación de mantener un registro en su cabeza.

Conchas nombradas
Con la idea de una cadena de hipertexto simple que muestre el nombre de una instancia de shell dentro de un panel de terminal, surge la posibilidad de una creación y un nombre alternativos. Entonces, un usuario tiene un solo shell configurado en settings.json, que podría ser 'cmd'.

Una vez que están en un shell, pueden saltar a otro shell, como 'powershell' o 'bash', y la cadena de hipertexto llamada 'cmd' en el encabezado de la terminal puede cambiar para reflejar el shell al que saltó el usuario.

O bien, el usuario puede crear una instancia de shell adicional desde el shell de inicio 'cmd' tal vez mediante el uso de un comando que el panel de terminal entiende como la creación de un "nuevo".

La idea es implicar en la interfaz de usuario el hecho de que los shells nombrados no son pestañas desasociadas sino shells dentro del editor principal. Estoy usando el término 'pestañas' para denotar un caparazón autónomo y no asociado que está separado de cualquier otra cosa. Este podría ser un modo, donde las pestañas duras son globales y las pestañas suaves están dentro del contexto de un editor.

Si se incluyera un modo de pestaña dura / pestaña blanda, entonces quizás las pestañas duras podrían tener límites rígidos, al igual que las pestañas que muestran editores. El comportamiento de los nombres sería idéntico al de las pestañas suaves.

Lo fundamental es mantener el modelo UI / UX establecido. Todos hemos visto muchos casos en los que los modelos se dividen en diferentes implementaciones de IU dentro de una sola aplicación. En realidad, Microsoft es bueno en esto (y más recientemente, Apple). Es un caso clásico de 'diseño por comité'.
establecido

Usuario simple de shell único
Sin embargo, si un usuario quiere ejecutar de forma simplificada y con un solo terminal / shell, entonces no hay nada en la forma de lograrlo y, lo que es más importante, la configuración es simple. Es solo otro escenario de uso en la matriz de consideración.

Si se van a agregar pestañas, me gustaría tener una opción de configuración para deshabilitarlas / forzar una sola instancia del terminal integrado. Si necesito tales funciones _ avanzadas_, normalmente recurro al terminal (externo) de mi elección.

También consideraría algo como la división de terminales (división más avanzada), por lo que todas las salidas de terminales importantes en ejecución (tal vez más de dos) están ante los ojos, incluso en parte.

¿Qué tal si se muestran las pestañas de la terminal en el mismo lugar que las pestañas de los archivos?
No dañaría la interfaz de usuario y no se perdería ninguna funcionalidad.

@cescoferraro Me gusta esta idea. Pero VS Code también debería admitir vistas de pestañas divididas verticalmente y no solo horizontalmente. De lo contrario, no cumpliría la condición para ver múltiples terminales sin perder espacio.

@Phisherman No me malinterpretes, me gusta el terminal dividido.
Lo uso mucho en Intellij con una pantalla grande y mucha configuración de memoria.
Cualquiera que sea la decisión, debería poder conectarse si ocupa mucha memoria para mantener VSCode lo más rápido posible.

Escribí una extensión con la que puede seleccionar la tarea npm / gulp, iniciará la terminal (con el nombre de la tarea) y la ejecutará allí, también colocará un elemento en la barra de estado en el que puede hacer clic en cualquier momento, también realiza un seguimiento básico del estado del proceso en ejecución.

Solo para mostrar la posible ubicación de las "pestañas", podrían estar en la parte inferior del terminal.

@whitecolor : open_mouth: ¿esto está usando la nueva API de terminal? ¡Eso es genial!

@Tyriar Sí, ese en el que estás trabajando: guiño:

Como lo menciona @whitecolor , WebStorm tiene pestañas para terminales y esto mejora la accesibilidad del IDE. Además de esto, WebStorm te permite cambiar el nombre de la pestaña que nuevamente te ayuda a identificar visualmente por qué empezar.

Sin embargo, algo que WebStorm no hace es que no guarda la cantidad de pestañas de terminal abiertas.
Cuando desarrollas, normalmente necesitas las mismas pestañas (servidor, observador, backend ...). Si se pudiera guardar el número de pestañas así como su nombre, sería fantástico.

@whitecolor después de pensarlo un poco, hay algunos problemas con los que se encontrará con la API actual al implementar pestañas de terminal de esa manera, asumiendo que está exponiendo un comando de extensión "crear nuevo terminal" que desea anular el predeterminado. Aquí hay algunos problemas que debe rastrear si está interesado en crear una extensión como esta:

• Cuando se reinicia vscode, se creará un terminal estándar, no puede adjuntar un elemento de la barra de estado a este
• La extensión no se da cuenta cuando el usuario desecha un terminal, por lo que el elemento de la barra de estado se mantendrá al menos hasta que se haga clic nuevamente
• (Error) Al deshacerse de un terminal, se mostrará el panel # 11275
• También en la v1.6.0 probablemente la terminal estará oculta de forma predeterminada, por lo que deberá llamar a Terminal.show justo después de crearla # 11384

@Tyriar gracias por compartir, responderé a su lista:

1) Sí, no es tan importante, mi extensión en realidad agrega un comando "Abrir nueva terminal" y permite abrir una nueva terminal con nombre , generalmente solo cierro el estándar y uso el creado, pero sería bueno si hubiera un acceso a todos los terminales existentes en el panel.
2) Sí, la extensión desconoce el estado de la terminal, pero hago un seguimiento de los procesos secundarios de terminal._id por PID, por lo que sé cuándo el usuario elimina la terminal (los procesos secundarios van a 0). Entonces, ¿qué pediría que no _elimine_ este ID de proceso en el futuro, no estoy seguro de si debe ser público? Así que incluso hago un seguimiento de la cantidad de procesos secundarios en ejecución y si el recuento se reduce, esto puede significar que algo está mal o que las tareas han terminado de ejecutarse, entonces muestro este terminal, bastante útil.
3) Así que no uso actualmente desechar.

Lo que realmente falta es acceso a la salida del proceso, que permitiría realizar analíticas más útiles (por ejemplo, rastrear alguna salida de error / excepciones) y mostrar el terminal al usuario.

La extensión está realmente lista para ser publicada, probablemente lo hará algunos días.

@whitecolor actualmente solo hay acceso a terminales creados a través de la API, sin embargo, este es un caso bastante convincente para cambiar eso.

Un vistazo furtivo a terminal._id : guiño: probablemente no se cambiará pronto, pero tan pronto como se agregue un evento que puedas escuchar, definitivamente debes aprovecharlo, ya que será la API estable oficial. El seguimiento y la salida de procesos secundarios se explorarán en el n. ° 11422 (puede seguir los problemas vinculados a eso para algunas discusiones sobre el tema).

Con el comando de terminal con nombre también está proporcionando una solución para # 10023: smiley:

Buen trabajo, ¡estoy deseando probarlo!

@whitecolor FYI, así que mentí y terminal._id probablemente cambiará en v1.6 para ser un ID aleatorio, no el PID. Estoy en medio de una gran refactorización para separar más el panel de la terminal de los procesos (para que puedan existir sin el panel existente # 11275) y no creo que pueda mantenerlo allí, desafortunadamente.

@whitecolor puedes probar window.onDidCloseTerminal (# 10925) en los insiders de mañana. Debería ser más fácil que rastrear el PID.

Me gustaría verlo como InteliJ. Hasta esto, le agrego estos teclados personales:

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

Los mismos atajos de teclado para navegar entre pestañas, pero si el cursor está enfocado en la terminal, alternar entre terminales.

La vista dividida en las pestañas de la terminal sería muy útil;

Actualmente estoy tratando de hacer una prueba de concepto con una instancia de servidor y ejecutar solicitudes a través de otra terminal de consola.

¿Algún progreso en esto?

@MeirionHughes
tmux podría ser una solución, pero funciona mal dentro del terminal integrado VSCode (por fin en Windows).

@MeirionHughes, aquí está el problema para esa función https://github.com/Microsoft/vscode/issues/7504. No hay progreso hasta ahora, la última vez que lo presioné, el equipo me rechazó. Cuanto más: +1: en ese tema, mejor.

@Tyriar , podría decir que este problema también solicita la división, ya que en la tercera imagen lo muestra explícitamente. Además, este número tiene 112 👍 :)

@MeirionHughes el primer comentario (mío) dice:

Hagamos un seguimiento de la división de la terminal en # 7504

La razón de esto es que las discusiones sobre 2 características diferentes no crean ruido entre sí.

Oh chicos, por favor ayuden, ya que es una característica de la interfaz de usuario realmente importante, a veces hace que crz maneje el menú desplegable para cambiar la consola, muchas gracias;)

+1 por cycle terminal combinaciones

@whitecolor _darn! _ Pensé que tmux dentro de la terminal integrada era mi propia solución inteligente, pero se me adelantó. Funciona bien para mí (no mouse mode ) pero los paneles funcionan bien:

El modo mouse funciona bien para mí con tmux.

En cualquier caso, creo que esta es una gran adición.

Creo que esto sería realmente útil. Pero no creo que deba limitarse a los terminales, sino que también debe incluir las pestañas "Problemas", "Salida", etc., para que pueda tener "Terminal", "Problemas" y el editor abiertos en una vista.

También voy a hacer +1 en una combinación de teclas para recorrer las terminales. Odio tener que usar el mouse para hacer clic en ese pequeño menú desplegable, especialmente en una computadora portátil con trackpad.

Dame una combinación de teclas para recorrer los terminales y creo que puedo prescindir de la división / pestañas

@ psimoneau22 esta es la combinación de teclas que uso para eso:

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

Vamos a considerar la posibilidad de dividirnos pronto.

No puedo creer lo bueno y poderoso que se está volviendo este editor. Esta será una adición súper poderosa para abrir vscode y nada más durante una sesión de codificación.

TL; DR; Use unas horas para recoger tmux.

Estoy contento con tmux en mi terminal (el modo mouse funciona como un encanto). Me tomó un día aprender. He jugado con él antes unas cuantas veces, pero pasé ayer configurándolo como un jefe. Acabo de hacer un tmux -CC en iTerm, que abre una ventana de terminal. Luego, haga un tmux a en el terminal vscode para conectarme a esa sesión; esto fue cuando obtuve sesiones de terminal persistentes para que siempre pueda volver por sesión al reiniciar vscode (actualizar Vscode, instalar extensiones). Esta es una característica mucho mejor para mí que tener pestañas o divisiones en la terminal. Mantenga Vscode ligero por favor. Atom es una lección de la que aprender (yo vine de él). TMUX FTW :)

Este mismo enfoque también me ha funcionado en Mac / cygwin / windows y debería funcionar prácticamente en todos los lugares donde se ejecuta Vscode.

TL; DR;

Sería bueno tener pestañas para el Terminal integrado en lugar del menú desplegable. ¿Alguna posibilidad de ver esta función en el futuro?

Teniendo en cuenta el acceso directo ctrl + shift + ` y ctrl + ` creo que estas configuraciones tienen más sentido.

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

@leocaseiro @Tyriar @ psimoneau22 A menos que esté usando una Mac, vale la pena agregar la opción 'when' a esas como ctrl + shift + left y ctrl + shift + right se utilizan para seleccionar fragmentos de texto en el editor.

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

o

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

Aquí un mi 2ct para esta característica tan deseable (lo siento si ya se han mencionado algunos de los puntos)

Casos de uso
La razón por la que utilizo múltiples terminales en el primer caso suele ser:

• Necesito trabajar en dos directorios en paralelo y no quiero cd hacia adelante y hacia atrás todo el tiempo
• Necesito trabajar con dos terminales diferentes (por ejemplo, bash vs powershel vs cmd o local vs remote / ssh)
• Quiero monitorear la salida de dos programas diferentes en paralelo

Tenga en cuenta que solo en el tercer caso necesito una vista dividida del terminal. En la mayoría de los otros casos, prefiero tener una terminal que use tanto espacio como sea posible.

UI
¿Por qué no ampliar las pestañas actuales (por ejemplo, Depuración, Salida, Terminal ...) y permitir un "Terminal1, Terminal2, Terminal3 ..." adicional?

Pestañas vs menú desplegable

• Ves todas las pestañas disponibles
• Es más fácil (para mí) recordar qué terminal sirve para qué propósito si están representados por ubicaciones visuales distintas (por ejemplo, tercera pestaña)

tl; dr

Estoy totalmente de acuerdo con @MikeGitb , siempre uso más de 1 terminal a la vez. Es difícil ver las pestañas abiertas en el menú desplegable para terminales en el Código VS actual. Sería realmente genial tener pestañas para el terminal integrado. Gracias.

Una idea loca: ¿por qué no darle al terminal el mismo estado que las pestañas normales del editor? Sería especialmente útil si uno quiere ver más de un par de líneas al mismo tiempo.

Una idea loca

No es una locura, así es como funcionan vim / neovim.

No es una locura, así es como funcionan vim / neovim.

Al igual que muchos otros IDE;).

Lo siento, esa introducción fue en realidad irónica.

@Tyriar, ¿existe una función que permita el paneo vertical del terminal junto con su código o no se permitirá?

@ajrator que está cubierto en https://github.com/Microsoft/vscode/issues/2806

Estaría totalmente feliz de darle a los terminales el mismo estado que las pestañas del editor: ComEmu y HyperTerminal tienen problemas serios que impiden su uso actual (ConEmu tiene problemas de contraste que no se pueden solucionar ya que el mantenedor quiere mantener el soporte de XP, HyperTerminal no puede hacer Ctrl + C en powershell y otros conceptos básicos). Sería fantástico tener vscode como un terminal con pestañas que funcione.

También sigo observando cuándo se publicará la vista con pestañas del terminal integrado en lugar de la lista desplegable.

El menú desplegable es un poco incómodo de usar. También sería genial tener más de una terminal abierta.

Para las personas que quisieran probar tmux mientras esperan el soporte de pestañas, creé una esencia para iniciar la configuración. Tiene soporte para mouse habilitado por defecto y usa enlaces simples para dividir el terminal.
https://gist.github.com/cybertim/e8b42c8cd8a5bebaa3eb8cec17a2746f

Gracias @cybertim , gran archivo! Ya usé tmux pero este archivo es útil.

La razón por la que personalmente estaría muy interesado en múltiples terminales en diferentes posiciones dentro de la ventana es que, con suerte, marcaría el camino para implementar un entorno similar a RStudio / Jupyter Lab dentro de VSCode.

Personalmente, me gustaría que todo fuera una pestaña y luego brindara la capacidad de dividir paneles infinitamente vertical y horizontalmente. Luego, también puede proporcionar la capacidad de fijar pestañas para mantener las herramientas más comunes, por ejemplo, Terminal, Explorer y Búsqueda.

Los editores más antiguos tienen los botones de guardar, deshacer y rehacer a lo largo de una barra de herramientas larga en la parte superior; VSCode no los tiene, ¿por qué? Porque se espera que la gente use el teclado. Somos programadores. El terminal anterior, el terminal siguiente se pueden vincular a las teclas de acceso directo; úselo. Digo que cerremos este tema y sigamos con lo importante.

A continuación, ¿todavía quieres pestañas? Panes? Divisiones?

Creo que muchas personas aquí solicitan una función que es excesiva para VScode. Si le dieran una oportunidad a tmux , no estarían pidiendo esto. Se nos entrega el terminal. Usando tmux, admite pestañas. Te tomará un par de horas como máximo para aprender tmux. Hay pestañas, ventanas, divisiones y más, si necesita reiniciar VSCode, simplemente puede escribir tmux -a después de que se reinicie para volver directamente a su sesión tmux. Después de activar el modo de mouse (solo una línea en la configuración), incluso puede cambiar el tamaño de los paneles, haga clic en las pestañas para ir a esa pestaña. Estoy en contra de esta característica en VSCode. Solo va a ralentizar el rendimiento. Mantenga VSCode lo más liviano posible, no queremos otro Atom. ¡Deje que tmux haga el trabajo pesado! Como puede ver a continuación, tengo divisiones y también, si miran de cerca la parte inferior, tengo dos pestañas: python & fish . Y sí, en la parte inferior izquierda, uso Googler en la línea de comandos de Google: D

@piggyslasher No veo cómo esta función podría hacer que vscode sea más lento.
Vscode ya admite tener más de una instancia de terminal. Esta función se trata simplemente de cambiar el selector desplegable a una función de pestaña, con suerte, más agradable de usar.

Con esta función, aún podrá continuar usando una instancia / pestaña de terminal con tmux, y no esperaría un cambio en el rendimiento en comparación con ahora.

Vscode es un editor multiplataforma. Decirle a la gente que use tmux está restringiendo a esas personas a entornos donde tmux está disponible. Además, tmux tiene una gran curva de aprendizaje que es totalmente exagerada para una función tan simple como esta.

Sin embargo , la sugerencia de

Esto es algo en lo que he estado pensando durante mucho tiempo. Tmux tiene tabs y cada tab se puede dividir en tantos panes como desee. En contraste, los editores tienen panes y luego cada pane puede tener tabs .

Me gusta más bien la forma tmux porque es como 'este diseño de terminales está relacionado, y luego cambiamos a otra pestaña de terminales relacionados'

Para algo como el desarrollo de reacción / angular, podría ver que esto es útil si tiene un 'panel' JS / HTML / CSS / Test abierto para cada componente y una 'pestaña' para cada componente en el que está trabajando.

Me interesaría ver si es posible hacer algo así en un complemento. Origami for Sublime está cerca, pero sigue siendo 'paneles llenos de pestañas', no 'pestañas llenas de paneles'.

Existe una gran preocupación sobre el alcance y la escala de la introducción de la administración de la consola a través de pestañas y otros mecanismos de interfaz de usuario y solo quiero señalar que si el problema que se está resolviendo se define con mucha claridad, los problemas de alcance y escala y expectativas del usuario van ser mitigado por la elegancia de la solución. Defina el problema con mucha claridad y la solución será más clara, y es más probable que la lógica sea coherente en toda la interfaz de usuario y la experiencia de usuario. Ya sabes, esa sensación de "simplemente funciona" que todos disfrutamos usando y creando.

Además, sería bueno tener una lista numerada o con viñetas de las diferentes soluciones ofrecidas en este hilo y sus preocupaciones identificadas (probablemente como viñetas / números con sangría). Un hilo como este puede dar vueltas en círculos sin que estas cosas se actualicen en una ubicación central, curada, o quizás en la publicación inicial.

Me parece que todo el mundo está de acuerdo en que se requiere algún tipo de gestión de la consola, más allá de lo que existe actualmente. Solo una sugerencia para resolver problemas de escala: brinde la opción al usuario de adjuntar las consolas a un editor o un grupo de editores. Permita también que una consola esté separada, pero haga de cualquier manera una configuración predeterminada definida por el usuario. Adjuntar las consolas al contexto del editor ayudará a reducir la generación excesiva de consolas. Además, permitirá que las consolas de un editor se oculten cuando se seleccione otro editor, manteniendo baja la complejidad de la interfaz de usuario. Si las consolas no están asociadas con editores, las cosas pueden salirse de control y la gente olvidará qué consola está haciendo qué, etc.

Considere agregar una configuración configurable por el usuario que permita que las consolas definidas para un editor se guarden en la aplicación, según el nombre y la ubicación del archivo (o, tal vez, según algún otro identificador más confiable y único en las propiedades del archivo en el Nivel del sistema).

Se podría decir que este nivel de refinamiento se acerca a los niveles de IDE, pero los creadores ya han dicho que VSCode trae algunas de las cosas buenas de un IDE al espacio del editor. Es posible introducir una solución de consola que no se sienta pesada o compleja, que simplemente funciona y brinda una excelente experiencia de usuario.

Si esto no tiene sentido, o si estoy diciendo lo obvio, hágamelo saber.

@ nick-walt cuando dices:

proporcionar la opción para que el usuario adjunte las consolas a un editor o un grupo de editores.

¿Está sugiriendo la posibilidad de que el terminal asocie instancias de shell con archivos abiertos particulares?

Me parece que lo estás complicando demasiado. Por supuesto, siga pensando fuera de la caja al respecto, pero por lo que he visto en características similares, al equipo de vscode le gusta mantener el impacto de pequeñas características como esta al mínimo. Así que apuesto a que están buscando la solución más simple (aunque efectiva) para hacer feliz a la gente.

El punto más básico de este problema es que un menú desplegable no es bueno para cambiar entre cosas, y que las pestañas son una alternativa bastante buena; de ahí la razón por la que la mayoría de las cosas usan pestañas: editores, IDE, navegadores, etc.Creo que todos aquí estarían de acuerdo que esencialmente cualquier forma de pestañas sería preferible a un menú desplegable.

Además de la parte más básica de cómo cambiamos entre instancias de shell, existe un interés en permitir también alguna forma de tener más de una instancia visible al mismo tiempo. Ya sea a través de paneles en la sección del terminal en la parte inferior, o también haciendo que las pestañas de la terminal sean intercambiables con las pestañas del editor de alguna manera, o alguna otra solución. Esta parte es más complicada y probablemente haya menos acuerdo sobre qué camino tomar. Especialmente teniendo en cuenta lo que @sorahn acaba de señalar sobre paneles-dentro-pestañas vs pestañas-dentro-paneles.

Personalmente, creo que hay suficiente soporte para eliminar el menú desplegable (porque realmente no es genial) y reemplazarlo con pestañas, y preocuparse por cosas más avanzadas después.

Hace más de un año @ bgashler1 dijo esto:

El miedo que tengo al introducir pestañas y dividir la terminal es que pueda parecer un grupo de editores. No quiero que los usuarios se sientan decepcionados por no poder arrastrar editores a la terminal o terminales a los grupos de editores. * Además, introducir esto puede ser una pendiente resbaladiza en la gestión de ventanas, por ejemplo, ¿por qué tenemos una horizontal especial panel para cosas como esta en primer lugar. ¿Por qué no dejar que un terminal viva donde quiera, en lugar de replicar tanta funcionalidad en una interfaz de usuario personalizada?

Entonces, ¿quizás en este momento es mejor considerar pestañas que son visiblemente diferentes a las pestañas del editor, lo que indica que _no_ son intercambiables con las pestañas del editor, para evitar confusiones?

Estoy de acuerdo, las pestañas son una solución bastante buena para seleccionar diferentes consolas.

Creo que la forma de habilitar la funcionalidad de asociar consolas con un editor sería simplemente cambiando la configuración del usuario. Una vez habilitado, abrir una consola mientras se selecciona un editor podría crear la asociación. Tan sencillo como eso.

Lo más probable es que la interfaz de usuario sea que cuando se selecciona un nuevo editor (archivo) en la parte superior de la aplicación, las pestañas de la consola en la parte inferior cambian a medida que cambia el editor. Es bastante simple e intuitivo.

Creo que solo se volvería más complejo si agregan la capacidad de asociar consolas individuales con más de un editor, en función de algún contexto de usuario, como:

• ubicación del directorio
• proyecto
• tipo de archivo (quizás cuando los archivos están en la misma ubicación)
• agrupación de editor (definida por el usuario)
• alguna otra abstracción

Esta experiencia sería que la consola especificada sigue siendo la misma independientemente del editor en el contexto que se seleccione (o sigue siendo la misma porque el usuario quiere que todas las consolas estén disponibles para todos los editores).

La forma en que se presenta la interfaz de usuario es donde las cosas deben ser creativas para evitar la sensación de complejidad y hacer que se sienta intuitivo, rápido y fácil de usar. Con un buen diseño de interfaz de usuario, la complejidad solo está ahí para el equipo que crea la función :)

Para reforzar la asociación de una pestaña de la consola con un editor, el panel que contiene las pestañas de la consola estaría claramente etiquetado con el nombre del editor.

Y cada pestaña podría mostrar automáticamente el tipo de consola cargada, como Git, Node, CMD, Powershell ... en lugar de mostrar Terminal 1, Terminal 2, etc. (como lo muestra @Perkovec ). Esto sería generado automáticamente por la aplicación.

Esto permitirá al usuario seleccionar directamente la consola que desee sin tener que buscar entre las pestañas el indicador de git o powershell.

La otra opción es proporcionar el motor de pestañas básico en el núcleo de la aplicación y permitir a los usuarios agregar una extensión de su elección para agregar más capacidades a la administración de la consola. En algún momento, las funciones que se utilizan mucho se pueden incorporar a la aplicación principal.

Si te entiendo correctamente, estoy estrictamente en contra de asociar el terminal con las ventanas del editor. La mayoría de las veces no tengo una relación fija entre las pestañas del editor y los terminales y, cuando lo hago, ciertamente no es una asignación 1: 1 (generalmente ni siquiera 1: N).

@MikeGitb Supongo que, dependiendo del peso de la preferencia del usuario, la asociación predeterminada del editor con la configuración de la consola podría estar habilitada o deshabilitada.

Algunos pueden querer mezclar ambos, dependiendo de lo que estén haciendo y de la consola que estén usando. Esto es solo un refinamiento del problema de UI / UX que los creadores tendrían que resolver. Igual que para cualquier desafío UI / UX.

El caso de uso del editor contextual / UX de consola será:

• sin contexto (sin consolas asociadas con ningún editor en particular)
• contexto mixto (algunas consolas asociadas, otras no)
• todo el contexto (todas las consolas asociadas con un editor)

Por cierto, sugiero la asociación de una consola con un editor como una opción para minimizar la proliferación de pestañas de la consola (y confusión / sobrecarga no deseada), que fue una preocupación expresada por algunas personas. Con un editor contextual / UX de consola, las consolas asociadas probablemente se ocultarán tan pronto como se seleccione un editor en otro contexto. El usuario siempre está viendo solo lo que es relevante para el editor seleccionado.

Como de costumbre, la implementación de la interfaz de usuario va a hacer o deshacer este tipo de cosas. El equipo de VSCode ya ha hecho un trabajo bastante asombroso con la interfaz de usuario y no hay razón para pensar que no pudieron descubrir cómo implementar una experiencia de administración de consola más sofisticada sin hacer que las cosas se sientan complicadas y sobrecargadas.

Como todos hemos experimentado antes, y cada vez más con el software más nuevo, es muy posible exponer al usuario a un grado significativamente mayor de complejidad y sofisticación al tiempo que hace que la experiencia sea más fácil y se sienta más simple.

Solo para comprender su caso de uso: ¿puedo preguntar qué tipo de operaciones realiza en la terminal, que están vinculadas a un archivo específico, en contraposición al proyecto / directorio?

Mis casos de uso típicos son usar git, compilar mi proyecto, ejecutar un binario y ver algunos resultados de seguimiento. Todos ellos son independientes de qué archivo está abierto actualmente, pero lo estoy usando principalmente para proyectos de C ++ o ediciones de un solo archivo, por lo que otras áreas pueden requerir diferentes flujos de trabajo.

Estoy bastante seguro de que casi todo el mundo usa instancias de terminal independientemente de las pestañas del editor. Esta característica estaría mejor como extensión.

Sí, estoy de acuerdo con extender la experiencia de la consola con extensiones. Probablemente la mejor manera de abrir esta área al desarrollo.

Crear un motor de consola en VScode para que todos puedan construirlo sería un experimento interesante.

Aquí hay un clip de cómo funciona el IDE de Cloud9 :

Parece tener lo que muchos de nosotros parecemos estar buscando: cualquier pestaña nueva puede ser un editor o una terminal, y cualquier pestaña se puede mover y dividir horizontal o verticalmente.

@plmrry ¡ Eso es increíble! Algo en esa dirección sería realmente bueno.

@plmrry, la pregunta de si tendríamos un sistema de paneles muy flexible como ese sigue abierta. Personalmente, me gusta cómo se arregla el panel, esto deja muy claro a los comandos del terminal lo que sucederá; El terminal de enfoque siempre abrirá el espacio de un terminal y enfocará el terminal activo.

Si hay varios terminales en las pestañas del editor, algunos en primer plano, otros en segundo plano, entonces la pregunta de qué hacen ciertos comandos de terminal no es tan clara y no será tan intuitiva.

¿Pueden los comandos de la terminal simplemente apuntar al que se enfocó por última vez? mucho de la misma manera que cmd + shift + t apuntará a la pestaña que se cerró por última vez

@btoo eso es probablemente lo que haría en un mundo así. Sin embargo, ese es un cambio muy radical en cómo funciona VS Code.

Vengo de PHPstorm y la falta de pestañas de terminal es realmente frustrante, todos los productos Brainstorm tienen pestañas de terminal, es una característica muy útil.

De hecho, una característica útil, pediría a los desarrolladores que la agreguen, esto facilitará la vida cuando necesitemos monitorear más de 2 cosas al mismo tiempo, realmente me gusta la idea @plmrry

+1
las pestañas en la terminal son más amigables con la UX que las seleccionadas y no ocupan mucho espacio

+1

Esta es parte de la razón por la que sigo usando iterm y cmder split screen, ya que puedo ver más de uno a la vez. Tiene sentido que vscode actualmente se pueda ejecutar en varios a la vez, lo que agrega la capacidad de mostrar ambos al mismo tiempo (ya sea que esté dividido horizontalmente o pestañas no debería interferir con el rendimiento).

Si hubiera un problema de rendimiento con eso, vscode también se congelaría si ejecutara npm run server en una pestaña y mongod en otra (o cualquiera de los múltiples comandos que alguien pueda necesitar ejecutar).

Pequeña actualización sobre esto: actualmente estoy consumido haciendo que el terminal sea accesible (https://github.com/Microsoft/vscode/issues/8339), después de eso, la próxima pieza importante en la que trabajaré probablemente sea división de terminal (https://github.com/Microsoft/vscode/issues/7504) que se bifurcó a partir de este problema (y es probable que muchas de las personas que votan a favor de esto realmente quieran). Esto está en la hoja de ruta https://github.com/Microsoft/vscode/wiki/Roadmap#terminal

@AnthonyMichaelc no hay problema de rendimiento con mostrar múltiples, el terminal es súper rápido después de las mejoras recientes .

(dividir) es probablemente lo que muchas de las personas que votaron a favor de esto realmente quieren

@Tyriar He votado a favor de las pestañas porque quiero pestañas, no dividir. Sospecho que la mayoría de las otras personas también querían decir lo que votaron : una terminal estrecha vertical u horizontalmente no lo hace por mí.

... Acabo de leer todos esos, y no puedo creer que me perdí esta idea:

¿Por qué no agregar pestañas adicionales a la barra de pestañas existente, cuando se abren nuevos terminales?
Problems | Output | Debug Console | Terminal 1 | Terminal 2 | Terminal 3 ...
... además, la consola de depuración no es muy útil si no estás usando el depurador ... solo un aparte.

(y es probable que muchas de las personas que votan a favor de esto realmente quieran)

Pegaré solo esto .... (primera publicación en este tema)

Además del comentario de @ericblade , ¡déjame ver al menos 2 paneles (problemas, salidas, consolas, terminales, ...) al mismo tiempo!
Por ejemplo, mientras depuro un servidor, me gustaría observar la salida de algún otro servicio o el observador de archivos que crea mi cliente sin cambiar de vista todo el tiempo, ni siquiera a través de atajos de teclado.
Daría la bienvenida con gusto a los terminales divididos (también en Windows;) como un comienzo, pero las pestañas flexibles aplacables en el panel izquierdo / medio / derecho mejorarían considerablemente la "plataforma de observación" de vscode sin saturar la interfaz de usuario.

@PixelT La primera imagen en la publicación que estás citando tiene pestañas agregadas, exactamente como dice el título. ¿Quizás presentar un PR separado y vincularlo aquí para dividirlo?

@mikemaccana, por favor lea con comprensión mi publicación una vez más, porque veo que no la entiende + No

@PixelT Tienes razón, pensé erróneamente que habías eliminado una imagen, lo siento. Dicho esto: el título y la primera sugerencia son pestañas en lugar de dividir, y sería bueno un problema separado para dividir.

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

¿Podríamos tener la opción de tener pestañas pero desactivarlas por defecto?

Una vista previa de la división ha llegado a Insiders , consulte https://github.com/Microsoft/vscode/issues/7504#issuecomment -365683609 para obtener la actualización completa.

Creo que definitivamente es un paso en la dirección correcta. Estoy seguro de que alguien se quejará de por qué no puedo poner 15 terminales, pero para mí sería genial. Si estoy trabajando en algo como una pila media, puedo tener una terminal doble solo para nodemon y mongos, etc. y luego abrir otro par de terminales para ejecutar los comandos ng serve y generate.

Ahora bien, si la versión estable de vscode tuviera esta opción y la otra característica solicitada de tener un diseño de cuadrícula que he estado esperando, todos los sueños se convertirían en realidad jaja.

Nota al margen: noté que solo después de usarlo durante unos minutos, si trato de alternar entre opt / alt + cmd / ctrl rápidamente, el enfoque parecía estar un poco atrás. (Puede ser solo yo)

@AnthonyMichaelc

Estoy seguro de que alguien se quejará de por qué no puedo poner 15 terminales, pero para mí sería genial.

En realidad, el plan es permitir tantos como desee, aunque solo resolví el problema para n = 2 hasta ahora.

diseño de cuadrícula

Estamos discutiendo activamente esto ahora, incluso tiene un lugar en el plan de iteración de febrero https://github.com/Microsoft/vscode/issues/43361

Nota al margen: noté que solo después de usarlo durante unos minutos, si trato de alternar entre opt / alt + cmd / ctrl rápidamente, el enfoque parecía estar un poco atrás. (Puede ser solo yo)

No he visto esto todavía, pero estaré atento a la lentitud.

@AnthonyMichaelc

Si estoy trabajando en algo como una pila media, puedo tener una terminal doble solo para nodemon y mongos, etc. y luego abrir otro par de terminales para ejecutar los comandos ng serve y generate.

Tener múltiples terminales y editor al mismo tiempo es muy cómodo. En mi vida diaria tengo el primer terminal para el servidor de desarrollo, el segundo para las pruebas unitarias y, a veces, el tercero para git.

Hay una forma hacky de archivar esto en el terminal cmder para Windows abriendo VSC como una de las pestañas del terminal (aquí). No puedo esperar a una solución nativa para Visual Studio Code, porque hay algunos problemas con los accesos directos al usar VSC y Cmder en de esta manera.

@Tyriar como puedo ver, este topis se trata de pestañas en la terminal, sin división ...?

@PixelT está claramente relacionado. Muchas personas han declarado en este número que pueden ver múltiples terminales al mismo tiempo, lo que resolverá la división por el momento, por lo que lo encontrarán útil.

No puedo estar de acuerdo con usted: este tema principalmente observa y discute personas que quieren pestañas en la terminal, para dividir la terminal hay otro tema: https://github.com/Microsoft/vscode/issues/7504 que usted creó :)

Las pestañas y la división de terminales son estándares actuales en casi todos los IDE modernos.

Cambiado a la compilación de Insiders para probar esto, funciona increíblemente, ¡gracias @Tyriar !

todavía no pasa nada con las pestañas en la terminal ... 😕

@PixelT ¿Has probado la versión interna que tiene el terminal dual? Por lo que dijeron, planean hacerlo para que pueda abrir tantos terminales en ese diseño como desee, pero creo que la versión interna actualmente permite 2 con el comando: cmd / ctrl + d, creo

@Morkowski Veo lo que hiciste Sí, tengo una computadora portátil con Windows y una computadora portátil OSX, así que cuando estoy en la computadora con Windows, uso cmder así, cuando en la computadora con OSX utilizo iterm y creo al menos 2 a 3 dentro de una cuadrícula layout y 4 cuando se trabaja en una aplicación de stack media.

Hola @Tyriar, un poco de retroalimentación: cuando se cambia el tamaño de la consola usando los botones Maximize Panel Size o Restore Panel Size (o un atajo de teclado), se olvida el ancho de los paneles de la consola y el ancho de cada panel es restablecer a una cantidad igual.

Al cambiar el tamaño de la consola hacia arriba o hacia abajo con el mouse, se recuerdan los anchos.

Del mismo modo, los anchos se olvidan al ocultar o mostrar la barra lateral izquierda.

Finalmente, los anchos se olvidan al agregar o quitar un panel, aunque este es el más comprensible.

¡Espero que esto ayude!

@jamesjryan se https://github.com/Microsoft/vscode/issues/45074

Del mismo modo, los anchos se olvidan al ocultar o mostrar la barra lateral izquierda.

No puedo reproducir la última versión, crea un problema si lo ves.

Finalmente, los anchos se olvidan al agregar o quitar un panel, aunque este es el más comprensible.

Sí, esto es como está diseñado 🙂

Alguien está escribiendo sobre terminal dividido, no sobre pestañas de terminal aquí nuevamente. Eso no es lo que nos gustaría ver al recibir notificaciones de este ticket :(

7504

@Tyriar actualizado: funciona como se describe, ¡gracias!

@KillyMXI es un progreso hacia el objetivo final y una implementación muy útil incluso en su forma actual.

@isidorn Me pregunto si ha pensado en cómo apoyaríamos inicialmente algo como esto. Cuando agregué pestañas en la terminal justo después de agregar la terminal, necesitaba revertir porque todos estaban en contra de tener pestañas en las pestañas, ¿qué pasaría si hiciéramos que las pestañas de los encabezados del panel sean algo como esto?

Realmente no sé cómo manejar los títulos a veces grandes y necesito decir terminal aquí para diferenciarlo de los demás. Habiendo dicho eso, esta sería mi configuración típica con (dos pestañas, una de las cuales tiene una división) y cabe fácilmente en la pantalla de mi computadora portátil cuando está maximizada, incluso sin ocultar los otros títulos del panel.

Creo que el juego final le está dando al usuario la flexibilidad de poner terminales donde quiera, pero ¿quizás esta es una buena solución provisional?

@jamesjryan No puedo ver la solución de Tyriar como el progreso hacia las pestañas. Me parece una cosa completamente ortogonal.

Hay muchas cosas útiles alrededor, pero tienen lugares adecuados. El lugar adecuado para la terminal dividida es un boleto diferente.

Finalmente volvemos a las pestañas.

Algo similar se propuso anteriormente, en realidad: https://github.com/Microsoft/vscode/issues/10546#issuecomment -359632932
Eso es lo más obvio al reemplazar el menú desplegable con la lista de terminales.

Hubiera intentado

• alinee las pestañas de los terminales a la derecha;
• o agregue una línea vertical antes de las terminales;
• o alinear a la derecha y mostrar una línea vertical cuando se acerquen a los elementos de la izquierda.

Prefiero evitar poner la palabra "Terminal" en cada pestaña. Quedará bastante claro qué es.
O tal vez use la palabra "Terminales:" como una especie de separador visual.

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

Así que este es el resultado final que esperaría aquí:

Tomado de https://atom.io/packages/terminal-tab

Es simple y fácil de entender y brinda flexibilidad al usuario final en cuanto a cómo desea dividir / estructurar su IDE.

Estoy confundido. Ya podemos tener un terminal en la parte inferior, derecha, izquierda o pantalla completa.

Ya podemos tener un terminal en la parte inferior, derecha, izquierda o pantalla completa.

¿Hacemos? ¿Cómo creo una terminal en el lado izquierdo? En este momento, solo puedo ver el lado inferior o derecho.

No puedes hacerlo a la izquierda, pero aún así, este gif me confunde. jajaja

No estoy seguro sobre el complemento Atom (no puedo decir que lo haya usado), pero supongo que podría abrir varios terminales, todos se tratarían como pestañas individuales.

Lo más importante es que se comportan de la misma manera que las pestañas normales del editor, pueden ir en los mismos lugares donde tiene su código. El IDE web Cloud9 hace algo muy similar a esto. Puede abrir tantos terminales como desee, y puede colocarlos donde desee en su espacio de trabajo dentro del diseño de pantalla dividida + pestañas.

Tal vez no entiendo la preocupación, pero básicamente a los diseñadores de UX les preocupa la confusión entre los diferentes tipos de pestañas.

Simplemente ocultaría la barra de pestañas de forma predeterminada y tendría 1 "pestaña" visible. Mantenga la cosa desplegable.

Luego, una vez que se lanza una nueva terminal, si el usuario establece una opción, elimine el menú desplegable y muestre una barra de pestañas.

¿Me estoy perdiendo de algo?

Creo que sería mejor hacer que el terminal sea una pestaña al igual que otras pestañas del editor, y dejar que el usuario decida cómo quiere distribuir las ventanas.

Esto es lo que el gif "confuso" anterior intenta demostrar.

Sí, lo siento si el gif lo hizo más confuso, pero esta es básicamente la premisa a la que estaba tratando de llegar.

En cuanto a que los diseñadores de UX estén preocupados por la confusión, creo que si estás abriendo una terminal, probablemente sepas lo que estás haciendo y no es nada confuso.

Como una especie de solución, configuré los siguientes atajos de teclado:

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

Me permite cambiar rápidamente entre terminales sin necesidad de usar el mouse y ese desagradable selector.

@vedmant , puede refinar eso para que solo funcione cuando el terminal está enfocado si eso también es preferible:

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

Lo siento si ya se ha sugerido algo como esto (solo leí los comentarios) o tal vez debería convertir esto en un nuevo problema. De cualquier manera, avíseme.

Dado el progreso que se ha logrado con el número 14909. ¿Podríamos tener una opción para poner el terminal en una pestaña normal que se trate desde el punto de vista de la ubicación igual que cualquier otra pestaña? Esto les daría mucha flexibilidad a los usuarios sobre cómo quieren ver su terminal. Ahora (o más bien pronto) hay tanta flexibilidad con la forma de ver y organizar las pestañas normales que el terminal ahora es muy limitado en comparación.

@Tyriar workbench.action.terminal.focusPrevious no parece estar funcionando

También probé workbench.action.terminal.focusPreviousPane ya que así es como lo usan los Kebindings predeterminados, pero no funciona ( workbench.action.terminal.focuNextPane no funciona tan bien)

en resumen: solo funciona workbench.action.terminal.focusNext

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

Versiones 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

SO: lubuntu 18.04

Probado sin extensiones

Editar

Gracias Tyriar, escribí cmd lugar de ctrl arriba

@caub , debería crear un nuevo problema si desea ayuda (aunque siempre me ha funcionado bien en Ubuntu 18).

Recientemente me di cuenta de un problema con tener el terminal donde está: hace imposible ver la pestaña de problemas al mismo tiempo.

Supongo que tienes un espacio de trabajo con varios proyectos. Lo que puede hacer es tener una terminal por proyecto y tener una extensión para enfocar la terminal correspondiente en función del archivo enfocado en el editor (y en qué proyecto pertenece)

No resuelve su problema particular, pero hace que sea más fácil cambiar y notar problemas

Estoy de acuerdo en que la selección de terminal no es realmente práctica, solo hay números: 1: bash , 2: bash , .. sería mucho mejor mostrar el nombre base de la carpeta en lugar de

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

Con más práctica, me doy cuenta de que esta propuesta de Tabs es la mejor manera: +1:, actualmente sigo usando mis propios terminales OS independientemente de VSCode, porque la selección de terminales no lo hace práctico, incluso con mejores nombres todavía no sería lo suficientemente práctico

También creo que esto podría resolverse bien si la terminal pudiera vivir como parte del diseño de la cuadrícula, y tendría mucho más sentido desde una perspectiva de UX, donde todo se puede ajustar en cualquier lugar.

@mrmckeb De acuerdo. No estoy seguro de cómo podrían manejar tanto las pestañas como las divisiones, pero es factible. Tmux lo hace.

Espero que podamos acoplar terminales también en los paneles del editor de texto, eso ya sería muy flexible.

He estado viendo este problema durante bastante tiempo y todavía espero que se implemente. Veo que problemas similares se abren con cierta regularidad. Ojalá pueda recapitular qué se pide exactamente y por qué (al menos desde mi perspectiva).

Qué

Básicamente, lo que espero es que se pueda _opcionalmente_ crear una nueva terminal como una _ pestaña del editor_, básicamente replicando el comportamiento de esta extensión de Atom (que me he perdido mucho desde que cambié de Atom a VSCode). Cuando se crea una nueva pestaña de terminal, se trata de la misma manera que una pestaña de editor y se coloca en un grupo de editor. Las pestañas de terminal se tratan en la interfaz de usuario de manera idéntica a las pestañas del editor.

Las pestañas de los terminales no necesitan ser intercambiables con los terminales en el panel para comenzar; inicialmente, podrían crearse como entidades totalmente independientes para recopilar comentarios.

Por qué

Prácticamente vivo en la terminal, y tener pestañas de terminal de esta manera resuelve todos los siguientes problemas y casos de uso:

• Vea y use más de dos terminales simultáneamente. Se hace fácilmente organizando tres o más terminales como quiera en la cuadrícula del editor.
• Use VSCode como mi único emulador de terminal, abriendo una ventana de VSCode con solo una pestaña de terminal en ella.
• Tengo muchas terminales abiertas al mismo tiempo, pero no quiero mirarlas ahora mismo.

Incluso en un mundo de pestañas terminales, me parecería útil la existencia del panel a diferencia de los grupos de editores y no abogaría por la dispensación del panel. El panel tiene sentido para colocar información complementaria distinta del _contenido principal_ con el que estoy trabajando. La clave es que, para mí, una terminal suele ser _contenido de primera clase_ con el que estoy trabajando, y no meramente contenido auxiliar. Con esta perspectiva, es completamente natural que los terminales convivan con los editores.

@sagebind Veo que el primer paso hacia esto es habilitar pestañas de terminal dentro del panel, esencialmente simplemente intercambiando el menú desplegable con algo menos horrible. Esto podría luego construirse de las siguientes maneras:

1. Permita que el panel se coloque de manera más 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. Investigue cómo permitir que los terminales individuales se "separen" del panel y se coloquen en la cuadrícula del editor como está hablando (algo así como se rastrea en este número). Esto necesita un poco de trabajo para descubrir los impactos en UX, comandos, combinaciones de teclas y la API de extensión.

Además, @sagebind , no estoy seguro si alguna vez has oído hablar de ConEmu, pero hace lo que describiste.

Y si eres un jugador de la vieja escuela, tiene un menú desplegable de estilo terremoto (Ctrl + ~). Así que todas mis térmicas permanecen ocultas hasta que llega el momento.

Creo que esta extensión muestra cómo hacer pestañas de forma limpia.

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

@PauloDanielCarneiro Esa extensión en realidad está hecha por uno de los desarrolladores senior de VSCode (@Tyriar)

Sé que este problema es antiguo, pero sería increíble

Esa es exactamente la característica que falta y que evita que todos los administradores de sistemas salten completamente de ISE a VSCode.

Como SysAdmin, paso la mayor parte del tiempo trabajando simultáneamente en varias computadoras.

Me conecto a una computadora remota con CTRL + SHIFT + R.
Esto abre una nueva pestaña de terminal nombrada con el nombre de la computadora a la que estoy conectado.
Y cada pestaña de terminal está vinculada a una o varias pestañas de secuencia de comandos a continuación.
Cambio de las pestañas de script a la pestaña de terminal y viceversa con CTRL + R.

Eso es tan fácil, práctico y poderoso al mismo tiempo ...

¿Se está considerando esta característica?

No es un reemplazo, pero puede usar cmd-\ para dividir su terminal

Gracias @ Hum4n01d, eso es incluso mejor, no sabía nada de eso.

@ Hum4n01d En mi caso, puedo dividir el terminal con Ctrl+] , o simplemente hacer clic en el icono para dividir el terminal en la esquina superior derecha de la ventana del terminal, junto a la opción Kill Terminal .

Si solo necesito 2 o 3 terminales, considero que esta función es muy útil (incluso mejor que las pestañas, porque no necesito pasar de una pestaña a otra para ver el terminal).

Solo en el caso en el que necesite varios terminales, esto podría no ser una solución, aunque las pestañas también podrían no serlo (per se), en su lugar necesitaría algo como pestañas + ventanas flotantes (https://github.com/Microsoft/vscode / issues / 10121).

Sigo creyendo que el mejor enfoque aquí es el que adoptó el equipo de Atom, que tiene terminales intercambiables con pestañas de código. De esta forma, los usuarios pueden crear el espacio de trabajo que deseen de forma modular.

Las pestañas en el área de la terminal serían geniales, pero ¿por qué invertir en hacerlo cuando se podría gastar el tiempo permitiendo que las pestañas de código envuelvan las instancias de la terminal?

Hola. Fui a buscar sobre un problema que tengo y terminé aquí.

Lo único que quiero hacer es usar una Terminal como una pestaña de editor regular

La pantalla de mi computadora portátil de 15 "no es lo suficientemente grande como para jugar con los pequeños terminales apiñados en un panel de sección de salida de construcción. Funciona bien para compilaciones, pero puede ser inapropiado para uso terminal.

Si cambio el tamaño del Panel para que sea grande para poder hacer el trabajo real allí, de repente no tiene sentido que la ventana emergente de salida de la compilación se vuelva muy grande. Y si lo hago pequeño para que sea apropiado para la salida de compilación, entonces no se puede usar para el trabajo de terminal. Estos conceptos de interfaz de usuario no se mezclan y agregar en la barra de pestañas hay más locura.

¿Y qué pasa si, literalmente, no quiero que el trabajo que estoy haciendo en una terminal sea parte de un panel que cambia entre pestañas cuando ejecuto tareas? ¿O subiendo y bajando dinámicamente? ¿De modo que cada vez que construyo, ahora cambio las pestañas en algún otro sistema de pestañas ? ¿Y luego volver a las cosas en las que estaba trabajando en la terminal? Oh, entonces la solución es que podemos dividir el panel ... Esto se vuelve más loco, y tienes una reproducción del mismo sistema de interfaz de usuario que VSCode ya tiene. No tiene sentido.

Sería una mala idea convertir el Panel en un sistema de interfaz de usuario paralelo con modismos competitivos. Varias personas están tratando de hacer esto con hacks deficientes y soluciones alternativas en las extensiones. Por lo tanto, sería bueno que Microsoft tomara el control de la situación solucionando el problema.

@Zyrsha - en ese caso, ¿por qué estás usando VS Code? Parece que obtendría más valor al usar directamente el terminal real que viene con su sistema operativo, con múltiples pestañas. Pregunta honesta / lector muy confundido.

Por cierto, vscode es el primer y único IDE en el que uso el terminal. En mi computadora portátil de 13 "funciona bien para mí. Para otros IDE como eclipse o webstorm, estoy muy feliz de usar Awesome WM para cambiar rápidamente y ordenar las ventanas.

Creo que la idea de usar la terminal (o cualquier otra "ventana") como una pestaña normal es agradable y funciona en eclipse. Pero la terminal tiene un flujo de trabajo ligeramente diferente, al menos para mí. Necesito la posibilidad de cambiar rápidamente al terminal "correcto". Como otros, uso Terminal Tabs para eso:

que, desafortunadamente, no es perfecto debido a problemas como este. Además, no entiendo por qué vsc no debería tener incorporado un terminal sofisticado.

@ shane-smith

el terminal real que viene con su sistema operativo, con múltiples pestañas.

Bueno, la aplicación de consola que viene con Windows no tiene soporte para pestañas AFAIK. Así que eso está fuera. Y Linux no "viene con" un emulador de terminal per se (una distribución podría), tienes que elegir uno que te guste. En este caso parece que el que le gusta a

@sagebind

En este caso parece que el que le gusta a

Oh, estoy de acuerdo, el terminal en VS Code es increíble. Y estoy comentando este tema porque estoy de acuerdo en que tiene margen de mejora.

La parte que me confunde es que parece que la otra persona quiere usar el terminal para editar todos sus archivos, así que me pregunto por qué usarían VS Code, si en realidad no están usando el editor de archivos en absoluto? Al releer su comentario, quizás saqué conclusiones precipitadas y solo quieren editar _algunos_ archivos en la terminal, no todos.

Hola.

La parte que me confunde es que parece que la otra persona quiere usar el terminal para editar todos sus archivos, así que me pregunto por qué usarían VS Code, si en realidad no están usando el editor de archivos en absoluto? Al releer su comentario, quizás saqué conclusiones precipitadas y solo quieren editar _algunos_ archivos en la terminal, no todos.

No, solo quieren tener una pestaña de terminal como pestañas de editor, exactamente lo que tenemos en Cloud9, Atom y algunos otros editores (incluso Vim y Emacs). Para las personas que usan Mac o Linux, es natural tener editores en la parte superior de la ventana y algunas pestañas de terminal en la parte inferior.

Incluso Theia-IDE puede tener varias pestañas de terminal y se basa en algunas partes de VSCode.

Eche un vistazo a estas capturas de pantalla y comprenderá:

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, ignoremos el por qué por un momento y centrémonos en el cómo:

¿Cómo se implementaría esto? ¿Existe una razón arquitectónica por la que las terminales se encuentran en su ubicación actual?

¿Sería posible de una manera eficiente tener un complemento que proporcione terminales en pestañas?

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

¿Cómo se implementaría esto? ¿Existe una razón arquitectónica por la que las terminales se encuentran en su ubicación actual?
¿Sería posible de una manera eficiente tener un complemento que proporcione terminales en pestañas?

Por el lado arquitectónico:

• VSCode tiene muchas pestañas de secuencias de comandos vinculadas a una sola consola (consola integrada de PowerShell) que es muy buena para probar varias secuencias de comandos en una sola máquina . Sin embargo, incluso cuando agrega más terminales, todas las pestañas de secuencias de comandos permanecen vinculadas a la misma consola integrada de PowerShell.
  Al principio, VSCode ha sido escrito por desarrolladores para desarrolladores.

• ISE se ha construido de forma opuesta: puede abrir varias consolas y para cada consola puede vincular varias pestañas de secuencias de comandos (esto es muy bueno para trabajar simultáneamente en varias computadoras).
  Escribimos y ejecutamos simultáneamente varios scripts en diferentes computadoras .
  Al principio, ISE ha sido diseñado para SysAdmins.

Afortunadamente, la forma ISE (pestañas de secuencias de comandos vinculadas a las pestañas de la consola) también funciona para los desarrolladores.
Pero la forma actual de VSCode (pestañas de la consola vinculadas a "una sola" pestaña de secuencias de comandos) no se ajusta a los administradores de sistemas.
Si no desea o no puede revertir el camino (desde Scripts vinculados a Consolas hasta Consolas vinculadas a scripts) al menos deberíamos poder elegir a qué pestaña de la consola queremos vincular cada pestaña de scripting ...

No sé nada sobre ISE, pero definitivamente quiero poder tener el terminal en su propia pestaña o ventana, en lugar de estar conectado permanentemente a la parte inferior de la pantalla. No me gusta tener que ajustar la altura para alternar entre archivos de código y una terminal.

Además, aunque las pestañas de la terminal _suelven_ el problema de querer más de una terminal activa, desde el punto de vista de UX, sería mejor tener terminales en las mismas pestañas que se utilizan para los archivos. Esto asegura que tenga dos combinaciones de teclas estándar para cambiar de pestaña, en lugar de dos estándar y dos para pestañas de terminal (sin incluir las combinaciones de teclas numéricas para cambiar a una pestaña de terminal específica). El flujo de trabajo para dividir el editor usando esas pestañas, o mover pestañas a otras ventanas de VS Code, o cualquier otra cosa que pueda hacer con las pestañas, sería el mismo y crearía una UX estándar. Tal como está ahora, tiene dos flujos de trabajo UX diferentes y no gana mucho con tener los dos.

Entiendo por qué es posible que no se haya hecho hasta este punto, o por qué tenemos Terminal Tabs como solución alternativa, pero terminales en las pestañas del editor / buffers / lo que sea que se esté haciendo en todos los ámbitos en Emacs, Atom y similares, como estándar Experiencia UX, que también me encantaría ver en VS Code.

Ahora que Nuclide está en desuso, me gustaría cambiar a VS Code, pero realmente me gustaría poder leer toda la salida de compilación en el terminal, lo cual es muy difícil con VS Code. ¿Por qué es necesario forzar la terminal a un lugar específico y no tratarse de la misma manera que cualquier otra pestaña / ventana?

Para mí, el problema principal es que no puedo ver cuántos terminales tengo abiertos sin usar el mouse. Y no hay forma de saber en qué dirección debe dirigirse para llegar a una terminal en particular sin pedalear arbitrariamente. Las pestañas fueron mi primer pensamiento, pero supongo que hay otras formas de resolver este problema. Puede, por ejemplo, mostrar opcionalmente terminales activos en la barra del Explorador, con el terminal activo resaltado.

¿Cómo se implementaría esto?

Para Linux, podríamos implementarlo como un caso especial de un enfoque más general: ejecutar comandos definidos por el usuario y proporcionarles un identificador de ventana X de la nueva pestaña. Entonces podríamos ejecutar xterm … -into $VSCODE_TAB … para la terminal, pero también integrar otras cosas muy fácilmente. También sería bueno si hubiera un comando CLI para buscar una instancia de VSCode por directorio de proyecto (predeterminado al directorio de trabajo donde se ejecutó el comando), abrir una pestaña en esa instancia e imprimir el ID de X win en stdouty $DISPLAY VSCode si es diferente por lo que cualquier utilidad externa podría unirse a la GUI de VSCode.

Edición 2: abriré un nuevo ticket para esa idea, ya que no se trata realmente de terminales.

No !!! tab hace que la interfaz de usuario se vea mal ...

@ donnisnoni95

No !!! tab hace que la interfaz de usuario se vea mal ...

Soy muy optimista de que será fácil desactivarlos y / u ocultarlos.

Simplemente convierta el menú desplegable en botones y déles el mismo estilo que las pestañas del editor principal.

Para que quede claro, me gustaría que las pestañas fueran intercambiables con todas las demás pestañas (por ejemplo, las pestañas del código fuente). Al igual que en Atom.

Para ser claro, voy a tomar ya sea soluciones @andraz 's o @floydnoel' s dado que los PO solicitud ha pasado desapercibido desde 2016

@kitsirota Se ha notado y está en la hoja de ruta de este año. Saben que esto, y un problema relacionado con las ventanas flotantes, son las dos características más solicitadas. No estoy seguro de cuándo se iniciará o completará, pero tal vez @Tyriar tenga más información al respecto.

Espero que esto reciba algo de atención pronto debido a la demanda, realmente lo quiero también. Además, como mencionó @jaxspades , está en la hoja de ruta.

Esperando esto y ventanas flotantes desde el primer día que comencé a usar VSCode. Actualmente estoy usando ConEmu. Simplemente no es útil el terminal adjunto y desplegable actual.

Solo una nota (aunque las pestañas definitivamente deberían agregarse a vscode) si todavía está usando ConEmu, puede probar Windows Terminal.

Todavía esperando esto :)

Solo me gustaría ver "Salida" y "Consola de depuración" al mismo tiempo.

No necesariamente necesito pestañas, pero quiero ver Problemas y Terminal al mismo tiempo. Sin embargo, puede ser difícil diferenciarlos sin algún tipo de etiqueta y, por lo tanto, una pestaña puede ser lo mejor. Así que creo que el panel dividido para el terminal debe quitarse y permitir pestañas adicionales para todos los tipos de paneles (Problemas, Salida, Terminal, etc.) Aunque realmente no puedo ver cómo se necesitarían múltiples pestañas de "Salida" o "Problema" como los datos serían idénticos. Entonces, tal vez cuando agregue una nueva pestaña y seleccione qué tipo está agregando, si Problemas ya está abierto, entonces está atenuado y deshabilitado para agregar una segunda y solo se permite Terminal para múltiples. Además, al hacer clic en el indicador Problemas y advertencias en la barra de estado, se debería abrir automáticamente una nueva pestaña Problemas al hacer clic en ella y, si ya está abierta, la eliminará.

Aunque realmente no puedo ver cómo se necesitarían múltiples pestañas de "Salida" o "Problema" ya que los datos serían idénticos.

• Constelaciones creativas de múltiples usuarios más allá del mapeo clásico 1: 1 de pantallas / teclados / focos de entrada a los usuarios.
• Usuario único que distribuye las herramientas utilizadas para la resolución de problemas en varias pantallas o regiones de pantalla. En cuyo caso, sería útil tener configuraciones de filtro, posición de desplazamiento, etc. independientes para cada panel de Problemas / Salida.
• Trabajando alrededor de errores exóticos / funciones faltantes en su software de screencasting.

@Tyriar @jaxspades son 1754: +1: y 187: corazón: ¿no es suficiente? Y 34: cohete :? ¿Cuánto debería ser?

¡¿Esto todavía está abierto ?!

¿Ayudaría a financiar esto colectivamente? ¿Dónde pongo mi dinero?

@Bessonov Quiero pestañas de terminal pero no estoy en Microsoft, así que no tengo voz. Sin embargo, los quiero como editor, no en esa pequeña ventana en la parte inferior de la pantalla. Así que la versión 1.43 se acaba de enviar con los editores de búsqueda, por lo que espero que pronto llegue Terminals. @Tyriar , ¿los editores de búsqueda nos ayudan a acercarnos a las pestañas / editores de terminales?

Editar: agregar un enlace al problema de los editores de búsqueda.

23931

Una vez más, esto está en la hoja de ruta, sucederá con el tiempo. No es necesario que me lo diga, es probable que lo quiera más que todos los presentes y soy consciente de que es el segundo tema más votado. Sin embargo, no es una tarea tan trivial como parece en la superficie. Estamos invirtiendo activamente en el diseño flexible del banco de trabajo:

• Buscar en el panel
• Buscar en el editor
• Todas las vistas de panel y viewlet son intercambiables

Todos estos esfuerzos están alimentando cómo se resolverá este problema y están bloqueando en gran medida el trabajo en la terminal, por ejemplo, el diseño que estamos considerando para este último elemento plantea algunas preguntas muy importantes sobre cómo funcionarán las pestañas en la terminal. a diferencia de las vistas de panel.

Sin embargo, los quiero como editor, no en esa pequeña ventana en la parte inferior de la pantalla.

Aunque traté de separar los conceptos en temas separados hace mucho tiempo, este tema cubre algunas cosas ahora; pestañas dentro del panel de terminales, pestañas de terminales en el editor y pestañas de terminales que se pueden arrastrar entre las dos.

Gracias por las actualizaciones @Tyriar. Eso suena genial: resolver todos estos problemas juntos tiene mucho sentido. Si hay oportunidades para realizar pruebas de usuario, háganoslo saber.

No estoy seguro de que se haya mencionado esta idea, aunque he revisado todos los comentarios:
(También) necesitamos pestañas de terminal no por el aspecto, sino porque actualmente todas las pestañas del editor están vinculadas al mismo terminal.

Actualmente, si quiero generar la ejecución de editores en otra terminal, tengo que abrir una nueva consola de VS Code.

Ser capaz de vincular un panel de editor a otro terminal es especialmente útil cuando desea ejecutar el código de diferentes paneles de editor en diferentes computadoras. Con ISE puede hacer esto en la misma consola.
Actualmente, con VS Code, debe abrir tantas consolas como computadoras en las que desee ejecutar el código de su editor.

@Tyriar ,
Junto con sus notas, también me gustaría poder ver "Problemas" y una ventana de "Terminal" al mismo tiempo uno al lado del otro. Espero que eso también sea posible.
Gracias

@ fullenw1 idea interesante de la que no había oído hablar todavía, ¡gracias!

@ggedde estamos discutiendo activamente cómo funcionaría esto en las reuniones de UX.

Con el problema # 10121 resuelto, esta será más que nunca una buena característica.

Los paneles de terminales necesitan algún tipo de encabezado.

Es imposible saber qué panel es qué ruta cuando tienes varios observadores en

@IceSentry Tuve un problema, pero @Tyriar dijo que era un duplicado de este. Supuse que estaba relacionado porque @Tyriar cerró el mío a favor de esto ... no, no leí 6 años de diálogo :)

No sé si alguien ha señalado esto todavía, pero las pestañas de Terminal que son intercambiables en la interfaz de usuario con las pestañas del editor, así como una consola de interfaz de usuario fija, son características en el IDE de Cloud9, si quieres un ejemplo de cómo ' Espero que esto funcione. Ni siquiera necesita deshacerse del antiguo panel de Terminal, solo haga que se pueda ocultar (como está ahora) y reemplazarlo con un panel de "editor" ordinario que contenga pestañas de Terminal.

Otra ventaja de los terminales en Cloud9 es que se adjuntan a instancias tmux (IIRC) en lugar de terminales directos. Esto permitió que la interfaz se cambiara de escala (es decir, se apagara) sin perder los procesos de la terminal, y que se conectara sin problemas a un nuevo cliente (una característica que sería muy útil para los usuarios de VS Code en la nube), e incluso compartir instancias de terminales de clientes con otros (hipervisor -nivel) usuarios.

Hay extensiones para hacer esto para el VS Code Terminal integrado, pero si está buscando una abstracción para terminales, sería genial incluirlo en abduco .

Pestañas de terminal que son intercambiables en la interfaz de usuario con pestañas del Editor

Esto es simplemente brillante.

Podríamos deshacernos de la consola inferior y convertir todos sus paneles (Problemas, Salida, Consola de depuración y todos los terminales) en pestañas de editor normales, que se pueden abrir según sea necesario, cada tipo de panel tiene un icono específico.

Como referencia, las páginas de información de la extensión, la interfaz de usuario de configuración, los atajos de teclado y probablemente otras cosas ya se manejan de esta manera, como pestañas de editor normales con un ícono personalizado.

Esto permitiría a las personas dividir y organizar sus terminales como les plazca, utilizando las funciones existentes para dividir y organizar las pestañas del editor.

Por supuesto, los terminales deben seguir ejecutándose en segundo plano incluso después de cerrar la pestaña del editor correspondiente, que podría volver a abrirse según sea necesario. La sugerencia adicional de usar tmux o dtach para mantener la sesión de terminal ejecutándose en los reinicios de VSCode también es una gran idea, pero pertenece a un problema diferente.

Con la nueva api de webview, probablemente ya podamos hacerlo en algún momento.
Pero eso significa que debe escribir todo el manejo de launch.json por su cuenta, lo cual no es ideal.

Sin embargo, existe la ventaja de convertirlo en una 'pestaña' del editor, porque la pestaña del editor puede tener controladores Serializar / Deserializar.
Por lo tanto, es posible darle al terminal el comportamiento de guardar y restaurar. (como, guarde la identificación de la sesión tmux y vuelva a adjuntar en la restauración)

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

@ mmis1000 es ciertamente posible construir con la API webview ahora, pero faltará toda la integración, comandos, características como manejo de enlaces, acceso a la API de extensión y, en general, actuará como una cosa separada.

La función de guardar y restaurar se rastrea en https://github.com/microsoft/vscode/issues/20013

@Tyriar En realidad pensé en generar una instancia Terminal lugar y usarla como instancia subyacente de pty, por lo que al menos cosas como la integración de git funcionarán (parece que necesita pasar algo de env a la terminal).

Sin embargo, resulta que la api vscode expuesta es demasiado limitada. No solo no expuso el proceso pty subyacente, tampoco expuso funciones stdio y terminal como pty resize. Hace que sea totalmente imposible utilizarlo como fuente pty. Así que me vi obligado a engendrar el pty por mi cuenta.

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

Hola @ mmis1000, ¿ podrías agregar algunas instrucciones de instalación?

@ mmis1000 está limitado por diseño, ya que debería ser parte del producto principal, también hay problemas de rendimiento con el evento window.onDidWriteTerminalData , por lo que está atascado en la propuesta. Si bien este tipo de extensión podría ser útil como solución temporal, me preocupa la posible gran cantidad de usuarios una vez que logremos que los terminales funcionen dentro del área del editor. Otro problema que podría tener es la dependencia de node-pty enviado como parte de vscode, esta no es una API pública destinada al consumo y probablemente romperá su extensión en el futuro.

@Tyriar Como usuario de cloud9 (y seguir siendo usuario de cloud9 ahora).

Es un poco útil usar cualquier área de la pantalla como terminal y con la sesión persistente respaldada por tmux.

En su mayoría, solo uso cloud9 como terminal web para controlar el VPS. (Y esta es la ÚNICA razón por la que todavía lo uso ahora. Porque vscode realmente hizo mal con la terminal. Es un dolor enorme perder la terminal por accidente y volver a abrirla cada vez).

Cloud9 siempre muestra la misma ventana, el mismo editor, el mismo terminal y la misma sesión en el mismo lugar que ve antes de cerrar el navegador ayer. Si no puede encontrar la sesión (tal vez el servidor se reinició), al menos volverá a abrir una nueva con el mismo entorno para usted.

Si estoy a punto de usar otro servicio de edición en línea (quiero decir, abrir en el navegador), espero que los admita de inmediato (o al menos se pueda lograr por extensión), porque es poco probable que no cierre su navegador ( intencionalmente o por accidente) en absoluto.

(También porque cloud9 hizo esto hace años, por lo que realmente no creo que sea un problema técnico)

La experiencia de terminal que proporciona vscode no me parece realmente un producto de última generación para ser honesto.

@ mmis1000 ¿Podría agregar algunas instrucciones de instalación?

El repositorio https://github.com/mmis1000/Vscode-terminal-tab tiene su propio rastreador de problemas. Cualquiera que sienta la necesidad de preguntar sobre ese proyecto, por favor pregunte allí.

Para una demostración sobre qué terminal espero ver en un ide remoto / basado en navegador.
Esperaría que simplemente restaurara la posición de la pestaña / sesión de terminal cuando la cerré ayer.
En lugar 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 .

Ese es otro problema https://github.com/microsoft/vscode-remote-release/issues/3096 .

@xgdgsc parece probable, pero no lo es.

Lo que espero es que el terminal esté disponible universalmente incluso en una instancia de vscode local. (al menos hasta el punto que lo hace iterm2)
¿Por qué una función tan útil debe limitarse a la conexión remota?

Y tampoco persistí en la conexión ssh, solo conecté un multiplexor de terminal y ejecuté las cosas allí.

@ mmis1000 nuevamente que se rastrea en https://github.com/microsoft/vscode/issues/20013 , consulte allí para obtener las últimas novedades. Intenta mantenerte en el tema, ya que hay muchas personas a las que se les notifica cuando comentas sobre este tema.

¿Existe alguna posibilidad de tener esto en las siguientes iteraciones?

Abrir terminal como una pestaña de página de editor normal es una idea maravillosa para mí, y la necesito mucho.