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