Vscode: Pestañas adecuadas para archivos abiertos

+1

¿Sería posible agregar pestañas a través de una extensión personalizada? Miré rápidamente los documentos pero no parecía posible agregar ese tipo de funcionalidad con la API actual

¿Sería posible agregar pestañas a través de una extensión personalizada?

No, esto no es posible actualmente desde una extensión (ver también http://code.visualstudio.com/docs/extensions/our-approach)

+1

: +1:

: +1:

+1

Las pestañas son la forma predeterminada de trabajar incluso en Visual Studio, por no mencionar otros editores de texto como sublime.

Para aquellos a los que les faltan pestañas, ¿ha intentado usar Ctrl+Tab para navegar en el historial de archivos abiertos?

Si. Pero el archivo permanece en el contexto Ctrl+tab incluso después de cerrar el archivo. La experiencia no es la misma que la de Sublime / Atom.

@snehilmodani correcto, ¿ayudaría si la lista mostrara solo lo que tiene en la sección de archivos de trabajo del explorador? ¿Puedes trabajar con la lista de archivos de trabajo al menos?

¡Eso seria genial!

En una nota al margen: no es un diseño con nombres de archivo como pestañas más fáciles de usar. Es extensible para tener una o más secciones de pestañas, cada una con su propio conjunto de archivos abiertos. (Nuevamente, estoy tomando Sublime Text como referencia aquí)

Creo que tener pestañas o no es independiente de tener secciones. Hoy puede abrir hasta 3 editores uno al lado del otro en VS Code y, por lo tanto, tenemos secciones. Dado que no tenemos pestañas, no agregamos varios archivos en estas secciones y tampoco puede tener secciones vacías (que es una discusión de UX separada).

Volviendo a Ctrl + Tab: nosotros en el equipo siempre hemos trabajado sin pestañas desde el primer día y en realidad ni siquiera tuvimos la vista de archivos de trabajo durante mucho tiempo y, de hecho, no muchas personas en el equipo la están usando. Descubrimos que para nosotros no importa mucho qué archivo tenía abierto o cerrado. Nuestras mentes piensan más bien en el orden cronológico del último archivo que editamos. Entonces, cuando abro Ctrl + Tab, generalmente me mostrará los archivos en los que estaba el último. Realmente no estoy mirando la cantidad de archivos allí, solo estoy interesado en los 5 primeros como máximo. La ventaja de este modelo es que no tiene que administrar diseños y pestañas en absoluto. La gestión se realiza de forma natural mientras navega entre archivos.

Podemos agregar un selector de archivos para los archivos de trabajo, pero sería interesante saber si se puede convencer a las personas de que usen Ctrl + Tab como está ahora y sepan cuáles son los problemas.

@bpasero Le daré una ctrl+tab , me acabo de dar cuenta de que se puede usar para pasar al archivo anterior, que es algo que quería y no había investigado hasta ahora. Entonces eso es bueno.

Por cierto, independientemente de si uno puede arreglárselas / acostumbrarse a ctrl+tab como alternativa a las pestañas, los nuevos usuarios del código VS probablemente se desanimen por la falta de pestañas, por lo que aunque solo sea por razones de participación en el mercado, recomiendo tener una opción de pestañas. Todos los demás editores usan pestañas (para bien o para mal), y no tenerlas introduce una barrera de entrada bastante innecesaria al código VS. Estoy usando el código VS independientemente de la compatibilidad con las pestañas debido a su increíble compatibilidad con mecanografiado, pero si no fuera por eso, no sé si lo hubiera mantenido las primeras veces que lo probé.

Sí, Ctrl+Tab se trata de navegar hacia atrás en el historial de archivos en los que se está trabajando. Puede mantener presionada la tecla Ctrl y presionar Tab repetidas veces para volver más allá de 1 archivo.

Ctrl+tab es algo maravilloso y soy un fanático de él. Es algo que incluso Atom se pierde.

Con respecto a las pestañas y varios archivos en cada sección: incluso en Sublime Text podemos abrir 3 editores uno al lado del otro, pero aún ofrecen un diseño con pestañas seccionales. Estoy de acuerdo con usted en el desorden y administrar el diseño del editor sería una gran tarea, pero la gente está acostumbrada a eso de todos modos.
Me encantaría ser parte de un experimento social en el que intentas convencernos de deshacernos de nuestras interacciones desordenadas basadas en diseños con nuestros editores.

Estoy de acuerdo con usted en el desorden y administrar el diseño del editor sería una gran tarea, pero la gente está acostumbrada a eso de todos modos.

Bueno, estoy seguro de que podemos encontrar más ejemplos de UX donde solíamos estar acostumbrados a algo y luego nos acostumbramos a algo mucho mejor :). Piense en la interacción entre el teclado del teléfono móvil y el teléfono inteligente.

Me encantaría ser parte de un experimento social en el que intentas convencernos de deshacernos de nuestras interacciones desordenadas basadas en diseños con nuestros editores.

Sí, creo que tendremos que hacer algo como este 2016. @stevencl fyi

Con respecto a las pestañas y varios archivos en cada sección: incluso en Sublime Text podemos abrir 3 editores uno al lado del otro, pero aún ofrecen un diseño con pestañas seccionales.

Estoy de acuerdo en una opción para permitir secciones más estables para que podamos tener secciones vacías, pero poder ver pestañas en esta sección es solo una representación visual de los archivos que en la mayoría de los casos crecen tanto que terminas no viendo cualquier cosa. No creo que las pestañas sean una buena manera de mostrar la lista de archivos abiertos a menos que administre estas cosas activamente y las cierre.

No creo que las pestañas sean una buena manera de mostrar la lista de archivos abiertos a menos que administre estas cosas activamente y las cierre.

Algunas personas realmente los administran y para otros hay pestañas cercanas a la derecha.

Muchas gracias por el comentario.

Tenemos un problema en nuestro backlog de UX (# 1133) para mejorar la administración del espacio de trabajo (administración de archivos abiertos, historial, etc.) del cual esto sería parte. Nuestra intención es mejorar la experiencia de modo que la gestión de la lista de archivos abiertos y recientes sea sencilla y sencilla y permita al usuario centrarse en su código, sin tener que prestar atención indebida a la interfaz de usuario de VS Code.

Nuestra hipótesis es que el sistema actual tiene algunas asperezas (p. Ej., Cerrar un editor en realidad cierra el editor, pero creemos que tal vez debería mostrar el archivo que estaba previamente abierto en ese mismo editor) y que suavizar estas asperezas ayudar a crear una experiencia mucho mejor.

Realizamos estudios de UX sobre el producto de forma muy regular. De hecho, así es como diseñamos gran parte de la UX en el producto. Repetimos nuestros diseños basándonos en comentarios reales, asegurándonos de utilizar un gran conocimiento de lo que las personas hacen y quieren hacer con el producto para informar nuestros diseños.

Si desea participar en estos estudios en el futuro (no volveremos a realizar ninguno hasta mediados de enero como muy pronto), hágamelo saber y agregaré su nombre a la lista.

Si desea participar en estos estudios en el futuro (no volveremos a realizar ninguno hasta mediados de enero como muy pronto), hágamelo saber y agregaré su nombre a la lista.

¡Inscríbeme!

No creo que las pestañas sean una buena manera de mostrar la lista de archivos abiertos a menos que administre estas cosas activamente y las cierre.

La gestión de pestañas es una parte inconsciente y desinhibida de mi desarrollo. VS-apropiado tiene pequeñas pestañas discretas, que no son intrusivas (vscode ya tiene el nombre de archivo ocupando espacio donde la pestaña estaría de otra manera). Estoy de acuerdo en que el spam de pestañas fuera de control es un problema, podría ser bueno innovar y abordar esto, pero yo diría que es una prioridad menor que tener pestañas. VSCode necesita alcanzar un estado de funcionamiento mínimo. En este momento, encuentro que se está acercando mucho, pero todavía no puedo trabajar de manera productiva. Comenzar con patrones establecidos probablemente nos haría trabajar antes.

Vale la pena tener en cuenta que no todos son desarrolladores web, creo que los patrones y el flujo de trabajo tienden a ser ligeramente diferentes para diferentes idiomas y estilos de aplicación. Como desarrollador nativo, es común tener visibles un conjunto de archivos asociados; cpp + h , quizás también un inl , y normalmente no trabaja en un solo archivo de forma aislada. A menudo tengo una vista de desmontaje visible junto al código. Mi entorno de editor abarca 2 monitores, con 4 archivos visibles en un momento dado, y me costaría trabajar en un entorno más restrictivo que ese.
También extraño poder tomar una pestaña y convertirla en una pequeña ventana flotante, que a menudo establezco en 'siempre arriba', que generalmente se usa como punto de referencia, o algo que estoy haciendo mucho para copiar pasando a / desde.

En este momento, por ejemplo, estoy intentando refactorizar y simplificar algún código heredado; mi conjunto de archivos de trabajo actual es ... component.cpp, component.h, component.inl, componentimpl.cpp, componentimpl.h, icomponent.h. ¡Son 6 archivos! Y no puedo escapar del ajuste ocasional de algunos otros archivos en la periferia. Utilizo ctrl-tab libremente cuando estoy trabajando en ese estilo de proyecto (cambiando entre 2 archivos), pero en este contexto / base de código, simplemente no puedo trabajar sin pestañas.

Refactorizar y mantener el código heredado tiene un flujo de trabajo muy diferente al de escribir código nuevo (lo que imagino que ustedes están haciendo, y que usan principalmente como una guía para el diseño de UX).

Mi punto aquí es; hay un deseo moderno de reinventar todo, y hemos visto grandes avances en el diseño de UX en los últimos años; vscode ya presenta algunos de estos, pero tenga cuidado y aplique su buen juicio al decidir cambiar la forma en que las personas han estado trabajando durante décadas. Muchos diseños establecidos se establecen porque son buenos y eficientes, no porque sean viejos y necesiten una actualización para estar más de moda :)

¡Agradecería la oportunidad de ser parte de estos estudios de enfoque!

Mi punto aquí es; hay un deseo moderno de reinventar todo, y hemos visto grandes avances en el diseño de UX en los últimos años; vscode ya presenta algunos de estos, pero tenga cuidado y aplique su buen juicio al decidir cambiar la forma en que las personas han estado trabajando durante décadas.

Es el caso para mí. De hecho, no puedo trabajar sin pestañas. Estoy trabajando con el sistema de pestañas desde hace años, y sin ellos, estoy realmente perdido. Esta es una de las razones por las que no estoy usando Code en realidad.

Muchos diseños establecidos se establecen porque son buenos y eficientes, no porque sean viejos y necesiten una actualización para estar más de moda :)

: +1:

Hasta ahora, no he escuchado una buena razón para las pestañas en comparación con tener solo una lista de "archivos de trabajo" en alguna parte. Ser capaz de tomar un archivo y arrastrarlo a una nueva ventana claramente no es un beneficio de un sistema de pestañas, es una característica que puede tener sin pestañas.

¿Es que la gente realmente quiere abrir archivos en pestañas, moverlos y cerrarlos eventualmente? ¿Esto se debe a que está tan acostumbrado o realmente vale la pena hacerlo? ¿El valor es capaz de establecer un conjunto de archivos de trabajo activo que luego descarta para comenzar algo nuevo? Me pregunto qué tiene de bueno tener pestañas que no se puede lograr con otra forma de representación. Y no acepto el argumento de que todo el mundo está acostumbrado a las pestañas :). Mucha gente está acostumbrada a guardar archivos y todavía hay editores con capacidad de guardado automático y a la gente parece gustarle.

Incluso si no lo es de forma predeterminada, dar al usuario la opción de activar la función de pestañas a través de alguna opción sería casi tan bueno para mí.

Por ejemplo, ¿qué hay de dejar que el usuario mueva / arrastre la sección "Archivos de trabajo" hacia la parte superior (convirtiéndolos en pestañas, digamos)? Nuevamente, el usuario puede elegir cómo quiere trabajar y creo que eso es genial.

Para mí, no es tanto la apariencia de las pestañas como su comportamiento lo que extraño. (Por ejemplo, puede hacer que Sublime Text se parezca a VS Code, ya que puede ocultar la barra de pestañas y mostrar los archivos abiertos en la barra lateral ... pero aún se comportan exactamente como lo hacen las pestañas).

Lo primero que hago con VS Code es intercambiar su archivo de cierre y cerrar los atajos de teclado del editor activo, de modo que ctrl + W realmente cierra un archivo cuando lo presiono, en lugar de dejarlo en archivos de trabajo y abarrotar ctrl + tab.

Pero incluso entonces, cada vez que cierro un archivo, me saludan con una pantalla en blanco y tengo que ctrl + tabulador solo para mostrar el archivo de trabajo aún abierto más reciente (diablos, cuando es el último, parece que también necesito presione enter después de ctrl + tab; no estoy seguro de qué se trata). En cualquier otro editor, inmediatamente sería recibido por el archivo (pestaña) abierto más reciente o adyacente al cerrar el actual.

Además, ctrl + tabulador entre archivos de trabajo parece funcionar en el orden más reciente, a diferencia de las pestañas que normalmente operan en el orden en que aparecen o están organizados. (He visto que algunos editores admiten ambos).

No uso ventanas divididas, por lo que si alguna de estas diferencias de comportamiento tiene algo que ver con eso, no entiendo. Tal vez lo entendería mejor si lo entendiera desde ese ángulo, pero ¿no seguiría siendo la no división el caso de uso más común?

En cualquier caso, son pequeñas pero frecuentes fricciones como estas las que me mantienen alejado de VS Code y volviendo a otros editores. Sí, se podría decir que VS Code funciona de manera diferente a lo que estoy acostumbrado. Pero cuando lo que estoy acostumbrado a _funciona_, y VS Code operando de manera diferente causa fricciones con las que preferiría usar un editor diferente para evitar tener que lidiar, es un gran problema.

Sí, puedo ver un modelo en el que el área del editor se comporta de manera similar a las pestañas sin mostrar pestañas. Queremos explorar esto el próximo año.

Por cierto, hay una extensión que, una vez que cierra un editor, abre el siguiente desde los archivos de trabajo. Si combinas eso con cambiar la combinación de teclas como sugiere @kfranqueiro , te acercas bastante en mi humilde opinión.

Aquí está el enlace: https://marketplace.visualstudio.com/items/bigous.file-smart-reopener-vscode

Hasta ahora, no he escuchado una buena razón para las pestañas en comparación con tener solo una lista de "archivos de trabajo" en alguna parte. Ser capaz de tomar un archivo y arrastrarlo a una nueva ventana claramente no es un beneficio de un sistema de pestañas, es una característica que puede tener sin pestañas.

Seguro, puede ser posible hacerlo de otra manera ... pero ¿por qué? A menos que tenga alguna mejora o innovación significativa que ofrecer.

¿Es que la gente realmente quiere abrir archivos en pestañas, moverlos y cerrarlos eventualmente?

si

¿Esto se debe a que está tan acostumbrado o realmente vale la pena hacerlo?

En parte hábito, pero también porque nadie ha presentado nada significativamente superior todavía. La innovación debería presentar una ventaja significativa si va a insistir en que las personas luchen y se vuelvan a capacitar contra sus hábitos de décadas.

¿El valor es capaz de establecer un conjunto de archivos de trabajo activo que luego descarta para comenzar algo nuevo?

No estoy muy seguro de entender esta frase exactamente; ¿Está tratando de describir una alternativa en la que trabaja en términos de múltiples conjuntos de 'archivos de trabajo'? Difícil de imaginar. No estoy seguro de que sea de utilidad universal. Para las tareas heredadas, de mantenimiento y de refactorización, creo que sería una gran desventaja trabajar de esta manera, ya que su conjunto de trabajo generalmente no se conoce de antemano, sino que es emergente a medida que trabaja. El modelo tradicional ya funciona bien en estos flujos de trabajo.

Me pregunto qué tiene de bueno tener pestañas que no se puede lograr con otra forma de representación.

Desde una perspectiva diferente; considere la utilización del espacio. Ya hay una pestaña en la parte superior de la ventana de código, es donde está el nombre del archivo, simplemente no tiene el rectángulo de pestaña alrededor del nombre (incluso se comporta como una pestaña; si hace clic con el botón central, se cierra). A la derecha del nombre del archivo encima de la ventana de código hay un espacio vacío vacío (donde deberían estar las pestañas).
En la parte superior izquierda del espacio de trabajo está la lista de 'archivos de trabajo'; este es un espacio doblemente desperdiciado ya que simplemente no necesita existir, su espacio podría moverse al espacio donde generalmente están las pestañas, llenando ese espacio desperdiciado.

También encuentro una diferencia práctica adicional a la utilización del espacio y la tendencia habitual; Me gusta tener las pestañas asociadas con la ventana del editor a la que están vinculadas. Por lo general, tengo al menos 2, 3, a menudo 4 ventanas de código abiertas (en vs-adecuada), y cada una tiene un par de pestañas asociadas. Quizás en una ventana tengo widget.cpp/.h , y en la otra tengo gizmo.cpp/.h/.inl . Estas pestañas están asociadas lógicamente con la ventana de código a la que están adjuntas, y eso me agrada.

Y no acepto el argumento de que todo el mundo está acostumbrado a las pestañas :). Mucha gente está acostumbrada a guardar archivos y todavía hay editores con capacidad de guardado automático y a la gente parece gustarle.

Bien, lo acepte o no, la gente lo encuentra como un argumento razonable y fuerte. Pero me reservaré mi juicio si tiene algo significativamente mejor en mente. Por supuesto, si cree que puede mejorar significativamente las pestañas, inténtelo, pero no lo fuerce obstinadamente solo por la innovación 'de moda';) .. Debe ser sustancialmente superior para expulsar el estado quot .

Solo puedo decir que la lista actual de 'archivos de trabajo' definitivamente no es superior. Básicamente son pestañas, simplemente organizadas verticalmente, excepto con las desventajas de que las pestañas están separadas de la ventana del editor y la lista vive en un espacio desperdiciado mientras que la ubicación habitual de las pestañas está vacía.
Tampoco me gusta que la lista de 'archivos de trabajo' tenga una altura dinámica, lo que significa que el árbol del proyecto se mueve verticalmente, y sospecho que me gustaría aún menos si los 'archivos de trabajo' tuvieran una altura fija y una barra de desplazamiento vertical en lugar.

Simplemente no es superior a las pestañas normales y, por lo tanto, no ofrece una razón convincente para adaptarse ... en mi opinión :)

+1 @TurkeyMan

En el equipo de VS Code llevamos trabajando sin pestañas y sin archivos de trabajo desde el principio (4 años) y no nos falta nada. Entonces, personalmente, estoy de acuerdo en que la sección de archivos de trabajo es espacio desperdiciado y mantengo esa sección colapsada. Sin embargo, también trabajamos con el guardado automático habilitado y, por lo general, no nos preocupan los archivos sucios. Los archivos de trabajo se introdujeron principalmente para que los archivos sucios y sin título aparecieran. Más tarde decidimos que también era un lugar útil para ayudar a las personas a las que les faltan las pestañas tradicionales porque es una representación similar, solo que en otra forma de interfaz de usuario.

Reservamos espacio encima del editor para mostrar información y acciones del archivo. Se podría argumentar que este espacio es el mismo que se necesita para las pestañas. Pero mi argumento contra las pestañas es que, por lo general, el espacio horizontal no es suficiente para mostrar la lista de archivos de trabajo porque rápidamente terminas con esto:

Esta es la pesadilla que tratamos de evitar: debe desplazarse hacia la izquierda y hacia la derecha por la lista de pestañas para encontrar los archivos que desea. Las pestañas solo funcionan bien siempre que no tenga más pestañas abiertas de las que se pueden mostrar horizontalmente. Una vez que una pestaña se vuelve lo suficientemente pequeña como para ocultar el nombre del archivo, debe comenzar a cerrar otras pestañas solo para ver qué está sucediendo.

Ahora, obviamente, los archivos de trabajo tienen un problema similar, solo que en otra dimensión. Es por eso que nosotros en el equipo usualmente usamos Ctrl+Tab para todo y no nos importa lo que esté abierto o no.

Para resumir: los archivos de trabajo no son nuestra respuesta para reemplazar las pestañas, es más bien la combinación de archivos de trabajo y Ctrl+Tab . Y nuestro equipo está más o menos al 100% en usar Ctrl+Tab y nada más.

Su imagen parece exagerar innecesariamente el problema; ventana poco realista, bordes de pestañas diagonales, demasiado texto en la pestaña, punto a la derecha;)
vs-apropiado clava las pestañas a la perfección, y no hay razón para no rodar con pestañas pequeñas y discretas como lo hace.

Soy un usuario muy liberal de Ctrl-Tab cuando es aplicable, pero no puede usar Ctrl-Tab a menos que esté editando activamente no más de 2 o 3 archivos.
Tengo la sospecha de que su opinión sobre este asunto puede estar bastante sesgada hacia su proyecto en particular, y eso podría incluir un sesgo de idioma. En C / C ++, el número típico de archivos de trabajo se duplica o triplica cuando acepta que hay un .h , y en mi caso, a menudo un .inl complementando cada .cpp . Ctrl-Tab es menos efectivo en este escenario, y tiende a usar Ctrl- ~ en su lugar (alternar cpp / h; para lo cual también he publicado una solicitud de función), junto con la administración de pestañas.
O considere Java, donde cada clase, sin importar cuán pequeña sea, debe vivir en su propio archivo.

En mi día a día actual, a menudo tengo un conjunto de trabajo de decenas de archivos, Ctrl-Tab no me sirve cuando trabajo de esta manera. El flujo de trabajo más práctico es de 2 a 4 ventanas de editor y un par de pestañas por ventana. No elegí este diseño porque me encanta; simplemente surgió, porque es el diseño de espacio de trabajo más eficiente para este trabajo en particular.

+ 1
Por lo general, tengo el editor dividido y cerrar una pestaña es un poco más intuitivo que tener más de 10 archivos de trabajo.

También suelo trabajar solo en un subconjunto de archivos y me gusta tenerlos a mano. 5/5 es más fácil de administrar que una lista de 10 para mí personalmente. También me muevo activamente entre ellos continuamente. Las pestañas también ayudan porque hay una indicación visual de que tienes demasiadas abiertas: el 'infierno de pestañas' que muestra @bpasero.

Acepto que las pestañas no son necesariamente el santo grial de la gestión de ventanas. Sin embargo, para los idiomas o proyectos en los que se trabajará con varios conjuntos de archivos, las pestañas supondrían menos esfuerzo de gestión.

Un ejemplo simple sería .cpp y '.h' con pestañas, serían dos clics ambos enfocados en la parte superior de la ventana, mientras que con archivos de trabajo serían 3-4 clics con archivos de trabajo que requieren que seleccione el editor en cuestión y luego seleccione el nuevo archivo para editar.

Las pestañas y las pestañas personalizadas también permitirían agregar más fácilmente algunas extensiones interesantes. Un ejemplo es una consola o una pestaña de gráfico. Estos requerirían entradas especiales en la sección del selector de archivos o tendrían que descartarse al cerrar con el sistema actual. Con mucha frecuencia vuelvo a mis parcelas, por lo que cerrar la ventana requeriría volver a trazarla. O la consola se cerraría y los datos del interior se perderían.

Sin embargo, si hay una alternativa adecuada disponible, me complacerá probarla. Simplemente siento que el espacio horizontal en las pantallas actuales es más grande que el espacio vertical que el diseño actual de administración de ventanas no aprovecha. Aunque no me gustaría que las pestañas fueran más grandes verticalmente que los nombres actuales en cada ventana.

Tengo curiosidad por saber por qué hay tanto retroceso en la implementación de pestañas. Técnicamente no es difícil y ya hay archivos de trabajo implementados; ¿Por qué no ambos y dejar que los usuarios decidan?

Esto suena casi como espacios v. Pestañas, 2.0

Tengo curiosidad por saber por qué hay tanto retroceso en la implementación de pestañas. Técnicamente no es difícil y ya hay archivos de trabajo implementados; ¿Por qué no ambos y dejar que los usuarios decidan?

Esto suena casi como espacios v. Pestañas, 2.0

Totalmente de acuerdo, probablemente sea mucho más fácil impulsar la función como una opción (desactivada por defecto si hace feliz a la gente anti-pestaña), y rastrear el uso a través de estadísticas / comentarios que teorizar interminablemente sobre si tiene sentido o no.

Me doy cuenta de que parece como si hubiéramos estado teorizando sin cesar sobre esto en lugar de hacer algo y disculparnos por eso. Sin embargo, tenemos un elemento para abordar esto en nuestra cartera de pedidos (mencionado anteriormente - # 1133). Simplemente no hemos podido dedicar una cantidad significativa de tiempo a esto recientemente, ya que hemos estado trabajando duro en la localización y la accesibilidad.

Como mencioné anteriormente, somos conscientes de los problemas con la experiencia actual para administrar archivos y tenemos una serie de cambios que queremos hacer para mejorar la experiencia.

Uno de nuestros objetivos con VS Code es que, a medida que realizamos cambios en la interfaz de usuario y la UX, nos aseguramos de que VS Code siga siendo un editor ligero y potente que permite a los usuarios centrarse en su código. Una de las formas en que intentamos lograr esto es teniendo mucho cuidado con cualquier nueva interfaz de usuario que agreguemos al producto.

Nuestra preocupación con agregar pestañas es que introduce otro conjunto de problemas que terminan requiriendo que el usuario se concentre en la interfaz de usuario en lugar del código. Nuestra experiencia con Visual Studio, por ejemplo, nos ha demostrado que muchos usuarios a menudo terminan con muchas pestañas abiertas que contienen archivos que ya no necesitan y que terminan abarrotando su espacio de trabajo. Esto causa algunos problemas cuando los usuarios buscan archivos y otros activos de código. Para resolver esos problemas se necesita más IU que permita a las personas cerrar todas las pestañas, cerrar todas las pestañas excepto esta pestaña, controles de desbordamiento de pestañas, etc. Queremos evitar esta situación y esperamos que los diseños en los que estamos trabajando nos ayuden a lograrlo.

Este no es un debate ideológico; realmente estamos tratando de mantener la estética mínima que creemos que brinda una experiencia liviana y poderosa. Simplemente estamos siendo muy cuidadosos con la introducción de nuevas UI y UX en el producto.

Es muy posible que después de algunas rondas de diseño e investigación sobre esto, terminemos introduciendo pestañas. Pero solo lo haríamos sabiendo que esta es la mejor manera de mejorar la forma en que los usuarios administran los archivos y activos con los que trabajan, pero sin terminar saturando la interfaz de usuario.

Espero que esto ayude a explicar nuestra opinión al respecto. Y me disculpo de nuevo por hacer que parezca que estamos mirando el ombligo y no estamos haciendo nada al respecto.

Gracias @stevencl , es bueno que al menos esté en el radar y que haya algo de lluvia de ideas.

Nuestra preocupación con agregar pestañas es que introduce otro conjunto de problemas que terminan requiriendo que el usuario se concentre en la interfaz de usuario en lugar del código.

Sin embargo, siento que necesito centrarme en la interfaz de usuario en lugar del código en este momento, por lo que este argumento se corta en ambos sentidos. :)

muchos usuarios terminan con muchas pestañas abiertas que contienen archivos que ya no necesitan

Es interesante que diga esto, ya que tuve la impresión de que parte del objetivo de trabajar con los archivos _ era_ fomentar el mantenimiento de más archivos abiertos a la vez. Lo que describe aquí también puede suceder con los archivos de trabajo, al menos con las combinaciones de teclas predeterminadas (y es por eso que jugué cambiando las combinaciones de teclas para cerrar el editor activo y cerrar el archivo de trabajo por completo).

Cuando se trata de eso, si VS logró replicar opcionalmente el _comportamiento_ de las pestañas (con lo que parece que al menos una de las cosas en el # 1133 se relaciona) mientras lo mantiene a un lado, podría ser un buen comienzo . Ctrl + orden de tabulación es MRU frente al orden de aparición es otra cosa (Sublime permite ambos a través de diferentes comandos enlazables).

@stevencl , gracias por tu respuesta. Me gustaría comentar algunos de sus puntos:

[...] somos conscientes de los problemas con la experiencia actual para administrar archivos y tenemos una serie de cambios que queremos hacer para mejorar la experiencia.

Ciertamente estoy esperando lo que parece ser un futuro muy brillante para VS Code. Me emocioné cuando escuché que Microsoft estaba trayendo un IDE tan poderoso como Visual Studio a mundos más allá de Windows y por adoptar nuevos paradigmas de desarrollo de aplicaciones con Electron. ¡Felicitaciones por su trabajo hasta la fecha!

Uno de nuestros objetivos con VS Code es que, a medida que realizamos cambios en la interfaz de usuario y la UX, nos aseguramos de que VS Code siga siendo un editor ligero y potente que permite a los usuarios centrarse en su código.

No creo que nadie pueda aportar un argumento convincente para que las pestañas hagan que las interfaces sean débiles, lentas o distraigan. De hecho, hay mucho más espacio horizontal para pestañas que espacio vertical sobre la vista de árbol del proyecto. Tener los archivos de trabajo allí, para mí, hace que la parte izquierda de la ventana se vea mucho más desordenada de lo que debería estar.

Nuestra preocupación con agregar pestañas es que introduce otro conjunto de problemas que terminan requiriendo que el usuario se concentre en la interfaz de usuario en lugar del código.

¿Habría alguna razón para usar algo más que TextEdit o el Bloc de notas si se tratara de centrarse en el código? Al estipular que la funcionalidad, para todos los efectos, es la misma en la mayoría de los editores, la interfaz de usuario / X utilizada para alcanzar esa funcionalidad y la calidad de la misma es realmente donde un producto se distingue.

Nuestra experiencia con Visual Studio, por ejemplo, nos ha demostrado que muchos usuarios a menudo terminan con muchas pestañas abiertas que contienen archivos que ya no necesitan y que terminan abarrotando su espacio de trabajo. Esto causa algunos problemas cuando los usuarios buscan archivos y otros activos de código.

Aquí hay un argumento que no creo que importe a favor o en contra de las pestañas o una lista de archivos de trabajo; cuando trabaje con más de un archivo, siempre tendrá que romper su enfoque para buscar activos de código.

Aun así, la lista de archivos de trabajo todavía no resuelve el problema. Demasiados archivos de trabajo hacen que la lista se desplace y no se pueda expandir. Entonces, en lugar de desplazarse eventualmente por las pestañas, más rápidamente se desplazará hacia abajo en la lista de archivos de trabajo.

[...] realmente estamos tratando de mantener la estética mínima que creemos que brinda una experiencia liviana y poderosa. Simplemente estamos siendo muy cuidadosos con la introducción de nuevas UI y UX en el producto.

Puedo apreciar y apoyar esta postura hasta cierto punto. Cuando la comunidad alza su voz, debe comenzar a hablar sobre la adopción de los usuarios. ¿No es por eso que colocó la falta de plegado de VS Code como una preocupación de adopción del usuario en su hoja de ruta para marzo? Algunas cosas son como son y por una buena razón. Me viene a la mente el menú Inicio en Windows y el dock en OSX.

[...] Me disculpo de nuevo por hacer que parezca que estamos mirando el ombligo y no estamos haciendo nada al respecto.

Definitivamente esa no es mi opinión al respecto, así que no se preocupe. Por las razones que ya mencioné, una conversación saludable sobre esto ciertamente solo puede mejorar el propósito mayor que es la UI / X de VS Code.

También quiero intervenir y decir simplemente que creo que no siento que "mirarse el ombligo" esté sucediendo en absoluto. El momento de este problema es parcialmente culpable: el 19 de noviembre no da tiempo para ubicarlo en diciembre y posiblemente en enero, dependiendo de qué tan lejos se planeen las cosas. Además, esta conversación que ha comenzado de nuevo es más importante que simplemente implementar pestañas al azar porque los usuarios lo desean.

Tengo que estar de acuerdo con ianwesterfield en que la interfaz de archivos de trabajo no es ideal y que hay más espacio horizontal que vertical. Las listas de archivos masivas y muchos archivos intercambiados son las debilidades actuales de vscode en términos de administración de archivos de trabajo.
Cuando comienzas a saltar alrededor de 16 archivos diferentes, ser capaz de administrar a qué editor dividido pertenecen es algo en lo que sería difícil superar las pestañas de los archivos de trabajo. Dicho esto, dividir la lista de archivos de trabajo en dos secciones diferentes sería una solución razonable.

Sin embargo, stevencl hizo un argumento que me hace muy feliz. "Es muy posible que después de algunas rondas de diseño e investigación sobre esto, terminemos introduciendo pestañas. Pero solo lo haríamos sabiendo que esta es la mejor manera de mejorar la forma en que los usuarios administran los archivos y activos con los que trabajan. con, pero no termina saturando la interfaz de usuario ". Intentando cosas nuevas, se pueden producir mejoras.

Una forma más sencilla de administrar las ventanas divididas ya sería una mejora. Puedo argumentar a favor de los archivos de trabajo en el sentido de que la gestión de las ventanas SIEMPRE puede estar en la misma ubicación. Administrar pestañas es más esfuerzo cuando desea reorganizar 2-4 divisiones (pantalla de alta resolución + átomo = división horizontal y vertical cuando sea necesario). Por lo tanto, existe una posible solución que mantiene la interfaz de archivos de trabajo, pero que la extiende para que sea un poco más compleja.

Gracias, agradezco la oportunidad de tener esta conversación.

@ianwesterfield , tiene razón sobre los archivos de trabajo y ha resaltado uno de los problemas que queremos abordar. También hay otros problemas, muchos de los cuales @kfranqueiro ha destacado. La experiencia actual definitivamente no es la experiencia deseada.

Después de haber trabajado en el diseño de Visual Studio durante varios años, he visto los problemas de UX que pueden causar las pestañas. Pasé 18 meses trabajando en la experiencia de la pestaña de vista previa en Visual Studio, que es un intento de reducir el problema del 'infierno de pestañas' que @bpasero describe anteriormente.

Sin embargo, queremos tratar de evitar entrar en una posición en la que esto sea necesario. Así que queremos continuar con nuestro análisis profundo de diseño para descubrir las opciones que están disponibles para nosotros y luego conformarnos con una. Como dije antes, bien podría ser que terminemos con pestañas. Si lo hacemos, sabremos que es el mejor enfoque que podríamos crear y que brindará una gran experiencia para administrar archivos y otros activos de código.

Gracias por todos los conocimientos y descripciones de los problemas que tiene actualmente con la forma en que administramos los archivos en VS Code.

@stevencl , es gracioso que menciones la pestaña de vista previa, me encanta. Es genial cómo VS Code, Sublime, Atom, Brackets (a través de la extensión), etc.tienen una función de vista previa como esta por defecto.

Estoy muy contento de que Microsoft nos haya dado la oportunidad de participar en discusiones de diseño en curso al mantener abierto este proyecto. Si los usuarios solo tuvieran esa voz durante el rediseño del menú Inicio, es posible que Windows no haya necesitado otro ciclo de lanzamiento para finalmente obtener la incorporación masiva de Windows 7.

Es muy posible que después de algunas rondas de diseño e investigación sobre esto, terminemos introduciendo pestañas. Pero solo lo haríamos sabiendo que esta es la mejor manera de mejorar la forma en que los usuarios administran los archivos y activos con los que trabajan, pero sin terminar saturando la interfaz de usuario.

Desde que abrí este número, que parece haber resurgido, me gustaría agregar que creo que este comentario es bastante satisfactorio. Sospecho que aparecerán pestañas, pero apoyo completamente la exploración de nuevas ideas, y el código es una gran plataforma para hacer esto. Me encanta el trabajo que han hecho hasta ahora.
Dicho esto, solo tenga en cuenta que queremos _usar_ esto, y cuanto antes pueda usarlo como mi editor principal, mejor, por lo que, por mi parte, agradecería si pudiera brindarnos una experiencia familiar (aún ligera) que podemos usarlo de manera productiva y sentirnos como en casa ahora mismo, y podemos continuar con nuestro trabajo. Entonces puedes tomarte todo el tiempo del mundo para explorar nuevos horizontes :)
Es solo que estamos esperando ansiosamente que el código alcance la línea mágica donde podamos adoptarlo a tiempo completo. Para mí, las pestañas son mi única queja de usabilidad, la compilación nativa y la depuración es la única técnica.

No creo que sea el único usuario de Windows cansado y sufriente que es irremediablemente adicto al Visual Studio. La salvación es solo un par de pequeños problemas y características que están más allá de nuestro alcance, está progresando rápidamente y estoy agradecido por la oportunidad de participar y mirar con tanta visibilidad.

Lamentablemente, Windows sigue siendo la peor plataforma / ecosistema de desarrollo, con el mejor entorno de desarrollo, y ha sido así durante unos 15 años. Muy raro.
No sé por qué, pero parece que para mí, el entorno de desarrollo (productividad) triunfa sobre el ecosistema en mi equilibrio, pero es un equilibrio doloroso y estaré tan feliz como un cerdo en el barro cuando pueda usar VS en Linux completo -¡hora! ¡Estamos tan cerca!
Sé que ven esto como un vehículo para explorar un nuevo territorio, y eso es totalmente genial, pero a corto plazo, realmente solo queremos VS en Linux (u osx, si se balancea de esa manera), como hemos soñado para un más o menos una década, y finalmente, después de todos estos años, ¡podemos terminar con nuestro sufrimiento! ;)
</dramatic_commentary>

TL; DR, explorar es totalmente genial y estoy seguro de que está comprometido con el mejor producto final que puede hacer, pero ¿quizás soluciones familiares seguras mientras tanto?

+1 para pestañas. La pregunta: ¿por qué no lo elimina de Visual Studio Bundle entonces? Mira lo que pasa entonces ...

+1 para pestañas! Implemente esto en una actualización futura.

La suposición actual parece ser que "[tabs] en la mayoría de los casos crece tanto que termina sin ver nada". Me gustaría desafiar esta suposición. Utilizo pestañas como índice visible de los archivos que me interesan actualmente y administro activamente ese índice a medida que mi interés cambia con el tiempo. La visibilidad es importante: me refiero a las pestañas físicas constantemente para reorientarme. Con Working Files, estoy despojado de mi capacidad para ver y manipular ese índice. Por ejemplo, no parece haber una forma de eliminar un archivo de Working Files mediante el teclado. Se siente como si estuviera luchando contra el editor. Agregue pestañas de estilo Sublime Text.

Si bien estoy de acuerdo con que VS Code funciona bien sin pestañas ahora (lo he estado usando desde el principio de manera bastante productiva), también estoy de acuerdo con algunos comentarios anteriores que sugieren tener pestañas como una opción (tal vez deshabilitada de forma predeterminada) y permitir que los usuarios decidan si las quieren o no.

Todos somos diferentes, por lo que tener una opción allí sería genial. Aunque puedo trabajar bien sin ellos, no me importaría agregarlos y probablemente los usaría algunos, demasiados años de uso de VS completo. Sin embargo, parece que ya están en la lista de trabajos pendientes, ¡gracias!

+1 para pestañas. Casi 1 año trabajo con VSCode y me gusta mucho. Pero aún faltan pestañas, especialmente cuando se trabaja con depuración o búsqueda, o git en la sección izquierda. Las pestañas ayudan a no pensar en qué archivo contiene código, ya que ha estado trabajando antes. Creo que los usuarios administran las pestañas y su orden para tener en cuenta también una posición de pestaña, que se puede asociar con el código fuente en el que están trabajando. Las pestañas del editor divididas también pueden mantener esta intención.

Ctrl + tabulador es una acción clave, y tabulador es una acción visual, que es mucho más rápida.

Probablemente podría vivir sin pestañas ... si VS no fuera tan malo en la gestión de "archivos de trabajo". Muy a menudo abro archivos solo para referirme a su interior, sin editarlos, pero VS no coloca esos archivos en mi lista de archivos de trabajo, mientras que definitivamente tendría una pestaña abierta en un entorno con pestañas.

Esto combinado con el hecho de que cuando cierra un archivo / enfoca uno nuevo "en funcionamiento", el explorador de archivos se MUEVE al archivo abierto en lugar de permanecer en su última ubicación, lo que crea una experiencia muy confusa.

Entiendo que eso no le preocupa, ya que "lo ha usado sin pestañas durante 4 años", por lo que cualquier cosa que salga del alcance de Ctrl + Tab se considera una forma extraña de usar el programa.

Esta debe ser una función y si está activada o desactivada de forma predeterminada es irrelevante. Prácticamente todos los editores de texto / IDE utilizan pestañas para la navegación. Quizás algunos sientan que hay una mejor manera, pero para la mayoría de nosotros las pestañas son eficientes, fáciles de usar y familiares ... ¡y obviamente las amamos! Sáquelos de Visual Studio para una versión y compruebe lo importantes que son ... (cuente la fusión épica de desarrolladores al estilo Metro) Considere las pestañas para una versión a corto plazo. es lo único que nos impide a muchos de nosotros adoptar VSCode a tiempo completo.

: +1:

¡Soy mucho más productivo con las pestañas! Uso Atom como uso Google Chrome (Ctrl + 1 para la primera pestaña, Ctrl + 5, etc. Ctrl + Tab, Ctrl + Shift + tab).

Trabajar con archivos me hace menos productivo y siempre me siento un poco frustrado después de usarlo.

Así que, por favor, implemente pestañas.

Las pestañas serán muy útiles, +1

: +1:

@MadSpindel "Trabajar con archivos me hace menos productivo y siempre me siento un poco frustrado después de usarlos". 1000% de acuerdo ... es como si nos estuviéramos obligando a no tener que controlar nada para que alguien haga un punto o algo. No nos gusta, si lo hace, entonces hágalo opcional para nosotros, por favor.

Visual Studio Power Tools tiene una opción para mostrar pestañas verticalmente, lo que me encanta.

: +1: y estoy de acuerdo con @sitefinitysteve. Si el equipo insiste en no tener pestañas, al menos mejore la API de extensión para que pueda ser agregada por un tercero.

Aquí es donde las pestañas son importantes: tenemos que retroceder un momento a otra característica que falta:

VSCode necesita volcar la implementación no informativa de Working Files y luego agregar la función para permitir la apertura de múltiples proyectos. Hago mi trabajo separando el código del lado del cliente en un proyecto y el código del lado del servidor en otro proyecto. En una pantalla grande, quiero dos ventanas de codificación abiertas, con un árbol de proyecto en el extremo izquierdo. Código de cliente en la ventana de la izquierda, código de servidor en la ventana de la derecha. Ahora, dentro de cualquiera de los proyectos, trabajaré en varios archivos fuente. En esos casos, quiero hacer referencia a ellos como pestañas sobre la ventana del proyecto respectivo en el que se abrieron. Puedo tener 3 o 4 pestañas en el proyecto del lado del cliente y 3 o más pestañas en el proyecto del lado del servidor.

La organización es orgánica. El árbol de trabajo completo, múltiples proyectos, se muestra a la izquierda. Tengo una separación de proyectos por ventanas de código y también tengo archivos de código abierto en los que se trabaja, o se hace referencia, mediante pestañas sobre sus respectivas ventanas de proyecto.

Este es un flujo de trabajo esencial para mí. Actualmente estoy haciendo exactamente esto en Atom pero me gusta VSCode y me gustaría ver ese flujo replicado en VSCode. Para hacerlo, VSCode necesita implementar múltiples pestañas y soporte para proyectos sobre las respectivas ventanas. De lo contrario, es solo otro editor de un tipo pequeño, y no lo creo. Por favor.

@riclf lo ha

Normalmente tengo 3 columnas verticales abiertas, HTML, JS y CSS de izquierda a derecha.

En Sublime tenía todas mis pestañas html encima de la primera columna, todos los archivos JS como pestañas encima de la segunda columna, etc. Las pestañas tienen un contexto y sé que no voy a abrir el archivo incorrecto en la columna incorrecta.

Esto es casi imposible en VS Code, puedo tener 3 columnas abiertas solo usando "abrir al lado" dos veces, y una columna puede desaparecer por completo si se cierra un archivo, momento en el que puedo abrir uno nuevo pero tengo que reordenar ellos. Si abro un archivo, se vuelve a abrir en la columna en la que se encuentra el cursor, por lo que si abro un archivo css, tengo que asegurarme de que mi cursor esté en la tercera columna. Es absolutamente exasperante.

Sin mencionar que la sección de Archivos de trabajo ocupa un espacio muy vertical en mi árbol de carpetas, lo cual es un problema real en mi computadora portátil.

Una pregunta para el equipo de microsoft. Si tiene una vista dividida, ¿cómo se supone que debe saber con qué columna está asociado un archivo en "archivos de trabajo"? Es simple cuando las pestañas están encima de sus respectivas columnas.

Solo mi 2c.

No tuve ninguna molestia cognitiva al acostumbrarme a Working Files. Los amo mucho más que las pestañas. La interfaz de usuario de VSCode está en el camino correcto. No estoy en contra de las pestañas de suscripción voluntaria, pero me encantarían las pestañas de exclusión voluntaria.

Los archivos de trabajo son pestañas con un mejor diseño (más espacio de desplazamiento). Les faltan funciones de "arrancar" y arrastrar, que se pueden agregar en el futuro.

Como usuario de mvim, tengo varios conjuntos de archivos TDD abiertos y tabuladores entre ellos. Por ejemplo, pruebas + angulares, pruebas + servidor, pepino o comporto + scripts. No quiero tabular para acceder a un solo archivo, sino a una combinación de archivos abiertos. Cambié a VSCode durante 3 meses para un proyecto de TypeScript, porque realmente tenía el mejor soporte de Typecript de su clase. Sin embargo, tan pronto como me mudé a un proyecto que no es Typecript, descubrí que comparé sus capacidades de búsqueda, navegación y sustitución de propósito general directamente con mvim y lamento decir que rápidamente (es decir, instantáneamente) volví a mi antiguo editor. Tengo una pantalla Apple Cinema de 27 "y, si es posible, obtendría una pantalla más grande. Tengo mucho espacio para muchas pestañas y pares de archivos, y no tengo una razón de peso para que mi editor me limite a usar ese espacio No quiero tratar con un solo archivo a la vez, quiero abrir muchos y rastrear el flujo de una pestaña a otra.

Probé de nuevo Visual Studio Code hace dos semanas. De hecho, me sorprendió gratamente cuando estaba jugando con algunos archivos. Pero cuando comencé a trabajar en un proyecto real (grande) con más de un puñado de archivos abiertos, la falta de pestañas se volvió muy molesta. _Working Files_ simplemente no me convenía y me hizo más lento. Después de 3 días estaba tan molesto con eso que volví a Sublime Text. Tengo dos pantallas de 24 "en el trabajo (Windows), una Mac de 27" en casa y puedo tener fácilmente 20 pestañas abiertas y aún distinguir qué archivo es cuál. Mucho espacio de pantalla para pestañas en mi caso. _You_ ya está mostrando el nombre de archivo del archivo que se abre en el editor. Todo el espacio a la derecha del nombre del archivo no se usa (excepto los íconos a la derecha de la ventana) y podría llenarse con pestañas (que es lo que también hace Sublime Text). Digo que dé a los usuarios la opción de trabajar con _Working Files_ y / o pestañas de archivos. Por ahora, voy a volver a una combinación de Sublime Text y Visual Studio Enterprise. Cuando se agreguen pestañas, lo reconsideraré.

Para la opción Working Files , tengo que alternar la barra lateral (ya que la mantengo oculta para la vista ampliada del código) para seleccionar el archivo. Y las opciones Ctrl+P y Ctrl+tab tampoco son fáciles de usar.

Sé que están intentando algo diferente para eso, pero las opciones que ya proporcionó no son fáciles de usar. Lo siento.

proporcione una extensión para esto, para que los usuarios tengan la oportunidad de usar pestañas en lugar de verse obligados a usar la lista de trabajo. Odio mucho la función de archivos de trabajo, hace que cambie de archivo lentamente y me robó la productividad

Cuando era nuevo en VS Code, realmente extrañaba las pestañas. Luego descubrí ctrl + tab y ya no los necesito.

He intentado hacer de vscode (que es increíble en la mayoría de las partes) mi editor principal durante varios meses, pero la falta de pestañas me sigue molestando y dañando mi productividad (soy uno de los que administran activamente el conjunto de pestañas abiertas en otros editores). Ctrl + tabulador no sustituye a las tabulaciones.

Es obvio que el equipo de vscode está predispuesto en contra de esto, y actualmente apunta a "convencer" a los usuarios de que realmente no necesitan pestañas. Pero este es el mismo tipo de pensamiento que llevó a la eliminación del menú Inicio de Windows 8 (todos sabemos cómo terminó esto).

@pesho ¡Exactamente!

Ahora que el plegado de código está fuera, este es el problema principal en User Voice. Estamos sopesando una serie de opciones internamente mientras seguimos sopesando los comentarios de la comunidad, las pruebas de la experiencia del usuario, etc. Gracias a todos por la discusión aquí. Muy útil.

probablemente sea la única razón por la que abrí vscode por primera vez hace casi un año y lo cerré justo después de unos minutos de juego. y todavía no tienes pestañas. Espero que aparezca pronto, para poder usarlo. Es de código abierto, y la gente de Microsoft necesita cambiar de opinión (eso es lo que están tratando de hacer ahora, ¿no?) Y escuchar a la comunidad, no simplemente "estamos usando esta herramienta internamente y no necesitamos pestañas bla bla"

@pleerock ¡ ¿Ni siquiera vas a probar un IDE porque no tiene pestañas ?! (Oo) weeeweweweweeeww. No quieren agregar pestañas porque las pestañas son inútiles, detalladas, generalmente no agregan valor mientras agregan peso superior en el espacio cromado de Windows. Las alternativas proporcionan más metadatos, facilidad de uso y una navegación más rápida.

Con las pestañas, elijo qué archivos permanecen abiertos. Ya sea CTRL + tabulador o "Archivos de trabajo", si abro un archivo para buscar algún código en él, cambio a otro para usar dicho código, no tengo forma de volver a mi primer archivo salvo tener que volver a navegue hasta el archivo en el explorador.

Sé que tengo 3 editores, pero a veces no quiero anular los otros 2 con mi archivo de solo código de búsqueda.

Si cuando abro un archivo permanece en los diferentes historiales de archivo, entonces estoy bien sin pestaña. Quizás si un archivo ha estado abierto más de 5 segundos, merece una entrada en CTRL + Tab.

@ 4tron sí, lo es para mí, porque quiero usar IDE, que es conveniente para mí. para alguien perder pestañas es inútil y proteger su espacio (probablemente están usando netbooks y no tienen suficiente espacio para realmente pocos píxeles adicionales =)), para otros es conveniente y aumenta su productividad. Cualquier buen software debe ser personalizable y tener la capacidad de ocultar / mostrar paneles. "guardar un espacio" no se discute. Introduzca pestañas + agregue la capacidad de mostrarlas / ocultarlas (si es realmente necesario para alguien =)) es la mejor manera de hacerlo. No es necesario abrir una nueva América o ir con innovaciones equivocadas, es necesario aprender de los mejores IDE aquí que hicieron que UX durante años fuera cada vez mejor, como intellij, visual studio y otros.

Es realmente simple, simplemente conviértalo en Preferencias, con pestañas o sin pestañas. Cuando las pestañas están activadas, no hay archivos de trabajo, cuando las pestañas están desactivadas, archivos de trabajo. ¡Eso fue genial! ;)

Yo soy un tipo de pestañas. Los archivos de trabajo son muy limitados y poco intuitivos, además de ocupar espacio vertical en el árbol del proyecto. Pero poco importa si no podemos tener más de un proyecto abierto. :(

Creo que una preferencia también debería estar bien.

También me importaba una forma de mejorar el sistema de archivos de trabajo. Debe usar la línea de tabulación como histórica.
Por ejemplo, si abre 4 archivos en la ventana de la izquierda, y luego abre un quinto haciendo que el archivo modificado más antiguo salga de la línea de pestañas, debería desaparecer y regresar como solo "archivo modificado" en los archivos de trabajo.

También podría hacerlo inteligente, el sistema también podría priorizar la desaparición de los archivos primero guardados y sin modificar.

El hecho es que las pestañas son tan prácticas, incluso si la hinchazón de las pestañas es un problema. Debería pensar en una forma de utilizar las pestañas, pero limitando el número de ellas.

Por lo general, mantengo abiertas las pestañas que no he editado durante días. esto es generalmente quien lo hace hinchar.

+1

Tengo una pantalla 4K y no tener pestañas para horizontalmente realmente me está desconectando de VsCode

Por cierto, quiero aclarar que no solo quiero pestañas, me gustaría conjuntos de pestañas. Como desarrollador full stack mvim TDD en Mac, pienso en términos de contextos. html + css, pruebas + angulares, pruebas + nodo, pepino + pasos de prueba. Normalmente trabajo en un solo contexto para unas pocas líneas de código antes de pasar al siguiente contexto, estilo TDD. Cuando uso mvim, no solo cambio entre estos contextos muy rápidamente (usando la misma secuencia de teclas que uso para Mac Terminal, Mac Finder y Safari o Chrome), sino que me beneficio de las macros que abren automáticamente el archivo emparejado, de modo que desde un archivo de origen angular, puedo abrir automáticamente la prueba correspondiente. Esta es una forma increíblemente productiva de trabajar y mantiene mis dedos en el teclado.

Si encontrara un IDE que me permitiera abrir archivos "asociados" en marcos uno al lado del otro, simplemente cambiando una pestaña, por ejemplo, cuando abro button.html , se abriría button.js al lado y button.scss en el tercer fotograma, nunca volvería a usar otro IDE.

Sé que nunca sucederá, pero solo digo.

Bueno, entonces, ¡deberías usar mvim! http://www.vim.org/scripts/script.php?script_id=1567 Comando: AV abre archivos asociados (A para asociados).

De lo que habla

+1

Lo mismo aquí, me encantaría tener pestañas.

Acabo de cambiar a VSCode de Atom y noté lo increíblemente organizado y limpio que se siente después de trabajar con él por un tiempo. ¿La razón? ¡Sin sobrepoblación de pestañas! La falta real de pestañas es lo que hace que esta experiencia sea tan fluida. Mi navegación de archivos principal es el menú de comando-P que me permite saltar rápidamente a cualquier archivo.

Las pestañas VS son perfectas, por favor traiga pestañas, ¡desacoplar las pestañas en una ventana separada también sería genial!
Gracias por vscode :)

De hecho, tengo mucha curiosidad sobre si desea hacer que VSC sea un editor de archivos de propósito general o simplemente un editor de código fuente.

Hay un par de situaciones en las que se exige absolutamente una barra de pestañas.

1. Cambie rápidamente entre muchas pestañas.
   Una situación común para mí es que necesito comparar 2 o más archivos por su forma, por ejemplo, para comparar el chino simplificado y su equivalente tradicional. Un diff no resolverá el problema porque son personajes diferentes. La única forma es cambiar rápidamente entre las pestañas para ver si falta alguna palabra en sus ojos. Usando ST y puedo cambiar de pestaña usando Alt-NUM, pero en VSC la única forma posible es usar múltiples Ctrl-Tab, o el mouse moviéndose rápidamente y haciendo clic.
2. Nombres de archivo largos y difíciles de escribir.
   Usar Ctrl-P para cambiar entre archivos no está mal. Pero, ¿qué tal algunos nombres de archivo que comparten una solución común desde hace mucho tiempo? ¿Qué tal algunos nombres que no están en inglés? Considere cuánto tiempo dedicaría a Ctrl-P para cambiar entre 青年急着买房的原因（上）.md y 青年急着买房的原因（下）.md ?

Yo diría que ninguna de las situaciones le afectará al escribir código, pero como editor de propósito general, este es un problema grave.

@ msg7086 No estoy seguro sobre el punto uno, pero para el punto dos, ¿no podrías ctrl + p y luego escribir .md dejándote con las dos opciones y luego solo ctrl + tab para elegir la que ¿desear? No estoy seguro de haber entendido el problema correctamente

@ 4tron Gracias por la respuesta. Sin embargo, su método solo funciona si solo tengo 2 archivos con ese tipo. En realidad, la gente probablemente estará trabajando con muchos de esos archivos en un solo directorio. Imaging Estoy escribiendo un blog que tiene 50 publicaciones en formato de rebajas, con diferentes caracteres en chino, coreano o árabe, etc. como nombres de archivo. El escenario real al que me estaba enfrentando eran en realidad algunos archivos de subtítulos con nombres CJK, donde todos son *.ass , por lo que Ctrl + P por extensión no funciona del todo bien.

Realmente aprecio si esto se puede implementar

Los desarrolladores están acostumbrados, conviértalo en una prioridad .

+1 para pestañas. Implemente pestañas.

+1 para pestañas!

Yo también voto por agregar pestañas.

+1

+1

+1

Necesitamos pestañas lo antes posible.

Echo de menos pestañas. Sigo buscándolos, sería bueno consultar rápidamente dos o tres documentos abiertos diferentes.

¿Cual es el problema?

• El área de archivos de trabajo está bloqueada en altura, el mismo problema que demasiadas pestañas, excepto que es complicado de administrar (no hay mouse ni rueda de desplazamiento aquí). Las pestañas se pueden eliminar fácilmente, dando al usuario el siguiente documento en la pila de archivos abiertos.
• La columna Explorer en Code es mucho más ancha que Sublimes, a veces uno quiere minimizarla cuando se ejecutan dos aplicaciones una al lado de la otra para ahorrar espacio (Unity a la izquierda, Code a la derecha, por ejemplo). Las pestañas no necesitan ahorrar espacio para funcionar, Code ya tiene un área vacía agradable donde pueden ir.
• Las pestañas ganan por la facilidad de uso y el ahorro de espacio, sin necesidad de investigación de UX. Son rápidos de usar y nos gustan a todos.

Danos la gestión de documentos con pestañas :)

+1, yo.

+1

+1

VSCode es un gran editor y tiene buenos puntos de integración con Git y Nodejs. La razón principal por la que no lo uso como mi IDE de desarrollo principal es porque no admite pestañas.

Igual que aquí. Es lo ÚNICO que me retiene para usarlo.
Op do 10 mrt. 2016 a las 15:18 schreef Konrad Piascik < [email protected]

VSCode es un gran editor y tiene buenos puntos de integración con Git y
Nodejs. La razón principal por la que no lo uso como mi IDE de desarrollo principal
es porque no admite pestañas.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -194867036.

Es un poco sorprendente ver tanto retroceso en este tema dado que debería ser tan fácil de implementar. Por lo menos, conviértalo en una opción o disponible a través de una extensión (como lo hace Brackets).

Si esto se agrega, POR FAVOR agregue lo siguiente:

1. Cerrar funcionalidad como Google Chrome. (Siempre me ha molestado que la versión estándar de VS no tuviera esto).
   - " Cerrar otras pestañas "
   - " Cerrar pestañas a la derecha ".
2. Una opción para abrir la pestaña hacia la derecha o hacia la izquierda. (VS cambió el valor predeterminado en algún momento, pero luego agregó una opción para cambiar)

Las pestañas funcionan. Están en todas partes, la gente está acostumbrada. La lista actual de archivos no es intuitiva. Después de 2 meses usando VS Code a diario, sigo buscando una pestaña casi cada vez que necesito cambiar de archivo. El hecho de que todos los demás editores sigan usando pestañas crea una barrera enorme para que algo diferente se vuelva intuitivo.

En mi equipo, la gente se queja todo el tiempo de eso, hasta el punto de que algunas personas prefieren usar sublime sin ningún soporte de mecanografiado y luego usar VS Code.

No estoy en contra de la investigación de UX para encontrar una "mejor" manera de manejar archivos abiertos, pero por favor no vuelva a convertir esto en el fiasco de Office, que tomó media década y múltiples lanzamientos para inventar otra forma de hacer exactamente el la misma cosa.

-1

Algunas notas sobre por qué estoy en contra de las pestañas:

• Cualquier tiempo dedicado a las pestañas será el tiempo necesario para realizar otras mejoras en el editor.
• Me he estado forzando a convertirme más en un comando de teclado y no tener pestañas ha sido útil. Así que estoy discutiendo desde la perspectiva de que es por tu propio bien, aunque yo ni siquiera estoy allí todavía.
• Relacionado con lo anterior, esto me recuerda cuando salió Gmail y tuve que convencer a la gente de que las etiquetas eran superiores a las carpetas. Algunas personas simplemente no pudieron procesarlo y todavía están sacudiendo sus cuentas de correo electrónico de AOL / ISP. Creo que la EM debería tomar una posición aquí al decir "simplemente creemos que esta es una mejor manera de hacer las cosas".
• Si quisiera sugerir algo, sería una explicación inicial de por qué las pestañas no están ahí junto con ejemplos de cómo navegar por el editor sin ellas.

Bueno, hay un compromiso: hacer que las pestañas sean visibles o no en Preferencias / Opciones.

No creo que le quite tiempo a otras mejoras porque estoy seguro de que tienen más de un programador en este desarrollador. También me encanta ser un comando de teclado. Si se implementaron, simplemente no los use, pero ¿por qué impedir que aquellos que prefieren pestañas en su flujo de trabajo los tengan?

De todos modos, no hay problema. Me he mudado de nuevo a Atom mientras espero que VSC decida lo que va a hacer. Encuentro las pestañas esenciales para el flujo de trabajo en un proyecto grande, además de poder abrir más de una carpeta de proyecto.

Me he estado forzando a convertirme más en un comando de teclado y no tener pestañas ha sido útil. Así que estoy discutiendo desde la perspectiva de que es por tu propio bien, aunque yo ni siquiera estoy allí todavía.

Como sugerí anteriormente en este hilo , lo que falta es el _comportamiento_ lo que es tan importante, si no más, que el componente visual. Estoy a favor de usar atajos de teclado como ctrl + [shift +] tab o incluso ctrl + P para navegar a los archivos (incluidos los abiertos), pero el comportamiento de Working Files y cómo administra las ventanas del editor (y el hecho de que ctrl + tabs en orden MRU) me parece terriblemente discordante.

¡Sostenga el teléfono! ¡Tengo la respuesta! ¡Es perfecto! Listo? No _necesitamos_ pestañas. ¡Extendamos los archivos de trabajo con una opción simple para mostrarlos en pestañas horizontalmente en la parte superior del editor! ¡Woo hoo! ¡Problema resuelto sin crear pestañas!

De hecho, prefiero la forma en que está ahora: paneles para archivos abiertos y un selector de archivos en forma de lista con "archivos de trabajo" en el lateral. Cuando usaba Atom, odiaba que cada vez que miraba rápidamente un archivo, se abría una nueva pestaña, y en unos minutos mi barra de pestañas estaba llena de pestañas inútiles.

Así que estoy -1 en esto. Pero aún me gustaría ver cómo se desacoplan las ventanas.

Acabo de cambiar a VSCode de Atom y noté lo increíblemente organizado y limpio que se siente después de trabajar con él por un tiempo. ¿La razón? ¡Sin sobrepoblación de pestañas! La falta real de pestañas es lo que hace que esta experiencia sea tan fluida

esta. 100% de acuerdo.

De hecho, prefiero la forma en que está ahora: paneles para archivos abiertos y un selector de archivos en forma de lista con "archivos de trabajo" en el lateral. Cuando usaba Atom, odiaba que cada vez que miraba rápidamente un archivo, se abría una nueva pestaña, y en unos minutos mi barra de pestañas estaba llena de pestañas inútiles.

Entiendo eso y es por eso que estamos solicitando una característica _additional_ no un reemplazo para los archivos de trabajo. No puedo por mi vida entender por qué no se pueden incluir ambos en el editor. Es enserio. ¡Mira cuántas pestañas quieren en este hilo! Este no es un escenario _Oye, me gustaría que los botones fueran azules_. Se trata de un obstáculo para la productividad de la gran mayoría de las personas que quieren pestañas en este editor de texto (que por cierto está en camino de ser superior a Atom y Sublime). Obtengo los argumentos válidos en ambos lados. Simplemente no puedo entender por qué las pestañas y los archivos de trabajo no se pueden incluir con opciones para desactivar ninguno. Entonces todos ganan.

@ jayrosen1576 Quizás el problema es que nadie realmente hizo una propuesta en profundidad sobre cómo debería verse

• ¿Debería la barra de pestañas estar encima de todas las ventanas?
• ¿Cómo funcionaría hacer clic en una pestaña cuando tiene varios archivos abiertos uno al lado del otro, o en una versión futura, incluso divididos horizontalmente?
• ¿La pestaña del archivo activo estaría siempre resaltada? ¿Qué pasa si la consola de depuración está enfocada?
• Si habilita la configuración de la pestaña, ¿se eliminará la sección de archivos de trabajo porque es redundante?
• ¿Qué pasa con los nombres de archivos duplicados en diferentes carpetas?
• ¿Qué pasa con el botón de cierre duplicado de una pestaña y un panel?
• ¿Cerrar el panel cerrará la pestaña?
• ¿Aparecerá una pestaña tan pronto como abra un archivo como en Atom (urgh) o solo cuando edite como con archivos de trabajo?

Todas estas son preguntas en las que el equipo de desarrollo tendría que dedicar tiempo. Y por mucho que lo intente, no puedo pensar en una implementación que sea más elegante que la lista de archivos de trabajo y que no sea confusa.

Aquí está la propuesta de cómo debería verse:

1) Descarga Atom
2) Átomo abierto
3) Mira las pestañas
4) Implementar en VSCode

@ jayrosen1576 en serio? Mencioné algunas preocupaciones válidas con la implementación de Atom y también problemas que Atom simplemente no tiene porque no tiene un concepto de archivos de trabajo.

Por otra parte, tu foto de perfil lo dice todo.

• ¿Debería la barra de pestañas estar encima de todas las ventanas?
  A: si. Prueba las pestañas en Atom
• ¿Cómo funcionaría hacer clic en una pestaña cuando tiene varios archivos abiertos uno al lado del otro, o en una versión futura, incluso divididos horizontalmente?
  R: Las pestañas aparecen en la parte superior de cada panel. Prueba las pestañas en Atom.
• ¿La pestaña del archivo activo estaría siempre resaltada?
  A: si. Prueba las pestañas en Atom.
• ¿Qué pasa si la consola de depuración está enfocada?
  R: El mismo resultado que cuando la consola de depuración está enfocada ahora con dos archivos abiertos uno al lado del otro.
• Si habilita la configuración de la pestaña, ¿se eliminará la sección de archivos de trabajo porque es redundante?
  R: Solo si deshabilita los archivos de trabajo (como una opción)
• ¿Qué pasa con los nombres de archivos duplicados en diferentes carpetas?
  R: La pestaña incluye una ruta parcial. Prueba las pestañas en Atom.
• ¿Qué pasa con el botón de cierre duplicado de una pestaña y un panel?
  R: El panel no tiene botón de cierre. Prueba las pestañas en Atom.
• ¿Cerrar el panel cerrará la pestaña?
  A: si. Prueba las pestañas en Atom.
• ¿Aparecerá una pestaña tan pronto como abra un archivo como en Atom (urgh) o solo cuando edite como con archivos de trabajo?
  R: Solo si habilita la opción para hacerlo (usePreviewTabs = false en Atom lo desactiva). De lo contrario, haga doble clic para abrirlos en una pestaña. Prueba las pestañas en Atom.

@felixfbecker Debido a que este producto lleva el apodo de Visual Studio, debería haber pestañas opcionales y deberían comportarse como lo hacen en cualquier otro producto de Visual Studio.

Dice mucho sobre tu personaje cuando mencionas algo tan trivial como una foto de perfil en respuesta a una respuesta válida a tus preocupaciones.

¡Sostenga el teléfono! ¡Tengo la respuesta! ¡Es perfecto! Listo? No necesitamos pestañas. ¡Extendamos los archivos de trabajo con una opción simple para mostrarlos en pestañas horizontalmente en la parte superior del editor! ¡Woo hoo! ¡Problema resuelto sin crear pestañas!

@ jayrosen1576 Esto en realidad no resuelve el problema completo, ya que como dije antes (y lo mencioné de nuevo literalmente en el comentario inmediatamente anterior al suyo), no es solo la apariencia visual de las pestañas lo que es diferente, es el comportamiento. Como dije en mi primer comentario aquí, también puede obtener "pestañas en la barra lateral" en Sublime Text, pero todavía no es lo mismo que los archivos de trabajo. (En mi opinión, es mejor).

@kfranqueiro Estoy totalmente de acuerdo. Solo estaba siendo sarcástico. Esto de la pestaña es un argumento realmente tonto. Si VSCode simplemente tuviera la capacidad de pestañas de las pestañas de Atom con la opción de ocultarlas (incluso de forma predeterminada), sería perfecto. Creo que todos estamos pidiendo lo mismo. Simplemente no puedo entender por qué no se pueden incluir ambos con una opción para desactivarlos.

Honestamente, discutir si las pestañas son una buena opción para un editor de texto es simplemente estúpido. Esto no es un nuevo concepto. Simplemente impleméntelos y déjelos opcionales. Conviértalo en una extensión y deje que sea el no. 1 hasta que la gente se dé cuenta de que esta es una funcionalidad básica y no tiene sentido no tenerla, al igual que la opción de menú en mayúsculas VS.

@nvivo No podría haberlo dicho yo mismo. Toda esta discusión parece tonta.

al igual que la opción de menú en mayúsculas VS.

@nvivo ¿Has probado esta extensión? No hay opción de menú, pero puede configurar algunos atajos de teclado. funciona bastante bien.

https://marketplace.visualstudio.com/items?itemName=wmaurer.change-case

Si no les gusta esta discusión, sigan adelante. ¡Leer este hilo es completamente opcional!

Por supuesto, leerlo es opcional, pero su existencia parece apoyar la idea de que agregar pestañas en VS Code es opcional y que deberíamos debatirlo. Una simple encuesta con la siguiente pregunta.

¿Continuará usando VS Code si las pestañas no se agregan pronto? Sí No

Demostraría que Microsoft perdería una proporción masiva de su base de usuarios potencial si no la agregan. Lo que significa que desde un punto de vista comercial, incluso si no necesitan la función ellos mismos, sería un suicidio comercial que no lo hicieran. Ergo, esta conversación distrae y es innecesaria.

Dicho esto, estamos hablando de la misma empresa que todavía no ha puesto extensiones en su navegador. Entonces supongo que todo es posible.

Con toda seriedad, la única conversación ahora debería ser sobre la mejor manera de implementar pestañas. Ya no hay un signo de interrogación sobre si las personas quieren la función, así que pasemos la conversación a algo más constructivo.

Extensiones de navegador? Activo ... NVM.

Honestamente, no veo razón para pestañas. El amor por las pestañas es demasiado grande. En términos de hacer el trabajo real, los atajos hacen todo lo necesario, con búsqueda por expresiones regulares, más metadatos y un proceso de trabajo mucho mejor. Proporcionan una necesidad esotérica básica de, no sé, algo familiar. Tengo la sensación de que esto es solo un impulso para ver si ms servirá a la comunidad, para ver si realmente están cambiando. Aunque no es tan inútil como todo el texto en mayúsculas en la edición vs.

En términos de lo dicho anteriormente.

"No creo que le quite tiempo a otras mejoras"

Personalmente, creo que sí, como por ejemplo, crear la capacidad de extensibilidad en la ventana del editor de texto, de modo que se puedan hacer extensiones para cualquiera que desee pestañas. Estoy bastante seguro de que la idea de vscode es mantenerlo lo más mínimo y liviano posible, con el usuario final agregando extensiones o extendiéndolo.

@ 4tron , ¡por supuesto que hay una conspiración de la comunidad malvada para probar microsoft aquí! ¿No hay siempre uno?

Si las pestañas tuvieran algún sentido, veríamos que otros editores las usan. Y si fuera una manera realmente buena de organizar múltiples contenidos abiertos, tal vez otros tipos de software que tengan esta necesidad de organizar múltiples contenidos abiertos, como por ejemplo, los navegadores, también los usarían. Pero por supuesto que no, ¡porque no tienen sentido! ¿Te imaginas algo que la gente use todo el tiempo, como el navegador usando pestañas? ¡Disparates!

Yo digo que juguemos seguros. Primero esperemos y veamos si algún otro buen editor es compatible con esta nueva función para no perder tiempo y esfuerzo en algo que en realidad no funciona. Revisemos visual studio, intellij, eclipse, atom, sublime, monodevelop, notepad ++ o cualquier otro que tenga una base de usuarios considerable. Una vez que al menos _algunos_ de estos editores admitan esta función durante un par de años sin sustituirla por otra, habrá indicios de que se trata de una función útil.

Pero no nos adelantemos. Necesitamos tener algo así como un rastreador de problemas donde las personas puedan expresar ese deseo directamente y tal vez dejar que otras personas voten, ¡para que podamos estar seguros de que no estamos haciendo esto por nada! Solo podemos tomar medidas si se convierte en una de las funciones más solicitadas en el repositorio. Entonces sabremos que no es solo una tendencia, sino que las personas lo encontraron útil para su trabajo diario y también quieren esa característica aquí.

Pero hasta ese día, esperemos con paciencia. Los editores de texto son algo nuevo y nadie sabe realmente qué tipo de funciones se necesitan.

¡Ghehehe, hilarante!

Op za 12 mrt. 2016 om 11:57 schreef Natan Vivo [email protected]

@ 4tron https://github.com/4tron , por supuesto que hay una conspiración del
comunidad malvada para probar microsoft aquí! ¿No hay siempre uno?

Si las pestañas tuvieran algún sentido, veríamos que otros editores las usan. Y si es
fue una muy buena manera de organizar múltiples contenidos abiertos, tal vez otros tipos
de software que tiene esta necesidad de organizar múltiples contenidos abiertos, como
digamos, los navegadores, por ejemplo, también los usarían. Pero por supuesto que no
¡porque no tienen sentido! ¿Te imaginas algo que la gente use todo el
tiempo como el navegador usando pestañas? ¡Disparates!

Yo digo que juguemos seguros. Primero esperemos y veamos si algún otro buen editor
admite esta nueva función para que no perdamos tiempo y esfuerzo en algo
eso en realidad no funciona. Revisemos Visual Studio, Intellij, Eclipse,
atom, sublime, monodevelop, notepad ++ o cualquier otro que tenga un
considerable base de usuarios. Una vez, al menos, _algunos_ de estos editores admiten
esta función durante un par de años sin reemplazarla por otra,
entonces habrá alguna indicación de que esta es una característica útil.

Pero no nos adelantemos. Necesitamos tener algo como un
rastreador de problemas donde la gente puede expresar ese deseo directamente y tal vez dejar
otras personas votan, por lo que realmente podemos asegurarnos de que no estamos haciendo esto por
¡nada! Solo podemos tomar medidas si se convierte en uno de los más solicitados.
características en el repositorio. Entonces sabremos que no es solo una tendencia,
pero la gente lo encontró útil para su trabajo diario y quiere esa función aquí
también.

Pero hasta ese día, esperemos con paciencia. Los editores de texto son algo nuevo
y nadie sabe realmente qué tipo de funciones se necesitan.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -195715795.

@nvivo ¿Realmente estás comparando un navegador con un editor de texto en este momento? Entiendo tu abuso de sarcasmo aquí, y es genial. El punto que intento señalar no es si las pestañas son útiles o no. Me gusta la idea de un editor ligero / mínimo. Esta es solo mi opinión, me gusta la idea de que el editor sea extensible para el usuario en función de sus preferencias de usuario. Eso es en lo que quiero que vscode esté trabajando. Entonces podemos mover esta discusión a "¿Por qué ningún desarrollador ha creado una extensión para esto todavía? Oh, tal vez debería porque me gustan las pestañas y me gustaría eso en esto, y vscode puede hacer eso, así que sí, ahora tengo un editor de texto que es similar a mi navegador "

@ 4tron Me pareció que también estaba comparando editores de texto con editores de texto.
Creo que están haciendo un gran trabajo al hacer que vscode sea extensible, pero estoy firmemente en el campo que considera que las pestañas deberían ser una característica lista para usar. Esta noción "Oh, ¿te gustan las pestañas como todos los demás programas que usas? Busca en Google el problema, encuentra recomendaciones que expliquen cómo instalar la extensión apropiada aportada por el usuario, ¡y listo!" no vuela. Me imagino que la mayoría de los usuarios solo esperan que existan pestañas, y dudo mucho que haya mucha gente que piense que encontrará una barra de pestañas instalando una extensión. Estoy bastante seguro de que no ha sido precedido por ningún otro software. ¿Por qué la gente pensaría en hacer eso?

@TurquíaHombre
Su retórica comenzó con una comparación con los navegadores.

Estamos hablando de desarrolladores aquí. Creo que tendrían la iniciativa si quisieran pestañas. Lo siento, estoy en contra de esta idea, pero no veo pestañas de motivos válidos, estoy alt + q en vs todo el tiempo. Simplemente no veo ningún valor agregado. esta es mi opinión personal, y tal vez soy un desarrollador de mierda por no entender cómo se supone que las pestañas son útiles. Creo que esta conversación es detallada y, personalmente, me gustaría ver que vscode se abra como un shell aislado para una personalización casi completa e incluso modelos basados ​​en negocios. donde alguien podría mejorar la personalización a un grado enfocado para, por ejemplo, desarrollo de drupal o desarrollo de wordpress donde la construcción de los editores se basa en el ecosistema de la base de código de los usuarios. Eso también me parece un problema mejor que resolver.

La desventaja de que todo sea una extensión es que terminas con interacciones extrañas no deseadas entre ellos. En vs código que ya usa GitHistory sobre Smart File Reopener causa extraños problemas de cierre de archivos.

Algo tan básico como las pestañas debería estar listo para usar. Ahora, como otros han solicitado en este hilo, abrir grupos o crear relaciones entre pestañas es donde las extensiones deberían entrar en la discusión.

@ 4tron , fue divertido, pero hablo en serio al respecto.

Los servicios de compiladores externos son algo que puede decidir o no admitir en un editor de texto. Los corredores de tareas integrados son una característica agradable.

Las pestañas no están en esta clase. Las pestañas son como ventanas, botones y archivos para abrir y guardar. No hay que tomar una decisión aquí, solo tíralos allí y sigue adelante, la gente lo espera. Esta no es una cosa personalizada avanzada que pocas personas quieran que sea compatible con complementos, son una interfaz de usuario estándar en _ cualquier sistema operativo en todas partes_. La gente está acostumbrada, y hay una razón por la que todos los demás posibles editores no requieren una petición para agregarlos.

Y es por eso que discutir si las pestañas son buenas o no es estúpido. VS Code no es un experimento de UX, es un intento de tener un buen editor .NET para todas las plataformas. Haz que esta maldita cosa sea útil para el 90% de la gente y tendrás éxito.

Honestamente, entiendo tu punto sobre las alternativas, pero solo debes entender que eres una minoría muy pequeña. Creer que la mayoría de las personas que preguntan por esto son solo trolls que quieren probar Microsoft es una ilusión.

Ese punto de que era una llamada para ver si ms cambiaría su postura en las pestañas, fue poco entusiasta, principalmente debido a la pasión por incluir pestañas. Hasta el punto de que alguien ni siquiera probaría el editor porque no había pestañas. Lucho por entender esto. No olvidemos que todavía está en Beta. Entonces, con suerte, agregarán pestañas (como opcional, por favor).

@ 4tron Lo probé muchas veces y no uso vscode con regularidad porque no parece escalar bien a proyectos grandes, y las pestañas que faltan es una de las principales razones prácticas que me parecen verdaderas.
Lo uso principalmente como un editor de texto ligero cuando estoy editando una pequeña cantidad de archivos, pero tan pronto como quiero trabajar en uno de nuestros grandes proyectos, vscode simplemente no funciona. Las pestañas que faltan y el hecho de que no hay una noción de subproyectos (o "soluciones", como dice VS) son los únicos bloqueadores que conozco actualmente.

Sin embargo, solo quiero comentar sobre esta idea de agregar todo con complementos. Ese es un buen gol; Tener un gran marco de extensión es importante, pero creo que deben tener cuidado con comprometerse demasiado con esa idea.
Yo uso VS, y aunque me vuelve loco, me siento apegado a él porque tiene un nivel muy alto de calidad de producto, que es lo que espero de un producto de MS. Probé todas las alternativas de OSS que existen (y otras herramientas patentadas), y todas parecen quedarse cortas en el frente de usabilidad básica (particularmente cuando se trata de la experiencia de depuración).
Realmente espero que la intención de vscode no sea ser un caparazón ligero en el que todos piratean funciones al azar a través de extensiones ... ya hay muchas otras herramientas que se ajustan a esa descripción, no encuentro otra que sea convincente. Lo que quiero de vscode es lo que siempre he deseado de VS; estar bien diseñado desde una perspectiva de usabilidad por diseñadores profesionales de UX, y ser PLATAFORMA CRUZADA.

Creo que aquellos que están en contra de las pestañas pueden estar perdiendo el punto. Yo (nosotros) no queremos una solución de todo o nada. Todo lo que pedimos es una opción simple para activar pestañas (pueden estar ocultas de forma predeterminada) que se ven y se comportan como las del popular editor Atom. Si no te gustan, nunca sabrás que existen. Si lo hace, pueden habilitarse. Y para aquellos que nunca han usado Atom y la experiencia de pestañas de múltiples paneles, les sugiero que lo prueben antes de descartar por completo el argumento para ellos. Puede que no le gusten, pero debe admitir que _son_ útiles para muchos de nosotros. Si no fuera por la excelente capacidad de depuración de node.js de VS Code, usaría Atom exclusivamente. No me importan los archivos de trabajo. Creo que pueden ser útiles, sin embargo, no son un buen reemplazo para las pestañas y no son realmente una forma alternativa de hacer lo mismo. Es como decir _Tienes un Honda Civic, ¿por qué quieres una camioneta? _ Bueno, prueba a cargar 1200 libras de piso de lengüeta y ranura de bambú en la parte trasera de tu Civic y verás por qué. Ambos son vehículos pero tienen diferentes propósitos.

Como dije antes, quite las pestañas de Visual Studio, Edge o cualquier otro producto de Microsoft para una versión y vea la reacción. No será bonito. Todos podemos tener las dos cosas. Estamos solicitando que las pestañas sean un _opcional_, no un componente obligatorio del editor. ¿Se puede invertir mejor el tiempo en el desarrollo de otros editores? Por supuesto. Las correcciones de errores críticos y las mejoras que bloquean el uso del editor siempre deben ser lo primero. Sin embargo, estoy seguro de que se han agregado un montón de características que no llegan al nivel de ser una mejora o solución crítica. Entonces, si se dedica tiempo a ellos, entonces debería reservarse un tiempo para una función que la gran mayoría de este hilo está pidiendo.

Nos encanta lo que VSCode se ha convertido en los últimos meses y estamos tan comprometidos con este tema porque queremos que sea el mejor editor disponible. Aquí no hay lugar para la negatividad. A todos nos apasiona lo que queremos / no queremos como desarrolladores. Nadie tiene una opinión equivocada, pero las opiniones contrarias deben ser respetadas como tales y no simplemente descartadas porque se sienta inválidas.

No creo que haya mucha "pasión por las pestañas". Lo que sucede es que después de que @bpasero dijo " No creo que las pestañas sean una buena manera de mostrar la lista de archivos abiertos " y " Hasta ahora no he escuchado una buena razón para las pestañas ", la gente se volverá más vocal tratando de justificar la solicitud al confirmador principal del proyecto.

Estoy graciosamente frustrado de ver toda esta discusión, y estoy un poco ofendido porque uso VS Code a diario en mi trabajo y quiero tener un buen editor .NET en mac y linux, y extraño mucho las pestañas. y no entendí ese momento de "¡wow! esto es realmente más útil", pero la respuesta aquí parece ser "¡simplemente no te diste cuenta de que creamos algo increíble! ¡dale tiempo y acostúmbrate!"

Aquí hay algunos problemas reales que veo al usar VS Code diariamente durante un par de meses:

• para mí no tiene sentido hacer clic en el icono de cierre en la ventana, pero mantengo el archivo en esa lista; tengo que seguir limpiando constantemente esa lista manualmente para tener una lista en la que solo veo los archivos con los que estoy trabajando, y los archivos Con las que trabajo no son las últimas que abro o las que estoy cambiando, son las que quiero mantener abiertas al mismo tiempo
• No tiene sentido para mí cerrar un archivo no guardado y tenerlo en esa lista con un marcador; muchas veces al día hago algo y el cambio no se refleja en la aplicación porque cerré el archivo y el código VS no preguntó yo para salvarlo, lo que me hace perder el tiempo
• un clic abre el archivo, pero solo haga doble clic para colocar el archivo en la sección de uso reciente, por lo que abro constantemente archivos que no aparecen allí, y luego mi memoria muscular encuentra que es más fácil agregar o eliminar un espacio en el archivo luego desplácese hasta el archivo que estoy viendo nuevamente y haga doble clic en él
• Me resulta molesto que no pueda ver la barra de desplazamiento una vez que se llena la lista a menos que pase el mouse sobre ella. Ahora, esto es complicado porque así es como funciona la interfaz de usuario en el editor. Pero mira, conozco el proyecto y sé que debe haber más archivos en la vista de carpeta. También conozco la estructura del código, así que sé que debe haber algo más en el panel del editor. Pero con la lista de recientes, no tengo ni idea. "¿Está lleno o me olvidé de abrir ese archivo? ¿No lo abrí hace 1 minuto? Déjame abrir ese archivo nuevamente ..."

Ahora, veo que la mayor parte de esto se resolvería con un argumento como "_oh, pero no entendiste, es una lista de archivos usados ​​recientemente, no una lista de archivos abiertos. La estás comparando con pestañas, y hay mejores formas de lidiar con los archivos abiertos. Después de un tiempo, empiezas a ..._ "

A lo que respondería con gusto: "_Todo esto no tiene ningún sentido para mí y en realidad me está volviendo improductivo. Ya existe una solución que funciona en todas partes durante décadas. No quiero arreglar algo que nunca fue un problema y, sinceramente, no veo esta nueva solución como una alternativa mejor. ¿Podemos tener algo familiar que funcione y que todos estamos acostumbrados? Gracias_ "

Sé que todo esto suena arrogante. Pero apuesto a que esto es lo que la mayoría de la gente piensa, pero es demasiado tímida o educada para decirlo.

Las IU experimentales son excelentes alternativas y estoy a favor de tener la opción de cambiar entre las dos. Pero este es actualmente un experimento forzado que impide la otra opción, que es la más común y esperada. Y al igual que el menú de inicio de Windows 8, no hay forma de que esto termine bien.

A lo que respondería con mucho gusto: "Todo esto no tiene ningún sentido para mí y en realidad me está volviendo improductivo. Ya existe una solución que funciona en todas partes durante décadas. No quiero arreglar algo que nunca fue problema y, sinceramente, no veo esta nueva solución como una alternativa mejor. ¿Podemos tener algo familiar que funcione y que todos estamos acostumbrados? Gracias "
...
Y al igual que el menú de inicio de Windows 8, no hay forma de que esto termine bien.

No podría estar mas de acuerdo.

Como el plegado de código fue una vez la función más votada, ahora lo es las pestañas . El equipo de vscode nos dio el doblez.

Me sorprenderé y decepcionaré si las pestañas nunca se materializan dado el gran historial de inclusión del equipo de vscode de las principales solicitudes de los usuarios a la luz de la refrescante participación de Microsoft en la comunidad de código abierto.

@ianwesterfield Exactamente, es la función más solicitada con miles de votos. Va a suceder. Esta conversación no tiene sentido y debe pasar a "¿Cómo deberían funcionar exactamente las pestañas?"

Comenté antes sobre la existencia de una implementación casi perfecta de pestañas: Atom. Son fáciles de organizar, tienen una visualización adecuada de las rutas de archivos parciales si dos pestañas tienen el mismo nombre de archivo y funcionan extremadamente bien en una ventana con múltiples paneles horizontales y / o verticales (que creo que es otra característica necesaria de VSCode). Si VSCode tuviera las mismas funciones de pestaña que Atom, creo que cubriría el 99% de lo que todos piden. Y dado que Atom también está basado en electrones, la implementación puede funcionar igualmente bien en VSCode. No estoy a favor de una solución imitadora de nada, sin embargo, ellos (Atom) han hecho un gran trabajo implementando pestañas y lo que tienen es una excelente solución en ese sentido.

@ jon64digital Tal vez sea solo yo, pero creo que lo que impide que esta conversación evolucione es una sensación de frustración. Esta solicitud aún no está asignada en la cartera de pedidos, incluso con más de 6000 votos y una referencia vagamente redactada en la iteración del 31 de marzo:

Mejorar la gestión de documentos, comportamiento de apilamiento de los editores

Parece que todavía tenemos que justificar repetidamente la existencia de pestañas, y mucho menos su comportamiento. Por lo menos, supongo, esa referencia es una de las tres para Eliminar los obstáculos de adopción , pero ahora es el 12 de marzo ...

Con eso en mente, creo que si al menos se lo asignaran a alguien, podríamos estar tranquilos en lo que dijo @waderyan antes y tal vez entonces la conversación pueda comenzar a evolucionar.

EDITAR Tal vez esta falta de compromiso del equipo de VS Code sea un malentendido, después de todo, el plan de iteración de marzo no se ha actualizado desde el 7 de enero.

@ jayrosen1576 Estoy de acuerdo, y creo que el 1% de las solicitudes de los usuarios que no se cubrirían podría abordarse mediante extensiones (por ejemplo, abrir archivos con relaciones en grupos de pestañas, etc.).

@ jayrosen1576 ¿Atom le permite vincular archivos para que pueda tener una vista dividida que (por ejemplo) abre toolbar.html en el primer cuadro, toolbar.js en el segundo y toolbar.css en el tercero?

Este es solo un ejemplo, pero sería absolutamente ideal. Alguien de arriba dijo que Vim puede hacer esto, pero revisé vim y no estaba interesado en él por varias razones, pero la pestaña suena excelente.

@ jon64digital Atom no hace esto de forma predeterminada, y no tengo conocimiento de ninguna extensión hasta la fecha que lo haga (incluso extensiones inspiradas en vim), pero este es el caso de uso de extensión al que me refería en mi última publicación.

EDITAR consulte el comentario de @jtosey anterior (aproximadamente 9 días antes de esta publicación).

Personalmente, pude ver que esto es una molestia. La mitad del tiempo no me importa la vista, solo el controlador, el modelo y el JS del lado del cliente. Probablemente terminaría volviéndome loco si la vista se abriera cada vez que abriera el JS.

Pero, de nuevo, esa es la belleza de una extensión: si no me gusta, puedo apagarla.

Cuando trabajamos en solicitudes de funciones como esta que tienen un impacto muy fuerte en UX, normalmente pasamos bastante tiempo en reuniones de UX para discutir cómo debería verse la implementación real. Tuvimos la gestión de documentos mejorada en nuestra agenda durante bastante tiempo, pero otras cosas en nuestra lista de GA simplemente tenían una prioridad más alta (Accesibilidad, por ejemplo).

Recogeremos este elemento después de nuestro lanzamiento de GA a fin de mes y comenzaremos la discusión sobre cómo debería funcionar la gestión de documentos en el futuro. Vemos algunas fallas en la forma actual en que funcionan las cosas y sabemos que debemos mejorarlas. Creemos que incluso sin pestañas, hay algunas cosas que simplemente no son muy intuitivas en la forma en que se comporta la UX hoy (Cerrar editor vs.Cerrar archivo, el hecho de que los editores secundarios se comportan de manera diferente en comparación con otros editores, archivos de trabajo y abierto, etc.).

Si bien el concepto de pestañas se comprende bien, no creemos que podamos simplemente agregar pestañas en la parte superior de nuestra gestión de documentos existente sin volver a revisar nuestros conceptos allí.

Creo que tendremos bastantes discusiones sobre cómo debería funcionar la gestión de documentos en el futuro y creo que estamos preparados para revisar los conceptos cuando lo consideremos necesario.

@bpasero después de revisar el código por otro problema, no entiendo por qué no es posible simplemente agregar pestañas o qué conceptos tendría que cambiar al hacerlo. Podría ser de gran ayuda si pudieras iluminarnos, o ¿es esto una referencia a la línea de pensamiento en tus publicaciones originales?

@bpasero Fue bueno si explicaras más sobre lo que se discute y cuáles son algunos de los enfoques que ves como posibles soluciones a los problemas que publicamos.

PD: No estoy seguro de si es posible con VSCode, pero algunos equipos como Roslyn, TypeScript y algunos más comparten sus notas de diseño, da mucho contexto a cómo funcionan y lo que viene a continuación, también abre la comunidad a nuevas discusiones, es posible algo como esto?

@bpasero ¿el equipo consideraría seriamente los intentos de la comunidad de agregar pestañas? No me importa intentarlo, pero no creo que nadie quiera perder el tiempo si se bloquea algún esfuerzo.

Creo que su equipo está bloqueado por haber hecho que este grano de arena llegue a la montaña.

Significado: las pestañas son constitutivas, no sinónimos, del concepto más amplio de gestión de documentos. Ya se han presentado otros problemas relacionados con otras áreas de la gestión de documentos de vscode.

Ya discutimos nuestras ideas de UX a través de problemas al aire libre (consulte https://github.com/Microsoft/vscode/issues?q=is%3Aopen+is%3Aissue+label%3Aux), supongo que haríamos lo mismo para gestión de documentos y pestañas.

También creo que no queremos que estas mejoras se realicen a través de extensiones, sino que las tengamos como un concepto central en el banco de trabajo de VS Code.

Una vez que comenzamos la discusión de UX en el equipo, nos gustaría involucrar a la comunidad también y luego también discutiremos las fallas que vemos en nuestro diseño actual y lo que planeamos mejorar.

@bpasero muchas gracias, eso es todo lo que quería saber. :)

@bpasero Impresionante. Sé que están poniendo un gran esfuerzo en el producto y todos lo apreciamos mucho. Creo que muchos de nosotros simplemente sentimos algo de frustración con la falta de pestañas en la interfaz de usuario, ya que dependemos mucho de ellas y cambiar completamente la forma en que trabajamos no es realmente una opción. Queremos que este sea el mejor editor que existe y está muy cerca de lograrlo.

Sin leer todo este hilo, doy un gran: +1: en esto.

He estado usando Sublime durante años y me encantan las pestañas. Veo que los archivos de trabajo llenan parte del vacío, pero no por completo. No puedo explicar completamente por qué, ¡pero dame mis pestañas!

+1

Extremadamente necesario.

+1

Trabajo en muchos tipos de archivos diferentes durante el desarrollo, por lo que a menudo me gusta crear un grupo de pestañas en el lado derecho para un tipo de archivo y otro grupo de pestañas a la izquierda para otros tipos de archivos. Por ejemplo, cuando trabajo en el código transportador / webdriverjs, me gusta mantener todos los "Objetos de página" a la derecha y todas las "especificaciones" a la izquierda, agrupadas por separado y lógicamente. De manera similar, cuando trabaje en cosas de front-end, mantendré un grupo de pestañas a la derecha para todos los archivos js / ts y otro a la izquierda para html y css.

Estos son solo dos ejemplos, pero hago esto TODO el tiempo en casi todos los proyectos hasta cierto punto y esta estrategia me ha servido bien durante muchos años de desarrollo y la encuentro extremadamente útil.

Si bien Code ciertamente me permite tener múltiples paneles, el enfoque de la lista de archivos global hace que sea más difícil diferenciar entre los tipos de archivos y, por lo tanto, pierdo mucho tiempo desplazándome por la lista del archivo que quería ver. Además, cuando (instintivamente) trato de cerrar solo un archivo en el panel derecho, todo el panel desaparece, lo cual es extremadamente frustrante, especialmente después de usar VS normal durante más de 16 años, lo que me ha entrenado para esperar que el panel permanezca abierto con el resto de los archivos visibles.

La falta de grupos de pestañas en Code es extremadamente decepcionante y no creo que la gente deba ser forzada o convencida a trabajar de cierta manera porque "es mejor" o "no hay una buena razón para las pestañas" en su opinión. Sí hay. Tal vez simplemente no los use de la mejor manera o no sienta que son útiles, pero hay muchos de nosotros que lo hacemos y realmente apreciaríamos algo tan básico como los grupos de pestañas.

Tengo entendido que Code se basa en Atom, que ya tiene soporte para grupos de pestañas. Parecería que se necesitaría mucho trabajo adicional para eliminar esta funcionalidad, lo que simplemente no tiene mucho sentido para mí. Por lo menos, permita que el usuario elija qué experiencia desea para que pueda usar el Código de la manera que mejor le funcione.

Regrese los grupos de pestañas a VS Code.

Tal vez si dibuja cuadros alrededor de los nombres de archivo en la lista de Archivos de trabajo, la gente verá que es funcionalmente equivalente a las pestañas del lado izquierdo ... :-)

@ChrisMiami : excepto que no lo es . (Potencialmente estaría dispuesto a vivir con eso si lo fuera).

Jajaja

El jueves 17 de marzo de 2016 a las 4:59 AM Kenneth G. Franqueiro <
[email protected]> escribió:

@ChrisMiami https://github.com/ChrisMiami : excepto que no lo es
https://github.com/Microsoft/vscode/issues/224#issuecomment -166931316.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -197603728

@kfranqueiro mientras espera una solución de pestañas adecuada, podría estar interesado en adoptar las combinaciones de teclas que utilizo, que acercan ctrl + wy ctrl + shift + w a una implementación de pestañas normal.

@ nub340 VSCode no se basa en Atom sino en Electron, que fue creado por el mismo grupo que está trabajando en Atom.

+1 ¡Por favor, agregue!

También creo que esta es una característica que falta mucho en un gran editor.

Agregue pestañas como una opción o permita el complemento de terceros para la funcionalidad de pestañas.

Lo primero que me llamó la atención sobre VSC (después del nombre tonto) fue lo _grande_ que era _no_ tener pestañas.

Actualmente tengo 8 archivos abiertos; las pestañas no tienen sentido para mí, porque los nombres de los archivos no se mostrarán en las pestañas.

_Adoro_ CTRL + TAB, y la lista de 'archivos de trabajo'.

Si debe agregar pestañas, hágalas opcionales.

@leegee No son "inútiles", simplemente no los necesitas. ¿Consideró que las personas que están trabajando en diferentes tipos de proyectos podrían tener un caso de uso diferente al suyo?

Dale a las miles de personas que han votado por pestañas, creo que lo único "inútil" por aquí es tu comentario :)

@ jon64digital : Vi que el proyecto había solicitado comentarios generales de los usuarios sobre la posibilidad de pestañas. Supuse que eso significaba que deberíamos expresar nuestras propias opiniones. Ahora me doy cuenta de que debería haberte enviado un correo electrónico primero para poder expresar tu opinión y evitar tu grosera invectiva ad-hominem. Mis disculpas.

@ jon64digital @leegee dijo que no tenían sentido _ para él_, no en general. Apoyo totalmente las pestañas, pero estoy de acuerdo en que deberían ser una opción que se pueda desactivar para aquellos que no las usan. Mantengamos la discusión civilizada y no recurramos a ataques personales. Nadie tiene una opinión incorrecta. Son solo eso ... opiniones.

@ jayrosen1576 Ha editado su comentario. Si originalmente hubiera dicho "inútil para mí", entonces, por supuesto, no habría dicho lo que hice. También supongo que las otras dos personas que rechazaron su comentario lo hicieron antes de que él lo editara.

Estoy totalmente de acuerdo en que todo el mundo tiene derecho a opinar, pero parece que hay varias personas aquí que no requieren pestañas en su flujo de trabajo que buscan negar a quienes las quieren poniendo -1 o diciéndole a MS que la función es no es necesario o desviaría de alguna manera recursos de características más importantes. Dado que pueden ver cuánta gente quiere pestañas, encuentro esto egoísta y un poco inmaduro.

De todos modos, me disculpo si alguien vio esto como un ataque personal. Le puse un emoticón después.

En todo caso, creo que esta discusión solo ilustra que hay muchas formas en que un desarrollador puede usar un IDE y todas son perfectamente válidas para su caso de uso. No existe una forma "correcta" y al final del día es solo una herramienta para hacer el trabajo. A algunos desarrolladores les gustan las pestañas para poder agrupar arbitrariamente archivos similares y otros encuentran que una sola lista MRU es perfectamente adecuada. Luego tienes a los que solo usan el bloc de notas para todo y todos somos un montón de pensamientos, ja, ja.

En serio, aunque creo que, dado que las pestañas han sido una parte esencial de Visual Studio durante casi siempre, hay muchos desarrolladores que se han acostumbrado a su utilidad y, por lo tanto, hacen que la lista de MRU única sea opcional (ya sea de suscripción o de exclusión) haría que la ya impresionante herramienta VS Code sea aún más versátil, para todos.

@ nub340 exactamente! a algunos de nosotros nos gustan las pestañas porque siempre fueron parte de nuestra experiencia como desarrolladores / usuarios, personalmente me gusta ver los archivos en los que estoy trabajando en la parte superior, no hay una ventaja inherente en las pestañas sobre los archivos de trabajo, pero así es como algunos de nos gusta.

De acuerdo, me gustaría que fuera una opción, no forzarlo.
El martes 22 de marzo de 2016 a las 6:22 a. M. Eyal Solnik [email protected]
escribió:

@ nub340 https://github.com/nub340 exactamente! a algunos de nosotros nos gustan las pestañas porque
siempre fueron parte de nuestra experiencia como desarrolladores / usuarios, personalmente me gusta
para ver los archivos en los que estoy trabajando en la parte superior, no hay inherentes
ventaja de las pestañas sobre los archivos de trabajo, pero así es como a algunos de nosotros nos gusta.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -199565160

No teníamos pestañas en el Vic-20 ...

Una cosa que surge de esta discusión es que todo lo que se (hace)
disponible, debería ser personalizable.

@glennblock , @leegee sí, definitivamente debería ser una opción, pero ¿no debería el archivo de trabajo recibir el mismo tratamiento para aquellos que no lo quieren? sin embargo, probablemente sea mejor discutirlo en otra solicitud de función. :)

He publicado este texto aquí: https://github.com/Microsoft/vscode/issues/101

También es válido para esta discusión. Me alegraría ver la respuesta de @bpasero .

Quiero esta característica. Fin de la discusión. A la mierda tus opiniones @bpasero No me importa lo que creas que es correcto y lo que no. Lo mismo ocurre con las pestañas # 224. Intenta convencernos de que su solución es mejor. Una vez más, joder tu solución. Todos hacemos las cosas de manera diferente y a nadie le importa lo que pienses. Estoy usando vscode solo por el gran soporte de mecanografiado y angular2. De lo contrario, lo odio porque carece de las características que tienen los editores normales, por ejemplo, SublimeText, Atom, Brackets

Jaja @PeterMtj , gracias por decir lo que todos estamos pensando :)

@bpasero parece tener la costumbre de rechazar y desacreditar cualquier característica que él mismo no usaría personalmente y que no se ajusta a su flujo de trabajo personal.

La gente usa el software de Microsoft principalmente porque es necesario, rara vez porque les gusta, y cuando ves que el personal de Microsoft tiene actitudes como la suya, demuestra por qué no pueden diseñar un software decente como Sublime Text. He hecho todo lo posible con VS Code, pero estoy muy cerca de desinstalarlo.

@PeterMtj ¿En serio? así es como abordan las cosas? maldecir a la gente? Si no le tienes respeto, ¡ten algo de respeto por ti mismo!

@ jon64digital ¡Puede votar en contra o decir su opinión personal y está bien! ¡no necesitamos ser personales y ciertamente no maldecir a la gente por sus opiniones!

También estoy en desacuerdo con su respuesta inicial, decir "No" no es profesional y bastante grosero en mi opinión, pero creo que la comunidad puede hacerlo mejor y mantenerse civilizada independientemente de la opinión de la gente.

La gente usa el software de Microsoft principalmente porque es necesario, rara vez porque les gusta, y cuando ves que el personal de Microsoft tiene actitudes como la suya, demuestra por qué no pueden diseñar un software decente como Sublime Text. He hecho todo lo posible con VS Code, pero estoy muy cerca de desinstalarlo.

Editar: ¡Las personas no tienen que usar productos de Microsoft! Ciertamente no tengo que hacer eso y decir que la gente rara vez lo hace porque les gusta, ¡es solo hablar basura! Microsoft crea excelentes productos y excelentes tecnologías y estoy lejos de ser un fanático de todo lo que hacen, ¡pero ciertamente hacen algunas cosas bien! nadie obliga a nadie a usar VSCode y si alguien te obliga a usar VSCode, ¡debería ser despedido porque debes elegir tus propias herramientas! ¡Lo único que debe preocuparle a un empleador es su trabajo, no cómo se hace!

¡No convierta esto en una guerra de llamas y manténgalo constructivo, por favor!

@eyalsk

No estaba tratando de iniciar una guerra de llamas o de hablar basura, pero estoy 100% de acuerdo con lo que dije. Históricamente, MS ha vinculado sus propios productos a su sistema operativo y entre sí para obligar a las personas a usar su software porque saben que no es lo suficientemente bueno como para valerse por sí solo. Conozco a muchas personas que tienen que usar MS Office en el trabajo, tuve que usar Visual Studio antes porque no tenía otra opción y podía contar la cantidad de personas que voluntariamente usarían Internet Explorer con los dedos de una mano. Incluso han sido objeto de demandas antimonopolio debido a estas prácticas, por lo que decir que nadie está haciendo que nadie use software de MS es ingenuo.

Las cosas se han movido en la dirección correcta recientemente y se están volviendo más independientes de la plataforma y están tratando de mejorar la interoperabilidad de su software con otros. Estoy seguro de que hay buenas personas en MS que intentan hacer un gran software y darles a las personas lo que quieren, pero bpasero claramente no es uno de ellos. Su actitud de mente cerrada no es un mérito para ellos y pensé que era divertido que @PeterMtj lo llamara de esa manera. Todos somos adultos aquí y nadie debería sentirse ofendido por alguna palabrota. Es solo una palabra.

Aquí tienes un hilo largo con cientos de personas que le dicen a MS EXACTAMENTE lo que quieren de un editor de código. No es como si no supieran lo que queremos. Luego tenemos a un empleado de MS aquí diciendo "no, básicamente estás equivocado". ¿No pinta eso una imagen de una empresa que no está exactamente en sintonía con su audiencia?

Solo mi 2c.

@ jon64digital

No estaba tratando de iniciar una guerra de llamas o de hablar basura, pero estoy 100% de acuerdo con lo que dije. Históricamente, MS ha vinculado sus propios productos a su sistema operativo y entre sí para obligar a las personas a usar su software porque saben que no es lo suficientemente bueno como para valerse por sí solo.

Esa es solo su suposición de sesgo y lo respeto, pero podemos decir exactamente lo mismo sobre cualquier otra corporación en el mundo, por nombrar algunos Apple, Oracle y Google ...

Conozco a muchas personas que tienen que usar MS Office en el trabajo,

Las personas no están obligadas a usar MS Office, esa es la decisión del empleador, Libre Office es un gran producto y es una alternativa bastante buena.

Tuve que usar Visual Studio antes porque no tenía otra opción

No sé _por qué_ no tuviste elección, ¡pero definitivamente tienes opciones hoy! Siempre tuve la opción, incluso cuando la gente usaba mucho Visual Studio para el desarrollo de .NET. Usé SharpDevelop, Vim y Notepad ++, nunca tuve problemas para usar varios editores, de todos modos no soy fanático de los diseñadores ...

Para C / ++, tiene aún más soporte de editores e IDE a menos que use VC ++ :)

Además, nunca entendí por qué algunas personas se encierran en una pila específica de tecnologías creadas por X, existen muchas tecnologías más allá de, digamos, Microsoft.

Podría contar el número de personas que voluntariamente usarían Internet Explorer con los dedos de una mano.

Tienes razón, Internet Explorer era muy malo hasta la versión 9, pero han mejorado bastante desde entonces y, aunque soy un usuario de FireFox, no juzgo a Microsoft por su pasado, los juzgo por quiénes son. el presente y se ve bien!

Incluso han sido objeto de demandas antimonopolio debido a estas prácticas, por lo que decir que nadie está haciendo que nadie use software de MS es ingenuo.

Nadie está haciendo que nadie use nada y no sé sobre la mayoría de la gente, pero estoy lejos de ser ingenuo, soy razonable.

Si su empleador toma la decisión de usar tecnologías MS, entonces ciertamente está _forzado_ pero nuevamente no es culpa de Microsoft, si tomó la decisión de usar tecnologías MS, entonces lo eligió y quejarse es un poco tonto, hay tecnologías equivalentes que son tan buenos como los de Microsoft, por lo que la gente tiene opciones.

Las cosas se han movido en la dirección correcta recientemente y se están volviendo más independientes de la plataforma y están tratando de mejorar la interoperabilidad de su software con otros. Estoy seguro de que hay buenas personas en MS que intentan crear un gran software y darles a las personas lo que quieren,

¡Exactamente! aunque no creo que dar a las personas lo que quieren sea bueno desde el punto de vista del diseño. :)

pero bpasero claramente no es uno de ellos. Su actitud de mente cerrada no es un mérito para ellos y pensé que era divertido que @PeterMtj lo llamara de esa manera. Todos somos adultos aquí y nadie debería sentirse ofendido por alguna palabrota. Es solo una palabra.

No creo que necesitemos definir a las personas en función de sus opiniones, ciertamente no en este tipo de opiniones y ser un adulto no hace que las personas sean vulnerables a ataques personales de ningún tipo, jurar que una persona no es agradable y debe desanimarse. Actuar como un adulto significa que puedes controlar tu rabia y escribir tu opinión sobre alguien o algo sin ser ofensivo.

Aquí tienes un hilo largo con cientos de personas que le dicen a MS EXACTAMENTE lo que quieren de un editor de código. No es como si no supieran lo que queremos. Luego tenemos a un empleado de MS aquí diciendo "no, básicamente estás equivocado". ¿No pinta eso una imagen de una empresa que no está exactamente en sintonía con su audiencia?

Ese es un buen punto y una queja, ¡no estoy diciendo lo contrario! pero @bpasero ya declaró que una vez que trabajen en la UX también abordarán este problema "_Una vez que comenzamos la discusión de UX en el equipo, nos gustaría involucrar a la comunidad también y luego también discutiríamos las fallas que vemos en nuestro diseño actual y lo que planeamos mejorar. "

@eyalsk Sí, así es exactamente como

@ jon64digital tiene razón sobre la actitud de @bpasero . No sé qué pensar de él. Tal vez solo quiera deshacerse del trabajo diciendo que estás equivocado y que no es necesario. De cualquier manera @bpasero probablemente no debería comunicarse con la comunidad con su actitud. Esa es mi opinión.

Trate de darse cuenta de que Microsoft no nos está ayudando. Estamos ayudando a Microsoft mediante el uso de sus productos y brindando comentarios para que puedan hacer un producto decente. Esto no debería ser una discusión sobre la defensa de pestañas, sino sobre cómo deberían funcionar las pestañas para que esté en la naturaleza con vscode. Vscode es para la comunidad, somos nosotros y, en un caso extremo, si todos quisiéramos un dinosaurio rojo en el medio de la pantalla, deberían hacerlo sin cuestionar las razones. Todos tenemos nuestras propias razones. De lo contrario, vscode es inútil para la comunidad. Así lo veo yo.

@PeterMtj Supongo que tendremos que aceptar estar en desacuerdo. :)

Quería intervenir y proporcionar algunos antecedentes adicionales para este problema. Estamos a punto de concluir un hito importante de Code. Un enfoque clave para nosotros en los últimos 6 meses fue el apoyo a la accesibilidad y la localización. Esto nos ha dejado sin ciclos en el área de la interfaz de usuario para trabajar activamente en los comentarios de las pestañas. Ahora que la mayoría de las casillas de verificación del plan de marzo (# 3555) están marcadas, poco a poco comenzamos a buscar nuevamente. En abril, intensificaremos este tema. @bpasero jugó un papel clave en el desarrollo de nuestra UX y esta será la próxima gran evolución.

Gracias a todos por su pasión y comentarios, ayudándonos a hacer de VS Code el mejor producto posible.

TIA para las adiciones de accesibilidad: marcará una gran diferencia para nosotros
medio ciego

El sábado 26 de marzo de 2016, 01:38 Erich Gamma, [email protected] escribió:

Quería intervenir y proporcionar algunos antecedentes adicionales para este problema.
Estamos a punto de concluir un hito importante de Code. Un enfoque clave para nosotros
en los últimos 6 meses fue el apoyo a la accesibilidad y localización. Esta
no nos ha dejado ciclos en el área de la interfaz de usuario para trabajar activamente en los comentarios de las pestañas.
Ahora que la mayoría de las casillas de verificación del plan de marzo (# 3555
https://github.com/Microsoft/vscode/issues/3555) están marcados, estamos
lentamente comenzando a mirar hacia arriba de nuevo. En abril, intensificaremos este tema.
@bpasero https://github.com/bpasero jugó un papel clave en la
desarrollo de nuestra UX y esta será la próxima gran evolución.

Gracias a todos por su pasión y comentarios, ayudándonos a hacer de VS Code el
mejor producto que puede ser.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -201618115

@egamma Realmente agradezco a ti y a tu equipo por todo, ¡creo que estás haciendo un gran trabajo! pero siento que la primera respuesta de @bpasero irritó a la gente y esto podría haberse evitado si hubiera dado una idea de por qué cree que las pestañas no deberían ser una opción en lugar de simplemente decir "No".

De todos modos, centrémonos en el presente, ¿hay alguna compilación nueva antes del evento // build /? :RE

@eyalsk Creo que el comentario "No" en realidad se refería a la primera respuesta de @inakianduaga , ya que no es posible implementar pestañas usando la API de extensión actual. Creo que esto se malinterpretó diciendo que las pestañas nunca sucederán, sin embargo, el problema probablemente se habría cerrado si ese fuera el caso.

@Tyriar , ¡gracias! :)

De todos modos, centrémonos en el presente, ¿hay alguna compilación nueva antes del evento // build /? :RE

Los bits de la nueva compilación ya lo están esperando en el canal interno ( notas de la versión ), utilícelo y envíenos sus comentarios.

@egamma gracias! ;)

Estamos comenzando el trabajo de diseño en esta experiencia y nos gustaría involucrar a la comunidad tanto como podamos. Realizaré discusiones de diseño regulares a medida que avancemos para recibir sus comentarios. La mayoría de las veces, serán sesiones individuales en las que compartiremos en qué estamos trabajando y las discutiremos con usted.

Las primeras sesiones tendrán lugar este miércoles. Regístrese aquí si está interesado: https://calendly.com/stevencl/visual-studio-code-tabs-design-discussion/04-06-2016

¡Increíble!
El lunes 4 de abril de 2016 a las 3:54 a. M. Steven Clarke [email protected]
escribió:

Estamos comenzando el trabajo de diseño en esta experiencia y nos gustaría
involucrar a la comunidad tanto como podamos. Estaré ejecutando un diseño regular
discusiones a medida que avanzamos para recibir sus comentarios. La mayoría de las veces estos
Ser sesiones individuales en las que compartimos en qué estamos trabajando y discutimos.
ellos contigo.

Las primeras sesiones tendrán lugar este miércoles. Regístrese aquí si
tú estás interesado:
https://calendly.com/stevencl/visual-studio-code-tabs-design-discussion/04-06-2016

-
Estás recibiendo esto porque te mencionaron.

Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205239769

Esperamos escuchar sus comentarios sobre los nuevos diseños que estamos explorando relacionados con este problema. Si está interesado, regístrese a través del enlace en el comentario de @stevencl arriba.

3 y 4 a. M. Solamente? ¿No en otras ocasiones? No puedo llegar a las 3/4 am PST un miércoles.

El lunes 4 de abril de 2016 a las 8:14 a. M. Brad Gashler [email protected]
escribió:

Esperamos escuchar sus comentarios sobre los nuevos diseños que estamos explorando.
relacionados con este tema. Si está interesado, regístrese a través del enlace en
¡El comentario de Steven arriba!

-
Estás recibiendo esto porque te mencionaron.

Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205342923

Sería bueno si tuviera el tiempo de acuerdo con PST, muchos (incluido yo) pueden participar

{Móvil}

El lunes 4 de abril de 2016 a las 8:50 a. M. -0700, "Glenn Block" [email protected] escribió:

3 y 4 a. M. Solamente? ¿No en otras ocasiones? No puedo llegar a las 3/4 am PST un miércoles.

El lunes 4 de abril de 2016 a las 8:14 a. M. Brad Gashler [email protected]

escribió:

Esperamos escuchar sus comentarios sobre los nuevos diseños que estamos explorando.

relacionados con este tema. Si está interesado, regístrese a través del enlace en

¡El comentario de Steven arriba!

-

Estás recibiendo esto porque te mencionaron.

Responda a este correo electrónico directamente o véalo en GitHub

https://github.com/Microsoft/vscode/issues/224#issuecomment -205342923

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente o véalo en GitHub

Sí por favor. Definitivamente me gustaría ser parte de la conversación.

Lo siento, sé que estos tiempos no son convenientes para todos. En el futuro, buscaremos formas de programar sesiones en diferentes zonas horarias, ya que planeamos realizarlas de forma regular.

¿Por qué no programar uno adicional esta semana a una hora diferente? Esto es un
tema candente con mucho interés.

El lunes, 4 de abril de 2016 a las 9:44 a. M. Steven Clarke [email protected]
escribió:

Lo siento, sé que estos tiempos no son convenientes para todos. En el futuro nosotros
buscará formas de programar sesiones en diferentes zonas horarias a medida que
planee mantenerlos regularmente.

-
Estás recibiendo esto porque te mencionaron.

Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205386984

Para que lo sepas, las franjas horarias que ves son solo las que aún están disponibles. Tenía espacios abiertos más tarde en el día, pero se tomaron bastante rápido.

Como dije, intentaremos programar sesiones en diferentes zonas horarias en el futuro.

Gracias por el interés.

Ya veo, bueno, supongo que se llenaron instantáneamente (lo cual es bueno)
El lunes 4 de abril de 2016 a las 11:30 a. M. Steven Clarke [email protected]
escribió:

Para que lo sepas, las franjas horarias que ves son solo las que están
aun disponible. Tenía espacios abiertos más tarde en el día, pero esos fueron ocupados
bastante rápido.

Como dije, intentaremos programar sesiones en diferentes zonas horarias en
el futuro.

Gracias por el interés.

-
Estás recibiendo esto porque te mencionaron.

Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205436942

¿Puedes grabar las sesiones?

El lunes 4 de abril de 2016 a las 11:32 a.m. Glenn Block glenn. [email protected] escribió:

Ya veo, bueno, supongo que se llenaron instantáneamente (lo cual es bueno)
El lunes 4 de abril de 2016 a las 11:30 a. M. Steven Clarke [email protected]
escribió:

Para que lo sepas, las franjas horarias que ves son solo las que están
aun disponible. Tenía espacios abiertos más tarde en el día, pero esos fueron ocupados
bastante rápido.

Como dije, intentaremos programar sesiones en diferentes zonas horarias en
el futuro.

Gracias por el interés.

-
Estás recibiendo esto porque te mencionaron.

Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205436942

Ojalá hubiera visto esto antes para poder haberme registrado. Por lo que vale, espero que nunca implemente pestañas. He progresado de vim a TextMate a Sublime a Atom y ahora a VS Code (con muchos IDE en el camino), por lo que he tenido MUCHA experiencia con pestañas. Para mí son una muleta que la gente usa y nunca pasa. Administrar muchas pestañas abiertas en un proyecto grande es un ejercicio de frustración que agrega una tarea más que no necesito. Olvídese de cerrar algunos y rápidamente se vuelve inútil. Para aquellos pocos de ustedes que tienen la disciplina para nunca encontrar esto, felicitaciones. Pero, ¿por qué gastar la energía mental en una tarea innecesaria?

Más importante aún, creo que las pestañas hacen que la gente piense en términos de ARCHIVOS, cuando (para la mayoría del desarrollo de código) deberían centrarse en funciones, clases, espacios de nombres, símbolos. Los archivos son un detalle de implementación en la mayoría de los casos que no deberían dominar su navegación. Creo que VS Code tiene una oportunidad real de ofrecer algo nuevo y mejor.

Me doy cuenta de que esta es solo MI preferencia y comprendo por qué mucha gente pide que las pestañas sean opcionales. Esto puede parecer un compromiso razonable, pero sería difícil admitir bien dos flujos de trabajo de navegación diferentes. Simplemente intente desactivar el complemento de pestañas en Atom y vea cuántas cosas no funcionan o funcionan mal porque los desarrolladores esperan que las pestañas estén allí. Entonces, por mis propias razones egoístas, quiero que los desarrolladores de VS Code se centren en la navegación que no está basada en pestañas (o incluso en archivos).

Ídem @indiejames

Si implementa pestañas, admita varias filas para muchos archivos. Odio tener una barra de desplazamiento en mi barra de pestañas. Mi implementación de pestañas favorita es Tabs Studio . Vea también cómo los archivos con el mismo nombre de base se pueden agrupar automáticamente.

Mi flujo de trabajo Abro pestañas mientras trabajo en Sublime según sea necesario. No dejo toneladas de pestañas abiertas y, a menudo, uso "cerrar todo" para que las cosas vuelvan a estar en cero.

He estado desarrollando más de 30 años en múltiples IDE y editores de texto. No veo las pestañas como una muleta, son una herramienta organizativa útil. Sí, pueden salirse de control si tienes un montón de pestañas, pero yo no ...

En términos de pestañas que se inclinan hacia el enfoque en archivos y demás, el código vive en archivos y los archivos se utilizan para la organización, y el código VS se basa en la administración de carpetas y archivos de código.

Entiendo totalmente que algunos pueden preferir no tener pestañas y no estoy diciendo que me deshaga de lo que está allí, pero tener un flujo de trabajo de pestañas compatible sería bueno.
El martes, 5 de abril de 2016 a las 7:32 a.m., el error [email protected] escribió:

Si implementa pestañas, admita varias filas para muchos archivos. odio
tener una barra de desplazamiento en mi barra de pestañas. Mi implementación de pestañas favorita es Tabs
Estudio https://tabsstudio.com/.

-
Estás recibiendo esto porque te mencionaron.

Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205834354

"Facilita que los usuarios hagan un mal uso del producto" es una razón terrible para no admitir una función. La herramienta está ahí para _facilitar_ los flujos de trabajo, no para _dictarlos_. Si un usuario no puede encontrar un flujo de trabajo cómodo, es más probable que elija otra herramienta donde pueda, en lugar de adaptarse a un paradigma desconocido.

Actualmente estoy trabajando en algunos archivos estrechamente relacionados, yendo y viniendo entre ellos. Cada vez que necesito cambiar, debo elegir de la barra lateral o de un menú desplegable, lo que demora de 3 a 4 veces más que una pestaña.

@indiejames

pero sería difícil admitir bien dos flujos de trabajo de navegación diferentes. Simplemente intente desactivar el complemento de pestañas en Atom y vea cómo las cosas no funcionan o funcionan mal porque los desarrolladores esperan que las pestañas estén allí. Entonces, por mis propias razones egoístas, quiero que los desarrolladores de VS Code se centren en la navegación que no está basada en pestañas (o incluso en archivos).

No es demasiado difícil admitir dos flujos de trabajo de navegación diferentes o incluso más de dos, ¡lo realmente difícil es conseguir el diseño correcto!

Si realmente desea admitir pestañas y archivos de trabajo u otro flujo de trabajo, debe retroceder unos pasos, alejar y rediseñar la navegación desde cero, haciendo de los flujos de trabajo una estrategia entre la que las personas pueden elegir.

Crear una extensión solo para tener pestañas en el editor sin considerar los casos de uso y cómo las personas están trabajando con pestañas u otro flujo de trabajo es simplemente pasar por alto la causa, lo que no agrega ningún beneficio real y, por lo tanto, lo más probable es que sea un fracaso.

Hay una diferencia entre la navegación de código y la navegación de archivos, cuando codifica seguramente necesita
piense en símbolos en lugar de archivos, pero el código vive en archivos y, a veces, también debe lidiar con él, por ejemplo, no abro muchas pestañas, pero cuando estoy trabajando en varios proyectos, generalmente tengo un archivo por proyecto abierto que está relacionado, uso las teclas de acceso rápido en gran medida, pero debido a que las pestañas siempre están en la parte superior, y cuando miro al editor, siempre están ahí, probablemente sea psicológico, pero solo me ayuda a concentrarme.

Tu experiencia con las pestañas es lamentable y no subestimo tu experiencia en absoluto, no sé cómo trabajas, pero a muchos de nosotros nos gusta y lo usamos con gran éxito.

No creo que una experiencia sea mejor que la otra, pero tener experiencias diferentes o incluso híbridas puede ser útil y los editores deben respetar mi experiencia y no ir en contra.

Sería muy útil para nosotros que no podemos asistir a las reuniones debido a otros compromisos poder dar su opinión.
Tal vez, una vez que las reuniones terminen el primer día, publique un video de una reunión (con el permiso de todos los involucrados) que otros puedan ver y comentar dentro del tiempo restante para las reuniones.

Obviamente, no puede ser un período largo, pero más comentarios no pueden hacer daño si se agregan algunos puntos de vista diferentes.

Realmente espero que algunos desarrolladores de Python y desarrolladores de c / c ++ estén en la reunión ya que su flujo de trabajo es diferente al flujo de trabajo de un desarrollador de JavaScript

¡Gracias Steven por tomarse el tiempo de hablar conmigo!
Este compromiso con la comunidad es realmente alentador y estoy disfrutando
siguiendo el desarrollo de vscode!

El 6 de abril de 2016 a las 19:41, Michael Wallace Louwrens < [email protected]

escribió:

Sería muy útil para nosotros que no podemos asistir a las reuniones debido a otras
compromisos para poder dar retroalimentación.
Quizás, una vez que las reuniones terminen el primer día, publique un video de un
reunión (con el permiso de todos los involucrados) que otros pueden ver y comentar
dentro del tiempo restante para las reuniones?

Obviamente, no puede ser un período largo, pero más comentarios no pueden hacer daño con
con suerte se agregaron algunos puntos de vista diferentes.

Realmente espero que algunos desarrolladores de Python y desarrolladores de c / c ++ estén en la reunión como
su flujo de trabajo es diferente al flujo de trabajo de un desarrollador de JavaScript

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -206261939

Gracias @TurkeyMan , es genial charlar contigo hoy.

Para todos los demás que no hayan podido participar, los realizaremos de forma regular, por lo que habrá oportunidades de participar en una fecha posterior.

Las conversaciones que estamos teniendo esta semana son todas conversaciones 1: 1 durante las cuales discutimos los detalles de los problemas que cada individuo ha experimentado. Esto nos permite obtener una comprensión más profunda de los problemas que debemos resolver.

En las próximas semanas, cuando revisaremos las maquetas de diseño, buscaremos formas de tener discusiones grupales, así como discusiones 1: 1. También veremos cómo podemos grabar y publicar videos de reuniones posteriormente.

@stevencl es posible publicar un resumen de las sesiones (o mejor aún, grabaciones) para aquellos de nosotros que no podemos participar, pero todavía estamos interesados ​​en darnos su opinión.

+1
El miércoles 6 de abril de 2016 a las 7:36 a. M. Peter Petrov [email protected]
escribió:

@stevencl https://github.com/stevencl ¿ es posible publicar un resumen?
de las sesiones (o mejor aún, grabaciones) para aquellos de nosotros que no podemos
para participar, pero todavía están interesados ​​en proporcionar comentarios.

-
Estás recibiendo esto porque te mencionaron.

Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -206405009

Me gustaría contribuir a mis expectativas de navegación de archivos dentro de un editor de código. He estado tratando de acostumbrarme a VScode durante semanas y sigo volviendo a Sublime. Esto es lo que espero:

1. navegación sin mouse
2. capacidad de navegar hacia adelante y hacia atrás dentro del conjunto de archivos abiertos
3. cerrar archivos fácilmente

Hasta ahora encontré que VScode desafortunadamente me fallaba en los tres. El espacio de trabajo no es intuitivo porque cuando cierro un archivo, no se cierra realmente, simplemente ya no se puede editar. Cerrar el archivo es una actividad mental de eliminarlo del conjunto de archivos con los que estoy trabajando.

En VScode, cuando navego dentro de los archivos que se abren _en mi cabeza_ sigo encontrando "basura" que pensé que antes se había tirado. Esto distrae excepcionalmente y termino teniendo 20 archivos abiertos en el espacio de trabajo y, finalmente, ya no puedo hacer un seguimiento de ellos y simplemente cerrarlos todos.

No puedo usar el teclado para cambiar rápidamente entre archivos abiertos, que _en mi cabeza_ forman una lista vinculada. El orden en el que los abro es tan significativo como el orden en el que los cierro. Ctrl + Tabulador me parece inútil porque tengo que leer los nombres de los archivos uno por uno en esa lista y luego averiguar a cuál tabular. Puedo pasar mucho más rápido de 5 a 8 archivos abiertos al correcto simplemente reconociendo el contenido mientras está parpadeando o simplemente sabiendo en qué parte de la "lista" se encuentra el archivo deseado.

Espero que tenga algún sentido. Intento optimizar mi flujo de trabajo tanto como sea posible, uso el teclado y evito el mouse porque ralentiza enormemente todo. Lucho con esto en VScode más que antes en cualquier otro editor (textmate, vim, sublime, flash, eclipse, etc.)

Solo para reiterar, las grabaciones de las reuniones que ocurran esta semana no estarán disponibles, ya que cada reunión es una conversación 1: 1 en la que cada persona discute los detalles de cómo funcionan y los problemas específicos que tienen con VS Code. Durante estas conversaciones no entraremos en detalles sobre ningún diseño.

Sin embargo, en las próximas semanas buscaremos oportunidades para grabar y hacer disponibles reuniones en las que discutiremos diseños para mejorar la gestión de documentos en VS Code. Busque otra invitación mía en algún momento de la próxima semana para participar en la próxima ronda de discusiones de diseño.

Gracias por todos los comentarios y los detalles de cómo VS Code funciona o no para usted.

Solo porque nadie parece haberlo mencionado y sospecho que no estoy solo en esto: para mí, las pestañas en un editor tienen que ver con la memoria espacial, es decir, ¿dónde estoy y dónde están las cosas a mi alrededor?

Vivimos en un mundo físico. Hemos evolucionado para comprender y hacer intuiciones sobre el espacio que nos rodea y lo hacemos sin pensar. Esta es la razón por la que podemos escribir sin mirar el teclado: "simplemente sabemos" dónde están las teclas y podemos escribir a gran velocidad. Con las pestañas, nuestro software de edición predeterminado con el que nacimos puede activarse y sabemos "dónde" se encuentra un archivo en la pantalla y podemos concentrarnos en él sin pensar porque es un instinto que usamos todos los días. "Dejo un archivo" por así decirlo a través de una pestaña en el editor, y puedo recordar "dónde lo dejé" exactamente de la misma manera que puedo recordar dónde coloco el control remoto de mi televisor la próxima vez que necesite cambiar de canal ( suponiendo que ya tuviera un televisor)

Para mí, un historial de archivos ordenado en el tiempo va totalmente en contra de esta comprensión intuitiva del espacio. Si sé que "main.java" o la tecla T de mi teclado está en una posición determinada, no quiero que se mueva a menos que la mueva física y deliberadamente. Si se mueve por sí solo, necesito detenerme, pensar y encontrarlo. ¡Imagínese un control remoto de TV con ruedas que se mueva solo por su casa, o un teclado que reorganice las teclas en función de la fecha reciente en que utilizó cada letra! ¡Sería un caos! :-)

Realmente me gusta VSCode, pero personalmente estoy frustrado y ralentizado por la falta de pestañas. Sigan con el buen trabajo - ¡Espero ver lo que se les ocurra!

@ mate1
Lo que estás describiendo es exactamente lo que hace que las pestañas sean tan limitantes (para mí). Las pestañas son una metáfora de las pestañas físicas colocadas en archivos en un archivador físico y tienen las mismas limitaciones. Prefiero tener un archivador automatizado en el que pueda escribir algunas teclas y saltar a mi información que uno físico donde tengo que ordenar las cosas yo mismo y administrar el espacio limitado para las pestañas visibles.

Tengo curiosidad: ¿navega por las pestañas con el mouse / trackpad o usando combinaciones de teclas en otros editores?
Si usa atajos de teclado exclusivamente, entonces tal vez tenga un flujo de trabajo de pestañas que no conozco
de y me encantaría verlo. Sospecho, sin embargo, que mucha gente usa el mouse / trackpad, sin darse cuenta de cuán improductivo es ese cambio de contexto y cuánto los está ralentizando para quitar las manos de las teclas. Es fácil de aprender y fácil de entender, pero menos potente / productivo que usar combinaciones de teclas. Si se encuentra "buscando una pestaña" con el mouse, puede ser intuitivo y puede aprovechar su sentido espacial, pero lo está frenando. No tanto en el tiempo perdido por el movimiento físico, sino en el cambio de contexto mismo.

Me doy cuenta de que estas son solo mis opiniones y la mayoría de la gente no está de acuerdo con ellas, pero es Visual Studio _Code_. Para codificadores / desarrolladores. Y los desarrolladores se dieron cuenta hace mucho tiempo de que shell> gui para la mayoría (no todas) las cosas, y que las metáforas de escritorio, aunque fáciles de aprender, son bastante limitantes.

Entonces, ¿es sólo posible que algunos de ustedes que dicen "No puedo vivir sin pestañas" no hayan explorado otros flujos de trabajo? Si es así, ¿no vale la pena intentarlo si la recompensa aumentaría su productividad?

Para aquellos de ustedes que han intentado trabajar sin pestañas y no pueden adaptarse o sinceramente sienten que las pestañas los hacen más productivos, puedo aceptar que esto es solo un desacuerdo honesto. Pero para aquellos que defienden metáforas físicas porque "¡han trabajado durante 30 años!" Yo preguntaría si realmente necesitamos _otro_ TextMate / Sublime / Atom? ¿No deberíamos intentar mover el sobre?

No tengo ninguna duda de que estoy en minoría aquí (pero eso no me equivoca), así que este es el último comentario que voy a hacer. Siéntete libre de apilar :)

Decidió revisar VS Code para ver si podría ser un reemplazo gratuito de Sublime, pero sin documentos con pestañas, no es un comienzo. Ser capaz de configurar VS Code en una sola instancia, tener varios documentos abiertos y cambiar fácilmente entre ellos es un requisito básico de cualquier editor de texto. Mantener Explorer abierto es una solución alternativa, pero no es antinatural dejar pestañas en lugar de pestañas superiores como en VS, navegadores, Sublime, etc. Ctrl-Tab tiene varios problemas, uno es tener que mirar el teclado y mover una mano (para algo que no sea el mouse), la otra es que no es intuitivo. Cualquiera que sugiera que un editor sin pestañas es algo más que BloatedNotepad claramente nunca ha realizado una edición seria de varios documentos, como se requiere cuando el depurador recorre algo que tenía más de 1 archivo como entrada del compilador.

@indiejames
Para mí, las pestañas no se tratan de productividad. Se trata de cognición.

Personalmente, nunca he descubierto que la velocidad de escritura sin procesar haya sido el factor limitante de mi productividad. La programación requiere pensamiento y consideración: unos pocos clics no son un problema en el gran esquema de las cosas para mí, considerando cuánto tiempo pasamos _pensando_.

@indiejames Uso la @ matt1 : el hecho de que ctrl + tab opera en el orden de uso más reciente. No recuerdo necesariamente qué archivo miré por último y penúltimo, pero es muy fácil para mí ver / recordar en qué orden los abrí / los ordené. Sublime Text también tiene por defecto ctrl + (shift +) tab en MRU orden; Siempre lo cambio, ya que tiene comandos tanto para MRU como para orden visible.

Recuerdo que en el día en que algún navegador web (¿era Opera antes de parpadear tal vez?) También usaba MRU para ctrl + tab de forma predeterminada, probablemente pensando que dado que los sistemas operativos lo hacen para las aplicaciones, un navegador también podría hacerlo; Sin embargo, me pareció terriblemente poco intuitivo y tuve que prestar más atención para encontrar a qué quería volver ... lo cual, adivina qué, hace que el proceso sea más lento.

El argumento de usar la apertura rápida exclusivamente también funciona tan bien en Sublime Text con pestañas como en VS Code con archivos de trabajo. Las pestañas no prohíben ese flujo de trabajo en absoluto.

Para aquellos que prefieren el enfoque actual de Archivos de trabajo en VS Code, ¿cuántos de ustedes realmente prefieren hacer clic en los archivos dentro de la lista de Archivos de trabajo en lugar de los siguientes flujos de trabajo?

• usando Ctrl + E / ⌘ + E para abrir rápidamente archivos recientes.
• usando Ctrl + Tab para cambiar archivos recientes

Por cierto, para aquellos que prefieren las pestañas , sus comentarios han sido muy útiles mientras investigamos cómo agregarlos al producto. ¡Muchas gracias por seguir compartiendo!

@ bgashler1
Prefiero los atajos de teclado. No para que pueda ser el mecanógrafo más rápido, sino porque los encuentro menos distraídos que mover el mouse / trackpad.

Creo que lo que muchos de los "archivos de trabajo y sin pestañas NUNCA" se están perdiendo es la _ forma_ en la que muchos de nosotros usamos pestañas. Por ejemplo, cuando trabajo en una aplicación MVC (web, móvil o de escritorio) tiendo a tener pestañas en uno o más paneles verticales (que VSCode también necesita) en un orden específico: archivo de modelo, archivo de vista, archivo de controlador . Entonces, una configuración que tengo abierta con frecuencia se ve así:

Panel izquierdo

Archivo Modelo 1 (pestaña) | Ver 1 archivo (pestaña) | Controlador 1 Archivo (pestaña)

Panel derecho

Archivo Modelo 2 (pestaña) | Ver 2 Archivo (pestaña) | Controlador 2 Archivo (pestaña)

Esta configuración me permite seleccionar rápidamente los archivos de modelo para ambos componentes en los que estoy trabajando para compararlos o ver archivos cuando tengo mi sombrero UI / UX. Esto absolutamente NO PUEDE lograrse de manera eficiente con archivos de trabajo, especialmente si tiene otros archivos abiertos también (es decir, CSS, scripts de base de datos, etc.). Hago un montón de UI / UX y esta es, con mucho, una práctica común. Si fuera estrictamente un desarrollador de backend de Java o un DBA, entonces no, esto no sería un requisito. Pero para la gran mayoría de nosotros, desarrolladores web y móviles de pila completa, no tener pestañas (y paneles verticales / horizontales con pestañas) es un obstáculo extremo. Si bien estoy cumpliendo con VSCode a corto plazo, tengo serias reservas para mantenerlo debido a esta capacidad que falta. Nadie puede convencernos de que las pestañas son inútiles y una lista de archivos de trabajo no es una innovación (Adobe Brackets también tiene una lista de archivos de trabajo y existe desde 2012).

Nuevamente, este no es un problema de todo o nada. Simplemente estamos solicitando la misma capacidad que existe en otros editores como una opción, incluso si esa capacidad está desactivada de forma predeterminada. Si VSCode implementara pestañas / paneles de ventana exactamente como lo hace Atom, resolvería el 99,99% de nuestro agarre relacionado con pestañas. Sé que no es una tarea trivial de implementar, sin embargo, creo que muchos de nosotros estaríamos satisfechos esperando un poco más (meses, no años) para que esta función se realice correctamente en lugar de permanecer en el trabajo pendiente.

Solo mis 2 ¢ ...

Si bien ya le he comunicado la mayor parte de esto a @ bgashler1 , escribiré un poco aquí explicando el comportamiento ideal para mí.

1. Las combinaciones de teclas deben cerrar los archivos de trabajo, eliminándolos de la lista de archivos de trabajo y de la pila MRU (utilizada más recientemente). Tengo las siguientes combinaciones de teclas para lograr esto:

json { "key": "ctrl+shift+w", "command": "workbench.files.action.closeAllFiles" }, { "key": "ctrl+w", "command": "workbench.files.action.closeFile" },

1. Los archivos en el editor deben estar "apilados", de modo que cuando cierre un archivo, se muestre el último archivo en la pila MRU.
2. ctrl + shift + t debería restaurar la pestaña cerrada más recientemente. Esta combinación de teclas entra en conflicto con workbench.action.tasks.test en vscode, pero es una tecla de acceso rápido muy estándar en entornos con pestañas. Creé una solicitud de función para el comando aquí https://github.com/Microsoft/vscode/issues/3989
3. ctrl + tab y ctrl + shift + tab solo deben rotar a través de archivos en la lista de "archivos de trabajo", no archivos que fueron "previsualizados" (un solo clic en el explorador y luego navegar fuera).
4. Quiero que mis archivos de trabajo estén distribuidos en la parte superior del editor. Las razones de esto son:
   
   
   
   • Quiero poder ver mis archivos de trabajo visualmente, independientemente de la barra lateral que haya abierto. Relacionado: https://github.com/Microsoft/vscode/issues/3360
   
   
   • Durante las casi 2 décadas que he estado programando, he estado buscando por encima del editor para mis archivos de trabajo. Es un hábito difícil de romper.
   
   

@bpasero

Por cierto, para aquellos que prefieren las pestañas, sus comentarios han sido muy útiles mientras investigamos cómo agregarlos al producto. ¡Muchas gracias por seguir compartiendo!

Utilizo mucho Ctrl + Tab en VSCode, pero creo que la experiencia en Visual Studio es mucho mejor porque, además de los archivos, también puedo navegar a otras partes de la interfaz de usuario, lo uso para navegar al Administrador de consola de paquetes, Explorador de soluciones, etc.

@Tyriar ¡ Grandes puntos!

[¡Advertencia de filosofía!]

¿Por qué ctrl+tab es mucho más útil que el concepto de 'archivos de trabajo', tal como está? Ésta es la cuestión crucial. Personalmente, creo que hay dos cuestiones en juego.

En primer lugar, ctrl+tab es un atajo de teclado y los atajos de teclado están asociados inconscientemente con el signo de intercalación: el usuario espera que ctrl+tab cambie el archivo en el editor actual, donde se coloca actualmente el intercalado, y eso es precisamente lo que hace. Esto es diferente a los 'archivos de trabajo' o al navegador que no están asociados con un editor en particular (están alejados horizontalmente de todos los editores menos uno y asociados con el editor _más reciente_) y generalmente se usan con el mouse. Incluso si los usa con el teclado, se ha alejado de su símbolo de intercalación cuando selecciona un archivo.

En segundo lugar, ctrl+tab muestra _todos_ los archivos que ha visto recientemente, en orden cronológico inverso. 'Archivos de trabajo' le muestra solo aquellos en los que hizo doble clic o realizó cambios y en el orden en que se molestó en abrirlos. Los criterios y el orden son arbitrarios y no tienen nada que ver con la forma en que piensan los programadores: saltar de un lado a otro entre la persona que llama y la función, la clase y el consumidor.

(Opiniones. El kilometraje puede variar).

EDITAR: Mi punto es este: comprender por qué una función funciona y otra no ayudará a corregir la función o diseñar una mejor. Tal como está, los archivos de trabajo no lo hacen.

@Tyriar : Personalmente, realmente odio el hecho de que los archivos de un solo clic no se muestren en Working Files. Quiero TODOS los archivos que he visto en mi pila utilizada recientemente, incluso los externos de solo lectura. Los abrí por una razón. Si termino con ellos, pronto desaparecerán de la lista. En el mejor de los casos, debería haber una opción para hacer que un solo clic y un doble clic se comporten de la misma manera.

Descubrí cómo obtener la mayor parte de lo que me faltaba de sublime en el contexto de este problema:

[
  { "key": "cmd+w", "command": "workbench.files.action.closeFile" },
  { "key": "cmd+shift+]", "command": "workbench.files.action.openNextWorkingFile" },
  { "key": "cmd+shift+[", "command": "workbench.files.action.openPreviousWorkingFile" }
]

@stephenmartindale No estoy seguro de si alguien ha realizado una solicitud de función para deshabilitar los 'archivos de vista previa' todavía.

@stephenmartindale , estamos buscando una forma de fijar "archivos de vista previa" para que permanezcan abiertos, incluidos los archivos de solo lectura.

Nos gustaría mantener "archivos de vista previa", porque muchas veces las personas no saben qué archivo están buscando hasta que han abierto varios (lo que puede resultar en una cantidad indeseable de archivos abiertos que son irrelevantes).

Realmente amo el flujo de Sublime aquí. Con un solo clic, salta al archivo,
haga doble clic en él permanece abierto.
El sábado 9 de abril de 2016 a las 11:49 a. M. Brad Gashler [email protected]
escribió:

@stephenmartindale https://github.com/stephenmartindale estamos buscando
en una forma de fijar "archivos de vista previa" para que permanezcan abiertos.

Nos gustaría mantener "archivos de vista previa", porque muchas veces la gente no sabe
qué archivo están buscando hasta que hayan abierto varios (que pueden
resultar en una cantidad indeseable de desorden de archivos abiertos).

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -207830702

@Tyriar , @ bgashler1 , @stevencl Creo que es mejor tener dos publicaciones nuevas para pestañas y archivos de trabajo para recopilar comentarios.

Solo mi opinión, pero creo que sería mucho mejor que discutir ambas características aquí, esta es lo suficientemente larga. :)

👎 Por favor, no haga esto, o al menos hágalo opcional. La interfaz de usuario limpia y sin pestañas es una de las cosas que más me gustan del código VS.

@tobico No tiene que ser todo o nada ... ya sabes, en lo que a mí respecta, quiero que tanto los archivos de trabajo como las pestañas sean opcionales y, sin embargo, integrales para las personas que desean tener esa experiencia.

Me gustaría segundo que Ctrl + W debería cerrar no solo el editor actual, sino el archivo de trabajo abierto correspondiente. Para mí, ese es el mayor inconveniente de la implementación actual. Eso y el hecho de que Ctrl + Tab enumera todos los archivos recientes, no solo los que están en los archivos de trabajo. Pensándolo bien, una tercera advertencia sería que un solo clic no abre un archivo como un archivo de trabajo, pero editarlo sí.

+1

@csholmq , puede hacerlo ahora, consulte las combinaciones de teclas personalizadas en https://github.com/Microsoft/vscode/issues/224#issuecomment -207507479

@Tyriar Eso aborda casi todas mis advertencias. ¡Gracias!

En 3 minutos, dejé de usar VS Code y volví a Atom. Sin pestañas, no vamos. Lo siento, mi flujo de trabajo se me ha perforado. Apostaría a que una encuesta rápida hace 4 años habría obtenido su respuesta de interfaz de usuario mucho más rápido. Pero deja demasiado la arrogancia de Microsoft para arreglar algo que no está roto.

@zunama no nos hemos olvidado de los usuarios que quieren pestañas y una gestión de documentos mejorada. Ahora que estamos en la versión 1.0, una de nuestras principales prioridades es abordar estas preocupaciones. Pronto llegarán cosas increíbles a VS Code.

Como desarrollador web, las pestañas son importantes para mí. A diferencia de los programadores de escritorio (que se centran principalmente en un solo archivo a la vez), siempre cambiamos entre ventanas y usamos el mouse al mismo tiempo (por ejemplo, cortamos una imagen de Photoshop y luego volvemos al editor de inmediato. O depuramos en los navegadores y vamos volver a otro archivo para arreglar). Con las pestañas, podemos navegar hasta el archivo de destino rápidamente. Con los atajos, son 2 pasos más. Con la barra lateral "archivos de trabajo", hay menos espacio en el área de código principal (como ponemos Photoshop y Editor o navegadores uno al lado del otro). Height en el editor son menos necesarios. Siempre puedes memorizar algunas líneas más, ¿no?

Además, las pestañas superiores son mejores para los ojos humanos. Puede escanear el título de la pestaña superior y el código de área principal al mismo tiempo. Pero no puede leer la izquierda working files con el código principal juntos. Inténtalo tú mismo. Además, las pestañas son más anchas, mejores para el movimiento del mouse. (Incluso si no te enfocas en eso, es más predecible)

+1/0

+1

Solo mi opinión personal, pero por favor, deja de hacer publicaciones -1, +1 ... Quiero decir, además de sugerir que te gusta o no te gusta esta función, algo para lo que se puede usar reacción / emoticón no dice nada sobre tu experiencia y por lo tanto Si ya está escribiendo una publicación, ¡asegúrese de que sea útil! ¡Estoy seguro de que tiene su propio conservante en las cosas y cómo le gustaría que funcionen! de lo contrario, usa emoticonos.

Meta:
@eyalsk En este caso, la discusión está en curso, por lo que de hecho parece redundante. Pero para los problemas en los que desea ganar terreno, ¿es realmente el equivalente "Agregue su reacción"? ¿No solo alerta a la operación de comentarios en lugar de indicar que el tema es un tema candente? Es decir, ¿alerta a los desarrolladores que están etiquetados con el problema o configuran el problema como modificado?

@csholmq No sé si te entiendo correctamente, pero no me refería a la reacción / emoticonos, sino a las publicaciones que no contienen nada más que +1, -1 en ellas, no agrega ningún valor, una entrada más significativa podría se han escrito en lugar de escribir una publicación con +1, -1 ... solo mi opinión, modificaré y enfatizaré esto en mi publicación.

@zunama No es arrogancia intentar buscar una alternativa mejor. "No roto" no es un argumento válido contra la búsqueda de cosas nuevas. Es más o menos un argumento a favor (¿tal vez hay algo mejor?). Aunque noté en esta discusión que si VS Code quiere ser utilizado completamente hoy , debería apuntar a complacer a la base de usuarios actual de la 'vieja mentalidad' e innovar más tarde. Porque la gente no es muy buena esperando y te ahorra tiempo tratar de discutir por qué esto o aquello es mejor.

De vuelta a tu comentario: si quieres hacer algo bien, no tardes 3 minutos y lo dejes. Enumera su punto de vista sobre la crítica útil y busca posibles mejoras. Un punto de vista de 3 minutos es inútil y peligroso para su diseño porque está sesgado.

Una encuesta no funciona cuando quieres innovar. Ejemplo:

¿Cuál de estos estilos de nagivación sería el más productivo para ti?

• Alguna cosa. (Prueba algo nuevo que podría ser mejor)
• Pestañas. (Buen estilo de trabajo antiguo que aprendiste a amar).

Por supuesto que las pestañas ganarían. Pero posiblemente la otra idea podría allanar el camino hacia una nueva interfaz de usuario de navegación estándar.

Para ser honesto, una de las características definitorias de VS Code para mí fue la ausencia de pestañas. ¡Ni siquiera me di cuenta (al principio) de que faltaban! Fue un punto de vista muy interesante.

Siempre que utilizo pestañas, siempre hacen ruido y son imposibles de encontrar. Cuando no puedo ver un determinado archivo inmediatamente en la lista de pestañas, mi primera reacción es volver a abrirlo. . . y luego descubriría que ya estaba abierto. Por supuesto, el orden de las pestañas se estropea seriamente en el proceso. Esto es lo que me pasa en Visual Studio 2015.

En el mundo en el que todo sigue igual, es refrescante tener una identidad.

PD. Sin embargo, no estoy muy impresionado con la sección de archivos de trabajo. Lo uso principalmente para ver rápidamente qué archivos requieren guardar.

PSS. Una idea: si hay pestañas en el código vs un día, ¿quizás sea mejor limitar el número máximo de pestañas abiertas, es decir, cerrar las pestañas más antiguas automáticamente cuando se abran nuevas?

@RussBaz No creo que limitar el número de pestañas sea una buena idea porque ese número puede cambiar de un usuario a otro, pero tal vez esta pueda ser una opción como esta:

tabs.autoClose = "not-visible", "off", "time", x donde x es un número

Esa es una idea extraña. Si me gustan 16 pestañas y a ti te gustan 4, es simple. ¡USTED usa 4 pestañas y yo usaré 16! Por qué decir que tu camino es mejor que el mío, o viceversa. ¿De qué se trata esto de todos modos? Incluso la conversación sobre pestañas no tiene sentido siempre que las pestañas estén activadas / desactivadas en Opciones / Preferencias. Aquellos que no quieren pestañas, ¡GENIAL! Aquellos que los quieran, marquen la pequeña casilla de verificación. Realmente, no tiene por qué ser que tu camino sea mejor que el mío, o que yo sepa mejor que tú.
+1
;)

Ejemplo de caso de uso: actualmente cambio entre 6 pestañas constantemente en atom.

Eso aumenta a alrededor de 10 cuando necesito trabajar en secciones más profundas. ¡Los uso todos! Entonces cerrar y reabrir sería un dolor. Podría tener archivos masivos en su lugar, pero sería mucho más doloroso lidiar con eso, ya que aumentaría a 6k líneas en un archivo si incluyo cada parte de un módulo en un solo archivo.

@Mediendo estoy de acuerdo y en desacuerdo contigo. Hay algunas cosas que deben innovarse, pero primero hay que preguntarse qué pasa con el flujo de trabajo que podemos mejorar eliminando pestañas. Bueno, para mí, cada editor que uso para el desarrollo tiene una interfaz de pestaña porque es común que un desarrollador trabaje entre 5 y 10 archivos a la vez sin recordar el nombre exacto de los archivos ni el orden en que se abren. Tengo que preguntar, ¿cómo lo mejoró esta nueva interfaz? ¿Cómo es innovador? Primero pregunte cómo lo usan, luego pregunte cómo puedo mejorarlo.

En cuanto al problema de los tres minutos, voy a suponer que Code no es muy diferente de Sublime (mi opción preferida) o Atom (lo que estoy probando), pero si desde el principio me cuesta trabajar con él o mostrar alguien de manera eficiente lo que necesita hacer entre archivos para que algo funcione, luego usaré algo que funcione mejor para mis necesidades ahora y buscaré en Code algunas versiones en el futuro cuando esté listo. No se trata de una mentalidad de la "vieja escuela", sino de la eficiencia con mi trabajo.

Pedir a aquellos de nosotros que preferimos las pestañas que cambiemos a ninguna pestaña es tan bueno como
pidiendo a aquellos que prefieren no tener pestañas que cambien a pestañas. Ambos no queremos
cambie al otro método.

¿Podemos detenernos ahora con el tipo de 'Mac vs Windows', 'Android vs IPhone'?
debates sobre qué camino es mejor: ¿'Pestañas vs Sin pestañas'? Ambos son buenos
y diferentes personas tienen sus propias preferencias.

Creo que la mejor solución es agregar pestañas como preferencia que se pueda
habilitado opcionalmente. Entonces ambas multitudes están complacidas.

¿Alguien está en contra de tener ambos métodos como opciones que puede activar o
apagado dependiendo de su preferencia?

Creo que todo se reduce a estas dos opciones:

1) Agregue pestañas como preferencia. Encendido para los que les gusta y apagado para los que
no lo hagas.

2) No agregue pestañas en absoluto, incluso si tengo la opción de desactivarlas.

¿Por qué votaría por la opción 2 cuando tiene la opción de convertirlos?
¿apagado?
El 15 de abril de 2016 a las 7:32 p.m., "James McLaughlin" [email protected]
escribió:

@Measuring https://github.com/Measuring Estoy de acuerdo y en desacuerdo contigo.
Hay algunas cosas que necesitan innovar, pero primero hay que preguntarse, ¿qué
sobre el flujo de trabajo, podemos mejorar eliminando pestañas. Bueno para mi, cada
El editor único que utilizo para el desarrollo tiene una interfaz de pestaña porque es
Es común que un desarrollador trabaje entre 5-10 archivos a la vez sin
recordar el nombre exacto de los archivos ni el orden en que se abren
en. Así que tengo que preguntar, ¿cómo la mejoró esta nueva interfaz? Como es
es innovador? Primero pregunte, ¿cómo lo usan, luego pregunte, cómo puedo hacer
es mejor. En cuanto al problema de los tres minutos, voy a suponer que el Código es
no muy diferente de Sublime o Atom y si desde el principio yo
luchar para trabajar con él o mostrarle a alguien de manera eficiente lo que necesita hacer
entre archivos para hacer que algo funcione, entonces usaré algo que funcione
mejor para mis necesidades ahora y busque en Code algunas versiones en el futuro
cuando esta listo.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -210705545

@tones411 Algunas personas elegirán la opción 2 solo porque piensan que la adición de pestañas arruinará de alguna manera su experiencia con los archivos de trabajo.

_No puedo enfatizarlo lo suficiente_ pero, en mi opinión, la discusión no debería ser solo agregar pestañas y terminar el día, sino obtener el flujo de trabajo correcto y lo dije muchas veces, lo que significa que necesita las opciones correctas para la personalización, necesita para sentirse integrado y no alienado y aún opcional! lo mismo ocurre con los archivos de trabajo.

Algunas personas pueden querer tener algo como búfer de Vim y no querrían tener pestañas ni archivos de trabajo en absoluto.

Tal vez algo como los búferes de Vim se puedan usar como superficie para VSCode, donde podemos usar comandos para administrar archivos y, además, sentar las bases para cada flujo de trabajo, ya sean pestañas, archivos de trabajo u otra cosa mañana.

Bien dicho. Esto se ha convertido en un debate religioso. Es obvio de esto
hilo largo que hay muchas personas aquí que sienten pasión por tener
pestañas y creen que son necesarias / facilitan su flujo de trabajo. Existen
otros que no creen que las pestañas sean necesarias y que sean un impedimento.

Aceptemos no estar de acuerdo, está bien. Siempre que las pestañas sean opcionales
que aquellos que no los quieren no tienen que usarlos.

Yo personalmente creo que son útiles, pero no voy a detener a nadie.
de usar archivos de trabajo si eso funciona para ellos. No funciona para mi.
El viernes, 15 de abril de 2016 a las 10:07 p. M., Tones411 [email protected] escribió:

Pedir a aquellos de nosotros que preferimos las pestañas que cambiemos a ninguna pestaña es tan bueno como
pidiendo a aquellos que prefieren no tener pestañas que cambien a pestañas. Ambos no queremos
cambie al otro método.

¿Podemos detenernos ahora con el tipo de 'Mac vs Windows', 'Android vs IPhone'?
debates sobre qué camino es mejor: ¿'Pestañas vs Sin pestañas'? Ambos son buenos
y diferentes personas tienen sus propias preferencias.

Creo que la mejor solución es agregar pestañas como preferencia que se pueda
habilitado opcionalmente. Entonces ambas multitudes están complacidas.

¿Alguien está en contra de tener ambos métodos como opciones que puede activar o
apagado dependiendo de su preferencia?

Creo que todo se reduce a estas dos opciones:

1) Agregue pestañas como preferencia. Encendido para los que les gusta y apagado para los que
no lo hagas.

2) No agregue pestañas en absoluto, incluso si tengo la opción de desactivarlas.

¿Por qué votaría por la opción 2 cuando tiene la opción de convertirlos?
¿apagado?
El 15 de abril de 2016 a las 7:32 p.m., "James McLaughlin" [email protected]
escribió:

@Measuring https://github.com/Measuring Estoy de acuerdo y en desacuerdo contigo.
Hay algunas cosas que necesitan innovar, pero primero hay que preguntarse, ¿qué
sobre el flujo de trabajo, podemos mejorar eliminando pestañas. Bueno para mi
cada
El editor único que utilizo para el desarrollo tiene una interfaz de pestaña porque es
Es común que un desarrollador trabaje entre 5-10 archivos a la vez sin
recordar el nombre exacto de los archivos ni el orden en que se abren
ellos
en. Así que tengo que preguntar, ¿cómo la mejoró esta nueva interfaz? Cómo
es
es innovador? Primero pregunte, ¿cómo lo usan, luego pregunte, cómo puedo
hacer
es mejor. En cuanto al problema de los tres minutos, voy a asumir que Code
es
no muy diferente de Sublime o Atom y si desde el principio
yo
luchar para trabajar con él o mostrarle a alguien de manera eficiente lo que necesita hacer
entre archivos para hacer que algo funcione, entonces usaré algo que
trabajos
mejor para mis necesidades ahora y busque en Code algunas versiones en el futuro
cuando esta listo.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -210705545

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -210712143

+1

He estado siguiendo este hilo durante el último ~ mes más o menos desde que cambié a Code como mi editor principal y continuamente me molesta el comportamiento de navegación de archivos. He pasado un tiempo _intentando_ acostumbrarme a la sección de Archivos de trabajo, que admites que es más o menos una ocurrencia tardía de todos modos, y Ctrl + Tab y Ctrl + P. Estoy muy contento con Code y es fácilmente mi editor favorito, pero estas opciones de navegación de archivos están tan mal concebidas que es difícil entender cómo se idearon en primer lugar.

La mayoría de estos han sido mencionados, pero aquí están mis quejas:

La lista de WF es esencialmente inútil, ya que cerrar una ventana del editor no cierra realmente el archivo de WF. De hecho, necesito cerrar un archivo _dos veces_ y usar el mouse para hacerlo (Ctrl + W _y_ cerrar el archivo desde el panel WF). Si quisiera dejar el archivo abierto, no habría presionado Ctrl + W. ¿Cómo tiene sentido presionar Ctrl + W y dejar un archivo "abierto" (visible en WF)? Sí, esto se puede reasignar, pero estoy hablando del comportamiento predeterminado de WF).

Al hacer clic en un archivo en WF o en la vista de árbol, se abre un archivo en una ventana de editor no deseada al menos la mitad del tiempo. Si tiene un editor de dos paneles con el panel izquierdo activo, "abrir al lado" lo abre en el panel _derecho_, no en un panel _nuevo_, y con 3 columnas siempre se abrirá en un panel existente. El problema aquí es que "las cosas no se quedan donde las puse". Espero decirle a mi editor dónde quiero que estén las cosas, no que mi editor decida dónde deben estar las cosas en función del estado actual de la interfaz de usuario y luego las cambie a medida que cambia el estado de la interfaz de usuario en otras partes de la aplicación. Obtener _back_ a un archivo previamente abierto es un PITA .

Los archivos de un solo clic y doble clic tienen un comportamiento _completamente diferente_ con _exactamente la misma_ IU. Un solo clic abre la vista previa del archivo temporalmente (para cuando no quiero cargarlo en WF porque luego necesitaré dos cierres para deshacerme de él más tarde), pero cargando un editor de "vista previa" con otro archivo (inevitable con la implementación actual como se mencionó arriba) saltará el árbol de carpetas a un nuevo lugar, y cargar el archivo de "vista previa" anterior significa que debo navegar nuevamente a la carpeta en la vista de árbol. Ni siquiera quiero admitir cuánto tiempo he pasado navegando hasta la misma carpeta _exact misma_ 6 veces seguidas debido a este comportamiento.

En mi opinión, hacer clic simple o doble en un archivo debería darme el mismo comportamiento exacto, pero si realmente desea una "vista previa" de un solo clic que no aparece en WF / Ctrl + Tab, debería haber un _marcador de interfaz de usuario obvio_ que la ventana del editor activo es una vista previa y desaparecerá cuando la reemplace.

El árbol de carpetas _no_ debería saltar a la ubicación de cada archivo en el que hago clic, o cuando estoy depurando, saltar a través de cada carpeta en mi carpeta de biblioteca. Si quisiera navegar a una carpeta en particular, navegaría hasta ella, y una vez que lo haya hecho, espero que permanezca así. Esto puede parecer que no es tan relevante en el hilo de pestañas, pero de hecho lo es.

La única razón por la que existen estos comportamientos absolutamente ridículos del panel del editor, WF y vista de carpeta es _porque no hay pestañas_. Si agrega pestañas (acopladas a un panel en particular si los paneles del editor están divididos) y por defecto el comportamiento normal del editor, que es _siempre abrir todo en una nueva pestaña_, nada de ese comportamiento es necesario. Solo déjame decidir cómo quiero navegar en mi árbol y cómo quiero apilar mis pestañas, y dejar de intentar mostrarme una "mejor manera" (a menos que realmente _tienes_ una mejor manera - después de ~ 6 meses de trabajo diario, puedo digo con absoluta certeza que el camino actual _no_ es mejor para mí).

Y mientras lo hace, por el amor de Dios, ¡POR FAVOR déjeme ver archivos del mismo directorio en más de una ventana! Hay una solución simple y elegante, que cualquier otro software basado en pestañas ha tenido durante años: arrastrar las pestañas a una nueva ventana, en serio amigos, esto no es algo revolucionario. Si desea mantener el comportamiento de "una carpeta solo obtiene una instancia", haga que los paneles floten en una nueva ventana (que todavía está controlada por / adjunta a la ventana principal).

Ustedes han hecho un trabajo increíble con este editor y continuaré usándolo. Si podemos ver:

1. Pestañas
2. Deshabilitar WF
3. Detener el árbol de carpetas de navegación automática
4. Ripoff pestañas en el panel del editor flotante (que comparte el mismo comportamiento que el otro panel del editor en la interfaz principal)

Entonces creo que VS Code llegará lejos, lejos, lejos. Gran editor, y estoy dispuesto a tolerar las desventajas para aprovechar el resto, pero muchos, muchos otros solo están esperando estas pocas características básicas.

Me encantaría ayudar con las pruebas de UI / UX o lo que sea que haga para recibir comentarios / aportes de los usuarios. Avísame si puedo ser de utilidad.

¡Gracias!

@anyong gracias por tus ideas!

Para el punto 3, no estoy seguro si lo sabe, pero también puede personalizarlo actualmente con:

"explorer.autoReveal": false

Vinculo workbench.files.action.showActiveFileInExplorer también para poder acceder a un archivo aleatorio en el explorador si es necesario.

@Tyriar No estoy seguro de a qué versión te refieres, pero estoy actualizado en Insider y esa opción aún no hace nada.

: +1:

: +1:

@bpasero He leído los primeros mensajes en este tablero sobre las ventajas / desventajas de las pestañas. También entiendo la postura del equipo MSFT en esto: el equipo está unido bajo el mismo estilo de codificación y desarrolló el mismo conjunto de reflejos con respecto a ctrl+tab y / o la sección de archivos de trabajo. Esa es una buena cosa. Todos los miembros del equipo tienen un flujo uniforme de hacer las cosas, en general. Sin embargo, no formamos parte de ese equipo, ni deseamos desarrollar el mismo conjunto de reflejos. Nuestros reflejos existentes deberían, idealmente, cumplirse, no forzarse y reemplazarse. El editor debe ayudar al usuario.

Tendremos que adaptarnos a su definición de UX o dejar de usar VSCode. Algunos se adaptarán, otros no. Se trata del equilibrio entre las cosas buenas y las malas puestas sobre la mesa. Dicho esto, creo que el equipo de MSFT subestima enormemente la importancia de las pestañas y sobreestima en gran medida los reflejos desarrollados internamente.

El equipo y las personas a cargo realmente necesitan tomar una decisión simple: ¿VS Code es un experimento de interacción humano-computadora o se supone que es un IDE sólido y utilizable que _da a los desarrolladores lo que quieren? _ Si es lo primero, está bien . Personalmente, dejaré de molestarme y me mudaré a otro lugar porque quiero hacer mi trabajo, no ser parte de un experimento de HCI, pero estoy seguro de que su experimento dará sus frutos en el futuro. Si es lo último, necesitan implementar pestañas, al menos, porque eso es lo que quieren los desarrolladores, y _ambas_ pestañas y no pestañas en el mejor de los casos si quieren perseguir a ambos conejos e intentar convertir a las personas a un nuevo flujo de trabajo.

@Tyriar : autoReveal en v.1.0.0-insider y tampoco hizo nada por mí. El explorador todavía salta cuando no quiero que lo haga, lo que es más irritante, cuando se desplaza completamente a un lugar diferente cuando uso ir a definición y eso abre otro archivo.

Esto es lo que puse en mi archivo de preferencias: "explorer.autoReveal": false,

@anyong @stephenmartindale tienes razón, no me di cuenta de lo nueva que era esta configuración. Debería estar disponible en la próxima compilación de Insiders.

Bien dicho @stephenmartindale. Sin pestañas, todo lo que tenemos es notepad.exe con su propia versión de Alt-Tab (que como se señaló muchas veces anteriormente, está roto). He intentado usar "Archivos de trabajo" como si fueran pestañas laterales, pero después de una semana estoy bastante listo para volver a Sublime y sus problemas, particularmente que no hay forma de hacer que la barra lateral siempre esté ahí. importa qué más esté sucediendo en la aplicación. Con el nombre "Visual Studio ..." esperaba al menos las características básicas del editor de Visual Studio (pestañas y la capacidad de arrastrar esas pestañas a sus propias ventanas). Por qué habrían eliminado esa funcionalidad es inexplicable. Tal vez vuelva en unos meses y vea si han llegado lo suficientemente lejos como para poner una etiqueta pre-alfa en una compilación. En este momento, esto no es más que un experimento de interfaz de usuario, la única pregunta es ¿ya ha fallado o está al borde del fracaso?

Como han indicado la mayoría de los 259 comentarios anteriores, me gustaría mucho ver pestañas en VS Code, similar a cómo operan en Sublime Text. Yo también cambiaría con mucho gusto si no fuera por esta característica que falta. Por extraño que parezca, necesito la capacidad de tener al menos cuatro documentos abiertos en la misma ventana para poder cambiar entre ellos rápidamente.

Ah, y si Microsoft no quiere que VS Code se compare tanto con Sublime Text, entonces no deberían haber hecho un producto que se vea y actúe de manera tan similar. Mantener las pestañas alejadas de la GUI no es una forma de desalentar las comparaciones con Sublime Text; es una forma de hacer que esas comparaciones sean menos favorables para Microsoft.

@SturmB Sublime no es el único editor que existe y no creo que hayan hecho que VSCode sea otro imitador de Sublime, al igual que Atom no es Sublime, pero todos los editores comparten funciones, lo cual es bueno, así es como obtienes opciones. !

VSCode no actúa como Sublime en absoluto porque son muy diferentes, VSCode pretende ser el término medio entre un editor de código y un IDE, mientras que Sublime no hace esa afirmación, por lo tanto, VSCode tiene una audiencia más amplia de personas, que van desde personas que usan Vim para Visual Studio.

Agregar pestañas no es el problema en absoluto, la gente sigue diciendo que necesitan agregar pestañas y estoy seguro de que ahora entienden que las pestañas son importantes, pero el problema real es lograr el diseño correcto y asegurarse de que la experiencia sea excelente para todos, los que aman las pestañas y los que las odian.

Ahora, cuando diseña una función, especialmente una función que es fundamental para la experiencia en el editor, no puede simplemente piratear algunas cosas y unirlas y luego volver con un anuncio que, después de unos días, decepcionará a muchas personas. ¡las cosas buenas llevan tiempo! y esto no es diferente. :)

Me gusta el concepto de archivos de trabajo. Las pestañas no se escalan bien cuando hay muchos archivos abiertos. Pase lo que pase, ¡mantenga el control de los archivos de trabajo!

@helmbold Tengo

@eyalsk :

el verdadero problema es conseguir el diseño correcto y asegurarse de que la experiencia sea excelente para todos, los que aman las pestañas y los que las odian.

Casi todos aquí han dicho que esperan que las pestañas estén controladas por una configuración exactamente por esta razón. Dicho esto, aunque algunos programas durante las primeras iteraciones de pestañas hace años no eran muy agradables de usar, en estos días suele ser bastante bueno. El código tiene Sublime, Atom y no editores, como navegadores, a los que buscar para hacer las pestañas "correctas".

Una característica que me gustaría ver que no he visto en ningún software con pestañas y que creo que aliviaría algunos problemas con "demasiadas pestañas" es una forma de seleccionar y arrastrar varias pestañas a una nueva ventana.

Al final del día, siempre faltarán interfaces humano-computadora para administrar cientos de archivos con nombres largos de apariencia similar; no es así como estamos diseñados para trabajar, es solo la forma en que nos vemos obligados a trabajar debido a la estado actual de la ingeniería de software.

@cualquier largo seguro! agregar opciones no es un problema en absoluto, quiero decir que el problema comienza cuando te preguntas qué opciones son redundantes y qué opciones son realmente útiles, los programas que se diseñaron con pestañas en mente desde el principio lo tienen realmente fácil para múltiples razones, pero principalmente porque las pestañas no son una ocurrencia tardía, además, no es posible comparar un editor con otro o incluso con otro programa que tiene pestañas principalmente porque la historia de navegación es generalmente diferente de un programa a otro, diferentes programas apuntan a enfocarse en diferentes cosas.

El hecho de que Sublime / Atom u otro programa tenga pestañas y funcione bien allí no significa que pueda tomar todas las cosas que funcionan allí y hornearlas en su programa, no es así como funcionan las cosas, de hecho, ¡así es como las cosas _pueden_ fallar! tiene éxito allí porque todo el paquete lo hace exitoso.

Ahora, agregar un nuevo tipo de experiencia de usuario al editor requiere que vuelva a evaluar toda la historia de navegación, incluidas las funciones existentes, como "archivos de trabajo", especialmente cuando tiene consumidores existentes donde cada persona espera que funcione como su editor de elección. y puede deducirse de las publicaciones que muchas de ellas tienen altos estándares sobre cómo debería funcionar. :)

: +1:

@bpasero , @ bgashler1 y yo hemos comenzado a trabajar en los diseños de UX para mejorar la gestión de documentos. Estamos observando todos los comentarios sobre este tema detenidamente y ya hemos hablado con algunos de ustedes para obtener más detalles sobre sus propias experiencias y perspectivas únicas.

Ahora nos gustaría compartir nuestros primeros diseños con usted para recibir sus comentarios. Organizaremos un Hangout de Google el jueves 21 de abril a las 4 p.m. BST. Si desea unirse a nosotros, haga clic en este enlace en ese momento: https://hangouts.google.com/call/u3wnrhjja5h47ovt7piatelkxme

Esta será nuestra primera reunión pública de diseño y estamos deseando que llegue.

He estado usando VSCode exclusivamente (vino de WebStorm) y no me han faltado pestañas. Al principio pensé que lo haría, pero me empezó a gustar más Working Files ya que podía ver más en menos espacio y sin tener que pensar en cómo organizar o agrupar las cosas en la pantalla. Ahora uso CTRL + TAB principalmente.

Creo que si algo, las pestañas tradicionales deberían ser una _extensión_ oficial o una _opción_ de suscripción. Personalmente, espero algo más que pestañas para mejorar la experiencia actual.

Lo que encuentro que le falta a CTRL + TAB es el contexto del panel del editor activo. Si tengo 2 paneles del editor abiertos uno al lado del otro, me gustaría ver CTRL + TAB mostrar el historial de archivos filtrado a los archivos que se han abierto en el panel del editor activo en lugar de todos los archivos abiertos en la aplicación como un todo ( aunque eso también debería existir). Además, quizás al hacer clic en algún lugar en / cerca del nombre de archivo en la parte superior de un panel de editor se podría mostrar una lista desplegable de archivos abiertos en ese panel de editor (igual que CTRL + TAB).

Sigan con el buen trabajo.

Otra sugerencia ... Sería bueno tener una mejor combinación de teclas predeterminadas para ver la lista de archivos de trabajo para cuando la barra lateral esté oculta. Recientemente descubrí que CTRL + K CTRL + P muestra lo que quiero, pero es más difícil de levantar que CTRL + TAB. Como sugerí con CTRL + TAB, la ventana emergente Working Files podría beneficiarse de algún contexto basado en el panel del editor activo. Tal vez se podría ordenar para que la lista de archivos de trabajo que se han abierto en el panel del editor activo esté por encima del resto.

@RyanEwen Supongo que antes no eres un usuario de atajos. Porque la plataforma Intellij Idea tiene los mismos accesos directos y puede colocar las pestañas en cualquier lugar (superior, inferior, izquierda, derecha, ninguna). Cuando se coloca en Izquierda / Derecha, funciona de manera similar a Working Files en VSCode. Sería genial hacer algún experimento. Volviendo a WebStorm usando la combinación CTRL + TAB con las pestañas superiores para ver si no lo necesita o si se ve obligado a aceptarlo como la única solución alternativa. CTRL + E en WebStorm también incluye archivos recientes con funciones de filtrado (escriba para buscar).

Si alguien dijo que no a las pestañas, mencione también si estaba usando MOUSE en su flujo de trabajo.

: +1:

@KayLeung He usado CTRL + E en WebStorm, pero como había pestañas, me permitiría usarlas con el mouse la mayoría de las veces. Recientemente usé un editor con pestañas (Koding.io) cuando no tenía acceso a VSCode y puedo decir confidencialmente que no extraño configurar / organizar pestañas. Parece tedioso comparado con solo tener un historial. Siempre me he quedado atrapado en cómo quiero que se distribuyan las cosas y en predecir qué archivos abrir en lugar de simplemente usar el editor y pasar de un archivo a otro. Esto es probablemente un problema "yo" más que un problema de tabulación, lo sé. Un poco de TOC, supongo.

Era mouser cuando usé WebStorm. Usé atajos de teclado para buscar archivos recientes y sin abrir aquí y allá, pero pasé el mouse a pestañas para lo que ya estaba abierto. No sentía que pudiera usar el teclado en pestañas específicas de manera fácil / intuitiva, y existía ese deseo de organizar las pestañas que también me hizo llegar a mi mouse al final. Tener una falta de pestañas inconscientemente (y sin dolor, en mi caso) me ayudó a deslizarme en un flujo de trabajo de teclado primero.

Acabo de probar Adobe Brackets y su lista de archivos de trabajo está dividida por paneles. Si tiene un panel izquierdo y uno derecho, entonces hay 2 listas de archivos de trabajo ("Izquierda" y "Derecha") en la barra lateral en lugar de una como en VSCode. No es una mala solución. No me importaría algo así (además de mi otra sugerencia de agregar contexto a CTRL + TAB según el panel del editor activo).

@RyanEwen has hecho un muy buen punto. Siempre trabajo con 2 paneles para cualquier instancia abierta de mi IDE. Puedo tener 2 instancias abiertas en 2 pantallas, para 4 paneles abiertos. No pude identificarlo, pero tú lo hiciste. Tener una sola lista cuando hay dos (o más?) Paneles abiertos, es el problema con la implementación actual de Working Files que la ha hecho inutilizable para mí. Gracias por ser específico aquí.

Un recordatorio amistoso de que nosotros (yo mismo, @bpasero y @ bgashler1) compartiremos nuestros últimos diseños para pestañas y archivos de trabajo más tarde hoy a las 4

Únase a nosotros en este enlace a las 4 p.m. BST: https://hangouts.google.com/call/u3wnrhjja5h47ovt7piatelkxme. Nos encantaría escuchar sus comentarios.

Recordatorio para cualquiera que esté planeando unirse a los hangouts: ya está activado, así que haga clic en el enlace de arriba. Solo ~ 5 personas hasta ahora.

Realmente me hubiera gustado estar allí, pero son las 11 de la mañana y no puedo unirme al trabajo. ¿Asumo que alguien tendrá algunas cosas para compartir por escrito después? :RE

Breve descripción:

1. Las pestañas y los archivos de trabajo (renombrados como "editores abiertos") se comportan exactamente de la misma manera, solo depende de si desea las imágenes en la parte superior (pestañas) o hacia la izquierda (editores abiertos)
2. Las pestañas se agrupan por panel visualmente en la parte superior, los editores abiertos se agrupan bajo los encabezados "Izquierda", "Derecha".
3. Haga clic en un archivo para abrir una pestaña de vista previa (o "editor abierto"); haga doble clic en el archivo, edite el archivo o haga doble clic en la pestaña para persistir
4. El depurador abre todos los archivos como archivos de vista previa a menos que persista el archivo que se está depurando tomando una de las opciones anteriores
5. Las pestañas / editores abiertos se pueden arrastrar entre paneles
6. Los paneles se pueden arrastrar para mover todo el grupo de pestañas

Se ve muy bien, y personalmente (desde el grupo muy pro-tab si leíste mi publicación arriba), creo que estaré feliz de darle una oportunidad justa a los nuevos "Editores Abiertos".

Pensamientos de seguimiento para los desarrolladores:

1. Dado que el flujo de pestañas / editores abiertos es exactamente el mismo, debería ser posible hacer algo como esto: mostrar los editores abiertos cuando el explorador está abierto y mostrar las pestañas cuando el explorador está cerrado. Podemos aumentar el espacio horizontal para el código y mantener el acceso a las pestañas. Suponiendo que hay un atajo para ocultar / mostrar pestañas, esto sería el equivalente a presionar eso y CTRL + B al mismo tiempo; si funciona, debería ser una opción en la configuración: autoShowTabsWhenExplorerClosed o algo así. Si necesitamos ver más pestañas, podemos hacer clic en el cheurón o simplemente CTRL + B para ver las pestañas en el panel izquierdo. No estoy seguro de si eso sería "desorientador" en absoluto, pero siempre que los editores abiertos y las pestañas sean siempre exactamente iguales y en el mismo orden, puedo imaginar que funcionaría muy bien.
2. Creo que mencionaste que las pestañas cerradas anteriormente estaban disponibles en una de las vistas CTRL + Tab + algo, pero ¿has pensado en un acceso directo CTRL + MAYÚS + T (deshacer pestaña cerrada) que simplemente reabriría pestañas previamente cerradas (en el orden en que estaban cerrados)?

Solo pude unirme durante los últimos 15 minutos más o menos. ¿Fue grabado?

Me decepcionó (pero no me sorprendió) ver que es probable que las pestañas
convertirse en el predeterminado. Espero que sigas conservando el peso ligero.
entorno de VS Code y explorar flujos de trabajo progresivos.

Gracias,

James

El jueves 21 de abril de 2016 a las 11:07 a. M., Anyong [email protected] escribió:

Recordatorio para todos los que planeaban unirse a los hangouts: ahora está activado
haga clic en el enlace de arriba. Solo ~ 5 personas hasta ahora.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -212963079

Parece que hubo algunas buenas ideas. Espero ver esto en acción.

FWIW (y si sigue siendo relevante) sigo pensando que es mejor no tener pestañas en la interfaz de usuario _por defecto_. Un encabezado de editor limpio y agradable en el que se puede hacer clic para ver una lista de archivos si no tengo la barra lateral visible, o CTRL + TAB, es lo que realmente espero :)

Gracias a todos los que pudieron asistir y darnos sus comentarios hoy. Hemos tomado notas y hemos estado siguiendo continuamente el problema de GitHub aquí. Estamos escuchando a todos.

@indiejames y @RyanEwen sí, tomamos notas y publicaremos pronto. Aún no hemos decidido con certeza el comportamiento predeterminado. Sin embargo, estamos proponiendo una solución que facilitaría la elección de si desea utilizar archivos de trabajo, pestañas o ambos.

@ bgashler1 , mencionas que estás buscando una solución que permita a las personas elegir si quieren los archivos de trabajo, las pestañas o ambos, ¿qué pasa con ninguno? ¿Es esa una opción? depende del proyecto y del idioma en el que esté trabajando, ninguno puede ser excelente para scripts como PowerShell. :)

Gracias a todos los que se tomaron el tiempo de unirse a la llamada de hoy y brindar comentarios, realmente lo apreciamos. @anyong ya ha hecho un gran trabajo al resumir lo que presentamos, pero

Diseño visual

Primero, esta imagen indica cómo creemos que se verían las pestañas en VS Code:

Nuestro objetivo es lograr un aspecto ligero que no distraiga, algo que encaje bien con el resto de VS Code. Todavía no hemos elaborado cómo se vería en un tema ligero.

Como puede ver en la imagen de arriba, las pestañas contienen un botón de cierre a la izquierda del nombre. Cuando el archivo contiene cambios no guardados, mostramos un indicador sucio donde está el botón de cierre.

Al pasar el cursor sobre una pestaña, se mostrará una información sobre herramientas con la ruta completa del archivo en la pestaña.

Pestañas de vista previa

Para distinguir claramente las pestañas de vista previa de las pestañas abiertas, ponemos en cursiva el título en la pestaña como en el siguiente esquema.

Discutimos las acciones para promover una pestaña de vista previa a una pestaña completamente abierta:

• Editar contenido dentro de la pestaña
• Hacer doble clic en un archivo en el explorador
• Haga doble clic en la pestaña de vista previa en el grupo de pestañas

Desbordamiento

Las pestañas se abren a la derecha de la pestaña activa. Si no hay suficiente espacio para mostrar todas las pestañas en un grupo de pestañas, desbordamos las pestañas. No truncamos el nombre del archivo dentro de la pestaña para dejar más espacio para más pestañas.

Mostramos un galón cada vez que hay un desbordamiento. Al hacer clic en ese cheurón, se mostrará un cuadro de diálogo de apertura rápida que enumera todas las pestañas en el grupo de pestañas, lo que permite al usuario encontrar la pestaña que desea ver.

Al hacer clic en una pestaña que se encuentra actualmente en desbordamiento, aparecerá esa pestaña.

Navegar por pestañas

Los siguientes comandos permiten a los usuarios navegar entre pestañas:

• Ctrl-Tab muestra una lista de todas las pestañas dentro del grupo de pestañas activo:
  
• Ctrl Alt Tab muestra una lista de todas las pestañas dentro de todos los grupos de pestañas
  
• La apertura rápida muestra el historial lineal de todas las pestañas
  

Archivos de trabajo

Cambiamos el nombre de los archivos de trabajo para abrir editores para reflejar mejor lo que realmente es.

La lista de editores abiertos funciona de manera idéntica a las pestañas. Simplemente los enumeramos en el explorador en lugar de visualizarlos como pestañas.

Si un archivo está abierto en dos o más grupos de editores, lo mostramos en la lista de editores abiertos:

Cualquier editor que abra el usuario aparecerá en la lista de editores abiertos. Entonces, por ejemplo, el editor de diferencias se muestra así:

Cada grupo solo contiene una pestaña de vista previa.

El cheurón en la parte superior derecha del grupo de editores activos indica si hay una pila de editores o no.

En este caso, cerrar un editor revelará el editor debajo de él en la pila, en lugar de cerrar el editor por completo.

Cerrar un editor (por ejemplo con Ctrl-W) también elimina el editor de la lista de editores abiertos.

@stevencl

Para distinguir claramente las pestañas de vista previa de las pestañas abiertas, ponemos en cursiva el título en la pestaña como en el siguiente esquema.

Además de ponerlo en cursiva, puede ser genial si hubiera una opción para atenuar los colores de las pestañas para que sea _realmente_ claro.

Como escribí antes, también me gustaría saber si hay una opción para no tener pestañas o editores abiertos, este puede ser un escenario útil para las personas que hacen scripts, por ejemplo, PowerShell.

@eyalsk se mencionó en la discusión que las pestañas y los editores abiertos deben habilitarse o deshabilitarse de forma independiente para cualquiera / ambos / ninguno.

@anyong gracias! :)

Ctrl-Tab muestra una lista de todas las pestañas dentro del grupo de pestañas activo:

¡Finalmente! Pestañas o no, ¡este es el comportamiento que estaba esperando! No más perderme en mi historial de archivos.

Cerrar un editor (por ejemplo con Ctrl-W) también elimina el editor de la lista de editores abiertos.

¡Excelente! Con suerte, esto se sentirá más intuitivo y ayudará a limpiar el desorden en _Archivos de trabajo_.

Ahora solo esperaré a que se cierre https://github.com/Microsoft/vscode/issues/5554 .

Hmm, no sé si esto se consideró, pero lo pensé ahora, ¡varios monitores soportan! en Visual Studio puedo arrastrar una pestaña a un monitor diferente y crear una nueva ventana / vista de pestaña, ¿se está considerando algo como esto? Me imagino que es posible lograr esto creando un nuevo proceso VSCode y arrastrando pestañas entre procesos a través de la comunicación entre procesos, lo mismo ocurre con los editores abiertos, solo una idea, :)

Por favor, por favor, ¿puede hacer que las "pestañas de vista previa" sean opcionales, es decir, tener una opción para hacer que cualquier cosa se promocione automáticamente a una pestaña permanente y nunca desaparezca? Sé que está discutiendo formas de distinguir visualmente las pestañas que son temporales pero, francamente, eso no funcionará para personas como yo que navegan entre archivos tan rápido (particularmente con Go-To-Definition et al.) Que no hay tiempo para inspecciono visualmente la pestaña para adivinar cómo podría comportarse, no recuerdo cómo abrí un archivo o si lo he editado y me resulta realmente desconcertante cuando los archivos desaparecen aparentemente al azar. (Sé que no es aleatorio, pero bien podría serlo).

Normalmente me entierro en pestañas abiertas hasta que he terminado una unidad de trabajo y luego las cierro todas al mismo tiempo que voy a comprometerme.

Gracias @eyalsk , sí, lo consideramos. En última instancia, nos gustaría poder respaldar esto, pero el trabajo requerido para compartir el contexto entre múltiples procesos es bastante significativo y, por lo tanto, es poco probable que suceda mientras trabajamos en el resto de la UX de administración de documentos. Sin embargo, definitivamente es algo que queremos hacer.

@stevencl Estaría feliz si al arrastrar simplemente se abriera una nueva ventana de vscode con ese archivo abierto (tal vez con la misma carpeta abierta también).

Gracias @Tyriar , seguiremos investigando esto. Si hay alguna forma de hacer que funcione bien, nos encantaría poder hacerlo.

@stevencl Solo me preocupa que se requiera aún más trabajo para agregarlo en el futuro, así que _cuando_ mejore la infraestructura, asegúrese de mantenerlo en sus trabajos pendientes. ;)

pestañas por favor

Genial ver esto. Me encanta la propuesta liviana y que está encontrando una manera de no romper la experiencia de los archivos de trabajo.

Estoy deseando darle una vuelta. Gracias por su atención.

@stevencl Eso parece lo mejor de ambos mundos. ¡Se ve maravilloso! Las pestañas aparecen como esperaba para que encajen con el resto de la interfaz de usuario, y parece que obtendría exactamente lo que quiero con los cambios de Working Files :)

¿Open Editors admitirá más de 2 grupos de editores? Me pregunto cómo los nombras si es más complicado que Izquierda y Derecha.

Sí, esto todavía sería compatible.

De: Maxime Quandallemail a: [email protected]
Enviado: 22/04/2016 23:09
Para: Microsoft / vscodemailto: [email protected]
Cc: Steven Clarkemailto: [email protected]; Mención correo electrónico a: menció[email protected]
Asunto: Re: [Microsoft / vscode] Pestañas adecuadas para archivos abiertos (# 224)

¿El reposicionamiento de paneles mediante arrastrar y soltar aún sería posible bajo la propuesta de @stevencl ?

Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/Microsoft/vscode/issues/224#issuecomment -213605667

@stevencl Creo que lo que describiste en la discusión de hace unos días es genial. Esto es exactamente lo que todos estábamos esperando con respecto a las pestañas. Algunos de los otros editores que he usado también implementan configuraciones de paneles horizontales y verticales. Esto le permite tener dos archivos abiertos uno al lado del otro en la parte superior y uno o dos abiertos debajo de ellos. Si bien esta no es una característica crítica, me pierdo esto con bastante frecuencia mientras desarrollo aplicaciones web y aplicaciones móviles. La razón es que la mayor parte de lo que trabajo es MVC o sus derivaciones, por lo que tener un modelo, vista, controlador y algún archivo de interfaz de usuario (css, Js, etc.) abiertos al mismo tiempo es un gran beneficio. ¿Hay planes para incluir esto también? Atom hace esto muy bien, que fue el último editor que usé antes de VSCode. Desafortunadamente, carecía severamente en otras áreas en las que VSCode sobresale, de ahí mi uso exclusivo de VSCode. Si no está en la versión planificada con pestañas y cambios en la administración de documentos, esta sería una gran mejora en el futuro.

@ jayrosen1576 La división horizontal se captura en este número https://github.com/Microsoft/vscode/issues/1749 , asegúrese de: +1: para mostrar su interés.

Buen trabajo chicos, parece que los marcos de alambre funcionarían muy bien.

Hola @stevencl
Gracias por el gran trabajo y aquí están mis dos centavos sobre el botón de cierre a la izquierda.
Cuando hay muchos archivos abiertos y las pestañas se reducen, el pequeño espacio para cada pestaña solo será suficiente para mostrar el botón de cierre, lo que facilitará cerrar la pestaña accidentalmente en lugar de seleccionarla.

El icono indicador sucio puede permanecer a la izquierda ya que solo indica el estado del archivo, pero mover el botón de cierre hacia la derecha nos permitirá reconocer fácilmente el nombre del archivo y evitará una acción de cierre accidental.

@stevencl Las maquetas se ven geniales y la descripción de la funcionalidad suena bien. Sin embargo, mi impresión inicial es que las pestañas son un poco grandes ... quizás más grandes de lo necesario y parecen desperdiciar algo de espacio. Entiendo la compensación entre la presentación elegante y la funcionalidad, pero esta es una herramienta de desarrollo, el diseño práctico triunfa con seguridad sobre el estilo. Sin embargo, estoy seguro de que ha experimentado con esta calibración, ¡así que espero probarla!

@hsyn tenía entendido que las pestañas no se encogerían, y las pestañas de desbordamiento estarán disponibles desde el botón de desbordamiento de chevron. El botón de cierre no debería ser un problema.

Las pestañas se abren a la derecha de la pestaña activa. Si no hay suficiente espacio para mostrar todas las pestañas en un grupo de pestañas, desbordamos las pestañas. No truncamos el nombre del archivo dentro de la pestaña para dejar más espacio para más pestañas.

No estoy de acuerdo con eso. Si la pantalla está dividida en 2-3 columnas, entonces mostrará 1-2 pestañas como máximo y desbordará el resto. Por favor, haga lo que hacen los navegadores, los usamos todos los días y es intuitivo y estamos acostumbrados. Te animo a que uses patrones establecidos, algunos de ellos han estado evolucionando durante más de una década. No vayas contra la corriente.

No estoy de acuerdo con eso. Si la pantalla está dividida en 2-3 columnas, entonces mostrará 1-2 pestañas como máximo y desbordará el resto. Por favor, haga lo que hacen los navegadores, los usamos todos los días y es intuitivo y estamos acostumbrados. Te animo a que uses patrones establecidos, algunos de ellos han estado evolucionando durante más de una década. No vayas contra la corriente.

Algunos navegadores combinan pestañas que se encogen, pero luego las desbordan más allá de un cierto umbral. Firefox lo hace; bastante seguro de que iOS Safari lo hace (o lo hizo) también.

Cuando hay suficientes pestañas abiertas que apenas se pueden ver unas pocas letras en cada una (aunque en la práctica normalmente no tengo tantas abiertas), no es particularmente más útil de lo que sería el desbordamiento.

@alexgorbatchev Definitivamente entiendo de dónde vienes, pero esto fue algo que explicaron en la conferencia telefónica el otro día: desde la otra perspectiva, tener un montón de pestañas abiertas y no poder leer los nombres de ninguna de ellas es tampoco es una buena solución. El "desbordamiento" es una especie de compromiso entre la ausencia de pestañas y las pestañas estándar de "estilo Chrome" que se reducen al olvido. Obligar a las pestañas a mostrar al menos los nombres de los archivos significa que las pestañas visibles al menos serán útiles.

Pero me diste una idea para los desarrolladores; creo que el problema real aquí es que, si bien sabemos que no podemos usar 20 pestañas cuando todos los nombres de archivo están ocultos, al menos _sabemos_ que hay 20 pestañas abiertas y nos proporciona una cierta sensación de "sé dónde están mis archivos si los necesito, no simplemente desaparecieron". Todo lo que se necesitaría para arreglar eso es un indicador que muestre el _número_ de pestañas actualmente ocultas, el indicador podría ser solo un pequeño círculo sobre el cheurón de desbordamiento para no ocupar ningún espacio horizontal adicional.

Gracias a todos. No lo mostramos en las maquetas, pero nuestra intención es que cuando sea necesario, reduzcamos las pestañas para que solo el nombre del archivo y el botón de cierre sean visibles. Por las razones que menciona @anyong , no creemos que queramos encogernos hasta el punto en que los nombres de archivo no se puedan distinguir entre sí. Creemos que probablemente sea más común que varias pestañas en un editor de código tengan nombres similares que que las pestañas del navegador tengan nombres similares (por ejemplo, podría haber muchos nombres de archivo con el mismo prefijo). Por lo tanto, pensamos que la reducción de pestañas en un editor de código tiene diferentes consecuencias que en un navegador.

Tenemos la intención de mostrar cuándo las pestañas están en el control de desbordamiento con el doble chevron, pero colocar una insignia con el número de pestañas desbordadas también es una idea interesante. ¿La intención es que el número simplemente indique que hay pestañas de desbordamiento o es importante el número real de pestañas de desbordamiento?

Gracias por aclararlo @stevencl.

Un caso extremo a tener en cuenta con los nombres de archivo en las pestañas son varios archivos con el mismo nombre abiertos desde diferentes carpetas (index.js, README, LICENSE, package.json, etc.).

Probablemente no usaré pestañas en absoluto, pero creo que también vale la pena señalar
que los navegadores suelen mostrar el favicon de un sitio en la pestaña que
hace que sea más fácil de identificar incluso cuando la pestaña se contrae más allá del punto que
es legible. Los archivos fuente no tendrían un favicon para eliminar la ambigüedad,
y, como señala Steven, los nombres de los archivos suelen ser similares en el código fuente.

El jueves 28 de abril de 2016 a las 12:16 p. M., Steven Clarke [email protected]
escribió:

Gracias a todos. No lo mostramos en las maquetas, pero nuestra intención es
que cuando sea necesario, encogeremos las pestañas para que solo el nombre del
archivo y el botón cerrar son visibles. Por las razones @anyong
https://github.com/anyong menciona, no creemos que queramos reducirnos a
el punto donde los nombres de archivo no se pueden distinguir entre sí. Nosotros pensamos
que probablemente sea más común que varias pestañas en un editor de código tengan
nombres similares a los que tienen las pestañas del navegador para tener nombres similares (por ejemplo,
podría haber muchos nombres de archivo con el mismo prefijo). Por eso pensamos que
El encogimiento de pestañas en un editor de código tiene diferentes consecuencias que en un
navegador.

Tenemos la intención de mostrar cuándo las pestañas están en el control de desbordamiento con el doble
chevron, pero colocar una insignia con el número de pestañas desbordadas es una
idea interesante también. ¿Es la intención que el número simplemente indique que
¿Hay pestañas de desbordamiento o es importante el número real de pestañas de desbordamiento?

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -215481474

Gracias @alexgorbatchev. Tenemos algunas ideas sobre cómo mostrar la ruta a un archivo para poder eliminar la ambigüedad en estos casos. En la maqueta de alta fidelidad que se muestra arriba, por ejemplo, mostramos la ruta al archivo debajo del nombre del archivo. Sin embargo, esta es solo una idea y puede que no funcione cuando el camino es largo. Otro sería poner la ruta en la barra de estado. Muchas cosas para explorar ...

@stevencl

¿La intención es que el número simplemente indique que hay pestañas de desbordamiento o es importante el número real de pestañas de desbordamiento?

Creo que mostrar el número real de pestañas abiertas (pero ocultas a la vista) resolvería el problema. Esencialmente, la gente está acostumbrada a ver esto (bueno, al menos hablando por mí):

por lo que intuitivamente tienen una idea de "Tengo muchas pestañas abiertas" frente a "Tengo 2 o 3 pestañas abiertas".

Una insignia que muestre "20" es mucho más pequeña (básicamente, sin espacio adicional) que mostrar 20 pestañas reducidas pequeñas / inútiles, pero aún me permite saber de inmediato que (a) las pestañas ocultas están ahí y (b) exactamente cómo muchos hay.

Solo soy nuevo en este hilo, pero mi 2p como usuario completo de VS2015:

Espero tener pestañas en vscode, ya que los archivos de trabajo nunca encajan conmigo (aunque ahora veo que presionar ctrl-f4 no se elimina de ese conjunto como había asumido).

Gran fan de la pestaña de vista previa, me alegro de verla llegar.

Tengo curiosidad por saber por qué se abrirán nuevas pestañas a la derecha de la pestaña activa. Espero 'porque los navegadores web' o 'porque sublime' es la respuesta, pero me parece contradictorio, especialmente si las pestañas se desbordan escondiéndose de la izquierda (en el cheurón de la derecha).

Espero ver menús de clic derecho para las pestañas según VS ... 'Cerrar todo' (para el grupo) lo más importante, no preocupado por 'Cerrar todo excepto esto'. Un cuadro de guardado de estilo VS para todos los archivos modificados sería útil aquí.

El botón de cierre de la izquierda es extraño para mí, supongo que es una convención de mac / linux, pero siempre que el 'clic del botón central' en la pestaña cierre un editor (se le pide que guarde si corresponde), entonces no se moleste. Puedo ver por qué está a la izquierda para cerrar rápidamente un montón de archivos en sucesión, pero el clic del medio es mejor para eso de todos modos (aunque tal vez no para Mac o portátiles sin rueda de desplazamiento).

El selector de archivos Chevron debería permitir escribir para un salto rápido a un archivo. No es que personalmente planee tener suficientes archivos abiertos para mostrar el cheurón (y cuando lo haga, sin duda usaré ctrl-p), pero sucede.

Número de galón: ¿es este un recuento de pestañas / archivos / editores ocultos en este grupo o un recuento de todos los archivos, incluidos los visibles? Yo diría que solo los elementos ocultos, especialmente si solo muestra el cheurón (y, por lo tanto, el recuento) cuando algo se desborda de la fila de pestañas.

En una nota ligeramente relacionada, si ctrl-f4 (o ctrl-w? Parece ser la versión de ctrl-f4 que no es de Windows, a menos que me equivoque), espero que si la pestaña desaparece, está cerrando el editor y debería solicitar guardar / descartar y eliminarlo de ctrl-tab / ctrl-alt-tab / archivos de trabajo ... Puedo ver que hay algún cambio de combinación de teclas que puedo hacer en este momento para habilitar esta funcionalidad, pero me cuesta vea por qué en una interfaz basada en pestañas, la existencia de una pestaña no está directamente relacionada con el "actual" - / apertura del archivo / editor.

Amando lo que todos están haciendo en vscode, se ve increíble ☺

Probé usando el historial de archivos como se sugirió, y después de un mes siento que ya no necesito pestañas. En VS tener un montón de pestañas abiertas es realmente molesto. Odio cuando hay demasiados y me mueven al pequeño menú desplegable de pestañas ocultas. Creo que ahora también me gustaría usar el historial de archivos en VS.

Con respecto a los archivos de trabajo, me parece realmente molesto que todo esté allí. Es molesto hasta el punto de que nunca lo abro y lo mantengo cerrado. Para lo único que lo encuentro útil es para ver archivos nuevos que no se han guardado, o cualquier archivo que no se haya guardado, supongo. Rápidamente se vuelve demasiado grande para que me importe. Sin embargo, no estoy seguro de cómo podría solucionarse esto. Tal vez solo muestre archivos no guardados, pero eso tendría algunos efectos secundarios extraños.

De todos modos, ahora soy un creyente de la historia de archivos. :)

Creo que sería genial si pudiéramos agregar la capacidad de ir y venir en el historial usando shift+cmd+[ y shift+cmd+] . Estos son los atajos predeterminados para navegar por las pestañas en otras aplicaciones y poder usarlos para navegar por el historial. Creo que al menos me ayudaría mucho a convertirme en un creyente.

Editar: básicamente lo logró implementando

  { "key": "shift+cmd+[", "command": "workbench.action.openPreviousEditor" },
  { "key": "shift+cmd+]", "command": "workbench.action.openPreviousEditor" },
  { "key": "shift+cmd+[", "command": "workbench.action.quickOpenNavigateNext", "when": "inQuickOpen" },
  { "key": "shift+cmd+]", "command": "workbench.action.quickOpenNavigatePrevious", "when": "inQuickOpen" }

como combinaciones de teclas personalizadas

Creo que también sería útil poder arrancar una sección de código en una nueva ventana. Sin embargo, no estoy seguro de si eso es posible.

@JoshClose es totalmente posible, pero carecen de la infraestructura para la comunicación entre procesos para el editor en sí, por lo que para que dos instancias se comuniquen y hagan cualquier cosa, primero deben tener un protocolo para esto.

... las pestañas contienen un botón de cierre a la izquierda del nombre

¿Existe una razón específica para romper las convenciones? Al leer LTR, la información más importante es el nombre del archivo, no un botón de cierre. Moverlo hacia la derecha también facilitaría que los botones de cierre estén ocultos de forma predeterminada (y se muestren al pasar el mouse). En una etapa posterior, es posible que los usuarios también deseen tener iconos de archivo a la izquierda del nombre del archivo.

Discutimos las acciones para promover una pestaña de vista previa a una pestaña completamente abierta ...

Creo que las dos primeras opciones probablemente serían suficientes. Hacer doble clic en una pestaña puede resultar útil para otras cosas en el futuro.

Tenemos algunas ideas sobre cómo mostrar la ruta a un archivo para poder eliminar la ambigüedad en estos casos.

¿Qué tal simplemente mostrar una información sobre herramientas (con la ruta relativa) al pasar el cursor sobre una pestaña? Esto haría que el diseño fuera menos desordenado y las pestañas no tendrían que ser tan altas.

Mostramos un galón cada vez que hay un desbordamiento ...

Firefox maneja bien el desbordamiento de pestañas: tiene un ancho de pestaña máximo, botones de desplazamiento hacia la izquierda / derecha, menú desplegable que enumera todas las pestañas (con las pestañas actualmente visibles marcadas), etc.

Sería realmente bueno si los botones de cierre de pestañas coincidieran con las convenciones de la plataforma: a la izquierda en OS X, a la derecha en Windows.

Después de usar VSCode durante algún tiempo, creo que el modo _Working Files_ ha crecido en mí, ¡mucho!

Aquí hay algunas razones:

1. Aunque suene contrario a la intuición, cerrar un archivo que no estoy usando (ctrl-w) no lo saca de los archivos de trabajo. Esto es muy bueno porque muchas veces me encuentro volviendo a abrir archivos cerrados recientemente (en un proyecto React) cuando trabajo con archivos relacionados (o clases secundarias). Entonces, cuando _ siento_ que debería cerrar un archivo, no se asigna uno a uno al momento en que _ debería_ haberlo cerrado.
2. Me gusta el Force-Close explícito, que ofrece el workbench.files.action.closeFile .
3. He reasignado workbench.files.action.closeFile a Ctrl + k Ctrl + w porque requiere (un poco) menos esfuerzo que Ctrl + kw ,
4. Puedo ver el nombre completo del archivo y la ruta en la barra superior del editor -> Esto es muy importante en proyectos profundamente anidados (como yo) que tienen archivos con nombres similares o iguales ( index.js ?) Y solo La forma de diferenciar es por camino.
5. Menos ruido de pestañas = ¡Zen!

Entonces, en cierto modo, estoy tratando de decir que, por favor, no elimines el flujo actual si introduces el tema de las pestañas.

@kumarharsh, ¿por qué quitarían eso? en todo caso, probablemente lo mejorarán para usted. :)

Si el indicador sucio reemplaza al icono CERRAR, ¿cómo podremos cerrar el archivo si no queremos guardar nuestros cambios? ¿Seguirá estando disponible ctrl-w?

¿No podría el indicador sucio simplemente cambiar al botón de cierre al pasar el mouse?
Esa es una solución bastante común ...

El miércoles 4 de mayo de 2016 a las 11:28 p.m., rojorojo [email protected] escribió:

Si el indicador de suciedad reemplaza al icono de CERRAR, ¿cómo podremos
cerrar el archivo si no queremos guardar nuestros cambios? ¿Seguirá ctrl-w?
¿disponible?

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -216901750

@rojorojo estamos haciendo lo que también sugirió @anyong , así que no tendrás ningún problema. Y sí, Ctrl + W seguirá estando disponible.

Gracias por todos los comentarios.

Estamos realizando un estudio de UX sobre nuestros últimos diseños a finales de este mes. Si puede dedicar una hora el 25 o 26 de mayo y le gustaría participar en el estudio, regístrese aquí: https://calendly.com/stevencl/vs-code-docmgmt/

Desafortunadamente, solo puedo ofrecer horarios durante el día (horario de verano británico) y no puedo realizar sesiones por la noche.

Esperamos tener algunas partes funcionales que pueda probar, así como algunos esquemas de diseño que aún no hemos mostrado.

Espera, me encanta el comportamiento actual de la interfaz de usuario, ¿habrá alguna configuración?

Hace tres semanas tenía muchas ganas de pestañas. Incluso pospuse el cambio a VSC por un tiempo ya que no tenía pestañas. Ahora que he pasado un par de semanas usando VSC, ni siquiera quiero pestañas. En este punto creo que se interpondrían en mi camino.

Espero que cuando esto se construya sea opcional para que aquellos de nosotros que lo deseemos podamos continuar en el entorno actual.

Como alguien a quien realmente le gustan las pestañas verticales (escalan mucho mejor y funcionan mejor en pantallas panorámicas), me pregunto: ¿Por qué necesita tanto pestañas como "editores abiertos"? Si el último es básicamente "archivos de trabajo" con comportamiento de pestaña, entonces eso es todo lo que necesito / quiero.

Quiero agregar mi voto para asegurarme de que las pestañas sean opcionales. Realmente no me gustan las pestañas del editor y prefiero el panel en el lado izquierdo de la ventana. Entiendo que los agregue para las personas que los quieran, pero por favor, no nos los fuerce. No tenerlos es una de las cosas que me gusta de este editor.

Mis dos centavos: nunca quiero cerrar botones; para mí, son un desperdicio de bienes raíces que a veces causan frustración (clic accidentalmente). Es mucho más difícil hacer clic con el botón central accidentalmente que hacer clic accidentalmente 1 px demasiado a la izquierda.

También creo que los indicadores sucios son un desperdicio de bienes raíces. En Sublime Text, configuro "sucio" para cambiar el color de fuente de la pestaña. En el pasado, también lo hice en cursiva, pero parece que tienes planes para poner en cursiva las vistas previas.

El lado izquierdo del borde es demasiado ancho

@ be5invis @MrTravisB @rauschma @marcusrugger @jpaaso

Amigos, entiendo que es un hilo largo, por lo que probablemente no lo leyeron todo, pero lean las publicaciones por aquí . Las pestañas serán opcionales, los desarrolladores ya son muy, muy conscientes de los puntos que mencionas.

Posibles carteles: mire el hilo para ver si sus problemas ya se han abordado; cada vez que publica, hay un centenar de personas que reciben correos electrónicos con su: +1: Gracias

@anyong Sin embargo, el "Editor abierto" separa la lista de archivos de trabajo existente en dos mitades si abre dos columnas. Me encanta la idea de que solo haya un "archivo de trabajo" para todas las columnas del editor.
Haga esto opcional.

@ be5invis La única diferencia es que hay un separador visual. Aún puede arrastrar los archivos y abrirlos en cualquier editor que desee.

@anyong ¿Puedo ocultarlo? Y si elijo ocultar el "separador" y Ctrl-Tab en una columna del editor, ¿puedo cambiar a un archivo abierto en la otra columna? Lo que quieren los estafadores es mantener completamente el comportamiento existente.

@ be5invis del comentario que

Ctrl Alt Tab muestra una lista de todas las pestañas dentro de todos los grupos de pestañas

Entonces sí, aún puede configurar el enlace de teclas para mantener el comportamiento actual de Ctrl + Tab si lo desea.

@anyong Eso es bueno.
Pero aún así, ¿puedo ocultar el indicador "izquierda / derecha" y hacer que la lista parezca una unidad?

Esa sería una pregunta para @stevencl

¡Hurra! ¡Espero que tengamos pestañas pronto!

Buenas noticias ... estamos recibiendo pestañas ... pero no queremos perder la carpeta 'Archivos de trabajo'. ¿Mantenerla junto con las pestañas?

¡Increíble! Grupos de pestañas

@ be5invis Tiene razón, tenemos la intención de mostrar varios grupos de editores en la lista de editores abiertos una vez que divida el editor. Pero no es necesario hacer esto para poder trabajar con varios archivos. Dividiría el editor para ver más de un archivo a la vez. Si solo mantiene un editor visible en cualquier momento, aún puede tener varios archivos abiertos. Por ejemplo, en esta captura de pantalla

Tengo dos archivos abiertos, pero solo veo uno de ellos, ya que no he dividido el editor. La lista de editores abiertos muestra ambos archivos y puedo interactuar con ellos allí o mediante el control de desbordamiento en la parte superior derecha. (Y tenga en cuenta que aquí no se muestran pestañas; esta es la opción sin pestañas).

La razón por la que hemos hecho esto es que existe la posibilidad de confusión al administrar un archivo que está abierto en dos editores en la configuración de archivos de trabajo actual. Por ejemplo, en la captura de pantalla a continuación del producto actual, ¿qué debería suceder cuando cierro el archivo app.js en la lista de archivos de trabajo? ¿Deben cerrar ambos editores o solo uno de ellos? Y si es solo uno de ellos, ¿cuál?

Queremos evitar cualquier ambigüedad e incertidumbre, por lo que hemos optado por ser más explícitos sobre los archivos que están abiertos en cada grupo de editores.

Por eso también cambiamos el nombre de los archivos de trabajo a editores abiertos, ya que creemos que refleja mejor el nuevo comportamiento.

La opción Ir a la definición (F12) debe mejorarse (incluso la Definición está en otra página del proyecto)) como texto sublime? Estoy enfrentando este problema desde hace mucho tiempo que instalo el código VS?

@ vinod-a-ext: abra un nuevo número que describa el problema al que se enfrenta con Ir a definición.

@stevencl
Ir a Problema de definición en el código VS
https://github.com/Microsoft/vscode/issues/6238

@stevencl Mi opinión es que puedes ocultar las etiquetas en el “editor abierto” y simplemente dibujar una línea para representar diferentes paneles. Una vez que se cierra un panel, se pueden fusionar dos listas de forma natural.

Gracias por la sugerencia, definitivamente exploraremos diferentes tratamientos visuales para esto.

Fecha: martes, 10 de mayo de 2016 04:06:34 -0700
De: [email protected]
Para: [email protected]
CC: [email protected]; menció[email protected]
Asunto: Re: [Microsoft / vscode] Pestañas adecuadas para archivos abiertos (# 224)

@stevencl Mi opinión es que puedes ocultar las etiquetas en el “editor abierto” y simplemente dibujar una línea para representar diferentes paneles. Una vez que se cierra un panel, se pueden fusionar dos listas de forma natural.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub

Tengo curiosidad, ¿qué programa usaste para generar las maquetas, como esta?

Usamos PowerPoint para estas maquetas. Nuestra intención era centrarnos en el flujo de interacción, no en el diseño visual, por lo que las herramientas de PowerPoint funcionan bien para ese nivel de detalle. Hacer cosas en PowerPoint también nos permite unir fácilmente una secuencia de pantallas para tener una mejor idea del flujo.

Fecha: martes, 10 de mayo de 2016 05:03:55 -0700
De: [email protected]
Para: [email protected]
CC: [email protected]; menció[email protected]
Asunto: Re: [Microsoft / vscode] Pestañas adecuadas para archivos abiertos (# 224)

Tengo curiosidad, ¿qué programa usaste para generar las maquetas, como esta?

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub

Vine aquí después de ver las notas de la versión de abril. Hilo abierto durante mucho tiempo, pero soy +1 para el diseño original, es decir, sin pestañas. Al principio me molestó, pero luego llegué a apreciar y comprender la filosofía detrás de esto ... Ahora, cuando pienso en Atom y el spam de pestañas ... me estremezco. Dejando todo eso a un lado, me encanta el compromiso y los comentarios reflexivos y los comentarios de los desarrolladores.

Con ganas de probar esto. Una cosa que me encantaría ver es la combinación de varios archivos relacionados en una sola pestaña (similar a este complemento de VS )

Esto sería realmente útil para mantenerse organizado en el desarrollo de Angular 2, donde comúnmente tiene archivos relacionados:

• widget.component.css
• widget.component.html
• widget.component.ts
• widget.component.spec.ts

De acuerdo con @lucidtech , solíamos 'trabajar en la carpeta de archivos'. Creo que las pestañas se pueden combinar con esta gran opción.

Estoy de acuerdo con @coreh en que la ubicación del botón Cerrar pestaña debe coincidir con las convenciones de la plataforma. Sería un cambio de contexto bastante frustrante que la ubicación del botón de cierre cambie cuando me muevo de Visual Studio a Visual Studio Code.

Mis dos centavos: una de las razones por las que me encanta Code sobre Atom, Sublime o cualquiera de los otros editores hipster, ejem, es que no intenta zapatear en el concepto de "pestaña" del navegador web. Los IDE tradicionales como Visual Studio, IDEA y Eclipse también hacen esto. El código, por otro lado, tiene un enfoque de "marcos y búferes", similar a lo que encontrarías en Emacs (y también en Vim, creo).

Inevitablemente, en cualquier editor basado en pestañas, me veo obligado a trabajar con resultados en los marcos de mi editor que son horriblemente spam con pestañas cuyas carpetas son tan pequeñas que no se pueden leer. Además, cuando utilizo el equivalente de un editor de este tipo a Ctrl / end-PI, termino deformando a otro marco como un artefacto de cualquier marco que estaba mirando cuando navegué por primera vez al archivo. Para ver el mismo archivo en otro marco, debe realizar una operación torpe de "pestaña dividida" que a menudo también suele ir acompañada de marcos divididos en muchos de estos editores. _Las pestañas acoplan estrechamente el estado del búfer de archivos con un marco determinado en la pantalla.

Si disculpa el atractivo emocional, _por favor_ no convierta VS Code en otro editor con pestañas.

Creo que, desde una perspectiva de UX, en lugar de implementar pestañas a ciegas para que coincidan con el comportamiento de Atom o cualquier otro editor, sería instructivo averiguar _por qué_ la gente quiere pestañas (además de una familiaridad cómoda) y ver si hay una solución más innovadora para sus necesidades es posible. Ciertamente estoy de acuerdo en que el régimen actual del espacio de trabajo puede seguir evolucionando: como alguien más ha mencionado abrir una ventana separada en el mismo proyecto (equivalente al "ripout" basado en pestañas) para aprovechar mejor las pantallas de múltiples cabezales, me viene a la mente.

editar: muy triste que perdí la llamada hace 19 días. Me habría unido si lo hubiera sabido. Solo se descubrió en las notas de la versión 1.1.0. :(

Las pestañas son una necesidad para mí y otra sugerencia para, por ejemplo, pestañas agrupadas angular 2.0 para archivos relacionados también es una gran idea. Si la función es configurable, aquellos cuyas preferencias sean diferentes también estarán felices. ¿Cuándo podemos intentarlo?

@orospakr , puede desactivar las pestañas en Sublime a través de una opción de menú. Solo para tu información.

@orospakr

Sería instructivo averiguar por qué la gente quiere pestañas (además de una familiaridad cómoda) y ver si es posible una solución más innovadora para sus necesidades.

Hay un montón de comentarios sobre por qué la gente quiere pestañas aparte de la familiaridad, sin mencionar que si es familiar y la gente se siente cómoda con él, entonces no tiene sentido ser creativo e innovar algo donde ya hay algo que funciona.

Intentaron innovar con los "archivos de trabajo" ya un grupo le gustó, al otro no le gustó y aquí estamos pidiendo pestañas. No creo que quieras que vuelva a ocurrir el mismo síndrome ...

La forma correcta de hacerlo es obtener la experiencia que las personas buscan primero y luego tener características adicionales, innovación o experimentos durante las compilaciones alfa y / o como una opción.

En este caso de pestañas / "editores abiertos" o mañana algo más, lo hicieron opcional y así debería ser la gente debe tener la capacidad de optar por participar en la experiencia o no participar.

Sé que llego un poco tarde al juego aquí, pero en lo que respecta a esta sección:

Discutimos las acciones para promover una pestaña de vista previa a una pestaña completamente abierta:

Editar contenido dentro de la pestaña
Hacer doble clic en un archivo en el explorador
Haga doble clic en la pestaña de vista previa en el grupo de pestañas

Me gustaría solicitar que "Agregar un marcador" se incluya en la lista anterior.
Me resulta extremadamente frustrante agregar un marcador a un archivo grande y luego, sin darme cuenta, hacer clic en otro archivo, cerrando el archivo de trabajo.

Es muy poco probable que haya agregado un marcador a un archivo que tengo la intención de cerrar de inmediato.

Revisé todos los comentarios que pude, buscando palabras clave y no encontré esto mencionado.

En cuanto a las pestañas, en primer lugar, _¡Gracias! _ Su ausencia es una de las únicas cosas que no me gustan de VS Code.

Me encantaría que la navegación entre pestañas sea personalizable; por ejemplo, me encanta la forma en que iTerm cambia entre pestañas presionando cmd + left , y también me gustaría mucho hacerlo en mi editor.

gracias por un gran editor <3

Las pestañas son imprescindibles para mí ... Volviendo a Sublime hasta que tengas pestañas. PD: Estoy muy decepcionado por su actitud; Parece que aún no tiene sentido de UX afirmando que esto se ha hecho para mejorar UX. ¿Cuáles son tus personajes? ¿Dónde están sus entrevistas con los usuarios? Pruébalo.

@asadighi , ¿leíste los comentarios antes de publicarlos? El equipo ha realizado extensas entrevistas y está realizando más para corregir las pestañas. Son increíblemente receptivos a la comunidad y están produciendo un gran editor (gratis). Buena suerte esperando el próximo lanzamiento de Sublime.

Tus comentarios anteriores hablan de tu parcialidad. Mi objeción está en la actitud que han tenido desde el principio. Las entrevistas con los usuarios deben realizarse ANTES de que las personas comiencen a criticar el producto por tal defecto. Es bastante interesante que pueda ver la duda de invertir para solucionar este defecto en nombre de una mejor UX. Este número ha estado abierto desde noviembre y durante gran parte de ese tiempo la mayoría de las respuestas están en línea con nosotros sabemos mejor que usted cómo debe hacer su trabajo.

@asadighi Está todo en tu cabeza y tus tonterías se muestran en tus comentarios, detente.

@muellerkyle : +1: debe crear un problema con la extensión de marcador que usa.

Espero esta característica

+1!

Diariamente, cambio entre Eclipse, PhpStorm, Notepad ++ y VSCode. Adivina qué, CTRL+W me vuelve loco.

Llego tarde a esta fiesta, pero ¿las pestañas serán opcionales? Solía ​​pensar que los extrañaba, pero ahora no. Solo tengo curiosidad por saber si habrá una manera de ocultarlos. No odio hacia las pestañas y las personas que quieran usarlas, solo piense que preferiría un interruptor para mostrar / ocultar. Todo eso sigue con el gran trabajo. Amo vscode.

@jamesmenera sí, será opcional, pero también lo son los archivos de trabajo (editores abiertos).

como acotación al margen, ¿divulgaría qué programa utilizó para hacer esas maquetas?

@ciel , @stevencl escribió que usaron PowerPoint para ello.

Personalmente, me encanta WireframeSketcher para hacerlo, pero PowerPoint también puede funcionar. :)

Tal como mencionó @jamesmenera, realmente extraño las pestañas y la barra lateral, pero puedo ver que a muchas personas les gusta el enfoque de Archivos de trabajo, por lo que debería ser opcional.

@ kadza93 tanto las pestañas como los archivos de trabajo serán opcionales ... Me pregunto cuántas veces lo voy a escribir.

Es muy fácil hacer una búsqueda y buscar la palabra "opcional", ¡te llevará menos tiempo encontrarla que escribir una publicación sobre ella!

@eyalsk ¡ Me pregunto por qué la llama! Estoy aquí para expresar mi necesidad y, en la medida de lo que puedo ver, la necesidad de muchas pestañas, así que al apoyar lo que otros dijeron y aceptarlo, ¿estoy haciendo algo mal? Por cierto, gracias por el consejo sobre la función de búsqueda, debería usarlo más en hilos largos donde quiero expresar mi opinión y si alguien ya expresó algo similar al mío, simplemente lo omitiré.

Estaba solo a 3 de tu publicación ...

Siguiendo este hilo, me parece que ya hay algunas decisiones tomadas en las pestañas para una versión futura (las pestañas son opcionales, donde se mostrarán los iconos, combinaciones de teclas, etc.). Si no me equivoco, ¿hay una lista de estas decisiones a las que se pueda señalar a las personas?

@jtlowe , sin

¿Quizás los administradores pueden poner un banner "ESTADO ACTUAL: EN DESARROLLO" en la parte superior de la página del problema (debajo del cuerpo del problema del OP)?

Esta debería ser una característica adecuada en github --- algo como sugiere el texto alternativo aquí: https://xkcd.com/979/

@ kadza93 No

Estoy aquí para expresar mi necesidad y, en la medida de lo que puedo ver, la necesidad de muchas pestañas, así que al apoyar lo que otros dijeron y aceptarlo, ¿estoy haciendo algo mal?

No, no hiciste nada malo pero tampoco escribiste nada útil, la función de emoticonos / reacción existe específicamente por esta razón.

Por cierto, gracias por el consejo sobre la función de búsqueda, debería usarlo más en hilos largos donde quiero expresar mi opinión y si alguien ya expresó algo similar al mío, simplemente lo omitiré.

Sí ... ¡tiene mucho sentido, me refiero a expresar una opinión sobre algo que se confirmó! y ni siquiera necesitabas buscarlo porque le respondí a la misma persona a la que le diste el visto bueno.

Generalmente, es de sentido común buscar palabras comunes probables en una publicación larga.

Realmente los desarrolladores deberían abrir un nuevo problema con preguntas frecuentes y detalles tomados de
los puntos más comunes en este hilo y cierre este problema. Personas
suscrito a este problema reciben docenas de correos electrónicos todos los días para
los mismos comentarios de "pulgar hacia arriba" / "pulgar hacia abajo".
El 18 de mayo de 2016 a las 1:51 a. M., "Kumar Harsh" [email protected] escribió:

Quizás los administradores puedan poner un banner "ESTADO ACTUAL: EN DESARROLLO" en
la parte superior de la página de problemas (debajo del cuerpo de problemas del OP)?

Esta debería ser una característica adecuada en github --- algo como el texto alternativo
aquí sugiere: https://xkcd.com/979/

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -219798727

@anyong sí, estoy completamente de acuerdo! no hay nada que discutir y una vez que tabs y open editors estén activos, deberían crear dos problemas separados para recibir comentarios sobre estas características.

@eyalsk todavía estamos experimentando con cómo manejar las actualizaciones sobre los problemas creados por la comunidad. Hay muchas formas de hacer esto, pero todas son malas sin una función de comentario fijada en GitHub. El problema del terminal integrado https://github.com/Microsoft/vscode/issues/143#issuecomment -213581854 ha estado bien hasta ahora con una gran actualización en el medio del hilo, supongo que tiene que ver con menos necesidad de discusión por lo que no ha sido enterrado.

@Tyriar bueno, puedes hacer referencia a publicaciones, entonces, ¿no puedes simplemente crear nuevas publicaciones y hacer una referencia a las antiguas cerrándolas? Creo que así es como lo hacen los chicos que trabajan en Roslyn y luego tienen una publicación que resume todas las características para los próximos lanzamientos, pero no obstante, estoy de acuerdo contigo, los comentarios fijados pueden ser extremadamente útiles.

Hemos estado trabajando en la implementación de diseños para pestañas y grupos de editores en este hito y continuaremos haciéndolo en el próximo hito.

Gracias a todos los que participaron en el estudio UX estos últimos días. Recibimos excelentes comentarios de usted que nos han ayudado a realizar algunas mejoras en la experiencia:

• Rediseñar el icono de desbordamiento
• Proporcionar una configuración para elegir si los archivos de apertura rápida se anclan o se previsualizan
• Agregar un comando para convertir un archivo de vista previa en un archivo anclado

Lo siento, si me perdí eso, pero ¿cómo habilitamos las pestañas? ¿Están disponibles en la última versión de información privilegiada, como la tengo, pero no hay rastro de pestañas allí? También sigo viendo 'archivos de trabajo' en el explorador, aunque parece que debería reemplazarse por 'Editores abiertos' como se indica en # 6536.

@lllopo aún no están disponibles. Las pilas / editores abiertos se fusionaron para la v1.3.0 y estarán disponibles en Insiders la próxima semana cuando las compilaciones diarias estén disponibles.

+1

+1

👎

¿Qué está pasando aquí, por qué se resiste a darnos la opción de usar pestañas? 😕
A tanta gente le gustan las pestañas, incluyéndome a mí, ¡danos la maldita opción PERIODO!

@aminroosta En serio ... ¿no sabes leer? ¿estás ciego?

Lo curioso es que estás preguntando qué está pasando aquí ... y luego continúa y asume que en realidad lo rechazan o, en tus propias palabras, "se resisten" cuando en realidad confirmaron que las pestañas están llegando y ¡están trabajando para implementarlo!

¡Algunas personas en este mundo! ¡increíble!

@eyalsk
Pasé 25 minutos leyendo los primeros 20 a 30 comentarios.
Me cansé y dejé un comentario que ahora parece ser un error de mi parte.

Lo siento por eso.

No podemos culpar a la I + D de microsoft por intentar innovar. El sistema de pestañas tiene contras.

El diseño de la interfaz de usuario es como toda forma de diseño. 90% haciendo lo que espera el usuario, 10% haciendo cosas nuevas, intentando crear un nuevo sistema revolucionario y amigable.

Todo el sistema fácil de usar que se considera imprescindible en el nuevo editor de texto de hoy ha sido experimentado y controvertido antes.

@aminroosta Te daré un consejo, cuando estés leyendo una publicación larga, lee la publicación original y luego, para obtener las últimas actualizaciones, dedica un minuto más o menos a desplazarte de abajo hacia arriba.

Esa es una buena sugerencia ya que este es un feed MUY largo.

El domingo, 5 de junio de 2016 a las 10:42 a. M. Eyal Solnik [email protected]
escribió:

@aminroosta https://github.com/aminroosta Te daré un consejo, cuando
estás leyendo una publicación larga, lee la publicación original y luego para obtener la
las últimas actualizaciones pasan aproximadamente un minuto desplazándose de abajo hacia arriba.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -223826495,
o silenciar el hilo
https://github.com/notifications/unsubscribe/AAInRHy6TDR-opr-8ZKmW-lRUgZDOP21ks5qIwqIgaJpZM4GljE8
.

Personalmente, me gusta el enfoque Ctrl + Tab. Desde mi experiencia personal, las pestañas pueden complicarse rápidamente si tienes más de 10 abiertas al mismo tiempo. Yo diría que elimine los "archivos de trabajo" o al menos déjelo como opción. No lo uso y me confunde. Usaré Ctrl + Tab desde aquí, gracias!

@adred Tanto Working files (ahora llamado Open editors ) como Tabs van a ser opcionales hasta donde yo sé.

@bpasero

¿Puedes _por favor_ bloquear este hilo y abrir uno nuevo con los bits importantes copiados en él? Todavía hay comentarios que llegan a diario de personas que no pueden leerlo todo (deberían decirte que es demasiado largo) y que hacen la misma pregunta una y otra vez, y una vez que el lanzamiento de pestañas llegue a las compilaciones públicas, vamos a vea aún más spam en este hilo.

Quiero estar al día sobre los acontecimientos relacionados con las pestañas, y este hilo es actualmente el lugar para hacerlo, pero es muy molesto recibir correos electrónicos no deseados varias veces al día con los mismos comentarios una y otra vez.

Disculpas por el tono y gracias.

Hay tantos +1 que es demasiado.

El lunes 6 de junio de 2016 a las 2:16 a. M. -0700, "anyong" [email protected] escribió:

@bpasero

¿Puedes _por favor_ bloquear este hilo y abrir uno nuevo con los bits importantes copiados en él? Todavía hay comentarios que llegan a diario de personas que no pueden leerlo todo (deberían decirte que es demasiado largo) y que hacen la misma pregunta una y otra vez, y una vez que el lanzamiento de pestañas llegue a las compilaciones públicas, vamos a vea aún más spam en este hilo.

Quiero estar al día sobre los acontecimientos relacionados con las pestañas, y este hilo es actualmente el lugar para hacerlo, pero es muy molesto recibir correos electrónicos no deseados varias veces al día con los mismos comentarios una y otra vez.

Disculpas por el tono y gracias.

Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/Microsoft/vscode/issues/224#issuecomment -223906131

Solo un comentario sobre el texto de actualización @ https://code.visualstudio.com/updates#_workbench

El texto no me quedó claro y de hecho pensé que las pilas actualizadas ya estaban aquí (y que las pestañas vendrían más tarde). Después de la actualización, no vi las pilas actualizadas y tuve que volver a leer el texto varias veces.

Para mí, dice que las pestañas tomarán más iteraciones (por lo que no hay pestañas en _esta_ actualización), pero que en mayo hiciste un gran progreso en cómo administrar las pilas de editores (así que a pesar de que no hay pestañas, ¿las pilas actualizadas _ están_ en esta actualización?) y que hay más trabajo por hacer para la rama de lanzamiento de junio (¿para mejorar aún más las pilas?).

Entonces, para cualquiera que haya estado confundido como yo ... parece que las pilas actualizadas no están realmente en esta actualización. Supongo que es solo una vista previa de las pestañas y las pilas por venir.

Estoy de acuerdo con @RyanEwen. Realmente aprecio el desarrollo abierto y la cantidad de comunicación, pero estos anuncios que forman parte de las "Notas de la versión" oficiales son realmente confusos.

Tal vez esto se pueda dividir en notas de lanzamiento reales y 'en lo que estamos trabajando ahora' o algo así.

Vincular este tema en la Hoja de ruta no ha sido una buena idea porque si lo lees desde la primera vez no tendrás una idea clara del estado actual (más que el Hito). Todavía hay trabajo por hacer, pero el estado actual es correcto: +1:

Sí, deberían resumir los problemas y luego tener enlaces a estos resúmenes para que la gente conozca el plan actual después de que se haya discutido.

La vinculación a las discusiones es mala porque tienden a ser largas y la gente no puede captar la idea sin leer casi todo, pero no sé, tal vez no sea posible que lo hagan de otra manera.

Cuando comencé a leer las notas de la versión 1.2, lo primero que busqué fue _la función de pestaña_. Aprecio que hayan puesto el estado actual allí. Pero también me confundí. Al principio pensé que había aterrizado, pero me di cuenta de que no, pero se avanzó mucho. En ese caso, parece que ese elemento debería estar al final de las notas de la versión con un enlace a la discusión o un hito (ambos demuestran el progreso de la función) junto con una pequeña nota que dice algo como _ progreso hacia la implementación de Tabs "_.

Independientemente de esta pequeña cosa. Buen trabajo en el lanzamiento. VS Code es un gran producto con un ciclo de desarrollo asombroso.

VSCode se acaba de actualizar a 1.3.0-insider. Parece que los archivos recientes se han ido. ¿Hay alguna forma de hacer eso ahora?

Gracias por los comentarios sobre las notas de la versión y perdón por la confusión. Hice modificaciones en el documento para dejar en claro que el trabajo no está en Estable, pero que puede obtener una vista previa del trabajo de la pestaña en la versión de Insiders .

Tener una sección hacia el final donde hablemos del trabajo realizado pero no en la construcción estable es una buena idea y lo haremos el próximo mes si tenemos más trabajo que quepa en ese grupo.

@JoshClose , abra un nuevo problema para esto, ya que en breve bloquearé este problema a favor de problemas individuales en lugar de este único hilo. gracias.

Primero, permítanme agradecerles a todos una vez más por sus pensamientos, me gusta y no me gusta acerca de las pestañas. Los comentarios que hemos visto en este hilo (tanto positivos como negativos) realmente muestran lo apasionados que están las personas con el futuro de VS Code.

Creo que todos pueden estar de acuerdo en que hemos agotado la utilidad de este tema y, como resultado, voy a bloquear la conversación. Dejaremos este problema abierto hasta que enviemos con una opción para pestañas / sin pestañas, lo que planeamos hacer para fines de la iteración de junio de 2016 .

Si bien el equipo de VS Code _ puede_ publicar actualizaciones en este número, debe esperar que creemos nuevos problemas para diseños de pestañas o discusiones adicionales. Marcaremos los problemas con la etiqueta tabs para facilitar la consulta. Usted también puede abrir una nueva pestaña para problemas específicos y esperamos sus comentarios sobre los problemas específicos, ya que juntos construimos las mejores experiencias posibles.

Gracias de nuevo, ahora ve e instala Insiders Release !

https://github.com/Microsoft/vscode/issues/6605 documenta todos los identificadores de comando agregados o modificados para usar con las combinaciones de teclas. Debido a que el modelo de pilas es un cambio tan grande en la interfaz de usuario de VS Code, decidimos volver a visitar todos los comandos relacionados con editores o grupos.

Nos complace anunciar que ahora puede habilitar pestañas en nuestras compilaciones internas nocturnas (http://code.visualstudio.com/Download#insiders). La configuración relacionada es workbench.editor.showTabs . Consulte nuestras notas de la versión para obtener más detalles sobre el concepto de pilas de editor, editores de vista previa y pestañas.

Todavía hay algo de trabajo planeado en esta área hasta fin de mes (y probablemente más allá), por lo que nos complace recopilar comentarios de los expertos. No dude en abrir problemas a medida que los encuentre mientras usa las pestañas.

¡Gracias!

Como @bpasero ha mencionado, ahora puede habilitar pestañas en nuestras compilaciones internas nocturnas.

Si ha probado esto y puede dedicar 30 minutos para compartir sus comentarios, regístrese para un chat aquí: https://calendly.com/stevencl/vs-code-tabs/

Lamentablemente, solo puedo ofrecer franjas horarias durante el día (estoy en Edimburgo, Escocia) los lunes y martes de la próxima semana.

tl; dr; habilitar pestañas en la compilación interna de VS Code con workbench.editor.showTabs: true

Estamos cerrando para el hito de junio durante esta semana con nuestras pruebas habituales de finales. Las pestañas están en el plan de prueba (https://github.com/Microsoft/vscode/issues/7854) y obtendrán algo de cobertura durante la semana. Todavía esperamos hacer arreglos en las pestañas para junio y posiblemente refinamientos basados ​​en comentarios posteriores a junio. Sin embargo, la mayor parte del trabajo está hecho, así que cerraré este tema.

A partir de la descripción de este elemento de trabajo, @TurkeyMan solicita tener pestañas y una forma de mover una pestaña fuera del banco de trabajo para abrirla dentro de una nueva ventana. He extraído este último en https://github.com/Microsoft/vscode/issues/8171 ya que no está relacionado con el trabajo de pestañas que hicimos.

Continúe presentando problemas en las pestañas tal como los ve mientras los prueba. ¡Gracias por ayudar a probar la compilación de información privilegiada!