Vscode: Adicionar suporte para abrir várias pastas de projeto na mesma janela

Criado em 21 nov. 2015  ·  380Comentários  ·  Fonte: microsoft/vscode

No momento, não parece possível abrir várias pastas de projetos na mesma janela, o que é um pouco restritivo. Se você está trabalhando em projetos modulares modernos, é obrigatório ser produtivo.

feature-request workbench-multiroot

Comentários muito úteis

Sublime, Atom, Webstorm - eles também são editores de código "leves" (exceto, talvez, Webstorm) e permitem abrir várias pastas raiz de diferentes locais. Esses editores são provavelmente 99% do que os desenvolvedores da web usam.
O código pode competir com eles com um suporte muito melhor em Typescript (e será muito popular, considere que o Angular 2 está chegando), mas somente se ele der aos desenvolvedores o que eles usam agora como uma funcionalidade básica.

Todos 380 comentários

concordo, mas talvez seja uma solução de otimização para memória

+1

Não tenho certeza se entendi a pergunta; é um editor de código leve, não um IDE ... por que você precisaria abrir várias pastas de "projeto" que não são hierárquicas (onde você poderia definir o caminho de trabalho para um pai mútuo)?

Se você estiver trabalhando em módulos que estão armazenados de forma diferente no disco que de alguma forma estão interagindo entre si nesse grau, então eles estão fortemente acoplados para começar ... seus projetos são irmãos? Em caso afirmativo, basta abrir a pasta pai, ou pasta pai / pai ... onde quer que esteja a raiz da sua "solução".

Bem, se você tiver vários módulos (que estão todos em seu próprio repositório git) que são independentes uns dos outros, mas você tem um repositório que usa essas dependências, faz sentido ser capaz de abrir essas pastas independentes e fazer alterações que ser refletido para que você possa testá-lo localmente. Esse ainda seria um editor de código leve, mas mais útil, imho!

O principal problema em definir o projeto como pai é que a integração git desaparece, mas existem outros casos de uso válidos além de ambos ter um pai mútuo.

@stoffeastrom soa como um caso de uso para submódulos; Não tenho certeza de como seu projeto faria referência a outro, a menos que você estivesse usando um alias com algum mecanismo, como vinculação de npm, etc. Esse problema é o que os gerenciadores de pacotes pretendem resolver. Se os módulos estiverem fortemente acoplados, eles realmente não são módulos isolados. Você não seria capaz de fazer alterações de forma confiável para dar suporte a um projeto sem se preocupar com as consequências para outros consumidores no futuro. Mesmo com submódulos, eles são somente leitura por padrão exatamente por esse motivo.

De qualquer forma, o que @Tyriar acabou de mencionar é uma das razões pelas quais estou desconfiado de ter esse tipo de interface de caminho multi-funcional em uma única instância / janela: você tem que lidar com integrações (como git), extensões, refatoração, depuração, etc, etc, etc. todos de alguma forma isolada. Por exemplo:

Se eu usar a integração git para fazer o commit, estou comprometendo o projeto A ou o projeto B?
Se eu refatorar um nome de classe no TypeScript, ele deve refatorar no projeto A ou no projeto B, ou em ambos? E se o mesmo nome de classe existir em ambos os projetos com significados diferentes? E se um estiver referenciando o outro vagamente?

Estes são apenas alguns exemplos de como algo aparentemente simples pode se tornar muito complicado, muito rapidamente. Acho que seria muito mais confuso e, francamente, menos útil do que alt-tab / cmd + tab entre algumas instâncias separadas do VSCode, cada uma gerenciando felizmente seu próprio caminho de trabalho isolado sem todo o esforço extra e problemas de casos extremos.

Não estou dizendo que não poderia ser resolvido, mas não entendo muito bem por que alternar entre várias janelas e / ou instâncias é um problema. Talvez eu esteja faltando alguma coisa ...

Sublime, Atom, Webstorm - eles também são editores de código "leves" (exceto, talvez, Webstorm) e permitem abrir várias pastas raiz de diferentes locais. Esses editores são provavelmente 99% do que os desenvolvedores da web usam.
O código pode competir com eles com um suporte muito melhor em Typescript (e será muito popular, considere que o Angular 2 está chegando), mas somente se ele der aos desenvolvedores o que eles usam agora como uma funcionalidade básica.

+1

+1

Como um desenvolvedor Go, acho esse recurso extremamente útil no Sublime ou no IntelliJ Idea. Por exemplo, meu pequeno projeto importa código da biblioteca central Go ou pode importar alguma biblioteca de terceiros. Portanto, preciso ser capaz de navegar rapidamente até eles e ler esse código.

+1. As soluções de microsserviço repo multi-git são muito dolorosas no VS Code agora, pensando em encontrar outro IDE compatível com Typescript.

Definitivamente, precisamos de algum tipo de 'solução'. Sou um desenvolvedor nativo, e isso quase sempre envolve a construção de um conjunto de libs / dll e, em seguida, referindo-se a eles a partir de algum projeto de aplicativo host.
Uma vez que temos vários projetos, também precisamos de um 'projeto de inicialização' para quando pressionamos 'executar'.

Eu também gostaria de suporte para projetos e múltiplas raízes git. O código que uso com frequência é encontrado em vários repositórios git e ser incapaz de alternar entre eles sem fechar meu espaço de trabalho atual e abrir outro apenas para virar e fechar aquele para abrir o anterior é exaustivo. Se eu adicionar a pasta pai onde todos os meus repositórios estão armazenados, ganho a capacidade de navegar e pesquisar entre meus arquivos, mas perco a integração com o git. É uma verdadeira chatice.

A linha entre "editor de texto" e "IDE" está muito borrada e eu realmente não me importo como o código do VS é rotulado. O que me preocupa é o que uma ferramenta pode fazer e como é fácil de usar. Acho que adicionar suporte ao projeto aliviaria muito o atrito para pessoas como eu.

Também gostaria de ver a integração do git funcionar quando seu espaço de trabalho contiver vários repositórios, mas só quero ter certeza de que pessoas como @ Loren-Johnson percebam que podem ter várias janelas de código vs abertas simultaneamente.

Isto é em resposta a: "incapaz de alternar entre eles sem fechar meu espaço de trabalho atual"

Quer dizer que # 2686 é uma duplicata disso?

Desculpe, eu li errado a descrição e reabri este aqui.

+1

Há algum progresso nesta questão, ou pelo menos alguma declaração se isso será implementado? Existem algumas decisões de baixo nível no código que evitam raízes múltiplas em um projeto?

Esse é praticamente o único motivo pelo qual não estou mudando de ST3 para VSCode.

+1

+1

+1

+1 isso seria muito útil. A sugestão de usar submódulos git é muito inconveniente. Adoraria ter esse recurso.

Uma abordagem leve inicial seria algo semelhante ao que a extensão git-project-manager faz. A abordagem poderia ser basicamente mudar o contexto / raiz para o que o git vê como mudanças, mas sem alterar o contexto / raiz para o que o navegador de arquivos vê. Esta extensão funciona perfeitamente, só precisa de uma integração mais forte para tornar a troca mais rápida.

+1

+1 - Comecei a usar submódulos git, mas parece mais um hack do que uma solução real.

+1

+1

Estou usando a extensão git-project-manager para alternar entre as pastas, mas adoraria ter a opção de abrir várias pastas ao mesmo tempo.
+1

Só quero dizer que o proprietário da extensão do Project Manager também está aguardando este problema.

Com relação a alguns dos comentários (acima), só quero dizer que somos todos diferentes, todos temos nossas maneiras particulares de executar nosso trabalho em nossos projetos particulares. Esse fato torna a UX mais importante do que já é.

Todos nós sabíamos que "Abrir pasta ..." era apenas o primeiro passo para inevitavelmente ter o gerenciamento de projetos em vscode com coisas como "Abrir projeto ..." e assim por diante. Assim como todos os outros editores por aí, especialmente SublimeText (de onde eu vim).

Para mim, esse problema é um aprimoramento da UX do produto. E todos nós sabemos que UX é rei.

Quase sinto que esse tipo de coisa deveria ser a lei e, portanto, a tag "solicitação de recurso" deveria ser "lembrete de recurso".

Este problema deve ter prioridade sobre qualquer outro problema no vscode. Não apenas porque UX é rei, mas porque eu não estou tendo nenhum outro problema com vscode agora além deste ... tecnicamente.

Originalmente, estava navegando para pedir que a Microsoft assumisse essas extensões semelhantes a projetos e as integrasse diretamente ao VSCode, e melhorasse sua UX, por exemplo, adicionando "Projetos ..." ao menu.

Obrigado,
+1

+1

Meu caso de uso para este recurso é descrito aqui: # 9515. (Foi encerrado como uma duplicata deste problema).

Espero que esse recurso aconteça!

+1

@ poidl, @mastrauckas , @mdedgjonaj , @alanleite , @Xcorpio , @mibanez , @josebalius & @brusbilis :
Há algum tempo, o GitHub introduziu o adorável recurso "Adicione sua reação" (veja o smiley em cada canto superior direito de um comentário ou do problema em si?).
Eles servem ao propósito de informar a equipe VSCode sobre seu interesse, mas evitam comentários +1 sem sentido. Também evita que outras pessoas que assinaram uma determinada edição ou MR recebam uma notificação e, portanto, economiza um tempo valioso. Outro bônus é que os problemas / MRs podem ser classificados por most reaction que torna instantaneamente visível para a equipe do VSCode o que é relevante para os usuários. Além disso, existe até um Uservoice para VSCode .

Este comentário em si é meta e, portanto, também sem sentido. Sinto muito, mas pensei que era necessário para fins educacionais. Cada resposta direta a este comentário (= mais meta) resultará no bloqueio do usuário.
Vamos nos exercitar apenas reagindo a esse comentário usando o recurso reaction !

À resposta de @poidl : Então não responda nada!

Eu não vejo aquele smiley. Pelo menos no celular. Bloqueio feliz!

@poidl sim, o recurso de reações não está disponível no site móvel do GitHub, infelizmente (junto com muitos outros recursos). Você pode acessá-lo no celular clicando no botão "Versão para desktop" na parte inferior do site.

O conselho de @dj-hedgehog é local, porém, as reações do GitHub nos permitem avaliar o interesse da comunidade em algo de forma mais eficaz do que a contagem de comentários. Além disso, estamos planejando descontinuar o User Voice para que os problemas e reações do GitHub sejam nossa fonte de informações para solicitações de recursos.

+1

+1

Minha solução para este problema: criar um link simbólico para a raiz do meu projeto.
Então, se eu tenho:
project/modules/gitmodule

Eu entro na minha pasta gitmodule e faço:
ln -s ../../../project .project

Agora posso abrir minha pasta gitmodule no vscode e ainda ter acesso à pasta do projeto pai.
Eu uso um ponto no nome do arquivo para que ele seja classificado no topo da minha lista no explorer.
Obviamente, eu preferiria não ter que fazer isso, mas achei que pode ser útil para alguns de vocês.

Quase esqueci: não se esqueça de adicionar o link simbólico ao seu .gitignore

+1

Este é um recurso muito importante para um editor de texto moderno. Resolva esse "problema", por favor.
Por um tempo, eu tive que copiar e colar todos os diretórios que são usados ​​para minha pasta de trabalho atual e isso em Sublime Text é tão Trivial.

Projeto> Adicionar pasta ao projeto no texto sublime incrementa um novo caminho para a estrutura Json.

Veja abaixo:
{ "folders": [ { "path": "~/cpp" }, { "path": "~/python" } ] }

Ao trabalhar com o chef, por exemplo, é comum ver uma estrutura de pastas como:

└── cookbooks
    ├── cookbook1
    ├── cookbook2
    ├── cookbook3
    └── cookbook4

Onde os livros de receitas (livro de receitas1 por exemplo) sob a pasta raiz (livros de receitas) são os repositórios git independentes. Isso é muito comum. Agora você tem que trabalhar no livro de receitas4, mas inclui o livro de receitas2 e o livro de receitas3. Freqüentemente, você precisará abrir todos os 3, simplesmente para se referir ao código ou para editar ou refatorar o código em todos os 3.

As 2 opções normais (não hacks de link simbólico) apresentam problemas que nenhum desenvolvedor deseja:

  1. Como mencionado acima muitas vezes, você teria que abrir várias janelas agora (não é bom)
  2. Se você abrir livros de receitas como root para ver todos os 3, perderá a integração do git, pois a pasta de livros de receitas não é um repositório obtido (também não é bom)

+1, usuário do Eclipse IDE aqui, que possui controle total do 'espaço de trabalho'.

O Visual Studio Code não é um IDE. É um editor de plataforma cruzada leve, como Atom ou Sublime. Eclipse, Xcode, Visual Studio, et. todos são gigantes em comparação.

Desculpe, não tenho certeza se você está argumentando contra ou a favor deste recurso ... Atom, Sublime, VIM, Emacs permitem que você abra várias pastas em uma instância. Peso leve ou não é um bom recurso, IntelliJ IDEA - um IDE - por exemplo, não permite que você abra vários projetos ainda.

@dmccaffery os recursos solicitados aqui não são apenas recursos do IDE. Os recursos solicitados são comuns a todos os _editores_ que você disse que o Visual Studio Code é _like_.

Atom, Sublime e outros editores leves podem abrir várias pastas.

Eu, pessoalmente, não me importo se esse recurso vai parar no produto ou não - eu entendo por que algumas pessoas querem, mas eu diria que torna tudo um pouco mais complicado. Por exemplo: ao pesquisar usando uma expressão regex - qual área de trabalho estou pesquisando? 1? todos?

E se eu tiver uma pasta contendo um projeto nodejs onde minha largura de tabulação é normalmente 2 espaços, e uma pasta é um projeto dotnet onde minha largura de tabulação é de 4 espaços? O código precisa estar ciente das configurações do espaço de trabalho para cada pasta e manter o contexto por toda parte.

Esses são apenas alguns exemplos de onde vários espaços de trabalho em uma única instância podem ser difíceis. Tudo o que estou dizendo é que esse recurso está muito mais envolvido do que apenas ter vários caminhos aparecendo no explorer.

@dmccaffery não é mais complicado do que sublime e átomo. Tudo isso deve ser configurável, mesmo as larguras de guia por espaço de trabalho. A pesquisa em átomo e sublime pode ser apenas no arquivo atual, neste espaço de trabalho, etc ... a escolha é sua.

Aqui está um fato, goste ou não e não tem nada a ver com o que você ou eu queremos. Se outro software semelhante com preços semelhantes (grátis neste caso) tiver melhores ou mais recursos, e o desenvolvedor negligenciar esse fato, este software será deixado para trás.

Eu, pelo menos, não gostaria de ver isso acontecer com este editor. Acho que este editor tem um potencial muito bom e pode permanecer relevante por algum tempo _se_ os desenvolvedores ouvirem os desejos / necessidades de sua base de usuários.

Novamente; não estou argumentando a favor ou contra - apenas tenha em mente que este é um editor muito novo com muito mais contexto fora da caixa do que seus concorrentes - espere um pouco.

Mesmo em seu exemplo com chef e integração git - como você mantém o contexto em relação a qual repo está se comprometendo? A UI atual precisaria se adaptar à troca de contexto constante - o mesmo para OmniSharp, que está usando um servidor e roslyn para fornecer destaque de sintaxe, etc. para projetos CoreCLR. As implicações são de longo alcance e precisam ser muito bem pensadas.

Nenhum argumento sobre a ideia de que os recursos precisam ser bem planejados e pensados. Isso é um dado, eu acho. Acho que todos os usuários ficariam felizes se a resposta aqui fosse "está no roteiro" ou "estamos trabalhando para esse fim". Tudo o que estou dizendo é que um "não" provavelmente mataria alguns usuários durante a noite.

Quanto à troca de contexto e repositórios git no chef, sim, concordou ... tudo isso é verdade e tudo já realizado em outros editores de código aberto. Você sabe o que há de bom sobre o código aberto ... é aberto! Olhe para o código, tenha ideias, diabos até use alguns deles (certifique-se de incluir o licenciamento conforme necessário). Essa é uma das melhores coisas sobre foss (software livre e aberto), colaboração e compartilhamento de conhecimento. Uma vez que este editor já está usando o código atom ... Eu acho que isso também seria um dado adquirido.

Encontrei isso mencionado em https://github.com/Microsoft/vscode/wiki/Roadmap

VS Code é um produto jovem e ainda faltam recursos e experiências que você está pedindo e que queremos oferecer.
....
....

  • Várias pastas dentro de um único espaço de trabalho

Acho que ninguém disse que esse recurso é simples (como todos nós somos desenvolvedores, podemos saber o que precisa ser mudado) e eu, convidados, comentam sobre este tíquete, só quero mostrar o quão importante ele é, como deve ser a prioridade, e como comparar este recurso com alguns irmãos VS Code (Atom, Sublime, por exemplo).

Mas porque isso já está no roteiro (qualquer um pode confirmar que a página wiki ainda está correta), devemos discutir sobre como implementar isso em vez de apenas dizer como precisamos e quão importante é (como novamente, acho que a equipe central do VS Code já saber como precisamos dele e a importância desse recurso).

Não estou familiarizado com o código-fonte do VS Code, alguém pode me dizer se desejo implementar esse recurso, onde devo olhar primeiro? Na primeira etapa, desejo apenas abrir várias pastas e mostrá-las na barra esquerda.

@nvcnvn não é tão trivial quanto pode parecer implementar isso, pois muitos vscode assume que apenas uma única pasta pode ser aberta. Como tal, ele precisará passar pela UX e provavelmente tocar muitas partes da base de código, potencialmente com impactos na API de extensão também.

Lembro-me de quando o Atom foi lançado, com a mesma limitação de _pasta única_. As reclamações também foram as mesmas, principalmente as comparações com o Sublime. Então, quando o suporte a _múltiplas pastas_ foi lançado, alguns pacotes (extensões) foram quebrados, devido à nova API. Outros não quebraram, mas também não o apoiaram. Demorou algum tempo até que se tornasse _estável_ em todo o ecossistema.

Como @Tyriar disse, haverá algum impacto de UX e API de extensão, e provavelmente será um lançamento _Insider_ ocupado para desenvolvedores de núcleo e extensões, para adotar a nova API.

Então, o que exatamente está sendo discutido aqui?
Quer dizer, tudo que vejo é "não faça melhorias porque isso pode quebrar as coisas" ...

Dica:
TODAS AS MELHORIAS NO CÓDIGO PODEM QUEBRAR ALGUMA COISA!

Esse é o ponto de depuração, refatoração, pré-lançamentos (alfa, beta, rc, etc ...)
Vamos, sério? Nunca conheci um programador sério que tivesse medo de melhorar o código porque isso poderia quebrar alguma coisa. Seja cauteloso sim, não tenha pressa e esteja seguro sim, mas nunca diga "não, pode quebrar as coisas" lol

@ddreggors Não estou discutindo, estou simplesmente declarando algumas informações sobre o problema. Eu disse o que disse para que @nvcnvn não tente construir um PR para isso, pois isso precisará ser feito pela equipe devido à lista de stakeholders.

Como @nvcnvn apontou, esse problema está no roteiro, o que significa que a equipe o examinará em breve. Somos uma equipe relativamente pequena, com muito material para cobrir, então algumas coisas precisam ser adiadas.

@Tyriar Compreendido, só continuo vendo esses comentários de várias pessoas que parecem sugerir que é melhor não adicionar esse recurso por um motivo ou outro. O pior deles foi devido ao fato de que o código não é um IDE, quando outros compararam claramente outros editores não IDEs. Isso me fez querer chegar à raiz do medo dessa mudança para superá-la, se possível.

Eu posso entender a preocupação de que o PR não esteja completo, porém pode ser um bom começo ... mesclar essa mudança em um branch e usá-lo como base. Use isso para ver as quebras e consertá-las.

@ddreggors , seria um esforço inútil para qualquer um tocar nisso antes que fosse discutido em uma de nossas reuniões de experiência do usuário

É justo, você saberia melhor nesse sentido. É bom saber que isso está sendo discutido. :-)

Obrigado pelos esforços e pelo que parece ser o início de um editor muito bom.

Também parece ser um esforço inútil sugerir este tópico para suas reuniões de experiência do usuário :–)

Mudei temporariamente de volta para o Atom, pois ele se tornou muito mais estável na versão 1.9. Costumava travar quando qualquer arquivo grande era aberto e esse foi o principal motivo para começar a verificar o VSCode em algum ponto. Estou ansioso para ver vários projetos em uma janela - parece que não tenho nada a fazer além de seguir este tópico até então.

Por que o pessoal da Microsoft não está se concentrando nisso?

+1

+1

Eu realmente amo o VS Code. Tornou-se meu editor principal, mas a dificuldade de trabalhar em mais de 2 projetos ao mesmo tempo está se tornando confusa. Há um golpe duplo nesses dois problemas em aberto: este e a configuração das informações da barra de título .

Qualquer um desses recursos resolveria o problema (embora o ideal seja eu preferir os dois!). Não me importo de colocar tudo com que trabalho em uma única pasta e abri-la - mas a integração com git não funciona e não há uma maneira trivial de pesquisar apenas em um projeto ou organizar os resultados por projeto.

Não me importo de abrir cada projeto em uma janela física diferente do VS Code e deixar meu sistema operacional gerenciar as instâncias - mas como a barra de título mostra o nome do arquivo aberto primeiro, em vez de alguma pasta raiz / identificador de projeto, é impossível mudar para outro projeto aberto específico sem abrir e olhar para cada instância ativa. Torna algo que deveria ser fácil em um aborrecimento constante.

Por favor - existe alguma maneira de adicionar um desses dois recursos pode se tornar uma prioridade? Eu tentei tudo que pude pensar para contornar isso, eu até passei uma hora procurando alguma alternativa na barra de tarefas do Windows que me deixasse escolher janelas em uma lista que poderia mostrar mais do texto na barra de título, mas não consigo encontrar qualquer coisa.

Se alguém tiver alguma sugestão sobre como gerenciar vários projetos abertos do VS Code com eficácia, eu adoraria ouvi-la.

Uma coisa importante que funciona bem no Atom é que os plug-ins, como o eslint, ainda devem funcionar no nível do projeto. Portanto, se o Projeto A tem suas próprias regras eslint, o Projeto B não deve ser afetado por essas regras e vice-versa. Mal posso esperar para ter essa UX no Code. Este é definitivamente um dos, senão o maior obstáculo à adoção no momento.

Isso é a única coisa que me impede de adotá-lo.

Eu sei que você pode ter muitos outros problemas para corrigir e outros recursos para implementar, mas, pelo menos, algum suporte básico para começar seria incrível.

Obrigado pelo trabalho árduo no VSCode!

+1

Até que esse recurso seja implementado (se for o caso), posso sugerir que você simplesmente adicione a capacidade de configurar a barra de título para mostrar o nome do projeto antes do nome do arquivo. Desta forma, pelo menos será possível distinguir entre as diferentes janelas vscode que estão abertas para os diferentes projetos. Veja # 1723 .

Isso é um obstáculo para mim também. Vejo que alguns desenvolvedores estão se perguntando por que você tem vários repositórios git ao mesmo tempo. Isso acontece com quase todas as linguagens que usam módulos de terceiros. Basta olhar para php - composer, js - bower, node - npm, golang etc. É muito comum iniciar um projeto que usa alguns de seus módulos e você deseja editar e enviar as alterações no escopo do projeto.

Existe pelo menos suporte para reconhecer .vscode/settings.json em diretórios aninhados. Ao trabalhar em um único projeto, pode haver subárvores com diferentes conjuntos de configurações e que vêm de diferentes repositórios (git). por exemplo

root/
    server/
        .vscode/
            settings.json // <== affects all files in the server/ directory
        code/
            tsconfig.json
            foo.ts
    client/
        .vscode/
            settings.json // <== affects all files in the client/ directory
        code/
            tsconfig.json
            foo.ts
    .vscode/
        settings.json // for any file not in server/ or client/

Eu esperaria que o vscode pegasse (e talvez mesclasse) as configurações do diretório pai mais próximo, como muitos arquivos de configuração ( .eslint , .gitignore , .editorconfig , tsconfig.json , 'package.json` ....).

Portanto, quando eu abro /root , qualquer arquivo em root/server/ deve ser tratado como se eu fosse abrir root/server/ diretamente. A solução mais simples seria parar de pesquisar configurações nos diretórios pai quando um arquivo .vscode/settings.json for encontrado.

Isso é realmente necessário.

+1. Dealbreaker para mim.

Isso é realmente necessário. +1

há uma solução alternativa para aninhar pastas em um espaço de trabalho vscode. apenas para criar um link de símbolo para a pasta da área de trabalho, como este mklink /d link target

Eu concordo - acho que este pedido é um requisito definitivo.
Você nem sempre tem um projeto em uma única pasta - você pode ter pastas auxiliares e irmãs, e não ter esse recurso é um grande obstáculo para o meu agora - é por isso que tenho que usar o sublime.
Por favor, adicione!

No lado esquerdo, você mostra a pasta em que está como um projeto. Isso poderia funcionar se você tivesse onde ver cada área de pasta (projeto) aberta. Você pode expandi-lo e recolhê-lo como faz agora (mas para várias áreas de pasta).

Um editor incrível se eu pudesse alternar entre dois projetos. Um verdadeiro Dealbreaker.

Olá a todos, recomendo a extensão Git Project Manager se você alternar muito entre os projetos enquanto isso. Ele escaneia um diretório em busca de diretórios que contenham uma pasta .git e permite alternar rapidamente entre eles. Estou usando-o há algumas semanas e certamente torna isso mais fácil.

Quando eu mudo de projeto, eu devo:

  1. ctrl + alt + p
  2. Digite início do projeto, por exemplo. "vsc" para vscode
  3. entrar

Ou se eu quiser abrir o projeto em outra janela, pressiono ctrl + shift + n antes. Você pode configurar a extensão para sempre abrir em uma nova janela se essa for a sua opção.

untitled-1

Esta é uma captura de tela de como você pode facilmente ter vários projetos.

@ soljohnston777 o problema é que a integração git (ou qualquer outro tipo de configuração de código VS) não é suportada no nível de pasta.

o problema é que a integração git (ou qualquer outro tipo de configuração de código do VS) não é compatível com o nível de pasta.

Huh realmente? O VSCode repetiu os erros que o eclipse cometeu quando se trata do conceito de espaço de trabalho? Isso seria surpreendente, sabendo que alguns membros da equipe VSCode fizeram parte da equipe principal do eclipse ....

O VSCode repetiu os erros cometidos pelo eclipse no que diz respeito ao conceito de espaço de trabalho

Não posso falar sobre a filosofia dos arquitetos aqui, mas esse fato (que a configuração é por instância e não por pasta) é a razão para este problema e discussão.

Você pode usar janelas VScode separadas para projetos. Por que não implementá-lo assim dentro do VSCode? (Janela separada por botão de projeto lateral - apenas faça referência a ele dentro). Isso evitaria o incômodo de codificá-lo dentro do programa, mas os projetos aparecem dentro dele e o tornam fácil de integrar e desenvolver.

Git pode ser colocado independentemente para cada área de pasta para vários projetos ... Eu acho o git confuso com VSCode, então eu tendo a apenas fazer a linha de comando de qualquer maneira (o que parece que você deve ser capaz de fazer isso no VSCode).

Ter uma pasta pai abrigando subpastas que são repositórios git independentes é realmente útil quando todas pertencem ao mesmo projeto. Gostaria de ver isso disponível, pelo menos com um sinalizador de configuração opcional nas configurações.

Também gosto de expressar meu grande interesse em ter suporte git para vários repositórios git.

+1. Este é um recurso principal que impede minha adoção do VSCode como meu editor principal.

+1

+1 - especialmente para pessoas que trabalham com bases de código de microsserviços / muitos repo, essa é a chave. (Chave: não abrir todos de uma vez, mas alternar entre eles e fazer com que o editor lembre quais arquivos foram abertos e em quais áreas de trabalho.)

+1
Nossa configuração é algo como código principal no repositório GIT, algum código regional em outro repositório e código específico do projeto em outro repositório, portanto, quando você trabalha em um projeto, precisa codificar de todos os três (ou mais) repositórios. Não ser capaz de ter um "projeto" com suas próprias configurações específicas e a capacidade de adicionar várias pastas de várias fontes é o rei de um bloqueador.

@danechitoaie como você sabe que uma mudança feita em seu

Não argumentando contra alguma implementação de espaços de trabalho, mas um sistema de projeto completo adiciona uma boa quantidade de complexidade.

Concordo, é e eles deveriam / poderiam fazer muitas coisas muito melhor, mas ... está fora do controle de nossos "usuários mortais" ou capacidade de tomar decisões ...

Entendido. Eu adoro quando esse tipo de coisa acontece.

b2r1ifriyaa-bnh
Que tal agora?

Para mim, um botão simples como esse não é suficiente. Se precisarmos apenas disso, abra 2 instâncias (ctrl shift N) e use a tecla de atalho do sistema operacional para alternar entre janelas / áreas de trabalho é praticamente o mesmo.
Adoro ter algo que facilite a comparação de arquivos, estrutura de projetos, algo que me ajude a fazer pequenas alterações rapidamente e construir e manter todas as diferenças na mesma tela, capaz de reverter as alterações para todos os projetos que estou trabalhando.

+1

+1

Tipo de solução alternativa para o macOS Sierra.

Uma guia por projeto dentro de uma janela, definindo Prefer tabs when opening documents para Always nas configurações do dock. Mas isso afetará o comportamento de outros aplicativos também.

+1

Isso está se tornando um assassino para mim. Eu amo o programa, mas cara, eu não gosto de ter só uma janela ...

Honestamente, tive que parar de usar o Code porque, por mais que eu gostasse, tornou-se muito complicado alternar as janelas.

Se isso for corrigido no futuro, vou tentar novamente, até então, isso é um empecilho para mim e para todas as pessoas que testei.

+1

+1

Por favor, prefira: +1: reações ao comentário do problema original, pois isso nos ajuda com a priorização e não envia notificações a todos que estão ouvindo o problema para atualizações.

+1

Atualmente, estou usando o Sublime e testando o Code. Parece e é bom, mas a integração do Git em um único projeto é um obstáculo. Tenho um projeto Hadoop / Oozie e, portanto, um repositório de código e outro de notas de trabalho. No Sublime, tenho os dois abertos na mesma janela e posso enviar o repositório Git apropriado para cada

então, será bom adicionar

+1 sim, crítico no mundo do microsserviço, é comum ter 3..4 repositórios abertos ao mesmo tempo

Lembrete semanal: pare de postar comentários com +1. Em vez disso, dê um polegar para o problema inicial, que é realmente contado.

Eu sei que você teve boas intenções. Portanto, sinta-se à vontade para excluir seu comentário +1 para que não ocupe espaço neste importante registro histórico também!

@jamietre eu tentei ... muito:

screen shot 2016-11-18 at 6 28 16 am

Talvez outra alternativa seja bloquear esse problema, mas manter em aberto até ser resolvido? Dessa forma, sabemos a importância do problema (diria que já temos + 1s suficientes para isso), mas não podemos aumentar a desordem / redundância (por exemplo, não são permitidos mais comentários).

Embora esse seja um recurso raramente usado, eu acho, só me deparei com o bloqueio em um projeto / repositório público no Github.

O bloqueio pode ser desbloqueado quando for considerado necessário, se for o caso.

@daluu é assim que funciona o repositório / aspnet / anúncio; cada problema é imediatamente bloqueado. Dito isso, o GitHub deve fazer algo na IU para, pelo menos, levar as pessoas a alternativas além de apenas "+1", pois as reações agora existem. 👍

É muito útil colocar a função multi-janela como um todo, ao olhar para os documentos de mais de dois projetos,

abordagem interessante para o problema. Fui um programador VB / .net por muitos anos, adorei as linguagens e as ferramentas, mas estive afastado por alguns anos em Hadoop / Spark / Scala / Intellij / Sublime-land. Eu ainda ouço DotNetRocks, gosto de me manter atualizado com o que está acontecendo, e fiquei interessado em ouvir sobre este aplicativo Code. No lado positivo, é um editor muito bom, com alguns recursos bonitos do Git, mas isso é totalmente irrelevante, infelizmente. Porque ele não lida com Git para vários projetos no mesmo espaço de trabalho, como o Sublime faz com muita elegância, então eu simplesmente não posso usá-lo

Isso acontece. O que mais me surpreende é a reação aqui, primeiro afirmar que esse não é um recurso necessário e, em seguida, a maior parte da discussão agora parece girar em torno de "como podemos impedir as pessoas de postar +1"

Vou lhe contar como você faz isso - você resolve um problema básico que foi levantado pela primeira vez há um ano inteiro! É chamado de "ouvir feedback". Só porque você não é afetado pessoalmente por um problema, isso não significa que ele não exista. Se você não quer que um determinado grupo de usuários use o aplicativo, tudo bem, mas não nos dê um mecanismo de feedback, então questione nosso problema e depois fique irritado conosco por continuarmos perguntando por ele.

Estou de volta a usar Sublime

O problema "+ 1" pode ser corrigido com o seguinte código: if (post_message == "+1") {add_smiley_reaction (); delete_post_message (); }

Caro GitHub, Estou disponível para aluguel.

sim, isso nunca vai ser consertado, não é? Muito mais fácil zombar e ignorar os comentários "+1" do que realmente resolver o problema central, o software sendo comercializado para uma seção específica de desenvolvedores que não faz o que precisa para ser produtivo ...

apenas leia este "Cada resposta direta a este comentário (= mais meta) resultará no bloqueio do usuário." - agora, é assim que você gerencia o feedback! Coloque os dedos nos ouvidos e diga "não estou ouvindo!"

Querido senhor

@ kryps1 então as pessoas adicionarão "+ 1" ou "++ 1" ou "1+" ou "bump" ou "Sim, por favor. +1". O que quer que você faça, as pessoas encontrarão uma maneira de contornar isso. Não é tão fácil quanto você pensa.

Pare com o debate inútil de +1 , por favor ... Concentre-se no que é necessário aqui, que são vários projetos no explorador.

Para o problema git , ele apenas precisa ser dividido da mesma forma que o explorador (isto é, por cwd).

Não vamos começar uma guerra de insultos sobre as coisas +1. Seria definitivamente bom se esse problema tivesse prioridade.

Mas gostaria de mencionar à comunidade, suponho que PRs e contribuições são bem-vindos ;-) alguém pode fazer um patch / consertar o código se os desenvolvedores principais não o fizerem. Eu tive alguns dos meus projetos aprimorados (com garfos) porque o usuário / desenvolvedor prefere fazer isso sozinho do que esperar que eu faça melhorias que eles gostariam de sugerir para mim. Portanto, qualquer pessoa que se irrite com esse problema e seja capaz / habilidosa o suficiente, por favor, corrija (e envie um PR)? ri muito

E de volta ao tópico +1, levantar problemas e adicionar sua opinião é bom, mas o +1 é uma maneira esfarrapada de fazer isso se houver outros métodos disponíveis, como o recurso de polegar para cima. Considere uma postagem do Facebook ou a postagem original do Google+, e os usuários / leitores adicionam um comentário +1 em vez de clicar em Curtir (ou uma das novas reações do Facebook), ou +1 para o Google+. Com o tempo, isso é um longo tópico de comentários de + 1s coxos, em que, como leitor, posso rolar para ver comentários interessantes, mas acabo vendo um monte de + 1s. Isso é o que estava acontecendo aqui, eu prefiro não ver / ler esses + 1s, seja eu um desenvolvedor de projeto ou apenas um usuário (ou pesquisando este projeto para uso potencial).

Em uma nota relacionada, aqui está um uso bobo (mas com boa intenção) de um problema de GH, graças a Deus, as pessoas nem todas marcaram isso com +1: https://github.com/sinatra/sinatra/issues/920

Presumo que RP e contribuições são bem-vindos

Na verdade não. Veja este comentário de agosto: https://github.com/Microsoft/vscode/issues/396#issuecomment -241806158

Aparentemente, esse problema está no roteiro, pelo menos desde então, mas não houve nenhum progresso nele. Seria bom ouvir uma atualização de status da equipe VSCode.

Para mim, e isso é tentar colocar o assunto de volta nos trilhos, são necessárias várias pastas de projeto.

No Atom, ele suporta GIT, e a única maneira de usá-lo é observar quais arquivos têm alterações. Eu tenho um servidor Rackspace que não permite o SSH, então os carregamentos manuais vou. No entanto, posso ter várias pastas de projeto na barra lateral, o que torna muito mais fácil fazer referência ao código que usei em um projeto anterior. Ou mude para outro projeto se eu precisar de um descanso.

Com o VSCode, o problema que está me impedindo de trocar, e cara, eu quero trocar, é a falta de várias pastas de projeto na barra lateral.

Quer dizer, eu poderia simplesmente abrir a pasta raiz para resolver temporariamente, mas se eu só precisar das pastas 3/20 e não quiser ver os arquivos soltos, então esta deve ser uma implementação fácil, certo?

Atualização: A grande atualização do workbench em breve é ​​a saída ativa (# 101), enquanto trabalhamos na saída ativa, discutimos ativamente esse problema para garantir que o design leve várias pastas em consideração.

Este problema é atualmente o número 2 em termos de: +1: reações de todos os problemas (número 1 por uma bancada de trabalho muito marcada), como tal, é muito provável que seja o próximo grande trabalho para a bancada após a saída quente.


Ligado: +1: comentários; eles só servem para irritar as mais de 80 pessoas que se inscreveram na edição. Votar na questão com uma reação, entretanto, é uma das coisas mais poderosas que você pode fazer para influenciar o projeto.

Também tenha em mente que somos uma equipe relativamente pequena e que a limpeza da base de código e o desempenho do vscode são muito importantes, então as coisas levam tempo para serem feitas da maneira certa. Particularmente para algo como isso, que é uma mudança fundamental em como o vscode foi construído até o momento, há bastante trabalho neste problema.

+1

Na verdade, esse seria um recurso útil.

Troquei do Atom e gostei muito, mas trabalho em dois aplicativos de IU e outros 2 SDKs, mas a incapacidade de alternar entre esses projetos (ou pastas) rapidamente é uma falta importante, acho que devo voltar ao Atom até este foi resolvido

Estou realmente ansioso por este recurso ~~~

Sou um desenvolvedor de golang usando vscode, espero que tenha um implemento, obrigado!

Estou tentando mudar de Sublime para VScode. E logo descobri que o VScode não suporta várias pastas em um conceito de "projeto", é realmente um problema que me bloqueia de fazê-lo.

Realmente amo os outros recursos deste editor "leve". Enquanto isso, acredito que o suporte a várias pastas em um "projeto" não tornaria o VScode "excessivo" ou "semelhante a IDE". Isso apenas tornaria mais conveniente para os desenvolvedores que usam outros editores para tornar a transição muito menos dolorosa.

Espero ter essa melhoria. Obrigado!

Além disso, se a equipe puder adicionar a capacidade de salvar configurações baseadas em projeto que substitui as configurações padrão, isso será ótimo. O caso de uso é se eu posso ter diferentes intérpretes para diferentes projetos. Da mesma forma, ter tamanhos de guia diferentes, etc. também ajudará. Por favor, deixe-me saber se isso já pode ser alcançado de alguma forma.

Como desenvolvedores, estamos sempre trabalhando em vários projetos e temos nossos próprios projetos paralelos. Personalizar as configurações do projeto (configurações do espaço de trabalho para vscode) toda vez que eu mudar de projeto é uma grande dor.

@bajubullet Você deve tentar https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig Não tenho certeza se cobre tudo que você precisa, mas é um começo.

@danechitoaie obrigado pela resposta. EditorConfig não ajuda, eu posso especificar propriedades por tipo de arquivo, mas se eu puder salvá-las como configurações de projeto, será mais fácil e eu não gosto de ter .editorconfig para todos os projetos. Além disso, no caso de extensões como a extensão python, que nos permite fornecer o interpretador a ser usado, isso não ajudará porque python.pythonPath não é compatível com editorconfig. Por favor, deixe-me saber se estou faltando alguma coisa aqui. Quaisquer sugestões são muito bem vindas.

Eu concordo, também estou ansioso por algum tipo de configurações específicas do projeto e ser capaz de abrir várias pastas "raiz". São as únicas coisas que sinto falta do Sublime.

Isso será implementado em breve!

Portanto, não há necessidade de continuar adicionando a este post. Se você tiver outros problemas, crie um novo tópico. Obrigado!

Este é um tópico bastante longo e eu li talvez um terço dele, mas quero apenas expressar meu apoio. Acabei de instalar o VS Code com https://github.com/JuliaEditorSupport/julia-vscode como um possível substituto para o Atom / Juno. É lindo! 😍

Ao desenvolver o código de Julia, no entanto, acho que é muito importante poder abrir vários pacotes em pastas diferentes. Em princípio, eu poderia abrir a pasta acima, mas isso exporia centenas de pacotes de Julia que instalei. Eu também poderia alterar meu LOAD_PATH, mas prefiro uma solução VS Code.

Espero sinceramente poder abrir várias pastas. Obrigado pelo esforço 👍

Olá a todos, como vocês devem ter notado, estamos explorando a implementação desse problema durante esta iteração.

De https://github.com/Microsoft/vscode/issues/17608

Investigue em espaços de trabalho com várias raízes nos diferentes componentes @team

Desejo bater um papo com 3 a 5 de vocês sobre seus casos de uso enquanto pensamos nos detalhes de implementação. Inscreva-se para um intervalo de 15 minutos na próxima terça-feira, se puder. Eu adoraria bater um papo.

alternar entre minha api e ui está me deixando louco ... :-(

@ehartford alguma razão em particular porque eles não compartilham um pai comum?

Sim. A integração do Git não funciona se eu apenas abrir o diretório pai.

@ehartford bom motivo: sorria:

@waderyan você está procurando apenas casos de uso de _ usuários finais_ ou _develadores de extensão_ também?

Como um _usuário final_, o suporte a várias pastas foi útil na maioria das vezes para _fins de pesquisa_. Eu costumava criar Projetos adicionando diferentes pastas de diferentes APIs, apenas para tornar as pesquisas mais fáceis (unificadas). Eu diria que não sinto tanta falta hoje e não me incomoda ter várias janelas VSCode hoje, especialmente depois que o comando Switch Window foi adicionado: +1:

Como _desenvolvedor de extensões_, tenho algumas extensões baseadas no _ Contexto do projeto_, como context.workspaceState , activationEvents/workspaceContains . E também Project Manager , que por sinal já comecei a refatorar os internos para suportar multi folder. Eu adoraria saber como isso afetará as extensões

obrigado

Para adicionar ao que eu disse acima (https://github.com/Microsoft/vscode/issues/396#issuecomment-270326917), eu realmente uso submódulos Git, então quando estou trabalhando em meus próprios pacotes (privados), faz todo o sentido agrupá-los, mas como Julia ainda é bastante jovem (relativamente falando), muitas vezes preciso trabalhar em outros pacotes junto com o meu. Não sinto uma razão convincente para adicionar esses outros pacotes como submódulos (embora pudesse).

Geralmente, para o desenvolvimento de pacotes Julia, estou constantemente pulando entre os pacotes, então ter várias pastas de projeto seria ótimo: +1:

PS: MS, preste mais atenção a Julia;)

Caso de uso mais simples: microsserviços

Haha. Sim @saada 👍 Na verdade, foram os microsserviços que nos trouxeram ao VS Code. Estamos usando o Azure Service Fabric e meu parceiro criou os primeiros microsserviços em .NET e Rust. Estou trabalhando nos microsserviços Julia. Meu parceiro é um cara do VS e gostava do VS Code for Rust. Ele sugeriu que eu tentasse o VS Code para Julia. Obrigado!

@saada definitivamente no radar. Você pode responder a essas perguntas para me ajudar a ser mais preciso nos requisitos?

  1. Seus microsserviços compartilham uma pasta pai? Por que ou por que não?
  2. Cada microsserviço é separado em seu próprio repositório git? Por que ou por que não?
  1. Cada microsserviço é separado em seu próprio repositório git? Por que ou por que não?

@waderyan um possível motivo é que algumas plataformas PaaS populares, como Heroku, exigem que cada aplicativo (microsserviço) esteja em um repositório Git separado. Deploy-via-git-push se tornou uma estratégia popular.

@waderyan Eu me inscrevi para um slot amanhã e estou ansioso por isso - mas ao longo das linhas de casos de uso como este, o nosso é semelhante.

Somos uma grande organização, temos um registro npm privado e publicamos nossos próprios módulos que são compartilhados dentro da organização. Temos um aplicativo de reação com uma base de código de cliente que é um grande aplicativo que consome alguns módulos comuns (como bibliotecas de utilitários, componentes compartilhados) e uma base de código de servidor que é composta por vários módulos também (aplicativo de servidor expresso, componentes de serviço de dados de back-end consumidos pelo camada de serviço e os serviços reais expostos ao cliente). O desenvolvimento ativo envolve no mínimo dois (o cliente e a camada de serviços), mas a solução de problemas pode facilmente envolver meia dúzia de módulos.

Mesmo ao usar módulos npm públicos, ocasionalmente é útil ter seu código-fonte vinculado diretamente e aberto em uma instância separada do VS Code para solucionar um problema difícil, ou mesmo um bug em um módulo de terceiros, mas principalmente é nosso próprio código.

Cada um é repositório git separado. Não há problema em mantê-los em meu sistema de arquivos em uma única pasta raiz (eu faria de qualquer maneira). Mas preciso ter uma instância separada do VS Code aberta para cada um, e alternar é difícil porque você só pode ver o nome do arquivo - não o nome do próprio aplicativo. Não há como descobrir facilmente qual aplicativo / módulo / projeto está aberto em qual janela. O nome do arquivo em si fornece muito poucas informações úteis na discriminação entre várias instâncias do VS Code.

Há outro problema em aberto relacionado a permitir que as informações da barra de título sejam configuráveis, que também comentei bastante - e também permanece sem solução. Se fosse possível deixar o nome da pasta raiz alinhado à esquerda na barra de título, o problema de ter vários projetos abertos seria bem menor, porque eu poderia pelo menos ver qual instância aberta era qual dentro do Windows ao alternar tarefas. Parece que deve ser muito trivial tornar configurável e pelo menos aliviaria a dor de não ser capaz de abrir vários repositórios git em uma única instância enquanto isso é resolvido ...

@waderyan

  1. Meus projetos da web são gerenciados por uma única pasta pai. É configurado desta forma para organização e links rápidos para minhas pastas de repositório. Eu também faço isso, pois é fácil para mim alternar para um projeto anterior / atual para extrair exemplos de código quando eles forem reutilizados. Ao contrário de abrir outra janela, é mais fácil abrir outra guia e mais eficiente em termos de tempo no meu caso.

  2. Cada projeto da web tem sua própria integração git, no entanto, para mim, pessoalmente, não exijo que .git seja integrado ao meu editor de código. É uma boa opção para mim, mas não um requisito. Eles têm sua própria integração .git devido ao desejo de manter cada projeto da web separado em meu host de repo.

@nickmak @jamietre @pesho obrigado por compartilhar suas idéias. Isso é útil e estou ansioso para conversar com muitos de vocês amanhã.

@alefragnani Estou focado no cenário do usuário final. Abordamos esse problema com cautela devido ao impacto nas extensões. Iremos agir com cuidado e comunicar quaisquer alterações de API. Envie-me um ping no Twitter, se quiser, e podemos atender uma chamada para discutir mais.

até mesmo o notepad ++ suporta várias pastas. é a razão pela qual não posso deixar o notepad ++.
este dia trabalhando com javascript precisa abrir vários projetos.

Eu faço o trabalho de software embarcado e geralmente há algumas pastas nas quais estou trabalhando no sistema. Por exemplo, código do aplicativo, biblioteca do fornecedor e código do sistema operacional.

Eu gostaria de adicionar meu caso de uso aqui para várias pastas na mesma janela.

Eu sou um desenvolvedor de jogos e, para nosso jogo atual, implementamos o suporte a mod. Nosso jogo tem projetos de cliente, servidor e servidor mestre. Enquanto edita os arquivos mod, é comum trabalhar apenas no nível mod do jogo (em vez do que chamamos de nível básico ou nativo do código do jogo real. Por exemplo, trabalhar apenas nos arquivos Lua em vez de arquivos C ++ e C # para servidor e cliente respectivamente). Freqüentemente, as pastas não podem estar localizadas em uma pasta pai comum.

Neste caso de uso, ao trabalhar apenas com os arquivos mod, no passado usamos a funcionalidade de múltiplas pastas do Sublime para criar uma visualização do projeto apenas das pastas mod de nível superior do Cliente e do Servidor. Isso nos permite evitar os arquivos nativos (C # e C ++) e editar rapidamente os arquivos Lua entre esses dois projetos que estão muito relacionados um ao outro.

Ter suporte a várias pastas no VSCode nos permitiria fazer o mesmo e facilitaria muito nossa adoção do VSCode (que amamos muito).

O que aconteceu com a chamada realizada na semana passada? Estou no mac e não consigo abrir várias instâncias do VSCode, o que achei que seria uma solução alternativa.

obrigado!

Eu recebi uma ligação na semana passada com Wade, é óbvio e justo que não foi um
prioridade inicial, eles construíram um editor muito bom e agora
eles estão estendendo para atender às necessidades de diferentes desenvolvedores. A equipe Dev são
ouvindo, estou ansioso para ver como eles farão isso

Em Dom, 15 de janeiro de 2017 21:20 nowherenearithaca, [email protected]
escrevi:

O que aconteceu com a chamada realizada na semana passada? Estou no mac e não consigo parecer
para abrir várias instâncias do VSCode, o que achei que seria uma solução alternativa.

obrigado!

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-272724576 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AA16yEIdTFJAnqXHLs_WUvrGBIR9G7f-ks5rSo2DgaJpZM4Gm3nX
.

em grande pedido
marca

@nowherenearithaca Tive ótimas ligações com vários usuários e compartilhei o que aprendi com o resto da equipe. Ainda estamos descobrindo as próximas etapas, mas espero que façamos algo nessa área em breve.

@waderyan , desculpe pela resposta tardia:

Seus microsserviços compartilham uma pasta pai? Por que ou por que não?

Sim, por conveniência. Torna mais fácil encontrar serviços relacionados quando eles estão no mesmo diretório.

Cada microsserviço é separado em seu próprio repositório git? Por que ou por que não?

Sim. Eles não apenas têm repositórios diferentes, mas também configurações de linting e depuração diferentes. Além disso, usar o Cmd + P para alternar arquivos entre projetos é muito útil. Pesquisa global em projetos relacionados, ...

Estou ansioso para ver isso em ação!

Uma solução seria criar um link para a pasta onde estão os arquivos que você gostaria de acessar.
Não é o ideal, mas pode ajudar.

_Exemplo:_

/home/myprojet
/home/mylibs
cd /home/myproject
ln -s /home/mylibs
code /home/myprojet

Tenho três monitores e desejo usar o VSCode em todos os três. Se eu não conseguir abrir várias instâncias, pelo menos suporte o desencaixe das guias e arrastá-las para outras janelas (semelhante ao Visual Studio 2015).

Aceita.

Todos os outros editores de texto fazem isso. Por que a Microsoft não pensou em algo tão simples e necessário?

@calloncampbell Esse recurso está neste problema: https://github.com/Microsoft/vscode/issues/2686

@calloncampbell @rsyring Não sei o que estou fazendo de errado, mas usando code -n posso abrir quantas instâncias de editor eu quiser.

Se bem entendi, isso será investigado no Plano de Iteração de fevereiro como "Investigação inicial sobre a implementação de 'espaços de trabalho com várias raízes', espaços de trabalho com 'várias pastas'" :)

+1 ...
Isso não é possível com a versão antiga do VSCode ou eu estava apenas usando o Sublime? esqueci ...
mas muito útil.
Agora meu Mac está cheio de 6 janelas por todo o lugar ...

E não, não vou abrir a pasta raiz de todas essas 6 pastas que abri, porque o explorer é um scroll vertical e demoraria uma eternidade para navegar pelos arquivos ...

@edmundtfy é possível no sublime. O Visual Studio Code nunca teve suporte para essa funcionalidade.

@ solução

@DeeJaVu considerando que ... VSCode tem esses mouseover-tooltip e control + click para ir para a definição. Eu baixei algumas extensões para Sublime, mas o mouseover e as coisas de controle + clique não funcionam tão bem .. alguma recomendação?

Eu realmente sinto falta disso depois de usar o Sublime por anos. No momento, estou trabalhando com o Intershop (como front-end) com centenas de milhares de arquivos por cardridge. Se eu tenho que carregar uma loja virtual completa, é muito lento quando você deseja abrir CTRL + P para alternar rapidamente para um arquivo ou quando você precisa pesquisar.

Além disso, simplesmente não quero todas as pastas de um projeto em meu editor. Não preciso de tudo como desenvolvedor front-end. Apenas as pastas de que preciso são suficientes.

Outro exemplo: criar um site Wordpress e plugins para ele ao mesmo tempo. Por que eu precisaria incluir um site Wordpress completo? Isso apenas diminui sua eficiência.

Outro problema que temos: nosso framework de front-end é dividido em diferentes repositórios git. Ter mais de 4 janelas abertas é uma verdadeira dor. E o IntelliSense SCSS não está funcionando então (IE. Variáveis ​​do núcleo> pacote)

TLDR; VScode é inutilizável para projetos grandes / enormes

+1, vamos imaginar que você desenvolva um wordpress ou drupal com vários módulos personalizados.

A raiz do seu projeto é a raiz do seu site, mas você não quer que o site completo seja um repositório, você apenas quer seus vários módulos ou temas como repositório independente cada.

Caso de uso muito comum em desenvolvimento web que deve ser coberto, mesmo pelo menor / mais leve IDE.

+1

+1, me tornaria capaz de editar um projeto e trabalhar em seus submódulos perfeitamente

+1

É o único problema que nos impede de migrar toda a nossa equipe de desenvolvimento de 32 pessoas para o VS.

O desenvolvimento de microsserviços simplesmente não é viável, é doloroso.

+1

+1, definitivamente útil, estou decidindo ir para vscode do sublime, mas, por causa da falta desse recurso, acho que ainda usaria o sublime até um dia ..

É um recurso muito necessário e básico. Não consigo acreditar como os desenvolvedores deste grande editor o ignoraram. É inútil sem esse recurso. Isso está me impedindo de mudar para VSCode do Atom.

Por favor, adicione este recurso. Depois de usar Sublime e Atom, este é para mim um recurso necessário de um editor. Claro que não é tão fácil por causa da integração com o git, mas é algo que preciso dentro do meu editor favorito.

+1

+1 necessidade urgente

+1 Como foi dito antes, para passar de Atom para VSCode, realmente precisamos deste recurso.

ATENÇÃO ANTES DO COMENTÁRIO
* POR FAVOR !!!! Pare de comentar com um "+1"

Cada um de seus comentários inúteis distrai mais de cem pessoas apenas com este tópico !!!
Se você quiser apoiar esse recurso - tem emoção na primeira mensagem!
Se você deseja se inscrever em atualizações - pois este é o botão "Inscrever-se" à direita dos tópicos
Respeite os outros membros, que são forçados a ler o seu "+1", "realmente necessário", etc.

Para referência, a forma como o Sublime Text (por exemplo) organiza seus projetos é "incluindo" árvores de pastas, com opções exclusivas por "pasta" incluída em seu projeto.

Para visualizar isso, o JSON de um arquivo de projeto Sublime Text se parece com isto:

{
    "folders":
    [
        {
            "name": "Front-End (web-forms)",
            "path": "source/www/forms",
            "file_exclude_patterns":
            [
                "*.sublime-*",
                ".gitignore"
            ],
            "folder_exclude_patterns":
            [
                "node_modules",
                ".idea",
                "bin",
                "fonts"
            ]
        },
        {
            "name": "CORE C# Server Components",
            "path": "Source/Server",
            "file_exclude_patterns":
            [
                ".gitignore",
                "*.resx",
                "*.designer.cs",
                "*.StyleCop",
                "*.testsettings",
                "*.cache",
                "*.user",
                "*.vsmdi"
            ],
            "folder_exclude_patterns":
            [
                "bin",
                "obj",
                "TestResults",
                "Service References"
            ]
        },
        {
            "name": "DB schemas & utility scripts",
            "path": "Source/Database"
        },
        {
            "name": "Grunt Build source",
            "path": "Build",
            "folder_exclude_patterns":
            [
                "dist",
                "node_modules",
                "TestResults"
            ]
        }
    ],
}

Como você pode ver, cada pasta incluída é relativa ao caminho do projeto (no caso de texto sublime, ele é o caminho do arquivo *.sublime-project ). Além disso, cada pasta tem uma seção para excluir padrões de arquivo e pasta com curingas. Ótimo para ignorar (como pode ser visto acima) resultados de testes, bibliotecas que você não deve editar, ilustrações e muitas outras coisas.

Este é o último motivo que deixei para não mudar.

É muito útil!

+1
Exemplo: preciso verificar se alguma funcionalidade ainda não foi implementada em outros módulos que o aplicativo faz referência para que eu não duplique a funcionalidade

Obviamente, os módulos são armazenados em outro lugar no caminho do arquivo, não no próprio aplicativo, e usar várias janelas é uma dor com apenas uma tela, quando você só quer acessar rapidamente um arquivo e ler o código
Estou falando de aplicativos AngularJS, que não precisam de implantação nem nada, apenas um servidor em execução.
Por que eu deveria me preocupar em desenvolver em outra estrutura de arquivo, quando posso simplesmente abrir a pasta do aplicativo diretamente do Tomcat e ter minhas alterações em vigor em tempo real.

E não, não há pasta pai, a menos que você sugira abrir a pasta do servidor Tomcat como um projeto (o que é como sugerir que eu abra todo o meu HDD como um projeto, porque então poderei abrir todos os arquivos).

Uau, eu desinstalei o atom para experimentar o VS, e esse recurso não foi adicionado desde 2015.

stoffeastrom abriu esta edição em 21 de novembro de 2015

Isso é deprimente. : desapontado:

PS: Abrir a pasta master não é exatamente uma solução, pois abre todos os arquivos indesejados também, superando todo o propósito deste ticket.

Isso é realmente deprimente. Mas, novamente, não é tão deprimente quanto as pessoas ainda reclamam sobre um editor de código aberto incrível e gratuito (que adiciona consistentemente um punhado de novos recursos _ a cada mês_). Nem tão deprimente quanto enviar spam a todos que assistem a este tópico com comentários sobre a própria depressão.

(Agora sou um dos spammers, eu acho: sorriso :)

Atualização: O plano atual é examinar isso nas iterações de março / abril.

Consulte https://github.com/Microsoft/vscode/issues/21923 para o plano de iteração de março:

Investigue em espaços de trabalho com várias raízes e várias pastas # 396 @bpasero @Tyriar

+1

Para compartilhar um exemplo do mundo real que refina a descrição do recurso: Exemplo, WordPress Theme / Plugin dev.

Em outros editores, configurei várias pastas como "favoritos", para obter uma árvore de arquivos bastante grande e complexa um pouco mais fácil de gerenciar. Uma é para o webroot, que é a raiz que eu prefiro que qualquer função de depuração e conclusão de código consulte para começar (o ambiente). O segundo é para o projeto real, uma pasta de tema ou uma pasta de plug-in que, em meu fluxo de trabalho, é a raiz do controle de versão. Ocasionalmente, configuro pastas adicionais como referência, como um tema pai, ou tema de modelo, ou um plugin com o qual estou integrando e preciso consultar / ler com frequência.

Portanto, o conjunto de recursos aqui é, 1. a capacidade de definir a raiz git e a raiz de pesquisa em locais diferentes. 2. Um sistema de marcação de pastas puramente visual para organizar o painel da árvore de arquivos.

Para alguns no thread, onde a raiz do git e a raiz do projeto são as mesmas, parece que aprender e usar submódulos seria o suficiente, e então é apenas cerca de 2. para obter uma visão menos confusa de uma pasta aninhada.

Tenho certeza de que alguns no segmento estão realmente pedindo suporte literal a vários projetos, mas eu presumo que a maioria está apenas pedindo principalmente a ideia mais simples de bookmarking de pasta.

Além disso, estou pedindo uma maneira de definir um como raiz do projeto (pesquisa / depuração) e outro como raiz git. (Sinta-se à vontade para ignorar meu péssimo nome de coisas.)

Minha solução alternativa para isso é simplesmente criar uma pasta pai e, dentro dela, criar os links simbólicos com todos os projetos que desejo.
_por exemplo._

Eu tenho esses projetos

1. my-app-api
2. my-app-client

Eu crio uma pasta chamada _my-app-all_ (o nome é irrelevante aqui) e dentro, eu crio dois links simbólicos apontando para my-app-api e my-app-client e então no VSCode eu só preciso abrir my-app- todos

Passos

  1. mkdir my-app-all
  2. cd my-app-all
  3. ls -s ../my-app-api
  4. ls -s ../my-app-client

Notas:
A integração git não funcionará

@DannyFeliz isso deve ser marcado como uma resposta a este problema e postado no topo para que todos vejam ... Eu testei isso no Windows também, usando o comando MKLINK.
Exemplo de uso:

  1. Abra o prompt de comando com privilégios de administrador
  2. Vá para a pasta do seu projeto
    3. [opcional] crie uma pasta de links
  3. use MKLINK / D "link_name" "caminho para a pasta que você deseja referenciar"

Ao abrir o projeto no código do VS, você verá a pasta referenciada e todos os arquivos / pastas nela.

Boas equipes de programação!

Isso não permite que a integração do Git funcione.

Na segunda-feira, 20 de março de 2017 às 14h42, poparazvandragos [email protected]
escrevi:

@DannyFeliz https://github.com/DannyFeliz deve ser marcado como um
responder a esta questão e postar no topo para que todos vejam ... Eu testei
isso no Windows também, usando o comando MKLINK.
Exemplo de uso:

  1. Abra o prompt de comando com privilégios de administrador
  2. Vá para a pasta do seu projeto
    3. [opcional] crie uma pasta de links
  3. use MKLINK / D "link_name" "caminho para a pasta que você deseja referenciar"

Quando você abre o projeto no código VS você verá a pasta referenciada
e todos os arquivos / pastas nele.

Boas equipes de programação!

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-287907310 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ABEOBVKz2bqFsRdfvyOpcFW2e_26HV5bks5rnvLWgaJpZM4Gm3nX
.

@ehartford Eu disse uma resposta, não A resposta, já que a maioria de nós estava procurando exatamente por isso, exibindo vários diretórios na mesma janela VSCode, que residem em locais diferentes.
Os Links Simbólicos fazem exatamente isso, mas ao trabalhar no Windows esta não é a solução que vem à mente.
Isso teve que passar 2 anos e para um desenvolvedor Linux / OSX vir e nos mostrar a solução mais simples.
Estou feliz por finalmente decidir deixar meu comentário sobre este problema, pois tenho uma solução alternativa para o que eu queria
depois de apenas 12 dias, quando eu mais precisava.

A questão não deve ser descartada, pois muito mais pode ser feito se os desenvolvedores decidirem intervir no assunto.
Mas para a maioria de nós, isso é satisfatório. Eu estava apenas sugerindo mover isso para cima de alguma forma, para que as pessoas não percam tempo lendo todos os outros comentários, até que cheguem a este comentário. Alguns podem simplesmente ignorar por causa do tamanho do segmento.

Vou apenas editar isso porque vejo pessoas pulando nas minhas costas porque descobri como conseguir o que queria e tentei tornar mais fácil para os outros verem uma alternativa, mesmo que não seja perfeita. BTW: você sempre pode usar o prompt de comando integrado ao VSCode para puxar / confirmar / enviar arquivos em pastas vinculadas individuais, mas por que se contentar com soluções alternativas.

Sem a integração do Git, é totalmente impossível. Não considero esta uma solução aceitável de forma alguma. Ansioso por uma solução real. Cumprimentos.

Se ajudar - o cliente nodejs do google appengine é estruturado assim:

https://github.com/GoogleCloudPlatform/google-cloud-node

Eu adoraria ser capaz de abrir / depurar / trabalhar em uma solução como essa (mesmo que seja um pacote por vez). Eu adoraria ser capaz de escrever projetos / bibliotecas baseados em Typescript neste estilo.

Obrigado por todo o excelente trabalho!

Adoro o VSCode, mas é uma porcaria em lidar com vários projetos. Mas posso entender por que o recurso foi adiado, pois torna várias coisas, como o controle de origem, mais complicadas devido ao aninhamento, etc.

Eu ficaria feliz com um recurso de 'troca rápida de projeto' OU a capacidade de 'tabular' várias instâncias de vscode em uma janela.

Concordo totalmente, por favor, suporte a abertura de várias pastas de projeto na mesma janela. Esta função é muito importante.

@replete Não é uma solução perfeita para o seu problema. Mas dê uma chance ao Gerente de Projeto , isso está me ajudando parcialmente agora.

@dariusrosendahl Sim, descoberto esta manhã de maneira bastante engraçada! Faz o trabalho por enquanto.

A barra lateral tem apenas 5 ícones, não demoraria muito para adicionar uma barra lateral 'Projeto'. Mas parece que os proprietários de produtos vscode são muito exigentes sobre como ele é mínimo. IMO mínimo, pois agora está se tornando um IDE.

@replete fico feliz em saber que está sendo útil 😄

Na verdade, existe uma _ API experimental_ para a criação de uma assim chamada _tribuição do Explorador de árvores_ (assim como um painel de símbolos - https://github.com/Microsoft/vscode/issues/15485). Com isso, a extensão pode adicionar um ícone à barra de atividades.

Vou adicionar um problema à minha extensão com a sua sugestão, obrigado 👍

+1

@dmccaffery

Eu, pessoalmente, não me importo se esse recurso vai parar no produto ou não - eu entendo por que algumas pessoas querem, mas eu diria que torna tudo um pouco mais complicado.

Então, talvez não domine a conversa com comentários negativos sobre o recurso e sobre como o VSC não é um IDE? Eu acho que uma única resposta / voto negativo é o suficiente, ou na pior das hipóteses duas, se alguém precisar esclarecer mais uma posição.

Além disso, o argumento "não é um IDE" é discutível. Outros não IDEs também permitem isso.

Por exemplo: ao pesquisar usando uma expressão regex - qual área de trabalho estou pesquisando? 1? todos?

Não é um problema tão grande. Pesquise tudo ou tenha um seletor para direcionar a pesquisa para uma das áreas de trabalho abertas. Novamente, outros "não IDEs" (bem como IDEs) já tratam desse (e de outros) casos.

Corrigi esse problema em minha própria configuração, criando um diretório para cada "espaço de trabalho" e criando um link simbólico para os projetos que desejo ver nesse espaço de trabalho.

eu vi isso

Investigação inicial em áreas de trabalho com várias raízes e várias pastas # 396 @bpasero @Tyriar

é feito de acordo com https://github.com/Microsoft/vscode/issues/21923 alguma atualização sobre isso? :)

Nós (subconjunto da equipe) fizemos uma investigação inicial sobre a quantidade de trabalho envolvida e os desafios que vemos e o próximo passo é discutir o resultado disso com a equipe e planejá-lo. Fazemos nosso planejamento para o lançamento de abril durante esta semana, então eu esperaria mais itens de plano de granulação fina como resultado deste trabalho aparecendo em breve.

screen shot 2017-04-06 at 12 09 26

Se eu não chegar muito tarde para a festa, eis uma maneira legal de implementar isso.
Quando você vai ao "Explorer", já temos duas seções. Um para arquivos abertos e outro para a árvore do explorer da pasta aberta atualmente.

Idealmente, poderíamos apenas abrir mais pastas na mesma janela e elas seriam adicionadas aqui em sua própria seção que pode ser expandida para ver a árvore do explorer.

A mesma coisa pode ser feita para a seção Source Control. Uma subseção para cada pasta que é aberta no "explorer". Portanto, uma relação 1to1.

Dessa forma, talvez possamos fazer todos felizes. Temos suporte para abrir várias pastas na mesma janela, se quisermos, e também a integração GIT ainda funciona e é capaz de lidar com cada "raiz do projeto" separadamente.

Abrir mais de um projeto na mesma janela é um recurso importante para mim também. Normalmente, eu também abro projetos para copiar alguns aplicativos básicos. Acabei de instalar o Visual Studio Code e voltarei ao Atom por esse motivo

1 Quero mostrar a outros desenvolvedores o valor do VSCode, mas não ser capaz de abrir duas pastas na mesma janela é um problema. Espero que isso tenha uma prioridade mais alta.

Apenas meus dois centavos:

Até agora, a palavra "monorepo" não aparece neste tópico

Meu monorepo centraliza as preocupações de configuração entre múltiplas raízes, onde cada uma é marcada por um arquivo ".root" na pasta que as contém.

Nem todo root é um repositório git externo, mas eles permitem a substituição parcial da configuração global.

Meu principal problema é que a busca por arquivos e / ou símbolos não prioriza o conteúdo de minhas raízes

Acho que o requisito pode ser dividido em ~ 4 requisitos separados, que podem ou não estar diretamente relacionados entre si (e provavelmente implementados de forma independente):

  • suporta várias pastas no explorer
  • suporta várias pastas na pesquisa
  • suporta várias pastas no controle de origem
  • suporta várias pastas na depuração

Pelo que vi neste tópico, separá-los pode dar suporte a uma ampla gama de cenários. É claro que ainda deve haver alguma pasta "principal", afetando como as pastas configuradas / selecionadas são persistidas.

Não entendo por que a maioria dos comentários fala sobre soluções de explorador multi-root ou multi-folder. Na verdade eu acho muito ruim tentar implementá-lo do jeito IDE. Ele adiciona complexidade e certamente impacta o desempenho (tempo de carregamento, atualização do git ....).

Acho que esse recurso é muito importante, a necessidade basicamente é ter um visual de todos os projetos relacionados e alternar entre as janelas dos projetos rapidamente!

Temos duas opções:

  • Implementação em uma única janela : No meu sentido, isso introduz muitas outras preocupações, raízes de múltiplos projetos para git, pesquisa ... ISSO É MUITO RUIM para a UX e irá potencialmente introduzir bugs e complexidade ao editor.
  • Implemente um mecanismo de switch que seja Visual e mantenha uma janela por projeto : esta é a escolha mais segura e conveniente por um custo muito menor! @ min20 postou um visual sobre os botões de alternância do slack entre os grupos que acho perfeito para a necessidade!

spack

Espero que esse recurso chegue, mas não como soluções multi-root! um dos principais benefícios de um pequeno editor é a sua simplicidade e velocidade, muti-root != simplicity & speed

Tenho que discordar totalmente de você @ g13013 , você viu a implementação do Sublime? É muito simples e ainda muito mais rápido que o Visual Studio Code. Mesmo com todos os plugins GIT habilitados.

Não estamos falando sobre o uso de vários projetos em um editor. Estamos falando apenas de usar as pastas de um projeto de que você precisa.

Estou trabalhando em lojas Intershop, por exemplo. Não preciso de muita coisa, só preciso editar os cartuchos. 80% das pastas e arquivos são inúteis para mim e só tornam o editor muito mais pesado (acredite, ele fica muito lento).

Usar o "Quick Open" no Visual Studio também é inutilizável se houver muitos arquivos duplicados. Freqüentemente, você não tem certeza se vai abrir o arquivo certo e, de novo, fica lento com MUITOS arquivos.

Eu entendo, mas, tendo usado sublime e atom no passado, finalmente concluí que nenhum deles com o recurso "muti-root" resolveu qualquer outra coisa além da exploração de arquivos de projeto, falando em sublime, a árvore de pastas sublime é muito lenta em grandes projetos e até mesmo congela ao descobrir, sublime não tem integração de recursos "git" e "debug" fora da caixa .... a introdução de muti-root irá introduzir uma série de problemas relacionados à integração git, procurando sem impactos sobre desempenho ... até a UX é afetada, como explorar questões importantes em grandes projetos.

Estranho, para mim é o contrário.

Talvez seja porque 99% das vezes eu só incluo o que preciso no Sublime ou no Atom :) e é exatamente isso que queremos.

Talvez seja apenas a maneira como você usa o editor. Estou acostumado a usar CMD / CTR + P e digitar exatamente o arquivo que desejo. Isso é impossível se você tiver que incluir a raiz de um projeto com muitos arquivos duplicados. (cartuchos / arquivos deixados lá para comparar o que era o original :)) ou algo como o wordpress onde há muitos arquivos com o mesmo nome.

Olá,
Sim, a ideia de várias pastas funciona sem quebrar muitas coisas. Cada pasta adicional pode ser uma nova subseção com um prefixo para indicar que é estranha à pasta principal. Primário é usado para depuração e Git. Um usuário pode clicar com o botão direito em qualquer pasta externa e torná-la primária . O que você ganha:
1) ser capaz de ver todas as suas pastas e arquivos e abri-los conforme necessário.
2) realinhar o que é principal para trabalhar.

Agora, se alguém deseja ter vários projetos abertos ao mesmo tempo, deve ter uma nova solicitação de emissão aberta. Isso adiciona complexidade significativa descrita por várias pessoas. Plugins não são iguais a builtins. Se houver um editor que tenha um recurso integrado correspondente, ele deve ser apontado para que outros desenvolvedores possam examinar como seu fluxo de trabalho se ajusta a esse recurso. Obrigado. Dia bom.

Adicione-me à lista de usuários que consideram este o único fator que me impede de mudar para o VSC. Acho que a implementação Sublime de Projetos está no local. Se eu precisar trabalhar no app "Horário de voluntariado", por exemplo, abro o projeto que populei com diferentes pastas (a pasta principal do projeto, bem como outra pasta que contém imagens). Esse é o meu conjunto de trabalho para esse projeto. Se eu precisar passar para o aplicativo "Exchange Calculator", posso trocar todo o conjunto de trabalho para esse projeto ou abrir uma nova janela com esse projeto nele.
Outro caso de uso é ao usar um CMS. Se estou trabalhando em um plugin para o CMS, posso ter um projeto para o plugin que é um repositório Git e outro para todo o CMS, que não é Gitified. Posso alternar entre os dois conforme necessário e manter minhas preocupações com o Git separadas.
O VSC parece ser o futuro para mim, mas não sem a capacidade de manter conjuntos de pastas de trabalho separados.

Olá,
Eu só vi que Sublime Text tem suporte para projetos com um arquivo de projeto . Como isso se compara ao que está sendo pedido aqui? Parece uma solicitação para que o vscode ofereça suporte a arquivos de projeto em um espaço de trabalho. Houve um comentário anterior sobre uma extensão que poderia lidar com coisas nesse sentido para um gerente de projeto .

Eu honestamente também uso o Atom e a função de várias pastas (embutida) que me permite ter as pastas de documentação e minha pasta de projeto atual abertas ao mesmo tempo. Realmente parece mais fácil apenas habilitar o primário e um monte de secundários. Provavelmente uma simples seta ou início para indicar o primário. Obrigado. Dia bom.

image

Se valer a pena, aqui está meu caso de uso. Eu trabalho em um jogo que é dividido em três repositórios; um repositório Git para o mecanismo, um repositório hg para o código do jogo + conteúdo e um hg para o código do jogo que é genérico em muitos projetos. Há também um repositório hg para os plug-ins Sublime Text da empresa. O repo genérico é um sub-repo para o repo de jogo.

No meu próximo local de trabalho, espero trabalhar com muitos repositórios novamente.

É muito conveniente ter tudo isso na mesma instância do editor, e acho que faria sentido para todos eles obterem SCM adequado no código do VS.

Eu esperaria que a pesquisa pesquisasse todas as pastas mapeadas por padrão. Um bom bônus seria poder ligar / desligar as pastas que deseja pesquisar, temporariamente. (Por exemplo, quando estou interessado apenas em encontrar coisas no motor de jogo)

Há muitas pessoas dizendo que o VS Code não deveria ter suporte para isso porque A) Eles não precisam dele e B) VS Code é um editor de texto simples. O primeiro motivo não é bom - existem poucos recursos que são usados ​​por todos. A segunda razão ... VS Code não é apenas um editor de texto simples, ele tem depuração, SCM, plugins. Outros "editores de texto simples", como o Sublime, oferecem suporte a várias pastas. E como alguém que é inflexível sobre o desempenho, não consigo ver como o acréscimo desse recurso afetaria o desempenho de alguma forma significativa, especialmente para pessoas que usam apenas uma pasta. Podemos focar a discussão em como queremos que o recurso funcione, em vez de por que não o queremos.

@Srekel você pode incluir uma captura de tela de como você trabalha assim em seus editores atuais? Parece uma mistura de pastas e projetos usando plug-ins e integrados. Esperançosamente, as pessoas naquele campo A dificilmente notariam mudanças para incorporar esse tipo de recurso. Para o pessoal do acampamento B , eles estão certos. Você pode fazer coisas rapidamente com o aplicativo pronto para uso, se não precisar ficar atolado. Manter perto disso provavelmente ajuda a ter tais ciclos de atualização rápidos e elementos de interface organizados.

Algumas coisas sobre como fazer isso incluem:

  • compreender a relação de escopo, contexto, sessão, pontos de vista e estar atualizado .
  • os limites superiores (mais de 256 pastas?)
  • principais áreas afetadas (guias do editor, configurações, scm, git, extensões).
  • substituição ou conflitos de configuração do espaço de trabalho.

Seria bom falar aqui sobre algumas das coisas que o VSCode considera certas nessas áreas que precisam de compensação. Obrigado. Dia bom.

+1

+1. Tenho mais de 30 módulos, cada um com um repositório git próprio ao qual gostaria de ter acesso e trabalhar em um único ambiente. Achei que era isso que a maioria dos desenvolvedores de js / node fazia. Com o VSCode, isso é impossível e, infelizmente, um problema para mim.

+1

Está aberto desde 2015 e ainda não foi corrigido. É um recurso simplesmente muito procurado em qualquer editor, mas infelizmente o vscode não o possui.

+1

Estou constantemente confundindo uma janela do VS Code com outra ao usar a tabulação de comandos.

Todos os outros editores que conheço têm isso (Atom, Sublime, Brackets ...)

Adicionar um link simbólico ao meu projeto é um hack e exigiria que eu atualizasse meu .gitignore. Abrir o diretório pai é irritante porque meu painel de arquivos fica inundado com outros projetos pelos quais não me importo.

Plano de iteração de abril mostrando a tarefa "Investigar em áreas de trabalho com várias raízes e várias pastas" como concluído. Quais são os resultados da investigação?
@bpasero @tyriar

+1

Desculpe se estou muito ansioso. Vocês estão ocupados liberando código agora.

Olá,
A caixa de diálogo Abrir pasta deve ser considerada como Pastas abertas. Portanto, se estou em uma pasta pai específica, posso na caixa de diálogo destacar duas ou mais de suas subpastas para abrir ao mesmo tempo. Isso seria uma adição bem-vinda com a incorporação desse recurso. Obrigado. Dia bom.

+ outro

Nunca vi tantos comentários de baixo esforço em um tópico do GitHub antes, especialmente pós-emojis. Meu Deus.

Eu realmente gostaria desse recurso. Como alguém já deve ter dito, muitos projetos modernos são modulares, por exemplo, front-end em um repo / projeto e backend / api em outro. Freqüentemente, você desejará trabalhar com eles como um só.

Esta é a única razão pela qual não desisti do Atom.

Os microsserviços e as plataformas sem servidor, combinados com o antigo mantra "repos são baratos", são o motivo pelo qual isso é obrigatório. Não é incomum ter ~ 30 [pequenos] repositórios abertos e trabalhando em arquivos de vários projetos simultaneamente; esperar que as pessoas alternem entre tantas janelas ou transferir a organização da visualização de arquivos para o gerenciador de janelas do ambiente de área de trabalho não vai funcionar.

Olá,
Como você gerencia seus 30 repos agora @martellaj ? Parece horrível trabalhar ao vivo com tantos arquivos abertos. Costumo ter muitas bibliotecas nas quais trabalho, mas se tenho uma necessidade significativa de trabalhar no backport de um recurso útil a ser compartilhado, fecho propositalmente todas as minhas outras janelas de edição. Eu crio arquivos de configuração de atualização de testes e opções de projeto para fazer eu funcionar, então eu volto para minha visão anterior. Isso ainda é talvez 3 ou 4 outras janelas.
Você está fazendo isso por causa de outras limitações em seu ambiente? talvez a linguagem de programação não tenha intellisense? Talvez uma extensão que possa ler a API para fornecer assinaturas funcionais ajude?
Uma linguagem como o F # tem um recurso chamado provedores de tipo, um dos quais pode fazer exatamente isso e tornar a programação da web mais fácil. Isso não é para diminuir sua necessidade de várias pastas, apenas que você provavelmente ainda teria pelo menos alguns outros problemas com um grande espaço de trabalho ativo. Obrigado. Dia bom.

@pr-yemibedu, acho que o que @martinjco está dizendo é que ele não tem os arquivos abertos, mas ele teria acesso rápido ao repo se tivéssemos uma estrutura multi-root. Imagine, basta CMD + P para qualquer arquivo que você precisa;)

O problema com a situação atual é que TEMOS que ter os arquivos abertos ou pelo menos alternar entre as 30 janelas diferentes porque o VScode não oferece suporte para isso.

Na verdade, mudei de volta para o Atom recentemente por causa do recurso ausente. Estou trabalhando em um projeto com 9 repo's no momento. Não quero abrir 9 widows VScode ao mesmo tempo, mas só quero usar um atalho para acessar o arquivo de que preciso.

Concordo com o comentário de @dariusrosendahl. Eu sou um programador novato e tenho que fazer referência a projetos antigos para escrever novos. Esperançosamente, isso mudará em breve, mas em sublime, posso facilmente ter três a quatro pastas de projetos e, em comparação, abri-las na mesma sessão
screen shot 2017-05-11 at 12 48 57 pm

Se conseguirmos isso no estúdio visual, seria ótimo

Olá,
Eu concordo com os pontos levantados, pois você pode ver minhas postagens anteriores a favor desse recurso. Havia uma declaração exata sobre a qual eu estava comentando por martinjco:

Não é incomum ter ~ 30 [pequenos] repositórios abertos e trabalhando em arquivos de vários projetos simultaneamente;

O que nuno1895 mostra é como eu uso o Atom hoje quando preciso trabalhar em várias pastas, mas em um projeto de foco principal simples. Na verdade, eu uso tanto VS2015, gedit, vim, notepad e notepad ++ para desenvolvimento ativo. Existem pontos fortes em cada um que ainda não têm equivalente em suas contrapartes.

Eu estava apenas tentando entender se há um ponto central que pode ser esclarecido. Todos nós queremos que isso seja trabalhado e favorecido pelos desenvolvedores que gastariam tempo com isso. É por isso que eu estava perguntando como isso é tratado hoje. 9 vs 30 provavelmente não teria despertado tanto meu interesse em responder, mas eu gosto de saber o que as pessoas estão comparando ao vscode e se vale a pena olhar para outra ferramenta.

Só vi Atom e SublimeText serem mencionados como base para comparação e com capturas de tela úteis. Mais discussão, polegares e comentários são bem-vindos para que isso seja aceito e implementado. Obrigado. Dia bom.

Um ponto que pode não ter sido enfatizado o suficiente é a capacidade de "alternar" rapidamente entre conjuntos de pastas (projetos). É chamado de "Projeto de troca rápida" no Sublime. Ao clicar nesse item de menu, você obtém um pop-up com uma lista de todos os seus projetos; ao selecionar um dos projetos, o editor exibe a (s) pasta (s) e todos os seus arquivos abertos como você os deixou pela última vez.
Por exemplo, se eu estivesse trabalhando no Projeto A e tivesse os arquivos app.js e index.html abertos e depois mudasse para o Projeto B, ele fecharia o Projeto A e exibiria o Projeto B. Se eu voltar para o Projeto A, mostre-me a (s) pasta (s) e o app.js e index.html como eu os deixei (até as edições não salvas estão lá).
Se eu precisar ter os dois projetos abertos ao mesmo tempo, posso apenas abrir duas instâncias do editor.
O importante é que posso manter todas as minhas coisas em baldes separados e posso alternar entre eles rapidamente.

+1

Olá,
Eu li sobre esse recurso. Alternar projetos sem navegar no Sublime Text aponta algumas das coisas boas e ruins. Seria bom talvez codificar as várias pastas abertas no arquivo de configurações do espaço de trabalho. Se esse arquivo parecer no local errado, algo como folders.json pode ser criado para persistir o estado atual de quais pastas e arquivos estão disponíveis e abertos para o conjunto de trabalho atual. Obrigado. Dia bom.

Comecei a usar o VSCode há alguns meses e, de modo geral, estou muito satisfeito. Vou acrescentar minha voz ao coro e dizer que essa característica que falta é a grande surpresa para mim. Existem _qualquer_ outros editores decentes que têm essa limitação? Em qualquer caso, deve ser consertado. :)

Esta é a configuração do meu novo trabalho:
Um repo para a tecnologia principal. Digamos que o caminho seja C: / mygamengine /
Um repo para o código do jogo. Está sincronizado com C: / mygamengine / mygame
Um repositório para o conteúdo do jogo (texturas etc): C: / mygamengine / mygame_data

Todos os três são git. Eles não são configurados como sub-repos, eles apenas são sincronizados com essas pastas.

De preferência, gostaria de apenas abrir a pasta raiz no VS Code e fazê-lo descobrir automaticamente que são essencialmente três projetos diferentes, e que os arquivos em mygame pertencem a esse repositório git e não ao de mygameengine.

Gostaria de poder definir configurações para este espaço de trabalho que sejam diferentes para cada repositório (por exemplo, posso querer executar um linter no projeto do motor, mas não no código do jogo). Também seria bom se as configurações do espaço de trabalho por padrão fossem definidas em todos os três projetos.

Nossa, isso ainda não foi resolvido? Eu esperava substituir o Atom pelo VS Code já que, de acordo com as análises, ele é muito mais rápido e não tem lag como o Atom.
Meu projeto principal são dois repositórios Git, um back end e outro um front end. Localmente, ambos estão na mesma pasta, mas se o código Atom ou VS abrir essa pasta pai, nenhum status Git será reconhecido.
No Atom, apenas adiciono as duas pastas à minha área de trabalho e funciona.

: brilhos: Atualização: brilhos:

Já faz um tempo desde nossa última atualização, então pensei em deixar todos informados. Eu, @bpasero e o resto da equipe identificamos a maioria dos problemas com a implementação de multi-root e estamos atualmente trabalhando em alguns modelos e descobrindo mais detalhes sobre a UX.

Por que demora tanto tempo?

Está demorando muito porque esse recurso não é nossa única responsabilidade e o trabalho envolvido em fazer o multi-root acontecer é imenso. Para começar, todos os componentes do VS Code foram projetados sob o pressuposto de que há apenas uma única pasta ou nenhuma pasta aberta em um determinado momento. Quando você tem uma base de código tão grande quanto a nossa com uma suposição como essa, é preciso muito trabalho para torná-la mais flexível.

Para dar alguns exemplos, aqui estão alguns dos maiores pontos problemáticos que identificamos até agora:

  • A API de extensão expõe um único workspace.rootPath , o que é insuficiente quando adicionamos suporte para pastas multi-root. Queremos evitar quebrar essas extensões e fornecer um caminho de migração, se necessário.
  • A maneira como as configurações do espaço de trabalho interagem em um mundo com várias raízes é um pouco diferente. Pegue workbench.statusBar.visible por exemplo, que atualmente é permitido nas configurações do espaço de trabalho. Não poderíamos mais suportar isso, pois isso levaria a um comportamento estranho / com erros se definido em 2 pastas. Estamos descobrindo como lidar com esse tipo de caso.
  • O provedor SCM (git) provavelmente precisa da maior quantidade de trabalho de UX para oferecer suporte a várias pastas: Precisamos introduzir o conceito de "projeto ativo"? Deve ser definido explicitamente (clique com o botão direito do mouse na pasta e defina-o) ou implícito (olhando para a pasta do arquivo ativo)? Deve ser um conceito global ou limitado a esse recurso específico? etc.

Não queremos nos apressar com uma solução mal pensada, então estamos demorando e realmente pensando nos problemas e implicações potenciais de como isso afetará cada componente. Ele virá quando estiver pronto.

Resumo dos comentários até o momento

Passei apenas algumas horas examinando o enorme tópico para reunir o feedback até agora. Foi um pouco difícil categorizar algumas dessas coisas, mas aqui está o que as pessoas buscavam em geral (estou parafraseando).

  • Quero integração git em várias pastas
  • A mudança de pasta atual e / ou gerenciamento de janela do sistema operacional UX é complicado
  • Quero pesquisar em várias pastas
  • Eu quero depurar em várias pastas

Preocupações

  • As refatorações funcionam entre projetos ou em um único projeto?
  • Com qual projeto estou me comprometendo no Git?
  • Em que pasta (s) minha pesquisa será executada?
  • Não quebre as configurações do espaço de trabalho
  • Não quebre as extensões - avise os desenvolvedores de extensões sobre a nova API
  • Um UX com guias no estilo Slack não é suficiente para mim, isso é basicamente apenas mover o gerenciamento de janela do SO para o VS Code - eu quero ser capaz de acessar todos os arquivos dos projetos em uma única janela (ou seja, conjunto de grupos de editores)
  • "No meu sentido, ele apresenta muitas outras preocupações, raízes de múltiplos projetos para git, pesquisa ... ISSO É MUITO RUIM para a UX e irá potencialmente introduzir bugs e complexidade para o editor."

Outros comentários

  • Eu só quero abrir um subconjunto dos repositórios na minha "pasta git"
  • Quero uma maneira legal de pesquisar em uma única pasta ou organizar os resultados da pesquisa por projeto
  • Eu quero ser capaz de navegar até o código de dependência para ler rapidamente
  • Quero executar diferentes versões do TypeScript para diferentes pastas
  • O código VS é muito lento com repositórios gigantes
  • Quero manter alguns projetos sempre abertos para uso como referência (por exemplo, um tema / modelo)
  • Quero que o VS Code reconheça arquivos .vscode / settings.json em qualquer diretório (isso ajudaria na solução alternativa)
  • Deixe-me definir uma raiz de projeto (pesquisa / depuração) e uma raiz git
  • Sublime lida com integração git multi-pasta com elegância
  • Pastas com guias semelhantes à IU do Slack (ou seja, algum paradigma de projeto ativo)
  • Uma seção separada no explorer para cada pasta
  • Use uma pasta como principal e o resto como vinculadas / subpastas
  • Quero projeto de troca rápida como no sublime (troca rápida + retém o layout do espaço de trabalho)
  • Este estilo de gerenciamento de espaço de trabalho é particularmente útil para o seguinte: módulo npm, julia, heroku PaaS, wordpress, drupal

Soluções alternativas atuais

Aqui estão as principais soluções alternativas atualmente:

Quando comentar?

Evite: +1: ou comentários "Eu quero isso". Quando um comentário é feito sobre este assunto, as 153 e mais pessoas que comentaram no são notificadas, além de muitas outras que clicaram no botão de inscrição. Os comentários também enterrarão as atualizações da equipe, portanto, tente estar atento a isso. Por suposto, comente se acrescenta à conversa.

Um recurso que teria mais utilidade indiscutivelmente do que ter raízes múltiplas é adicionar a capacidade de ter conjuntos de trabalho configuráveis. Isso permitiria que você abra um pai comum, mas tem muitas combinações de pastas neste projeto.

Genericamente, isso seria útil para qualquer projeto por ser capaz de "focar" em certos arquivos / pastas de uma vez em bases de código maiores sem ter que mudar a configuração de todo o root a cada vez.

NÃO tem plano sobre este recurso?

Você pode ver o plano para este recurso no comentário de @Tyriar e nestes links relacionados:
https://github.com/alefragnani/vscode-project-manager/issues/46
https://github.com/Microsoft/vscode/issues/26068

Gostaríamos de compartilhar nossos designs e receber seus comentários. Para fazer isso, iremos configurar uma série de teleconferências onde examinaremos nossos designs e discutiremos suas reações a eles.

Se você gostaria de participar dessas discussões e nos ajudar a fazer o design certo, entre em contato comigo (envie-me um e-mail - stevencl em microsoft ponto com) e eu irei configurá-los.

Esperamos agendar essas discussões para quinta-feira, 1 de junho e sexta-feira, 2 de junho.

@Tyriar @stevencl Obrigado pessoal! :aplaudir:

Obrigado a todos por participarem das sessões de hoje. As gravações das sessões foram postadas aqui

Por favor, assista aos vídeos e compartilhe quaisquer comentários adicionais que você tenha sobre os designs.

@stevencl obrigado por executar os estudos e disponibilizá-los!

Ótimos vídeos, obrigado! Algum feedback:

  • 👍👍👍 para o design geral simples e extensão natural de como o VSCode funciona hoje. Vocês lidaram com muitas situações complexas de uma forma simples e elegante. Parabéns por isso!
  • Eu gosto da notificação SCM agregada no canto esquerdo inferior, nenhuma mudança necessária do meu ponto de vista com uma exceção: eu pularia o pop-up após clicar na notificação SCM e ir direto para o painel SCM. Menos cliques = sempre melhor para mim.
  • Raízes codificadas por cores, como sugeriu Alexey, é uma ideia interessante, pode ajudar.
  • Pesquisar: definir o escopo para uma pasta será importante para mim, acho que o campo atual "arquivos a serem incluídos" pode ser usado para isso, só queria ter certeza.
  • A única coisa sobre a qual não tenho certeza é a persistência e a abertura de additionalFolders quando abro path . Faz sentido com o último exemplo em que express-project é claramente o "projeto mestre", mas não tenho certeza sobre o exemplo anterior: express e express-plugin pareciam iguais, como verdadeiros irmãos, e não tenho certeza se eu esperaria que a abertura de express também abriria express-plugin .

    • De certa forma, a estrutura de dados por trás disso parece que deveria ser apenas uma lista plana de caminhos, não um "caminho" e depois "pastas adicionais".

    • Não tenho certeza se o conceito de um caminho mestre é tão útil. Em meus projetos, provavelmente não.

    • Para abrir o espaço de trabalho multi-root, esperaria um comando de nível superior como _Arquivo> Abrir espaço de trabalho_ além do _Arquivo> Abrir pasta_ atual.

    • No geral, não estou muito certo sobre isso. Desculpe, não tenho sugestões mais concretas.

Obrigado novamente, com isso, VSCode ganhará novos super-poderes.

Obrigado por compartilhar os vídeos. Eu gostaria de apoiar o design de "uma seção por pasta raiz":

one-section-per-root-folder

No início, eu esperava o outro design (semelhante a um texto sublime), mas depois de ver a alternativa "uma seção por pasta raiz", ficou claro para mim que essa abordagem tinha as seguintes vantagens:

  • Distinção e separação clara e inequívoca entre pastas (especialmente se eu tiver mais de 2 ou 3 delas, o que costuma ser o caso quando uso outros editores e IDEs)
  • Força a noção de que uma pasta raiz é um (sub) projeto separado
  • Acesso rápido aos comandos do subprojeto (como "novo arquivo", "atualizar" ... e, talvez no futuro, clicar com o botão direito para iniciar uma tarefa (por exemplo, "reconstruir") naquele subprojeto específico;))
  • Conforme mencionado pelo 2º grupo, com este design, é menos provável ter o problema de truncamento do nome da pasta

Com relação ao conceito de "uma seção por pasta raiz" ... Não tenho certeza se isso funcionará bem para mim e para a maioria dos meus casos de uso. Sempre que tenho uma situação de raiz múltipla, é comum que tenha muitas ; não apenas 2 ou 3.
Não tenho certeza de como essa abordagem será dimensionada?

Além disso, algum argumento para o layout semelhante a uma pasta atual é que ele é consistente com a forma como um monorepo seria exibido. Por exemplo, compare:

monorepo/      <- contains .git
  project1
  project2

vs.

microservices/
  project1      <- contains .git
  project2      <- contains .git

Esses dois devem realmente ser tratados de forma bastante semelhante pelo VSCode: monorepo já is (committing: natural, search: "files to include", vários READMEs: sua pasta é exibida na guia do editor; etc.). Multi-root deve seguir isso o mais próximo possível, IMO, que o design atual faz muito bem.

@stevencl Uma coisa que eu não entendi completamente: a solução trará um tratamento com escopo (ou mesmo hierárquico) das configurações de .vscode ? Por exemplo, se eu tivesse .vscode por pasta de nível superior, essas configurações serão aplicadas individualmente? Eles serão agregados de alguma forma na raiz do projeto? Ou apenas o .vscode "principal" contará?

Eu prefiro o design "uma seção por pasta raiz", pelos mesmos motivos listados por @maddouri. Além disso, tendo usado a outra alternativa (no Atom), é visualmente mais difícil encontrar onde uma nova pasta raiz começa quando várias pastas altamente hierárquicas são abertas e expandidas.

Obrigado pelas atualizações de design, está realmente bom!

Existe a possibilidade de ter vários espaços de trabalho disponíveis ao mesmo tempo na IU? Para que você possa alternar facilmente entre eles. Por exemplo, você tem algo como:

EXPRESS, EXPRESS-PLUGIN
  express/
    lib/
    test/
    package.json
  express-plugin/
    lib/
    test/
    package.json
CONNECT, CONNECT-PLUGIN

E então clicar / clicar duas vezes no divisor CONNECT, CONNECT-PLUGIN mudaria para ter esse como o espaço de trabalho ativo. Isso permitiria alternar facilmente entre os espaços de trabalho para pessoas que precisam lidar com vários conjuntos de projetos. Não estou sugerindo que todos eles estejam disponíveis para pesquisa e SCM e outros enfeites, que permaneceriam com o espaço de trabalho atual, que é o atualmente expandido.

Isso poderia funcionar com o realce das pastas raiz conforme sugerido no primeiro grupo e, talvez, com os novos ícones de arquivo / pasta disponíveis ao passar o mouse sobre essas pastas.

Alguns comentários sobre as configurações JSON, pode ser útil para as configurações do espaço de trabalho ser algo como:

workspaces: [
    {
        name: "Express Project",
        root: "file://C:/workspace/",
        folders: [
            "./express/",
            "./express-plugin/"
        ]
    }
]

Então o root se torna a fonte para abrir as pastas, ao invés do caminho, mas a própria raiz não é aberta, apenas cada pasta. Você não tem uma "pasta primária", mas ainda mantém os caminhos de arquivo relativos. Isso pressupõe que você pode abrir uma área de trabalho predefinida por meio da IU, em vez de abrir a pasta raiz e todas as pastas adicionais com ela. O nome pode então ser usado como divisor, evitando que um grande número de nomes de pastas o torne muito longo ou reduzido de forma desnecessária.

Se a solução "uma seção por pasta raiz" for escolhida, eu gostaria de sugerir que a pasta raiz atualmente visível "grude" no topo da barra lateral, em vez de rolar para fora da vista. Ele só rolaria para cima quando a pasta raiz subsequente atingisse o topo da barra lateral.

Em 4 de junho de 2017, às 6h47, Peter Petrov [email protected] escreveu:

Eu prefiro o design "uma seção por pasta raiz", pelos mesmos motivos listados por @maddouri. Além disso, tendo usado a outra alternativa (no Atom), é visualmente mais difícil encontrar onde uma nova pasta raiz começa quando várias pastas altamente hierárquicas são abertas e expandidas.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub ou ignore a conversa.

Ou podemos seguir a abordagem Sublime, Atom, mas mudar a cor ou de alguma forma mostrar qual pasta é a raiz e / ou colocá-la no topo. Claro que ambas as abordagens são boas, mas ter muitas pastas abertas reduz o espaço, porque a barra com atualização, criar um novo arquivo, etc. ficará visível, por isso é melhor não carregar a barra, mas de alguma forma mostrar qual pasta está a raiz. MAS, novamente, esta barra é muito boa, porque é muito mais fácil ver as pastas raiz abertas e você pode atualizá-las e fazer outras coisas que estão incluídas na barra. Precisamos ver como fica com, por exemplo, 10 pastas abertas com e sem barra.

@stevencl Obrigado por postar essas gravações! No geral, estou animado com a direção que o recurso está tomando! Obrigado por todo o tempo e esforço investidos até agora. Aqui está meu feedback / pensamentos:

  • Eu prefiro o primeiro design com o design de barra de nome de pasta única em "EXPLORER", no entanto, estou preocupado que se todos os nomes de pasta estiverem listados lá, ele ficará rapidamente truncado para mostrar o "adicionar arquivo", " adicionar pasta ", etc., botões. Acho que colocaria a string "Multiple" ou algo semelhante quando mais de uma pasta estiver aberta; caso contrário, haverá apenas uma pasta, então coloque o nome da pasta lá como é feito hoje (e oculte a raiz da pasta na árvore).
  • A desambiguação de nomes de arquivo anexando o nome da pasta no título da guia no Editor, IMO, não é necessária, a menos que haja vários editores abertos com o mesmo nome de arquivo. Observe que esse cenário não é incomum, mesmo com uma única pasta aberta. É muito fácil obter vários arquivos (por exemplo, .gitignore ) com o mesmo nome entre subpastas na mesma raiz. Portanto, este design (anexando o nome da pasta pai) deve ser um recurso separado, IMO, e deve ser implementado. Junto com isso, eu adoraria ver uma boa solução para https://github.com/Microsoft/vscode/issues/15048 porque isso tornará alguns títulos de guia ainda mais longos. :)
  • Para resultados de pesquisa, acho essencial que a pesquisa funcione em todas as pastas raiz. Outro filtro pode ser adicionado para limitar a pesquisa às raízes escolhidas. Ao exibir os resultados, pode ser útil ver os resultados por raiz, então pode ser uma opção para ver uma longa lista com nomes de pasta raiz anexados, ou ver uma lista separada em seções, uma para cada pasta raiz.
  • Acho estranho que você esteja propondo adicionar 'espaços de trabalho' às __configurações do usuário__. Eu realmente esperava que isso acabasse em __configurações do espaço de trabalho__. _Acho_ que você está realmente dizendo que as configurações do espaço de trabalho também podem conter a nova propriedade 'espaços de trabalho', o que é bom. Também é muito bom que os caminhos do espaço de trabalho possam ser relativos. Simplesmente não parece ser algo que pertence às configurações do usuário. É um recurso que parece muito específico para áreas de trabalho. Ah, mas agora vejo por que também é válido nas configurações do usuário, porque me permite armazenar esses espaços de trabalho quando quero pastas "aleatórias" no meu disco rígido em um espaço de trabalho onde não há raiz comum.
  • Uma coisa que parece se perder nos espaços de trabalho quando são armazenados nas configurações do usuário é a capacidade de ter outras configurações específicas do projeto atribuídas a um espaço de trabalho ou outro. Por exemplo, se eu tivesse um espaço de trabalho onde precisasse que o tamanho da guia fosse 2 espaços e outro onde tivesse que ser 3, não seria capaz de fazer isso com espaços de trabalho nas configurações do usuário. Eu teria que criar uma pasta em algum lugar e, em seguida, colocar uma pasta .vscode dentro dela e definir .vscode/settings.json para finalmente definir meu espaço de trabalho com a substituição de tamanho de guia apropriada. Neste ponto, estou pensando que criar um novo tipo de arquivo de projeto VSCode que armazene todas essas configurações e possa ser aberto como um arquivo especial se torna muito menos complicado do que ter que criar essa hierarquia de pastas para armazenar o espaço de trabalho settings.json file ...

No primeiro design, para pastas adicionais, o caminho (relativo ou absoluto) entre parênteses pode ser anexado ao nome para diferenciação. Essa será uma solução simples, eu acho.

@stevencl obrigado por gravar as sessões. Queria muito participar, mas não estava disponível na época 😢

Gostei da interface SCM proposta. Ter uma seção de resumo e a seção Uma por pasta me dá, IMHO, uma interface muito mais fácil de detectar e trabalhar com as alterações. E eu gosto da ideia de ter um comportamento consistente em toda a IU, então a ideia Uma seção por pasta deve ser usada na guia Pesquisar também, em vez de concatenar o nome da pasta em cada resultado. O mesmo para a guia Explorer .

Usar as configurações do smile : additionalFolder _sempre_ parte de Workspace Settings . Fazendo isso, quando você _Adiciona uma pasta_, ela será adicionada apenas a Workspace Settings . Então, ao abrir uma pasta, você apenas procura por .vscode\settings.json file e uma entrada additionalFolders lá, para verificar _se é uma área de trabalho com várias pastas_. _É semelhante ao segundo exemplo que você usou, sobre os dois git repos_ ausentes.

SomeFolder.vscodesettings.json

{
    "editor.wordWrap": "off",
    "editor.codeLens": false,
    "editor.renderWhitespace": "all",
    "workbench.colorTheme": "Abyss",

    "additionalFolders": [
        "./express",
        "./express-plugin",
        "~/commons/other-stuff",
        "file:///C://Temp//oldlib"
    ]
}

Além disso, ofereça suporte a locais de _ dados do usuário_ como ~ e $home , facilitando o compartilhamento de projetos entre diferentes computadores / plataformas.

Perdi apenas um ponto: API . Como as extensões se integrariam a isso?

Obrigado pelo esforço. Ansioso pelos primeiros lançamentos de insiders 👍

Obrigado pelo feedback! Eu queria acompanhar a direção de aproveitar uma nova propriedade de configurações additionalFolders para implementar "Multi Root" porque ouvi alguns comentários sobre isso nos comentários acima.

Em primeiro lugar, a principal motivação para introduzir um ambiente é, na verdade, manter as coisas simples e não introduzir muitos conceitos novos, ao mesmo tempo que temos uma solução poderosa e que permite alguns cenários interessantes. Aqui estão algumas decisões de design e consequências:

Mantenha simples
Sentimos que abrir arquivos e pastas é o cerne do VS Code. Portanto, não gostaríamos de introduzir um novo conceito de nível superior de "Projetos". Por exemplo, não pensaríamos que uma ação "Abrir projeto" fosse necessária, mas sim que um projeto é sempre uma pasta e pode, opcionalmente, ter pastas adicionais associadas. Com essa suposição, um ambiente parece a maneira natural de permitir isso. Sempre que você abre essa pasta, abre as pastas adicionais com ela. Adicionar e remover pastas é um gesto simples e atualizará as configurações diretamente.

As configurações são poderosas
Ter múltiplas raízes como configuração permite muitos cenários interessantes. Por exemplo, você está livre para colocar a configuração additionalFolders em sua área de trabalho e, como tal, compartilhá-la com outras pessoas (usando caminhos relativos - isso é mostrado nos vídeos).
Além disso, você também está livre para configurar projetos em primeiro lugar: por exemplo, em alguns casos não há uma relação clara de uma pasta mestre com pastas adicionais (por exemplo, pode ser que algumas delas não estejam nem relacionadas a entre si). Nesse caso, você pode apenas criar uma pasta "projeto" que inclua apenas settings.json com as pastas vinculadas a:

allMyRandomProjects/ 
  .vscode
    settings.json <- contains additionalFolders setting  

Agora, quando você abrir allMyRandomProjects ele mostrará a lista de pastas com base nas configurações. Você pode até incluir algumas configurações em settings.json que devem ser aplicadas a todas as pastas mostradas.

Troca de espaço de trabalho e várias janelas
Sem dúvida, precisamos trabalhar em uma melhor troca de espaço de trabalho e suporte a várias janelas no VS Code. Como tratamos um espaço de trabalho com várias raízes da mesma forma que qualquer outro espaço de trabalho com uma pasta, melhorar a alternância do espaço de trabalho e o suporte a várias janelas beneficiará qualquer usuário, mesmo aqueles que não estão aproveitando os espaços de trabalho com várias raízes.
Teremos que procurar maneiras melhores e mais fáceis de alternar entre pastas e janelas abertas independentemente de multi-root.

Em meu próximo comentário, fornecerei feedback sobre os comentários individuais feitos.

@borekb search incluiria opções para limitar a uma pasta raiz específica (ou múltiplas) da mesma forma que você pode configurar a pesquisa para incluir um caminho específico hoje.

@maddouri @TurkeyMan @pesho , @dgileadi @stefcameron parece claro que algumas pessoas preferem uma única árvore e outras preferem várias seções no explorador. Então podemos acabar com uma configuração para isso, existem prós e contras para ambas as soluções e deve caber ao usuário qual é a melhor para o cenário.

@borekb como as configurações são aplicadas mudará um pouco dependendo se você está em uma configuração multi-root ou não: as configurações do usuário sempre se aplicam a todas as pastas abertas como antes. As configurações do espaço de trabalho serão obtidas da pasta principal ("master") e aplicadas a todos os arquivos e pastas associados a ela. Agora, você ainda pode definir configurações em qualquer uma das pastas adicionais por meio das configurações do espaço de trabalho, embora possamos não oferecer suporte a todas elas. Por exemplo, uma configuração como update.channel: none não pode ser suportada em uma base por pasta. O que teremos que fazer é identificar as configurações que podemos suportar em um nível de pasta (por exemplo, files.exclude , todas as configurações do editor) e fazer as alterações necessárias para habilitá-las. Essa é uma das principais áreas de trabalho em que devemos investir, especialmente porque as extensões também podem definir configurações que desejamos oferecer suporte em um escopo por pasta.

@BTMorton parece-me que você deseja maneiras mais fáceis de alternar entre os espaços de trabalho. Isso é algo que devemos examinar independentemente de multi-root para qualquer transição de pasta que um usuário possa fazer.

@stefcameron , manteremos a configuração additionalFolders aberta o suficiente para, eventualmente, adicionar metadados adicionais a ela. Por exemplo, eu poderia pensar em ser capaz de fornecer um nome para tal configuração de forma que a alternância entre os projetos seja pelo nome e não pela pasta principal.

Uma coisa que ainda não tocamos nos vídeos é como as extensões podem suportar pastas multi-root. Outro objetivo principal com suporte multi-root (além de "mantê-lo simples") é: não quebre as extensões

Hoje, as extensões têm API simples para obter acesso ao espaço de trabalho aberto atualmente ( workspace.rootPath: string ). Esta propriedade pode ser null caso nenhuma pasta seja aberta.

Agora, com a introdução da configuração additionalFolders , uma extensão ainda pode contar com a propriedade workspace.rootPath sendo definida (se uma pasta for aberta), ou não (quando nenhuma pasta for aberta). Como additionalFolders é na verdade uma configuração, uma extensão é gratuita para ler e até mesmo gravar nessa configuração com as APIs que já temos hoje em torno das configurações. Há até mesmo um evento emitido quando esta configuração muda, permitindo uma reação dinâmica ao usuário alterando esta configuração.

Ler esta configuração permite que uma extensão fique ciente de pastas adicionais na área de trabalho. Por exemplo, a extensão do Travis CI pode escolher mostrar um status agregado em todas as pastas.

Escrever esta configuração permite alguns cenários interessantes para extensões: por exemplo, você pode ter uma extensão do gerenciador de projetos que adiciona e remove pastas dinamicamente para o seu espaço de trabalho e, como tal, permite transições de projeto dentro da janela, por exemplo, mostrando uma lista de projetos por meio de um seletor de IU .

Em um ponto, provavelmente apresentaremos alguma nova API de extensão real para lidar com pastas multi-root. Enterrar isso dentro de uma configuração para extensões de leitura / gravação é um pouco estranho. Mas, para começar, as extensões já podem explorar a configuração additionalFolders para aproveitá-la, se possível. Também trabalharemos em estreita colaboração com os autores de extensão para compreender seus cenários e como melhor apoiá-los.

@bpasero O conceito de pastas adicionais também será adicionado ao LSP ou o VS Code simplesmente iniciará um servidor de idioma por pasta adicional?

@felixfbecker isso é algo que ainda temos que investir e explorar para encontrar uma boa solução para extensões de linguagem. Assim que pensarmos em APIs adicionais para extensões, também precisamos pensar sobre o que isso significa para o LSP.

Porém, vale a pena mencionar que hoje você já pode ter situações em que os usuários abrem um arquivo de uma pasta que não está aberta como área de trabalho (por exemplo, Arquivo> Abrir> algumarquivo.xyz). Idealmente, uma extensão de idioma pode mostrar o mesmo nível de recursos de idioma para esse arquivo, mesmo se a pasta desse arquivo não estiver aberta.

No início, abrir um arquivo de um dos additionalFolders se comportaria de forma muito semelhante a abrir um arquivo que não está na pasta que você abriu inicialmente. O TypeScript, por exemplo, pode lidar bem com este caso: eles simplesmente caminham do arquivo aberto atualmente até que um arquivo tsconfig.json seja encontrado e então tratam isso como um projeto. Recursos como encontrar referências funcionam sem problemas:

image

Seria bom se qualquer extensão de idioma pudesse funcionar apenas indo do arquivo ativo no momento em vez de forçar um contexto de projeto explícito.

@bpasero obrigado pelos comentários. Portanto, parece que no modelo atual, sempre haverá uma pasta "master" : mesmo no exemplo allMyRandomProjects , esta é basicamente a pasta master, embora quase toda vazia. Isso tem algumas implicações sutis, mas preciso pensar um pouco mais para fornecer um feedback útil.

No geral, acho que o VSCode deve oferecer suporte a monorepo em comparação com vários repositórios de maneira bastante semelhante, conforme o comentário acima: https://github.com/Microsoft/vscode/issues/396#issuecomment -306040485.

BTW, como você define "root", exatamente? Se eu abrir a pasta A que contém as subpastas B e C, quanto é diferente de definir A como path e B e C como additionalFolders ? A intenção do VSCode é tratar essas duas situações de maneira bastante diferente ou basicamente a mesma? (Acho que deve ser uma experiência muito semelhante.)

@bpasero

No início, abrir um arquivo de uma das pastas adicionais se comportaria de forma muito semelhante a abrir um arquivo que não está na pasta que você abriu inicialmente. O TypeScript, por exemplo, pode lidar bem com este caso: eles simplesmente caminham do arquivo aberto atualmente até que um arquivo tsconfig.json seja encontrado e então tratam isso como um projeto. Recursos como encontrar referências funcionam sem problemas:

No entanto, o TypeScript não usa LSP. No LSP, os servidores de linguagem têm um rootUri e, por exemplo, o PHP usará esse rootUri para procurar arquivos que precisam ser indexados. Ele não tem um arquivo como tsconfig.json que denotaria um "projeto". Portanto, se houver arquivos que não são abertos por meio de didOpen mas também não por meio de rootUri , eles não seriam considerados para inteligência de código, por isso minha pergunta se o LSP será estendido para isso.

Só para esclarecer, abrir raízes múltiplas criaria um arquivo ./.vscode/settings.json se ele ainda não existisse?
Pelo que li aqui até agora, parece que estamos dizendo que sim.

Eu entendo porque é útil evitar adicionar o conceito de projetos, mas talvez seja bom tornar opcional o salvamento de uma área de trabalho - embora, neste caso, 'salvar' signifique apenas criar um arquivo de configurações na pasta raiz.

Acho que pode surpreender um usuário que não tem seguido este tópico se abrir uma segunda pasta e criar um arquivo de configurações. Abrir pastas é o tipo de coisa que acredito que a maioria dos usuários espera que seja somente leitura.

Obrigado por todos os comentários a todos, isso é muito útil.

@saborrie - boa pergunta sobre até que ponto as pessoas ficariam surpresas com a criação de uma configuração ao adicionar uma pasta. Precisamos investigar isso para ver se é esse o caso (obviamente, com pessoas que não têm seguido este tópico :-)).

@borekb - falamos sobre o cenário que você mencionou (abrir uma pasta que contém uma ou mais subpastas) e temos tentado tratar isso da mesma forma que abrir um espaço de trabalho com várias raízes. O desafio, porém, é determinar quando tratar tal situação como multi root e não apenas uma pasta que contém outras pastas.

Eu também estaria interessado no que os outros pensam sobre isso.

@borekb você trouxe um bom ponto, eu também diria que se você abrir uma pasta que contém vários repositórios git dentro, nossa visão SCM deve ser capaz de mostrar a você a mesma visão que você teria se configurasse explicitamente por meio do additionalFolders propriedade. Acho que podemos começar a explorar essa evolução da IU com pastas que têm a configuração additionalFolders definida e, posteriormente, expandi-la para mais casos de uso. Outro cenário interessante e relacionado é como escolhemos apresentar submódulos em um repositório.

Eu também acho que, eventualmente, queremos oferecer suporte às configurações de .vscode em qualquer nível de hierarquia de pasta, uma vez que tenhamos resolvido os desafios que vêm com isso.

Eu falaria menos sobre o relacionamento master-details ao falar sobre multi-root porque a maior parte da UX tratará a pasta principal igual às pastas adicionais. A pasta mestre é realmente apenas o contêiner das configurações para pastas adicionais e será o principal driver para as configurações globais do espaço de trabalho. Para compatibilidade com versões anteriores, também será o que enviamos para extensões como rootPath .

@felixfbecker significa que não posso fazer um "Localizar referências" ou recursos de linguagem semelhantes ao abrir apenas um arquivo PHP do meu projeto, preciso abrir essa pasta para obter esses recursos? Não estou muito interessado em PHP, mas se houver um conceito de dependências de arquivos cruzados, não seria capaz de navegar para outro arquivo PHP a partir de apenas um único arquivo. Preciso abrir a pasta primeiro?

@saborrie , NÃO adicionaríamos uma configuração de espaço de trabalho por padrão ao adicionar pastas. Uma das razões pelas quais decidimos colocar isso nas configurações do usuário é para que um espaço de trabalho não fique "sujo" com a configuração de várias raízes. É possível colocar essa configuração na área de trabalho, mas você precisará fazer isso manualmente. Isso não vai acontecer por padrão.

@bpasero Ok, sim, manter o salvamento nas configurações do usuário em vez das configurações da área de trabalho evitaria a sujeira das pastas da área de trabalho - estou supondo que ainda salvaria antes de exigir que o usuário explicitamente execute uma ação de salvamento, sim?

Isso me deixa com duas perguntas de acompanhamento:

1) O que aconteceria quando um usuário abre um espaço de trabalho com additionalFolders definido em suas configurações de espaço de trabalho? Isso seria sincronizado com as configurações do usuário? e substituiria a entrada para aquela raiz do espaço de trabalho se ela existisse na lista de espaços de trabalho de configurações do usuário? Ou vice-versa?

2) Colocar esta lista de espaços de trabalho nas configurações do usuário é uma opção melhor do que evitar inicialmente o armazenamento de espaços de trabalho em qualquer um desses arquivos de configuração JSON? No sistema de pasta única atual, quando uma pasta é reaberta a partir do item de menu File > Open Recent , as guias que foram abertas anteriormente são lembradas - pelo que eu posso dizer, isso não está sendo armazenado em nenhum usuário - arquivo de configurações editáveis, os caminhos adicionais não poderiam ser armazenados da mesma maneira, até que um usuário os salve explicitamente?

- Desculpem o inglês, usei o Google Translator -

Bem, eu revi o layout, (sim - um pouco de dificuldade em entender inglês). Desculpa, então...

Não gostei do layout apresentado por @maddouri , principalmente devido aos problemas encontrados nesta edição (# 25352, # 25354). Acho que será mais complexo mesmo se você tiver que usar o teclado para acessar as pastas no modelo exibido.

Eu prefiro este modelo, que pela ideia posso navegar entre as diferentes pastas do projeto usando as teclas de seta e se eu precisar criar uma pasta / arquivo na pasta principal, posso usar a tecla de menu no teclado, direto no principal pasta.

explorernew

E / ou com as opções de novo arquivo, nova atualização de pasta e Recolher tudo.

explorernew2

Quanto ao título que aparece no topo, prefiro que foque no arquivo atual com a pasta em que se encontra, ou em vez de mostrar todas as pastas principais abertas mais o arquivo atual, semelhante a esta imagem.

explorernew3

E uma pergunta: ainda existirá Open Editores?

@bpasero

isso significa que não posso fazer um "Localizar referências" ou recursos de linguagem semelhantes ao abrir apenas um arquivo PHP do meu projeto, preciso abrir essa pasta para obter esses recursos? Não estou muito interessado em PHP, mas se houver um conceito de dependências de arquivos cruzados, não seria capaz de navegar para outro arquivo PHP a partir de apenas um único arquivo. Preciso abrir a pasta primeiro?

Isso é correto, se você apenas abrir um único arquivo, você não pode ir para a definição de um arquivo em um arquivo diferente que não está aberto, mas apenas para aqueles abaixo de rootUri . Isso porque no PHP cada arquivo pode despejar símbolos no namespace global, e os namespaces são, na verdade, apenas prefixos de nome para classes. Não há restrição sobre como os namespaces e nomes de classes precisam corresponder aos diretórios e nomes de arquivos (apenas algumas convenções) e não há instruções de importação como no TS, apenas aliases de namespace. O carregamento de classes acontece em tempo de execução por meio de "carregadores automáticos" registrados. Isso significa que para um servidor de linguagem em go-to-definition, um símbolo pode ser definido em qualquer arquivo. Portanto, o servidor de idioma indexará todos os arquivos em rootUri na inicialização e trabalhará com o índice para responder às solicitações. O que funciona é se você tiver um projeto aberto e criar um novo arquivo não salvo - você obterá inteligência para isso, porque você obteve rootUri e o novo arquivo por meio de textDocument/didOpen . Mas quaisquer símbolos definidos em arquivos não abertos que não sejam em rootUri não serão considerados.

As configurações do espaço de trabalho additionalFolders dentro da área de trabalho sempre tem precedência. Porém, dada a natureza desta configuração, você só pode substituir as AdditionalFolders para a pasta aberta no momento quando esta configuração for especificada dentro da área de trabalho (isso é mostrado nos vídeos por ter path: "." para o "mestre").

Ter isso como estado da IU armazenado de forma semelhante a, por exemplo, quantas guias são abertas foi uma opção que discutimos, mas não achamos que tenha muitas vantagens sobre uma configuração. Algumas razões:

  • isso não é compartilhável (nem por meio da configuração do espaço de trabalho, nem por meio de uma extensão de sincronização de configurações)
  • isso não é algo que as extensões podem acessar facilmente hoje (API de configurações existe, API de estado da interface do usuário não)

Há algum motivo específico para você não querer essas configurações internas?

@Tekbr sim, "Editores Abertos" funcionará como antes

@felixfbecker seria a extensão PHP capaz de adotar algo como rootUri: string[] facilmente? Ou você prefere que o servidor de linguagem PHP inicie várias vezes para cada pasta aberta (por exemplo, o VS Code seria multiplex no nível de pastas abertas para servidores de linguagem N?)

@bpasero PHP pode trabalhar com rootUris: string[] facilmente. Porém, outros servidores de idioma não podem. Gerar servidores em vários idiomas significaria que cada pasta funcionaria isolada (sem pular para definição, localizar todas as referências entre elas). Talvez uma abordagem seria um novo ServerCapability que decide se o VS Code irá gerar um ou vários servidores de idioma.

Eu gosto do conceito de configuração de pastas adicionais. Para mim, basta ter uma única pasta raiz. Se eu quiser funcionalidade de desenvolvimento completa em um projeto associado, posso abrir uma nova janela vscode.

O que preciso das pastas adicionais é apenas uma funcionalidade limitada. Por exemplo, posso querer uma definição de símbolo de um projeto associado para uso no projeto raiz, mas não preciso ou quero a capacidade de renomeá-lo ou encontrar todas as referências para ele na pasta adicional.

@bpasero Estou apenas defendendo a consideração de tornar opcional a criação de um espaço de trabalho nas configurações (e opt-in). Essencialmente, em vez de alterar as configurações automaticamente quando um usuário adiciona uma pasta, comece com ela apenas no estado da IU e, em seguida, permitindo que os usuários salvem isso nas configurações de alguma forma. Talvez também permitindo a escolha de entrar nas configurações do espaço de trabalho ou nas configurações do usuário.

Não sou totalmente contra o armazenamento totalmente em configurações, estou apenas fazendo minha parte para questionar a decisão de não usar o estado da IU, apenas no caso de ter sido esquecido.

@bpasero @saborrie Se

# 396 (comentário)

@Tekbr sim, "Editores Abertos" funcionará como antes

Obrigado pela resposta, @bpasero.

TL; DR: Use uma visualização em árvore sempre que fizer sentido, em vez de anexar o nome das raízes a cada item.

Poucas coisas, eu realmente não gosto da maneira como você anexa a pasta no final, eu realmente gostaria que fosse uma opção porque provavelmente gostaria de tê-la assim express\.editorconfig e express-plugin\.editorconfig então talvez você possa oferecer a seguinte opção: editor.tabName: "${root}\${filename}"

Outra coisa que eu gostaria e que você mencionou no vídeo é a coloração sobre as raízes para combinar com as guias então 👍 para isso.

Pesquisa:

Na visão Search eu realmente acho que você está cometendo um erro no que diz respeito à experiência, na minha opinião, ela deveria ser exibida como uma árvore, assim:

[-] express
    [v] file1.ext
         ... expression ... 
    [v] file2.ext
         ... expression ... 
[-] express-plugin
    [v] file1.ext
         ... expression ... 
    [v] file2.ext
         ... expression ... 

As razões para isso são:

  1. Você pode ver facilmente onde estão os arquivos, independentemente do comprimento de seus nomes.

  2. Você pode recolher as raízes que não quer ver.

Acho que também se ajusta mais ao tipo de design que você aplicou ao Explorer .

Tarefas:

Por Tasks , prefiro ter este tipo de visão:

express
    Compile
    Run Tests
express-plugin
    Compile
    Run Tests

Poucos pontos:

  1. Na minha opinião, você não deve tocar / alterar os nomes das pastas, o que significa que "express-plugin" deve ser exibido exatamente como é exibido no Explorer e não como "Express Plugin".

  2. A movimentação entre as tarefas com o teclado também pode ser feita de forma que ignore a seleção das raízes, portanto, se você descer de express\"Run Tests" no exemplo, o próximo item que será selecionado é express-plugin\Compile as oposto a express-plugin

ps Não vi o vídeo completo ainda, mas essas coisas que me vieram à mente.

E se todas as pastas raiz incluídas em sua área de trabalho tiverem o mesmo nome?
por exemplo

  • / dev / project / public / src
  • / dev / framework / src
  • / dev / algum-componente / src

Você teria então um espaço de trabalho com:

[+] src\
[+] src\
[+] src\

De acordo com a maneira _sublime_ de incluir pastas em um espaço de trabalho, cada raiz de pasta virtual tem:

  • Caminho
  • Nome (opcional) - este é o nome da pasta, se excluído, mas pode ser exibido como qualquer coisa
  • Filtro de exclusão para arquivos / pastas

Consulte a nota https://github.com/Microsoft/vscode/issues/396#issuecomment -283541760 (acima) para obter um exemplo dos metadados associados a essa maneira de fazer as coisas.

Gostaria de saber que este recurso ainda está em fase de desenvolvimento?

@ifzm É, e se você ler as notas de lançamento mais recentes (maio de 2017 (versão 1.13)), saberá que eles estão trabalhando ativamente nisso.

@eyalsk Desculpe, não olhei com atenção, este é um recurso interessante: D

Não sou louco pelo conceito additionalFolders , embora entenda o desejo de manter as coisas simples.

Parece-me estranho que uma das pastas armazene a configuração da "área de trabalho".

Imagine as seguintes pastas raiz:

  • local na rede Internet
  • api
  • Móvel

... qual pasta deve conter a configuração additionalFolders ? Por quê?

Eu prefiro a ideia de um espaço de trabalho / gerente de projeto, onde as configurações são armazenadas em um local compartilhado / geral. Eu realmente não acho que isso seja complicado de uma perspectiva de UX, e a terminologia workspace poderia ser reutilizada / estendida.


Não relacionado: concordo totalmente com os comentários de @eyalsk sobre listas aninhadas (e nomes de guias).

@ glen-84, nesse caso, você está livre para ter uma quarta pasta no disco chamada "my-mobile-website-project" que tem essa configuração e links para todas as outras pastas.

@bpasero Eu entendo isso, mas é apenas um hack.

Para elaborar:

Estou ocupado trabalhando em website e decido que quero fazer algumas alterações em api . Se eu clicar em Add Folder , ele vai associar api com website , de forma que abrir website no futuro abrirá api também. Preciso entender como isso funciona e, quando o fizer, tenho que abrir uma instância separada do VSC, criar uma pasta vazia com o nome apropriado, adicionar as duas pastas "projeto" a ela e, em seguida, fechar a instância inicial.

Em contraste, eu poderia simplesmente ir Add Folder e ele poderia (opcionalmente) solicitar um nome de área de trabalho para usar no futuro para abrir as duas pastas ao mesmo tempo.

workspaces.json (exemplo)

{
    "workspaces": {
        "My company workspace": {
            "folders": {
                "/path/to/website": {
                    "folder-setting1": "value1"
                },
                "/path/to/api": {
                    "folder-setting1": "value1"
                }
            },
            "settings": {
                "workspace-setting1": 123
            }
        }
    }
}

Eu apenas me sinto mais flexível e menos estranho para mim.

@ glen-84 compreendido. seguir sua solução proposta torna o uso do VS Code mais complexo, é por isso que optamos por esse conceito não. O principal motivo é que, de repente, não há apenas "Abrir arquivo" e "Abrir pasta", mas também "Abrir projeto". Ficar com os primitivos que temos é a abordagem mais direta, sem introduzir novos conceitos.

Dito isso, todo o trabalho que fazemos agora para oferecer suporte a várias pastas é um bom trabalho também para cenários como o que você propôs. Se quisermos oferecer suporte ao seu cenário, as etapas para chegar lá são muito menos pesadas porque a IU já está adequada para isso. Eu também poderia imaginar que talvez uma extensão pudesse introduzir essa noção de espaços de trabalho e nós apenas adicionamos as APIs necessárias para oferecer suporte a isso.

Vamos primeiro acertar a UX sem introduzir novos conceitos e, em seguida, pensar em outros cenários em torno de pastas múltiplas. Há muitas coisas a serem examinadas primeiro (extensões, configurações, interface do usuário SCM, etc.).

sua solução proposta torna o uso do VS Code mais complexo

Tenho de discordar com isso. Se um usuário estiver confuso com um recurso opcional "Open Project" (ou área de trabalho), é provável que ele se confunda com muitos recursos existentes no VSCode. Isso não é complicado da perspectiva do usuário (se alguém lendo isso discordar, por favor, diga).

Eu também poderia imaginar que talvez uma extensão pudesse introduzir essa noção de espaços de trabalho e nós apenas adicionamos as APIs necessárias para oferecer suporte a isso.

A extensão já existe e já foi mencionada algumas vezes. O autor ainda tem um suporte para várias pastas de rastreamento de tíquete aberto . Esta extensão tem mais de 370 mil instalações e uma classificação de 4,7. Mesmo com uma IU simplista utilizando a paleta de comandos, há poucos sinais de confusão a julgar pelos comentários.

Vamos primeiro acertar a UX sem introduzir novos conceitos e depois pensar em outros cenários em torno de pastas múltiplas

Isso é bastante justo. De qualquer forma, trata-se de suportar várias pastas raiz na mesma janela - o método real de gerenciamento desses grupos de pastas pode ser abordado em um estágio posterior.

Você consideraria criar uma enquete pública para coletar as opiniões dos usuários sobre o assunto (conheço os vídeos do YouTube, mas estou me referindo a esse aspecto por conta própria), ou já foi decidido usar o additionalFolders Conceito de

Eu concordo com @ glen-84. Não entendo a questão da complexidade. Sim, pode torná-lo mais complexo, mas este é um editor de código. Eu acho que são 95% dos programadores que estão usando, o que poderia facilmente entender a ideia de projetos. Deve haver pouca preocupação em confundir as pessoas todos os dias, porque todos os dias as pessoas não o usam.

Embora uma extensão seja uma espécie de solução, as extensões também são de segunda categoria em comparação com melhorias implementadas nativamente (ou seja, não é possível adicionar opções aos menus, apenas à paleta de comandos, etc.).

@ glen-84 foi tomada a decisão de ir com a configuração additionalFolders base no sentimento da equipe de desenvolvimento, estudos de usuário que fizemos (aqueles 2 vídeos) e feedback que recebemos nesta edição.

@pltrant torna o uso de multi-root mais complexo porque você tem que pensar constantemente em abrir uma pasta ou abrir um projeto. Coisas como "Abrir recente" de repente exigiriam mais atenção se a entrada escolhida fosse uma pasta ou um projeto, ou pior, você ainda teria 2 seletores e teria que decidir qual usar.

Não tenho certeza de como ter uma configuração é mais complexo. Você basicamente não precisa se preocupar com a configuração, basta adicionar e remover pastas em sua configuração e a configuração será atualizada em segundo plano. Eu diria que você nunca olha para o valor dessa configuração na maioria dos casos.

@ glen-84 Com relação ao seu exemplo de projeto com 3 pastas de mesma importância, acho que qual delas deve conter as configurações additionalFolders deve ser decidida pela dependência. Se a pasta API não depender de outro projeto, quando for aberta, deve ser aberta como uma única pasta e não deve conter nenhuma configuração adicional de pastas. Mas quando você abre a pasta móvel , acho que depende da pasta API. Portanto, você adiciona as configurações na pasta móvel para abrir a API como uma pasta adicional quando aberta no vscode. O mesmo vale para o site. Se for dependente da API, adicione configurações lá. Caso contrário, nenhuma configuração necessária.

Não acho que haverá abertura de pasta adicional recursiva ou em cascata. Eu também gosto da ideia de extensões ler outros formatos de projeto como Visual Studio Solutions e sugerir / colocar configurações adicionais de pasta no lugar. E você sempre pode abrir a pasta pai comum de todos.

@stevencl assistiu aos dois vídeos.

  1. A alternativa 2 com a desambiguação parece a mais clara. Parece que isso poderia ser dobrável (ou seja, uma das raízes da árvore), o que permitiria que muitos projetos fossem vistos ao mesmo tempo. Se você precisar de uma maquete, me avise.

  2. A alternativa 2 é mais eficiente do ponto de vista do estado real da tela. Você não terá a mesma informação (nome do projeto) repetida no topo - como na opção 1 e mostrada na raiz de cada projeto.

  3. Os resultados de pesquisa e o Git podem se comportar da mesma maneira ... como uma árvore recolhível. Os resultados seriam agrupados (junto com w / status) sob o título apropriado. Eu acho que se você quiser um resumo navegável (como você mostrou para o GIT, essa seria uma opção que poderia existir na pesquisa (quantos arquivos você encontrou) e na área do projeto (isso poderia abrigar os botões de ação).

Portanto, em resumo, sou um fã das raízes recolhíveis individuais com a possível adição do resumo navegável. Uma espécie de combinação da Alternativa 2 e este exemplo

Espero que, independentemente do que vocês escolham, tornem a experiência semelhante nos vários mecanismos. Você diz que havia duas alternativas, mas na verdade existem quatro, já que GIT e Pesquisa eram diferentes. Estou concordando com quem fez este comentário

Re: compartilhamento das informações do multiprojeto. Eu acho que seria útil - como você entendeu, seria razoável para começar - eu faria apenas usar tarefas de gole - ou tarefas que o VS Code pudesse entender.

Obrigado por todo o seu esforço nisso.

A implementação do espaço de trabalho multi-root está sendo monitorada em # 28344 e neste marco de junho.

@gulshan ,

Pode haver casos em que não há dependências. Por exemplo, se estou trabalhando em website e decido adicionar mobile para trabalhar ao mesmo tempo. Não há dependências entre os dois, mas agora website se torna o "pai". Se eu estivesse trabalhando primeiro em mobile , então ele se tornaria o pai. É um pouco arbitrário. As pastas também podem ser para projetos completamente não relacionados.

De qualquer forma, eu respeito a decisão dos desenvolvedores do VSC, mesmo que não concorde necessariamente com ela.

Obrigado por todos os comentários contínuos. Conforme mencionado acima, estamos acompanhando o trabalho na edição # 28344. Levaremos em consideração esses comentários enquanto continuamos a trabalhar nisso, especialmente ao projetar a experiência de SCM. Conforme foi discutido nos vídeos e mencionado acima várias vezes, queremos obter consistência ao longo da experiência.

Em relação ao problema de complexidade que @ glen-84, @pltrant e outros levantaram, obrigado pelas sugestões e respostas detalhadas. Entendemos o feedback e continuaremos monitorando isso enquanto trabalhamos no recurso.

A discussão em torno disso foi muito útil e nos deu algumas coisas em que pensar para o nosso design atual. Por exemplo, talvez devêssemos considerar permitir que os usuários escolham a pasta 'principal' ao adicionar uma segunda pasta a um espaço de trabalho. Talvez solicitemos isso quando o espaço de trabalho for fechado, talvez seja uma configuração. Muitas coisas em que pensarmos para agilizar a experiência.

Como @bpasero menciona, porém, sempre

Além disso, uma vez que algo está no VS Code, é muito mais difícil removê-lo (com o tempo as pessoas se acostumam e dependem dele). Portanto, gastamos muito tempo considerando cuidadosamente o que adicionamos ao VS Code e apenas adicionamos algo quando estamos confiantes de que o custo de adicionar novos conceitos valerá a pena. Portanto, agora, queremos determinar o quão bem-sucedido pode ser um design para multi-raiz que não adiciona novos conceitos.

Mais uma vez, obrigado pelo feedback incrivelmente valioso. Sem um diálogo como esse, seria muito mais difícil tentar projetar essa experiência.

Incrível como todos vocês da equipe são atenciosos e receptivos; é muito apreciado!

O que provavelmente não foi dito ainda com relação à complexidade é que você está adicionando alguma de qualquer maneira. Acho que essas duas opções são discutidas atualmente:

  1. Projetos explícitos.
  2. Algo que parece várias pastas simples, mas na verdade não é - há um conceito importante de uma pasta primária que se refere a coisas como rootUrl para extensões e possivelmente outras coisas (herança de configurações de espaço de trabalho, por exemplo). Acho que, normalmente, o usuário do VSCode precisará entender esse conceito e talvez seja mais fácil ser claro e direto sobre ele, em vez de tentar abstraí-lo.

Na verdade, eu prefiro a terceira maneira, sem realmente apresentar nada de novo, apenas lidar com coisas como vários .git repos e pesquisas e tarefas e coisas assim de uma forma transparente - mais ou menos como os primeiros dois terços dos vídeos sugerido (gostei muito dos wireframes). No entanto, percebi que rootUrl precisa ser considerado para extensões, o que é provavelmente a principal razão pela qual isso é complicado.

Se não fosse por rootUrl , eu apenas começaria com as atualizações da IU conforme proposto nos wireframes mais a persistência local do espaço de trabalho multi-root, da mesma forma que todas as outras pastas são persistidas em "Abrir recente".

Gostaria de repetir que, do meu ponto de vista, o estado ideal é onde o VSCode trabalha com várias pastas, independentemente de serem raízes SCM ou não (monorepo vs. vários repositórios, veja acima). Acredito que os wireframes propostos mais algum trabalho de núcleo extra como herdar configurações de .vscode seriam suficientes para "v1" de suporte multi-root. "Projetos" ou "pastas principais + adicionais" podem vir mais tarde, IMO. No entanto, o que estou dizendo pode cair em rootUrl , não tenho certeza sobre isso, só quero transmitir meu sentimento geral sobre isso.

É ótimo que você esteja tentando resolver este problema difícil e manter a simplicidade o máximo possível!

Eu tenho um projeto de nó de back-end e front-end e tenho 2 editores do VisualCode abertos, o que é um desgaste significativo de recursos.

Assisti aos dois vídeos e concordo com o comentário acima de que esses projetos múltiplos não precisam ter nada a ver um com o outro. Talvez um pudesse ser um projeto nodejs enquanto o outro fosse C ++.

Não gostei da ideia de um dos projetos se tornar o projeto "mestre", com os projetos adicionais adicionados. Cada projeto deve ser igual e não relacionado.

Eu esperava conseguir abrir uma pasta e depois abrir outra pasta (não ADD). A pasta será simplesmente adicionada como no vídeo 1, com as raízes apenas aparecendo (mas mostram caminhos completos em uma dica de ferramenta ao passar o mouse sobre a pasta raiz). Esses projetos não teriam nenhuma relação. Selecionar um ou outro causaria uma troca de contexto. Seria como se eu estivesse alternando entre 2 instâncias do Visual Code, ambas as configurações, esquemas de cores e tudo o mais.

A maneira de persistir esses vários projetos seria salvá-lo como um novo arquivo de projeto, que referencia os outros dois projetos, mas sem modificar nenhum dos 2 projetos em si. Em outras palavras, os 2 projetos permanecem independentes, autossuficientes e desconhecem o terceiro projeto (arquivo de configurações) que os referencia.

Uma vez que este terceiro arquivo é salvo / criado, deve ser possível criar configurações que substituam as configurações do projeto A e B. As configurações não criadas dependerão novamente do projeto ativo.

Ao compartilhar o projeto, um pode compartilhar o arquivo do projeto que faz referência aos outros dois. Quando eles estão ausentes do sistema de arquivos, mas contêm uma referência aos seus urls do github, ele deve perguntar ao usuário se deseja buscá-los (por padrão, como uma subpasta na raiz desse arquivo de projeto mestre, mas o usuário pode procurar por um localização para cada).

A capacidade de pesquisar em vários projetos deve ser opcional, e a capacidade de executar e depurar vários projetos simultaneamente seria muito útil, mas parece realmente muito complexo para uma primeira versão e talvez tal caso de uso deva exigir a execução de 2 instâncias de qualquer maneira. Pelo menos por enquanto.

A aparência disso na IU é a etapa dois, mas funcionalmente é como eu esperava que funcionasse. Não gosto da ideia de modificar o projeto A para fazer referência a B ou vice-versa, e foi isso que entendi ser a intenção. Para o desenvolvedor Agile, eu ficaria feliz se pudesse trabalhar em 2 projetos em 1 janela, em vez de ter que executar 2 instâncias, mas não mais do que isso por enquanto. Talvez nem mesmo com o terceiro arquivo de projeto de substituição, mas apenas com a troca de contexto.

Obrigado pelo feedback contínuo. Existe um tema definido sobre o atraso da persistência de uma área de trabalho com várias pastas até alguma ação explícita do usuário (como salvar). Precisamos pensar mais sobre isso e investigar mais.

Eu também sugiro que os desenvolvedores dêem uma olhada no Eclipse IDE para saber como
lida com essa funcionalidade, eles descobriram há muito tempo e funciona
ótimo.

Na terça-feira, 13 de junho de 2017 às 9h11, Steven Clarke [email protected]
escrevi:

Obrigado pelo feedback contínuo. Existe um tema definido sobre
atrasar a persistência de um espaço de trabalho com várias pastas até que algum
ação do usuário (como salvar). Precisamos pensar mais sobre isso
e investigar mais.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-308110390 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAQsBWywBoe2KQRGuXKHv179MmugstCfks5sDop7gaJpZM4Gm3nX
.

-
Daniel Sokolowski
arquiteto técnico

Stantive Technologies Group Inc.
Telefone: +1 (613) 634-7410
http://www.stantive.com

Aviso de Confidencialidade:
As informações transmitidas destinam-se apenas à pessoa ou entidade a
que é endereçado e pode conter informações confidenciais e / ou privilegiadas
material. Qualquer revisão, disseminação de retransmissão ou outro uso de ou
tomar qualquer ação com base nessas informações por pessoas ou
entidades que não sejam o destinatário pretendido é proibido. Se você recebeu
isto é um erro, entre em contato com o remetente imediatamente por meio eletrônico de retorno
transmissão e, em seguida, exclua imediatamente esta transmissão, incluindo todos
anexos sem copiar, distribuir ou divulgar os mesmos.

Projeto Mestre
Sou contra ter um projeto MASTER. A troca de contexto ocorre frequentemente ao trabalhar com microsserviços diferentes. Isso se aplica aos seguintes pontos sobre Linting e SCM.

Persistência de espaço de trabalho
Acho que na primeira iteração, não devemos ter que persistir no espaço de trabalho. Eu preferiria iterações em uma ou duas versões para este recurso antes de introduzirmos quaisquer configurações ou camadas de persistência para minimizar quaisquer tipos de migrações complexas ou destrutivas.

Linting / Configurações
O linting específico do projeto deve ter namespaces para arquivos nos diretórios correspondentes. Por exemplo, o Projeto A usa mais bonito, enquanto o Projeto B usa o padrão. A alternância entre os dois contextos deve ser perfeita, sem regras conflitantes entre si.

Pesquisa
Adorei alguns wireframes para este onde os resultados da pesquisa estavam em todos os projetos e classificados por projeto.

_Project A_
file1: matched substring
file2: matched substring
...

_Project B_
file3: matched substring
file4: matched substring

SCM
Neste caso, estou mais inclinado a mostrar uma divisão por projeto com cada mudança de scm.

_Project A_
file1: added
file2: removed
...

_Project B_
file3: moved
file4: added
file5: added

Eu sinto que essas abordagens são mais transparentes e intuitivas.

O consenso (com base em comentários recentes e outras questões) parece ser contra a ideia de additionalFolders , pelo menos na versão inicial.

Embora eu entenda que a decisão já foi tomada, você consideraria tentar implementar esse recurso como um conjunto de APIs, deixando a persistência para uma iteração posterior? Portanto, APIs para adicionar / abrir pastas e atualizações para o explorador, pesquisa, tarefas e visualizações de SCM para oferecer suporte a isso.

Você falou sobre como é difícil remover algo do produto (se um conceito de projeto / espaço de trabalho falhar de alguma forma), mas a realidade é que isso se aplica igualmente (se não mais) ao conceito additionalFolders .

Implementar additionalFolders e "projetos / espaços de trabalho" como extensões permitiria a você coletar dados de uso sem se comprometer com um único modelo. Uma dessas extensões (ou uma solução híbrida) poderia ser posteriormente integrada ao produto.

Os problemas com o ambiente foram corrigidos no Mac OS? Ainda não consigo usar o npm Homebrew sem abrir o VSCode na linha de comando por meio de code e isso causará confusão com o suporte a várias raízes, certo?

Sim, isso é obrigatório para mim também. Eu não entendo os problemas das pessoas com isso. Pode não ser a maneira como uma pessoa trabalha, mas isso não significa que o gerenciamento de espaço de trabalho preferido de outra pessoa seja menos válido. Eu simplesmente odeio respostas do tipo "Por que você quer fazer isso?" em vez de "Vamos descobrir como adicionar um recurso que todos os outros editores de código do mundo possuem".

De volta ao Atom, eu acho.

@saborrie https://github.com/Microsoft/vscode/issues/24961 (recebo o mesmo problema em versões internas e regulares). Se eu puder ajudar a depurar, estou no jogo.

@akutz, esses caras se

Olá @cliffrowley ,

Ótimo ouvir isso. Recentemente, dei outra olhada no VSCode, pois tenho usado o Atom desde sempre (e o Sublime antes disso). Recentemente, o Atom tem sido problemático e em um tópico do Reddit vi que o VSCode era realmente uma ótima opção nos dias de hoje. Fiquei surpreso ao ver que ele não era compatível com um recurso básico.

Apenas continuando aqui - este é realmente o único recurso que me impede de considerar a mudança do IntelliJ / WebStorm para o VSCode em tempo integral ... principalmente porque, como um pôster anterior mencionado, trabalho com arquiteturas distribuídas o dia todo e preciso de vários gerenciamento Git integrados para o meu editor (porque sou muito preguiçoso 😆)

_Adoro_ que vocês estejam trabalhando nisso e mal posso esperar para vê-lo em ação.

Eu gosto de vscode, mas esse "recurso ausente" está me impedindo de mudar totalmente de atom para vscode

Uma versão anterior já está na compilação do Insiders. Vai buscar :)

+1 Precisa deste recurso

A primeira versão de visualização é muito legal, pessoal!
Já existe um pequeno problema antes mesmo de eu começar a testar corretamente ...
Quando adiciono duas pastas "raiz" com o mesmo nome de dois projetos separados, não há nada que os diferencie.

por exemplo, adiciono /dev/www/myproject/src e, em seguida, adiciono /dev/libraries/mycomponent/src
Tudo o que vejo são duas pastas raiz chamadas src .

> src
> src

Acredito que precisamos de uma maneira de alterar o nome de
Que então exibiria:

> My Project (/src)
> Component 1 (/src)

Pensamentos?

VSCode mostra parte do nome da pasta quando você abre dois arquivos com o mesmo nome, que poderia funcionar com pastas também?

@doublehelix , discutimos isso recentemente, mas não havia nenhum local rastreando o problema. Criei https://github.com/Microsoft/vscode/issues/29871 , obrigado 😄

@Tyriar Eu realmente acho a funcionalidade de pesquisa confusa para dizer o mínimo e acho que ela deve exibir os resultados semelhantes a como são exibidos no Explorer como eu disse antes .

Não sei se vocês analisaram o que eu e algumas pessoas dissemos acima ou se há mais mudanças chegando, mas pessoalmente não gosto da maneira como você acrescenta o nome da raiz a cada vez em vez de classificar as coisas em uma árvore como visualização quando possível.

@eyalsk É um trabalho em andamento. Analisarei mais os resultados da pesquisa em julho: # 29977

O projeto vscode é baseado em uma pasta.
Assim, você pode configurar a configuração de cada projeto separadamente, e pode usar o Git integrado diretamente, ou não pode.

PyCharm: coração:: coração:: coração:

+1

Eu tenho que elogiar você, cara equipe VSCode.
Por fim, sou capaz de abandonar o Atom, já que o Multi-Root Workspaces chegou ao Insiders Builds!
Há dois anos .gitignore etc. não são respeitados no Atom ao pesquisar em espaços de trabalho com várias raízes e você acertou desde o início!

A persistência de espaços de trabalho é rastreada em outro problema?

Ontem, a equipe do VS Code lançou uma nova versão do VS Code com o recurso Multi Root Workspaces 🎉.

O resultado deste trabalho é o que chamamos de "Produto Mínimo Viável" (MVP) para permitir o teste em vários espaços de trabalho de pasta raiz.

Na verdade, só está disponível na compilação do Insiders, então você pode baixá-lo aqui Baixe o VS Code Insiders

Explorador de arquivos

Pesquisa

Suponha que cada pasta adicionada ao espaço de trabalho seja um repositório git separado - a versão atual do Multi Root Workspaces lida com a diferenciação do controle de origem desses repositórios?

@Weyzu , estamos trabalhando para adotar o SCM para cenários de múltiplas raízes neste marco. Nosso pensamento inicial é que a visão SCM precisa se tornar ciente de vários repositórios, o que não é necessariamente o mesmo que ciente de várias pastas, como no explorer e na pesquisa: já quando você abre uma única pasta no VS Code, você pode ter vários repositórios dentro . Achamos que a visão do SCM deve mostrar esses repositórios de uma maneira boa para que você veja as mudanças de saída / entrada para cada repositório, bem como a capacidade de enviar arquivos de cada repositório.

O resultado deve fornecer uma experiência melhor para cenários de múltiplas raízes, bem como cenários de raiz única, onde vários repositórios estão contidos em uma raiz.

O resultado deve fornecer uma experiência melhor para cenários de múltiplas raízes, bem como cenários de raiz única, onde vários repositórios estão contidos em uma raiz.

Excelente abordagem, vocês são demais!

@bpasero incrível! Eu definitivamente estaria interessado em ver a opinião de seus rapazes sobre isso. O IntelliJ / WebStorm tem algo semelhante, onde detecta automaticamente as raízes do Git e as alinha apropriadamente no canto inferior direito, e pessoalmente adorei usá-lo.

image

Vocês estavam pensando em algo nesse sentido ou algo um pouco mais elaborado?

Ainda estamos resolvendo a experiência do usuário para isso e manteremos você informado sobre os resultados.

Uma raiz de sistema de arquivos virtual não poderia funcionar aqui? Ele atuaria efetivamente como se a raiz VFS fosse o diretório pai de vários caminhos diferentes.

Eu queria dar uma atualização sobre nosso trabalho multi-root porque hoje é o primeiro dia em que nosso UX multi-root revisado atingiu o lançamento interno e muitos de vocês que se acostumaram com o comportamento "antigo" podem estar confusos com o que está acontecendo.

Falhas da solução antiga
A solução antiga para multi-raiz introduziria uma nova configuração workspace (no global settings.json ) que permite adicionar pastas adicionais a uma única pasta raiz. A configuração estava assim, caso você não tenha notado:

{
  "path to folder": [
      "additionalFolder1",
      "additionalFolder2"
   ]
}

Chamamos essa solução de pasta "mestre" com pastas adicionais ("detalhes").

Esta foi a solução mais direta, sem introduzir muitos conceitos novos, mas também tem falhas:

  • você nunca poderia abrir a pasta mestre como uma única pasta novamente porque a configuração persistia
  • você não pode remover a pasta master do explorer
  • algumas configurações da pasta mestre aplicadas a todas as outras pastas
  • suas configurações ficam poluídas com coisas de configuração multi-root
  • é difícil permitir a abertura de algumas pastas ao mesmo tempo (por exemplo, quando você abre 3, qual pasta mestre devemos escolher?)

Nossa Solução
Achamos que um conceito de espaço de trabalho mais explícito é necessário para cenários de múltiplas raízes e, como tal, no insider de hoje, você verá uma nova IU surgindo:

image

A ideia é que os espaços de trabalho com várias raízes exigem que uma ação explícita seja criada. Da mesma forma que você pode estar em um espaço de trabalho vazio (nenhuma pasta aberta, barra de status roxa) ou em um espaço de trabalho de uma única pasta (barra de status azul claro), você também pode estar em um espaço de trabalho multi-root (status azul escuro Barra). Esta terceira forma de abrir um espaço de trabalho no VS Code permite ter quantas pastas você quiser. Esses espaços de trabalho podem ser salvos em um arquivo (por exemplo, myWorkspace.code ) e também incluem configurações de espaço de trabalho. No entanto, você não é forçado a salvá-los, desde que não queira salvá-los, eles aparecerão como "Espaços de trabalho sem título".

Para abrir um espaço de trabalho, você pode abrir o arquivo do espaço de trabalho salvo ou escolher na lista aberta recentemente:

image

Tudo isso é código muito jovem e UX muito jovem, então espere algumas mudanças nas próximas semanas. Sabemos que ainda há algumas coisas a resolver (por exemplo, como podemos tornar a transição de pasta única para pasta múltipla mais suave).

Algumas mudanças que já foram feitas hoje que serão lançadas amanhã com base no feedback:

  • renomear .code para .code-workspace como extensão para espaços de trabalho
  • ter uma lista unificada de pastas e áreas de trabalho (por exemplo, em Arquivo> Abrir recente) em vez de distinguir entre pastas e áreas de trabalho

Fique ligado para mais por vir 👍

Além disso, agora temos uma pasta .vscode por pasta de projeto contendo o arquivo settings.json . Este arquivo pode conter o seguinte:

// Place your settings in this file to overwrite default and user settings.
{
      "editor.wordWrap": "on",
      "files.autoSave": "onFocusChange",
       "editor.fontSize": 15
}

O problema aqui é que, quando queremos trabalhar com vários usuários (sessão RDP diferente) no servidor nas mesmas pastas de projeto, compartilhamos as mesmas configurações. Este pode não ser o comportamento pretendido. Eu gostaria que o tamanho da minha fonte fosse maior do que o do meu colega.

Portanto, em minha opinião, você também deve levar em consideração que diferentes usuários podem estar trabalhando nas mesmas pastas, mas com configurações diferentes em settings.json .

@ DarkLite1 você trouxe um bom ponto. Em nosso design de configurações para multi-root, tentamos identificar configurações que podemos suportar por pasta e configurações que não podemos suportar. Normalmente dizemos que as configurações que visam o editor ou um recurso específico podem ser suportadas por pasta porque é claro de qual pasta o editor foi aberto. Outras configurações que não serão suportadas são mais em torno da personalização do ambiente de trabalho (por exemplo, mostrar a barra de status ou não).

Seu exemplo é sobre a configuração editor.fontSize que, na verdade, suportamos por pasta, mesmo em um espaço de trabalho com várias raízes. Acho que pode ser um cenário válido que um usuário deseja ter um tamanho de fonte maior para uma pasta que contém muita documentação de markdown (talvez até uma fonte diferente?). Portanto, eu acho que não devemos evitar de respeitar essa configuração por pasta também em um ambiente multi-root.

Se você quiser manter editor.fontSize como uma configuração de espaço de trabalho pessoal, acho que não deve ser feito o check-in no repositório.

Com o novo conceito de espaços de trabalho, você pode fazer o seguinte:

  • Arquivo> Espaços de trabalho> Novo espaço de trabalho
  • Escolha sua pasta
  • Abra as configurações do espaço de trabalho
  • Alterar editor.fontSize: 15

A partir de então, sua área de trabalho carregará essa configuração, mas você não a estará forçando para mais ninguém.

Da perspectiva da UX, seria conveniente se eu pudesse arrastar e soltar pastas em uma janela do VS Code sem ter que criar explicitamente um espaço de trabalho primeiro (é algo que faço o tempo todo no Sublime). Eu invariavelmente trabalho em vários projetos ao mesmo tempo e, dependendo do que estou fazendo, haverá um conjunto diferente (sobreposto) de projetos todos os dias.

Os espaços de trabalho introduziriam um conceito que não é nativo da minha maneira de trabalhar, e eu teria que controlar as diferentes configurações do espaço de trabalho (pelo que entendi), o que parece que vai criar alguma confusão de configuração nas pastas do meu projeto.

Além disso, acho que falo por muitos usuários se eu argumentar que coisas como pesquisa e configuração são globais por padrão (aplicam-se a todas as pastas abertas) - embora fosse bom se eu tivesse a opção de pesquisar localmente em uma pasta ( Sempre achei isso complicado no Sublime).

@SanderMertens Você pode ter perdido isso, mas @bpasero escreveu;

Esses espaços de trabalho podem ser salvos em um arquivo (por exemplo, myWorkspace.code) e também incluem configurações de espaço de trabalho. No entanto, você não é forçado a salvá-los, desde que não queira salvá-los, eles aparecerão como "Espaços de trabalho sem título".

Bem, não tenho certeza se você teria a capacidade de arrastar e soltar pastas, mas pelo que estou obtendo, as pessoas teriam a capacidade de abrir pastas arbitrárias sem criar um espaço de trabalho.

Eu não posso esperar para que este recurso seja incluído na compilação estável.

Yay! 😄

Atualmente você não pode arrastar uma pasta para o explorador para adicioná-la, mas isso está em nosso backlog. A complicação dessa interação é que não sabemos a intenção do usuário: abrir a pasta na janela ou adicioná-la ao espaço de trabalho?

A transição de uma pasta para várias pastas atualmente é uma etapa mais explícita em comparação com o que outros editores fazem (você precisa ir em Arquivo> Áreas de trabalho> Salvar área de trabalho e escolher as pastas que deseja). Há algumas razões pelas quais queremos seguir o comportamento atual por enquanto até que o multi root se estabilize. O principal motivo é que o multi-root é uma grande mudança para todas as nossas extensões. Embora o explorador funcione e você possa pesquisar em todas as pastas, a maioria das extensões não funcionará corretamente até que a nova API multi-root seja adotada. Como tal, não queremos tornar muito fácil no início inserir acidentalmente várias raízes. É um gesto explícito do usuário entrar em espaços de trabalho com várias raízes e, nesse modo, podemos chamar a atenção para o fato de que algumas extensões ainda não estão funcionando.

Outro motivo são as configurações do espaço de trabalho: Imagine este fluxo:

  • você começa com 1 pasta que tem configurações de espaço de trabalho
  • você adiciona uma segunda pasta (suponha que isso funcione sem mudança de contexto e recarregamento da janela)
  • você abre as configurações do espaço de trabalho
    => configurações de espaço de trabalho em multi root agora são armazenadas em algum local fora das pastas, porque você pode ter vários
    => provavelmente precisamos perguntar ao usuário se ele deseja migrar as configurações do espaço de trabalho para esse novo local

Portanto, não importa o que aconteça, inserir multi-root não é uma operação leve atualmente. Podemos revisitar isso quando a poeira baixar e o multi-root for amplamente adotado, mas por enquanto achamos que este modelo é melhor e evita frustrações.

@bpasero Acho que por padrão, uma vez que você arrasta uma pasta para o explorador, ela não deve salvá-la automaticamente na área de trabalho, mesmo que exista uma e esta deve ser uma ação explícita onde o usuário clica na (s) pasta (s) que ele / ela arrastar e, em seguida, adicioná-lo explicitamente ao espaço de trabalho e se você tiver poucas pastas não relacionadas, pode ser sensato fornecer outra ação para salvar todas de uma vez.

Tudo depende dos casos de uso que se deseja cobrir. Eu descobri por experiência própria que o KISS é sempre a melhor abordagem. Apresentar Workspaces soa muito bem como feature mas qual é o benefício real e quais são as desvantagens?

Uma desvantagem que vem à mente ao introduzir e usar Workspaces é que ele precisa armazenar seus dados (configurações) em algum lugar e requer manutenção / conscientização do usuário.

Suponha que o único objetivo seja dar aos usuários a capacidade de trabalhar com várias pastas em uma sessão do VS Code. Nada menos, nada mais.

Caso de uso mais comum:
Não há conceito Workspaces . O usuário apenas abre uma pasta extra, ou quantas quiser, e elas são abertas na visualização à esquerda, como uma única pasta. Ele espera que suas configurações sejam as mesmas em todos os lugares. independentemente de onde seus arquivos estão localizados. E ele não quer nenhuma confusão extra de arquivos de configuração do VS Code entre seus arquivos de projeto, conforme declarado por @SanderMertens , eu e provavelmente outros por aí também.

Desafios / problemas / perguntas:

  • Por que existem tantos arquivos de configuração diferentes? Configurações do usuário, configurações do espaço de trabalho? Deve IMHO tudo ser armazenado em um e no mesmo local. De preferência no usuário sua pasta / perfil pessoal, para que cada usuário do sistema possa ter suas próprias configurações. Bônus extra. eles não confundem os arquivos do projeto e vários usuários podem fazer suas próprias coisas. Limpar o perfil? Ótimo! Também está em branco para o VS Code.

Eu acho que Workspaces são coisas um pouco exageradas se você quiser:
Velocidade, simplicidade e um editor que simplesmente funciona., Sem complicar demais as coisas ou entender conceitos extras. Se os usuários do Sublime ou de outros editores não usarem esse conceito em seu fluxo de trabalho, isso deve ser uma indicação de que está pensando demais. Ou pode significar que algo realmente incrível foi inventado que outros editores irão implementar também, mas tenho minhas dúvidas.

Lamento se isso soa como discurso retórico, não é absolutamente minha intenção. Mas acredito que podemos fazer melhor no que diz respeito ao acesso a várias raízes / pastas.

@ DarkLite1, obrigado por nos fornecer feedback sobre nossa nova estratégia para espaços de trabalho.

Concordo com todos os seus pontos e também quero uma solução simples. Espaços de trabalho como um conceito é nosso primeiro passo em direção a uma solução multi-root que funciona com nossos padrões existentes (configurações de espaço de trabalho, extensões, etc.). Como esta é a primeira etapa, espere algumas bordas mais ásperas (por exemplo, a transição de 1 para N pastas não é tão leve quanto poderia ser). Nosso objetivo é tornar essa transição suave e não torná-la mais complexa do que precisa ser no futuro. E também não queremos forçar um usuário a gerenciar esses espaços de trabalho (é por isso que temos "Espaços de trabalho sem título" que vivem enquanto a janela estiver aberta e irão embora assim que você fechar essa janela).

Há algumas coisas em torno de espaços de trabalho com várias raízes que devem ser lembradas, mas talvez não sejam tão óbvias. Espero que a seguinte explicação detalhada ajude a entender nosso processo de design:

Configurações do espaço de trabalho
Oferecemos suporte para configurações dentro de uma pasta de espaço de trabalho ( .vscode folder). Por mais que alguns usuários possam não gostar desse tipo de configuração, que acaba em .gitignore arquivos ou no repositório, muitos dependem dessa funcionalidade. Não podemos simplesmente parar de oferecer suporte a configurações que residem em pastas porque os usuários dependem delas. Agora, para cenários de múltiplas raízes, é claro que temos que encontrar um novo local para as configurações do espaço de trabalho. Criamos o conceito de um arquivo de espaço de trabalho que contém essas configurações. Desde que o espaço de trabalho não seja salvo em nenhum lugar, ele reside em uma pasta que contém outros dados específicos do VS Code e, quando você salva o arquivo, as configurações estarão dentro desse arquivo.

Agora imagine que você começa com 1 pasta no VS Code que possui configurações de espaço de trabalho definidas e deseja adicionar uma segunda pasta. O que devemos fazer agora? Ignorar as configurações do espaço de trabalho da primeira pasta? Pedir ao usuário para migrar as configurações? Decidimos tornar isso uma troca de contexto explícita para deixar claro que a abertura de um espaço de trabalho carrega suas próprias configurações de espaço de trabalho em um local diferente.

E agora imagine que você passou de 1 pasta para 2 pastas e movemos as configurações do espaço de trabalho para outro lugar. Imagine que você faça alterações nessas configurações do espaço de trabalho. Agora que você deseja voltar de 2 pastas para 1, espera migrar as configurações do espaço de trabalho de volta para a pasta?

Outro exemplo: você faz a transição de 1 para 2 pastas e define as configurações do espaço de trabalho. Agora você fecha a janela. Acho que você ficaria bravo conosco se não pudesse voltar a este espaço de trabalho de alguma forma porque definiu cuidadosamente as configurações para este espaço de trabalho. Portanto, mesmo que você não goste do conceito de espaço de trabalho, depois de definir as configurações para ele, acho que você deseja que esse espaço de trabalho permaneça.

Espero que esses exemplos tornem um pouco mais fácil entender por que o KISS não é tão fácil para nós como se pensa.

Extensões
Todas as nossas extensões sempre trabalharam com uma API que fornece um único caminho de espaço de trabalho porque até agora não suportávamos espaços de trabalho com várias raízes. Como usuário, você pode pensar que mudar de 1 pasta para 2 pastas é uma operação muito simples e leve, mas para extensões isso pode significar muitas coisas: As extensões de idioma que até agora supunham que havia apenas uma pasta de repente precisam estar cientes de várias pastas. E, além disso, essas pastas podem entrar e sair dinamicamente a qualquer momento.

A introdução de um conceito de espaço de trabalho real nos dá mais espaço e tempo para ampliar e ajudar as extensões a adotarem esse conceito. Poderíamos, por exemplo, desabilitar extensões que ainda não adotaram espaços de trabalho multi-root para evitar que coisas estranhas aconteçam (por exemplo, uma extensão de idioma só funciona em uma pasta e relata erros incorretos na outra).

Vamos tentar estabilizar no suporte multi-root com esses novos espaços de trabalho primeiro e, em seguida, revisitar o quão leve podemos fazer as transições. Assim que tivermos as extensões integradas e descobrirmos nossa história de configurações, acho que podemos fazer a mudança para uma experiência mais leve.

PS: já que você faz uma referência a outros editores com relação ao suporte multi-root, eu só queria salientar que esses editores também vêm com uma área de trabalho ou conceito de projeto que você pode salvar em um arquivo e compartilhar com outras pessoas. Normalmente, você não está vendo esses conceitos porque passar de 1 para N pastas é uma operação muito leve. Eu diria, porém, que as pessoas que contam com esse recurso começam a se mover para espaços de trabalho / projetos salvos como uma forma de gerenciar o trabalho. Por exemplo, a menos que você salve a área de trabalho / projeto e feche a janela, todas essas informações serão perdidas.

@bpasero obrigado por me responder e pela explicação detalhada, eu realmente aprecio isso.

Como não conheço totalmente o Sublime , tomei a liberdade de verificar como eles lidam com isso. E você está correto, eles usam Workspaces também e até Project arquivos. A única coisa que me incomoda um pouco é que ele coloca os arquivos do VS Code entre meu projeto. Mas, como você mencionou, se outros confiarem nisso, deve-se levar em consideração que isso pode ser apenas o que é melhor. Só estou me perguntando por que esses arquivos de configuração não são específicos do usuário. Posso imaginar um colega abrindo o VS Code na mesma estrutura de pastas, mas querendo ter suas próprias configurações.

Se Workspaces são o caminho a seguir, e parece que são, seria lógico ao abrir o aplicativo que ele recarregaria as últimas configurações usadas. Mesmo se este for um Workspace não salvo. Isso torna a vida um pouco mais simples, eu acho.

Por que escolhi o VS Code? Por ser multiplataforma, como eu uso o Linux em casa e o Windows no trabalho, esse pode realmente se tornar meu editor padrão! Como um bônus extra, sou um desenvolvedor PowerShell e também há uma extensão para ele. Então, duas grandes vitórias! Além disso, para o curso Java que estou seguindo, a Red Hat está fazendo uma extensão também para o VS Code. Assim, quando você conhecer melhor o VS Code, com seus atalhos e tudo mais, terá benefícios em todos os aspectos.

O aplicativo e suas extensões ainda estão um pouco em estado beta ou mesmo alfa em alguns pontos, mas ainda assim, ótimo trabalho pessoal! Realmente aprecio os esforços e ver o progresso nas compilações do Insider todos os dias. Continue com o excelente trabalho e tenha um bom fim de semana.

Obrigado por essa explicação @bpasero , acho que entendi melhor agora qual é a complexidade.

Uma abordagem poderia ser tratar conceitualmente qualquer conjunto de projetos com a mesma configuração de um espaço de trabalho. Além disso, você pode evitar adicionar uma pasta .vscode , desde que o projeto não divirta da configuração padrão. Isso deveria:
1) livrar-se da maior parte da desordem em projetos
2) evitar a maioria dos conflitos de configuração ao adicionar projetos (no caso simples, não haverá configuração)

Acho que o conceito de espaço de trabalho explícito conforme discutido é uma boa solução para o problema mencionado. Com essas duas regras simples, minimizo os casos de uso em que as pessoas se deparam com esse problema.

Para mim, olhando os comentários no thread e meus casos de uso, vejo _Multi-folder_ e _Workspaces_ como dois conceitos diferentes e talvez devam ser tratados separadamente também.

Não deve forçar a _criar um espaço de trabalho_ apenas para adicionar outra pasta à janela atual. Deve apenas adicionar a nova pasta na árvore e deixar a área de trabalho recém-criada como uma _informação interna_. Se o usuário decidir salvar a área de trabalho, ela será realmente criada. E mesmo se eu não salvar o espaço de trabalho, ao reabrir a pasta superior, ele _rembraria_ meu espaço de trabalho temporário_ e abriria as outras pastas também, assim como lembra os arquivos abertos quando você abre uma pasta hoje. BTW, gostaria de saber como eu poderia abrir várias pastas na linha de comando.

Para meus casos de uso, várias pastas é apenas uma maneira de ver mais de uma pasta por vez na mesma janela, não uma abordagem de _grupo de projetos / solução_. Portanto, uma solução mais simples seria adequada. Mas eu entendo como outras pessoas precisam de um _Workspace_, com suas próprias configurações e então: thumbsup :

O que mais me incomoda nesse novo conceito de espaço de trabalho (em comparação com a primeira iteração usando User Settings ) é a mesma coisa que me incomodava quando estava usando Sublime Text. O fato de que você _pode_ salvar os .code-workspace arquivos _qualquer lugar_, e agora tenho que gerenciar um lugar comum para armazená-los. Seria muito mais simples, IMHO, caber automaticamente, em um destes dois lugares:

  • dentro da pasta user-data-dir , como User Settings e Keybindings
  • dentro da _Pasta Superior_

Só para ficar claro, eu entendo o conceito de espaço de trabalho mais complexo de que outros usuários precisam. Eu só queria uma abordagem mais simples para um conceito mais simples de várias pastas.

Eu gosto desta opção, adicione esta opção.
dddsa
Porque a pasta dentro não é muito impressionante.
default
ou adicione a capacidade de alterar esta opção.

Gosto da ideia do Workspace! Alguma ideia de quando isso ficará pronto?

Espera-se neste ponto que as informações do git no canto inferior esquerdo não reflitam com precisão o branch git de qualquer repositório em que o arquivo focado atualmente está? Eu não vi nada sobre "raízes múltiplas do git" nas notas de lançamento da v1_15.

Estou usando esse recurso agora com a construção do Insider por alguns dias e devo dizer que é tudo o que eu queria que fosse. Experiência de usuário muito limpa e mal posso esperar até que esteja na construção principal para poder converter toda a minha equipe para isso.

Ao trabalhar com NodeJS e ter vários módulos NPM abertos ao mesmo tempo, a maneira como ele reúne tudo em uma janela economiza muito tempo.

Enormes adereços para a equipe!

Por que esse recurso aparece em minhas notas de versão com um gif e uma explicação, mas não está disponível no editor real ?!

@ShashankaNataraj que está nos internos e não na versão original. Se você ver o documento com atenção, ele será mencionado apenas para compilações internas

Nosso roteiro para o trabalho contínuo de várias raízes é capturado em https://github.com/Microsoft/vscode/issues/28344 e continuará durante agosto, setembro e provavelmente também outubro.

Manteremos esse recurso disponível apenas em insiders até:

  • podemos fornecer um SCM habilitado para múltiplas raízes, depuração e experiência de tarefas
  • adotamos APIs multi-root e funcionalidades para as extensões com as quais fornecemos e para as quais contribuímos ativamente (por exemplo, Go)
  • autores de extensão tiveram tempo suficiente (por exemplo, 1 marco) para adotar as novas APIs multi-root

Por favor, entenda que queremos evitar o envio desse recurso para o estável e ter uma experiência de extensões interrompidas porque nos apressamos a disponibilizar esse recurso.

Obrigado por serem profissionais, ótimo trabalho!

@bpasero Estou um pouco preocupado com os autores de extensões, pois eles atualizarão os plug-ins no momento. Eles recebem algum e-mail especial sobre alterações urgentes?

obrigado

@FelikZ consulte nosso roteiro (https://github.com/Microsoft/vscode/issues/28344). Para o lançamento de setembro, planejamos adotar as extensões que enviamos no VS Code e, enquanto estamos trabalhando nisso, adicionamos as APIs e utilitários necessários para fazê-lo.

Durante setembro, este é o plano:

image

A atualização de hoje vem com algumas mudanças no arquivo .code-workspace que eu queria resumir aqui. Os espaços de trabalho existentes com o formato anterior serão migrados automaticamente para o novo formato.

O formato antigo era assim:

{
    "id": "1500007676869",
    "folders": [
        "file:///Users/bpasero/Development/Microsoft/monaco",
        "file:///Users/bpasero/Development/Microsoft/vscode-distro",
        "file:///Users/bpasero/Development/Microsoft/vscode-docs",
        "file:///Users/bpasero/Development/Microsoft/vscode-extension-sdk"
    ]
}

E o novo formato é:

{
    "folders": [
        { "path": "/Users/bpasero/Development/Microsoft/monaco" },
        { "path": "/Users/bpasero/Development/Microsoft/vscode-distro" },
        { "path": "/Users/bpasero/Development/Microsoft/vscode-docs" },
        { "path": "/Users/bpasero/Development/Microsoft/vscode-extension-sdk" }
    ]
}

ID do espaço de trabalho
O ID do espaço de trabalho é usado para associar algumas coisas ao espaço de trabalho:

  • todos os estados da IU (por exemplo, arquivos abertos)
  • todo o estado de arquivo sujo (também conhecido como hot-exit)
  • estado de extensões (se houver)

Decidimos remover a propriedade id do arquivo do espaço de trabalho e, em vez disso, calcular id automaticamente com base no caminho absoluto do arquivo do espaço de trabalho no disco. Isso tem algumas vantagens e desvantagens, mas no final pensamos que as vantagens tornam esta solução melhor:

  • era estranho que você pudesse editar o id no arquivo simplesmente digitando outro valor
  • não estava muito claro como tratar id ao compartilhar o arquivo da área de trabalho com outras pessoas (o id deveria ser alterado? O id deveria ser um uuid?)
  • não foi possível copiar um arquivo de espaço de trabalho e abri-lo em uma janela separada, você teve que alterar o id primeiro no arquivo copiado
  • como consequência, a ação "Salvar espaço de trabalho como" teria que perguntar ao usuário se a cópia deveria ter um id ou não

Uma desvantagem dessa abordagem é que, depois de mover ou renomear um arquivo de espaço de trabalho, o estado associado será perdido. Arquivos sujos ("hot-exit") ainda serão reabertos após uma reinicialização, mas serão abertos em uma janela vazia e não estarão mais associados à janela do espaço de trabalho. Ainda achamos que podemos melhorar esse comportamento, embora ele esteja se comportando de maneira consistente com o que acontece hoje quando você renomeia uma pasta com o estado da IU associado e arquivos sujos.

Pastas
Decidimos revisitar o formato da propriedade folders .

  • não exigimos mais que você use URIs de recursos, mas apenas caminhos de arquivo para facilitar a edição
  • mudamos as entradas da propriedade folders para serem objetos para que possamos associar metadados às entradas conforme necessário (por exemplo, cada pasta pode ter uma propriedade name extra)

Finalmente, o suporte para caminhos relativos também foi alcançado. Você pode inserir um caminho de arquivo relativo e ele será resolvido na pasta pai do arquivo da área de trabalho. Observe que, devido ao bug https://github.com/Microsoft/vscode/issues/33188 , estamos reescrevendo caminhos relativos para caminhos absolutos ao fazer alterações no arquivo do espaço de trabalho.

@bpasero é incrível. Quando a propriedade name extra funcionará? No momento, tenho duas pastas com o mesmo nome em meu espaço de trabalho e é horrível.

@DaniloPolani consulte https://github.com/Microsoft/vscode/issues/29871

Uma atualização para o tratamento de caminhos relativos : começando com a construção interna de hoje, vamos escrever caminhos para o arquivo da área de trabalho como um caminho relativo se a localização do arquivo da área de trabalho for um pai do destino. Em outras palavras, os caminhos agora serão sempre relativos, a menos que tenhamos que usar a notação " ../ " para expressar o caminho.

Como os espaços de trabalho sem título sempre residem no diretório de dados do VS Code, os caminhos lá sempre serão absolutos. Mas, depois de salvar um espaço de trabalho sem título em um local, reescreveremos os caminhos, se possível.

Se você estiver curioso sobre as mudanças em torno dos espaços de trabalho com várias raízes que ocorreram durante este sprint, verifique as notas de versão atualizadas .

+1

+1

@bpasero IMHO, a forma como os estados da IU são tratados (se estiver usando uma string de ID no arquivo .code-workspace ou usando o caminho do arquivo como o ID) não é adequada.
Renomear um arquivo .code-workspace , ou qualquer uma de suas pastas pai, ou movê-lo, e perder o estado da IU é, em minha opinião, totalmente não intuitivo. Acho que as pessoas que não sabem como isso funciona nos bastidores não têm absolutamente nenhuma ideia sobre o motivo pelo qual perderam o estado anterior da IU e como recuperá-lo.
Isso não deve estar vinculado ao caminho absoluto dos arquivos no sistema de arquivos!

Isso também se aplica à maneira como o estado da IU se relaciona ao caminho da pasta atualmente na versão estável. Fiquei muito confuso com isso no início, até que fiz algumas pesquisas no Google.

IMO No caso de estarmos lidando com apenas uma pasta, o estado da IU deve ser salvo dentro da pasta .vscode . Se estivermos lidando com um espaço de trabalho multi-root, o estado da IU deve ser salvo como um arquivo separado na mesma pasta do arquivo .code-workspace usando as convenções de nomenclatura apropriadas (ou talvez dentro do próprio arquivo, embora misture as configurações e estado pode não ser uma boa ideia).

Se implementado corretamente, isso permitiria aos usuários ter acesso completo aos estados da IU, anexar novos estados da IU a um determinado espaço de trabalho (multi-root ou não), etc.
Adoraria poder sincronizar o estado da IU entre diferentes computadores, digamos, trabalhar no escritório, depois ir para casa, pegar um laptop ou qualquer coisa e continuar exatamente de onde parei.
Ter vários estados de IU anexados a um espaço de trabalho e alternar facilmente entre eles (menu / atalho de teclado / comando / etc) ao trabalhar em diferentes recursos também seria incrível. Talvez .code-uistate arquivos diferentes dentro de .vscode listados automaticamente, ou muitos .code-uistate arquivos prefixados de acordo com o .code-workspace , ou listados em um array.

Estou pensando nisso como uma extensão de como os projetos e áreas de trabalho funcionam no Sublime Text. Mesma funcionalidade, design diferente. Nesse caso, um espaço de trabalho do VS Code seria semelhante a um projeto Sublime e os diferentes estados da IU do VS Code seriam semelhantes aos dos espaços de trabalho Sublime.

Em relação a essas questões:

era estranho que você pudesse editar o id no arquivo simplesmente digitando outro valor

Sim, totalmente. Remover o ID de lá foi a escolha certa.

não estava muito claro como tratar o id ao compartilhar o arquivo do espaço de trabalho com outras pessoas (o id deveria ser alterado? o id deveria ser um uuid?)

Bem, se nós temos myproject.code-workspace e myproject.code-uistate então cabe ao usuário decidir se deseja compartilhar seu estado de IU ou não. Chega de pensar no que esse ID significa, como é gerado, se precisa ser um UUID para evitar conflitos durante o compartilhamento, etc.
Quer compartilhar a configuração e as configurações da pasta? Envie myproject.code-workspace , não se preocupe.
Quer compartilhar tudo? Envie os dois arquivos.

não foi possível copiar um arquivo de espaço de trabalho e abri-lo em uma janela separada, você teve que alterar o id primeiro no arquivo copiado

Se você quiser começar com um novo estado de IU com a mesma configuração de pasta e configurações, basta duplicar seu arquivo .code-workspace .

como conseqüência, a ação "Salvar espaço de trabalho como" teria que perguntar ao usuário se a cópia deveria ter um id diferente ou não

Isso foi complicado, pois o usuário não sabia o que era esse ID. Talvez fosse mais simples ter duas opções "Clonar espaço de trabalho com estado atual" e "Novo espaço de trabalho em branco". Mas isso é UX e você teria que fazer uma análise sobre isso.

De acordo com Franc, manter todos os arquivos de configuração do projeto dentro das configurações
pasta nos projetos, dê uma olhada no Eclipse IDE, que tem o direito
aproximação. Tem o conceito de configurações de projeto e espaço de trabalho com
sobrescrever padrões de projeto no espaço de trabalho. O espaço de trabalho é apenas uma pasta com
pastas que representam projetos. Portanto, tenha a pasta .vscode na área de trabalho
pasta, e cada projeto tem sua própria pasta .vscode . E por favor não
apenas vote abaixo para mencionar o IDE Eclipse.

Na segunda-feira, 18 de setembro de 2017 às 20:52, Franco Gallardo Grazio <
notificaçõ[email protected]> escreveu:

@bpasero https://github.com/bpasero IMHO, a forma como os estados da IU são tratados
(se estiver usando uma string de ID no arquivo .code-workspace, ou usando
o caminho do arquivo como o ID) não é adequado.
Renomear um arquivo .code-workspace, ou qualquer uma de suas pastas pai, ou mover
ao redor, e perder o estado da interface do usuário é, na minha opinião, totalmente não intuitivo. Eu
acho que as pessoas que não sabem como isso funciona nos bastidores teriam absolutamente
nenhuma pista sobre o motivo pelo qual eles perderam o estado anterior da interface do usuário e como obter
de volta.
Isso não deve estar vinculado ao caminho absoluto dos arquivos no arquivo
sistema em tudo!

Isso se aplica à forma como o estado da interface do usuário se relaciona ao caminho da pasta atualmente no
versão estável também. Fiquei muito confuso com isso no início, até que
fiz algumas pesquisas no Google.

IMO No caso de estarmos lidando com apenas uma pasta, o estado da IU deve ser salvo
dentro da pasta .vscode. Se estamos lidando com um espaço de trabalho multi-root,
O estado da IU deve ser salvo como um arquivo separado na mesma pasta que o
arquivo .code-workspace usando convenções de nomenclatura apropriadas (ou talvez
dentro do próprio arquivo, embora misturar configurações e estado possa não ser um
boa ideia).

Se implementado corretamente, isso permitiria aos usuários ter acesso completo
aos estados da IU, anexe novos estados da IU a um determinado espaço de trabalho (multi-root ou
não), etc.
Eu adoraria poder sincronizar o estado da IU entre diferentes computadores, digamos
trabalhando no escritório, depois indo para casa, pegando um laptop ou algo assim e
continuando exatamente de onde parei.
Ter vários estados de IU anexados a um espaço de trabalho e alternar facilmente entre
eles (menu / atalho de teclado / comando / etc) ao trabalhar em recursos diferentes
seja incrível também. Talvez diferentes arquivos .code-uistate dentro .vscode
listados automaticamente, ou muitos arquivos .code-uistate prefixados de acordo com
o espaço de trabalho .code principal ou listado em uma matriz

Estou pensando nisso como uma extensão de como os projetos e espaços de trabalho
trabalhar em Sublime Text. Mesma funcionalidade, design diferente. Neste caso, um
O espaço de trabalho do VS Code seria semelhante a um projeto Sublime, e os diferentes
Os estados da IU do código do VS seriam semelhantes aos espaços de trabalho Sublime.

Em relação a essas questões:

era estranho que você pudesse editar o id no arquivo simplesmente digitando
outro valor

Sim, totalmente. Remover o ID de lá foi a escolha certa.

não estava muito claro como tratar o id ao compartilhar o arquivo do espaço de trabalho
com outros (o id deve ser alterado? o id deve ser um uuid?)

Bem, se tivermos myproject.code-workspace e myproject.code-uistate
então, cabe ao usuário decidir se deseja compartilhar seu estado de IU ou não.
Chega de pensar no que esse ID significa, como é gerado, se precisa ser
um UUID para evitar conflitos ao compartilhar, etc.
Quer compartilhar a configuração e as configurações da pasta? Envie myproject.code-workspace,
não precisa se preocupar.
Quer compartilhar tudo? Envie os dois arquivos.

não foi possível copiar um arquivo de espaço de trabalho e abri-lo em um separado
janela, você teve que alterar o id primeiro no arquivo copiado

Se você deseja começar com um novo estado de IU com a mesma configuração de pasta e
as configurações apenas duplicam seu arquivo .code-workspace.

como consequência, a ação "Salvar espaço de trabalho como" teria que perguntar ao
usuário se a cópia deve ter um id diferente ou não

Isso foi complicado, pois o usuário não sabia o que era esse ID. Talvez fosse
ser mais simples ter duas opções "Clonar espaço de trabalho com o atual
State "e" New Blank Workspace ". Mas isso é UX e você teria que fazer um
análise sobre isso.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-330396242 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAQsBQ5rdj3VGoNwy77jfSQ7V_tqWFOfks5sjxBYgaJpZM4Gm3nX
.

-
Daniel Sokolowski
arquiteto técnico

Stantive Technologies Group Inc.
Telefone: +1 (613) 634-7410
http://www.stantive.com

Aviso de Confidencialidade:
As informações transmitidas destinam-se apenas à pessoa ou entidade a
que é endereçado e pode conter informações confidenciais e / ou privilegiadas
material. Qualquer revisão, disseminação de retransmissão ou outro uso de ou
tomar qualquer ação com base nessas informações por pessoas ou
entidades que não sejam o destinatário pretendido é proibido. Se você recebeu
isto é um erro, entre em contato com o remetente imediatamente por meio eletrônico de retorno
transmissão e, em seguida, exclua imediatamente esta transmissão, incluindo todos
anexos sem copiar, distribuir ou divulgar os mesmos.

@danielsokolowski Eu entendo a noção de um projeto sobrescrevendo um espaço de trabalho para configurações. No vscode, você tem configurações gerais, configurações de usuário (sobrescrevendo geral) e configurações de espaço de trabalho (sobrescrevendo usuário ou geral). Cada projeto já tem a oportunidade de ter sua própria pasta .vscode (as configurações do espaço de trabalho estão nela). Você está sugerindo uma pasta adicional que aninharia projetos apenas para compartilhar informações de configurações? Isso pareceria semelhante a um arquivo / pasta de " solução " em termos de visual studio.

@fgallardograzio Ter uma configuração de projeto misturada com configurações no mesmo arquivo irá forçar o acoplamento. O material da interface do usuário soa muito melhor como outro recurso separado deste tíquete de problema. Agora que a construção do Insiders tem um bom layout das raízes extras no arquivo, talvez uma extensão possa preencher a lacuna para a parte ui. Obrigado. Dia bom.

@Yemi , sim, então a Elcipse me permite abrir diferentes espaços de trabalho que são
simplesmente pastas que contêm várias subpastas para representar projetos. Eu
pessoalmente, use dois espaços de trabalho, um para desenvolver Eclipse IDE e outro para
todos os meus projetos relacionados ao trabalho. A principal conclusão é que as configurações são apenas
arquivos legíveis por humanos armazenados em suas respectivas pastas de configurações - http://wiki.eclipse.org/IRC_FAQ#Where_are_Eclipse_preferences_stored.3F -
isso é muito lógico para mim.

Um comentário / dica que vale a pena mencionar para qualquer IDE, em situações onde você tem
projetos autônomos, digamos workspace/your-awesome-library que você deseja
incluir como parte de outro projeto diga
workspace/my-wiget/libraries/your-awesome-library one pode usar junções
ou hardlinking dependendo do sistema operacional - acho isso mais limpo do que subrepos git / hg
conceitos.

Em Ter, 19 de setembro de 2017 às 10:33, Yemi Bedu @ P&R [email protected]
escrevi:

@danielsokolowski https://github.com/danielsokolowski Eu entendo o
noção de um projeto substituindo um espaço de trabalho para configurações. No vscode você
têm configurações gerais, configurações de usuário (sobrescrevendo gerais) e espaço de trabalho
configurações (sobrescrevendo usuário ou geral). Cada projeto já tem o
oportunidade de ter sua própria pasta .vscode (as configurações do espaço de trabalho estão nela).
Você está sugerindo uma pasta adicional que aninharia projetos apenas para
compartilhar informações de configurações? Isso pareceria uma " solução "
arquivo / pasta em termos de estúdio visual.

@fgallardograzio https://github.com/fgallardograzio Ter um projeto
configuração misturada com configurações no mesmo arquivo forçará
acoplamento. As coisas da interface do usuário soam muito melhor como outro recurso separado do
este bilhete de problema. Agora que a construção do Insiders tem um bom layout do
raízes extras no arquivo, talvez uma extensão possa preencher a lacuna para a interface do usuário
parte. Obrigado. Dia bom.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-330558669 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAQsBajECULDuQiqUZj6SRdfwJG-Bcw0ks5sj9CfgaJpZM4Gm3nX
.

-
Daniel Sokolowski
arquiteto técnico

Stantive Technologies Group Inc.
Telefone: +1 (613) 634-7410
http://www.stantive.com

Aviso de Confidencialidade:
As informações transmitidas destinam-se apenas à pessoa ou entidade a
que é endereçado e pode conter informações confidenciais e / ou privilegiadas
material. Qualquer revisão, disseminação de retransmissão ou outro uso de ou
tomar qualquer ação com base nessas informações por pessoas ou
entidades que não sejam o destinatário pretendido é proibido. Se você recebeu
isto é um erro, entre em contato com o remetente imediatamente por meio eletrônico de retorno
transmissão e, em seguida, exclua imediatamente esta transmissão, incluindo todos
anexos sem copiar, distribuir ou divulgar os mesmos.

Este recurso ainda não foi adicionado?

Isso é muito importante para mim. Estou trabalhando em um projeto que é composto de 2 repositórios separados: o front-end da web e o api. Seria bom se eu pudesse abrir essas duas pastas em um único "projeto".

Claro, eu poderia resolver isso clonando os 2 repositórios em uma única pasta e abrindo essa pasta, mas isso não funciona para todos os casos. Especialmente se você tiver vários projetos que dependem de um único repositório (ou seja, compartilham a mesma API).

Esse recurso também seria útil para aqueles que usam código como documentação.

@JamesTheHacker por um tempo use vscode-insiders que suportam vários projetos ao mesmo tempo. E você pode sugerir recursos, dependendo do que sente com a versão interna para torná-la melhor

Quando for lançado, a versão do VSCode provavelmente deverá atingir 2.0. Apenas dizendo :)

Pergunta rápida sobre este recurso:

Este recurso oferece suporte à adição de várias pastas com repositórios a um espaço de trabalho existente. Também suportaria uma configuração mono-repo, por meio da qual desejo abrir vários projetos em um mono-repo, mas como eles estão em um repo, eles não têm um repo git próprio. Portanto, do ponto de vista do projeto, eles não têm uma pasta .git - uma das pastas ancestrais os tem.

Você pode perguntar por que não abrir a pasta mono-repo como uma grande pasta e simplesmente trabalhar nela? Existem duas respostas:

  1. (menos interessante para mim) há muitos projetos no mono-repo e estou interessado apenas em alguns deles.
  2. Muitos plug-ins assumem que um projeto contém apenas um ... projeto. Por exemplo, apenas um pacote npm. Então, eles procuram coisas na _root_ do projeto. Exemplos: o plug-in npm para VSCode, o plug-in mocha para vscode e muitas funcionalidades no próprio VSCode - por exemplo, não posso especificar um caminho no launch.json que seja relativo ao arquivo atual, ou seja, "a pasta node_modules que é o ancestral mais próximo do arquivo atual".

Após esta explicação contextual, minha pergunta é simples - este recurso suportaria projetos cuja pasta .git seja um ancestral de sua raiz? Nesse caso, seria possível usar esse recurso em um mono-repo.

@borekb Sim. Não sei como as pessoas da Microsoft gerenciam suas versões, mas acho que é um recurso grande o suficiente para um grande

Após essa explicação contextual, minha pergunta é simples - esse recurso ofereceria suporte a projetos cuja pasta .git seja ancestral de sua raiz? Nesse caso, seria possível usar esse recurso em um mono-repo.

Isso já é suportado há muito tempo, se você simplesmente abrir uma subpasta de um repositório git.

+1

Sublime e Atom fazem isso como você deve. Nenhuma razão melhor. Este é o NOVO MS, faça isso galera, eu tenho total fé em vocês. :)

Olá,
@inestyne, se você ler posts anteriores, como @Jeyanthinath, você já deve estar ciente de usar o VSCode Insiders para avaliar esse recurso. Existe até um roteiro para verificar. Portanto, use o produto e forneça feedback antes que ele migre para o estável, para que todos obtenhamos o melhor produto possível. Obrigado. Dia bom.

Basta ler o tópico e usar o Insiders OMG. Vou cancelar a assinatura ... seus trolls que não lêem são impossíveis. Obrigado @ pr-yemibedu

Sensível

Uma vez que este tópico tem 2 anos de duração, e o recurso parece estar na construção dos Insiders agora, há uma maneira de marcar este tópico de forma que seja mais óbvio do que ler o tópico inteiro do início?

Uma coisa que está faltando é a capacidade de abrir uma nova janela com um novo espaço de trabalho da CLI.

@jearle Uma nova janela / espaço de trabalho deve ser criada como antes com code-insiders <folder> , não?
code-insiders -a <folder> é necessário para adicionar a pasta à janela atual.

@Jeyanthinath obrigado! Tenho feito a mesma coisa que

@Tyriar para obter a funcionalidade que desejo, preciso executar os seguintes comandos:

code .; code -a .

code . abre a pasta como um não espaço de trabalho e, em seguida, code -a . anexa à janela aberta anteriormente como um espaço de trabalho, permitindo-me abrir a mesma pasta mais de uma vez.

Eu pessoalmente acho que isso também precisa ser mudado. Estou trabalhando com iônico e um servidor personalizado em dois repositórios git diferentes e não é muito fácil. A capacidade de ter pelo menos duas "guias de projeto" separadas abertas ou algo assim seria ótimo.

Troquei do Atom por causa de como ele era lento e cheio de erros.

@ dark-swordsman você pode habilitar nativeTabs no mac

@felixfbecker isso é possível no Windows?

Editar: Eu pesquisei o arquivo de configurações completamente e não há opção para isso. É por isso que estou perguntando.

Edit2: Além disso, não há um recurso claro sobre como habilitar vs insiders

Olá,
@ dark-swordsman você não habilitou VS Insiders. É uma construção do VSCode que possui alguns recursos extras que não foram finalizados para estáveis ​​e de certa forma oferece um namespace de editor extra para trabalhar (você pode instalá-los lado a lado sem conflitos de configurações ou extensões). Obrigado. Dia bom.

O suporte para espaços de trabalho com várias raízes agora está habilitado por padrão na versão estável.

panel-red2

Consulte nossa documentação para obter uma explicação completa de todos os recursos que o acompanham. Os autores das extensões devem consultar nosso wiki que explica as novas APIs de extensão para tornar sua extensão pronta para espaços de trabalho com várias raízes. Estamos felizes que algumas extensões já começaram a adotar a nova API multi-root, obrigado por isso!

Por favor, não hesite em arquivar problemas para multi-root assim que os encontrar. Ainda estamos planejando fazer ajustes e fornecer APIs adicionais para extensões para trabalhar com espaços de trabalho multi-root no futuro.

Isso é ótimo, mas quando estará disponível? Você diz que está no build estável, mas eu tenho o build do Stable mais recente (1.17.2) e não consigo atualizá-lo. Além disso, na documentação que você acabou de fazer referência, está escrito que ainda está na compilação do Insider e estará na versão estável em breve.

Eu entendo que pode demorar um pouco antes que a próxima compilação seja lançada, mas vi esta notificação esperando que ela esteja disponível.

Edit: Peço desculpas por minha impaciência. Eu estava tentando abrir uma nova janela do modo manual (chame o .exe novamente) e não estava funcionando, mas não procurei em Arquivo> Abrir nova janela. Isso vai funcionar por enquanto. Ansioso pelo lançamento da próxima compilação. 👍

@bpasero Por favor, feche este # 35849 problema aberto, pois a funcionalidade esperada foi encerrada como parte deste # 396 recurso.

Só uma pergunta rápida. É possível, depois de abrir mais pastas, mudar a pasta que desejo compilar? No momento, é sempre o primeiro em versão estável.

EDIT: Isso pode ser para o criador da extensão PlatformIO, mas estou perguntando dos dois lados. Apenas no caso de...

@DJManas parece que depende da extensão que você está usando para decidir, portanto, pergunte ao autor da extensão.

@bpasero Ok, fiz em paralelo, obrigado pela resposta.

Esta página foi útil?
0 / 5 - 0 avaliações