Vscode: Abas adequadas para arquivos abertos

+1

Seria possível adicionar guias por meio de uma extensão personalizada? Eu rapidamente olhei para os documentos, mas não parecia possível adicionar esse tipo de funcionalidade com a API atual

Seria possível adicionar guias por meio de uma extensão personalizada?

Não, no momento isso não é possível a partir de uma extensão (consulte também http://code.visualstudio.com/docs/extensions/our-approach)

+1

: +1:

: +1:

+1

As guias são a forma padrão de trabalhar mesmo no Visual Studio, sem mencionar outros editores de texto, como o sublime.

Para aqueles que não têm guias, você tentou usar Ctrl+Tab para navegar no histórico de arquivos abertos?

Sim. Mas o arquivo permanece no contexto Ctrl+tab mesmo depois de fechar o arquivo. A experiência não é a mesma do Sublime / Atom.

@snehilmodani certo, ajudaria se a lista mostrasse apenas o que você tem na seção de arquivos de trabalho do explorer? você pode trabalhar com a lista de arquivos de trabalho, pelo menos?

Isso seria bom!

Em uma nota lateral: não é um layout com nomes de arquivo como guias mais amigável. É extensível ter uma ou mais seções de guias, cada uma com seu próprio conjunto de arquivos abertos. (Novamente, estou tomando Sublime Text como referência aqui)

Acho que ter guias ou não é independente de ter seções. Hoje você pode abrir até 3 editores lado a lado no VS Code e, portanto, temos seções. Como não temos guias, não adicionamos vários arquivos a essas seções e você também não pode ter seções vazias (que é uma discussão de UX separada).

Voltando ao Ctrl + Tab: Nós da equipe sempre trabalhamos sem guias desde o primeiro dia e, na verdade, nem mesmo tínhamos a visualização dos arquivos de trabalho por muito tempo e, na verdade, poucas pessoas na equipe estão usando. Descobrimos que, para nós, não importa muito qual arquivo você abriu ou fechou. Em vez disso, nossas mentes estão pensando sobre a ordem cronológica do arquivo que editamos por último. Então, quando eu abrir Ctrl + Tab, ele normalmente me mostrará os arquivos que estava usando por último. Não estou realmente olhando para o número de arquivos lá, estou apenas interessado nos 5 principais no máximo. A vantagem deste modelo é que você não precisa gerenciar layouts e guias. O gerenciamento acontece naturalmente enquanto você navega entre os arquivos.

Podemos adicionar um seletor de arquivos para arquivos de trabalho, mas seria interessante ouvir se as pessoas podem ser convencidas a usar Ctrl + Tab como é hoje e aprender quais são os problemas.

@bpasero Vou dar uma chance a ctrl+tab , acabei de perceber que pode ser usado para ir para o arquivo anterior, que é algo que eu queria e não tinha examinado ainda até agora. Então isso é bom.

A propósito, independentemente de alguém poder usar / usar ctrl+tab como alternativa às guias, os novos usuários do código VS provavelmente ficarão desanimados pela falta de guias, então, se apenas por razões de compartilhamento de mercado recomendo ter uma opção de guias. Todos os outros editores usam guias (para melhor ou pior), e não tê-las introduz uma barreira de entrada bastante desnecessária para o código do VS. Estou usando o código VS, independentemente do suporte a guias, por causa de seu incrível suporte à digitação, mas se não fosse por isso, não sei se teria continuado a usá-lo nas primeiras vezes que tentei.

Sim, Ctrl+Tab tem tudo a ver com navegar de volta na história dos arquivos que estão sendo trabalhados. Você pode pressionar e segurar a tecla Ctrl e pressionar Tab repetidas vezes para voltar além de 1 arquivo.

Ctrl+tab é uma coisa maravilhosa de se ter e sou totalmente fã disso. É algo que até o Atom perde.

Com relação às guias e vários arquivos em cada seção: Mesmo no Sublime Text, podemos abrir 3 editores lado a lado, mas eles ainda oferecem um layout com guias seccionais. Eu concordo com você sobre a desordem e gerenciar o layout do editor seria uma tarefa e tanto, mas as pessoas estão acostumadas com isso de qualquer maneira.
Eu adoraria fazer parte de um experimento social no qual você está tentando nos convencer a nos livrar de nossas confusas interações baseadas em layout com nossos editores.

Eu concordo com você sobre a desordem e gerenciar o layout do editor seria uma tarefa e tanto, mas as pessoas estão acostumadas com isso de qualquer maneira.

Bem, tenho certeza que podemos encontrar mais exemplos de UX onde estávamos acostumados com algo e depois nos acostumamos com algo muito melhor :). Pense no teclado do telefone móvel vs interação de toque do smartphone.

Eu adoraria fazer parte de um experimento social no qual você está tentando nos convencer a nos livrar de nossas confusas interações baseadas em layout com nossos editores.

Sim, acho que precisaremos fazer algo como este 2016. @stevencl fyi

Com relação às guias e vários arquivos em cada seção: Mesmo no Sublime Text, podemos abrir 3 editores lado a lado, mas eles ainda oferecem um layout com guias seccionais.

Eu concordo com uma opção para permitir seções mais estáveis ​​para que possamos ter seções vazias, mas poder ver as guias nesta seção é apenas uma representação visual dos arquivos lá que na maioria dos casos cresce tanto que você acaba não vendo nada. Não acho que as guias sejam uma boa maneira de mostrar a lista de arquivos abertos, a menos que você gerencie essas coisas ativamente e as feche.

Não acho que as guias sejam uma boa maneira de mostrar a lista de arquivos abertos, a menos que você gerencie essas coisas ativamente e as feche.

Algumas pessoas realmente os gerenciam e, para outras, há guias fechadas à direita.

Muito obrigado pelo feedback.

Temos um problema em nosso backlog de UX (# 1133) para melhorar o gerenciamento do espaço de trabalho (gerenciamento de arquivos abertos, histórico, etc.), do qual isso seria um problema. Nossa intenção é melhorar a experiência de forma que o gerenciamento da lista de arquivos abertos e recentes seja direto e fácil e permita que o usuário se concentre em seu código, sem ter que prestar atenção indevida à interface do usuário do VS Code.

Nossa hipótese é que o sistema atual tem algumas arestas (por exemplo, fechar um editor na verdade fecha o editor, mas achamos que talvez ele deva mostrar o arquivo que foi aberto anteriormente nesse mesmo editor) e que suavizar essas arestas irá ajudar a criar uma experiência muito melhor.

Fazemos estudos de UX sobre o produto regularmente. Na verdade, é assim que projetamos grande parte da experiência do usuário no produto. Nós iteramos nossos designs com base em feedback real, certificando-nos de que usamos um ótimo entendimento do que as pessoas fazem e querem fazer com o produto para informar nossos designs.

Se você quiser participar desses estudos no futuro (não teremos nenhum novamente até meados de janeiro, no mínimo), me avise e eu adicionarei seu nome à lista.

Se você quiser participar desses estudos no futuro (não teremos nenhum novamente até meados de janeiro, no mínimo), me avise e eu adicionarei seu nome à lista.

Me inscreva!

Não acho que as guias sejam uma boa maneira de mostrar a lista de arquivos abertos, a menos que você gerencie essas coisas ativamente e as feche.

O gerenciamento de guias é uma parte inconsciente e desinibidora do meu desenvolvimento. O VS-Proper tem pequenas abas discretas, que não são intrusivas (vscode já tem o nome do arquivo ocupando espaço onde a aba estaria). Eu concordo que o spam de guia descontrolado é um problema, pode ser bom inovar e resolver isso, mas eu diria que é uma prioridade menor do que ter guias. O VSCode precisa atingir um estado mínimo de funcionamento. No momento, acho que está chegando perto, mas ainda não consigo trabalhar de forma produtiva. Começar com padrões estabelecidos provavelmente nos faria trabalhar mais cedo.

Vale a pena ter em mente que nem todo mundo é desenvolvedor da Web. Acho que os padrões e o fluxo de trabalho tendem a ser ligeiramente diferentes para diferentes linguagens e estilos de aplicativo. Como um desenvolvedor nativo, é comum ter um conjunto de arquivos associados visíveis; cpp + h , talvez também um inl , e você normalmente não trabalha em apenas um arquivo isolado. Freqüentemente, tenho uma visão de desmontagem visível ao lado do código. Meu ambiente de editor abrange 2 monitores, com 4 arquivos visíveis a qualquer momento, e eu teria dificuldade em trabalhar em um ambiente mais restrito do que isso.
Também sinto falta de poder pegar uma guia e rasgá-la em uma pequena janela flutuante, que costumo definir como "sempre no topo", que geralmente é usado como um ponto de referência, ou algo que estou copiando muito / passando para / de.

Agora, por exemplo, estou tentando refatorar e simplificar alguns códigos legados; meu conjunto de arquivos de trabalho atual é ... component.cpp, component.h, component.inl, componentimpl.cpp, componentimpl.h, icomponent.h. São 6 arquivos! E não posso escapar do ajuste ocasional de alguns outros arquivos na periferia. Eu uso ctrl-tab liberalmente quando estou trabalhando nesse estilo de projeto (alternando entre 2 arquivos), mas neste contexto / base de código, simplesmente não consigo trabalhar sem guias.

Refatorar e manter o código legado tem um fluxo de trabalho muito diferente de escrever um novo código (o que eu imagino que vocês estão fazendo, e usando principalmente como uma diretriz para design de UX).

Meu ponto aqui é; existe um desejo moderno de reinventar tudo, e vimos grandes avanços no design UX nos últimos anos; O vscode já apresenta alguns deles, mas seja cuidadoso e use o bom senso ao decidir mudar a maneira como as pessoas vêm trabalhando há décadas. Muitos designs estabelecidos são estabelecidos porque são bons e eficientes, não porque sejam antigos e precisem de atualização para ficarem mais na moda :)

Eu apreciaria a oportunidade de fazer parte desses estudos focais!

Meu ponto aqui é; existe um desejo moderno de reinventar tudo, e vimos grandes avanços no design UX nos últimos anos; O vscode já apresenta alguns deles, mas seja cuidadoso e use o bom senso ao decidir mudar a maneira como as pessoas vêm trabalhando há décadas.

É o meu caso. Na verdade, não consigo trabalhar sem guias. Trabalho com sistema de abas há anos e, sem elas, estou realmente perdido. Esse é um dos motivos pelos quais não estou usando o Code.

Muitos designs estabelecidos são estabelecidos porque são bons e eficientes, não porque sejam antigos e precisem de atualização para ficarem mais na moda :)

: +1:

Até agora, ainda não ouvi um bom motivo para abas em comparação a ter apenas uma lista de "arquivos de trabalho" em algum lugar. Ser capaz de pegar um arquivo e arrastá-lo para uma nova janela claramente não é um benefício de um sistema de abas, é um recurso que você pode ter sem abas.

As pessoas realmente desejam abrir arquivos em guias, movê-los e eventualmente fechá-los? Isso é porque você está tão acostumado com isso ou há realmente um valor em fazer isso? O valor é capaz de definir um conjunto de arquivos de trabalho ativo que você mais tarde descarta para iniciar algo novo? Eu me pergunto o que há de tão bom em ter guias que você não consegue com outra forma de representação. E não estou aceitando o argumento de que todo mundo está acostumado com tabs :). Muitas pessoas estão acostumadas a salvar arquivos e ainda existem editores com capacidade de salvamento automático e as pessoas parecem gostar.

Mesmo que não seja por padrão, dar ao usuário a opção de ativar o recurso de guias por meio de alguma opção seria quase tão bom para mim.

Por exemplo, que tal deixar o usuário mover / arrastar a seção "Arquivos de trabalho" para o topo (convertendo-os em guias, digamos). Novamente, o usuário pode escolher como deseja trabalhar e eu acho isso ótimo!

Para mim, não é tanto a aparência das guias quanto o comportamento delas que sinto falta. (Por exemplo, você pode fazer com que o Sublime Text se pareça com o VS Code, pois pode ocultar a barra de guias e mostrar os arquivos abertos na barra lateral ... mas eles ainda se comportam exatamente como as guias.)

A primeira coisa que faço com o VS Code é trocar seu arquivo fechado e fechar os atalhos de teclado do editor ativo, de modo que ctrl + W realmente feche um arquivo quando eu pressiono, ao invés de ainda deixá-lo em arquivos de trabalho e bagunçando ctrl + tab.

Mas mesmo assim, cada vez que fecho um arquivo, sou saudado com uma tela em branco e tenho que ctrl + tab apenas para mostrar o arquivo de trabalho ainda aberto mais recente (droga, quando é o último, parece que também preciso pressione Enter após ctrl + tab; não tenho certeza do que se trata). Em qualquer outro editor, eu seria imediatamente saudado pelo arquivo aberto mais recente ou adjacente (guia) ao fechar o atual.

Além disso, ctrl + tab entre os arquivos de trabalho parece funcionar na ordem mais recente, ao contrário das guias que geralmente operam na ordem em que aparecem ou são organizadas. (Eu vi alguns editores apoiarem ambos.)

Eu não uso janelas divididas, então, se alguma dessas diferenças comportamentais tiver algo a ver com isso, não sei. Talvez eu entendesse melhor se entendesse desse ângulo, mas o no-split ainda não seria o caso de uso mais comum?

De qualquer forma, são pequenos atritos, mas frequentes como esses, que me mantêm longe do VS Code e voltando para outros editores. Sim, você poderia dizer que o VS Code opera de maneira diferente do que estou acostumado. Mas quando o que estou acostumado a _funciona_ e o VS Code operando de maneira diferente causa atrito que eu preferiria usar um editor diferente para evitar ter que lidar com isso, é um grande negócio.

Sim, posso ver um modelo em que a área do editor se comporta de forma semelhante às guias sem mostrar as guias. Queremos explorar isso no próximo ano.

Aliás, há uma extensão que - uma vez que você fecha um editor - abre o próximo dos arquivos de trabalho. Se você combinar isso com a alteração do atalho de teclado como @kfranqueiro sugere, você chega bem perto do imho.

Aqui está o link: https://marketplace.visualstudio.com/items/bigous.file-smart-reopener-vscode

Até agora, ainda não ouvi um bom motivo para abas em comparação a ter apenas uma lista de "arquivos de trabalho" em algum lugar. Ser capaz de pegar um arquivo e arrastá-lo para uma nova janela claramente não é um benefício de um sistema de abas, é um recurso que você pode ter sem abas.

Claro, pode ser possível fazer de uma maneira diferente ... mas por quê? A menos que você tenha alguma melhoria ou inovação significativa a oferecer.

As pessoas realmente desejam abrir arquivos em guias, movê-los e eventualmente fechá-los?

sim

Isso é porque você está tão acostumado com isso ou há realmente um valor em fazer isso?

Em parte hábito, mas também porque ninguém apresentou ainda nada significativamente superior. A inovação deve representar uma vantagem significativa se for para insistir que as pessoas lutem e se retreinem contra seus hábitos de décadas atrás.

O valor é capaz de definir um conjunto de arquivos de trabalho ativo que você mais tarde descarta para iniciar algo novo?

Não tenho certeza se entendi essa frase exatamente; você está tentando descrever uma alternativa em que trabalha em termos de vários conjuntos de 'arquivos de trabalho'? Difícil de imaginar. Não tenho certeza se isso seria universalmente útil. Para tarefas legadas, de manutenção e de reformulação, acho que seria uma grande desvantagem trabalhar dessa maneira, já que seu conjunto de trabalho geralmente não é conhecido com antecedência, em vez disso, é emergente enquanto você trabalha. O modelo tradicional já funciona bem nesses fluxos de trabalho.

Eu me pergunto o que há de tão bom em ter guias que você não consegue com outra forma de representação.

De uma perspectiva diferente; considere a utilização do espaço. _Já existe_ uma guia no topo da janela de código, é onde está o nome do arquivo, apenas não tem o retângulo da guia ao redor do nome (até se comporta como uma guia; se você clicar com o botão do meio, fecha!). À direita do nome do arquivo acima da janela de código está um espaço desperdiçado vazio (onde deveriam estar as guias).
No canto superior esquerdo da área de trabalho está a lista de 'arquivos de trabalho'; este é um espaço duplamente desperdiçado, pois simplesmente não precisa existir, seu espaço pode ser movido para a lacuna onde as guias geralmente estão, preenchendo o espaço desperdiçado.

Também encontro outra diferença prática do que a utilização do espaço e a tendência habitual; Gosto de ter as guias associadas à janela do editor à qual estão vinculadas. Normalmente, tenho pelo menos 2, 3, frequentemente 4 janelas de código abertas (no vs adequado) e cada uma tem algumas guias associadas. Talvez em uma janela eu tenha widget.cpp/.h e na outra eu tenha gizmo.cpp/.h/.inl . Essas guias estão logicamente associadas à janela de código à qual estão anexadas e acho isso agradável.

E não estou aceitando o argumento de que todo mundo está acostumado com tabs :). Muitas pessoas estão acostumadas a salvar arquivos e ainda existem editores com capacidade de salvamento automático e as pessoas parecem gostar.

Bem, aceite ou não, as pessoas acham que é um argumento razoável e forte. Mas reservarei meu julgamento se você tiver algo significativamente melhor em mente. Por suposto, se você acha que pode melhorar significativamente nas abas, tente, mas não teimosamente forçá-lo por conta da inovação 'da moda' apenas;) .. Ele precisa ser substancialmente superior para expulsar o status quot .

Só posso dizer que a lista atual de 'arquivos de trabalho' definitivamente não é superior. Basicamente são guias, apenas organizadas verticalmente, exceto com a desvantagem de que as guias são destacadas da janela do editor a que estão vinculadas, e a lista fica em um espaço desperdiçado enquanto o local usual para as guias está vazio.
Eu também não gosto que a lista de 'arquivos de trabalho' tenha uma altura dinâmica, o que significa que a árvore do projeto se move verticalmente, e eu acho que gostaria ainda menos se os 'arquivos de trabalho' tivessem uma altura fixa e uma barra de rolagem vertical em vez de.

Simplesmente não é superior às guias normais e, portanto, não oferece nenhum motivo convincente para se adaptar ... na minha opinião :)

+1 @TurkeyMan

Na equipe do VS Code, trabalhamos sem abas e sem arquivos de trabalho desde o início (4 anos) e não está faltando nada. Então, pessoalmente, concordo que a seção de arquivos de trabalho é espaço desperdiçado e mantenho essa seção reduzida. No entanto, também trabalhamos com salvamento automático habilitado e geralmente não nos importamos com arquivos sujos. Os arquivos de trabalho foram introduzidos principalmente para dar aos arquivos sujos e sem título um lugar para serem exibidos. Mais tarde, decidimos que também era um lugar útil para ajudar as pessoas que não têm as guias tradicionais porque é uma representação semelhante, apenas em outra forma de IU.

Nós reservamos espaço acima do editor para mostrar informações e ações do arquivo. Alguém poderia argumentar que este espaço é o mesmo espaço necessário para guias. Mas meu argumento contra as tabulações é que normalmente o espaço horizontal não é suficiente para mostrar a lista de arquivos de trabalho porque você rapidamente termina com isto:

Este é o pesadelo que tentamos evitar: você precisa rolar para a esquerda e para a direita na lista de guias para encontrar os arquivos que deseja. As guias só funcionam bem se você não tiver mais guias abertas do que as que podem ser exibidas horizontalmente. Uma vez que uma guia fica pequena o suficiente para que o nome do arquivo seja oculto, você precisa começar a fechar as outras guias apenas para ver o que está acontecendo.

Agora, obviamente, os arquivos de trabalho têm um problema semelhante, apenas em outra dimensão. É por isso que normalmente usamos apenas Ctrl+Tab para tudo e não nos importamos com o que está aberto ou não.

Para resumir: arquivos de trabalho não são a nossa solução para substituir guias, é a combinação de arquivos de trabalho e Ctrl+Tab . E nossa equipe está mais ou menos 100% usando apenas Ctrl+Tab e nada mais.

Sua imagem parece exagerar desnecessariamente o problema; janela estranhamente estreita, bordas diagonais da guia, muito texto na guia, ponto à direita;)
vs-adequado une as abas lindamente, e não há razão para não rolar com pequenas abas discretas como faz.

Sou um usuário Ctrl-Tab muito liberal quando aplicável, mas você não pode usar Ctrl-Tab a menos que esteja editando ativamente não mais do que 2 ou 3 arquivos.
Suspeito que sua opinião sobre este assunto pode ser bastante tendenciosa em relação ao seu projeto em particular, e isso pode incluir um viés de linguagem. Em C / C ++, o número típico de arquivos de trabalho é dobrado ou triplicado quando você aceita que há .h e, no meu caso, geralmente .inl complementando cada .cpp . Ctrl-Tab é menos eficaz neste cenário, e você tende a usar Ctrl- ~ em vez disso (alternar cpp / h; para o qual também postei uma solicitação de recurso), em conjunto com o gerenciamento de guias.
Ou considere o Java, onde cada classe - não importa quão pequena - deve viver em seu próprio arquivo.

No meu dia-a-dia atual, muitas vezes tenho um conjunto de trabalho de 10s de arquivos, Ctrl-Tab não é útil para mim quando estou trabalhando dessa forma. O fluxo de trabalho mais prático é de 2 a 4 janelas do editor e algumas guias por janela. Não escolhi este layout porque adoro; simplesmente surgiu, porque é o layout de espaço de trabalho mais eficiente para este trabalho específico.

+ 1
Normalmente, divido o editor e fechar uma guia é um pouco mais intuitivo do que ter mais de 10 arquivos de trabalho.

Normalmente, também trabalho apenas em um subconjunto de arquivos e gosto de mantê-los à mão. 5/5 é mais fácil de gerenciar do que uma lista de 10 para mim pessoalmente. Também estou me movendo ativamente entre eles continuamente. As guias também ajudam, pois há uma indicação visual de que você abriu demais - o 'inferno de guias' mostrado por @bpasero.

Eu aceito que as guias não são necessariamente o Santo Graal do gerenciamento de janelas. No entanto, para idiomas ou projetos em que vários conjuntos de arquivos devem ser trabalhados, o gerenciamento das guias seria menos difícil.

Um exemplo simples seria .cpp e '.h' com guias, seriam dois cliques, ambos focados no topo da janela, enquanto com arquivos de trabalho seriam 3-4 cliques com arquivos de trabalho que requerem que você selecione o editor em questão e, em seguida, selecione o novo arquivo para editar.

Guias e guias personalizadas também permitiriam que algumas extensões interessantes fossem adicionadas com mais facilidade. Um exemplo é um console ou uma guia de plotagem. Isso exigiria entradas especiais na seção do seletor de arquivo ou teria que ser descartado ao fechar com o sistema atual. Eu volto regularmente às minhas parcelas, portanto, fechar a janela exigiria que ela fosse refeita. Ou o console seria fechado e os dados perdidos.

No entanto, se uma alternativa adequada estiver disponível, eu ficaria feliz em testá-la. Eu apenas sinto que o espaço horizontal nas telas atuais é maior do que o espaço vertical, do qual o design de gerenciamento de janela atual não tira proveito. Embora eu não gostasse se as guias fossem maiores verticalmente do que os nomes atuais em cada janela.

Estou curioso para saber por que há tantas dificuldades na implementação de guias. Tecnicamente, não é difícil e já existem arquivos de trabalho implementados; por que não ambos e deixar os usuários decidirem?

Isso soa quase como espaços v. Tabs, 2.0

Estou curioso para saber por que há tantas dificuldades na implementação de guias. Tecnicamente, não é difícil e já existem arquivos de trabalho implementados; por que não ambos e deixar os usuários decidirem?

Isso soa quase como espaços v. Tabs, 2.0

Concordo totalmente, provavelmente é muito mais fácil empurrar o recurso como uma opção (desativar o padrão se isso deixar as pessoas do anti-tab felizes) e rastrear o uso por meio de estatísticas / feedback do que teorizar interminavelmente se faz sentido ou não.

Percebo que parece que temos teorizado incessantemente sobre isso, em vez de realmente fazer algo e nos desculpar por isso. No entanto, temos um item para tratar disso em nossa carteira (referenciado acima - # 1133). Nós simplesmente não temos conseguido gastar muito tempo nisso recentemente, pois temos trabalhado muito na localização e acessibilidade.

Como mencionei acima, estamos cientes dos problemas com a experiência atual de gerenciamento de arquivos e desejamos fazer uma série de alterações para melhorar a experiência.

Um dos nossos objetivos com o VS Code é que, à medida que fazemos alterações na IU e UX, garantimos que o VS Code permaneça um editor leve e poderoso que permite que os usuários se concentrem em seu código. Uma das maneiras de tentarmos fazer isso é sendo muito cuidadosos com qualquer nova IU que adicionamos ao produto.

Nossa preocupação com a adição de guias é que isso introduz outro conjunto de problemas que acabam exigindo que o usuário se concentre na IU em vez do código. Nossa experiência com o Visual Studio, por exemplo, nos mostrou que muitos usuários frequentemente acabam com muitas guias abertas contendo arquivos que eles não precisam mais e que acabam bagunçando seu espaço de trabalho. Isso causa alguns problemas quando os usuários procuram arquivos e outros ativos de código. Para resolver esses problemas, é necessária mais IU que permita às pessoas fechar todas as guias, fechar todas as guias exceto esta guia, controles de estouro de guia, etc., etc. Queremos evitar essa situação e esperamos que os designs em que estamos trabalhando nos ajudem a conseguir isso.

Este não é um debate ideológico - estamos realmente tentando manter a estética mínima que acreditamos fornecer uma experiência leve e poderosa. Estamos simplesmente sendo muito cuidadosos ao introduzir novas IU e UX no produto.

É perfeitamente possível que, após algumas rodadas de design e pesquisa sobre isso, acabemos introduzindo as guias. Mas faríamos isso apenas sabendo que essa é a melhor maneira de melhorar a maneira como os usuários gerenciam os arquivos e ativos com os quais trabalham, mas não acaba bagunçando a IU.

Espero que isso ajude a explicar nossa visão sobre isso. E peço desculpas novamente por fazer parecer que estamos olhando para o umbigo e não fazendo nada a respeito.

Obrigado @stevencl , é bom que esteja pelo menos no radar e haja algum brainstorming acontecendo.

Nossa preocupação com a adição de guias é que isso introduz outro conjunto de problemas que acabam exigindo que o usuário se concentre na IU em vez do código.

Eu sinto que preciso me concentrar na IU em vez do código agora, portanto, esse argumento tem dois lados. :)

muitos usuários geralmente acabam com muitas guias abertas contendo arquivos que eles não precisam mais

É interessante que você diga isso, pois eu meio que tive a impressão de que parte do objetivo dos arquivos de trabalho _era_ encorajar a manutenção de mais arquivos abertos de uma vez. O que você descreve aqui pode acontecer com os arquivos de trabalho também, pelo menos com os atalhos de teclado padrão (e é por isso que brinquei com a troca dos atalhos de teclado para fechar o editor ativo e fechar o arquivo de trabalho completamente).

No final das contas, se o VS conseguisse replicar opcionalmente o _comportamento_ das guias (ao qual parece que pelo menos uma das coisas em # 1133 está relacionada), mantendo-o na lateral, isso pode ser um bom começo . A ordem das guias Ctrl + sendo MRU vs. ordem de aparência é outra coisa (Sublime permite ambos por meio de comandos vinculáveis ​​diferentes).

@stevencl , obrigado pela sua resposta. Eu gostaria de comentar alguns de seus pontos:

[...] estamos cientes dos problemas com a experiência atual de gerenciamento de arquivos e temos uma série de mudanças que queremos fazer para melhorar a experiência.

Estou certamente ansioso para o que parece ser um futuro brilhante para o VS Code. Fiquei animado quando soube que a Microsoft estava trazendo um IDE tão poderoso como o Visual Studio para mundos além do Windows, e para abraçar novos paradigmas de desenvolvimento de aplicativos com Electron. Parabéns pelo seu trabalho até agora!

Um dos nossos objetivos com o VS Code é que, à medida que fazemos alterações na IU e UX, garantimos que o VS Code permaneça um editor leve e poderoso que permite que os usuários se concentrem em seu código.

Não acho que alguém possa apresentar um argumento convincente para as guias tornando as interfaces fracas, lentas ou distrativas. Na verdade, há muito mais espaço horizontal para guias do que vertical acima da visualização em árvore do projeto. Ter os arquivos de trabalho lá, para mim, faz com que o lado esquerdo da janela pareça muito mais desordenado do que deveria ser.

Nossa preocupação com a adição de guias é que isso introduz outro conjunto de problemas que acabam exigindo que o usuário se concentre na IU em vez do código.

Haveria alguma razão para usar algo além do TextEdit ou do Notepad se fosse tudo para focar no código? Estipular essa funcionalidade, para todos os efeitos e propósitos, é a mesma na maioria dos editores, a UI / X usada para alcançar essa funcionalidade e a qualidade dela é realmente o lugar onde um produto se destaca.

Nossa experiência com o Visual Studio, por exemplo, nos mostrou que muitos usuários frequentemente acabam com muitas guias abertas contendo arquivos que eles não precisam mais e que acabam bagunçando seu espaço de trabalho. Isso causa alguns problemas quando os usuários procuram arquivos e outros ativos de código.

Aqui está um argumento que não importa a favor ou contra guias ou uma lista de arquivos de trabalho; ao trabalhar com mais de um arquivo, você sempre terá que quebrar seu foco para procurar ativos de código.

Mesmo assim, a lista de arquivos de trabalho ainda não resolve o problema. Muitos arquivos de trabalho fazem com que a lista role e não possa ser expandida. Portanto, em vez de rolar as guias, você vai rolar mais rapidamente para baixo na lista de arquivos de trabalho.

[...] realmente estamos tentando manter a estética mínima que acreditamos fornecer uma experiência leve e poderosa. Estamos simplesmente sendo muito cuidadosos ao introduzir novas IU e UX no produto.

Posso apreciar e apoiar essa postura até certo ponto. Quando a comunidade levanta sua voz, você deve começar a falar sobre a adoção do usuário. Não é por isso que você colocou a falta de dobramento do VS Code como uma preocupação de adoção do usuário em seu roteiro para março? Algumas coisas são exatamente como são e por boas razões. O menu Iniciar no Windows e o dock no OSX vêm à mente.

[...] peço desculpas novamente por fazer parecer que a gente tá olhando o umbigo e não tá fazendo nada a respeito.

Essa definitivamente não é minha opinião sobre isso, então não se preocupe. Por razões que já declarei, uma conversa saudável sobre isso certamente só pode aprimorar o propósito maior que é a UI / X do código VS

Também quero intervir e apenas dizer que acho que não estou "olhando para o umbigo". O momento desta edição é parcialmente culpado - 19 de novembro não dá tempo para colocá-lo em qualquer lugar em dezembro e possivelmente janeiro, dependendo de quão longe as coisas estão planejadas. Além disso, essa conversa que começou novamente é mais importante do que apenas implementar guias aleatoriamente porque os usuários querem.

Tenho que concordar com ianwesterfield em que a interface de arquivos de trabalho não é ideal e que há mais espaço horizontal do que espaço vertical. Enormes listas de arquivos e muitos arquivos sendo alternados são os pontos fracos atuais do vscode em termos de gerenciamento de arquivos de trabalho.
Quando você começa a pular em torno de 16 arquivos diferentes, então ser capaz de gerenciar a qual editor de divisão eles pertencem é algo que os arquivos de trabalho seriam difíceis de superar. Dito isto, dividir a lista de arquivos de trabalho em duas seções diferentes seria uma solução razoável.

No entanto, stevencl apresentou um argumento que me deixa muito feliz. "É perfeitamente possível que, após algumas rodadas de design e pesquisa sobre isso, acabemos introduzindo guias. Mas só faríamos isso sabendo que essa é a melhor maneira de melhorar a maneira como os usuários gerenciam os arquivos e ativos que trabalham com, mas não acaba bagunçando a IU. " Ao tentar coisas novas, podem surgir melhorias.

Uma maneira mais fácil de gerenciar as janelas divididas já seria uma melhoria. Posso defender os arquivos de trabalho em que o gerenciamento das janelas SEMPRE pode estar no mesmo local. Gerenciar guias exige mais esforço quando você deseja reorganizar as divisões de 2 a 4 (tela de alta resolução + átomo = divisão horizontal e vertical quando necessário). Portanto, existe uma solução possível que mantém a interface de arquivos de trabalho, mas ao invés disso, estende-a para ser um pouco mais complexa.

Obrigado, agradeço a oportunidade de ter essa conversa.

@ianwesterfield , você está certo sobre os arquivos de trabalho e destacou um dos problemas que queremos abordar. Existem também outras questões, muitas das quais @kfranqueiro destacou. A experiência atual definitivamente não é a experiência desejada.

Tendo trabalhado no design do Visual Studio por vários anos, eu já vi os problemas de UX que as guias podem causar. Passei 18 meses trabalhando na experiência da guia de visualização no Visual Studio, que é uma tentativa de reduzir o problema do 'inferno da guia' que @bpasero descreveu acima.

No entanto, queremos evitar chegar a uma posição em que isso se torne necessário. Portanto, queremos continuar em nosso mergulho profundo de design para descobrir as opções que estão disponíveis para nós e, em seguida, escolher uma. Como eu disse antes, pode muito bem ser que acabemos com guias. Se o fizermos, saberemos que é a melhor abordagem que poderíamos criar, que fornecerá uma ótima experiência para gerenciar arquivos e outros ativos de código.

Obrigado por todos os insights e descrições dos problemas que você está tendo atualmente com a forma como gerenciamos arquivos no VS Code.

@stevencl , É engraçado você mencionar a guia de visualização - eu adoro isso. É ótimo como o VS Code, Sublime, Atom, Brackets (via extensão), etc. têm um recurso de visualização como este por padrão.

Estou muito feliz que a Microsoft nos deu a oportunidade de participar das discussões de design em andamento, mantendo este projeto aberto. Se os usuários tivessem apenas essa voz durante o redesenho do Menu Iniciar, o Windows poderia não ter precisado de outro ciclo de lançamento para finalmente ter uma integração massiva após o Windows 7.

É perfeitamente possível que, após algumas rodadas de design e pesquisa sobre isso, acabemos introduzindo as guias. Mas faríamos isso apenas sabendo que essa é a melhor maneira de melhorar a maneira como os usuários gerenciam os arquivos e ativos com os quais trabalham, mas não acaba bagunçando a IU.

Desde que abri esta edição, que parece ter ressurgido, gostaria apenas de acrescentar que considero este comentário bastante satisfatório. Prefiro que as guias apareçam, mas apoio totalmente a exploração de novas ideias, e o código é uma ótima plataforma para fazer isso. Eu amo o trabalho que vocês fizeram até agora.
Dito isso, apenas tenha em mente que queremos _usar_ isso, e quanto mais cedo eu puder usá-lo como meu editor principal, melhor, então eu, pelo menos, apreciaria se você pudesse nos dar uma experiência familiar (ainda leve) que podemos usar de forma produtiva e nos sentir em casa agora, e podemos continuar com nosso trabalho. Então você pode usar todo o tempo do mundo para explorar novos horizontes :)
É que estamos aguardando ansiosamente o código para alcançar a linha mágica onde podemos adotá-lo em tempo integral. Para mim, as guias são minha única reclamação de usabilidade, a compilação e depuração nativas é minha única reclamação técnica.

Não acho que sou o único usuário cansado e sofrendo do Windows que é irremediavelmente viciado em estúdio visual. A salvação é apenas alguns pequenos problemas e recursos além do nosso alcance, está progredindo rapidamente e estou grato pela oportunidade de participar e assistir com tanta visibilidade.

Infelizmente, o Windows continua sendo a pior plataforma / ecossistema de desenvolvimento, com o melhor ambiente de desenvolvimento, e tem sido assim há uns 15 anos. Muito estranho.
Não sei por que, mas parece que para mim, o ambiente de desenvolvimento (produtividade) supera o ecossistema em meu equilíbrio, mas é um equilíbrio doloroso e ficarei feliz como um porco na lama quando puder usar o VS no linux full -Tempo! Estamos tão perto!
Eu sei que vocês veem isso como um veículo para explorar um novo território, e isso é totalmente legal, mas no curto prazo, nós realmente só queremos VS no linux, (ou osx, se você balançar dessa forma), como temos sonhado por um mais ou menos uma década, e podemos finalmente, depois de todos esses anos, acabar com nosso sofrimento! ;)
</dramatic_commentary>

TL; DR, explorar é totalmente ótimo e estou confiante de que você está comprometido com o melhor produto final que pode fazer, mas talvez soluções familiares seguras enquanto isso?

+1 para guias. A questão - por que você não o remove do Visual Studio Bundle então? Veja o que acontece então ...

+1 para guias! Implemente isso em uma atualização futura.

A suposição corrente parece ser que "[tabs] na maioria dos casos cresce tanto que você acaba não vendo nada". Eu gostaria de desafiar essa suposição. Eu uso as guias como um índice visível dos arquivos nos quais estou interessado no momento e gerencio ativamente esse índice conforme meu interesse muda com o tempo. A visibilidade é importante: refiro-me às guias físicas constantemente para me reorientar. Com o Working Files, perco minha capacidade de visualizar e manipular esse índice. Por exemplo, não parece haver uma maneira de remover um arquivo dos Arquivos de Trabalho por meio do teclado. Parece que estou lutando contra o editor. Adicione guias de estilo Sublime Text.

Embora eu concorde que o VS Code funciona bem sem guias agora (tenho usado desde o início de forma bastante produtiva), também concordo com alguns comentários acima que sugerem ter guias como uma opção (talvez desativada por padrão) e permitir que os usuários decidam se querem ou não.

Todo mundo é diferente, então ter uma opção seria ótimo. Mesmo que eu possa trabalhar bem sem eles, eu não me importaria em adicioná-los e provavelmente os usaria alguns - muitos anos de uso do VS completo. Parece que eles já estão atrasados ​​- obrigado!

+1 para guias. Trabalho com VSCode há quase 1 ano e gosto muito. Mas ainda faltam guias, especialmente ao trabalhar com depuração ou pesquisa, ou seção git à esquerda. As guias ajudam a não pensar sobre qual arquivo contém o código que você já trabalhou antes. Acredito que os usuários gerenciam as guias e sua ordem para ter em mente também uma posição da guia, que pode ser associada ao código-fonte que estão trabalhando. As guias do editor divididas também podem manter essa intenção.

Ctrl + tab é uma ação-chave e tabs é uma ação visual, que é muito mais rápida.

Eu provavelmente poderia viver sem guias ... se o VS não fosse tão ruim em gerenciar "arquivos de trabalho". Muitas vezes eu abro arquivos apenas para fazer referência a eles, sem realmente editá-los, mas o VS não coloca esses arquivos na minha lista de arquivos de trabalho, ao passo que eu definitivamente teria uma guia aberta em um ambiente com guias.

Isso combinado com o fato de que quando você fecha um arquivo / focaliza um novo "funcional", o explorador de arquivos SE MOVE para o arquivo aberto em vez de permanecer em seu último local, torna a experiência muito confusa.

Eu entendo que essas não são preocupações para você, já que "você o usou sem guias por 4 anos", então qualquer coisa que saia do escopo Ctrl + Tab é vista como uma forma estranha de usar o programa.

Isso precisa ser um recurso e se está ativado ou desativado por padrão é irrelevante. Praticamente todo editor de texto / IDE usa guias para navegação. Talvez alguns sintam que existe uma maneira melhor, mas para a maioria de nós as guias são eficientes, fáceis de usar e familiares ... e obviamente nós as amamos! Tire-os do Visual Studio para um lançamento para ver o quão importante eles são ... (sugestão derretimento épico do desenvolvedor no estilo Metro) Considere as guias para um lançamento de curto prazo. é a única coisa que impede muitos de nós de adotarmos o VSCode em tempo integral.

: +1:

Sou muito mais produtivo com guias! Eu uso Atom como uso o Google Chrome (Ctrl + 1 para a primeira guia, Ctrl + 5 etc. Ctrl + Tab, Ctrl + Shift + tab).

Trabalhar com arquivos me torna menos produtivo e sempre me sinto um pouco frustrado depois de usá-los.

Então, por favor, implemente as guias.

As guias serão muito úteis, +1

: +1:

@MadSpindel "Trabalhar com arquivos me torna menos produtivo e sempre me sinto um pouco frustrado depois de usá-los." 1000% concordam ... é como se não estivéssemos sendo forçados a nenhuma aba para alguém fazer uma afirmação ou algo assim. Não gostamos, se você gosta, torne-o opcional para nós, por favor.

O Visual Studio Power Tools tem a opção de exibir guias verticalmente, o que eu adoro.

: +1: e eu concordo com @sitefinitysteve. Se a equipe insiste em não ter guias, pelo menos melhore a API de extensão para que possa ser adicionada por terceiros.

É aqui que as guias são importantes - temos que voltar um momento para outro recurso ausente:

O VSCode precisa descartar a implementação não informativa dos Arquivos de Trabalho e, em seguida, adicionar o recurso para permitir a abertura de vários projetos. Eu faço meu trabalho separando meu código do lado do cliente em um projeto e meu código do lado do servidor em outro projeto. Em uma tela grande, quero duas janelas de codificação abertas, com uma árvore de projeto na extremidade esquerda. Código do cliente na janela esquerda, código do servidor na janela direita. Agora, em qualquer um dos projetos, estarei trabalhando em vários arquivos de origem. Nesses casos, desejo referenciá-los como guias acima da respectiva janela do projeto em que foram abertos. Posso ter 3 ou 4 guias no projeto do lado do cliente e 3 ou mais guias no projeto do lado do servidor.

A organização é orgânica. Toda a árvore de trabalho, vários projetos, é exibida à esquerda. Tenho separação de projetos por janelas de código e também tenho arquivos de código aberto sendo trabalhados ou referenciados por guias acima de suas respectivas janelas de projeto.

Este é um fluxo de trabalho essencial para mim. Atualmente, estou fazendo exatamente isso no Atom, mas gosto do VSCode e gostaria de ver esse fluxo replicado no VSCode. Para fazer isso, o VSCode precisa implementar suporte a vários projetos e guias acima das respectivas janelas. Caso contrário, é apenas mais um editor de um carinha, e não acredito nisso. Por favor.

@riclf acertou no ponto.

Normalmente tenho 3 colunas verticais abertas, HTML, JS e CSS da esquerda para a direita.

No Sublime, eu tinha todas as minhas guias html acima da primeira coluna, todos os arquivos JS como guias acima da segunda coluna etc. As guias têm um contexto e eu sei que não vou abrir o arquivo errado na coluna errada.

Isso é quase impossível no VS Code, posso ter 3 colunas abertas apenas usando "abrir ao lado" duas vezes, e uma coluna pode desaparecer totalmente se um arquivo for fechado, momento em que posso abrir um novo, mas tenho que reordenar eles. Se eu abrir um arquivo, ele reabrirá na coluna em que o cursor está atualmente; portanto, se eu abrir um arquivo css, tenho que ter certeza de que meu cursor está na terceira coluna. É absolutamente irritante.

Sem falar que a seção Arquivos de trabalho ocupa um espaço muito vertical na minha árvore de pastas, o que é um problema real no meu laptop.

Uma pergunta para a equipe da microsoft. Se você tiver uma visão dividida, como saberá a qual coluna um arquivo em "arquivos de trabalho" está associado? É simples quando as guias estão acima de suas respectivas colunas.

Apenas meu 2c.

Não tive nenhum desconforto cognitivo ao me acostumar com o Working Files. Eu os amo muito mais do que guias. A IU do VSCode está no caminho certo. Não sou contra guias opt-in, mas daria um jeito nas guias opt-out.

Arquivos de trabalho são guias em um layout melhor (mais espaço de rolagem). Eles estão perdendo os recursos de "arrancar" e arrastar, que podem ser adicionados no futuro.

Como um usuário mvim, tenho vários conjuntos de arquivos TDD abertos e tab entre eles. Por exemplo, eu angular + testes, servidor + testes, pepino ou comportamento + scripts. Não quero tabular para acessar um único arquivo, mas uma combinação de arquivos abertos. Mudei para VSCode por 3 meses para um projeto Typescript, porque ele realmente tinha o melhor / incrível suporte Typescript. No entanto, assim que mudei para um projeto não Typecript, descobri que comparei seus recursos de pesquisa, navegação e substituição de propósito geral diretamente com o mvim e lamento dizer que rapidamente (ou seja, instantaneamente) voltei ao meu antigo editor. Tenho um monitor Apple Cinema de 27 "e, se possível, obteria um monitor maior. Tenho muito espaço para muitas guias e pares de arquivos e não tenho um motivo convincente para limitar o uso desse espaço pelo meu editor Não quero lidar com apenas um arquivo por vez - quero abrir muitos e controlar o fluxo de guia para guia.

Dei outra tentativa ao Visual Studio Code duas semanas atrás. Na verdade, fiquei agradavelmente surpreso ao mexer em alguns arquivos. Mas quando comecei a trabalhar em um projeto real (grande) com mais de um punhado de arquivos abertos, a falta de guias se tornou muito chata. _Working Files_ simplesmente não combinava comigo e me deixava mais lento. Depois de 3 dias, eu estava tão irritado com isso que voltei para o Sublime Text. Eu tenho duas telas de 24 "no trabalho (Windows), um Mac de 27" em casa e posso facilmente ter 20 guias abertas e ainda distinguir qual arquivo é. Muito espaço na tela para guias no meu caso. _Você_ já está mostrando o nome do arquivo do arquivo que está aberto no editor. Todo o espaço à direita do nome do arquivo não é usado (exceto os ícones à direita da janela) e pode ser preenchido com guias (que é o que o Sublime Text também faz). Eu digo para dar aos usuários a opção de trabalhar com _Arquivos de Trabalho_ e / ou guias de arquivo. Por enquanto, estou voltando para uma combinação de Sublime Text e Visual Studio Enterprise. Quando as guias forem adicionadas, vou reconsiderar.

Para a opção Working Files , tenho que alternar a barra lateral (porque a mantenho oculta para visualização expandida do código) para selecionar o arquivo. E as opções Ctrl+P e Ctrl+tab também não são amigáveis.

Eu sei que vocês estão tentando algo diferente para isso, mas as opções que você já forneceu não são amigáveis. Desculpa.

forneça uma extensão para isso, para que os usuários tenham a chance de usar guias em vez de serem forçados a usar a lista de trabalho. Eu odeio muito o recurso de arquivos de trabalho, ele me faz alternar arquivos lentamente e rouba minha produtividade

Quando eu era novo no VS Code, eu realmente sentia falta das guias. Então descobri ctrl + tab e não preciso mais deles.

Tenho tentado fazer do vscode (que é incrível na maioria das partes) meu editor principal por vários meses, mas a falta de guias continua me incomodando e prejudicando minha produtividade (sou um daqueles que gerenciam ativamente o conjunto de guias abertas em outros editores). Ctrl + tab não substitui tabs.

É óbvio que a equipe vscode é tendenciosa contra isso, e atualmente visa "convencer" os usuários de que eles realmente não precisam de guias. Mas esse é o mesmo tipo de pensamento que levou à remoção do menu Iniciar do Windows 8 (todos sabemos como isso terminou).

@pesho Exatamente!

Agora que a dobradura de código foi eliminada, este é o principal problema na voz do usuário. Estamos avaliando uma série de opções internamente à medida que continuamos a avaliar os comentários da comunidade, testes de experiência do usuário, etc. Obrigado a todos pela discussão aqui. Muito útil.

provavelmente é a única razão pela qual abri o vscode pela primeira vez há quase um ano e fechei-o logo após alguns minutos de jogo. e você ainda não tem guias. Espero que apareça em breve, para que eu possa usá-lo. É open source, e o pessoal da Microsoft precisa mudar de ideia (é isso que eles estão tentando fazer agora, não é?) E ouvir a comunidade, não apenas "estamos usando essa ferramenta internamente e não precisamos de guias, bla bla"

@pleerock Você nem vai tentar um IDE porque não tem abas ?! (Oo) weeeweweweeeww. Eles não querem adicionar guias porque as guias são inúteis, prolixo, elas geralmente não agregam valor ao adicionar peso superior no espaço do Windows Chrome. As alternativas fornecem mais metadados, facilidade de uso e navegação mais rápida.

Com as guias, eu escolho quais arquivos permanecem abertos. Quer seja CTRL + guia ou "Arquivos de trabalho", se eu abrir um arquivo para procurar algum código nele, mudar para outro para usar o referido código, não tenho como voltar para o meu primeiro arquivo, a não ser ter que voltar navegue até o arquivo no explorer.

Eu sei que tenho 3 editores, mas às vezes não quero substituir os outros 2 com meu arquivo de código de pesquisa apenas.

Se quando eu abro um arquivo ele permanece nos diferentes históricos de arquivo, então estou bem sem tabulação. Talvez se um arquivo foi aberto por mais de 5 segundos, ele merece uma entrada em CTRL + Tab.

@ 4tron sim, é para mim, porque eu quero usar o IDE que seja conveniente para mim. para quem perder tabs é inútil e seguro seu espaço (provavelmente estão usando netbooks e não têm espaço suficiente para realmente poucos pixels extras =)), para outros é conveniente e aumenta sua produtividade. Qualquer bom software deve ser personalizável e ter a capacidade de ocultar / mostrar painéis. "salvar um espaço" não é discutir. Introduzir guias + adicionar capacidade de mostrar / ocultar (se for realmente necessário para alguém =)) o melhor caminho a seguir. Não há necessidade de abrir uma nova América ou ir com inovações erradas, precisa aprender com os melhores IDEs aqui que tornaram a UX por anos cada vez melhor, como intellij, visual studio e outros

É muito simples - basta torná-lo uma preferência - guias ou sem guias. Quando as guias estão ativadas, nenhum arquivo de trabalho, quando as guias estão desativadas, os arquivos de trabalho. Isso foi Genius! ;)

Eu sou um cara de tabs. Acho os Arquivos de Trabalho muito limitados e não intuitivos, além de ocupar espaço vertical na Árvore do Projeto. Mas pouco importa se não podemos ter mais de 1 projeto aberto. :(

Acho que uma preferência também deve servir.

Também pensei em uma maneira de melhorar o sistema de arquivos de trabalho. Você deve usar tab line como histórico.
Por exemplo, se você abrir 4 arquivos na janela à esquerda e, em seguida, abrir um quinto criando o arquivo modificado mais antigo fora da linha da guia, ele deve desaparecer e retornar como apenas "arquivo modificado" nos arquivos de trabalho.

Você também pode torná-lo inteligente, o sistema também pode priorizar o desaparecimento dos arquivos salvos primeiro e, portanto, não modificados.

O fato é que as guias são muuuito práticas, mesmo que o inchaço delas seja um problema. Você deve pensar em uma maneira de usar guias, mas limitando o número delas.

Normalmente, mantenho guias abertas que não edito há dias. geralmente é isso que o faz inchar.

+1

Eu tenho uma tela de 4K e não ter guias na horizontal está realmente me desligando do VsCode

BTW, quero esclarecer que não quero apenas guias, gostaria de conjuntos de guias. Como um desenvolvedor TDD mvim full stack no Mac, acho que em termos de contextos. html + css, angular + testes, nó + testes, pepino + etapas de teste. Normalmente trabalho em um único contexto por algumas linhas de código antes de passar para o próximo contexto, o estilo TDD. Ao usar mvim, eu não apenas alterno entre esses contextos muito rapidamente (usando a mesma sequência de teclas que uso para Mac Terminal, Mac Finder e Safari ou Chrome), mas me beneficio de macros que abrem automaticamente o arquivo emparelhado, para que de um arquivo de origem angular, posso abrir automaticamente o teste correspondente. Esta é uma maneira incrivelmente produtiva de trabalhar e mantém meus dedos no teclado.

Se eu encontrasse um IDE que me permitisse abrir arquivos "associados" em frames próximos uns dos outros, apenas mudando uma guia, por exemplo, quando eu abro button.html, ele abriria button.js próximo a ele e button.scss no terceiro quadro, eu nunca mais usaria outro IDE.

Eu sei que isso nunca vai acontecer, mas apenas dizendo.

Bem, então, você deve usar o mvim! http://www.vim.org/scripts/script.php?script_id=1567 Comando: AV abre arquivos associados (A para associados).

O que @jtosey fala é exatamente o que vim aqui dizer. Eu uso painéis para organizar um conjunto de arquivos relacionados. A maior parte do gerenciamento de guias envolve colocar esses arquivos relacionados lado a lado quando eu alterno os contextos.

+1

O mesmo aqui, adoraria guias.

Acabei de mudar para o VSCode do Atom e percebi como é incrivelmente organizado e limpo depois de trabalhar com ele por um tempo. O motivo? Sem superpopulação de guias! A falta real de guias é o que torna essa experiência tão tranquila. Minha navegação de arquivo principal é o menu de comando P que me permite pular rapidamente para qualquer arquivo.

As guias do VS são perfeitas, traga as guias, desencaixá-las para uma janela separada também seria ótimo!
Obrigado por vscode :)

Na verdade, estou bastante curioso para saber se você deseja fazer o VSC como um editor de arquivo de propósito geral ou apenas um editor de código-fonte.

Existem algumas situações em que uma barra de guias é absolutamente necessária .

1. Alterne rapidamente entre várias guias.
   Uma situação comum para mim é a necessidade de comparar 2 ou mais arquivos pelo formato, como para comparar entre o chinês simplificado e seu equivalente tradicional. Um diff não resolverá o problema porque são personagens diferentes. A única maneira é alternar rapidamente entre as guias para ver se há alguma palavra faltando em seus olhos. Usando ST e eu podemos alternar as guias usando Alt-NUM, mas no VSC a única maneira possível é usar várias teclas Ctrl-Tab ou mover e clicar rapidamente com o mouse.
2. Nomes de arquivo longos e difíceis de digitar.
   Usar Ctrl-P para alternar entre arquivos não é ruim. Mas que tal alguns nomes de arquivo que compartilham uma longa correção comum? Que tal alguns nomes que não estão em inglês? Considere quanto tempo você gastaria em Ctrl-P para alternar entre 青年急着买房的原因（上）.md e 青年急着买房的原因（下）.md ?

Eu diria que nenhuma dessas situações você atingirá ao escrever o código, mas como um editor de propósito geral, esse é um problema sério.

@ msg7086 Não tenho certeza sobre o ponto um, mas para o ponto dois você não poderia ctrl + p e então digitar .md deixando você com as duas opções e então apenas ctrl + tab para escolher aquela que você quer? Não tenho certeza se entendi o problema corretamente

@ 4tron Obrigado pela resposta. No entanto, seu método só funciona se eu tiver apenas 2 arquivos desse tipo. Na realidade, as pessoas provavelmente trabalharão com muitos desses arquivos em um único diretório. Imaging Estou escrevendo um blog que tem 50 posts em formato markdown, com diferentes caracteres em chinês, coreano, árabe etc. como nomes de arquivo. O cenário real que eu estava acertando era na verdade alguns arquivos de legenda com nomes CJK, onde todos eles são *.ass , portanto Ctrl + P por extensão não funciona muito bem.

Agradeço muito se isso pode ser implementado

Os desenvolvedores estão acostumados com isso, faça disso uma prioridade .

+1 para guias. Implemente as guias.

+1 para guias!

Eu voto para adicionar guias também.

+1

+1

+1

Precisamos de guias o mais rápido possível.

Sinto falta de guias. Eu continuo procurando por eles, seria bom consultar dois ou três documentos abertos diferentes rapidamente.

Qual é o problema?

• A área dos arquivos de trabalho está bloqueada em altura, o mesmo problema que muitas guias, exceto que é difícil de gerenciar (sem mouse ou roda de rolagem aqui). As guias podem ser banidas facilmente, dando ao usuário o próximo documento na pilha de arquivos aberta.
• A coluna Explorer em Code é muito mais ampla do que Sublimes, às vezes é desejável minimizá-la ao executar dois aplicativos lado a lado para economizar espaço (Unity à esquerda, Code à direita, por exemplo). As guias não precisam de economia de espaço para funcionar, o Code já tem uma bela área vazia onde elas podem ir.
• As guias ganham pela facilidade de uso e economia de espaço, nenhuma pesquisa UX necessária. Eles são rápidos de usar e todos nós gostamos deles.

Forneça gerenciamento de documentos com guias :)

+1, eu.

+1

+1

VSCode é um ótimo editor e tem bons pontos de integração com Git e Nodejs. O principal motivo pelo qual não o uso como meu IDE de desenvolvimento principal é porque ele não oferece suporte a guias.

O mesmo aqui. É a ÚNICA coisa que me impede de usá-lo.
Op do 10 mrt. 2016 om 15:18 schreef Konrad Piascik < [email protected]

VSCode é um ótimo editor e tem bons pontos de integração com Git e
Nodejs. O principal motivo de eu não usá-lo como meu IDE de desenvolvimento principal
é porque ele não suporta guias.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -194867036.

É um pouco surpreendente ver tantos recuos sobre esse problema, já que deve ser tão fácil de implementar. No mínimo, torná-lo uma opção ou disponível por meio de uma extensão (como faz os colchetes).

Se for adicionado, POR FAVOR, adicione o seguinte:

1. Fechar funcionalidade como o Google Chrome. (Sempre fiquei irritado porque a versão padrão do VS não tinha isso.)
   - " Fechar outras guias "
   - " Fechar guias à direita ".
2. Uma opção para abrir a guia à direita ou esquerda. (VS mudou o padrão em algum ponto, mas depois adicionou uma opção para alterar)

As guias funcionam. Eles estão em toda parte, as pessoas estão acostumadas. A lista atual de arquivos não é intuitiva. Depois de 2 meses usando o VS Code diariamente, ainda me vejo buscando uma guia quase toda vez que preciso trocar de arquivo. O fato de que todos os outros editores continuarão usando guias cria uma grande barreira para que algo diferente se torne intuitivo.

Na minha equipe, as pessoas reclamam o tempo todo sobre isso, a ponto de algumas pessoas preferirem usar o sublime sem qualquer suporte de digitação do que usar o VS Code.

Não sou contra a pesquisa de UX para encontrar uma maneira "melhor" de lidar com arquivos abertos, mas por favor, não torne isso o fiasco da fita do Office novamente, que levou meia década e vários lançamentos para inventar outra maneira de fazer exatamente o mesma coisa.

-1

Algumas observações sobre por que sou contra as guias:

• Qualquer tempo gasto em guias será o tempo perdido para fazer outras melhorias no editor.
• Eu tenho me forçado a me tornar mais um comando de teclado e não ter guias tem sido útil. Portanto, estou argumentando a partir da perspectiva é-para-seu-próprio-bem, embora eu nem mesmo tenha chegado lá ainda.
• Em relação ao anterior, isso me lembra de quando o Gmail foi lançado e eu tive que convencer as pessoas de que os rótulos eram superiores às pastas. Algumas pessoas simplesmente não conseguiram processar e ainda estão balançando suas contas de e-mail AOL / ISP. Acho que a MS deveria se posicionar aqui ao dizer "nós apenas achamos que esta é a melhor maneira de fazer as coisas".
• Se eu sugerisse algo, seria uma explicação inicial de por que as guias não estão lá, junto com exemplos de navegação no editor sem elas.

Bem, há um compromisso - Tornar as guias visíveis ou não em Preferências / Opções.

Não acho que demore muito para outras melhorias, porque tenho certeza de que há mais de um programador neste desenvolvedor. Eu amo ser um comando de teclado também. Se eles foram implementados, simplesmente não os use, mas por que inibir aqueles que preferem guias em seu fluxo de trabalho de tê-los?

Enfim, não é nada demais. Voltei para o Atom enquanto espero o VSC decidir o que vai fazer. Acho as guias essenciais para o fluxo de trabalho em um projeto grande, além de poder abrir mais de uma pasta de projeto.

Eu tenho me forçado a me tornar mais um comando de teclado e não ter guias tem sido útil. Portanto, estou argumentando a partir da perspectiva é-para-seu-próprio-bem, embora eu nem mesmo tenha chegado lá ainda.

Como sugeri anteriormente neste tópico , é o _comportamento_ que está faltando que é tão importante, se não mais, do que o componente visual. Eu adoro usar atalhos de teclado como ctrl + [shift +] tab ou mesmo ctrl + P para navegar pelos arquivos (incluindo os abertos), mas o comportamento dos Arquivos de Trabalho e como ele gerencia as janelas do editor (e o fato de que ctrl + tabs na ordem MRU) Acho terrivelmente chocante.

Segure o telefone! Eu tenho a resposta! É perfeito! Pronto? Não _precisamos_ guias. Vamos estender os arquivos de trabalho com uma opção simples de exibi-los em guias horizontalmente na parte superior do editor! Woo hoo! Problema resolvido sem criar guias!

Na verdade, prefiro do jeito que está agora - painéis para arquivos abertos e um seletor de arquivos em formato de lista com "arquivos de trabalho" ao lado. Quando eu usava o Atom, odiava que toda vez que eu olhava rapidamente para um arquivo, ele abria uma nova aba e em minutos minha barra de abas estava cheia de abas inúteis.

Então eu sou -1 nisso. Mas eu ainda gostaria de ver as janelas desencaixadas.

Acabei de mudar para o VSCode do Atom e percebi como é incrivelmente organizado e limpo depois de trabalhar com ele por um tempo. O motivo? Sem superpopulação de guias! A falta real de guias é o que torna essa experiência tão tranquila

esta. 100% concordam.

Na verdade, prefiro do jeito que está agora - painéis para arquivos abertos e um seletor de arquivos em formato de lista com "arquivos de trabalho" ao lado. Quando eu usava o Atom, odiava que toda vez que eu olhava rapidamente para um arquivo, ele abria uma nova aba e em minutos minha barra de abas estava cheia de abas inúteis.

Eu entendo isso e é por isso que estamos pedindo um recurso _adicional_ e não um substituto para arquivos de trabalho. Não consigo entender por que os dois não puderam ser incluídos no editor. Eu quero dizer sério. Veja quantas guias desejadas neste tópico! Este não é um cenário _Ei, gostaria que os botões fossem azuis_. Trata-se de um obstáculo à produtividade para a grande maioria das pessoas que desejam abas neste editor de texto (que por sinal está se tornando superior ao Atom e Sublime). Recebo os argumentos válidos em ambos os lados, mas não consigo entender por que guias e arquivos de trabalho não podem ser incluídos com opções de desativação. Todo mundo ganha então.

@ jayrosen1576 Talvez o problema seja que ninguém realmente fez uma proposta detalhada sobre como deveria ser

• a barra de guias deve ficar no topo de todas as janelas?
• Como clicar em uma guia funcionaria quando você tem vários arquivos abertos lado a lado ou, em uma versão futura, até mesmo divididos horizontalmente?
• A guia do arquivo ativo estaria sempre destacada? E se o console de depuração estiver focado?
• Se você habilitar a configuração da guia, a seção de arquivos de trabalho seria removida por ser redundante?
• E quanto a nomes de arquivo duplicados em pastas diferentes?
• E quanto ao botão Fechar duplicado de uma guia e um painel?
• Fechar o painel fecha a guia?
• Uma guia aparecerá assim que você abrir um arquivo como no Atom (urgh) ou apenas quando você editar como com arquivos de trabalho?

Todas essas são questões nas quais a equipe de desenvolvimento teria que se dedicar. E por mais que tente, não consigo pensar em uma implementação que seja mais elegante do que a lista de arquivos de trabalho e não confunda.

Aqui está a proposta de como deve ser:

1) Faça o download do Atom
2) Abra o Atom
3) Observe as guias
4) Implementar em VSCode

@ jayrosen1576 sério? Mencionei algumas preocupações válidas com a implementação do Atom e também problemas que o Atom simplesmente não tem porque não tem um conceito de arquivos de trabalho.

Então, novamente, sua foto de perfil diz tudo.

• a barra de guias deve ficar no topo de todas as janelas?
  R: Sim. Experimente as guias no Atom
• Como clicar em uma guia funcionaria quando você tem vários arquivos abertos lado a lado ou, em uma versão futura, até mesmo divididos horizontalmente?
  R: As guias aparecem na parte superior de cada painel. Experimente as guias no Atom.
• A guia do arquivo ativo estaria sempre destacada?
  R: Sim. Experimente as guias no Atom.
• E se o console de depuração estiver focado?
  R: O mesmo resultado de quando o console de depuração está focado agora com dois arquivos abertos lado a lado.
• Se você habilitar a configuração da guia, a seção de arquivos de trabalho seria removida por ser redundante?
  R: Somente se você desativar os arquivos de trabalho (como uma opção)
• E quanto a nomes de arquivo duplicados em pastas diferentes?
  R: A guia inclui um caminho parcial. Experimente as guias no Atom.
• E quanto ao botão Fechar duplicado de uma guia e um painel?
  R: O painel não possui um botão Fechar. Experimente as guias no Atom.
• Fechar o painel fecha a guia?
  R: Sim. Experimente as guias no Atom.
• Uma guia aparecerá assim que você abrir um arquivo como no Atom (urgh) ou apenas quando você editar como com arquivos de trabalho?
  R: Somente se você habilitar a opção para fazer isso (usePreviewTabs = false no Atom para desativar). Caso contrário, clique duas vezes para abri-los em uma guia. Experimente as guias no Atom.

@felixfbecker Como este produto carrega o moniker do Visual Studio, deve haver guias opcionais e elas devem se comportar como em qualquer outro produto do Visual Studio.

Diz muito sobre seu personagem quando você menciona algo tão sem graça como uma foto de perfil em resposta a uma resposta válida às suas preocupações.

Segure o telefone! Eu tenho a resposta! É perfeito! Pronto? Não precisamos de guias. Vamos estender os arquivos de trabalho com uma opção simples de exibi-los em guias horizontalmente na parte superior do editor! Woo hoo! Problema resolvido sem criar guias!

@ jayrosen1576 Isso não resolve todo o problema, já que, como eu disse antes (e trouxe de volta literalmente o comentário imediatamente anterior ao seu), não é apenas a aparência visual das guias que é diferente - é o comportamento. Como eu disse em meu primeiro comentário aqui, você pode obter "guias na barra lateral" em vez de Sublime Text também, mas ainda não é o mesmo que arquivos de trabalho. (OMI é melhor.)

@kfranqueiro concordo totalmente. Eu estava apenas sendo sarcástico. Essa coisa de tabulação é um argumento muito bobo. Se o VSCode simplesmente tivesse o recurso de guias das guias do Atom com a opção de ocultá-las (mesmo por padrão), seria perfeito. Acho que todos estamos pedindo a mesma coisa. Eu simplesmente não consigo entender por que ambos não podem ser incluídos com uma opção de desativação.

Honestamente, discutir se as guias são uma boa escolha para um editor de texto é simplesmente estúpido. Este não é um conceito novo. Basta implementá-los e deixá-los opcionais. Faça uma extensão e deixe ser o não. 1 extensão, de longe, até que as pessoas percebam que esta é uma funcionalidade básica e não faz sentido não tê-la, assim como as opções de menu do VS em maiúsculas.

@nvivo Não poderia ter colocado. Toda essa discussão parece idiota.

assim como a opção de menu em maiúsculas do VS.

@nvivo Já experimentou esta extensão? Nenhuma opção de menu, mas você pode configurar alguns atalhos de teclado. funciona muito bem.

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

Se você não gosta dessa discussão, vá em frente. Ler este tópico é totalmente opcional!

Claro que a leitura é opcional, mas sua própria existência parece apoiar a ideia de que adicionar guias ao código do VS é opcional e que devemos debatê-lo. Uma enquete simples com a seguinte pergunta.

Você continuará a usar o VS Code se as guias não forem adicionadas em breve? Sim não

Isso mostraria que a Microsoft perderia uma grande proporção de sua base de usuários em potencial se não adicionasse. O que significa que do ponto de vista comercial, mesmo que eles próprios não precisem do recurso, seria suicídio comercial não o fazer. Portanto, esta conversa distrai e é desnecessária.

Dito isso, estamos falando da mesma empresa que ainda não colocou extensões em seu navegador. Então eu acho que tudo é possível.

Com toda a seriedade, a única conversa agora deve ser sobre a melhor maneira de implementar guias. Não há mais um ponto de interrogação sobre se as pessoas querem o recurso, então vamos passar a conversa para algo mais construtivo.

Extensões do navegador? Ativo ... NVM.

Honestidade, não vejo razão para tabs. O amor por guias é muito maldito. Em termos de realizar o trabalho real, os atalhos fazem tudo o que é necessário, com pesquisa por regex, mais metadados e um processo de trabalho muito melhor. Eles fornecem uma necessidade esotérica básica para, eu não sei, algo familiar. Tenho a sensação de que isso é apenas um empurrão para ver se a senhora irá servir a comunidade, para ver se eles realmente estão mudando. Embora não seja tão inútil quanto todo o texto em maiúsculas na edição vs.

Em termos do que foi dito anteriormente.

"Não acho que demore muito para outras melhorias"

Pessoalmente, acho que sim, como, por exemplo, criar a capacidade de extensibilidade na janela do editor de texto, para que as extensões possam ser feitas para quem deseja guias. Tenho certeza de que toda a ideia do vscode é mantê-lo o mais mínimo e leve possível, com o usuário final adicionando extensões ou estendendo-o.

@ 4tron , é claro que há conspiração da comunidade do mal para testar a microsoft aqui! Não há sempre um?

Se as guias fizessem algum sentido, veríamos outros editores usando-as. E se fosse uma maneira realmente boa de organizar vários conteúdos abertos, talvez outros tipos de software que têm essa necessidade de organizar vários conteúdos abertos, como navegadores, por exemplo, também os usariam. Mas é claro que não, porque não fazem sentido! Você pode imaginar algo que as pessoas usam o tempo todo, como um navegador usando guias? Absurdo!

Eu digo vamos jogar pelo seguro. Vamos primeiro esperar e ver se algum outro bom editor suporta esse novo recurso, para não perdermos tempo e esforço em algo que realmente não funciona. Vamos verificar o visual studio, intellij, eclipse, atom, sublime, monodevelop, notepad ++ ou qualquer outro que tenha uma base de usuários considerável. Uma vez que pelo menos _alguns_ desses editores suportem esse recurso por alguns anos sem substituí-lo por outro, haverá alguma indicação de que este é um recurso útil.

Mas não vamos nos precipitar. Precisamos ter algo como um rastreador de problemas onde as pessoas possam expressar esse desejo diretamente e talvez permitir que outras pessoas votem, para que possamos realmente ter certeza de que não estamos fazendo isso por nada! Só podemos agir se ele se tornar um dos recursos mais solicitados no repositório. Então saberemos que não é apenas uma tendência, mas as pessoas acharam útil para seu trabalho diário e querem esse recurso aqui também.

Mas até esse dia, vamos esperar pacientemente. Editores de texto são algo novo e ninguém sabe realmente que tipo de recursos são necessários.

Ghehehe, hilário!

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

@ 4tron https://github.com/4tron , é claro que há uma conspiração do
comunidade do mal para testar a microsoft aqui! Não há sempre um?

Se as guias fizessem algum sentido, veríamos outros editores usando-as. E se isso
era uma maneira muito boa de organizar vários conteúdos abertos, talvez outros tipos
de software que precisa organizar vários conteúdos abertos, como
digamos, navegadores, por exemplo, também os usariam. Mas é claro que não,
porque eles não fazem sentido! Você pode imaginar algo que as pessoas usam todos os
tempo como navegador usando guias? Absurdo!

Eu digo vamos jogar pelo seguro. Vamos primeiro esperar e ver se algum outro bom editor
suporta este novo recurso para que não percamos tempo e esforço em algo
isso realmente não funciona. Vamos verificar o visual studio, intellij, eclipse,
átomo, sublime, monodesenvolvimento, notepad ++ ou qualquer outro que tenha um
base de usuários considerável. Uma vez que pelo menos _alguns_ desses editores apoiem
esse recurso por alguns anos sem substituí-lo por outro,
então haverá alguma indicação de que este é um recurso útil.

Mas não vamos nos precipitar. Precisamos ter algo como um
rastreador de problemas onde as pessoas podem expressar esse desejo diretamente e talvez deixar
outras pessoas votam, para que possamos ter certeza de que não estamos fazendo isso por
nada! Só podemos agir se for um dos mais solicitados
recursos no repositório. Então saberemos que não é apenas uma tendência,
mas as pessoas acharam útil para seu trabalho diário e querem esse recurso aqui
também.

Mas até esse dia, vamos esperar pacientemente. Editores de texto são algo novo
e ninguém sabe realmente que tipo de recursos são necessários.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -195715795.

@nvivo Você está realmente comparando um navegador a um editor de texto agora? Eu entendo o seu uso excessivo de sarcasmo aqui, e isso é ótimo. O que estou tentando mostrar não é se as guias são úteis ou não. Gosto da ideia de um editor leve / mínimo. Esta é apenas minha opinião, gosto da ideia do editor ser extensível para o usuário com base em suas preferências. É nisso que eu quero que o vscode esteja trabalhando. Então, podemos mover esta discussão para "Por que nenhum desenvolvedor criou uma extensão para isso ainda ... talvez eu devesse, porque gosto de guias e gostaria disso, e o vscode pode fazer isso, então, agora eu tenho um editor de texto que é semelhante ao meu navegador "

@ 4tron Pareceu-me que ele também estava comparando editores de texto a editores de texto.
Acho que eles estão fazendo um ótimo trabalho em tornar o vscode extensível, mas estou firmemente no campo que considera as guias um recurso out-of-the-box. Esta noção "Ah, você gosta de guias como todos os outros softwares que usa? Procure no Google o problema, encontre recomendações que explicam como instalar a extensão de contribuição do usuário apropriada e pronto!" não voa. Imagino que a maioria dos usuários apenas espera que existam guias, e duvido muito que haja muitas pessoas que pensariam que você encontraria uma barra de guias instalando uma extensão. Tenho certeza de que isso nunca foi precedido por nenhum outro software. Por que as pessoas pensariam em fazer isso?

@TurkeyMan
Sua retórica começou com uma comparação com os navegadores.

Estamos falando de desenvolvedores aqui. Acho que eles teriam a iniciativa se quisessem guias. Lamento ser contra essa ideia, mas não vejo guias de motivo válido, eu alt + q em vs o tempo todo. Simplesmente não vejo nenhum valor agregado. esta é minha opinião pessoal, e talvez eu seja um péssimo desenvolvedor por não entender como as guias são supostamente úteis. Acho que essa conversa é prolixa e, pessoalmente, gostaria de ver o vscode sendo aberto como um shell isolado para uma personalização quase completa e até mesmo modelos baseados em negócios. onde alguém poderia aprimorar a customização a um grau focado para, digamos, desenvolvimento drupal ou desenvolvimento wordpress, onde os editores constroem é baseado em torno do ecossistema da base de código dos usuários. Esse também me parece um problema melhor a ser resolvido.

A desvantagem de tudo ser uma extensão é que você acaba tendo estranhas interações indesejadas entre eles. No código vs, já usar GitHistory em cima do Smart File Reopener causa problemas estranhos de fechamento de arquivo.

Algo tão básico quanto guias deve estar pronto para uso. Agora, como outros solicitaram neste tópico, abrir grupos ou criar relações entre guias é onde as extensões devem entrar na discussão.

@ 4tron , foi engraçado, mas estou falando sério

Serviços de compilador externo são algo que você pode decidir ou não oferecer suporte em um editor de texto. É bom ter um recurso de executores de tarefas integrados

As guias não estão nesta classe. As guias são como janelas, botões e como abrir e salvar arquivos. Não há decisão a ser tomada aqui, basta tê-los lá e seguir em frente, as pessoas esperam por isso. Isso não é uma coisa personalizada avançada que poucas pessoas querem que os plug-ins suportem, eles são UI padrão em _qualquer SO em qualquer lugar_. As pessoas estão acostumadas com isso, e há uma razão pela qual todos os outros editores possíveis não exigiram uma petição para adicioná-los.

E é por isso que discutir se as guias são boas ou não é estúpido. O VS Code não é um experimento UX, é uma tentativa de ter um bom editor .NET para todas as plataformas. Faça essa maldita coisa útil para 90% das pessoas e você terá sucesso.

Sinceramente, entendi seu ponto sobre as alternativas, mas você só precisa entender que é uma minoria muito pequena. Acreditar que a maioria das pessoas que pedem por isso são apenas trolls que querem testar a microsoft é simplesmente ilusório.

Aquele ponto sobre ser uma chamada para ver se o ms mudaria sua postura sobre as abas, foi tímido, principalmente por causa da paixão por abas a serem incluídas. A ponto de alguém nem tentar o editor porque não havia guias. Eu me esforço para entender isso. Não vamos esquecer que ainda está em Beta. Então, esperançosamente, eles irão adicionar guias (opcional, por favor).

@ 4tron Eu tentei várias vezes e não uso o vscode regularmente porque não parece escalar bem para grandes projetos, e a falta de guias é um dos principais motivos práticos que parecem ser verdadeiros para mim.
Eu o uso principalmente como um editor de texto leve quando estou editando um pequeno número de arquivos, mas assim que quero trabalhar em um de nossos grandes projetos, o vscode simplesmente não funciona. Abas ausentes e o fato de não haver noção de subprojetos (ou 'soluções', como o VS coloca) são os únicos bloqueadores que estou ciente no momento.

Eu só quero comentar sobre essa ideia de adicionar tudo com plug-ins. Essa é uma boa meta; ter uma ótima estrutura de extensão é importante, mas acho que eles precisam ter cuidado para não se comprometer demais com essa ideia.
Eu uso o VS e, embora me deixe louco, acho que estou apegado a ele porque tem um nível muito alto de qualidade de produto, que é o que eu espero de um produto MS. Eu tentei todas as alternativas de software de fonte aberta por aí (e outras ferramentas proprietárias), e todas elas parecem ser insuficientes na frente de usabilidade básica (particularmente quando se trata de experiência de depuração).
Eu realmente espero que a intenção do vscode não seja ser um shell leve que todo mundo hackeia recursos aleatoriamente por meio de extensões ... já existem muitas outras ferramentas que se encaixam nessa descrição, não acho outra que seja atraente. O que eu quero do vscode é o que sempre desejei do VS; para ser bem projetado de uma perspectiva de usabilidade por designers de UX profissionais e para ser CROSS PLATFORM.

Acho que aqueles que são contra as guias podem estar perdendo o ponto. Eu (nós) não quero uma solução tudo ou nada. Tudo o que estamos pedindo é uma opção simples para ativar as guias (elas podem ser ocultadas por padrão) que se parecem e se comportam como as do popular editor Atom. Se você não gosta deles, você nunca saberá que eles existem. Se você fizer isso, eles poderão ser ativados. E para aqueles que nunca usaram o Atom e a experiência com vários painéis + guias, sugiro que você experimente antes de descartar completamente o argumento para eles. Você pode não gostar deles, mas tem que admitir que eles _são_ úteis para muitos de nós. Se não fosse pela excelente capacidade de depuração do node.js do VS Code, eu usaria exclusivamente o Atom. Não me importo com os arquivos de trabalho. Acho que podem ser úteis, no entanto, não são um bom substituto para as guias e não são realmente uma maneira alternativa de fazer a mesma coisa. É como dizer _Você tem um Honda Civic, por que quer uma caminhonete? _ Bem, tente carregar 1200 libras de piso de lingüeta e ranhura de bambu na parte de trás de seu Civic e você verá por quê. Ambos são veículos, mas têm finalidades diferentes.

Como eu disse antes, pegue as guias do Visual Studio, Edge ou qualquer outro produto da Microsoft para uma versão e veja a reação. Não vai ser nada bonito. Todos nós _podemos_ ter as duas coisas. Estamos pedindo que as guias sejam _opcionais_ e não um componente obrigatório do editor. O tempo pode ser melhor gasto no desenvolvimento de outro editor? Certo. Correções de bugs críticos e melhorias que bloqueiam o uso do editor devem sempre vir primeiro. No entanto, tenho certeza de que vários recursos foram adicionados que não chegam ao nível de uma melhoria ou correção crítica. Portanto, se você gasta tempo com eles, deve haver um tempo reservado para um recurso que a grande maioria neste tópico está pedindo.

Amamos o que o VSCode se tornou nos últimos meses e estamos engajados neste tópico porque queremos que ele seja o melhor editor disponível. Não há espaço para negatividade aqui. Todos nós somos apaixonados pelo que queremos / não queremos como desenvolvedores. Ninguém tem uma opinião errada, mas as opiniões opostas devem ser honradas como tal e não simplesmente desconsideradas porque você acha que elas são inválidas.

Não acho que haja muita "paixão por tabs". O que acontece é que depois de @bpasero afirmar " Não acho que as abas sejam uma boa maneira de mostrar a lista de arquivos abertos " e " Até agora não ouvi um bom motivo para as abas ", as pessoas ficarão mais vocais tentando justificar a solicitação ao committer principal do projeto.

Estou muito frustrado de ver toda essa discussão e um pouco ofendido porque uso o VS Code diariamente no meu trabalho e quero ter um bom editor .NET no Mac e Linux, e sinto muitas saudades das guias, e não entendi o momento "_wow! isso é realmente mais útil_", mas a resposta aqui parece ser "_você simplesmente não percebeu que criamos algo incrível! dê um tempo e se acostume! _".

Aqui estão alguns problemas reais que vejo ao usar o VS Code diariamente por alguns meses:

• não faz sentido para mim clicar no ícone de fechar na janela, mas manter o arquivo nessa lista - eu tenho que constantemente limpar essa lista manualmente para ter uma lista onde vejo apenas os arquivos com os quais estou trabalhando - e os arquivos Eu trabalho não são os últimos que abro ou os que estou mudando, são os que eu quero manter abertos ao mesmo tempo
• não faz sentido para mim fechar um arquivo não salvo e colocá-lo nessa lista com um marcador - muitas vezes ao dia eu faço alguma coisa, e a mudança não se reflete no aplicativo porque fechei o arquivo e o código do VS não perguntou eu para salvá-lo, o que me faz perder tempo
• um clique abre o arquivo, mas apenas um clique duplo para colocá-lo na seção usada recentemente - então, eu abro constantemente arquivos que não aparecem lá - e então minha memória muscular acha mais fácil adicionar ou remover um espaço no arquivo em seguida, role até o arquivo que estou olhando novamente e clique duas vezes nele
• Acho irritante que você não consiga ver a barra de rolagem depois que a lista for preenchida, a menos que você passe o mouse sobre ela. Agora, isso é complicado porque é assim que a IU funciona no editor. Mas veja, eu conheço o projeto e sei que deve haver mais arquivos na visualização da pasta. Também conheço a estrutura do código, então sei que deve haver algo mais no painel do editor. Mas com a lista de recentes, não tenho ideia. "Está cheio ou esqueci de abrir o arquivo? Não abri o arquivo há 1 minuto? Deixe-me abrir o arquivo de novo ..."

Agora, vejo que a maior parte disso seria resolvido com um argumento como "_oh, mas você está perdendo o ponto, é uma lista de arquivos usados ​​recentemente, não uma lista de arquivos abertos. Você está comparando-a a guias, e há melhores maneiras de lidar com arquivos abertos. Depois de algum tempo, você começa a ..._ "

Ao que eu responderia de bom grado: "_Isso tudo não faz sentido para mim e está me tornando improdutivo. Já existe uma solução que funciona em todos os lugares há décadas. Não quero consertar algo que nunca foi um problema e, honestamente, não vejo essa nova solução como uma alternativa melhor. Podemos apenas ter algo familiar que funcione e que estamos acostumados a fazer? Obrigado_ "

Eu sei que tudo isso parece arrogante. Mas aposto que é isso que a maioria das pessoas está pensando, mas são muito tímidas ou educadas demais para falar.

IUs experimentais são ótimas alternativas e eu sou totalmente favorável a alternar entre as duas. Mas esse é atualmente um experimento forçado que impede a outra opção, que é a mais comum e esperada. E, assim como o menu Iniciar do Windows 8, isso não termina bem.

Ao que eu responderia com prazer: "Essa coisa toda não faz nenhum sentido para mim e está me tornando improdutivo. Já existe uma solução que funciona em todos os lugares há décadas. Não quero consertar algo que nunca foi um problema e, honestamente, não vejo essa nova solução como uma alternativa melhor. Podemos apenas ter algo familiar que funcione e que estamos acostumados a fazer? Obrigado "
...
E, assim como o menu Iniciar do Windows 8, isso não termina bem.

Eu não poderia concordar mais.

Como a dobragem de código já foi o recurso mais votado, agora são as guias . A equipe do vscode nos deu o fold.

Ficarei surpreso e desapontado se as guias nunca se concretizarem, dado o excelente histórico da inclusão da equipe vscode das principais solicitações do usuário, tendo em vista a participação renovadora da Microsoft na comunidade de código aberto.

@ianwesterfield Exatamente, é o recurso mais solicitado com milhares de votos. Isso vai acontecer. Esta conversa é inútil e precisa passar para "Como exatamente as guias devem funcionar?"

Eu comentei antes sobre a existência de uma implementação quase perfeita de guias: Atom. Eles são fáceis de organizar, têm uma exibição adequada de caminhos de arquivos parciais se duas guias têm o mesmo nome de arquivo e funcionam extremamente bem em uma janela com vários painéis horizontais e / ou verticais (que eu acho que é outro recurso necessário do VSCode). Se o VSCode tivesse os mesmos recursos de guia do Atom, acho que isso cobriria 99% do que todos estão pedindo. E como o Atom também é baseado em elétrons, a implementação pode funcionar igualmente bem no VSCode. Não sou a favor de uma solução copiadora de nada, no entanto, eles (Atom) fizeram um ótimo trabalho ao implementar guias e o que eles têm é uma solução excelente a esse respeito.

@ jon64digital Talvez seja só eu, mas acho que o que impede essa conversa de evoluir é uma sensação de frustração. Esta solicitação ainda não foi atribuída no backlog, mesmo com 6k + votos e uma referência vagamente redigida na iteração de 31 de março:

Melhorar o gerenciamento de documentos, empilhando o comportamento dos editores

Parece que ainda temos que justificar repetidamente a existência de guias, quanto mais seu comportamento. No mínimo, suponho, essa referência é uma de três para Eliminar os obstáculos à

Com isso em mente, acho que se eles pelo menos atribuíssem a alguém, poderíamos ficar tranquilos com o que

EDITAR Talvez essa falta de compromisso da equipe do VS Code seja um mal-entendido - afinal, o plano de iteração de março não foi atualizado desde 7 de janeiro.

@ jayrosen1576 Eu concordo - e acho que 1% das solicitações do usuário que não seriam cobertas poderiam ser atendidas por meio de extensões (por exemplo, abrir arquivos com relações em grupos de guias, etc.).

@ jayrosen1576 O atom permite vincular arquivos para que você possa ter uma visão dividida que (por exemplo) abre toolbar.html no primeiro quadro, toolbar.js no segundo e toolbar.css no terceiro?

Este é apenas um exemplo, mas seria absolutamente ideal. Alguém acima disse que o Vim pode fazer isso, mas eu verifiquei o vim e não gostei dele por uma série de razões, mas a coisa da guia parece excelente.

@ jon64digital Atom não faz isso por padrão, e eu não conheço nenhuma extensão que o faça (até mesmo extensões inspiradas no vim), mas este é o caso de uso de extensão a que me referi em meu último post.

EDIT, consulte o comentário de @jtosey acima (cerca de 9 dias antes deste post).

Pessoalmente, acho que isso é um aborrecimento. Metade do tempo eu não me importo com a visualização - apenas o controlador, modelo e JS do lado do cliente. Eu provavelmente ficaria louco se a visualização abrisse toda vez que abrisse o JS.

Mas, novamente, essa é a beleza de uma extensão - se eu não gostar, posso desligá-la.

Ao trabalhar em solicitações de recursos como essa, que têm um impacto muito forte na experiência do usuário, normalmente passamos algum tempo em reuniões de experiência do usuário para discutir como a implementação real deve ser. Fazia algum tempo que tínhamos

Pegaremos este item após o lançamento do GA no final do mês e iniciaremos a discussão sobre como o gerenciamento de documentos deve funcionar no futuro. Vemos algumas falhas na forma como as coisas funcionam e sabemos que precisamos melhorá-la. Achamos que mesmo sem abas, há algumas coisas que simplesmente não são muito intuitivas na maneira como a UX se comporta hoje (Fechar Editor vs. Fechar Arquivo, o fato de que os editores laterais estão se comportando de maneira diferente em comparação com outros editores, arquivos de trabalho e aberto, etc.).

Embora o conceito de guias seja bem compreendido, não achamos que poderíamos simplesmente adicionar guias no topo de nosso gerenciamento de documentos existente sem revisitar nossos conceitos lá.

Acho que teremos muitas discussões sobre como o gerenciamento de documentos deve funcionar no futuro e acho que estamos prontos para revisar os conceitos conforme consideramos necessário.

@bpasero depois de revisar o código de outro problema, não entendo por que não é possível apenas adicionar guias ou quais conceitos você teria que alterar ao fazer isso. Poderia ser um longo caminho se você pudesse nos esclarecer, ou isso é uma referência à linha de pensamento em seus posts originais?

@bpasero Foi bom se você elaborou mais sobre o que é discutido e quais são algumas das abordagens que você vê como possíveis soluções para os problemas que postamos.

PS: Não tenho certeza se isso é possível com o VSCode, mas algumas equipes como Roslyn, TypeScript e alguns outros compartilham suas notas de design, dá muito contexto de como eles funcionam e o que está por vir, também abre a comunidade para novas discussões algo assim é possível?

@bpasero a equipe consideraria seriamente as tentativas da comunidade de adicionar guias. Não me importo de tentar, mas acho que ninguém quer perder seu tempo se algum esforço for bloqueado

Acho que sua equipe está bloqueada por ter feito este pequeno morro na montanha.

Significado: as guias são constituintes, e não sinônimos, do conceito mais amplo de gerenciamento de documentos. Existem outras questões já arquivadas que tratam de outras áreas de gerenciamento de documentos do vscode.

Já discutimos nossas ideias de UX por meio de questões abertas (consulte https://github.com/Microsoft/vscode/issues?q=is%3Aopen+is%3Aissue+label%3Aux), eu presumiria que faríamos o mesmo para gerenciamento de documentos e guias.

Também acho que não gostaríamos que essas melhorias fossem feitas por meio de extensões, mas sim tê-las como um conceito central no ambiente de trabalho do VS Code.

Assim que começarmos a discussão de UX na equipe, gostaríamos de envolver a comunidade também e, então, também discutiríamos as falhas que vemos em nosso design atual e o que planejamos melhorar.

@bpasero muito obrigado, isso é tudo que eu queria saber. :)

@bpasero Awesome. Eu sei que vocês estão colocando um grande esforço no produto e todos nós realmente apreciamos isso. Acho que muitos de nós apenas sentimos alguma frustração com a falta de guias na interface do usuário, já que dependemos muito delas e mudar completamente a maneira como trabalhamos não é realmente uma opção. Queremos que este seja o melhor editor que existe e está muito perto de conseguir isso.

Sem ler este tópico inteiro, dou um grande: +1: sobre isso.

Eu uso o Sublime há anos e adoro as guias. Vejo que os arquivos de trabalho preenchem algumas lacunas, mas não completamente. Não posso explicar totalmente o porquê, mas, por favor, me dê minhas guias!

+1

Extremamente necessário.

+1

Eu trabalho em muitos tipos de arquivos diferentes durante o desenvolvimento, então geralmente gosto de criar um grupo de guias no lado direito para um tipo de arquivo e outro grupo de guias à esquerda para outros tipos de arquivos. Por exemplo, ao trabalhar no código do transferidor / webdriverjs, gosto de manter todos os "Objetos de página" à direita e todas as "especificações" à esquerda, agrupados separadamente e de forma lógica. Da mesma forma, ao trabalhar no front-end, vou manter um grupo de guias à direita para todos os arquivos js / ts e outro à esquerda para html e css.

Esses são apenas dois exemplos, mas eu faço isso TODO o tempo em quase todos os projetos até certo ponto e essa estratégia tem me servido bem por muitos anos de desenvolvimento e eu a considero extremamente útil.

Embora o Code certamente me permita ter vários painéis, a abordagem da lista de arquivos global torna mais difícil diferenciar entre os tipos de arquivo e, portanto, perco muito tempo percorrendo a lista do arquivo que eu queria visualizar. Além disso, quando eu (instintivamente) tento fechar apenas um arquivo no painel direito, todo o painel desaparece, o que é extremamente frustrante, especialmente depois de usar o VS regular por mais de 16 anos, o que me treinou para esperar que o painel permaneça aberto com o resto do os arquivos visíveis.

A falta de grupos de guias no Code é extremamente decepcionante e não acho que as pessoas devam ser forçadas ou convencidas a trabalhar de determinada maneira porque "é melhor" ou "não há um bom motivo para guias" em sua opinião. Sim existe. Talvez você simplesmente não os use da melhor maneira ou não ache que são úteis, mas muitos de nós fazemos e realmente apreciariam algo tão básico como grupos de guias.

Meu entendimento é que o Código é baseado no Atom, que já tem suporte para grupos de guias. Parece que seria necessário muito trabalho extra para remover essa funcionalidade, o que simplesmente não faz muito sentido para mim. No mínimo, permita que o usuário escolha a experiência que deseja, para que possa usar o Código da maneira que for melhor para ele.

Por favor, traga grupos de guias de volta para o VS Code.

Talvez se você desenhar caixas ao redor dos nomes de arquivo na lista de Arquivos de Trabalho, as pessoas verão que é funcionalmente equivalente às guias do lado esquerdo ... :-)

@ChrisMiami : exceto que não é . (Eu estaria potencialmente disposto a viver com isso se fosse.)

ri muito

Em Qui, 17 de março de 2016 às 4:59 Kenneth G. Franqueiro <
notificaçõ[email protected]> escreveu:

@ChrisMiami https://github.com/ChrisMiami : exceto que não é
https://github.com/Microsoft/vscode/issues/224#issuecomment -166931316.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -197603728

@kfranqueiro enquanto espera por uma solução de tabulação adequada, você pode estar interessado em adotar os atalhos de teclado que uso, que trazem ctrl + w e ctrl + shift + w mais perto de uma implementação de tabs regulares.

@ nub340 VSCode não é baseado no Atom, mas no Electron, que foi feito pelo mesmo grupo que está trabalhando no Atom.

+1 Por favor, adicione !!!

Eu também acho que esse é um recurso que falta em um grande editor.

Adicione guias como uma opção ou permita um plug-in de terceiros para a funcionalidade de guias.

A primeira coisa que me impressionou sobre o VSC (depois do nome bobo) foi como _grande_ era _não_ ter guias.

Atualmente, tenho 8 arquivos abertos - as guias são inúteis para mim, porque os nomes dos arquivos não aparecem nas guias.

Eu _adore_ CTRL + TAB e a lista de 'arquivos de trabalho'.

Se você precisar adicionar guias, torne-as opcionais.

@leegee Eles não são "inúteis", você simplesmente não precisa deles. Você considerou que as pessoas que estão trabalhando em diferentes tipos de projetos podem ter um caso de uso diferente para você?

Dê às milhares de pessoas que votaram nas guias, acho que a única coisa "inútil" por aqui é o seu comentário :)

@ jon64digital : Percebi que o projeto pedia comentários gerais dos usuários sobre a possibilidade de guias - entendi que isso significava que deveríamos expressar nossas próprias opiniões. Agora percebo que deveria ter lhe enviado um e-mail primeiro, para que pudesse expressar sua opinião e evitar sua injúria ad-hominem grosseira. Me desculpe.

@ jon64digital @leegee disse que eram inúteis _para ele_, não em geral. Eu apoio totalmente as guias, mas concordo que devem ser uma opção que pode ser desativada para aqueles que não as usam. Vamos manter a discussão civilizada e não recorrer a ataques pessoais. Ninguém tem uma opinião incorreta. Eles são apenas isso ... opiniões.

@ jayrosen1576 Ele editou seu comentário. Se ele tivesse originalmente dito "inútil para mim", então é claro que eu não teria dito o que disse. Também presumo que as duas outras pessoas que votaram negativamente em seu comentário o fizeram antes de ele editá-lo.

Concordo totalmente que todos têm direito a uma opinião, mas parece que várias pessoas aqui que não exigem guias em seu fluxo de trabalho estão tentando negar aqueles que as desejam, colocando -1 ou dizendo à MS que o recurso é não exigido ou desviaria de alguma forma recursos de recursos mais importantes. Visto que eles podem ver quantas pessoas querem tabs, acho isso egoísta e um pouco imaturo.

De qualquer forma, peço desculpas se alguém viu isso como um ataque pessoal. Eu coloquei um smiley depois disso.

Acho que esta discussão apenas ilustra que existem muitas maneiras de um desenvolvedor usar um IDE e todas elas são perfeitamente válidas para seu caso de uso. Não existe uma maneira "certa" e, no final do dia, é apenas uma ferramenta para fazer o trabalho. Alguns desenvolvedores gostam de guias para que possam agrupar arquivos semelhantes de forma arbitrária e outros encontram uma única lista MRU perfeitamente adequada. Então você tem aqueles que só usam bloco de notas para tudo e somos todos um bando de amores-perfeitos ha-ha.

Sério, eu sinto que, uma vez que as guias têm sido uma parte essencial do Visual Studio para quase todos os tempos, muitos desenvolvedores se acostumaram com sua utilidade e, portanto, tornam a lista MRU única opcional (opt-in ou out) tornaria a ferramenta já incrível que o VS Code é ainda mais versátil, para todos.

@ nub340 exatamente! alguns de nós gostam de guias porque sempre fizeram parte de nossa experiência como desenvolvedores / usuários, pessoalmente, gosto de ver os arquivos em que estou trabalhando na parte superior, não há nenhuma vantagem inerente às guias sobre os arquivos de trabalho, mas é assim que alguns dos nós gostamos.

Concordo, eu gostaria como uma opção, não forçá-la.
Na terça, 22 de março de 2016 às 6h22 Eyal Solnik [email protected]
escrevi:

@ nub340 https://github.com/nub340 exatamente! alguns de nós gostam de guias porque
eles sempre fizeram parte da nossa experiência como desenvolvedores / usuários, pessoalmente eu gosto
para ver os arquivos em que estou trabalhando na parte superior, não há
vantagem para as guias sobre os arquivos de trabalho, mas é assim que alguns de nós gostam.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -199565160

Não tínhamos guias no Vic-20 ....

Uma coisa que sai dessa discussão é que tudo o que é (feito)
disponível, deve ser personalizável.

@glennblock , @leegee sim, definitivamente deveria ser uma opção, mas o arquivo de trabalho não deveria receber o mesmo tratamento para aqueles que não o querem? no entanto, provavelmente é melhor discuti-lo em outra solicitação de recurso. :)

Postei este texto aqui: https://github.com/Microsoft/vscode/issues/101

Também é válido para esta discussão. Eu ficaria feliz em ver a resposta de @bpasero .

Eu quero esse recurso. Fim de discussão. Foda-se suas opiniões @bpasero , não me importo com o que você acha que é certo ou não. O mesmo se aplica às guias # 224. Você está tentando nos convencer de que sua solução é a melhor. Mais uma vez foda-se sua solução. Todos nós fazemos as coisas de maneira diferente e ninguém se importa com o que você pensa. Estou usando o vscode apenas por causa do grande suporte de typescript e angular2. Caso contrário, eu odeio porque não tem recursos que os editores normais têm, por exemplo, SublimeText, Atom, Brackets

Haha @PeterMtj , obrigado por dizer o que todos estamos pensando :)

@bpasero parece ter o hábito de rejeitar e desacreditar qualquer recurso que ele não usaria pessoalmente e que não se encaixe em seu fluxo de trabalho pessoal.

As pessoas usam softwares da Microsoft principalmente porque precisam, raramente porque gostam, e quando você vê que a equipe da Microsoft tem atitudes como a dele, isso mostra porque eles não podem projetar um software decente como o Sublime Text. Eu tentei o meu melhor com o VS Code, mas estou muito perto de desinstalá-lo.

@PeterMtj Sério? é assim que você aborda as coisas? amaldiçoar as pessoas? se você não tem respeito por ele, tenha algum respeito por si mesmo!

@ jon64digital Ele pode votar contra ou dizer sua opinião pessoal e tudo bem! não precisamos ser pessoais e certamente não amaldiçoar as pessoas por suas opiniões!

Também discordo da resposta inicial dele, dizendo "Não" não é profissional e muito rude na minha opinião, mas acho que a comunidade pode fazer melhor e permanecer civilizada independentemente da opinião das pessoas.

As pessoas usam softwares da Microsoft principalmente porque precisam, raramente porque gostam, e quando você vê que a equipe da Microsoft tem atitudes como a dele, isso mostra porque eles não podem projetar um software decente como o Sublime Text. Eu tentei o meu melhor com o VS Code, mas estou muito perto de desinstalá-lo.

Edit: As pessoas não precisam usar produtos Microsoft! Eu certamente não tenho que fazer isso e dizer que as pessoas raramente fazem isso porque gostam, é só conversa fiada! A Microsoft faz alguns produtos e tecnologias excelentes e estou longe de ser um fã de tudo o que eles fazem, mas certamente fazem algumas coisas certas! ninguém força ninguém a usar o VSCode e se alguém o forçar a usar o VSCode, ele / ela deve ser demitido porque você precisa escolher suas próprias ferramentas! a única coisa com que um empregador deve se preocupar é com o seu trabalho e não com o modo como ele é feito!

Não vamos transformar isso em uma guerra de insultos e mantê-la construtiva, por favor!

@eyalsk

Eu não estava tentando iniciar uma guerra de insultos, ou falando mal, mas eu mantenho 100% o que eu disse. A MS historicamente vinculou seus próprios produtos ao sistema operacional e uns aos outros para forçar as pessoas a usar seu software, porque sabem que não é bom o suficiente para se manter por conta própria. Conheço muitas pessoas que precisam usar o MS Office no trabalho, já tive que usar o Visual Studio antes porque não tinha outra escolha e podia contar o número de pessoas que usariam voluntariamente o Internet Explorer nos dedos de uma mão. Eles até já foram objeto de processos antitruste por causa dessas práticas, então dizer que ninguém está fazendo ninguém usar software MS é ingênuo.

As coisas mudaram na direção certa recentemente e eles estão se tornando mais agnósticos quanto à plataforma e tentando melhorar a interoperabilidade de seu software com os outros. Tenho certeza de que existem boas pessoas na MS tentando fazer ótimos softwares e dando às pessoas o que elas querem, mas bpasero claramente não é uma delas. Sua atitude de mente fechada não é um crédito para eles e eu achei engraçado que @PeterMtj o chamasse dessa forma. Somos todos adultos aqui e ninguém deveria se ofender com um ou outro palavrão. É apenas uma palavra.

Você tem um longo tópico aqui com centenas de pessoas dizendo à MS EXATAMENTE o que querem de um editor de código. Não é como se eles não soubessem o que queremos. Então temos um funcionário da MS aqui dizendo "não, você está basicamente errado". Isso não retrata uma empresa que não está exatamente em sintonia com seu público?

Apenas meu 2c.

@ jon64digital

Eu não estava tentando iniciar uma guerra de insultos, ou falando mal, mas eu mantenho 100% o que eu disse. A MS historicamente vinculou seus próprios produtos ao sistema operacional e uns aos outros para forçar as pessoas a usar seu software, porque sabem que não é bom o suficiente para se manter por conta própria.

Essa é apenas sua suposição de preconceito e eu respeito isso, mas podemos dizer exatamente a mesma coisa sobre qualquer outra empresa no mundo, para citar alguns Apple, Oracle e Google ...

Eu conheço muitas pessoas que precisam usar o MS Office no trabalho,

As pessoas não são obrigadas a usar o MS Office, essa é a decisão do empregador, o Libre office é um ótimo produto e é uma boa alternativa.

Eu tive que usar o Visual Studio antes porque não tinha outra escolha

Eu não sei _por que_ você não teve escolha, mas você definitivamente tem escolhas hoje! Eu sempre tive uma escolha mesmo quando as pessoas usaram fortemente o Visual Studio para desenvolvimento .NET. Eu usei SharpDevelop, Vim e Notepad ++, nunca tive problemas em usar vários editores, não sou fã de designers mesmo ...

Para C / ++, você tem ainda mais suporte de editores e IDEs, a menos que use VC ++ :)

Além disso, eu nunca entendi por que algumas pessoas estão se prendendo a uma pilha específica de tecnologias feitas por X, existem muitas tecnologias por aí além, digamos, da Microsoft.

Eu poderia contar o número de pessoas que usariam voluntariamente o Internet Explorer com os dedos de uma mão.

Você está certo, o Internet Explorer era muito ruim até a versão 9, mas eles melhoraram bastante desde então e, embora eu seja um usuário do FireFox, não julgo a Microsoft por seu passado, eu os julgo por quem eles são o presente e parece bom!

Eles até já foram objeto de processos antitruste por causa dessas práticas, então dizer que ninguém está fazendo ninguém usar software MS é ingênuo.

Ninguém está obrigando ninguém a usar nada e não sei sobre a maioria das pessoas, mas estou longe de ser ingênuo, sou apenas razoável.

Se o seu empregador opta por usar tecnologias MS, então você certamente é _forçado_, mas novamente não é culpa da Microsoft, se você escolheu usar tecnologias MS, então você escolheu e reclamar disso é um pouco bobo, existem tecnologias equivalentes que são tão bons quanto os da Microsoft, então as pessoas certamente têm opções.

As coisas mudaram na direção certa recentemente e eles estão se tornando mais agnósticos quanto à plataforma e tentando melhorar a interoperabilidade de seu software com os outros. Tenho certeza de que existem boas pessoas na MS tentando fazer um ótimo software e dando às pessoas o que elas querem,

Exatamente! embora eu não ache que dar às pessoas o que elas querem seja bom do ponto de vista do design. :)

mas bpasero claramente não é um deles. Sua atitude de mente fechada não é um crédito para eles e eu achei engraçado que @PeterMtj o chamasse dessa forma. Somos todos adultos aqui e ninguém deveria se ofender com um ou outro palavrão. É apenas uma palavra.

Não acho que precisamos definir as pessoas com base em suas opiniões, certamente não esse tipo de opinião, e ser adulto não torna as pessoas vulneráveis ​​a ataques pessoais de qualquer tipo, jurar que uma pessoa não é agradável e deve ser desencorajada, agir como um adulto significa que você pode controlar sua raiva e escrever sua opinião sobre alguém ou algo sem ser ofensivo.

Você tem um longo tópico aqui com centenas de pessoas dizendo à MS EXATAMENTE o que querem de um editor de código. Não é como se eles não soubessem o que queremos. Então temos um funcionário da MS aqui dizendo "não, você está basicamente errado". Isso não retrata uma empresa que não está exatamente em sintonia com seu público?

Esse é um ponto justo e reclamação, não estou dizendo o contrário! mas @bpasero já afirmou que assim que trabalharem no UX, também resolverão esse problema "_Uma vez que começarmos a discussão UX na equipe, gostaríamos de envolver a comunidade também e, então, também discutiríamos as falhas que vemos em nosso design atual e o que planejamos melhorar._ "

@eyalsk Sim, é exatamente assim que eu

@ jon64digital está certo sobre a atitude @bpasero . Não sei o que pensar dele. Talvez ele só queira se livrar do trabalho dizendo que você está errado e que não é necessário. De qualquer forma, @bpasero provavelmente não deve se comunicar com a comunidade com sua atitude. Essa é a minha opinião.

Tente perceber que a Microsoft não está nos ajudando. Estamos ajudando a Microsoft usando seus produtos e dando feedback para que eles possam fazer produtos decentes. Esta não deve ser uma discussão sobre a defesa de guias, mas sobre como as guias devem funcionar, por isso é natural com o vscode. Vscode é para a comunidade, somos nós e em casos extremos, se todos quisermos um dinossauro vermelho no meio da tela, eles deveriam fazê-lo sem questionar os motivos. Todos nós temos nossas próprias razões. Caso contrário, o vscode é inútil para a comunidade. É assim que eu vejo.

@PeterMtj Acho que teremos que concordar em discordar. :)

Eu queria pular e fornecer algumas informações adicionais sobre esse problema. Estamos prestes a encerrar um marco importante do Código. O foco principal para nós nos últimos 6 meses foi o suporte para acessibilidade e localização. Isso nos deixou sem ciclos na área da IU para trabalhar ativamente no feedback das guias. Agora que a maioria das caixas de seleção no plano de março (# 3555) está marcada, estamos lentamente começando a olhar para cima novamente. Em abril, vamos nos aprofundar nesse tópico. @bpasero teve um papel fundamental no desenvolvimento de nossa

Obrigado a todos por sua paixão e feedback, ajudando-nos a fazer do VS Code o melhor produto que pode ser.

TIA para as adições de acessibilidade - fará uma grande diferença para nós
meio cego

No sábado, 26 de março de 2016, 01:38 Erich Gamma, [email protected] escreveu:

Eu queria pular e fornecer algumas informações adicionais sobre esse problema.
Estamos prestes a encerrar um marco importante do Código. Um foco principal para nós
nos últimos 6 meses houve suporte para acessibilidade e localização. este
não nos deixou ciclos na área da interface do usuário para trabalhar ativamente no feedback das guias.
Agora que a maioria das caixas de seleção no plano de março (# 3555
https://github.com/Microsoft/vscode/issues/3555) estão verificados, nós estamos
lentamente começando a olhar para cima novamente. Em abril, vamos nos aprofundar nesse tópico.
@bpasero https://github.com/bpasero desempenhou um papel fundamental no
desenvolvimento de nossa UX e esta será a próxima grande evolução.

Obrigado a todos por sua paixão e feedback, ajudando-nos a tornar o VS Code o
melhor produto que pode ser.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -201618115

@egamma Agradeço muito a você e sua equipe por tudo, acho que você está fazendo um ótimo trabalho! mas acho que a primeira resposta de @bpasero irritou as pessoas e isso poderia ter sido evitado se ele ideia de por que ele acha que as tabulações não deveriam ser uma opção em vez de apenas dizer "Não".

De qualquer forma, vamos nos concentrar no presente, há alguma nova construção antes do // build / evento? : D

@eyalsk Eu acredito que o comentário "Não" estava realmente se referindo à primeira resposta de @inakianduaga , em que não é possível implementar abas usando a API de extensão atual. Acho que isso foi mal interpretado como uma declaração de que as guias nunca acontecerão; no entanto, o problema provavelmente teria sido encerrado se fosse o caso.

@Tyriar ,

De qualquer forma, vamos nos concentrar no presente, há alguma nova construção antes do // build / evento? : D

Os bits para a nova construção já estão esperando por você no canal interno ( notas de lançamento ), use-o e nos dê feedback.

@egamma obrigado! ;)

Estamos iniciando o trabalho de design desta experiência e gostaríamos de envolver a comunidade o máximo que pudermos. Estarei conduzindo discussões regulares sobre design à medida que progredimos para receber seus comentários. Na maioria das vezes, essas serão sessões individuais, nas quais compartilhamos o que estamos fazendo e discutimos com você.

As primeiras sessões acontecerão nesta quarta-feira. Inscreva-se aqui se estiver interessado: https://calendly.com/stevencl/visual-studio-code-tabs-design-discussion/04-06-2016

Impressionante!
Na segunda-feira, 4 de abril de 2016 às 03h54 Steven Clarke [email protected]
escrevi:

Estamos começando o trabalho de design nesta experiência e gostaríamos de
envolver a comunidade tanto quanto pudermos. Eu estarei executando o design normal
discussões à medida que avançamos para obter seu feedback. Na maioria das vezes, eles vão
ser um a um sessões onde compartilhamos o que estamos trabalhando e discutimos
eles com você.

As primeiras sessões acontecerão nesta quarta-feira. Por favor, inscreva-se aqui se
você está interessado:
https://calendly.com/stevencl/visual-studio-code-tabs-design-discussion/04-06-2016

-
Você está recebendo isso porque foi mencionado.

Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205239769

Estamos ansiosos para ouvir seus comentários sobre os novos designs que estamos explorando relacionados a esse problema. Se você estiver interessado, inscreva-se pelo link no comentário de @stevencl acima!

3 e 4 da manhã apenas? Nenhuma outra vez? Não posso chegar às 3/4 da manhã PST em uma quarta-feira.

Na segunda-feira, 4 de abril de 2016 às 8:14 AM Brad Gashler [email protected]
escrevi:

Estamos ansiosos para ouvir seus comentários sobre os novos designs que estamos explorando
relacionados a este problema. Se você estiver interessado, inscreva-se através do link em
Comentário de Steven acima!

-
Você está recebendo isso porque foi mencionado.

Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205342923

Seria bom se você tivesse tempo de acordo com o PST, muitos (inclusive eu) podem participar

{Móvel}

Na segunda-feira, 4 de abril de 2016 às 8h50 -0700, "Glenn Block" [email protected] escreveu:

3 e 4 da manhã apenas? Nenhuma outra vez? Não posso chegar às 3/4 da manhã PST em uma quarta-feira.

Na segunda-feira, 4 de abril de 2016 às 8:14 AM Brad Gashler [email protected]

escrevi:

Estamos ansiosos para ouvir seus comentários sobre os novos designs que estamos explorando

relacionados a este problema. Se você estiver interessado, inscreva-se através do link em

Comentário de Steven acima!

-

Você está recebendo isso porque foi mencionado.

Responda a este e-mail diretamente ou visualize-o no GitHub

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

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente ou visualize-o no GitHub

Sim por favor. Eu definitivamente gostaria de fazer parte da conversa.

Desculpe, sei que esses horários não são convenientes para todos. No futuro, examinaremos maneiras de agendar sessões em diferentes fusos horários, pois planejamos realizá-las regularmente.

Por que não agendar um adicional esta semana em um horário diferente? Isto é um
tópico quente com muito interesse.

Na segunda-feira, 4 de abril de 2016 às 9h44 Steven Clarke [email protected]
escrevi:

Desculpe, sei que esses horários não são convenientes para todos. No futuro nós
analisará maneiras de agendar sessões em diferentes fusos horários,
planeje mantê-los regularmente.

-
Você está recebendo isso porque foi mencionado.

Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205386984

Para que você saiba, os intervalos de tempo que você vê são apenas aqueles que ainda estão disponíveis. Eu tinha vagas abertas no final do dia, mas elas foram ocupadas rapidamente.

Como eu disse, tentaremos agendar sessões em diferentes fusos horários no futuro.

Obrigado por todo o interesse.

Eu vejo, bem, eu acho que eles encheram instantaneamente (o que é bom)
Na segunda-feira, 4 de abril de 2016 às 11h30 Steven Clarke [email protected]
escrevi:

Só para você saber, os intervalos de tempo que você vê são apenas aqueles que são
ainda disponível. Eu tinha vagas abertas no final do dia, mas elas foram ocupadas
bem rápido.

Como eu disse, tentaremos agendar sessões em diferentes fusos horários em
o futuro.

Obrigado por todo o interesse.

-
Você está recebendo isso porque foi mencionado.

Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205436942

Você pode / você pode gravar as sessões?

Na segunda-feira, 4 de abril de 2016 às 11h32 Glenn Block glenn. [email protected] escreveu:

Eu vejo, bem, eu acho que eles encheram instantaneamente (o que é bom)
Na segunda-feira, 4 de abril de 2016 às 11h30 Steven Clarke [email protected]
escrevi:

Só para você saber, os intervalos de tempo que você vê são apenas aqueles que são
ainda disponível. Eu tinha vagas abertas no final do dia, mas elas foram ocupadas
bem rápido.

Como eu disse, tentaremos agendar sessões em diferentes fusos horários em
o futuro.

Obrigado por todo o interesse.

-
Você está recebendo isso porque foi mencionado.

Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205436942

Gostaria de ter visto isso antes para poder ter me inscrito. Se valer a pena, espero que você nunca implemente guias. Eu progredi de vim para TextMate para Sublime para Atom e agora para VS Code (com muitos IDEs ao longo do caminho), então tive MUITA experiência com guias. Para mim, eles são uma muleta que as pessoas usam e nunca passam. Gerenciar muitas guias abertas em um grande projeto é um exercício de frustração que adiciona mais uma tarefa que eu não preciso. Esqueça de fechar alguns e rapidamente se tornará impossível. Para aqueles poucos de vocês que têm disciplina para nunca encontrar isso, parabéns. Mas por que gastar energia mental em uma tarefa desnecessária?

Mais importante, acho que as guias fazem as pessoas pensarem em termos de ARQUIVOS, quando (para a maioria do desenvolvimento de código) elas deveriam se concentrar em funções, classes, namespaces - símbolos. Os arquivos são um detalhe de implementação na maioria dos casos que não devem dominar sua navegação. Acho que o VS Code tem uma oportunidade real de fornecer algo novo e melhor.

Sei que essa é apenas MINHA preferência e entendo por que tantas pessoas estão pedindo que as guias sejam opcionais. Isso pode parecer um meio-termo razoável, mas seria difícil suportar bem dois fluxos de trabalho de navegação diferentes. Experimente desligar o plug-in de guias no Atom e ver quantas coisas não funcionam ou funcionam mal porque os desenvolvedores esperam que as guias estejam lá. Portanto, por minhas próprias razões egoístas, quero que os desenvolvedores do VS Code se concentrem na navegação que não é baseada em guias (ou mesmo em arquivos).

Idem @indiejames

Se você implementar guias, suporte várias linhas para muitos arquivos. Eu odeio ter uma barra de rolagem na minha barra de guias. Minha implementação de guias favoritas é Tabs Studio . Veja também como arquivos com o mesmo nome de base podem ser agrupados automaticamente.

Meu fluxo de trabalho Abro guias enquanto trabalho no Sublime conforme preciso. Eu não deixo toneladas de guias abertas e costumo usar "fechar tudo" para trazer as coisas de volta para uma lousa limpa.

Tenho desenvolvido mais de 30 anos em vários IDEs e editores de texto. Não vejo as guias como uma muleta, elas são uma ferramenta organizacional útil. Sim, eles podem ficar fora de controle se você tiver zilhões de guias, mas eu não ...

Em termos de guias voltadas para o foco em arquivos e coisas semelhantes, o código reside em arquivos, e os arquivos SÃO usados ​​para organização, e o código do VS é construído em torno do gerenciamento de pastas e arquivos de código.

Eu entendo totalmente que alguns podem preferir não ter guias e não estou dizendo para se livrar do que está lá, mas ter um fluxo de trabalho de guias com suporte seria bom.
Na terça-feira, 5 de abril de 2016 às 7h32, erro notificaçõ[email protected] escreveu:

Se você implementar guias, suporte várias linhas para muitos arquivos. eu odeio
ter uma barra de rolagem na minha barra de guias. Minha implementação de guias favoritas é Tabs
Studio https://tabsstudio.com/.

-
Você está recebendo isso porque foi mencionado.

Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205834354

"Facilita o uso indevido do produto pelos usuários" é um motivo terrível para não oferecer suporte a um recurso. A ferramenta existe para _facilitar_ fluxos de trabalho, não para _ditá-los_. Se um usuário não consegue encontrar um fluxo de trabalho confortável, é mais provável que ele escolha outra ferramenta onde puder, em vez de se adaptar a um paradigma desconhecido.

Atualmente estou trabalhando em alguns arquivos intimamente relacionados, alternando entre eles. Sempre que preciso alternar, preciso escolher na barra lateral ou em uma lista suspensa, o que leva de 3 a 4 vezes mais que uma guia.

@indiejames

mas seria difícil suportar bem dois fluxos de trabalho de navegação diferentes. Experimente ativar o plug-in de guias no Atom e ver como as coisas podem não funcionar ou funcionar mal porque os desenvolvedores esperam que as guias estejam lá. Portanto, por minhas próprias razões egoístas, quero que os desenvolvedores do VS Code se concentrem na navegação que não é baseada em guias (ou mesmo em arquivos).

Não é muito difícil suportar dois fluxos de trabalho de navegação diferentes ou até mais de dois, o que é realmente difícil é acertar o design!

Se você realmente deseja oferecer suporte a guias e arquivos de trabalho ou outro fluxo de trabalho, precisa retroceder alguns passos, diminuir o zoom e redesenhar a navegação do zero, tornando os fluxos de trabalho uma estratégia que as pessoas podem escolher.

Criar uma extensão apenas para ter guias no editor sem considerar casos de uso e como as pessoas estão trabalhando com guias ou outro fluxo de trabalho é apenas perder a causa, o que não adiciona nenhum benefício real e, portanto, provavelmente é uma falha.

Há uma diferença entre navegação de código e navegação de arquivo, quando você codifica, certamente precisa
pense em símbolos em vez de arquivos, mas o código reside em arquivos e às vezes você precisa lidar com isso também, por exemplo, não abro muitas guias, mas quando estou trabalhando em vários projetos, geralmente tenho um arquivo por projeto aberto que está relacionado, uso muito as teclas de atalho, mas como as guias estão sempre no topo, e quando eu olho para o editor, elas estão sempre lá, provavelmente é psicológico, mas apenas me ajuda a me concentrar.

Sua experiência com guias é lamentável e eu não subestimo sua experiência de forma alguma, não sei como você trabalha, mas muitos de nós gostam e usam com grande sucesso.

Não acho que uma experiência seja melhor do que a outra, mas ter experiências diferentes ou mesmo híbridas pode ser útil e os editores devem honrar minha experiência e não ir contra ela.

Seria muito útil para nós que não pudemos comparecer às reuniões devido a outros compromissos, poder dar um feedback.
Talvez, uma vez que as reuniões terminem no primeiro dia, postar um vídeo de uma reunião (com a permissão de todos os envolvidos) que outras pessoas possam ver e comentar dentro do tempo restante para as reuniões?

Obviamente, não pode ser um longo período, mas mais feedback não pode machucar com alguns pontos de vista diferentes adicionados.

Eu realmente espero que alguns desenvolvedores de Python e c / c ++ estejam na reunião, pois seu fluxo de trabalho é diferente de um fluxo de trabalho de desenvolvimento de JavaScript

Obrigado Steven por falar comigo!
Este envolvimento com a comunidade é muito encorajador e estou gostando
seguindo o desenvolvimento do vscode!

Em 6 de abril de 2016 às 19:41, Michael Wallace Louwrens < notificaçõ[email protected]

escrevi:

Seria muito útil para nós que não podemos fazer as reuniões devido a outros
compromissos para poder dar feedback.
Talvez, quando as reuniões terminarem no primeiro dia, postar um vídeo de um
reunião (com a permissão de todos os envolvidos) que outros podem ver e comentar
dentro do tempo restante para reuniões?

Obviamente, não pode ser um longo período, mas mais feedback não pode prejudicar com
esperançosamente alguns pontos de vista diferentes adicionados.

Eu realmente espero que alguns devs Python e devs c / c ++ estejam na reunião como
seu fluxo de trabalho é diferente do fluxo de trabalho de um desenvolvedor de JavaScript

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -206261939

Obrigado @TurkeyMan , ótimo bate-papo com você hoje cedo.

Para todos os outros que não puderam participar, faremos isso regularmente, para que haja oportunidades de participar em uma data posterior.

As conversas que estamos tendo esta semana são todas conversas 1: 1 durante as quais discutimos os detalhes dos problemas que cada indivíduo experimentou. Isso nos permite obter uma compreensão mais profunda dos problemas que precisamos resolver.

Nas semanas subsequentes, quando revisarmos os modelos de design, procuraremos maneiras de ter discussões em grupo, bem como discussões 1: 1. Também veremos como podemos gravar e postar vídeos de reuniões posteriormente.

@stevencl é possível postar um resumo das sessões (ou melhor, gravações) para aqueles de nós que não

+1
Na quarta-feira, 6 de abril de 2016 às 7h36 Peter Petrov [email protected]
escrevi:

@stevencl https://github.com/stevencl é possível postar um resumo
das sessões (ou melhor, gravações) para aqueles de nós que são incapazes
para participar, mas ainda está interessado em fornecer feedback.

-
Você está recebendo isso porque foi mencionado.

Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -206405009

Gostaria de contribuir com minhas expectativas de navegação de arquivos em um editor de código. Estou tentando me acostumar com o VScode há semanas e continuo voltando para o Sublime. Aqui está o que eu espero:

1. navegação sem mouse
2. capacidade de navegar para frente e para trás no conjunto de arquivos abertos
3. feche arquivos facilmente

Até agora descobri que o VScode infelizmente falha para mim em todos os três. O espaço de trabalho não é intuitivo porque, quando fecho um arquivo, ele não fecha realmente, simplesmente não pode ser editado. Fechar o arquivo é uma atividade mental para removê-lo do conjunto de arquivos com o qual estou trabalhando.

No VScode, quando navego nos arquivos que são abertos _na minha cabeça_, sempre encontro "lixo" que pensei ter sido jogado fora. Isso causa uma distração excepcional e acabo tendo arquivos 20 ish abertos no espaço de trabalho e, eventualmente, não consigo mais rastreá-los e apenas fecho todos eles.

Não consigo usar o teclado para alternar rapidamente entre os arquivos abertos, que _na minha cabeça_ formam uma lista vinculada. A ordem em que os abro é tão significativa quanto a ordem em que os fecho. Acho que Ctrl + Tab é inútil porque tenho que ler os nomes dos arquivos um por um nessa lista e então descobrir para qual tabular. Posso passar de 5 a 8 arquivos abertos para o arquivo certo com muito mais rapidez, simplesmente reconhecendo o conteúdo enquanto ele está piscando ou apenas sabendo em que local da "lista" meu arquivo desejado está.

Espero que faça algum sentido. Tento otimizar meu fluxo de trabalho o máximo possível, uso o teclado e evito o mouse porque ele torna tudo muito mais lento. Eu luto com isso no VScode mais do que antes em qualquer outro editor (textmate, vim, sublime, flash, eclipse, etc ...)

Apenas para reiterar, quaisquer gravações de reuniões que acontecem esta semana não serão disponibilizadas, pois cada reunião é uma conversa 1: 1 em que cada pessoa discute os detalhes de como trabalham e os problemas específicos que têm com o VS Code. Durante essas conversas, não entraremos em grandes detalhes sobre os designs.

Porém, nas semanas subsequentes, procuraremos oportunidades para registrar e disponibilizar reuniões nas quais discutiremos projetos para aprimorar o gerenciamento de documentos no Código VS. Procure outro convite meu na próxima semana para participar da próxima rodada de discussões sobre design.

Obrigado por todos os comentários e os detalhes de como o VS Code funciona ou não para você.

Só porque ninguém parece ter mencionado isso e eu suspeito que não estou sozinho nisso: para mim, as guias em um editor têm tudo a ver com memória espacial - ou seja, onde estou e onde estão as coisas ao meu redor?

Vivemos em um mundo físico. Evoluímos para entender e fazer intuições sobre o espaço ao nosso redor e fazemos isso sem pensar. É por isso que podemos digitar sem olhar para o teclado - nós "simplesmente sabemos" onde estão as teclas e podemos digitar rapidamente. Com as guias, nosso wetware padrão com o qual nascemos pode entrar em ação e sabemos "onde" um arquivo está na tela e podemos aprimorá-lo sem pensar por causa do instinto que usamos todos os dias. Eu "coloco um arquivo" por meio de uma guia no editor e consigo me lembrar de "onde o deixei" exatamente da mesma maneira que consigo lembrar onde coloquei meu controle remoto da TV na próxima vez que precisar mudar de canal supondo que eu já tivesse uma TV)

Para mim, um histórico de arquivos ordenado pelo tempo vai totalmente contra essa compreensão intuitiva do espaço. Se eu sei que "main.java" ou a tecla T do meu teclado está em uma determinada posição, não quero que ela se mova, a menos que eu a mova física e deliberadamente. Se ele se move sozinho, preciso parar e pensar e encontrá-lo. Imagine um controle remoto de TV com rodas que se movem por conta própria em sua casa ou um teclado que reorganiza as teclas com base na data de uso de cada letra! Seria o caos! :-)

Eu realmente gosto do VSCode, mas estou pessoalmente frustrado e lento pela falta de guias. Continue com o bom trabalho - estou ansioso para ver o que você encontrará!

@ matt1
O que você está descrevendo é exatamente o que torna as guias tão limitantes (para mim). As guias são uma metáfora para as guias físicas colocadas em arquivos em um gabinete de arquivo físico e têm as mesmas limitações. Eu preferiria ter um arquivo automatizado no qual posso digitar algumas teclas e acessar minhas informações do que um físico onde tenho que ordenar as coisas sozinho e gerenciar o espaço limitado para guias visíveis.

Estou curioso - você navega pelas guias usando o mouse / trackpad ou usando combinações de teclas em outros editores?
Se você usa atalhos de teclado exclusivamente, talvez tenha algum fluxo de trabalho de guias que não conheço
de e eu adoraria ver isso. Suspeito, entretanto, que muitas pessoas usam o mouse / trackpad - sem perceber como essa troca de contexto é improdutiva e o quanto está atrasando-as ao tirar as mãos das teclas. É fácil de aprender e entender, mas menos poderoso / produtivo do que usar combinações de teclas. Se você se pega "procurando uma guia" com o mouse, pode ser intuitivo e tirar vantagem de seu senso espacial, mas está deixando você mais lento. Não tanto no tempo perdido para o movimento físico, mas na própria mudança de contexto.

Sei que são apenas minhas opiniões e a maioria das pessoas discorda delas, mas é o _Code_ do Visual Studio. Para codificadores / desenvolvedores. E os desenvolvedores perceberam há muito tempo que o shell> gui para a maioria (não todas) as coisas e que as metáforas de desktop, embora fáceis de aprender, são bastante limitantes.

Então, é _possível_ que alguns de vocês dizendo "Não consigo viver sem guias" não exploraram outros fluxos de trabalho? Em caso afirmativo, não vale a pena tentar se a recompensa for aumentar sua produtividade?

Para aqueles de vocês que tentaram trabalhar sem guias e não conseguem se adaptar ou honestamente sentem que as guias os tornam mais produtivos, posso aceitar que esta é apenas uma discordância honesta. Mas para aqueles que defendem metáforas físicas porque "eles trabalharam por 30 anos!" Eu perguntaria se realmente precisamos de _another_ TextMate / Sublime / Atom? Não deveríamos estar tentando mover o envelope?

Não tenho dúvidas de que estou em minoria aqui (mas isso não me torna errado), então este é o último comentário que farei. Sinta-se à vontade para acumular :)

Decidi verificar o VS Code para ver se ele poderia ser um substituto gratuito para o Sublime, mas sem documentos com guias, não é um iniciante. Ser capaz de definir o código do VS em uma única instância, ter vários documentos abertos e alternar facilmente entre eles é um requisito básico de qualquer editor de texto. Manter o Explorer aberto é uma solução alternativa, mas não é incomum ter as guias esquerdas em vez das guias superiores, como no VS, navegadores, Sublime, etc. Ctrl-Tab tem vários problemas, um deles é ter que olhar para o teclado e mover a mão (para algo diferente do mouse), a outra é que ele não é intuitivo. Qualquer um sugerindo que um editor sem guias é algo mais do que BloatedNotepad claramente nunca fez qualquer edição séria de vários documentos, como é necessário quando o depurador percorre algo que tinha mais de um arquivo como entrada do compilador.

@indiejames
As guias não são sobre produtividade para mim. É sobre cognição.

Pessoalmente, nunca descobri que a velocidade de digitação bruta sempre foi o fator limitante da minha produtividade. A programação requer reflexão e consideração - alguns cliques não são um problema no grande esquema das coisas para mim, considerando quanto tempo passamos _pensando_.

@indiejames Eu uso ctrl + (shift +) tab para navegar bastante entre as abas, não necessariamente o mouse. Uma das minhas maiores queixas com arquivos de trabalho é a mesma de @ matt1 - o fato de que ctrl + tab opera na ordem usada mais recentemente. Não me lembro necessariamente de qual arquivo olhei por último e penúltimo, mas é muito fácil para mim ver / lembrar a ordem em que os abri / organizei. Texto Sublime também padroniza ctrl + (shift +) tab para MRU ordem; Eu sempre mudo, pois tem comandos para MRU e ordem visível.

Eu me lembro de algum navegador da Web (talvez tenha sido antes do Blink Opera?) Também usava MRU para ctrl + tab por padrão, presumivelmente imaginando que, como os sistemas operacionais fazem isso para aplicativos, um navegador também pode fazer isso; Eu achei isso terrivelmente não intuitivo e tive que prestar atenção extra para descobrir para onde eu realmente queria voltar ... o que, adivinha, torna o processo _mais lento_.

O argumento de usar abertura rápida exclusivamente também funciona tão bem no Sublime Text com guias quanto no VS Code com arquivos de trabalho. As guias não proíbem esse fluxo de trabalho de forma alguma.

Para aqueles que preferem a abordagem atual de Arquivos de Trabalho no VS Code, quantos de vocês realmente preferem clicar nos arquivos da lista de Arquivos de Trabalho ao invés dos seguintes fluxos de trabalho?

• usando Ctrl + E / ⌘ + E para abrir rapidamente os arquivos recentes.
• usando Ctrl + Tab para alternar arquivos recentes

A propósito, para aqueles que preferem guias , seus comentários foram muito úteis enquanto investigamos como adicioná-los ao produto. Muito obrigado por continuar compartilhando!

@ bgashler1
Eu prefiro os atalhos de teclado. Não que eu possa ser o digitador mais rápido, mas porque acho que eles me distraem menos do que mover o mouse / trackpad.

Acho que o que muitos do pessoal do "Working Files and No Tabs EVER" estão perdendo é que eles _maneira_ em que muitos de nós usam guias. Por exemplo, quando trabalho em um aplicativo MVC (web, celular ou desktop), costumo ter guias em um ou mais painéis verticais (dos quais o VSCode também precisa) em uma ordem específica: arquivo de modelo, arquivo de visualização, arquivo de controlador . Portanto, uma configuração que abro com frequência se parece com esta:

Painel Esquerdo

Arquivo do modelo 1 (guia) | Exibir 1 arquivo (guia) | Arquivo do controlador 1 (guia)

Painel Direito

Arquivo do modelo 2 (guia) | Exibir 2 Arquivo (guia) | Arquivo do controlador 2 (guia)

Esta configuração me permite selecionar rapidamente os arquivos de modelo para ambos os componentes em que estou trabalhando para comparação ou Exibir arquivos quando estou com o chapéu UI / UX. Isso NÃO PODE ser feito de forma eficiente com arquivos de trabalho, especialmente se você também tiver outros arquivos abertos (ou seja, CSS, scripts de banco de dados, etc). Eu faço uma tonelada de UI / UX e esta é de longe uma prática comum. Se eu fosse estritamente um desenvolvedor de back-end Java ou um DBA, não, isso não seria um requisito. Mas, para a grande maioria de nós, desenvolvedores web e móveis full stack, não ter guias (e painéis verticais / horizontais com guias) é um obstáculo extremo. Embora eu esteja ganhando com o VSCode no curto prazo, tenho sérias reservas em mantê-lo por causa dessa capacidade ausente. Ninguém pode nos convencer de que as guias são inúteis e uma lista de arquivos de trabalho não é uma inovação (Adobe Brackets também tem uma lista de arquivos de trabalho e existe desde 2012).

Novamente, este não é um problema de tudo ou nada. Estamos simplesmente pedindo o mesmo recurso que existe em outros editores como uma opção, mesmo se esse recurso estiver desativado por padrão. Se o VSCode implementasse abas / painéis de janela exatamente como o Atom faz, ele resolveria 99,99% de nossa reclamação relacionada à aba. Sei que não é uma tarefa trivial de implementar, mas acho que muitos de nós ficaríamos satisfeitos em esperar um pouco mais (meses, não anos) para que esse recurso seja feito corretamente, em vez de ficar no backlog.

Apenas meus 2 centavos ...

Embora já tenha comunicado a maior parte disso a @ bgashler1 , vou escrever um pouco aqui explicando o comportamento ideal para mim.

1. Os atalhos de teclado devem fechar os arquivos de trabalho, removendo-os da lista de arquivos de trabalho e da pilha MRU (usado mais recentemente). Eu tenho os seguintes atalhos de teclado para fazer isso:

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

1. Os arquivos no editor devem ser "empilhados", para que, ao fechar um arquivo, seja mostrado o último arquivo da pilha MRU.
2. ctrl + shift + t deve restaurar a guia fechada mais recentemente. Este atalho de teclas está em conflito com workbench.action.tasks.test no vscode, mas é uma tecla de atalho padrão em ambientes com guias. Criei uma solicitação de recurso para o comando aqui https://github.com/Microsoft/vscode/issues/3989
3. ctrl + tab e ctrl + shift + tab devem apenas girar pelos arquivos na lista de "arquivos de trabalho", não pelos arquivos que foram "visualizados" (clique uma vez no explorer e navegue para fora).
4. Quero meus arquivos de trabalho dispostos na parte superior do editor. As razões para isso são:
   
   
   
   • Quero ser capaz de ver meus arquivos de trabalho visualmente, independentemente de qual barra lateral eu abri. Relacionado: https://github.com/Microsoft/vscode/issues/3360
   
   
   • Ao longo das quase 2 décadas que tenho programado, tenho olhado acima do editor para meus arquivos de trabalho. É um hábito difícil de quebrar.
   
   

@bpasero

A propósito, para aqueles que preferem guias, seus comentários foram muito úteis enquanto investigamos como adicioná-los ao produto. Muito obrigado por continuar compartilhando!

Eu uso Ctrl + Tab bastante no VSCode, mas acho que a experiência no Visual Studio é muito melhor porque, além dos arquivos, também posso navegar para outras partes da IU, uso-o para navegar até o Package Console Manager, Solution Explorer etc ...

@Tyriar Ótimos pontos!

[Aviso de filosofia!]

Por que ctrl+tab é muito mais útil do que o conceito de 'arquivos de trabalho'? Esta é a questão crucial. Pessoalmente, acho que há duas questões em jogo.

Em primeiro lugar, ctrl+tab é um atalho de teclado e os atalhos de teclado estão subconscientemente associados ao acento circunflexo - o usuário espera que ctrl+tab altere o arquivo no editor atual, onde o acento circunflexo está colocado atualmente, e isso é precisamente o que faz. Isso é diferente dos 'arquivos de trabalho' ou do navegador que não estão associados a um editor específico - eles estão horizontalmente distantes de todos, exceto um editor e associados ao editor _mais recente_ - e são normalmente usados ​​com o mouse. Mesmo se você usá-los com o teclado, você se afastou do cursor no momento em que selecionou um arquivo.

Em segundo lugar, ctrl+tab mostra _todos_ os arquivos que você viu, recentemente, em ordem cronológica inversa. 'Arquivos de trabalho' mostra apenas aqueles em que você clicou duas vezes ou fez alterações e na ordem em que se preocupou em abri-los. Os critérios e a ordem são arbitrários e não têm nada a ver com a maneira como os programadores pensam - alternando entre chamador e função, classe e consumidor.

(Opiniões. A quilometragem pode variar.)

EDIT: Meu ponto é este: entender por que um recurso funciona e outro não ajudará a consertar o recurso ou projetar um melhor. Do jeito que está, os arquivos de trabalho não.

@Tyriar : Pessoalmente, eu realmente odeio o fato de que arquivos com um único clique não aparecem em Arquivos de Trabalho. Quero TODOS os arquivos que vi em minha pilha usada recentemente - mesmo aqueles externos somente leitura. Eu os abri por um motivo. Se eu terminar com eles, logo sairão da lista. Na melhor das hipóteses, deve haver uma opção para que o clique único e o clique duplo tenham o mesmo comportamento.

Eu descobri como obter a maior parte do que estava faltando no sublime no contexto deste 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 Não tenho certeza se alguém já fez uma solicitação de recurso para desativar 'arquivos de visualização'.

@stephenmartindale , estamos procurando uma maneira de fixar "arquivos de visualização" para que permaneçam abertos - incluindo arquivos somente leitura.

Gostaríamos de manter os "arquivos de visualização", porque muitas vezes as pessoas não sabem qual arquivo estão procurando até que abram vários (o que pode resultar em um número indesejável de arquivos abertos que são irrelevantes).

Eu realmente amo o fluxo do Sublime aqui. Um único clique para pular para o arquivo,
clique duas vezes para permanecer aberto.
No sábado, 9 de abril de 2016 às 11h49 Brad Gashler [email protected]
escrevi:

@stephenmartindale https://github.com/stephenmartindale que estamos procurando
em uma forma de fixar "arquivos de visualização" para permanecerem abertos.

Gostaríamos de manter "arquivos de visualização", porque muitas vezes as pessoas não sabem
o arquivo que procuram até que abram vários (o que pode
resultar em uma quantidade indesejável de desordem de arquivos abertos).

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -207830702

@Tyriar , @ bgashler1 , @stevencl Acho que é melhor ter duas novas postagens para guias e arquivos de trabalho para coletar feedback.

Apenas minha opinião, mas eu sinto que seria muito melhor do que discutir os dois recursos aqui, este é longo o suficiente. :)

👎 Não faça isso, ou pelo menos torne-o opcional. A IU limpa e livre de guias é uma das coisas que mais gosto no código do VS.

@tobico Não precisa ser tudo ou nada ... você sabe, no que me diz respeito, quero que os arquivos de trabalho e as guias sejam opcionais e, ainda assim, essenciais para as pessoas que desejam ter essa experiência.

Gostaria de ressaltar que Ctrl + W deve fechar não apenas o editor atual, mas o arquivo de trabalho aberto correspondente. Para mim, essa é a maior desvantagem da implementação atual. Isso e o fato de que Ctrl + Tab lista todos os arquivos recentes, não apenas os dos arquivos de trabalho. Pensando bem, uma terceira advertência seria que um único clique não abre um arquivo como um arquivo de trabalho, mas a edição abre.

+1

@csholmq você pode fazer isso agora, veja os atalhos de teclado personalizados em https://github.com/Microsoft/vscode/issues/224#issuecomment -207507479

@Tyriar Isso resolve quase todas as minhas advertências. Obrigado!

Em 3 minutos, parei de usar o VS Code e voltei para o Atom. Sem guias, não vá. Desculpe, meu fluxo de trabalho foi perfurado em mim. Eu apostaria que uma enquete rápida, 4 anos atrás, teria obtido sua resposta da IU muito mais rápido. Mas deixe a arrogância da Microsoft consertar algo que não está quebrado.

@zunama , não esquecemos dos usuários que desejam guias e gerenciamento de documentos aprimorado. Agora que somos 1.0, uma de nossas maiores prioridades é lidar com essas preocupações. Coisas incríveis chegarão ao VS Code em breve.

Como desenvolvedor web, Tabs são importantes para mim. Ao contrário dos programadores de desktop (que se concentram principalmente em um único arquivo no momento), sempre alternamos entre janelas e usando o mouse ao mesmo tempo (por exemplo, cortando uma imagem do Photoshop e, em seguida, voltando ao editor imediatamente. Ou depurando em navegadores e pronto de volta para outro arquivo para fazer a correção). Com as guias, podemos navegar para o arquivo de destino rapidamente. Com atalhos, são mais 2 etapas. Com a barra lateral "arquivos de trabalho", é menos espaço na área de código principal (como colocamos Photoshop & Editor ou navegadores lado a lado). Height no editor são menos necessários. Você sempre consegue memorizar mais algumas linhas, não é?

Além disso, as guias principais são melhores para os olhos humanos. Você pode escanear o título da guia superior e o código de área principal ao mesmo tempo. Mas você não pode ler working files esquerdo com o código principal junto. Tente você mesmo. Além disso, as guias são mais largas, melhores para o movimento do mouse. (Mesmo que você não se concentre nisso, é mais previsível)

+1/0

+1

Apenas minha opinião pessoal, mas por favor, pare de fazer -1, +1 postagens ... Quero dizer, além de sugerir que você gosta ou não gosta desse recurso, algo que a reação / emoticon pode ser usado para isso não diz nada sobre sua experiência e então se você já está escrevendo um post, certifique-se de que é útil! Tenho certeza de que você tem seu próprio preservativo nas coisas e como gostaria que funcionassem! caso contrário, apenas use emoticons.

Meta:
@eyalsk Neste caso, a discussão está em andamento de forma que realmente parece redundante. Mas para questões que você deseja ganhar força, o "Adicione sua reação" é realmente o equivalente? Isso não apenas alerta o op de comentário, em vez de indicar que o problema é um tópico quente? Ou seja, ele alerta os desenvolvedores marcados para o problema ou define o problema como modificado?

@csholmq Não sei se estou entendendo corretamente, mas não estava me referindo à reação / emoticons, mas a postagens que não contêm nada além de +1, -1, não agrega valor, uma entrada mais significativa poderia foram escritos em vez de escrever uma postagem com +1, -1 ... apenas minha opinião, vou modificar e enfatizar isso em minha postagem.

@zunama Não é arrogância tentar procurar uma alternativa melhor. "Não quebrado" não é um argumento válido contra a procura de coisas novas. É praticamente um argumento para isso (talvez haja algo melhor?). Embora eu tenha percebido nesta discussão que se o VS Code deseja ser totalmente usado hoje, ele deve ter como objetivo agradar a base de usuários da 'velha mentalidade' atual e inovar mais tarde. Porque as pessoas não são muito boas em esperar e você economiza tempo tentando argumentar por que isso ou aquilo é melhor.

Voltando ao seu comentário: Se você quer fazer algo certo, não gaste 3 minutos e desista. Você enumera seu ponto de vista sobre críticas úteis e procura possíveis melhorias. Um ponto de vista de 3 minutos é inútil - e perigoso - para o seu design porque é tendencioso.

Uma enquete não funciona quando você quer inovar. Exemplo:

Qual desses estilos de nagivação seria o mais produtivo para você?

• Alguma coisa. (Experimente algo novo que possa ser melhor)
• Tabs. (Bom e velho estilo de trabalho que você aprendeu a amar).

É claro que as guias venceriam. Mas possivelmente a outra ideia poderia abrir caminhos para uma nova IU de navegação padrão.

Para ser honesto, uma das características definidoras do VS Code para mim foi a ausência de guias. Eu nem percebi (a princípio) que eles estavam faltando! Foi um ponto de vista muito interessante.

Sempre que uso as guias, elas ficam barulhentas e impossíveis de encontrar. Quando não consigo ver um determinado arquivo imediatamente na lista de guias, minha primeira reação é reabri-lo. . . e então eu descobriria que já estava aberto. É claro que a ordem das guias fica seriamente confusa no processo. Isso é o que acontece comigo no Visual Studio 2015.

No mundo em que tudo é igual, é revigorante ter uma identidade.

PS. Não estou muito impressionado com a seção de arquivos de trabalho, no entanto. Eu o uso principalmente para ver rapidamente quais arquivos precisam ser salvos.

PSS. Uma ideia - se houver abas no código vs um dia, talvez seja melhor limitar o número máximo de abas abertas, ou seja, fechar as abas mais antigas automaticamente quando novas forem abertas?

@RussBaz Não acho que limitar o número de guias seja uma boa ideia porque esse número pode mudar de usuário para usuário, mas talvez isso possa ser uma opção como esta:

tabs.autoClose = "not-visible", "off", "time", x onde x é um número

É uma ideia estranha. Se eu gosto de 16 guias e você gosta de 4, é simples. VOCÊ usa 4 guias e eu usarei 16! Por que dizer que seu jeito é melhor do que o meu, ou vice-versa. Afinal, do que se trata? Mesmo a conversa sobre as guias é meio inútil, desde que as guias sejam ativadas / desativadas em Opções / Preferências. Aqueles que não querem tabs, ÓTIMO! Quem quiser, marque a caixinha! Na verdade, não precisa ser que o seu jeito seja melhor do que o meu, ou que eu saiba melhor do que você.
+1
;)

Exemplo de caso de uso: Atualmente, alterno entre 6 guias constantemente no átomo.

Isso aumenta para cerca de 10 quando preciso trabalhar nas seções mais profundas. Eu uso todos eles! Portanto, fechar e reabrir seria uma dor. Eu poderia ter arquivos enormes em seu lugar, mas seria muito mais doloroso lidar com isso, já que aumentaria para 6 mil linhas em um arquivo se eu incluísse cada parte de um módulo em um único arquivo.

@Measuring Concordo e discordo de você. Há algumas coisas que precisam ser inovadas, mas primeiro é preciso perguntar: e quanto ao fluxo de trabalho podemos melhorar removendo as guias. Bem, para mim, cada editor que uso para o desenvolvimento tem uma interface de guia porque é comum um desenvolvedor trabalhar entre 5 e 10 arquivos por vez sem lembrar o nome exato dos arquivos nem a ordem em que são abertos. Eu tenho que perguntar, como essa nova interface o tornou melhor? Como é inovador? Primeiro pergunte como eles usam e, em seguida, pergunte como posso torná-lo melhor.

Quanto à questão dos três minutos, vou supor que o Code não é muito diferente do Sublime (minha escolha preferida) ou do Atom (o que estou testando), mas se desde o início tenho dificuldade em trabalhar com ele ou mostrar alguém com eficiência o que eles precisam fazer entre os arquivos para fazer algo funcionar, então usarei algo que funcione melhor para minhas necessidades agora e examinarei o código em algumas versões mais adiante, quando estiver pronto. Não é uma mentalidade da 'velha escola', mas sim eficiência com meu trabalho.

Pedir àqueles que preferem guias para alternar para sem guias é tão bom quanto
pedindo àqueles que preferem nenhuma guia para alternar para guias. Nós dois não queremos
mude para o outro método.

Podemos parar agora com o tipo de 'Mac vs Windows', 'Android vs IPhone'
debates sobre qual caminho é melhor: 'Tabs vs No Tabs'? Ambos são bons
e diferentes pessoas têm suas próprias preferências.

Acho que a melhor solução é adicionar guias como uma preferência que pode ser
habilitado opcionalmente. Então, ambas as multidões ficam satisfeitas.

Alguém é contra ter ambos os métodos como opções que você pode ativar ou
desligado dependendo da sua preferência?

Acho que se trata de duas opções:

1) Adicione guias como preferência. On para quem gosta e off para quem
não.

2) Não adicione guias, mesmo se eu tiver a opção de desativá-las.

Por que você votaria na opção 2 quando você tem a opção de transformá-los
fora?
Em 15 de abril de 2016, 19h32, "James McLaughlin" [email protected]
escrevi:

@Measuring https://github.com/Measuring Eu concordo e discordo de você.
Há algumas coisas que precisam ser inovadas, mas primeiro é preciso perguntar o que
sobre o fluxo de trabalho, podemos melhorar removendo as guias. Bem para mim, todo
editor único que uso para desenvolvimento tem uma interface de guia porque é
comum para um desenvolve para trabalhar entre 5-10 arquivos ao mesmo tempo sem
lembrando o nome exato dos arquivos nem a ordem em que são abertos
in. Então, eu tenho que perguntar, como essa nova interface o tornou melhor? Como é
é inovador? Primeiro pergunte, como eles usam, depois pergunte, como posso fazer
é melhor. Quanto à questão de três minutos, vou assumir que o Código é
não é muito diferente do Sublime ou do Atom e, desde o início,
luta para trabalhar com isso ou mostrar a alguém com eficiência o que eles precisam fazer
entre os arquivos para fazer algo funcionar, então usarei algo que funcione
melhor para minhas necessidades agora e olhar para o código em algumas versões no futuro
quando estiver pronto.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -210705545

@ tones411 Algumas pessoas escolherão a opção 2 só porque pensam que a adição de guias de alguma forma arruinará sua experiência com os arquivos de trabalho.

_Eu não posso enfatizar o suficiente_ mas na minha opinião a discussão não deveria ser apenas sobre adicionar abas e encerrar o dia, mas acertar o fluxo de trabalho e eu disse isso muitas vezes, ou seja, ele precisa das opções certas de customização, ele precisa sentir-se integrado e não alienado e ainda opcional! o mesmo vale para os arquivos de trabalho.

Algumas pessoas podem querer ter algo como buffers do Vim e não querer nem guias nem arquivos de trabalho.

Talvez algo como os buffers do Vim possam ser usados ​​como superfície para o VSCode, onde podemos usar comandos para gerenciar arquivos e, além disso, estabelecer as bases para cada fluxo de trabalho, sejam guias, arquivos de trabalho ou outra coisa amanhã.

Bem dito. Isso se transformou em um debate religioso. É óbvio a partir disso
longa discussão que há muitas pessoas aqui que são apaixonadas por ter
guias e acreditam que são necessárias / facilitam seu fluxo de trabalho. tem
outros que não acreditam que os tabs são necessários e que são um impedimento.

Vamos apenas concordar em discordar, tudo bem. Contanto que as guias sejam opcionais
do que aqueles que não os querem, não precisam usá-los.

Eu pessoalmente acredito que eles são úteis, mas não vou impedir ninguém
de usar arquivos de trabalho, se isso funcionar para eles. Não funciona para mim.
Na sexta-feira, 15 de abril de 2016 às 22h07, tones411 [email protected] escreveu:

Pedir àqueles que preferem guias para alternar para sem guias é tão bom quanto
pedindo àqueles que preferem nenhuma guia para alternar para guias. Nós dois não queremos
mude para o outro método.

Podemos parar agora com o tipo de 'Mac vs Windows', 'Android vs IPhone'
debates sobre qual caminho é melhor: 'Tabs vs No Tabs'? Ambos são bons
e diferentes pessoas têm suas próprias preferências.

Acho que a melhor solução é adicionar guias como uma preferência que pode ser
habilitado opcionalmente. Então, ambas as multidões ficam satisfeitas.

Alguém é contra ter ambos os métodos como opções que você pode ativar ou
desligado dependendo da sua preferência?

Acho que se trata de duas opções:

1) Adicione guias como preferência. On para quem gosta e off para quem
não.

2) Não adicione guias, mesmo se eu tiver a opção de desativá-las.

Por que você votaria na opção 2 quando você tem a opção de transformá-los
fora?
Em 15 de abril de 2016, 19h32, "James McLaughlin" [email protected]
escrevi:

@Measuring https://github.com/Measuring Eu concordo e discordo de você.
Há algumas coisas que precisam ser inovadas, mas primeiro é preciso perguntar o que
sobre o fluxo de trabalho, podemos melhorar removendo as guias. Bem para mim,
cada
editor único que uso para desenvolvimento tem uma interface de guia porque é
comum para um desenvolve para trabalhar entre 5-10 arquivos ao mesmo tempo sem
lembrando o nome exato dos arquivos nem a ordem em que são abertos
eles
in. Então, eu tenho que perguntar, como essa nova interface o tornou melhor? Quão
é
é inovador? Primeiro pergunte como eles usam, depois pergunte, como posso
faço
é melhor. Quanto à questão de três minutos, vou assumir que o Código
é
não muito diferente do Sublime ou do Atom e, se certo desde o início
Eu
luta para trabalhar com isso ou mostrar a alguém com eficiência o que eles precisam fazer
entre os arquivos para fazer algo funcionar, então usarei algo que
trabalho
melhor para minhas necessidades agora e olhar para o código em algumas versões no futuro
quando estiver pronto.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -210705545

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -210712143

+1

Eu tenho seguido este tópico no último mês ou assim desde que mudei para o Code como meu editor principal e estou continuamente incomodado com o comportamento de navegação de arquivo. Passei um tempo _tentando_ me acostumar com a seção Arquivos de Trabalho, que você admite ser mais ou menos uma reflexão tardia de qualquer maneira, e Ctrl + Tab e Ctrl + P. Estou muito feliz com o Code e ele é facilmente meu editor favorito, mas essas opções de navegação de arquivo são tão mal concebidas que é difícil entender como foram pensadas em primeiro lugar.

A maioria deles foi mencionada, mas aqui estão minhas queixas:

A lista do WF é essencialmente inútil, pois fechar uma janela do editor não fecha realmente o arquivo do WF. Na verdade, preciso fechar um arquivo _duas vezes_ e usar o mouse para fazer isso (Ctrl + W _e_ fecha o arquivo do painel WF). Se eu quisesse deixar o arquivo aberto, não teria pressionado Ctrl + W - como faz algum sentido pressionar Ctrl + W e deixar um arquivo "aberto" (visível no WF). Sim, isso pode ser reatribuído, mas estou falando sobre o comportamento padrão do WF).

Clicar em um arquivo no WF ou visualização em árvore abre um arquivo em uma janela do editor indesejado pelo menos metade das vezes. Se você tiver um editor de dois painéis com painel esquerdo ativo, "abrir ao lado" abre no painel _direito_, não em um painel _novo_, e com 3 colunas ele sempre será aberto em um painel existente. O problema aqui é que "as coisas não ficam onde as coloquei". Espero dizer ao meu editor onde quero que as coisas estejam, não que o meu editor decida onde as coisas devem ser baseadas no estado atual da IU e, em seguida, altere-as conforme o estado da IU muda em outras partes do aplicativo. Voltar a um arquivo aberto anteriormente é um PITA .

Clicar uma vez e clicar duas vezes em arquivos tem um comportamento _completamente diferente_ com _exatamente a mesma_ UI. Um único clique abre a visualização do arquivo temporariamente (para quando eu não quero carregá-lo no WF porque então serão necessários dois fechamentos para se livrar dele mais tarde), mas carregando um editor de "visualização" com outro arquivo (inevitável com a implementação atual, conforme mencionado acima) irá pular a árvore de pastas para um novo local e carregar o arquivo de "visualização" anterior significa que devo navegar novamente para a pasta na visualização em árvore. Não quero nem admitir quanto tempo passei navegando até a _ mesma pasta exata_ 6 vezes seguidas por causa desse comportamento.

Na minha opinião, clicar uma ou duas vezes em um arquivo deve me dar o _exato mesmo comportamento_, mas se você realmente quiser um único clique "visualização" que não apareça em WF / Ctrl + Tab, deve haver um _marcador de IU óbvio_ que a janela do editor ativo é uma prévia e desaparecerá quando você substituí-la.

A árvore de pastas _não_ deve pular para o local de todos os arquivos em que clico ou, quando estou depurando, pular por todas as pastas da minha biblioteca. Se eu quisesse navegar para uma pasta específica, navegaria até ela e, depois de fazer isso, espero que continue assim. Pode parecer que não é tão relevante no tópico das guias, mas de fato é.,

A única razão pela qual esses painéis do editor absolutamente ridículos, WF e comportamentos de exibição de pasta existem é _porque não há guias_. Se você adicionar guias (encaixadas em um painel específico se os painéis do editor forem divididos) e usar como padrão o comportamento normal do editor, que é _sempre abrir tudo em uma nova guia_, nenhum desses comportamentos é necessário. Deixe-me decidir como quero navegar na minha árvore e como quero empilhar minhas guias, e pare de tentar me mostrar uma "maneira melhor" (a menos que você realmente _tenha_ uma maneira melhor - depois de aproximadamente 6 meses de trabalho diário, posso dizer com absoluta certeza que a maneira atual _não_ é melhor para mim).

E já que está nisso, pelo amor de Deus, POR FAVOR, deixe-me ver os arquivos do mesmo diretório em mais de uma janela! Existe uma solução simples e elegante, que todos os outros softwares baseados em abas tiveram por anos - arraste as abas para uma nova janela - sério, pessoal, isso não é algo revolucionário. Se você deseja manter o comportamento de "uma pasta recebe apenas uma instância", faça com que os painéis flutuem em uma nova janela (que ainda é controlada / anexada à janela principal).

Vocês fizeram um trabalho incrível com este editor e vou continuar a usá-lo. Se pudermos ver:

1. Abas
2. Desativar WF
3. Pare de navegação automática na árvore de pastas
4. Ripoff abas no painel do editor flutuante (que compartilha o mesmo comportamento de outro painel do editor na interface principal)

Então eu acho que o VS Code irá longe, muito, muito. Ótimo editor, e estou disposto a tolerar as desvantagens para tirar vantagem do resto, mas muitos, muitos outros estão apenas esperando por esses poucos recursos básicos.

Eu adoraria ajudar com os testes de UI / UX ou o que quer que você faça para feedback / entrada do usuário. Deixe-me saber se posso ajudar.

Obrigado!

@anyong, obrigado por seus insights!

Para o ponto 3, não tenho certeza se você sabe, mas você também pode personalizar isso atualmente com:

"explorer.autoReveal": false

Eu vinculo workbench.files.action.showActiveFileInExplorer também para que possa obter um arquivo aleatório no explorer se precisar.

@Tyriar Não tenho certeza de qual versão você está se referindo, mas estou atualizado no Insider e essa opção ainda não faz nada.

: +1:

: +1:

@bpasero Eu li as primeiras mensagens neste fórum sobre as vantagens / desvantagens das guias. Eu também entendo a postura da equipe MSFT no seguinte: a equipe está unida sob o mesmo estilo de codificação e desenvolveu o mesmo conjunto de reflexos em relação a ctrl+tab e / ou a seção de arquivos de trabalho. Isso é uma coisa boa. Todos os membros da equipe têm um fluxo uniforme de fazer as coisas, em geral. No entanto, não fazemos parte dessa equipa, nem queremos desenvolver o mesmo conjunto de reflexos. Nossos reflexos existentes devem, idealmente, ser satisfeitos, não forçados e substituídos. O editor deve ajudar o usuário.

Teremos que nos adaptar à sua definição de UX ou parar de usar o VSCode. Alguns se adaptarão, outros não. Tem tudo a ver com o equilíbrio entre as coisas boas e ruins colocadas na mesa. Dito isso, acho que a equipe da MSFT subestima muito a importância das tabulações e superestima muito os reflexos desenvolvidos internamente.

A equipe e as pessoas responsáveis ​​realmente precisam tomar uma decisão simples: o VS Code é um experimento de interação humano-computador ou deveria ser um IDE sólido e utilizável que _dá aos desenvolvedores o que eles querem? _ Se for o primeiro, tudo bem . Pessoalmente, vou parar de me preocupar e mudar para outro lugar porque quero fazer meu trabalho, não fazer parte de um experimento de IHC, mas tenho certeza de que o experimento deles renderá dividendos no futuro. Se for o último, eles precisam implementar guias, pelo menos, porque é isso que os desenvolvedores querem, e _both_ tabs e no-tabs na melhor das hipóteses se eles quiserem perseguir os dois coelhos e tentar converter pessoas para um novo fluxo de trabalho.

@Tyriar : Tentei sua configuração autoReveal no v.1.0.0-insider e também não adiantou nada. O explorador ainda pula quando eu não quero - mais irritantemente, quando ele rola completamente para um lugar diferente quando eu uso ir para definição e isso abre outro arquivo.

Isto é o que coloquei no meu arquivo de preferências: "explorer.autoReveal": false,

@anyong @stephenmartindale você está certo, eu não sabia como essa configuração era nova. Deve estar disponível no próximo build do Insiders.

Bem dito @stephenmartindale. Sem as guias, tudo o que temos é o notepad.exe com sua própria versão do Alt-Tab (que, como observado muitas vezes acima, está corrompido). Tenho tentado usar "Arquivos de trabalho" como se fossem guias laterais, mas depois de uma semana estou quase pronto para voltar ao Sublime e seus problemas, principalmente que não há como fazer com que essa barra lateral sempre esteja lá. importa o que mais está acontecendo no aplicativo. Com o nome "Visual Studio ...", eu esperava pelo menos os recursos básicos do editor do Visual Studio (guias e a capacidade de arrastar essas guias para suas próprias janelas). Por que eles removeram essa funcionalidade é inexplicável. Talvez eu volte em alguns meses e veja se eles foram longe o suficiente para colocar uma etiqueta pré-alfa em uma construção. No momento, isso nada mais é do que um experimento de IU, a única questão é: ele já falhou ou está à beira do fracasso?

Como muitos dos 259 comentários anteriores declararam, eu gostaria muito de ver guias no VS Code, semelhantes a como elas operam no Sublime Text. Eu também mudaria de bom grado se não fosse por esse recurso ausente. Por mais estranho que possa parecer, preciso ter pelo menos quatro documentos abertos na mesma janela para poder alternar entre eles rapidamente.

Ah, e se a Microsoft não quer que o VS Code seja comparado tanto ao Sublime Text, então eles não deveriam ter feito um produto que se parecesse e se comportasse de maneira tão semelhante a ele. Manter as guias longe da GUI não é uma forma de desencorajar comparações com o Sublime Text; é uma maneira de tornar essas comparações menos favoráveis ​​para a Microsoft.

@SturmB Sublime não é o único editor que existe e eu não acho que eles fizeram o VSCode para ser mais um imitador do Sublime, assim como o Atom não é Sublime, mas todos os editores estão compartilhando recursos, o que é uma coisa boa, é assim que você obtém opções !

VSCode não está agindo como Sublime porque eles são muito diferentes, VSCode visa ser o meio termo entre um editor de código e um IDE, enquanto Sublime não faz essa afirmação, portanto, VSCode tem um público maior de pessoas, variando de pessoas que usam Vim para Visual Studio.

Adicionar guias não é o problema, as pessoas continuam dizendo que precisam adicionar guias e tenho certeza que agora eles entendem que as guias são importantes, mas o verdadeiro problema é fazer o design certo e ter certeza de que a experiência é ótima para todos, aqueles que amam guias e aqueles que os odeiam.

Agora, quando você projeta um recurso, especialmente um recurso que é fundamental para a experiência no editor, você não pode simplesmente hackear algumas coisas e colocá-las juntas e depois voltar com um anúncio de que depois de alguns dias deixará muitas pessoas desapontadas! coisas boas levam tempo! e isso não é diferente. :)

Eu gosto do conceito de arquivos de trabalho. As guias não se adaptam bem quando muitos arquivos estão abertos. Aconteça o que acontecer, mantenha o controle dos arquivos de trabalho!

@helmbold Estou genuinamente curioso - _como_ você os usa com eficiência? _Tentei_ e simplesmente não consigo descobrir como entender a bagunça que é o WF. (Além disso, em algum ponto desse problema, a equipe disse que os arquivos de trabalho eram apenas uma reflexão tardia, não um recurso planejado.)

@eyalsk :

o verdadeiro problema é fazer o design certo e garantir que a experiência seja ótima para todos, aqueles que amam as guias e aqueles que as odeiam.

Quase todo mundo aqui disse que espera que as guias sejam controladas por uma configuração exatamente por esse motivo. Dito isso, embora alguns softwares durante as primeiras iterações das guias anos atrás não fossem muito agradáveis ​​de usar, atualmente é geralmente muito bom. O código tem Sublime, Atom e não editores, como navegadores, para tornar as guias "certas"

Um recurso que gostaria de ver que não vi em nenhum software com guias e que acho que aliviaria alguns problemas com "muitas guias" é uma maneira de selecionar e arrastar várias guias para uma nova janela.

No final do dia, interfaces homem-computador para gerenciar centenas de arquivos com nomes longos de aparência semelhante sempre vão faltar - não é assim que fomos projetados para trabalhar, é apenas como somos forçados a trabalhar por causa do estado atual da engenharia de software.

@anyong com certeza! adicionar opções não é um problema, quero dizer, o problema começa quando você está se perguntando quais opções são redundantes e quais opções são realmente úteis, programas que foram projetados com guias em mente desde o início têm muito facilidade para múltiplos razões, mas principalmente porque as guias não são uma reflexão tardia, também, não é possível comparar um editor com outro ou mesmo com outro programa que tem guias, principalmente porque a história de navegação é geralmente diferente de programa para programa, programas diferentes visam focar em diferentes coisas.

Só porque Sublime / Atom ou outro programa tem guias e funciona bem ali, não significa que você pode pegar todas as coisas que funcionam lá e incorporar em seu programa, não é assim que as coisas funcionam, na verdade é assim que as coisas _podem_ falhar! lá é bem-sucedido porque todo o pacote o torna bem-sucedido.

Agora, adicionar um novo tipo de experiência do usuário ao editor exige que você reavalie toda a história de navegação, incluindo recursos existentes como "arquivos de trabalho", especialmente quando você tem consumidores existentes onde cada pessoa espera que funcione como seu editor de escolha e você pode dizer pelas postagens que muitas delas têm padrões elevados de como isso deve funcionar. :)

: +1:

@bpasero , @ bgashler1 e eu começamos a trabalhar nos designs de UX para melhorar o gerenciamento de documentos. Estamos observando todos os comentários sobre esse problema com atenção e já falamos com alguns de vocês para obter mais detalhes sobre suas próprias experiências e perspectivas únicas.

Gostaríamos agora de compartilhar nossos primeiros designs com você para obter seus comentários. Faremos um hangout do Google na quinta-feira, 21 de abril, às 16h BST. Se você quiser se juntar a nós, clique neste link: https://hangouts.google.com/call/u3wnrhjja5h47ovt7piatelkxme

Esta será nossa primeira reunião pública de design e estamos ansiosos por isso.

Tenho usado o VSCode exclusivamente (proveniente do WebStorm) e não perdi as guias. Inicialmente pensei que sim, mas comecei a gostar mais do Working Files, pois conseguia ver mais em menos espaço e sem ter que pensar em como organizar ou agrupar as coisas na tela. Agora eu uso CTRL + TAB principalmente.

Acho que as guias tradicionais deveriam ser uma _extensão_ oficial ou uma _opção_ opcional. Pessoalmente, espero algo diferente das guias para aprimorar a experiência atual.

O que eu acho que CTRL + TAB não tem é o contexto do painel do editor ativo. Se eu tiver 2 painéis de editor abertos lado a lado, gostaria de ver CTRL + TAB mostrar o histórico de arquivos filtrado para arquivos que foram abertos no painel de editor ativo em vez de todos os arquivos abertos no aplicativo como um todo ( embora isso também precise existir). Além disso, talvez clicar em algum lugar no / próximo ao nome do arquivo no topo de um painel do editor possa exibir uma lista suspensa de arquivos abertos nesse painel do editor (o mesmo que CTRL + TAB).

Mantenha o bom trabalho.

Outra sugestão. Seria bom ter uma combinação de teclas padrão melhor para visualizar a lista de Arquivos de Trabalho para quando a barra lateral estiver oculta. Eu descobri recentemente que CTRL + K CTRL + P mostra o que eu quero, mas é mais difícil de puxar do que CTRL + TAB. Como sugeri com CTRL + TAB, o pop-up Arquivos de trabalho pode se beneficiar de algum contexto baseado no painel do editor ativo. Talvez pudesse ser classificado de forma que a lista de Arquivos de Trabalho que foram abertos no painel do editor ativo ficasse acima do resto.

@RyanEwen Acho que você não era um usuário de atalho antes? Porque a plataforma Intellij Idea tem os mesmos atalhos e é capaz de colocar as guias em qualquer lugar (superior, inferior, esquerdo, direito, nenhum). Quando colocado à esquerda / direita, funciona de maneira semelhante a Arquivos de trabalho em VSCode. Seria ótimo fazer alguma experiência. Voltando ao WebStorm usando a combinação CTRL + TAB com as guias superiores para ver se você não precisa disso ou sendo forçado a aceitá-lo como a única solução alternativa. CTRL + E no WebStorm também um Arquivos Recentes com recursos de filtragem (digite para pesquisar).

Se alguém disse não ao Tabs, mencione também se você estava usando o MOUSE em seu fluxo de trabalho.

: +1:

@KayLeung Eu usei CTRL + E no WebStorm, mas como havia guias, eu me permitia acessá-las usando o mouse na maioria das vezes. Recentemente, usei um editor de guias (Koding.io) quando não tinha acesso ao VSCode e posso dizer confidencialmente que não sinto falta de configurar / organizar as guias. Parece tedioso comparado a apenas ter uma história. Sempre me pego pensando em como quero as coisas organizadas e em prever quais arquivos abrir, em vez de apenas usar o editor e alternar entre os arquivos. Isso provavelmente é parcialmente um problema "eu", mais do que um problema de guia, eu sei. Um pouco de TOC, eu acho.

Eu era um mouser quando usei o WebStorm. Usei atalhos importantes para pesquisar arquivos recentes e não abertos aqui e ali, mas passei o mouse nas guias para ver o que já estava aberto. Achei que não conseguiria usar o teclado em guias específicas de forma fácil / intuitiva, e havia aquele desejo de organizar as guias que também me fez pegar o mouse no final. A falta de guias inconscientemente (e sem dor - no meu caso) me ajudou a entrar em um fluxo de trabalho que prioriza o teclado.

Acabei de experimentar o Adobe Brackets, e sua lista de arquivos de trabalho é dividida por painel. Se você tiver um painel esquerdo e um direito, então existem 2 listas de arquivos de trabalho ("Esquerda" e "Direita") na barra lateral em vez de uma como no VSCode. Não é uma solução ruim. Não me importaria com algo assim (além da minha outra sugestão de adicionar contexto a CTRL + TAB com base no painel do editor ativo).

@RyanEwen, você fez uma observação muito boa. Eu sempre trabalho com 2 painéis para qualquer instância aberta do meu IDE. Posso ter 2 instâncias abertas em 2 telas, para 4 painéis abertos. Eu não conseguia definir o que era, mas você fez. Ter uma única lista quando há dois (ou mais?) Painéis abertos, é o problema com a implementação do Working Files que o tornou inutilizável para mim. Obrigado por ser específico aqui.

Um lembrete amigável de que nós (eu, @bpasero e @ bgashler1) estaremos compartilhando nossos designs mais recentes para guias e arquivos de trabalho mais tarde hoje às 16h, horário de verão britânico.

Junte-se a nós neste link às 16h BST: https://hangouts.google.com/call/u3wnrhjja5h47ovt7piatelkxme. Adoraríamos ouvir seus comentários.

Lembrete para quem estava planejando participar dos hangouts - está ativado agora, clique no link acima. Apenas cerca de 5 pessoas até agora.

Eu realmente gostaria de ter estado lá, mas são 11h e não posso entrar no trabalho. Presumo que alguém terá algumas coisas para compartilhar por escrito depois. : D

Breve visão geral:

1. As guias e os arquivos de trabalho (renomeados como "editores abertos") se comportam exatamente da mesma maneira, apenas depende se você deseja os visuais na parte superior (guias) ou à esquerda (editores abertos)
2. As guias são agrupadas por painel visualmente na parte superior, os editores abertos são agrupados sob os cabeçalhos "Esquerda", "Direita"
3. Clique uma vez em um arquivo para abrir uma guia de visualização (ou "abrir editor"); clique duas vezes no arquivo, edite o arquivo ou clique duas vezes na própria guia para persistir
4. O depurador abre todos os arquivos como arquivos de pré-visualização, a menos que você mantenha o arquivo que está sendo depurado usando uma das opções acima
5. As guias / editores abertos podem ser arrastados entre os painéis
6. Os painéis podem ser arrastados para mover todo o grupo de guias

Parece muito bom e, pessoalmente (do grupo muito pró-tab, se você leu meu post acima), acho que ficarei feliz em dar aos novos "Editores Abertos" uma chance justa.

Pensamentos de acompanhamento para os desenvolvedores:

1. Como o fluxo de guias / editores abertos é exatamente o mesmo, deve ser possível fazer algo assim: mostrar editores abertos quando o explorador estiver aberto e mostrar guias quando o explorador estiver fechado. Podemos aumentar o espaço horizontal para o código e manter o acesso à guia. Supondo que haja um atalho ocultar / mostrar abas, isso seria o equivalente a pressionar aquele e CTRL + B ao mesmo tempo - se funcionar, deve ser uma opção nas configurações: autoShowTabsWhenExplorerClosed ou algo assim. Se precisarmos ver mais guias, podemos clicar na divisa ou simplesmente CTRL + B para ver as guias no painel esquerdo. Não tenho certeza se isso seria "desorientador", mas desde que os editores abertos e as guias sejam sempre exatamente os mesmos e na mesma ordem, posso imaginar que funcionaria muito bem.
2. Acho que você mencionou que as guias fechadas anteriormente estavam disponíveis em uma das visualizações CTRL + Tab + algo, mas você já pensou em um atalho CTRL + SHIFT + T (desfazer o fechamento da guia) que simplesmente reabriria as guias fechadas anteriormente (na ordem em quais foram fechados)?

Só consegui entrar nos últimos 15 minutos ou mais. Foi gravado?

Fiquei desapontado (mas não surpreso) ao ver que as guias provavelmente
se tornar o padrão. Uma esperança de que você continue a preservar o peso leve
ambiente do VS Code e para explorar fluxos de trabalho progressivos.

Obrigado,

James

Na quinta-feira, 21 de abril de 2016 às 11h07, anyong [email protected] escreveu:

Lembrete para quem estava planejando participar dos hangouts - está ativado agora, então
clique no link acima. Apenas cerca de 5 pessoas até agora.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -212963079

Parece que houve algumas boas ideias. Estou ansioso para ver isso em ação.

FWIW (e se ainda for relevante), ainda acho que é melhor não ter guias na IU _por padrão_. Um cabeçalho de editor limpo e agradável que pode ser clicado para ver uma lista de arquivos se eu não tiver a barra lateral visível, ou CTRL + TAB, é o que eu realmente espero :)

Obrigado a todos que puderam comparecer e nos dar feedback hoje. Tomamos notas e seguimos continuamente o problema do GitHub aqui. Estamos ouvindo a todos.

@indiejames e @RyanEwen sim, nós tomamos notas e postaremos em breve. Ainda não decidimos com certeza o comportamento padrão. No entanto, estamos propondo uma solução que tornaria mais fácil escolher se deseja ou não usar arquivos de trabalho, guias ou ambos.

@ bgashler1 você mencionou que está procurando uma solução que permitirá que as pessoas escolham se desejam os arquivos de trabalho, guias ou ambos e nada? isso é uma opção? depende do projeto e da linguagem em que estou trabalhando, nenhum pode ser ótimo para scripts como o PowerShell. :)

Agradecemos a todos que participaram da teleconferência hoje e forneceram feedback. Agradecemos muito. @anyong já fez um ótimo trabalho resumindo o que apresentamos, mas adicionarei mais alguns detalhes abaixo e algumas capturas de tela.

Design visual

Primeiro, esta imagem indica como achamos que as guias podem ficar no código VS:

Nosso objetivo é um visual leve e que não distraia, algo que se encaixa bem com o resto do VS Code. Ainda não definimos como ficaria um tema leve.

Como você pode ver na imagem acima, as guias contêm um botão Fechar à esquerda do nome. Quando o arquivo contém alterações não salvas, mostramos um indicador sujo onde está o botão Fechar.

Passar o mouse sobre uma guia mostrará uma dica de ferramenta com o caminho completo para o arquivo na guia.

Abas de visualização

Para distinguir claramente as guias de visualização das guias abertas, colocamos o título em itálico na guia como no wireframe a seguir.

Discutimos ações para promover uma guia de visualização em uma guia totalmente aberta:

• Editando o conteúdo dentro da guia
• Clicar duas vezes em um arquivo no explorer
• Clique duas vezes na guia de visualização no grupo de guias

Transbordar

As guias são abertas à direita da guia ativa. Se não houver espaço suficiente para mostrar todas as guias em um grupo de guias, transbordamos as guias. Não truncamos o nome do arquivo dentro da guia para abrir mais espaço para mais guias.

Mostramos um chevron sempre que há um estouro. Clicar nessa divisa irá mostrar uma caixa de diálogo de abertura rápida que lista todas as guias no grupo de guias, permitindo ao usuário encontrar a guia que deseja visualizar.

Clicar em uma guia que está atualmente em estouro trará essa guia à vista.

Guias de navegação

Os seguintes comandos permitem que os usuários naveguem entre as guias:

• Ctrl-Tab mostra uma lista de todas as guias dentro do grupo de guias ativo:
  
• Ctrl Alt Tab mostra uma lista de todas as guias dentro de todos os grupos de guias
  
• A abertura rápida mostra o histórico linear de todas as guias
  

Arquivos de trabalho

Renomeamos os arquivos de trabalho para abrir editores para refletir melhor o que realmente é.

A lista de editores abertos funciona de forma idêntica às guias. Nós apenas os listamos no explorer em vez de visualizá-los como guias.

Se um arquivo for aberto em dois ou mais grupos de editores, mostramos isso na lista de editores abertos:

Qualquer editor que o usuário abrir aparece na lista de editores abertos. Então, por exemplo, o editor de diferenças aparece assim:

Cada grupo contém apenas uma guia de visualização.

A divisa no canto superior direito do grupo de editores ativo indica se há ou não uma pilha de editores.

Nesse caso, fechar um editor revelará o editor abaixo dele na pilha, em vez de fechar o editor completamente.

Fechar um editor (por exemplo, com Ctrl-W) também remove o editor da lista de editores abertos.

@stevencl

Para distinguir claramente as guias de visualização das guias abertas, colocamos o título em itálico na guia como no wireframe a seguir.

Além de itálico, pode ser ótimo se houvesse a opção de escurecer as cores das guias para torná-las _realmente_ claras.

Como escrevi antes, também gostaria de saber se há uma opção de não ter guias ou editores abertos, este pode ser um cenário útil para pessoas que fazem scripts, por exemplo, PowerShell.

@eyalsk foi mencionado na discussão que as guias e os editores abertos devem ser ativados ou desativados independentemente para um / ambos / nenhum.

@anyong obrigado! :)

Ctrl-Tab mostra uma lista de todas as guias dentro do grupo de guias ativo:

Finalmente! Tabs ou não, esse é o comportamento que eu estava esperando! Não me perca mais no meu histórico de arquivos.

Fechar um editor (por exemplo, com Ctrl-W) também remove o editor da lista de editores abertos.

Ótimo! Esperamos que seja mais intuitivo e ajude a limpar a bagunça em _Arquivos de trabalho_.

Agora, vou apenas esperar o fechamento de https://github.com/Microsoft/vscode/issues/5554 .

Hmm, não sei se isso foi considerado, mas pensei nisso agora, suporte para vários monitores! no Visual Studio, posso arrastar uma guia para um monitor diferente e criar uma nova janela / visualização da guia. Algo assim está sendo considerado? Eu imagino que seja possível fazer isso criando um novo processo VSCode e arrastando guias entre os processos por meio da comunicação entre processos, o mesmo vale para editores abertos, apenas uma ideia :)

Por favor, por favor, você pode tornar as "guias de visualização" opcionais - ou seja, ter a opção de fazer qualquer coisa ser promovida automaticamente para uma guia permanente e nunca ter coisas desaparecendo. Eu sei que você está discutindo maneiras de distinguir visualmente as guias que são temporárias, mas, francamente, isso não funcionará para pessoas como eu, que navegam entre os arquivos tão rapidamente (especialmente com Go-To-Definition et al.) Que não há tempo para inspecione visualmente a guia para adivinhar como ela pode se comportar, não me lembro como abri um arquivo ou se por acaso o editei e acho muito desconcertante quando os arquivos desaparecem aparentemente ao acaso. (Eu sei que não é aleatório, mas pode muito bem ser.)

Normalmente me enterro em abas abertas até terminar uma unidade de trabalho e, em seguida, fecho todas ao mesmo tempo que vou cometer.

Obrigado @eyalsk , sim, nós consideramos isso. Em última análise, gostaríamos de poder oferecer suporte a isso, mas o trabalho necessário para compartilhar o contexto entre vários processos é bastante significativo e, portanto, é improvável que aconteça enquanto trabalhamos no restante da UX de gerenciamento de documentos. É definitivamente algo que queremos fazer.

@stevencl Ficaria feliz se arrastando acabasse de abrir uma nova janela do vscode com aquele arquivo aberto (talvez com a mesma pasta aberta também).

Obrigado @Tyriar , continuaremos investigando isso. Se houver uma maneira de fazer funcionar bem, adoraríamos poder fazê-lo.

@stevencl Só estou preocupado porque será necessário ainda mais trabalho para adicioná-lo no futuro, então _quando_ você melhorar a infraestrutura, certifique-se de mantê-la em seus backlogs! ;)

abas por favor

Ótimo ver isso. Adorei a proposta leve e que você está encontrando uma maneira de não quebrar a experiência dos arquivos de trabalho.

Estou ansioso para experimentar. Obrigado pela atenção.

@stevencl Isso parece o melhor dos dois mundos. Parece maravilhoso! As guias aparecem como eu esperava para se encaixar no resto da interface do usuário, e parece que eu estaria obtendo exatamente o que desejo com as alterações dos Arquivos de Trabalho :)

O Open Editors oferecerá suporte a mais de 2 grupos de editores? Basta saber como você nomeá-los se for mais complicado do que Esquerda e Direita.

Sim, isso ainda seria compatível.

De: Maxime Quandallemailto: [email protected]
Enviado: 22/04/2016 23:09
Para: Microsoft / vscodemailto: [email protected]
Cc: Steven Clarkemailto: [email protected]; Mentionmailto: [email protected]
Assunto: Re: [Microsoft / vscode] Guias adequadas para arquivos abertos (# 224)

O reposicionamento dos painéis por arrastar e soltar ainda seria possível sob a proposta @stevencl ?

Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/Microsoft/vscode/issues/224#issuecomment -213605667

@stevencl Acho que o que você descreveu na discussão de alguns dias atrás é ótimo. Isso é exatamente o que todos nós estávamos esperando em relação às guias. Alguns dos outros editores que usei também implementam configurações de painéis horizontais e verticais. Isso permite que você tenha dois arquivos abertos lado a lado na parte superior e um ou dois abertos abaixo deles. Embora este não seja um recurso crítico, eu me encontro perdendo isso com frequência ao desenvolver aplicativos da web front end e aplicativos móveis. A razão é que a maior parte do que trabalho é MVC ou suas derivações, portanto, ter um modelo, visualização, controlador e algum arquivo de IU (css, Js, etc) abertos ao mesmo tempo é um grande benefício. Existem planos para incluir isso também? O Atom faz isso muito bem, que foi o último editor que usei antes do VSCode. Infelizmente, faltava muito em outras áreas em que o VSCode se destaca, daí meu uso exclusivo do VSCode. Se não estiver na versão planejada com alterações de guias e gerenciamento de documentos, isso seria um grande aprimoramento futuro.

@ jayrosen1576 a divisão horizontal é capturada nesta edição https://github.com/Microsoft/vscode/issues/1749 , certifique-se de: +1: para mostrar seu interesse.

Bom trabalho pessoal, as armações de arame parecem que funcionariam muito bem.

Ei @stevencl
Obrigado pelo excelente trabalho e aqui estão meus 2 centavos sobre o botão Fechar à esquerda.
Quando há muitos arquivos abertos e as guias estão diminuindo, o pequeno espaço para cada guia será suficiente apenas para mostrar o botão Fechar, o que tornará mais fácil fechar acidentalmente a guia em vez de selecioná-la.

O ícone indicador sujo ainda pode ficar à esquerda, pois indica apenas o status do arquivo, mas mover o botão Fechar para a direita nos permitirá reconhecer facilmente o nome do arquivo e evitará ação de fechamento acidental.

@stevencl Os mock -ups parecem ótimos e a descrição da funcionalidade parece perfeita. Minha impressão inicial, porém, é que as abas são meio grandes ... talvez maiores do que precisam ser, e parecem ocupar algum espaço. Eu entendo a relação entre apresentação elegante e funcionalidade, mas esta é uma ferramenta de desenvolvimento, o design prático supera o estilo com certeza. Tenho certeza de que você já experimentou esta calibração, então estou ansioso para experimentá-la!

@hsyn , eu entendi que as guias não encolherão e as guias de estouro estarão disponíveis no botão chevron. O botão Fechar não deve ser um problema.

As guias são abertas à direita da guia ativa. Se não houver espaço suficiente para mostrar todas as guias em um grupo de guias, transbordamos as guias. Não truncamos o nome do arquivo dentro da guia para abrir mais espaço para mais guias.

Eu não concordo com isso. Se a tela estiver dividida em 2 a 3 colunas, você estará mostrando 1 a 2 guias no máximo e transbordando as demais. Por favor, faça o que os navegadores fazem, nós os usamos todos os dias e é intuitivo e estamos acostumados. Eu o encorajo a usar padrões estabelecidos, alguns deles estão evoluindo há mais de uma década. Não vá contra a corrente.

Eu não concordo com isso. Se a tela estiver dividida em 2 a 3 colunas, você estará mostrando 1 a 2 guias no máximo e transbordando as demais. Por favor, faça o que os navegadores fazem, nós os usamos todos os dias e é intuitivo e estamos acostumados. Eu o encorajo a usar padrões estabelecidos, alguns deles estão evoluindo há mais de uma década. Não vá contra a corrente.

Alguns navegadores fazem uma combinação de redução de guias, mas depois transbordam delas além de um certo limite. Firefox faz isso; tenho certeza que o iOS Safari faz (ou fez) também.

Quando abas suficientes estão abertas e você mal consegue ver algumas letras em cada uma (embora na prática eu normalmente não tenha tantas abertas), não é particularmente mais utilizável do que o overflow.

@alexgorbatchev Eu definitivamente entendi de onde você está vindo, mas isso foi algo que eles explicaram na teleconferência outro dia - de outra perspectiva, ter uma tonelada de guias abertas e não ser capaz de ler os nomes de nenhuma delas é também não é uma boa solução. O "estouro" é uma espécie de meio-termo entre a ausência de abas e as abas "estilo Chrome" padrão que encolhem no esquecimento. Forçar as guias a pelo menos exibir os nomes dos arquivos significa que as guias visíveis serão pelo menos úteis.

Mas você me deu uma ideia para os desenvolvedores - acho que o verdadeiro problema aqui é que, embora saibamos que não podemos usar 20 guias quando todos os nomes de arquivos estão ocultos, pelo menos _sabemos_ que há 20 guias abertas e isso nos fornece um certo sentimento de "Eu sei onde meus arquivos estão se precisar deles, eles não simplesmente desapareceram." Tudo o que seria necessário para consertar isso é um indicador mostrando o _número_ de guias ocultas no momento, o indicador poderia ser apenas um pequeno círculo acima da divisa de estouro para não ocupar nenhum espaço horizontal extra.

Obrigado a todos. Não o mostramos nas maquetes, mas nossa intenção é que, quando necessário, reduzamos as guias para que apenas o nome do arquivo e o botão Fechar fiquem visíveis. Pelas razões que @anyong menciona, não achamos que queremos diminuir ao ponto em que os nomes de arquivo não sejam distinguíveis uns dos outros. Achamos que é provavelmente mais comum que várias guias em um editor de código tenham nomes semelhantes do que guias do navegador com nomes semelhantes (por exemplo, pode haver muitos nomes de arquivo com o mesmo prefixo). Assim, pensamos que reduzir as guias em um editor de código tem consequências diferentes do que em um navegador.

Pretendemos mostrar quando as guias estão no controle de estouro com a divisa dupla, mas colocar um selo com o número de guias transbordando também é uma ideia interessante. A intenção é que o número simplesmente indique que há guias de estouro ou o número real de guias de estouro é importante?

Obrigado por esclarecer @stevencl.

Um caso extremo a se ter em mente com nomes de arquivo em guias são vários arquivos com o mesmo nome abertos em pastas diferentes (index.js, README, LICENSE, package.json, etc).

Provavelmente não usarei guias, mas acho que também vale a pena apontar
que os navegadores geralmente exibem o favicon de um site na guia que
torna mais fácil identificar, mesmo quando a guia encolhe além do ponto que
é legível. Os arquivos de origem não teriam um favicon para eliminá-los,
e, como Steven aponta, os nomes dos arquivos costumam ser semelhantes no código-fonte.

Em quinta-feira, 28 de abril de 2016 às 12h16, Steven Clarke [email protected]
escrevi:

Obrigado a todos. Não o mostramos nas maquetes, mas nossa intenção é
que, quando necessário, reduziremos as guias para que apenas o nome do
arquivo e o botão Fechar estão visíveis. Pelas razões @anyong
https://github.com/anyong menciona, não achamos que queremos encolher para
o ponto em que os nomes dos arquivos não são distinguíveis uns dos outros. Nós pensamos
que é provavelmente mais comum para várias guias em um editor de código ter
nomes semelhantes aos das guias do navegador com nomes semelhantes (por exemplo,
pode haver muitos nomes de arquivo com o mesmo prefixo). Assim, pensamos que
reduzir as guias em um editor de código tem consequências diferentes do que em um
navegador.

Pretendemos mostrar quando as guias estão no controle de estouro com o duplo
chevron, mas colocar um emblema com o número de guias transbordando é um
ideia interessante também. A intenção é que o número simplesmente indique que
existem guias de estouro ou o número real de guias de estouro é importante?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -215481474

Obrigado @alexgorbatchev. Temos algumas idéias sobre como mostrar o caminho para um arquivo para poder desambiguar nesses casos. Na maquete de alta fidelidade mostrada acima, por exemplo, mostramos o caminho para o arquivo abaixo do nome do arquivo. Esta é apenas uma ideia e pode não funcionar quando o caminho é longo. Outra seria colocar o caminho na barra de status. Muitas coisas para explorar ...

@stevencl

A intenção é que o número simplesmente indique que há guias de estouro ou o número real de guias de estouro é importante?

Eu acho que mostrar o número real de guias abertas (mas ocultas) resolveria o problema. Essencialmente, as pessoas estão acostumadas a ver isso (bem, falando por mim, pelo menos):

para que eles intuitivamente tenham alguma ideia de "Tenho muitas guias abertas" versus "Tenho 2 ou 3 guias abertas"

Um emblema que mostra "20" é muito menor (sem espaço extra, essencialmente) do que mostrar 20 guias reduzidas minúsculas / inúteis, mas ainda me permite saber imediatamente que (a) as guias ocultas estão lá e (b) exatamente como muitos existem.

Eu só sou novo neste tópico, mas meu 2p como um usuário VS2015 completo:

Estou ansioso para ter abas no vscode, já que os arquivos de trabalho nunca cabem em mim (embora eu agora veja que pressionar ctrl-f4 não remove daquele conjunto como eu supus que acontecesse).

Grande fã da guia de visualização, fico feliz em vê-la chegando.

Curioso para saber por que novas guias serão abertas à direita da guia ativa. Espero que "porque navegadores da web" ou "porque sublime" seja a resposta, mas parece contra-intuitivo para mim, especialmente se as guias transbordam ocultando-se da esquerda (para a divisa à direita).

Espero ver os menus do botão direito para guias conforme VS ... 'Fechar tudo' (para o grupo), o mais importante, não me preocupei com 'Fechar tudo exceto este'. Uma caixa de salvamento do estilo VS para todos os arquivos modificados seria útil aqui.

O botão Fechar à esquerda é estranho para mim - presumo que seja alguma convenção do mac / linux - mas desde que 'clique no botão do meio' na guia feche um editor (prompt para salvar, se aplicável), então não se preocupe. Posso ver por que está à esquerda para fechar rapidamente um monte de arquivos em sucessão, mas o botão do meio é melhor para isso de qualquer maneira (embora talvez não para macs ou notebooks sem roda de rolagem?).

O seletor de arquivo Chevron deve permitir a digitação para um salto rápido para um arquivo. Não que eu planeje ter arquivos suficientes abertos para exibir a divisa (e quando o fizer, sem dúvida usarei ctrl-p), mas acontece.

Número divisa - esta é uma contagem de guias / arquivos / editores _ocultos_ neste grupo ou uma contagem de _todos_ incluindo os arquivos visíveis? Eu argumentaria apenas os itens ocultos, especialmente se você mostrar apenas a divisa (e, portanto, a contagem) quando algo ultrapassa a linha da guia.

Em uma nota ligeiramente relacionada, se eu ctrl-f4 (ou ctrl-w? Parece ser a versão não Windows de ctrl-f4, a menos que eu esteja enganado), espero que se a guia está indo embora, está fechando o editor e deve solicitar salvar / descartar e removê-lo dos arquivos ctrl-tab / ctrl-alt-tab / de trabalho ... Posso ver que há algumas alterações de atalhos de teclado que posso fazer no momento para habilitar essa funcionalidade, mas tenho dificuldade para veja porque em uma interface baseada em abas a existência de uma aba não está diretamente relacionada ao 'atual' - / abertura do arquivo / editor.

Amando o que todos vocês estão fazendo no vscode, está incrível ☺

Tentei usar o histórico de arquivos conforme sugerido e, depois de um mês, não sinto mais que preciso de guias. No VS, ter um monte de abas abertas é realmente irritante. Eu odeio quando há muitos e sou movido para a pequena lista suspensa de guias ocultas. Eu acho que eu realmente gostaria de usar o histórico de arquivos no VS agora também.

Em relação aos arquivos de trabalho, acho muito chato que tudo esteja lá. É irritante a ponto de nunca abri-lo e mantê-lo fechado. A única coisa que acho útil é ver novos arquivos que não foram salvos, ou qualquer arquivo que não foi salvo, eu acho. Rapidamente fica grande demais para eu me preocupar. Não tenho certeza de como isso pode ser corrigido. Talvez mostre apenas arquivos não salvos, mas isso teria alguns efeitos colaterais estranhos.

De qualquer forma, agora acredito em história de arquivos. :)

Acho que seria muito legal se pudéssemos adicionar a capacidade de ir e voltar na história usando shift+cmd+[ e shift+cmd+] . esses são os atalhos padrão para navegar pelas guias em outros aplicativos e ser capaz de usá-los para navegar pelo histórico.

Editar: basicamente consegui isso 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 combinações de teclas personalizadas

Ser capaz de separar uma seção de código em uma nova janela também seria útil. Não tenho certeza se isso é possível.

@JoshClose é totalmente possível, mas falta-lhes a infraestrutura para comunicação entre processos para o editor em si, portanto, para que duas instâncias se comuniquem e façam qualquer coisa, é necessário ter um protocolo para isso primeiro.

... as guias contêm um botão Fechar à esquerda do nome

Existe um motivo específico para quebrar as convenções? Ao ler o LTR, a informação mais importante é o nome do arquivo, não um botão Fechar. Movê-lo para a direita também tornaria mais fácil tornar os botões de fechamento ocultos por padrão (e exibidos ao passar o mouse). Em um estágio posterior, os usuários também podem querer ter ícones de arquivo à esquerda do nome do arquivo.

Discutimos ações para promover uma guia de visualização em uma guia totalmente aberta ...

Acho que as duas primeiras opções provavelmente seriam suficientes. Clicar duas vezes em uma guia pode ser útil para outras coisas no futuro.

Temos algumas idéias sobre como mostrar o caminho para um arquivo para poder desambiguar nesses casos.

Que tal simplesmente mostrar uma dica de ferramenta (com o caminho relativo) ao passar o mouse sobre uma guia? Isso tornaria o design menos desordenado e as abas não precisariam ser tão altas.

Mostramos um chevron sempre que há um estouro ...

O Firefox lida bem com o estouro de guias - ele tem largura máxima da guia, botões de rolagem para a esquerda / direita, menu suspenso listando todas as guias (com as guias visíveis marcadas), etc.

Seria muito bom se os botões de fechamento da guia correspondessem às convenções da plataforma: à esquerda no OS X, à direita no Windows.

Depois de usar o VSCode por algum tempo, acho que o modo _Working Files_ cresceu muito em mim!

Aqui estão algumas razões:

1. Embora pareça contra-intuitivo, fechar um arquivo que não estou usando (ctrl-w) não o retira dos Arquivos de Trabalho. Isso é muito bom porque muitas vezes me pego reabrindo arquivos recentemente fechados (em um projeto React) ao trabalhar com arquivos relacionados (ou classes infantis). Portanto, quando eu _sinto_ que devo fechar um arquivo, não mapeia um a um para o momento em que _deve_ tê-lo fechado.
2. Eu gosto do Force-Close explícito, que é oferecido pelo workbench.files.action.closeFile .
3. Eu remapeei workbench.files.action.closeFile para Ctrl + k Ctrl + w porque requer (um pouco) menos esforço do que Ctrl + kw ,
4. Posso ver o nome completo do arquivo e o caminho na barra superior do editor -> Isso é muito importante em projetos profundamente aninhados (como eu) que têm arquivos com nomes semelhantes ou iguais ( index.js ?) E somente forma de diferenciar é pelo caminho.
5. Menos ruído de abas = Zen!

Então, de certa forma, estou tentando dizer que _não remova_ o fluxo atual se você introduzir a coisa das guias.

@kumarharsh por que eles removeriam isso? se houver alguma coisa, eles provavelmente irão melhorar para você! :)

Se o indicador sujo substituir o ícone CLOSE, como poderemos fechar o arquivo se não quisermos salvar nossas alterações? O ctrl-w ainda estará disponível?

O indicador de sujeira não poderia simplesmente mudar para o botão Fechar ao pairar?
Essa é uma solução bastante comum ...

Na quarta-feira, 4 de maio de 2016 às 23h28, rojorojo [email protected] escreveu:

Se o indicador sujo substituir o ícone FECHAR, como poderemos
fechar o arquivo se não quisermos salvar nossas alterações? O ctrl-w ainda será
acessível?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -216901750

@rojorojo estamos fazendo o que @anyong também sugeriu, então você não terá nenhum problema. E sim, Ctrl + W ainda estará disponível.

Obrigado por todos os comentários.

Estamos realizando um estudo de experiência do usuário em nossos designs mais recentes no final deste mês. Se você puder reservar uma hora no dia 25 ou 26 de maio e quiser participar do estudo, inscreva-se aqui: https://calendly.com/stevencl/vs-code-docmgmt/

Infelizmente, só posso oferecer horários durante o dia (horário de verão britânico) e não posso realizar sessões à noite.

Esperamos ter alguns bits de trabalho que você possa experimentar, bem como alguns wireframes de design que ainda não mostramos.

Espere, adoro o comportamento atual da IU, haverá uma configuração?

Três semanas atrás, eu realmente queria guias. Até adiei a mudança para o VSC por um tempo, já que ele não tinha guias. Agora que passei algumas semanas usando o VSC, não quero nem guias. Nesse ponto, acho que eles entrariam no meu caminho.

Espero que, quando for construído, seja opcional para que aqueles de nós que o desejarem possam continuar no ambiente atual.

Como alguém que realmente gosta de guias verticais (elas escalam muito melhor e funcionam melhor em telas widescreen), estou me perguntando: Por que você precisa de guias e “editores abertos”. Se o último for basicamente “arquivos de trabalho” com comportamento de guia, isso é tudo que eu preciso / quero.

Quero adicionar meu voto para garantir que as guias sejam opcionais. Eu realmente não gosto das guias do editor e prefiro muito mais o painel do lado esquerdo da janela. Eu entendo adicioná-los para as pessoas que os desejam, mas, por favor, não os force. Não tê-los é uma das coisas que _ gosto_ neste editor.

Meus dois centavos: eu nunca quero fechar botões; para mim, eles são um desperdício de bens imóveis que às vezes causam frustração (clique acidentalmente). É muito mais difícil clicar acidentalmente com o botão do meio do que clicar acidentalmente 1px muito à esquerda.

Também acho que indicadores sujos são um desperdício de bens imóveis. No Sublime Text, configuro "sujo" para apenas mudar a cor da fonte da guia. No passado, eu também coloquei itálico, mas parece que você tem planos de colocar as visualizações em itálico.

O lado esquerdo da borda é muito largo

@ be5invis @MrTravisB @rauschma @marcusrugger @jpaaso

Gente, eu entendo que é uma longa discussão, então provavelmente vocês não leu tudo, mas por favor, leiam os posts por aqui . As guias serão opcionais, os desenvolvedores já estão muito, muito cientes dos pontos que você está mencionando.

Potenciais cartazes: por favor, dê uma olhada no tópico para ver se seus problemas já foram resolvidos - toda vez que você posta, centenas de pessoas recebem e-mails com seu: +1: Obrigado

@anyong No entanto, o “editor aberto” separa a lista de arquivos de trabalho existente em duas metades se você abrir duas colunas. Adoro a ideia de que existe apenas um “arquivo de trabalho” para todas as colunas do editor.
Por favor, torne isso opcional também.

@ be5invis A única diferença é que existe um separador visual. Você ainda pode arrastar os arquivos e abri-los em qualquer editor de sua preferência.

@anyong Posso esconder isso? E se eu escolher ocultar o "separador" e Ctrl-Tab em uma coluna do editor, posso alternar para um arquivo aberto na outra coluna? O que os con-tabbers querem é manter completamente o comportamento existente.

@ be5invis do comentário que fiz um

Ctrl Alt Tab mostra uma lista de todas as guias dentro de todos os grupos de guias

Então, sim, você ainda pode definir a combinação de teclas para manter o comportamento atual de Ctrl + Tab, se desejar.

@anyong Isso é bom.
Mesmo assim, posso ocultar o indicador “esquerda / direita” e fazer a lista parecer uma unidade?

Isso seria uma pergunta para @stevencl

Yay! Espero que recebamos guias em breve!

Ótimas notícias ... estamos obtendo guias ... mas não queremos perder a pasta 'Arquivos de trabalho' .Mantê-la junto com as guias?

Impressionante! Grupos de guias

@ be5invis Você está certo, pretendemos mostrar vários grupos de editores na lista de editores abertos, uma vez que você dividir o editor. Mas você não precisa fazer isso para poder trabalhar com vários arquivos. Você dividiria o editor para ver mais de um arquivo de uma vez. Se você mantiver apenas um editor visível a qualquer momento, ainda poderá ter vários arquivos abertos. Por exemplo, nesta imagem

Tenho dois arquivos abertos, mas só estou vendo um deles, pois não dividi o editor. A lista de editores aberta mostra os arquivos e posso interagir com eles lá ou por meio do controle de estouro no canto superior direito. (E observe que não há guias mostradas aqui - esta é a opção sem guias.)

A razão de termos feito isso é que existe o potencial para confusão ao gerenciar um arquivo que está aberto em dois editores na configuração de arquivos de trabalho atual. Por exemplo, na captura de tela abaixo do produto atual, o que deve acontecer quando eu fecho o arquivo app.js na lista de arquivos de trabalho. Os dois editores devem fechar ou apenas um deles. E se apenas um deles, qual?

Queremos evitar qualquer ambigüidade e incerteza, então optamos por ser mais explícitos sobre os arquivos que são abertos em cada grupo de editores.

É também por isso que renomeamos os arquivos de trabalho para editores abertos, pois achamos que isso reflete melhor o novo comportamento.

A opção Ir para a definição (F12) precisa ser aprimorada (até mesmo a definição está em outra página no projeto)) como texto sublime? Estou enfrentando esse problema desde que instalei o código do VS? Alguma ajuda nisso?

@ vinod-a-ext - abra uma nova edição descrevendo o problema que você está enfrentando ao acessar a definição.

@stevencl
Vá para o Problema de Definição no Código VS
https://github.com/Microsoft/vscode/issues/6238

@stevencl Minha opinião é que você pode ocultar os rótulos no “editor aberto” e simplesmente desenhar uma linha para representar os diferentes painéis. Depois que um painel é fechado, duas listas podem ser mescladas naturalmente.

Obrigado pela sugestão, definitivamente exploraremos diferentes tratamentos visuais para isso.

Data: Ter, 10 de maio de 2016 04:06:34 -0700
De: notificaçõ[email protected]
Para: [email protected]
CC: [email protected]; mençã[email protected]
Assunto: Re: [Microsoft / vscode] Guias adequadas para arquivos abertos (# 224)

@stevencl Minha opinião é que você pode ocultar os rótulos no “editor aberto” e simplesmente desenhar uma linha para representar os diferentes painéis. Depois que um painel é fechado, duas listas podem ser mescladas naturalmente.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub

Estou curioso, qual programa você usou para gerar os mock ups, como este

Usamos PowerPoint para essas maquetes. Nossa intenção era focar no fluxo de interação, não no design visual, para que as ferramentas do PowerPoint funcionem bem para esse nível de detalhe. Fazer coisas no PowerPoint também nos permite reunir facilmente uma sequência de telas para ter uma ideia melhor do fluxo.

Data: Ter, 10 de maio de 2016 05:03:55 -0700
De: notificaçõ[email protected]
Para: [email protected]
CC: [email protected]; mençã[email protected]
Assunto: Re: [Microsoft / vscode] Guias adequadas para arquivos abertos (# 224)

Estou curioso, qual programa você usou para gerar os mock ups, como este

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub

Acabei de chegar aqui depois de ver as notas de lançamento de abril. Tópico aberto por um longo tempo - mas eu sou +1 para o design original - ou seja, sem guias. Inicialmente isso me incomodou - mas depois passei a apreciar e entender a filosofia por trás disso ... Agora, quando penso no Atom e no spam de guias ... estremeço. Tudo isso à parte - adoro o envolvimento e os comentários e feedback atenciosos dos desenvolvedores.

Estou ansioso para experimentar isso. Uma coisa que eu adoraria ver é a combinação de vários arquivos relacionados em uma única guia (semelhante a este plugin VS )

Isso seria muito útil para se manter organizado no desenvolvimento do Angular 2, onde você normalmente tem arquivos relacionados:

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

De acordo com @lucidtech , usamos a pasta 'Arquivos de trabalho'. Acho que as guias podem ser combinadas com essa ótima opção?

Concordo com @coreh que a localização do botão Fechar guia deve corresponder às convenções da plataforma. Seria uma mudança de contexto bastante frustrante ter a localização do botão Fechar mudando quando eu passar do Visual Studio para o Visual Studio Code.

Meus dois centavos: Uma razão pela qual eu _aoro_ Code over Atom, Sublime, ou qualquer um dos outros, ahem, editores hipster é que ele não tenta se encaixar no conceito de "guia" do navegador da web. Os IDEs tradicionais como Visual Studio, IDEA e Eclipse também fazem isso. O código, por outro lado, tem uma abordagem de "frames e buffers", semelhante ao que você encontraria no Emacs (e no Vim também, eu acredito).

Inevitavelmente, em qualquer editor baseado em abas, sou obrigado a trabalhar com resultados em que os frames do meu editor recebem um spam horrível de abas cujos porta-pastas são tão pequenos que são ilegíveis. Além disso, quando eu uso o equivalente a Ctrl / ⌘-PI de um editor, acabo deformando para outro quadro como um artefato de qualquer quadro que eu estava olhando quando naveguei pela primeira vez até o arquivo. Para visualizar o mesmo arquivo em outro quadro, você deve fazer uma operação desajeitada de "divisão de guia" que também costuma ser associada à divisão de quadros em muitos desses editores. _Tabs acoplam firmemente o estado do buffer de arquivo com um determinado quadro no display._

Se você desculpar o apelo emocional, _por favor_ não transforme o VS Code em mais um editor com guias.

Acho que, de uma perspectiva de UX, em vez de implementar cegamente guias para corresponder ao comportamento do Atom ou de qualquer outro editor, seria instrutivo descobrir _por que_ as pessoas querem guias (além de uma familiaridade confortável) e ver se uma solução mais inovadora para suas necessidades são possíveis. Eu certamente concordo que o regime de espaço de trabalho atual pode continuar a evoluir: como alguém mencionou a abertura de uma janela separada no mesmo projeto (equivalente ao "ripout" baseado em guias) para melhor aproveitar os monitores de várias cabeças, venha à mente!

editar: muito triste por ter perdido a ligação há 19 dias. Eu teria entrado se soubesse disso. Descoberto apenas nas notas de lançamento de 1.1.0. :(

As guias são essenciais para mim e outra sugestão, por exemplo, de guias agrupadas do Angular 2.0 para arquivos relacionados, também é uma ótima idéia. Se o recurso for configurável, aqueles cujas preferências forem diferentes também ficarão felizes. Quando podemos tentar !!! ???

@orospakr , você pode desligar as guias no Sublime por meio de uma opção do menu. Apenas para sua informação.

@orospakr

seria instrutivo descobrir por que as pessoas querem guias (além de uma familiaridade confortável) e ver se uma solução mais inovadora para suas necessidades é possível.

Há muitos comentários sobre por que as pessoas querem guias além da familiaridade, sem mencionar que, se for familiar e as pessoas se sentirem confortáveis ​​com isso, não faz sentido ser criativo e inovar algo onde já existe algo que funciona.

Tentaram inovar com os "arquivos de trabalho" e um grupo gostou, o outro não gostou e aqui estamos hoje pedindo abas! Não acho que você queira que a mesma síndrome volte a acontecer ...

A maneira certa de fazer isso é obter a experiência que as pessoas estão procurando primeiro e, em seguida, ter recursos adicionais, inovação ou experimentos durante as compilações alfa e / ou como uma opção.

Neste caso de guias / "editores abertos" ou amanhã qualquer outra coisa, eles tornaram opcional e é assim que as pessoas precisam ter a possibilidade de optar pela experiência ou não.

Eu sei que estou um pouco atrasado para o jogo aqui, mas com relação a esta seção:

Discutimos ações para promover uma guia de visualização em uma guia totalmente aberta:

Editando o conteúdo dentro da guia
Clicar duas vezes em um arquivo no explorer
Clique duas vezes na guia de visualização no grupo de guias

Gostaria de solicitar que "Adicionando um marcador" seja incluído na lista acima.
Acho extremamente frustrante adicionar um marcador a um arquivo grande e, em seguida, clicar inadvertidamente em outro arquivo, fechando o arquivo de trabalho.

É muito improvável que eu tenha adicionado um marcador a um arquivo que pretendo fechar imediatamente.

examinei tantos comentários quanto pude, procurando por palavras-chave e não encontrei isso mencionado.

no que diz respeito às guias, em primeiro lugar, _obrigado! _ a ausência delas é uma das únicas coisas que não gosto no VS Code.

Eu adoraria ver a navegação entre as guias personalizável; por exemplo, adoro a maneira como o iTerm alterna entre as guias pressionando cmd + left e gostaria muito de fazer isso no meu editor também.

obrigado por um ótimo editor <3

As guias são essenciais para mim ... Voltar para o Sublime até ter as guias. PS Estou muito desapontado com a sua atitude; Você parece não ter nenhuma noção de UX ainda, alegando que isso foi feito para melhorar a UX. Quais são suas personas? Onde estão suas entrevistas de usuário? Prove.

@asadighi você ao menos leu os comentários antes de postar? A equipe fez extensas entrevistas e está conduzindo mais para acertar as guias. Eles são incrivelmente responsivos à comunidade e estão produzindo um ótimo editor (de graça). Boa sorte esperando o próximo lançamento do Sublime.

Seus comentários anteriores falam de seu preconceito. Minha objeção é sobre a atitude que eles tiveram desde o início. As entrevistas com os usuários devem acontecer ANTES das pessoas começarem a criticar o produto por causa dessa falha. Interessante, você pode ver a hesitação em investir para consertar essa falha em nome de uma UX melhor. Esta edição está aberta desde novembro e durante boa parte desse tempo a maioria das respostas está na linha de sabemos melhor do que você como você deve fazer seu trabalho.

@asadighi Está tudo na sua cabeça e as suas bobagens

@muellerkyle : +1: você deve criar um problema contra a extensão de marcador que você usa.

Estou ansioso por este recurso

+1!

Diariamente, eu alterno entre Eclipse, PhpStorm, Notepad ++ e VSCode. Adivinhe, CTRL+W me deixa maluco.

Estou atrasado para esta festa, mas as guias serão opcionais? Eu costumava pensar que sentia falta deles, mas agora não sinto mais. Só por curiosidade se haverá uma maneira de escondê-los. Não odeio as guias e as pessoas que querem usá-las, mas acho que prefiro alternar para exibir / ocultar. Isso é tudo para manter o ótimo trabalho. Eu amo vscode.

@jamesmenera sim, será opcional, mas o mesmo acontece com os arquivos de trabalho (editores abertos).

À parte, você divulgaria qual programa utilizou para fazer aquelas fotos maquetes?

@ciel , @stevencl escreveu que usou o PowerPoint para isso.

Pessoalmente, adoro o WireframeSketcher, mas o PowerPoint também pode funcionar. :)

Assim como @jamesmenera mencionou, eu realmente sinto falta das guias e da barra lateral, mas posso ver que muitas pessoas gostam da abordagem de Arquivos de Trabalho, então deve ser opcional.

@ kadza93 ambas as guias e arquivos de trabalho serão opcionais ... Eu me pergunto quantas vezes vou escrever isso.

É muito fácil fazer uma busca e procurar a palavra "opcional", você vai demorar menos tempo para encontrá-la do que escrever um post sobre ela!

@eyalsk Eu me pergunto por que a chama! Estou aqui para expressar minha necessidade e pelo que posso ver a necessidade de muitas guias, então, ao apoiar o que outros disseram e concordar com isso, estou fazendo algo errado? A propósito, obrigado pela dica sobre a funcionalidade de pesquisa, devo usá-la mais em tópicos longos onde quero expressar minha opinião e se alguém já expressou algo semelhante ao meu, vou simplesmente pular.

Eram apenas 3 da sua postagem ...

Seguindo este tópico, parece-me que já existem algumas decisões feitas nas guias para uma versão futura (as guias são opcionais, onde os ícones serão exibidos, combinações de teclas, etc.). Se eu não estiver errado, há uma lista dessas decisões para as quais as pessoas podem ser apontadas?

@jtlowe, não há uma maneira fácil de tornar isso óbvio, como os comentários fixados no GitHub. As pessoas fazem novos comentários e isso esconde as coisas importantes. O GitHub também faz a dobradura de comentários quando há muitos comentários, o que dificulta a localização na página.

Talvez os administradores possam colocar um banner "STATUS ATUAL: EM DESENVOLVIMENTO" no topo da página do problema (sob o corpo do problema do OP).

Este deve ser um recurso adequado no github --- algo como o texto alternativo aqui sugere: https://xkcd.com/979/

@ kadza93 Eu não

Estou aqui para expressar minha necessidade e pelo que posso ver a necessidade de muitas guias, então, ao apoiar o que outros disseram e concordar com isso, estou fazendo algo errado?

Não, você não fez nada de errado, mas também não escreveu nada de útil, o recurso emoticons / reação existe especificamente para esse motivo.

A propósito, obrigado pela dica sobre a funcionalidade de pesquisa, devo usá-la mais em tópicos longos onde quero expressar minha opinião e se alguém já expressou algo semelhante ao meu, vou simplesmente pular.

Sim ... você está fazendo muito sentido, quer dizer, expressar uma opinião sobre algo que foi confirmado! e você nem mesmo precisou pesquisar porque respondi para a mesma pessoa que você deu o polegar para cima.

Geralmente, é bom senso pesquisar por palavras comuns prováveis ​​em uma postagem longa.

Na verdade, os desenvolvedores devem apenas abrir um novo problema com perguntas frequentes e detalhes retirados de
os pontos mais comuns neste tópico e feche este problema. Pessoas
inscritos nesta edição estão recebendo dezenas de e-mails todos os dias para o
mesmos comentários de "polegar para cima" / "polegar para baixo".
Em 18 de maio de 2016 1h51, "Kumar Harsh" [email protected] escreveu:

Talvez os administradores possam colocar um banner "STATUS ATUAL: EM DESENVOLVIMENTO" em
no topo da página de problema (sob o corpo de emissão do OP)?

Este deve ser um recurso adequado no github --- algo como o alt-text
aqui sugere: https://xkcd.com/979/

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -219798727

@anyong sim, eu concordo completamente! não há nada para discutir e uma vez que tabs e open editors estiverem ativos, eles devem criar duas edições separadas para feedback sobre esses recursos.

@eyalsk ainda estamos experimentando como lidar com atualizações sobre problemas criados pela comunidade. Existem várias maneiras de fazer isso, mas todas são ruins sem um recurso de comentário fixado no GitHub. O problema do terminal integrado https://github.com/Microsoft/vscode/issues/143#issuecomment -213581854 tem estado bem até agora com uma grande atualização no meio do tópico, acho que tem a ver com menos necessidade de discussão então não foi enterrado.

@Tyriar bem, você pode referenciar posts, então você não pode simplesmente criar novos posts e fazer uma referência aos antigos fechando-os? Eu acho que é assim que os caras que trabalham no Roslyn fazem e então eles têm um post que resume todos os recursos para os próximos lançamentos, mas mesmo assim eu concordo com você, os comentários fixados podem ser extremamente úteis.

Temos trabalhado na implementação dos designs para guias e grupos de editores neste marco e continuaremos a fazê-lo no próximo marco

Obrigado a todos que participaram do estudo UX nos últimos dias. Recebemos ótimos comentários seus que nos ajudaram a fazer algumas melhorias na experiência:

• Redesenhe o ícone de estouro
• Fornece uma configuração para escolher se os arquivos de abertura rápida são fixados ou visualizados
• Adicione um comando para transformar um arquivo visualizado em um arquivo fixado

Desculpe, se eu perdi isso, mas como ativamos as guias? Eles estão disponíveis na versão mais recente do insider, como eu tenho, mas nenhum vestígio de guias lá. Eu também ainda vejo 'arquivos de trabalho' no explorer, embora pareça que ele deve ser substituído por 'Editores abertos', conforme declarado em # 6536.

@lllopo eles ainda não estão disponíveis. As pilhas / editores abertos foram mesclados para a v1.3.0 e estarão disponíveis nos Insiders na próxima semana quando as compilações diárias estiverem disponíveis.

+1

+1

👎

O que está acontecendo aqui, por que você resiste em nos dar a opção de usar guias? 😕
Muitas pessoas gostam de guias, incluindo eu, dê-nos a maldita opção PERÍODO!

@aminroosta Sério ... você não consegue ler? Você é cego?

O engraçado é que você está perguntando o que está acontecendo aqui ... e então prossegue e presume que eles realmente recusam ou, em suas próprias palavras, "resistem" quando, na verdade, eles confirmaram que as guias estão chegando e trabalhando para implementá-lo!

Algumas pessoas neste mundo! inacreditável!

@eyalsk
Passei 25 minutos lendo os primeiros 20 a 30 comentários.
Cansei e deixei um comentário que agora parece um erro da minha parte.

Me desculpe por isso.

Não podemos culpar o R&D da microsoft por tentar inovar. Sistema de guias tem contras.

O design da interface do usuário é como todas as formas de design. 90% fazendo o que o usuário espera, 10% fazendo coisas novas, tentando criar um novo sistema revolucionário e amigável.

todo sistema amigável visto como deve ter no novo editor de texto hoje já foi experimentado e controverso antes.

@aminroosta Vou te dar uma dica, quando você estiver lendo uma postagem longa, leia a postagem original e, para obter as atualizações mais recentes, gaste um minuto ou mais rolando de baixo para cima.

Essa é uma boa sugestão, pois é um feed MUITO longo.

No domingo, 5 de junho de 2016 às 10:42 AM Eyal Solnik [email protected]
escrevi:

@aminroosta https://github.com/aminroosta Vou te dar uma dica, quando
você está lendo uma longa postagem, leia a postagem original e, em seguida, para obter o
as atualizações mais recentes passam um minuto ou mais rolando de baixo para cima.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -223826495,
ou silenciar o tópico
https://github.com/notifications/unsubscribe/AAInRHy6TDR-opr-8ZKmW-lRUgZDOP21ks5qIwqIgaJpZM4GljE8
.

Pessoalmente, gosto da abordagem Ctrl + Tab. Pela minha experiência pessoal, as guias podem ficar bagunçadas rapidamente se você tiver mais de 10 delas abertas ao mesmo tempo. Eu diria para remover os "arquivos de trabalho" ou pelo menos deixar como uma opção. Eu não uso e isso me deixa confuso. Vou usar Ctrl + Tab a partir daqui, obrigado!

@adred Ambos Working files (agora chamados de Open editors ) e Tabs serão opcionais, tanto quanto eu posso dizer.

@bpasero

Você pode _por favor_ bloquear este tópico e abrir um novo com as partes importantes deste aqui copiadas? Ainda há comentários que chegam diariamente de pessoas que não conseguem ler tudo (deve dizer que é muito longo), e fazendo a mesma pergunta repetidamente, e quando o lançamento das guias chegar ao público, iremos veja ainda mais spam neste tópico.

Quero me manter atualizado sobre os acontecimentos relacionados à guia, e este tópico é atualmente o lugar para fazer isso, mas é muito chato receber e-mails com spam várias vezes ao dia para os mesmos comentários repetidamente.

Desculpas pelo tom e obrigado.

Existem tantos + 1s que é um pouco demais.

Na segunda-feira, 6 de junho de 2016 às 2h16 -0700, "anyong" [email protected] escreveu:

@bpasero

Você pode _por favor_ bloquear este tópico e abrir um novo com as partes importantes deste aqui copiadas? Ainda há comentários que chegam diariamente de pessoas que não conseguem ler tudo (deve dizer que é muito longo), e fazendo a mesma pergunta repetidamente, e quando o lançamento das guias chegar ao público, iremos veja ainda mais spam neste tópico.

Quero me manter atualizado sobre os acontecimentos relacionados à guia, e este tópico é atualmente o lugar para fazer isso, mas é muito chato receber e-mails com spam várias vezes ao dia para os mesmos comentários repetidamente.

Desculpas pelo tom e obrigado.

Você está recebendo isso porque comentou.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/Microsoft/vscode/issues/224#issuecomment -223906131

Apenas um comentário sobre o texto de atualização @ https://code.visualstudio.com/updates#_workbench

O texto não estava claro para mim e realmente pensei que as pilhas atualizadas já estavam aqui (e que as guias viriam depois). Depois de atualizar, não vi as pilhas atualizadas e tive que reler o texto algumas vezes.

Para mim, diz que as guias levarão mais iterações (portanto, nenhuma guia _esta_ atualização), mas que em maio você fez um grande progresso em como gerenciar pilhas de editores (portanto, apesar de não haver guias, pilhas atualizadas _estam_ nesta atualização?) e que há mais trabalho a ser feito para o branch de lançamento de junho (para melhorar ainda mais as pilhas?).

Então, para qualquer um que possa ter ficado confuso como eu ... parece que as pilhas atualizadas não estão realmente nesta atualização. Acho que é apenas uma prévia das guias e pilhas que virão.

Eu concordo com @RyanEwen. Eu realmente aprecio o desenvolvimento aberto e a quantidade de comunicação, mas esses anúncios sendo parte das "Notas de Lançamento" oficiais são realmente confusos.

Talvez isso possa ser dividido em notas de lançamento reais e 'no que estamos trabalhando agora' ou algo assim.

Vincular este problema ao Roadmap não foi uma boa ideia porque se você lê-lo desde a primeira vez, não terá uma ideia clara do status atual (mais do que o Milestone). Ainda há trabalho a ser feito, mas o estado atual é ok: +1:

Sim, eles devem resumir os problemas e, em seguida, ter links para esses resumos para que as pessoas conheçam o plano atual depois de discutido.

Vincular a discussões é ruim porque eles tendem a ser longos e as pessoas não conseguem ter a ideia sem ler quase tudo, mas não sei, talvez não seja possível para eles fazerem de outra forma.

Quando comecei a ler as notas de lançamento do 1.2, a primeira coisa que procurei foi _o recurso de guia_. Eu aprecio que eles colocaram o status atual lá. Mas também fiquei confuso. A princípio pensei que tinha pousado, depois percebi que não, mas muito progresso foi feito. Nesse caso, realmente parece que esse item deveria estar na parte inferior das notas de lançamento com um link para a discussão ou um marco (ambos provam o progresso do recurso) junto com uma pequena nota dizendo algo como _ "Confira o progresso na implementação do Tabs "_.

Independentemente dessa coisa menor. Ótimo trabalho no lançamento. VS Code é um ótimo produto com incrível ciclo de desenvolvimento.

O VSCode acabou de ser atualizado para 1.3.0-insider. Os arquivos recentes parecem ter sumido. Existe uma maneira de fazer isso agora?

Obrigado pelo feedback sobre as notas de lançamento e desculpe a confusão. Fiz modificações no documento para deixar claro que o trabalho não está no Estável, mas que você pode visualizar o trabalho da guia no Lançamento do

Ter uma seção no final, onde falamos sobre o trabalho realizado, mas não na construção estável, é uma boa ideia e faremos isso no próximo mês se tivermos mais trabalho que se encaixe nesse balde.

@JoshClose , abra um novo problema para isso, pois irei travar esse problema em breve em favor de problemas individuais em vez deste único tópico. THX.

Em primeiro lugar, gostaria de agradecer a todos mais uma vez por suas opiniões, gostos e desgostos sobre as guias. O feedback que vimos neste tópico (positivo e negativo) realmente mostra como as pessoas estão entusiasmadas com o futuro do VS Code.

Acho que todos podem concordar que esgotamos a utilidade desse problema e, como resultado, vou bloquear a conversa. Deixaremos esse problema em aberto até o lançamento com uma opção para guias / sem guias, o que planejamos fazer até o final da iteração de junho de 2016 .

Embora a equipe do VS Code _pode_ publicar atualizações nesta edição, você deve esperar que criaremos novas edições para designs de guias ou discussões adicionais. Iremos marcar os problemas com o rótulo tabs para facilitar a consulta. Você também pode abrir uma nova guia de problemas específicos e aguardamos seus comentários sobre os problemas específicos, pois juntos construímos as melhores experiências possíveis.

Obrigado novamente, agora vá e instale o Insiders Release !

https://github.com/Microsoft/vscode/issues/6605 documenta todos os identificadores de comando adicionados ou alterados para usar com atalhos de teclado. Como o modelo de pilhas é uma grande mudança na IU do VS Code, decidimos revisitar todos os comandos relacionados a editores ou grupos.

Temos o prazer de anunciar que agora você pode habilitar guias em nossas compilações noturnas (http://code.visualstudio.com/Download#insiders). A configuração relacionada é workbench.editor.showTabs . Consulte nossas notas de lançamento para obter mais detalhes sobre o conceito de pilhas de editores, editores de visualização e guias.

Ainda há algum trabalho planejado nesta área até o final do mês (e provavelmente depois), então temos o prazer de receber feedback de especialistas. Sinta-se à vontade para abrir os problemas à medida que os encontra ao usar as guias.

Obrigado!

Como @bpasero mencionou, agora você pode habilitar guias em nossas compilações noturnas.

Se você já tentou isso e pode dispor de 30 minutos para compartilhar seus comentários, inscreva-se para um bate-papo aqui: https://calendly.com/stevencl/vs-code-tabs/

Infelizmente, só posso oferecer horários durante o dia (estou em Edimburgo, Escócia), segunda e terça-feira da próxima semana.

tl; dr; habilitar guias nos insiders do VS Code workbench.editor.showTabs: true

Estamos fechando para o marco de junho durante esta semana com nosso teste de final de jogo usual. As guias estão no plano de teste (https://github.com/Microsoft/vscode/issues/7854) e terão alguma cobertura durante a semana. Ainda esperamos fazer correções nas guias para junho e, possivelmente, refinamentos com base no feedback postado em junho. A maior parte do trabalho está concluída, portanto, encerrarei esta edição.

A partir da descrição deste item de trabalho, @TurkeyMan pede guias e uma maneira de mover uma guia para fora do ambiente de trabalho para abrir em uma nova janela. Extraí o último em https://github.com/Microsoft/vscode/issues/8171, pois não está relacionado ao trabalho de guias que fizemos.

Continue a registrar os problemas nas guias conforme você os vê enquanto os testa. Obrigado por ajudar a testar a construção interna!