Vscode: Ajout de la prise en charge de l'ouverture de plusieurs dossiers de projet dans la même fenêtre

Cr√©√© le 21 nov. 2015  ¬∑  380Commentaires  ¬∑  Source: microsoft/vscode

À l'heure actuelle, il ne semble pas possible d'ouvrir plusieurs dossiers de projet dans la même fenêtre, ce qui à mon avis est un peu contraignant. Si vous travaillez sur des projets modulaires modernes, il est indispensable d'être productif.

feature-request workbench-multiroot

Commentaire le plus utile

Sublime, Atom, Webstorm - ce sont aussi des éditeurs de code "légers" (sauf peut-être Webstorm) et ils permettent d'ouvrir plusieurs dossiers racine à partir d'emplacements différents. Ces éditeurs représentent probablement 99% de ce que les développeurs Web utilisent.
Le code peut rivaliser avec eux avec un bien meilleur support de Typescript (et il sera très populaire si Angular 2 arrive), mais seulement s'il donne aux développeurs ce qu'ils utilisent maintenant comme fonctionnalité de base.

Tous les 380 commentaires

d'accord, mais c'est peut-être une solution d'optimisation de la mémoire

+1

Je ne suis pas s√Ľr de comprendre la demande; c'est un √©diteur de code l√©ger, pas un IDE ... pourquoi auriez-vous besoin d'ouvrir plusieurs dossiers "projet" qui ne sont pas hi√©rarchiques (o√Ļ vous pouvez d√©finir le chemin de travail vers un parent mutuel)?

Si vous travaillez sur des modules qui sont stock√©s de mani√®re disparate sur le disque et qui interagissent d'une mani√®re ou d'une autre les uns avec les autres √† ce degr√©, alors ils sont trop √©troitement coupl√©s pour commencer ... vos projets sont-ils fr√®res? Si c'est le cas, ouvrez simplement le dossier parent, ou le dossier parent / parent ... o√Ļ que se trouve la racine de votre ¬ęsolution¬Ľ.

Eh bien, si vous avez un certain nombre de modules (qui sont tous dans leur propre référentiel git) qui sont indépendants les uns des autres mais que vous avez un référentiel qui utilise ces dépendances, il est logique de pouvoir ouvrir ces dossiers indépendants et d'apporter des modifications qui être reflété afin que vous puissiez le tester localement. Ce serait toujours un éditeur de code léger mais plus utile à mon humble avis!

Le principal probl√®me avec la d√©finition du projet en tant que parent est que l'int√©gration git dispara√ģt, il existe d'autres cas d'utilisation valides au-del√† des deux ayant un parent mutuel.

@stoffeastrom sonne comme un cas d'utilisation pour les sous-modules; Je ne sais pas comment votre projet en ferait référence à un autre, à moins que vous n'utilisiez un alias avec un mécanisme, tel que la liaison npm, etc. Ce problème est ce que les gestionnaires de paquets sont en grande partie destinés à résoudre. Si les modules sont étroitement couplés, alors ils ne sont vraiment pas des modules isolés. Vous ne seriez pas en mesure d'apporter des modifications de manière fiable pour soutenir un projet sans vous soucier des conséquences du changement pour les autres consommateurs sur la route. Même avec des sous-modules, ils sont en lecture seule par défaut pour exactement cette raison.

En tout cas, ce que @Tyriar vient de mentionner est l'une des raisons pour lesquelles je me méfie d'avoir ce type d'interface de chemin multi-travail dans une seule instance / fenêtre: vous devez gérer les intégrations (comme git), les extensions, le refactoring, le débogage, etc., etc., le tout de manière isolée. Par exemple:

Si j'utilise l'intégration git pour valider, est-ce que je valide le projet A ou le projet B?
Si je refactore un nom de classe dans TypeScript, doit-il refactoriser dans le projet A ou le projet B, ou les deux? Que faire si le même nom de classe existe dans les deux projets avec des significations différentes? Et si l'un faisait vaguement référence à l'autre?

Ce ne sont que quelques exemples de la façon dont quelque chose d'apparemment simple peut devenir très compliqué, très rapidement. Je pense que ce serait beaucoup plus déroutant et, franchement, moins utile que d'alt-tab / cmd + tab entre quelques instances distinctes de VSCode, chacune gérant joyeusement son propre chemin de travail isolé sans tous les efforts supplémentaires et les problèmes de cas extrêmes.

Je ne dis pas que cela n'a pas pu être résolu, mais je ne comprends pas très bien pourquoi le basculement entre plusieurs fenêtres et / ou instances est un problème. Peut-être que je manque quelque chose ...

Sublime, Atom, Webstorm - ce sont aussi des éditeurs de code "légers" (sauf peut-être Webstorm) et ils permettent d'ouvrir plusieurs dossiers racine à partir d'emplacements différents. Ces éditeurs représentent probablement 99% de ce que les développeurs Web utilisent.
Le code peut rivaliser avec eux avec un bien meilleur support de Typescript (et il sera très populaire si Angular 2 arrive), mais seulement s'il donne aux développeurs ce qu'ils utilisent maintenant comme fonctionnalité de base.

+1

+1

En tant que développeur Go, je trouve cette fonctionnalité extrêmement utile dans Sublime ou IntelliJ Idea. Par exemple, mon petit projet importe du code de la bibliothèque principale de Go ou peut importer une bibliothèque tierce. Je dois donc pouvoir y accéder rapidement et lire ce code.

+1. Les solutions de microservices de repo multi-git sont très pénibles dans VS Code pour le moment, en pensant à trouver un autre IDE compatible Typescript à la place.

Nous avons certainement besoin d'une sorte de ¬ęsolution¬Ľ. Je suis un d√©veloppeur natif, et cela implique presque toujours de cr√©er un ensemble de biblioth√®ques / dll et de s'y r√©f√©rer √† partir d'un projet d'application h√īte.
Une fois que nous avons plusieurs projets, nous avons √©galement besoin d'un ¬ęprojet de d√©marrage¬Ľ lorsque nous appuyons sur ¬ęex√©cuter¬Ľ.

Je souhaite √©galement un support pour des projets et plusieurs racines git. Le code que j'utilise fr√©quemment se trouve dans plusieurs d√©p√īts git et √™tre incapable de basculer entre eux sans fermer mon espace de travail actuel et en ouvrir un autre juste pour faire demi-tour et fermer celui-ci pour ouvrir le pr√©c√©dent est √©puisant. Si j'ajoute le dossier parent o√Ļ tous mes d√©p√īts sont h√©berg√©s, je gagne la possibilit√© de naviguer et de rechercher parmi mes fichiers, mais je perds l'int√©gration git. C'est vraiment d√©cevant.

La ligne entre "éditeur de texte" et "IDE" est assez floue et je ne me soucie pas vraiment de ce que VS Code est étiqueté. Ce qui m'importe, c'est ce qu'un outil peut faire et à quel point il est indolore à utiliser. Je pense que l'ajout d'un support de projet soulagerait beaucoup de frictions pour des gens comme moi.

J'aimerais √©galement voir l'int√©gration git fonctionner lorsque votre espace de travail contient plusieurs d√©p√īts, mais je veux juste m'assurer que des gens comme @ Loren-Johnson se rendent compte qu'ils peuvent avoir plusieurs fen√™tres de code ouvertes simultan√©ment.

Ceci est en réponse à: "impossible de basculer entre eux sans fermer mon espace de travail actuel"

Vous voulez dire que # 2686 est un double de ceci?

Désolé, j'ai mal lu la description et j'ai rouvert celle-ci.

+1

Y a-t-il des progr√®s sur cette question, ou au moins une d√©claration si cela sera jamais mis en Ňďuvre? Y a-t-il des d√©cisions de bas niveau dans le code qui emp√™chent plusieurs racines dans un projet?

C'est à peu près la seule raison pour laquelle je ne passe pas de ST3 à VSCode.

+1

+1

+1

+1 ce serait très utile. La suggestion d'utiliser des sous-modules git est très gênante. J'adorerais avoir cette fonctionnalité.

Une approche légère initiale serait quelque chose de similaire à ce que fait l'extension git-project-manager . L'approche pourrait être de changer fondamentalement le contexte / racine pour ce que git considère comme des changements, mais sans changer le contexte / racine pour ce que le navigateur de fichiers voit. Cette extension fonctionne parfaitement, a juste besoin d'une intégration plus étroite pour rendre la commutation plus rapide.

+1

+1 - J'ai commencé à utiliser les sous-modules git, mais cela ressemble plus à un hack qu'à une solution réelle.

+1

+1

J'utilise l'extension git-project-manager pour basculer entre les dossiers, mais j'aimerais vraiment avoir une option pour ouvrir plusieurs dossiers à la fois.
+1

Je veux juste dire que le propriétaire de l'extension Project Manager attend également ce problème.

En ce qui concerne certains des commentaires (ci-dessus), je veux juste dire que nous sommes tous différents, nous avons tous nos façons particulières d'exécuter notre travail sur nos projets particuliers. Ce fait rend l'UX plus important qu'il ne l'est déjà.

Nous savions tous que "Ouvrir le dossier ..." n'√©tait que la premi√®re √©tape pour avoir in√©vitablement une gestion de projet dans vscode avec des choses comme "Ouvrir un projet ...", etc. Tout comme tous les autres √©diteurs, en particulier SublimeText (d'o√Ļ je viens).

Pour moi, ce problème est une amélioration de l'UX du produit. Et nous savons tous que l'UX est roi.

J'ai presque l'impression que ce genre de choses devrait √™tre la loi, et donc la balise "demande de fonctionnalit√©" devrait plut√īt √™tre "rappel de fonctionnalit√©".

Ce problème doit être prioritaire par rapport à tout autre problème dans vscode. Non seulement parce que l'UX est roi, mais parce que je ne rencontre actuellement aucun autre problème avec vscode que celui-ci ... techniquement.

Au départ, je cherchais à demander à Microsoft de reprendre ces extensions de type projet et de les intégrer directement dans VSCode, et d'améliorer son UX, par exemple en ajoutant "Projets ..." au menu.

Merci,
+1

+1

Mon cas d'utilisation de cette fonctionnalité est décrit ici: # 9515. (Il a été fermé en tant que double de ce numéro.)

J'espère que cette fonctionnalité se produira!

+1

@ poidl, @ mastrauckas , @mdedgjonaj , @alanleite , @Xcorpio , @mibanez , @josebalius et @brusbilis :
Il y a quelque temps, GitHub a présenté la jolie fonctionnalité "Ajoutez votre réaction" (voir le smiley dans chaque coin supérieur droit d'un commentaire ou le problème lui-même?).
Celles-ci ont pour but d'informer l'équipe VSCode de votre intérêt mais évitent les commentaires +1 sans signification. Cela empêche également les autres personnes qui ont souscrit un certain problème ou MR de recevoir une notification et économise donc un temps précieux. Un autre avantage est que les problèmes / MR peuvent être triés par most reaction ce qui rend instantanément visible pour l'équipe VSCode ce qui est pertinent pour les utilisateurs. En plus de cela, il y a même un Uservoice pour VSCode .

Ce commentaire lui-m√™me est m√©ta et donc d√©nu√© de sens aussi. Je suis d√©sol√© mais j'ai pens√© que c'√©tait n√©cessaire √† des fins √©ducatives. Chaque r√©ponse directe √† ce commentaire (= plus de m√©ta) entra√ģnera le blocage de l'utilisateur.
Exercice en ne réagissant à ce commentaire qu'en utilisant la fonctionnalité reaction !

À la réponse de @poidl : Alors ne répondez pas du tout!

Je ne vois pas ce smiley. Au moins sur mobile. Bon blocage!

@poidl oui la fonction de réaction n'est malheureusement pas disponible sur le site mobile de GitHub (avec de nombreuses autres fonctionnalités). Vous pouvez y accéder sur mobile en cliquant sur le bouton "Version bureau" en bas du site.

Les conseils de @ dj-hedgehog sont parfaits, cependant, les réactions de GitHub nous permettent d'évaluer l'intérêt de la communauté pour quelque chose de plus efficacement que le nombre de commentaires. De plus, nous prévoyons de déprécier User Voice afin que les problèmes et les réactions de GitHub soient notre source de vérité pour les demandes de fonctionnalités.

+1

+1

Ma solution à ce problème: créer un lien symbolique vers la racine de mon projet.
Donc si j'ai:
project/modules/gitmodule

Je vais dans mon dossier gitmodule et fais:
ln -s ../../../project .project

Maintenant, je peux ouvrir mon dossier gitmodule dans vscode et avoir toujours accès au dossier du projet parent.
J'utilise un point dans le nom du fichier pour qu'il trie en haut de ma liste dans l'explorateur.
√Čvidemment, je pr√©f√©rerais ne pas avoir √† faire cela, mais j'ai pens√© que cela pourrait √™tre utile pour certains d'entre vous.

Presque oublié: n'oubliez pas d'ajouter le lien symbolique à votre .gitignore

+1

C'est une fonctionnalit√© tr√®s importante pour un √©diteur de texte moderne. Veuillez r√©soudre ce "probl√®me" s'il vous pla√ģt.
Pendant un certain temps, j'ai d√Ľ copier et coller tous les r√©pertoires utilis√©s dans mon dossier de travail r√©el et cela dans Sublime Text est tellement trivial.

Projet> Ajouter un dossier au projet à Sublime Text incrémente un nouveau chemin vers la structure Json.

Regardez ci-dessous:
{ "folders": [ { "path": "~/cpp" }, { "path": "~/python" } ] }

Lorsque vous travaillez avec chef par exemple, il est courant de voir une structure de dossiers comme:

‚ĒĒ‚ĒÄ‚ĒÄ cookbooks
    ‚Ēú‚ĒÄ‚ĒÄ cookbook1
    ‚Ēú‚ĒÄ‚ĒÄ cookbook2
    ‚Ēú‚ĒÄ‚ĒÄ cookbook3
    ‚ĒĒ‚ĒÄ‚ĒÄ cookbook4

O√Ļ les livres de recettes (cookbook1 par exemple) sous le dossier racine (livres de recettes) sont les d√©p√īts git ind√©pendants. Ceci est tr√®s courant. Vous devez maintenant travailler sur cookbook4 mais il inclut cookbook2 et cookbook3. Vous devrez souvent ouvrir les 3, soit simplement pour faire r√©f√©rence au code, soit pour modifier ou refactoriser le code dans les 3.

Les 2 options normales (pas les hacks de lien symbolique) présentent des problèmes qu'aucun développeur ne veut:

  1. Comme mentionné ci-dessus à plusieurs reprises, vous devrez maintenant ouvrir plusieurs fenêtres (pas bon)
  2. Si vous ouvrez des livres de recettes en tant que root pour voir les 3, vous perdez l'int√©gration git car le dossier des livres de recettes n'est pas un d√©p√īt obtenu (pas bon non plus)

+1, utilisateur Eclipse IDE ici qui dispose d'un contr√īle complet de l'espace de travail.

Visual Studio Code n'est pas un IDE. C'est un éditeur multiplateforme léger, comme Atom ou Sublime. Eclipse, Xcode, Visual Studio, et. tous sont des mastodontes en comparaison.

Désolé, je ne sais pas si vous vous disputez contre ou pour cette fonctionnalité ... Atom, Sublime, VIM, Emacs vous permettent d'ouvrir plusieurs dossiers en une seule instance. Léger ou pas c'est une bonne fonctionnalité, IntelliJ IDEA - un IDE - par exemple ne vous permet pas d'ouvrir encore plusieurs projets.

@dmccaffery les fonctionnalités demandées ici ne sont pas que des fonctionnalités IDE, les fonctionnalités demandées sont communes à tous les _editors_ dont vous avez dit que Visual Studio Code est _like_.

Atom, Sublime et d'autres éditeurs légers peuvent tous ouvrir plusieurs dossiers.

Personnellement, je ne me soucie pas de savoir si cette fonctionnalité se retrouve dans le produit ou non - je comprends pourquoi certaines personnes la veulent, mais je tiens à souligner que cela rend tout un peu plus compliqué. Par exemple: lors d'une recherche à l'aide d'une expression regex - quel espace de travail suis-je en train de rechercher? une? tout?

Que faire si j'ai un dossier contenant un projet nodejs o√Ļ ma largeur de tabulation est g√©n√©ralement de 2 espaces, et un dossier est un projet dotnet o√Ļ ma largeur de tabulation est de 4 espaces? Le code doit conna√ģtre les param√®tres de l'espace de travail pour chaque dossier et maintenir le contexte tout au long.

Ce ne sont l√† que quelques exemples o√Ļ plusieurs espaces de travail dans une seule instance peuvent √™tre difficiles. Tout ce que je dis, c'est que cette fonctionnalit√© est beaucoup plus impliqu√©e que le simple fait d'afficher plusieurs chemins dans l'explorateur.

@dmccaffery pas plus compliqué que sublime et atom. Tout cela devrait être configurable, même les largeurs d'onglet par espace de travail. La recherche dans atom et sublime peut être uniquement dans le fichier courant, dans cet espace de travail, etc ... c'est votre choix.

Voici un fait, qu'on le veuille ou non et cela n'a rien à voir avec ce que vous ou moi voulons. Si d'autres logiciels similaires à des prix similaires (gratuits dans ce cas) ont de meilleures ou plus de fonctionnalités et que le développeur néglige ce fait, .. ce logiciel sera laissé pour compte.

Pour ma part, je ne voudrais pas que cela arrive à cet éditeur. Je pense que cet éditeur a un très bon potentiel et peut rester pertinent pendant un certain temps _si_ les développeurs écoutent les désirs / besoins de sa base d'utilisateurs.

Encore; Je ne discute pas pour ou contre - gardez simplement à l'esprit qu'il s'agit d'un tout nouvel éditeur avec beaucoup plus de contexte original que ses concurrents - laissez-lui un peu de temps.

Même dans votre exemple avec l'intégration chef et git - comment maintenez-vous le contexte quant au repo dans lequel vous vous engagez? L'interface utilisateur actuelle devrait s'adapter au changement de contexte constant - même chose pour OmniSharp, qui utilise un serveur et Roslyn pour fournir la coloration syntaxique, etc. pour les projets CoreCLR. Les implications sont profondes et devront être bien pensées.

Aucun argument sur l'id√©e que les fonctionnalit√©s doivent √™tre bien planifi√©es et bien pens√©es. C'est une donn√©e, je pense. Je pense que tous les utilisateurs seraient heureux si la r√©ponse ici √©tait ¬ęc'est sur la feuille de route¬Ľ ou ¬ęnous travaillons √† cette fin¬Ľ. Tout ce que je dis, c'est qu'un "non" tuerait probablement pas mal d'utilisateurs pendant la nuit.

En ce qui concerne le changement de contexte et git repos dans chef, oui d'accord ... tout cela est vrai et tout est déjà accompli dans d'autres éditeurs open source. Vous connaissez la grande chose à propos de l'open source, c'est ouvert! Regardez le code, trouvez des idées, et utilisez-en une partie (assurez-vous d'inclure les licences si nécessaire). C'est l'un des avantages de foss (logiciel open source gratuit), de la collaboration et du partage des connaissances. Puisque cet éditeur utilise déjà le code atom ... je pense que ce serait également une donnée.

J'ai trouvé cela mentionné dans https://github.com/Microsoft/vscode/wiki/Roadmap

VS Code est un produit jeune et il manque encore des fonctionnalités et des expériences que vous demandez et que nous voulons offrir.
....
....

  • Plusieurs dossiers dans un seul espace de travail

Je pense que personne ne dit que cette fonctionnalité est simple (comme nous sommes tous développeurs, nous pouvons savoir ce qui doit être changé) et les invités commentent ce ticket veulent juste montrer à quel point il est important, quelle priorité devrait-il être, et comment comparer cette fonctionnalité à certains frères VS Code (Atom, Sublime par exemple).

Mais comme cela figure déjà dans la feuille de route (tout le monde peut confirmer que la page wiki est toujours correcte), nous devrions discuter de la façon de l'implémenter au lieu de simplement dire comment nous en avons besoin et à quel point c'est important (comme encore, je suppose que l'équipe de base de VS Code est déjà savoir comment nous en avons besoin et à quel point cette fonctionnalité est importante).

Je ne connais pas le code source de VS Code, quelqu'un peut-il me dire si je veux impl√©menter cette fonctionnalit√©, o√Ļ dois-je chercher en premier? √Ä la premi√®re √©tape, je veux simplement ouvrir plusieurs dossiers et les afficher dans la barre de gauche.

@nvcnvn ce n'est pas aussi trivial que cela puisse para√ģtre d'impl√©menter cela, car beaucoup de vscode supposent qu'un seul dossier peut √™tre ouvert. En tant que tel, il devra passer par UX et toucher probablement de nombreuses parties de la base de code, avec potentiellement des impacts sur l'API d'extension.

Je me souviens quand Atom est sorti, avec la même limitation de _single folder_. Les plaintes étaient également les mêmes, spécialement les comparaisons avec Sublime. Ensuite, lorsque la prise en charge des _ dossiers multiples_ a été publiée, certains packages (extensions) ont été endommagés, en raison de la nouvelle API. D'autres n'ont pas cassé mais ne l'ont pas non plus supporté. Il a fallu un certain temps avant qu'il ne devienne stable dans tout l'écosystème.

Comme l'a dit @Tyriar , il y aura un impact sur l'UX et l'API d'extension, et sera probablement une version _Insider_ occupée pour les développeurs de noyau et d'extensions, pour adopter la nouvelle API.

Alors, qu'est-ce qui est exactement discuté ici?
Je veux dire tout ce que je vois, c'est "ne pas apporter d'améliorations car cela pourrait casser des choses" ...

Allusion:
TOUTES LES AM√ČLIORATIONS DU CODE PEUVENT BRISER QUELQUE CHOSE!

C'est le point du débogage, du refactoring, des pré-versions (alpha, beta, rc, etc ...)
Allez, sérieusement? Je n'ai jamais rencontré un programmeur sérieux qui avait peur d'améliorer le code car cela risquait de casser quelque chose. Soyez prudent oui, prenez votre temps et soyez prudent oui, mais ne dites jamais "non, ça pourrait casser des choses" lol

@ddreggors Je ne @nvcnvn n'essaye pas de construire un PR pour cela car cela devra être fait par l'équipe en raison de la liste des parties prenantes.

Comme @nvcnvn l'a soulign√©, ce probl√®me est sur la feuille de route, ce qui signifie que l'√©quipe l'examinera bient√īt. Nous sommes une √©quipe relativement petite avec beaucoup de choses √† couvrir, donc certaines choses doivent √™tre retard√©es.

@Tyriar Compris, je continue de voir ces commentaires de plusieurs personnes qui semblent sugg√©rer qu'il est pr√©f√©rable de ne pas ajouter cette fonctionnalit√© pour une raison ou une autre. Le pire √©tait d√Ľ au fait que le code n'est pas un IDE, alors que d'autres comparaient clairement d'autres √©diteurs et non des IDE. Cela m'a donn√© envie d'aller √† la racine de la peur de ce changement pour le d√©passer si possible.

Je peux comprendre le souci que ce PR ne soit pas complet, mais cela pourrait être un bon début ... fusionner ce changement dans une branche et l'utiliser comme base. Utilisez-le pour voir les bris et les réparer.

@ddreggors, ce serait un effort réunions UX

Assez juste, vous sauriez mieux à cette fin. Il est bon de savoir que cela est en cours de discussion. :-)

Merci pour vos efforts et ce qui ressemble au début d'un très bon éditeur.

Suggérer ce sujet pour vos réunions UX semble également être un effort

Je suis temporairement revenu √† Atom car il est devenu beaucoup plus stable dans la version 1.9. Il avait l'habitude de planter quand un fichier volumineux √©tait ouvert et c'√©tait la raison principale au d√©but de l'extraction de VSCode √† un moment donn√©. J'ai vraiment h√Ęte de voir plusieurs projets dans une seule fen√™tre - il semble que je n'ai rien √† faire √† part suivre ce fil jusque-l√†.

Pourquoi les gens de Microsoft ne se concentrent-ils pas là-dessus?

+1

+1

J'adore vraiment VS Code. C'est devenu mon éditeur principal, mais la difficulté de travailler sur plus de 2 projets à la fois devient déconcertante. Il y a un double coup dur sur ces deux problèmes en suspens: celui-ci et la configuration des informations de la barre de titre .

L'une ou l'autre de ces fonctionnalités résoudrait le problème (même si idéalement, j'aimerais les deux!). Cela ne me dérange pas de mettre tout ce avec quoi je travaille dans un seul dossier et de l'ouvrir - mais l'intégration git ne fonctionne pas, et il n'y a pas de moyen simple de rechercher dans un seul projet ou d'organiser les résultats par projet.

Cela ne me d√©range pas d'ouvrir chaque projet dans une fen√™tre VS Code physique diff√©rente et de laisser mon syst√®me d'exploitation g√©rer les instances - mais comme la barre de titre affiche d'abord le nom du fichier ouvert, plut√īt qu'un identifiant de dossier racine / projet, il est impossible de passer √† un autre projet ouvert sp√©cifique sans ouvrir et regarder chaque instance active. Cela fait de quelque chose qui devrait √™tre sans effort un ennui constant.

S'il vous pla√ģt - y a-t-il un moyen d'ajouter l'une de ces deux fonctionnalit√©s peut devenir une priorit√©? J'ai essay√© tout ce que je pouvais penser pour contourner ce probl√®me, j'ai m√™me pass√© une heure √† chercher une alternative √† la barre des t√Ęches Windows qui me permettrait de choisir des fen√™tres dans une liste qui pourrait afficher plus de texte dans la barre de titre mais je ne trouve pas n'importe quoi.

Si quelqu'un a des suggestions sur la façon de gérer efficacement plusieurs projets VS Code ouverts, je serais ravi de les entendre.

La chose importante qui fonctionne bien dans Atom est que les plugins, tels que eslint, doivent toujours fonctionner au niveau du projet. Donc, si le projet A a ses propres r√®gles eslint, le projet B ne devrait pas √™tre affect√© par ces r√®gles et vice versa. J'ai h√Ęte d'avoir un tel UX dans Code. C'est certainement l'un des plus grands obstacles √† l'adoption √† l'heure actuelle.

C'est la seule chose qui me pousse à l'adopter.

Je sais que vous pouvez avoir beaucoup d'autres problèmes à résoudre et d'autres fonctionnalités à implémenter, mais au moins un support de base pour commencer serait génial.

Merci pour le travail acharné sur VSCode!

+1

Jusqu'√† ce que cette fonctionnalit√© soit mise en Ňďuvre (le cas √©ch√©ant), puis-je vous sugg√©rer d'ajouter simplement la possibilit√© de configurer la barre de titre pour afficher le nom du projet avant le nom du fichier. De cette fa√ßon, il sera au moins possible de faire la distinction entre les diff√©rentes fen√™tres de vscode ouvertes pour les diff√©rents projets. Voir # 1723 .

C'est aussi un obstacle pour moi. Je vois que certains d√©veloppeurs se demandent pourquoi vous avez plusieurs d√©p√īts git √† la fois. Cela se produit avec presque tous les langages qui utilisent des modules tiers. Il suffit de regarder php - composer, js - bower, node - npm, golang etc. Il est tr√®s courant de d√©marrer un projet qui utilise certains de vos modules et vous voulez √©diter et valider les changements dans la port√©e du projet.

Existe-t-il au moins un support pour reconna√ģtre .vscode/settings.json dans les r√©pertoires imbriqu√©s. Lorsque vous travaillez sur un seul projet, il peut y avoir des sous-arborescences avec diff√©rents ensembles de param√®tres et qui proviennent de diff√©rents r√©f√©rentiels (git). par exemple

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/

Je m'attendrais à ce que vscode prenne (et fusionne peut-être) les paramètres du répertoire parent le plus proche comme beaucoup de fichiers de configuration ( .eslint , .gitignore , .editorconfig , tsconfig.json , 'package.json` ....).

Ainsi, quand j'ouvre /root , alors n'importe quel fichier dans root/server/ doit être traité comme si root/server/ directement .vscode/settings.json fichier

C'est vraiment nécessaire.

+1. Dealbreaker pour moi.

C'est vraiment nécessaire. +1

il existe une solution de contournement pour imbriquer des dossiers dans un espace de travail vscode. juste pour créer un lien symbolique vers le dossier de l'espace de travail, comme ceci mklink /d link target

Je suis d'accord - je pense que cette demande est une exigence définitive.
Vous n'avez pas toujours un projet dans un seul dossier - vous pouvez avoir des dossiers auxiliaires et frères et ne pas avoir cette fonctionnalité est un véritable facteur de rupture pour mon tout à l'heure - c'est pourquoi je dois utiliser sublime.
Veuillez l'ajouter!

Sur le c√īt√© gauche, vous affichez le dossier dans lequel vous vous trouvez en tant que projet. Cela pourrait fonctionner si vous l'aviez l√† o√Ļ vous pouvez voir chaque zone de dossier (projet) ouverte. Vous pouvez le d√©velopper et le r√©duire comme vous le faites maintenant (mais pour plusieurs zones de dossier).

Un éditeur génial si seulement je pouvais basculer entre deux projets. Un vrai Dealbreaker.

Salut à tous, je recommande l'extension Git Project Manager si vous passez beaucoup d'un projet à l'autre entre-temps. Il scanne un répertoire pour les répertoires contenant un dossier .git et permet de basculer rapidement vers eux, je l'utilise depuis quelques semaines et cela facilite certainement les choses.

Lorsque je change de projet, je vais soit:

  1. ctrl + alt + p
  2. Tapez le début du projet, par exemple. "vsc" pour vscode
  3. entrer

Ou si je veux ouvrir le projet dans une autre fenêtre, j'ai appuyé sur shift + n au préalable. Vous pouvez configurer l'extension pour qu'elle s'ouvre toujours dans une nouvelle fenêtre si c'est aussi votre truc.

untitled-1

Ceci est une capture d'écran sur la façon dont vous pouvez facilement avoir plusieurs projets.

@ soljohnston777 le problème est que l'intégration git (ou tout autre type de configuration de code VS) n'est pas prise en charge au niveau du dossier.

le problème est que l'intégration git (ou tout autre type de configuration de code VS) n'est pas prise en charge au niveau du dossier.

Hein vraiment? VSCode a-t-il répété les erreurs d'éclipse commises en ce qui concerne le concept d'espace de travail? Ce serait surprenant, sachant que bon nombre de membres de l'équipe VSCode ont fait partie de l'équipe principale de l'éclipse ...

VSCode a-t-il répété les erreurs d'éclipse commises en ce qui concerne le concept d'espace de travail

Je ne peux pas parler de la philosophie des architectes ici, mais ce fait (cette configuration est par instance et non par dossier) est la raison entière de ce problème et de cette discussion.

Vous pouvez utiliser des fenêtres VScode distinctes pour les projets. Pourquoi ne pas l'implémenter comme ça dans VSCode? (Fenêtre séparée par bouton de projet latéral - il suffit de le référencer à l'intérieur). Cela éviterait les tracas de le coder dans le programme, mais les projets apparaissent à l'intérieur et le rendraient facile à intégrer et à développer.

Git peut être placé indépendamment pour chaque zone de dossier pour plusieurs projets ... Je trouve que le git est déroutant avec VSCode, donc j'ai tendance à simplement faire la ligne de commande de toute façon (ce qui semble que vous devriez pouvoir le faire dans VSCode).

Avoir un dossier parent contenant des sous-dossiers qui sont des référentiels git indépendants est vraiment utile lorsqu'ils appartiennent tous au même projet. Voudrait voir cela disponible, au moins avec un indicateur de configuration facultatif dans les paramètres.

J'aime aussi exprimer mon vif int√©r√™t pour le support git pour plusieurs d√©p√īts git.

+1. C'est une fonctionnalité principale qui empêche mon adoption de VSCode en tant qu'éditeur principal.

+1

+1 - en particulier pour les personnes qui travaillent avec des bases de code microservices / many-repo, c'est la clé. (Clé: ne pas les avoir tous ouverts en même temps, mais basculer entre eux et faire en sorte que l'éditeur se souvienne quels fichiers étaient ouverts et dans quels espaces de travail.)

+1
Notre configuration est quelque chose comme le code de base dans le d√©p√īt GIT, du code r√©gional dans un autre d√©p√īt et du code sp√©cifique au projet dans un autre d√©p√īt.Ainsi, lorsque vous travaillez sur un projet, vous devez coder √† partir des trois d√©p√īts (ou plus). Ne pas pouvoir avoir un ¬ęprojet¬Ľ avec ses propres param√®tres sp√©cifiques et la possibilit√© d'ajouter plusieurs dossiers √† partir de plusieurs sources, c'est le roi d'un bloqueur.

@danechitoaie comment savez-vous qu'une modification que vous apportez à votre référentiel principal ne casse pas quelqu'un d'autre qui en dépend pour une région ou une base de code de projet différente? Cela semble être une façon dangereuse de travailler; il devrait y avoir une gestion des versions distincte utilisant une sorte de système de gestion de paquets ou autre.

Ne pas argumenter contre une certaine implémentation d'espaces de travail, mais un système de projet complet ajoute une bonne dose de complexité.

D'accord, c'est le cas et ils devraient / pourraient faire beaucoup de choses beaucoup mieux, mais ... c'est hors de notre contr√īle ou de notre capacit√© √† prendre des d√©cisions.

Compris. J'adore quand ce genre de chose se produit.

b2r1ifriyaa-bnh
Que dis-tu de ça?

Pour moi, un simple bouton interrupteur comme celui-là ne suffit pas. Si nous avons besoin de ce simple, ouvrez 2 instances (ctrl shift N), puis utilisez la touche de raccourci de votre système d'exploitation pour basculer entre les fenêtres / espaces de travail est à peu près la même chose.
J'adore avoir quelque chose qui facilite la comparaison des fichiers, la structure des projets, quelque chose m'aide à faire rapidement des modifications mineures et à créer et à conserver tous les différences dans le même écran, capable d'annuler les modifications pour tous les projets avec lesquels je travaille.

+1

+1

Type de solution de contournement pour macOS Sierra.

Un onglet par projet dans une fenêtre en définissant Prefer tabs when opening documents sur Always dans les paramètres du dock. Mais cela affectera également le comportement des autres applications.

+1

Cela devient un tueur pour moi. J'adore le programme, mais mec je n'aime pas un programme ayant juste une fenêtre ...

Honn√™tement, j'ai d√Ľ arr√™ter d'utiliser Code car autant que je l'aime, il est devenu trop encombrant de changer de fen√™tre.

Si cela se corrige à l'avenir, je vais essayer à nouveau, jusque-là, c'est un frein pour moi et chaque personne que j'ai testé.

+1

+1

Veuillez préférer: +1: réactions sur le commentaire d'origine du problème car cela nous aide à prioriser et n'envoie pas de notifications à tous ceux qui écoutent le problème pour des mises à jour.

+1

J'utilise actuellement Sublime et j'essaye Code. Cela a l'air et se sent bien, mais l'int√©gration de Git √† un seul projet est un facteur d√©cisif. J'ai un projet Hadoop / Oozie, et j'ai donc un d√©p√īt de code et un autre de notes de travail. Dans Sublime, je les ai tous les deux ouverts dans la m√™me fen√™tre et je peux m'engager dans le d√©p√īt Git appropri√© pour chaque

alors, ce sera bien d'ajouter

+1 oui, critique dans le monde des microservices, il est habituel d'avoir 3..4 d√©p√īts ouverts en m√™me temps

Rappel hebdomadaire: arrêtez de publier des commentaires avec +1. Au lieu de cela, donnez un coup de pouce au problème initial, qui est en fait compté.

Je sais que vous vouliez tous bien. Alors n'hésitez pas à supprimer votre commentaire +1 pour qu'il ne prenne pas de place dans cet important dossier historique!

@jamietre j'ai essayé ... dur:

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

Peut-être qu'une autre alternative est de verrouiller ce problème mais de rester ouvert jusqu'à ce qu'il soit résolu? De cette façon, nous connaissons l'importance du problème (je dirais que nous avons déjà assez de +1 pour cela), mais nous ne pouvons pas ajouter à l'encombrement / redondance (par exemple, plus de commentaires autorisés).

Bien que ce soit une fonctionnalit√© rarement utilis√©e, je pense, je ne suis tomb√© sur le verrouillage que sur un projet / d√©p√īt public sur Github.

Le verrouillage pourrait être déverrouillé lorsque cela est jugé nécessaire, si jamais.

@daluu voici comment fonctionne le repo / aspnet / annonce; chaque num√©ro est imm√©diatement verrouill√©. Cela √©tant dit, GitHub devrait faire quelque chose dans l'interface utilisateur pour au moins conduire les gens vers des alternatives au-del√† du simple "+1", car des r√©actions existent maintenant. ūüĎć

Il est très utile de mettre la fonction multi-fenêtres dans son ensemble, lorsque l'on regarde les documents de plus de deux projets,

approche int√©ressante du probl√®me. J'ai √©t√© programmeur VB / .net pendant de nombreuses ann√©es, j'ai ador√© les langages et les outils, mais je suis absent depuis quelques ann√©es chez Hadoop / Spark / Scala / Intellij / Sublime-land. J'√©coute toujours DotNetRocks, j'aime me tenir au courant de ce qui se passe, et j'√©tais int√©ress√© d'entendre parler de cette application Code. Du c√īt√© positif, c'est un tr√®s bon √©diteur, avec de jolies fonctionnalit√©s Git, mais c'est malheureusement totalement hors de propos. Parce qu'il ne g√®re pas Git pour plusieurs projets dans le m√™me espace de travail, comme le fait tr√®s √©l√©gamment Sublime, alors je ne peux tout simplement pas l'utiliser

Cela arrive. Ce qui me surprend le plus, c'est la réaction ici, d'abord pour affirmer que ce n'est pas une fonctionnalité nécessaire, puis la majeure partie de la discussion semble désormais porter sur "comment pouvons-nous empêcher les gens de publier +1"

Je vais vous dire comment vous faites cela - vous corrigez un probl√®me de base qui a √©t√© soulev√© pour la premi√®re fois il y a un an! Cela s'appelle ¬ę√©couter les commentaires¬Ľ. Ce n'est pas parce que vous n'√™tes pas personnellement touch√© par un probl√®me qu'il n'existe pas. Si vous ne voulez pas qu'un groupe d'utilisateurs particulier utilise l'application, alors tr√®s bien, mais ne nous donnez pas de m√©canisme de r√©troaction, puis contestez notre probl√®me et soyez ennuy√© contre nous de continuer √† le demander.

Je recommence à utiliser Sublime

Le problème "+ 1" peut être résolu avec le code suivant: if (post_message == "+1") {add_smiley_reaction (); delete_post_message (); }

Cher GitHub, je suis disponible à la location.

ouais, cela ne sera jamais r√©gl√©, n'est-ce pas. Il est beaucoup plus facile de se moquer et d'ignorer les commentaires ¬ę+1¬Ľ plut√īt que de r√©soudre le probl√®me central, les logiciels √©tant commercialis√©s aupr√®s d'une section particuli√®re de d√©veloppeurs qui ne font pas ce dont ils ont besoin pour √™tre productifs ...

il suffit de lire celui-ci "Chaque réponse directe à ce commentaire (= plus de méta) me fera bloquer l'utilisateur." - voilà comment gérer les retours! Mettez vos doigts dans vos oreilles et dites "ne peut pas vous entendre!"

cher Seigneur

@ kryps1 alors les gens ajouteront "+ 1" ou "++ 1" ou "1+" ou "bump" ou "Oui, s'il vous pla√ģt. +1". Quoi que vous fassiez, les gens trouveront un moyen de contourner cela. Ce n'est pas aussi simple que vous le pensez.

Arr√™tez avec le d√©bat inutile de +1 s'il vous pla√ģt ... Concentrez-vous sur ce qui est n√©cessaire ici, √† savoir plusieurs projets dans l'explorateur.

Pour le problème git , il suffit de le diviser de la même manière que l'explorateur (c'est-à-dire par cwd).

Ne commençons pas une guerre des flammes pour les +1. Ce serait vraiment bien si cette question était prioritaire.

Mais je voudrais mentionner √† la communaut√©, je suppose que les PR et les contributions sont les bienvenus ;-) quelqu'un peut corriger / r√©parer le code si les d√©veloppeurs principaux ne le comprennent pas. J'ai fait am√©liorer certains de mes projets (avec des fourches) parce que l'utilisateur / d√©veloppeur pr√©f√®re le faire lui-m√™me plut√īt que d'attendre que je fasse les am√©liorations qu'il aimerait me sugg√©rer. Donc, toute personne ennuy√©e par ce probl√®me et suffisamment comp√©tente / comp√©tente, veuillez corriger (puis soumettre un PR)? lol

Et revenons au sujet +1, remonter le probl√®me et ajouter votre opinion est une bonne chose, mais le +1 est un moyen boiteux de le faire s'il existe d'autres m√©thodes disponibles comme la fonction Thumbs up. Pensez √† une publication Facebook, ou √† la publication Google+ d'origine, et les utilisateurs / lecteurs ajouteront un commentaire +1 au lieu de cliquer sur J'aime (ou l'une des nouvelles r√©actions de Facebook), ou +1 pour Google+. Au fil du temps, c'est un long fil de commentaires de boiteux + 1, o√Ļ, en tant que lecteur, je peux peut-√™tre faire d√©filer pour afficher des commentaires int√©ressants, mais je finis par voir un tas de + 1. C'est ce qui se passait ici, je pr√©f√©rerais ne pas voir / lire ces +1, que je sois un d√©veloppeur de projet ou juste un utilisateur (ou que je recherche ce projet pour une utilisation potentielle).

Dans le même ordre d'idées, voici une utilisation idiote (mais de bonne intention) d'un problème de GH, Dieu merci, les gens n'ont pas tous donné +1 à ce sujet: https://github.com/sinatra/sinatra/issues/920

Je suppose que les RP et les contributions sont les bienvenus

Pas vraiment. Voir ce commentaire d'ao√Ľt: https://github.com/Microsoft/vscode/issues/396#issuecomment -241806158

Apparemment, cette question figure dans la feuille de route depuis au moins, mais aucun progrès n'a été enregistré. Ce serait bien d'entendre une mise à jour du statut de l'équipe VSCode.

Pour moi, et cela essaie de remettre le sujet sur les rails, plusieurs dossiers de projet sont nécessaires.

Dans Atom, il prend en charge GIT, et la seule façon de l'utiliser est de noter quels fichiers ont des modifications. J'ai un serveur Rackspace qui n'autorise pas SSH, donc les téléchargements manuels je vais. Cependant, je peux avoir plusieurs dossiers de projet dans la barre latérale, ce qui facilite grandement la référence au code que j'ai utilisé dans un projet précédent. Ou changez de vitesse pour un autre projet si j'ai besoin d'un répit.

Avec VSCode, le problème qui m'empêche de basculer, et est-ce que je veux changer, c'est l'absence de plusieurs dossiers de projet dans la barre latérale.

Je veux dire, je suppose que je pourrais simplement ouvrir le dossier racine pour le résoudre temporairement, mais si je n'ai besoin que de 3/20 dossiers et que je ne veux pas voir les fichiers en vrac, alors cela devrait être une implémentation facile, non?

Mise √† jour: La grande mise √† jour de l'atelier √† venir est la sortie √† chaud (n ¬į 101), tout en travaillant sur la sortie √† chaud, nous avons activement discut√© de ce probl√®me pour nous assurer que la conception prend en compte plusieurs dossiers.

Ce problème est actuellement numéro 2 en termes de: +1: réactions de tous les problèmes (numéro 1 par un atelier étiqueté de longue date), en tant que tel, il s'agit très probablement du prochain gros travail de l'atelier après une sortie à chaud.


Sur: +1: commentaires; ils ne servent qu'à ennuyer les 80+ personnes souscrites au problème. Voter sur le problème avec une réaction est cependant l'une des choses les plus puissantes que vous puissiez faire pour influencer le projet.

Gardez également à l'esprit que nous sommes une équipe relativement petite et que la propreté de la base de code et les performances de vscode sont très importantes, donc les choses prennent du temps pour bien faire. En particulier pour quelque chose comme celui-ci, qui est un changement fondamental dans la façon dont vscode a été construit à ce jour, il y a pas mal de travail dans ce problème.

+1

En effet, ce serait une fonctionnalité pratique.

Je suis passé d'Atom et j'ai vraiment aimé, mais je travaille sur deux applications d'interface utilisateur et 2 autres SDK, mais l'incapacité de changer rapidement entre ces projets (ou dossiers) est un manque important, je suppose que je devrais revenir à Atom jusqu'à ce que cela a été résolu

J'ai vraiment h√Ęte de voir cette fonctionnalit√© ~~~

Je suis un développeur de golang utilisant vscode, j'espère que cela a un implémentation, merci!

J'essaye de passer de Sublime √† VScode. Et bient√īt j'ai d√©couvert que VScode ne supportant pas plusieurs dossiers dans un concept de ¬ęprojet¬Ľ est vraiment un probl√®me qui me bloque de le faire.

J'adore vraiment les autres fonctionnalités de cet éditeur "léger". En attendant, je crois que le fait de supporter plusieurs dossiers dans un "projet" ne rendrait pas VScode "en surpoids" ou "semblable à l'IDE". Cela rendrait simplement plus pratique pour les développeurs utilisant d'autres éditeurs de rendre la transition beaucoup moins douloureuse.

J'espère avoir cette amélioration. Merci!

Aussi, si l'équipe peut ajouter la possibilité d'enregistrer les paramètres basés sur le projet qui remplacent les paramètres par défaut, ce sera génial. Le cas d'utilisation est de savoir si je peux avoir différents interprètes pour différents projets. De même, avoir différentes tailles d'onglets, etc. aidera également. Veuillez me faire savoir si cela peut déjà être réalisé d'une manière ou d'une autre.

En tant que développeur, nous travaillons toujours sur plusieurs projets et nous avons nos propres projets parallèles. Personnaliser les paramètres du projet (paramètres de l'espace de travail pour vscode) à chaque fois que je change de projet est un gros problème.

@bajubullet Vous devriez essayer https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig Je ne sais pas si cela couvre tout ce dont vous avez besoin, mais c'est un début.

@danechitoaie merci pour la r√©ponse. EditorConfig n'aide cependant pas, je peux sp√©cifier des propri√©t√©s par type de fichier, mais si je peux les enregistrer en tant que param√®tres de projet, ce sera plus facile et je n'aime pas avoir .editorconfig pour chaque projet. De plus, dans le cas d'extensions comme l'extension python qui nous permettent de fournir l'interpr√©teur √† utiliser, cela n'aidera pas car python.pythonPath n'est pas pris en charge via editorconfig. S'il vous pla√ģt laissez-moi savoir si je manque quelque chose ici. Toutes les suggestions sont les bienvenues.

Je suis d'accord, j'attends vraiment avec impatience une sorte de param√®tres sp√©cifiques au projet et de pouvoir ouvrir plusieurs dossiers ¬ęracine¬Ľ. Ce sont les seules choses qui me manquent de Sublime.

Ceci sera bient√īt mis en Ňďuvre!

Donc pas besoin de continuer à ajouter à ce post. Si vous rencontrez d'autres problèmes, créez un nouveau fil de discussion. Merci!

C'est un fil assez long et j'en ai lu peut-√™tre un tiers, mais je veux juste exprimer mon soutien. Je viens d'installer VS Code avec https://github.com/JuliaEditorSupport/julia-vscode comme substitut possible d'Atom / Juno. C'est beau! ūüėć

Lors du développement du code Julia, cependant, je pense qu'il est assez important de pouvoir ouvrir plusieurs packages dans différents dossiers. En principe, je pourrais ouvrir le dossier ci-dessus, mais cela exposerait les centaines de packages Julia que j'ai installés. Je pourrais également changer mon LOAD_PATH, mais je préfère de loin une solution VS Code.

J'esp√®re sinc√®rement pouvoir ouvrir plusieurs dossiers. Merci pour les efforts ūüĎć

Salut √† tous, comme vous l'avez peut-√™tre remarqu√©, nous explorons la mise en Ňďuvre de ce probl√®me au cours de cette it√©ration.

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

Enquêter sur les espaces de travail multi-racines à travers les différents composants @team

Je souhaite discuter avec 3 √† 5 d'entre vous de vos cas d'utilisation pendant que nous r√©fl√©chissons aux d√©tails de la mise en Ňďuvre. Veuillez vous inscrire pour un cr√©neau horaire de 15 minutes mardi prochain si vous le pouvez. J'adorerais discuter.

basculer entre mon api et ui me rend fou ... :-(

@ehartford une raison en particulier pour laquelle ils ne partagent pas un parent commun?

Oui. L'intégration Git ne fonctionne pas si j'ouvre simplement le répertoire parent.

@ehartford bonne raison: sourire:

@waderyan recherchez-vous uniquement des cas d'utilisation _end user_, ou des _extensions developer_ aussi?

En tant qu'utilisateur final, la prise en charge de plusieurs dossiers était la plupart du temps utile à des fins de recherche. J'avais l'habitude de créer des projets en ajoutant différents dossiers à partir de différentes API, juste pour faciliter les recherches (unifiées). Je dirais que je ne manque pas grand chose aujourd'hui et que cela ne me dérange pas d'avoir plusieurs fenêtres VSCode aujourd'hui, surtout après l'ajout Switch Window commande

En tant que _extension developer_, j'ai quelques extensions basées sur _Project Context_, comme context.workspaceState , activationEvents/workspaceContains . Et aussi Project Manager , qui d'ailleurs j'ai déjà commencé à refactoriser les internes pour prendre en charge plusieurs dossiers. J'aimerais savoir comment cela affectera les extensions

Merci

Pour ajouter à ce que j'ai dit ci-dessus (https://github.com/Microsoft/vscode/issues/396#issuecomment-270326917), j'utilise en fait des sous-modules Git, donc quand je travaille sur mes propres packages (privés), cela Il est parfaitement logique de les regrouper, mais comme Julia est encore assez jeune (relativement parlant), j'ai souvent besoin de travailler sur d'autres packages en plus du mien. Je ne ressens pas de raison impérieuse d'ajouter ces autres packages en tant que sous-modules (bien que je puisse le faire).

En général, pour le développement de packages Julia, je passe constamment d'un package à l'autre, donc avoir plusieurs dossiers de projet serait génial: +1:

PS: MS, faites plus attention à Julia;)

Cas d'utilisation le plus simple: les microservices

Haha. Oui @saada ūüĎć Ce sont en fait des microservices qui nous ont amen√©s √† VS Code. Nous utilisons Azure Service Fabric et mon partenaire a cr√©√© les premiers microservices dans .NET et Rust. Je travaille sur les microservices Julia. Mon partenaire est un gars VS et a aim√© VS Code pour Rust. Il m'a sugg√©r√© d'essayer VS Code pour Julia. Merci!

@saada est définitivement sur le radar. Pouvez-vous répondre à ces questions pour m'aider à être plus précis sur les exigences?

  1. Vos micro-services partagent-ils un dossier parent? Pourquoi ou pourquoi pas?
  2. Chaque microservice est-il séparé dans son propre référentiel git? Pourquoi ou pourquoi pas?
  1. Chaque microservice est-il séparé dans son propre référentiel git? Pourquoi ou pourquoi pas?

@waderyan une raison possible est que certaines plates-formes PaaS populaires telles que Heroku exigent que chaque application (microservice) se trouve dans un d√©p√īt Git distinct. Deploy-via-git-push est devenu une strat√©gie populaire.

@waderyan Je

Nous sommes une grande organisation, nous avons un registre npm privé et publions nos propres modules qui sont partagés au sein de l'organisation. Nous avons une application de réaction avec une base de code client qui est une grosse application qui consomme certains modules communs (comme des bibliothèques d'utilitaires, des composants partagés), et une base de code de serveur qui comprend également plusieurs modules (application de serveur express, composants de service de données backend consommés par le couche de service et les services réels exposés au client). Le développement actif implique un minimum de deux (la couche client et services) mais le dépannage peut facilement impliquer une demi-douzaine de modules.

Même lors de l'utilisation de modules npm publics, il est parfois utile d'avoir son code source lié directement et ouvert dans une instance VS Code distincte pour résoudre un problème difficile, ou même un bogue dans un module tiers, mais il s'agit principalement de notre propre code.

Chacun est un d√©p√īt git distinct. Il n'y a aucun probl√®me √† les garder dans mon syst√®me de fichiers sous un seul dossier racine (je le ferais de toute fa√ßon). Mais j'ai besoin d'avoir une instance distincte de VS Code ouverte pour chacun, et basculer dans les deux sens est douloureux car vous ne pouvez voir que le nom du fichier - pas le nom de l'application elle-m√™me. Il n'y a aucun moyen de d√©terminer facilement quelle application / module / projet est ouvert dans quelle fen√™tre. Le nom du fichier lui-m√™me fournit tr√®s peu d'informations utiles pour distinguer les instances de VS Code multiples.

Il y a un autre probl√®me en suspens li√© √† la possibilit√© de configurer les informations de la barre de titre sur lequel j'ai √©galement beaucoup comment√© - et qui reste √©galement non r√©solu. S'il √©tait possible d'afficher le nom du dossier racine √† gauche dans la barre de titre, le probl√®me de l'ouverture de plusieurs projets serait beaucoup moins probl√©matique, car je pourrais au moins voir quelle instance ouverte √©tait celle dans Windows lors du changement de t√Ęche. Cela semble √™tre vraiment trivial de rendre configurable et all√©gerait au moins la douleur de ne pas pouvoir ouvrir plusieurs d√©p√īts git en une seule instance pendant que cela est compris ...

@waderyan

  1. Mes projets Web sont gérés par un seul dossier parent. Il est configuré de cette façon pour l'organisation et les liens rapides pour mes dossiers de référentiel. Je fais également cela, car il m'est facile de basculer dans un projet précédent / actuel pour extraire des échantillons de code lorsqu'ils vont être réutilisés. Par opposition à l'ouverture d'une autre fenêtre, il est plus facile d'ouvrir un autre onglet et plus efficace dans mon cas.

  2. Chaque projet Web a sa propre int√©gration git, mais pour moi personnellement, je n'ai pas besoin que .git soit int√©gr√© dans mon √©diteur de code. C'est une bonne option pour moi, mais pas une exigence. Ils ont leur propre int√©gration .git car ils souhaitent conserver chaque projet Web s√©par√© dans mon h√īte de d√©p√īt.

@nickmak @jamietre @pesho merci d'avoir partag√© vos pens√©es. C'est utile et j'ai h√Ęte de discuter avec beaucoup d'entre vous demain.

@alefragnani Je me concentre sur le scénario de l'utilisateur final. Nous avons abordé ce problème avec prudence en raison de son impact sur les extensions. Nous ferons attention et communiquerons tout changement d'API. Envoyez-moi un ping sur Twitter si vous le souhaitez et nous pourrons passer un appel pour en discuter davantage.

même notepad ++ prend en charge plusieurs dossiers. c'est la raison pour laquelle ne peut pas quitter notepad ++.
cette journée de travail avec javascript doit ouvrir plusieurs projets.

Je travaille sur des logiciels embarqués et il y a généralement quelques dossiers sur lesquels je travaille dans tout le système. Par exemple, le code d'application, la bibliothèque du fournisseur et le code du système d'exploitation.

Je voudrais ajouter mon cas d'utilisation ici pour plusieurs dossiers dans la même fenêtre.

Je suis d√©veloppeur de jeux et, pour notre jeu actuel, nous avons impl√©ment√© le support des mods. Notre jeu a un projet client, serveur et serveur ma√ģtre. Lors de l'√©dition des fichiers mod, il est courant de ne travailler qu'au niveau mod du jeu (au lieu de ce que nous appelons le niveau principal ou natif du code du jeu r√©el. Par exemple, travailler uniquement dans les fichiers Lua au lieu de fichiers C ++ et C # pour le serveur et client respectivement). Les dossiers peuvent souvent ne pas √™tre situ√©s dans un dossier parent commun.

Dans ce cas d'utilisation, lorsque nous travaillons uniquement dans les fichiers de mod, dans le passé, nous avons utilisé la fonctionnalité multi-dossiers de Sublime pour créer une vue de projet des seuls dossiers de mod de niveau supérieur du client et du serveur. Cela nous permet d'éviter les fichiers natifs (C # et C ++) et de modifier rapidement les fichiers Lua dans ces deux projets qui sont très liés l'un à l'autre.

La prise en charge de plusieurs dossiers dans VSCode nous permettrait de faire de même et faciliterait grandement l'adoption de VSCode (que nous aimons beaucoup).

Que s'est-il passé de l'appel qui a eu lieu la semaine dernière? Je suis sur mac et je n'arrive pas à ouvrir plusieurs instances de VSCode, ce que je pensais être une solution de contournement.

Merci!

J'ai eu un appel la semaine dernière avec Wade, il est évident et juste que ce n'était pas un
priorité précoce, ils ont construit un très bon éditeur, et maintenant j'espère
ils l'étendent pour répondre aux différents besoins des développeurs. L'équipe de développement est
√©coute, j'ai h√Ęte de voir comment ils s'y prennent

Le dim, 15 janvier 2017 21:20 nowherenearithaca, [email protected]
a écrit:

Que s'est-il passé de l'appel qui a eu lieu la semaine dernière? Je suis sur mac et je ne peux pas sembler
pour ouvrir plusieurs instances de VSCode, ce que je pensais être une solution de contournement.

Merci!

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-272724576 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AA16yEIdTFJAnqXHLs_WUvrGBIR9G7f-ks5rSo2DgaJpZM4Gm3nX
.

en grande demande
marque

@nowherenearithaca J'ai eu de bons appels avec un certain nombre d'utilisateurs et j'ai partag√© ce que j'ai appris avec le reste de l'√©quipe. Nous sommes toujours en train de d√©terminer les prochaines √©tapes, mais je pense que nous ferons quelque chose dans ce domaine tr√®s bient√īt.

@waderyan , désolé pour la réponse tardive:

Vos micro-services partagent-ils un dossier parent? Pourquoi ou pourquoi pas?

Oui, pour plus de commodité. Cela facilite la recherche de services associés lorsqu'ils se trouvent dans le même répertoire.

Chaque microservice est-il séparé dans son propre référentiel git? Pourquoi ou pourquoi pas?

Oui. Ils ont non seulement des d√©p√īts diff√©rents, mais √©galement des configurations de linting et de d√©bogage diff√©rentes. De plus, utiliser Cmd + P pour basculer entre les fichiers est tr√®s utile. Recherche globale dans les projets associ√©s, ...

Au plaisir de voir cela en action!

Une solution serait de cr√©er un lien vers le dossier o√Ļ se trouvent les fichiers auxquels vous souhaitez acc√©der.
Ce n'est pas idéal, mais cela peut aider.

_Exemple:_

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

J'ai 3 moniteurs et je souhaite utiliser VSCode sur les trois. Si je ne peux pas ouvrir plusieurs instances, au moins prendre en charge le désancrage des onglets et les faire glisser vers d'autres fenêtres (similaire à Visual Studio 2015).

Se mettre d'accord.

Tous les autres éditeurs de texte le font. Pourquoi Microsoft n'a-t-il pas pensé à quelque chose d'aussi simple et nécessaire?

@calloncampbell Cette fonctionnalité est dans ce numéro: https://github.com/Microsoft/vscode/issues/2686

@calloncampbell @rsyring Je ne sais pas ce que je fais de mal mais en utilisant code -n je peux ouvrir autant d'instances d'éditeur que je veux.

Si je comprends bien, cela sera √©tudi√© dans le plan d'it√©ration de f√©vrier sous le titre ¬ęEnqu√™te initiale sur la mise en Ňďuvre d'espaces de travail multi-racine¬Ľ, d'espaces de travail ¬ęmulti-dossier¬Ľ ¬Ľ :)

+1 ...
N'est-ce pas possible avec l'ancienne version de VSCode ou est-ce que j'utilisais juste Sublime? oublié...
mais très pratique.
Maintenant, mon Mac est jonché de 6 fenêtres partout ...

Et non, je n'ouvrirai pas le dossier racine de tous ces 6 dossiers que j'ai ouverts, car l'explorateur est un défilement vertical et il me faudrait une éternité pour parcourir les fichiers ...

@edmundtfy c'est possible en sublime. Visual Studio Code n'a jamais pris en charge cette fonctionnalité.

La solution

@DeeJaVu consid√©rant que ... VSCode a ces info-bulles au-dessus de la souris et contr√īle + clic pour aller √† la d√©finition. J'ai t√©l√©charg√© des extensions pour Sublime mais le survol de la souris et le contr√īle + clic ne fonctionnent pas aussi bien .. des recommandations?

Cela me manque vraiment après avoir utilisé Sublime pendant des années. En ce moment, je travaille avec Intershop (en tant que frontal) avec des centaines de milliers de fichiers par cardridge. Si je dois charger une boutique en ligne complète, c'est vraiment lent lorsque vous souhaitez ouvrir CTRL + P pour passer rapidement à un fichier ou lorsque vous devez effectuer une recherche.

De plus, je ne veux tout simplement pas que chaque dossier d'un projet se trouve dans mon éditeur. Je n'ai pas besoin de tout en tant que développeur front-end. Les dossiers dont j'ai besoin suffisent.

Autre exemple: créer un site Wordpress et des plugins pour celui-ci en même temps. Pourquoi aurais-je besoin d'inclure un site Wordpress complet? Cela ralentit simplement votre efficacité.

Un autre probl√®me que nous avons: notre framework front-end est divis√© en diff√©rents d√©p√īts git '. Avoir plus de 4 fen√™tres ouvertes est une vraie douleur. Et SCSS intellisense ne fonctionne pas alors (variables IE. Du package core>)

TLDR; VScode est inutilisable pour les grands / grands projets

+1, imaginons que vous développiez un wordpress ou un drupal avec plusieurs modules personnalisés.

La racine de votre projet est la racine de votre site Web, mais vous ne voulez pas que le site Web complet soit un d√©p√īt, vous voulez juste que vos plusieurs modules ou th√®mes en tant que d√©p√īt ind√©pendant chacun.

Cas d'utilisation très courant dans le développement Web qui devrait être couvert, même par le plus petit / le plus léger IDE.

+1

+1, me permettrait d'éditer un projet et de travailler sur ses sous-modules de manière transparente

+1

C'est le seul problème qui nous empêche de migrer toute notre équipe de développement de 32 personnes vers VS.

Le développement de micro-services n'est tout simplement pas faisable, c'est douloureux.

+1

+1, vraiment utile, je décide de passer à vscode de sublime, mais, à cause de cette fonctionnalité manquante, je pense que j'utiliserais encore sublime jusqu'à un jour ..

C'est une fonctionnalité très nécessaire et basique. Je ne peux pas croire comment les développeurs de ce grand éditeur l'ont ignoré. C'est inutile sans cette fonctionnalité. Cela m'empêche de passer à VSCode depuis Atom.

Veuillez ajouter cette fonctionnalit√©. Apr√®s avoir utilis√© Sublime puis Atom, c'est pour moi une fonctionnalit√© n√©cessaire d'un √©diteur. Bien s√Ľr, ce n'est pas si facile √† cause de l'int√©gration git, mais c'est quelque chose dont j'ai besoin dans mon √©diteur pr√©f√©r√©.

+1

+1 besoin urgent

+1 Comme il a été dit précédemment, pour passer d'Atom à VSCode, nous avons vraiment besoin de cette fonctionnalité.

ATTENTION AVANT COMMENTAIRE
* S'IL VOUS PLAÎT !!!! Arrêter le commentaire avec un "+1"

Chacun de vos commentaires inutiles distrait plus d'une centaine de personnes uniquement avec ce fil !!!
Si vous souhaitez prendre en charge cette fonctionnalité - elle a de l'émotion dans le premier message!
Si vous souhaitez vous abonner aux mises à jour - pour cela, c'est le bouton "S'abonner" à droite des sujets
Respectez les autres membres, qui sont obligés de lire votre "+1", "vraiment nécessaire", etc.

Pour référence, la façon dont Sublime Text (à titre d'exemple) organise ses projets consiste à "inclure" des arborescences de dossiers, avec des options uniques par "dossier" incluses dans votre projet.

Pour visualiser cela, le JSON d'un fichier de projet Sublime Text ressemble à ceci:

{
    "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"
            ]
        }
    ],
}

Comme vous pouvez le voir, chaque dossier inclus est relatif au chemin du projet (dans le cas d'un texte sublime, il s'agit du chemin du fichier *.sublime-project ). En outre, chaque dossier a une section pour exclure les modèles de fichier et de dossier avec des caractères génériques. Idéal pour ignorer (comme on peut le voir ci-dessus) les résultats des tests, les bibliothèques que vous ne devriez pas éditer, les illustrations et plein d'autres choses.

C'est la dernière raison qui me reste pour ne pas changer.

C'est très utile!

+1
Exemple: besoin de vérifier si certaines fonctionnalités ne sont pas déjà implémentées dans d'autres modules référencés par l'application afin de ne pas dupliquer les fonctionnalités

De toute évidence, les modules sont stockés ailleurs dans le chemin du fichier, pas dans l'application elle-même, et l'utilisation de plusieurs fenêtres est pénible avec un seul écran, lorsque vous souhaitez simplement accéder rapidement à un fichier et lire le code
Je parle des applications AngularJS, qui n'ont pas besoin de déploiement ou de quoi que ce soit, juste un serveur en cours d'exécution.
Pourquoi devrais-je me soucier de dev dans une autre structure de fichiers, alors que je peux simplement ouvrir le dossier App directement à partir de Tomcat et que mes modifications prennent effet en temps réel.

Et non, il n'y a pas de dossier parent, à moins que vous ne suggériez d'ouvrir le dossier du serveur Tomcat en tant que projet (ce qui revient à suggérer d'ouvrir tout mon disque dur en tant que projet, car je pourrai alors ouvrir tous les fichiers).

Wow, j'ai désinstallé atom pour essayer VS, et cette fonctionnalité n'a pas été ajoutée depuis 2015.

stoffeastrom a ouvert ce numéro le 21 novembre 2015

C'est déprimant. :désappointé:

PS: L'ouverture du dossier ma√ģtre n'est pas exactement une solution car elle ouvre √©galement tous les fichiers ind√©sirables, d√©passant ainsi l'objectif de ce ticket.

C'est vraiment déprimant. Mais là encore pas aussi déprimant que les gens se plaindre encore à un incroyable, libre, éditeur opensource (qui ajoute toujours une poignée de nouvelles fonctionnalités every mois_). Ni aussi déprimant que de spammer tout le monde qui regarde ce fil avec des commentaires sur sa dépression.

(Maintenant, je suis l'un des spammeurs, je suppose: sourire :)

Mise à jour: le plan actuel est d'examiner cela dans les itérations de mars / avril.

Voir https://github.com/Microsoft/vscode/issues/21923 pour le plan d'itération de mars:

Enquêter sur les espaces de travail multi-racines et multi-dossiers # 396 @bpasero @Tyriar

+1

Pour partager un exemple du monde réel qui affine la description de la fonctionnalité: Exemple, WordPress Theme / Plugin dev.

Dans d'autres √©diteurs, j'ai mis en place plusieurs dossiers comme "signets", pour acc√©der √† une arborescence de fichiers assez grande et complexe un peu plus facile √† g√©rer. La premi√®re concerne la racine Web, qui est la racine que je pr√©f√®re √† toute fonction de d√©bogage et de compl√©tion de code pour commencer (l'environnement). Deuxi√®mement, le projet r√©el, un dossier de th√®me ou un dossier de plugins qui, dans mon flux de travail, est la racine du contr√īle de version. Parfois, je configure des dossiers suppl√©mentaires comme r√©f√©rence, tels qu'un th√®me parent, ou un th√®me de mod√®le, ou un plugin avec lequel je m'int√®gre et que je dois consulter / lire fr√©quemment.

Donc, l'ensemble des fonctionnalités ici est, 1. la possibilité de définir la racine git et la racine de recherche à des emplacements différents. 2. Un système de bookmarking de dossier qui est purement visuel pour désencombrer le panneau de l'arborescence des fichiers.

Pour certains sur le thread, o√Ļ la racine git et la racine du projet sont les m√™mes, il semble que l'apprentissage et l'utilisation de sous-modules suffiraient, et ensuite c'est √† peu pr√®s 2. pour obtenir une belle vue moins encombr√©e d'un dossier imbriqu√©.

Je suis s√Ľr que certains sur le fil demandent en fait une prise en charge litt√©rale de plusieurs projets, mais je suppose que la plupart demandent simplement l'id√©e plus simple de bookmarking de dossier.

Je demande également un moyen d'en définir un comme racine de projet (recherche / débogage) et un autre comme racine git. (N'hésitez pas à ignorer ma mauvaise dénomination des choses.)

Ma solution de contournement pour cela est simplement de créer un dossier parent et de créer les liens symboliques avec tous les projets que je souhaite.
_par exemple._

J'ai ces projets

1. mon-application-api
2. mon-client-application

Je crée un dossier appelé _my-app-all_ (le nom n'est pas pertinent ici) et à l'intérieur, je crée deux liens symboliques pointant vers my-app-api et my-app-client puis dans VSCode il me suffit d'ouvrir my-app- tout

Pas

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

Remarques:
L'intégration git ne fonctionnera pas

@DannyFeliz cela devrait être marqué comme une réponse à ce problème et affiché en haut pour que tout le monde puisse le voir ... J'ai également testé cela sur Windows, en utilisant la commande MKLINK.
Exemple d'utilisation:

  1. Ouvrir l'invite de commande avec les privilèges d'administrateur
  2. Accédez au dossier de votre projet
    3. [facultatif] créer un dossier de liens
  3. utilisez MKLINK / D "link_name" "chemin vers le dossier que vous souhaitez référencer"

Lorsque vous ouvrez le projet en code VS, vous verrez le dossier référencé et tous les fichiers / dossiers qu'il contient.

Heureux les gars de codage!

Cela ne permet pas à l'intégration Git de fonctionner.

Le lun.20 mars 2017 √† 14:42, poparazvandragos [email protected]
a écrit:

@DannyFeliz https://github.com/DannyFeliz cela devrait être marqué comme un
réponse à ce problème et posté en haut pour que tout le monde puisse le voir ... J'ai testé
ceci aussi sur Windows, en utilisant la commande MKLINK.
Exemple d'utilisation:

  1. Ouvrir l'invite de commande avec les privilèges d'administrateur
  2. Accédez au dossier de votre projet
    3. [facultatif] créer un dossier de liens
  3. utilisez MKLINK / D "link_name" "chemin vers le dossier que vous souhaitez référencer"

Lorsque vous ouvrez le projet en code VS, vous verrez le dossier référencé
et tous les fichiers / dossiers qu'il contient.

Heureux les gars de codage!

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-287907310 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABEOBVKz2bqFsRdfvyOpcFW2e_26HV5bks5rnvLWgaJpZM4Gm3nX
.

@ehartford J'ai dit une réponse, pas LA réponse, car la plupart d'entre nous recherchaient juste cette chose exacte, affichant plusieurs répertoires dans la même fenêtre VSCode, qui résident à des endroits différents.
Les liens symboliques font exactement cela, mais lorsque vous travaillez sous Windows, ce n'est pas la solution qui me vient à l'esprit.
Il a fallu 2 ans et pour qu'un développeur Linux / OSX vienne nous montrer la solution de contournement la plus simple.
Je suis content d'avoir décidé de laisser enfin tomber mon commentaire sur ce problème car j'ai une solution de contournement pour ce que je voulais
après seulement 12 jours, quand j'en avais le plus besoin.

Le problème ne doit pas être abandonné, car beaucoup plus peut être fait si les développeurs choisissent d'intervenir sur la question.
Mais pour la plupart d'entre nous, c'est satisfaisant. Je suggérais simplement de déplacer cela par-dessus, afin que les gens ne perdent pas de temps à lire tous les autres commentaires, jusqu'à ce qu'ils atteignent ce commentaire. Certains pourraient simplement l'oublier à cause de la taille du fil.

Je vais simplement éditer ceci car je vois des gens qui sautent déjà sur mon dos parce que j'ai découvert comment réaliser ce que je voulais et j'ai essayé de permettre aux autres de voir plus facilement une alternative même si elle n'est pas parfaite. BTW: Vous pouvez toujours utiliser l'invite de commande intégrée à VSCode pour extraire / valider / pousser des fichiers dans des dossiers liés individuels, mais pourquoi vous contenter de solutions de contournement.

Sans intégration Git, c'est un total non-démarreur. Je ne considère en aucun cas cette solution acceptable. Dans l'attente d'une solution réelle. Meilleures salutations.

Si cela aide - le client google appengine nodejs est structuré comme ceci:

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

J'aimerais pouvoir ouvrir / déboguer / travailler dans une solution comme celle-ci (même si c'est un package à la fois). J'adorerais pouvoir écrire des projets / bibliothèques basés sur Typescript dans ce style.

Merci pour tout l'excellent travail!

J'adore VSCode, mais c'est de la merde pour g√©rer plusieurs projets. Mais je peux comprendre pourquoi la fonctionnalit√© a √©t√© d√©sactiv√©e, car elle rend plusieurs choses comme le contr√īle de source plus compliqu√©es en raison de l'imbrication, etc.

Je serais heureux d'avoir une fonctionnalit√© de ¬ęchangement rapide de projet¬Ľ OU la possibilit√© de ¬ętabuler¬Ľ plusieurs instances de vscode dans une fen√™tre.

Entièrement d'accord, veuillez prendre en charge l'ouverture de plusieurs dossiers de projet dans la même fenêtre. Cette fonction est très importante.

@replete Ce n'est pas une solution parfaite à votre problème. Mais essayez Project Manager , cela m'aide partiellement en ce moment.

@dariusrosendahl Ouais , d√©couvert ce matin assez dr√īle! Fait le travail pour le moment.

La barre lat√©rale n'a que 5 ic√īnes, il ne faudrait pas beaucoup pour ajouter une barre lat√©rale `` Projet ''. Mais il semble que les propri√©taires de produits vscode soient tr√®s pointilleux sur son minimum. IMO trop minime car il devient maintenant un IDE.

@replete heureux de savoir que cela est utile ūüėĄ

En fait, il y a une _ API exp√©rimentale_ pour cr√©er une soi-disant _Tree Explorer Contribution_ (tout comme un panneau Symboles - https://github.com/Microsoft/vscode/issues/15485). Avec cela, l'extension pourrait ajouter une ic√īne √† la barre d'activit√©.

Je vais ajouter un probl√®me √† mon extension avec votre suggestion, merci ūüĎć

+1

@dmccaffery

Personnellement, je ne me soucie pas de savoir si cette fonctionnalité se retrouve dans le produit ou non - je comprends pourquoi certaines personnes la veulent, mais je tiens à souligner que cela rend tout un peu plus compliqué.

Alors peut-être ne dominez pas la conversation avec des commentaires négatifs contre la fonctionnalité et sur le fait que VSC n'est pas un IDE? Je pense qu'une seule réponse / vote négatif suffit, ou au pire deux, si l'on a besoin de clarifier davantage une position.

En outre, l'argument "pas un IDE" est sans objet. D'autres non-IDE le permettent également.

Par exemple: lors d'une recherche à l'aide d'une expression regex - quel espace de travail suis-je en train de rechercher? une? tout?

Pas si gros probl√®me. Recherchez tout ou disposez d'un s√©lecteur pour √©tendre la recherche √† l'un des espaces de travail ouverts. Encore une fois, d'autres ¬ęnon IDE¬Ľ (ainsi que des IDE) g√®rent d√©j√† ce cas (et d'autres).

J'ai résolu ce problème dans ma propre configuration en créant un répertoire pour chaque "espace de travail" et en créant un lien symbolique vers les projets que je veux voir dans cet espace de travail.

j'ai vu ça

Enquête initiale sur les espaces de travail multi-racines et multi-dossiers # 396 @bpasero @Tyriar

est fait selon https://github.com/Microsoft/vscode/issues/21923 des mises à jour à ce sujet? :)

Nous (un sous-ensemble de l'√©quipe) avons effectu√© une enqu√™te initiale sur la quantit√© de travail impliqu√©e et les d√©fis que nous constatons et les prochaines √©tapes consistent √† en discuter avec l'√©quipe et √† le planifier. Nous faisons notre planification pour la sortie d'avril au cours de cette semaine, donc je m'attendrais √† des √©l√©ments de plan plus fins √† la suite de ce travail bient√īt.

screen shot 2017-04-06 at 12 09 26

Si je ne suis pas trop tard √† la f√™te, voici une belle fa√ßon de mettre en Ňďuvre cela.
Lorsque vous allez dans "Explorer", nous avons déjà deux sections. Un pour les fichiers ouverts et un pour l'arborescence de l'explorateur du dossier ouvert actuel.

Idéalement, nous pourrions simplement ouvrir plus de dossiers dans la même fenêtre et ils seraient ajoutés ici dans sa propre section qui peut être développée pour voir l'arborescence de l'explorateur.

La m√™me chose pourrait √™tre faite pour la section Contr√īle de code source. Une sous-section pour chaque dossier ouvert dans "l'explorateur". Donc une relation 1to1.

De cette fa√ßon, nous pouvons peut-√™tre rendre tout le monde heureux. Nous prenons en charge l'ouverture de plusieurs dossiers dans la m√™me fen√™tre si nous le voulons, et l'int√©gration GIT fonctionne toujours et est capable de g√©rer chaque ¬ęracine de projet¬Ľ s√©par√©ment.

Ouvrir plus d'un projet dans la même fenêtre, c'est aussi une fonctionnalité importante pour moi. Généralement, j'ouvre aussi des projets pour copier certaines applications de base. Je viens d'installer Visual Studio Code et je reviendrai sur Atom pour cette raison

+1 Je veux montrer aux autres développeurs la valeur de VSCode, mais ne pas pouvoir ouvrir deux dossiers dans la même fenêtre est un dealbreaker. J'espère que cela aura une priorité plus élevée.

Juste mes deux cents:

Jusqu'√† pr√©sent, le mot "monorepo" n'appara√ģt pas dans ce fil

Mon monorepo centralise les probl√®mes de configuration entre plusieurs racines, o√Ļ chacune est marqu√©e par un fichier ".root" dans le dossier qui les contient.

Toutes les racines ne sont pas un référentiel git externe, mais elles permettent un remplacement partiel de la configuration globale.

Mon principal problème est que la recherche de fichiers et / ou de symboles ne donne pas la priorité au contenu de mes racines

Je pense que l'exigence peut √™tre divis√©e en ~ 4 diff√©rents, qui peuvent ou non √™tre directement li√©s les uns aux autres (et probablement mis en Ňďuvre ind√©pendamment):

  • prend en charge plusieurs dossiers dans l'explorateur
  • prendre en charge plusieurs dossiers dans la recherche
  • prendre en charge plusieurs dossiers dans le contr√īle de code source
  • prendre en charge plusieurs dossiers dans le d√©bogage

D'apr√®s ce que j'ai vu dans ce fil, les s√©parer peut prendre en charge un plus large √©ventail de sc√©narios. Bien s√Ľr, il devrait y avoir encore un dossier "principal", affectant la fa√ßon dont les dossiers configur√©s / s√©lectionn√©s sont conserv√©s.

Je ne comprends pas pourquoi la plupart des commentaires parlent de solutions d'explorateur multi-racine ou multi-dossier. En fait, je pense que c'est vraiment mal d'essayer de l'impl√©menter de la mani√®re IDE. Cela ajoute de la complexit√© et impacte s√Ľrement les performances (temps de chargement, rafra√ģchissement git ....).

Je pense que cette fonctionnalité est très importante, le besoin est essentiellement d'avoir un visuel sur tous les projets associés et de basculer rapidement entre les fenêtres des projets!

Nous avons deux choix:

  • Impl√©mentation dans une seule fen√™tre : Dans mon sens, cela introduit de nombreuses autres pr√©occupations, de multiples projets racines pour git, recherche ..... CECI EST TR√ąS MAUVAIS pour l'UX et introduira potentiellement des bogues et de la complexit√© pour l'√©diteur.
  • Impl√©mentez un m√©canisme de commutation visuel et gardez une fen√™tre par projet : c'est le choix le plus s√Ľr et le plus pratique pour un co√Ľt tr√®s inf√©rieur! @ min20 a post√© un visuel sur les boutons de commutation de Slack entre les groupes que je trouve parfait pour le besoin!

spack

J'espère que cette fonctionnalité débarquera, mais pas en tant que solutions multi-racines! l'un des principaux avantages d'un petit éditeur est sa simplicité et sa rapidité, muti-root != simplicity & speed

Je dois être complètement en désaccord avec vous @ g13013 avez-vous vu l'implémentation de Sublime? C'est très simple et toujours beaucoup plus rapide que Visual Studio Code. Même avec tous les plugins GIT activés.

Nous ne parlons pas d'utiliser plusieurs projets dans un seul éditeur. Nous parlons d'utiliser uniquement les dossiers d'un projet dont vous avez besoin.

Je travaille par exemple sur les boutiques Intershop. Il y en a beaucoup dont je n'ai pas besoin, seulement les cartouches que je dois éditer. 80% des dossiers et des fichiers me sont inutiles et ne font qu'alourdir l'éditeur (croyez-moi, ça ralentit beaucoup).

L'utilisation de l '¬ęouverture rapide¬Ľ dans Visual Studio est √©galement inutilisable s'il y a beaucoup de fichiers en double. Vous n'√™tes souvent pas s√Ľr d'ouvrir le bon et encore une fois, il ralentit avec BEAUCOUP de fichiers.

Je comprends, mais, ayant utilis√© sublime et atom dans le pass√©, je suis finalement arriv√© √† la conclusion qu'aucun d'entre eux avec la fonctionnalit√© "multi-root" n'a r√©solu autre chose que l'exploration de fichiers de projet, en parlant d'arborescence de dossiers sublime et sublime est tr√®s lente dans gros projets et m√™me se fige lors de la d√©couverte, sublime n'a pas d'int√©gration des fonctionnalit√©s "git" et "debug" hors de la bo√ģte .... l'introduction de muti-root introduira beaucoup de probl√®mes li√©s √† l'int√©gration git, la recherche sans impact sur performances ... m√™me UX est impact√©, comme l'exploration des probl√®mes de srcoll dans les grands projets.

Bizarre, pour moi c'est le contraire.

C'est peut-être parce que 99% du temps, je n'inclus que ce dont j'ai besoin dans Sublime ou Atom :) et c'est exactement ce que nous voulons.

C'est peut-√™tre juste la fa√ßon dont vous utilisez l'√©diteur. J'ai l'habitude d'utiliser CMD / CTR + P et de taper le fichier exact que je veux. Ceci est impossible si vous devez inclure la racine d'un projet avec beaucoup de fichiers en double. (cartouches / fichiers laiss√©s l√† pour comparer ce qu'√©tait l'original :)) ou quelque chose comme wordpress o√Ļ il y a beaucoup de fichiers avec le m√™me nom.

Bonjour,
Oui, l'idée de plusieurs dossiers convient sans casser beaucoup de choses. Chaque dossier supplémentaire peut être une nouvelle sous-section avec un préfixe pour indiquer qu'il est étranger au dossier principal. Le primaire est utilisé pour le débogage et Git. Un utilisateur peut faire un clic droit sur n'importe quel dossier étranger et le rendre principal . Ce que vous gagnez:
1) pouvoir voir tous vos dossiers et fichiers et les ouvrir si nécessaire.
2) le recentrage de ce qui est primordial sur lequel travailler.

Désormais, si quelqu'un souhaite ouvrir plusieurs projets à la fois, une nouvelle demande de problème doit être ouverte. Cela ajoute une complexité significative soulignée par de nombreuses personnes. Les plugins n'équivalent pas aux intégrés. S'il existe un éditeur doté d'une fonctionnalité intégrée correspondante, il doit être indiqué pour que les autres développeurs puissent examiner comment leur flux de travail s'intègre à une telle fonctionnalité. Je vous remercie. Bonne journée.

Ajoutez-moi √† la liste des utilisateurs qui consid√®rent que c'est le seul facteur qui m'emp√™che de passer √† VSC. Je trouve que la mise en Ňďuvre Sublime des projets est parfaite. Si j'ai besoin de travailler sur l'application "Volunteer Hours" par exemple, j'ouvre le projet que j'ai rempli avec diff√©rents dossiers (le dossier principal du projet ainsi qu'un autre dossier contenant des images). C'est mon ensemble de travail pour ce projet. Si j'ai besoin de retourner √† l'application "Exchange Calculator", je peux √©changer l'ensemble de travail sur ce projet ou ouvrir une nouvelle fen√™tre avec ce projet.
Un autre cas d'utilisation est l'utilisation d'un CMS. Si je travaille sur un plugin pour le CMS, je peux avoir un projet pour le plugin qui est un d√©p√īt Git et un autre pour l'ensemble du CMS, qui n'est pas Gitified. Je peux basculer entre les deux si n√©cessaire et garder mes pr√©occupations Git s√©par√©es.
VSC me ressemble à l'avenir, mais pas sans la possibilité de conserver des ensembles de travail séparés de dossiers.

Bonjour,
J'ai seulement vu que Sublime Text prend en charge les projets avec un fichier projet . Comment cela √©quivaut-il √† ce qui est demand√© ici? Cela ressemble √† une demande de vscode pour prendre en charge les fichiers de projet dans un espace de travail. Il y avait un commentaire plus t√īt sur une extension qui pourrait g√©rer les choses √† cet √©gard pour un chef de projet .

Honnêtement, j'utilise aussi Atom et j'utilise la fonction multi-dossier (intégrée) qui me permet d'ouvrir les dossiers de documentation et mon dossier de projet actuel en même temps. Cela semble vraiment être un fruit plus bas pour activer uniquement le primaire et un tas de secondaires. Probablement une simple flèche ou commencer à indiquer le primaire. Je vous remercie. Bonne journée.

image

Pour ce que ça vaut, voici mon cas d'utilisation. Je travaille sur un jeu qui est divisé en trois référentiels; un repo Git pour le moteur, un repo hg pour le code du jeu + le contenu et un hg pour le code du jeu qui est générique sur de nombreux projets. Il existe également un référentiel hg pour les plugins Sublime Text de la société. Le repo générique est une assignation au repo de jeu.

Sur mon prochain lieu de travail, je prévois de travailler à nouveau avec de nombreux référentiels.

C'est super pratique d'avoir tous ces éléments dans la même instance d'éditeur, et je pense qu'il serait logique que tous ces éléments aient un SCM approprié dans VS Code.

Je m'attendrais à ce que la recherche recherche par défaut dans tous les dossiers mappés. Un bonus intéressant serait de pouvoir activer / désactiver les dossiers à rechercher, temporairement. (Par exemple, lorsque je ne suis intéressé que par la recherche de choses dans le moteur de jeu)

Il y a beaucoup de gens qui disent que VS Code ne devrait pas avoir de support pour cela parce que A) Ils n'en ont pas besoin et B) VS Code est un simple √©diteur de texte. La premi√®re raison n'est pas bonne - il y a peu de fonctionnalit√©s qui sont utilis√©es par tout le monde. La deuxi√®me raison ... VS Code n'est pas qu'un simple √©diteur de texte, il a des plugins de d√©bogage, SCM. D'autres "√©diteurs de texte simples" tels que Sublime prennent en charge plusieurs dossiers. Et en tant que personne intransigeante sur les performances, je ne vois pas comment l'ajout de cette fonctionnalit√© affecterait les performances de mani√®re significative, en particulier pour les personnes qui n'utilisent de toute fa√ßon qu'un seul dossier. Pouvons-nous s'il vous pla√ģt concentrer la discussion sur la fa√ßon dont nous voulons que la fonctionnalit√© fonctionne plut√īt que sur les raisons pour lesquelles nous ne le voulons pas.

@Srekel pouvez-vous inclure une capture d'écran de la façon dont vous travaillez comme ça dans vos éditeurs actuels? Cela ressemble à un mélange de dossiers et de projets utilisant des plugins intégrés. Espérons que les gens de ce camp A remarqueront à peine les changements pour intégrer ce type de fonctionnalité. Pour les gens du camp B , ils ont raison. Vous pouvez faire les choses rapidement avec l'application prête à l'emploi si vous n'avez pas besoin de vous enliser. Rester proche de cela aide probablement à avoir des cycles de mise à jour rapides et des éléments d'interface épurés.

Certaines choses sur la façon d' y arriver comprennent:

  • comprendre la relation entre la port√©e, le contexte, la session, les points de vue et l' actualit√© .
  • les limites sup√©rieures (plus de 256 dossiers?)
  • zones affect√©es par les touches (onglets de l'√©diteur, param√®tres, scm, git, extensions).
  • remplacement des param√®tres d'espace de travail ou conflits.

Ce serait bien de parler ici de certaines des choses que VSCode tient pour acquis dans ces domaines qui nécessitent une compensation. Je vous remercie. Bonne journée.

+1

+1. J'ai plus de 30 modules, chacun avec son propre référentiel git auquel j'aimerais avoir accès et travailler dans un seul environnement. Je pensais que c'était ce que font la plupart des développeurs js / node. Avec VSCode, cela est impossible, un facteur décisif pour moi à regret.

+1

Il est ouvert depuis 2015 et n'est toujours pas résolu. C'est une fonctionnalité tout simplement la plus recherchée dans n'importe quel éditeur, mais malheureusement, vscode ne l'a pas.

+1

Je confond constamment une fenêtre VS Code avec une autre lors de la tabulation des commandes.

Tous les autres éditeurs que je connais ont ceci (Atom, Sublime, Brackets ...)

Ajouter un lien symbolique à mon projet est un hack et me demanderait de mettre à jour mon .gitignore. Ouvrir le répertoire parent est ennuyeux car mon volet de fichiers est inondé d'autres projets dont je ne me soucie pas.

Plan d'it√©ration d'avril montrant la t√Ęche ¬ęEnqu√™te sur les espaces de travail multi-racines et multi-dossiers¬Ľ comme termin√©e. Quels sont les r√©sultats de l'enqu√™te?
@bpasero @tyriar

+1

Désolé si je suis trop impatient. Vous êtes occupés à publier du code maintenant.

Bonjour,
La bo√ģte de dialogue Ouvrir un dossier doit √™tre consid√©r√©e comme des dossiers ouverts. Donc, si je suis sous un dossier parent particulier, je peux dans la bo√ģte de dialogue mettre en √©vidence deux ou plusieurs de ses sous-dossiers √† ouvrir en m√™me temps. Ce serait un ajout bienvenu avec l'incorporation de cette fonctionnalit√©. Je vous remercie. Bonne journ√©e.

+ un autre

Jamais vu autant de commentaires à faible effort dans un fil GitHub auparavant, en particulier les post-emojis. Bonté moi.

J'aimerais vraiment cette fonctionnalité. Comme quelqu'un d'autre l'aura déjà dit, de nombreux projets modernes sont modulaires, par exemple frontend dans un référentiel / projet et backend / api dans un autre. Vous aurez souvent envie de les travailler ensemble comme un seul.

C'est la seule raison pour laquelle je n'ai pas abandonné Atom.

Les microservices et les plates-formes sans serveur, combin√©s avec le mantra de longue date ¬ęles d√©p√īts sont bon march√©¬Ľ, sont pourquoi c'est un must have. Il n'est pas inhabituel d'avoir ~ 30 [petits] d√©p√īts ouverts et de travailler sur des fichiers de plusieurs projets simultan√©ment; s'attendre √† ce que les gens basculent entre autant de fen√™tres, ou d√©charger la disposition des vues de fichiers vers le gestionnaire de fen√™tres de l'environnement de bureau ne fonctionnera pas.

Bonjour,
Comment g√©rez-vous vos 30 d√©p√īts maintenant
Faites-vous cela en raison d'autres limitations de votre environnement? peut-être que le langage de programmation n'a pas intellisense? Peut-être qu'une extension capable de lire l'API pour vous donner des signatures fonctionnelles vous aiderait?
Un langage comme F # a une fonctionnalité appelée fournisseurs de types, dont l'un peut faire exactement cela et faciliter la programmation du Web. Ce n'est pas pour diminuer votre besoin de plusieurs dossiers, mais simplement que vous auriez probablement encore au moins une poignée d'autres problèmes avec un si grand espace de travail actif. Je vous remercie. Bonne journée.

@ pr-yemibedu, je pense que ce que @martinjco dit, c'est qu'il n'a pas les fichiers ouverts mais qu'il aurait un acc√®s rapide aux d√©p√īts si nous avions une structure multi-racine. Imaginez, juste CMD + P √† n'importe quel fichier dont vous avez besoin;)

Le problème avec la situation actuelle est que nous DEVONS ouvrir les fichiers ou au moins basculer entre les 30 fenêtres différentes car VScode ne le prend pas en charge.

En fait, je suis retourné à Atom récemment en raison de la fonctionnalité manquante. Je travaille sur un projet avec 9 repo en ce moment. Je ne veux pas que 9 veuves VScode s'ouvrent en même temps, mais je veux juste utiliser un raccourci pour accéder au fichier dont j'ai besoin.

D'accord avec le commentaire de @dariusrosendahl. Je suis un codeur d√©butant et je dois faire r√©f√©rence √† des projets plus anciens pour en √©crire de nouveaux. J'esp√®re que cela changera bient√īt, mais en sublime, je peux facilement avoir trois √† quatre dossiers de projet et comparer les ouvrir dans la m√™me session
screen shot 2017-05-11 at 12 48 57 pm

Si nous pouvons obtenir cela dans un studio visuel, ce serait génial

Bonjour,
Je suis d'accord avec les points soulevés car vous pouvez voir que mes précédents articles favorisent cette fonctionnalité. Il y avait une déclaration exacte que je commentais par martinjco:

Il n'est pas inhabituel d'avoir ~ 30 [petits] d√©p√īts ouverts et de travailler sur des fichiers de plusieurs projets simultan√©ment;

Ce que montre nuno1895, c'est comment j'utilise Atom aujourd'hui quand j'ai besoin de travailler sur plusieurs dossiers mais sur un simple projet principal. J'utilise en fait à la fois VS2015, gedit, vim, notepad et notepad ++ pour le développement actif. Il y a des atouts dans chacun qui n'ont pas encore d'équivalent dans leurs homologues.

J'essayais simplement de comprendre s'il y avait un point central qui pouvait être clarifié. Nous voulons tous que cela soit travaillé et favorisé par les développeurs qui y consacreraient du temps. C'est pourquoi je demandais comment cela est géré aujourd'hui. 9 vs 30 n'aurait probablement pas autant suscité mon intérêt pour répondre, mais j'aime savoir ce que les gens comparent à vscode et si cela vaut même la peine de regarder un autre outil.

Je n'ai vu que Atom et SublimeText dont on parle comme base de comparaison et avec des captures d'√©cran utiles. Plus de discussions, de pouces et de commentaires sont les bienvenus pour que cela soit accept√© et mis en Ňďuvre. Je vous remercie. Bonne journ√©e.

Un point qui n'a peut-√™tre pas √©t√© suffisamment soulign√© est la possibilit√© de ¬ębasculer¬Ľ rapidement entre les ensembles de dossiers (projets). Il s'appelle "Quick Switch Project" dans Sublime. Lorsque vous cliquez sur cet √©l√©ment de menu, vous obtenez une fen√™tre contextuelle avec une liste de tous vos projets, lorsque vous s√©lectionnez l'un des projets, l'√©diteur affiche le ou les dossiers et tous vos fichiers ouverts tels que vous les avez laiss√©s pour la derni√®re fois.
Par exemple, si je travaillais dans le projet A et que les fichiers app.js et index.html étaient ouverts, puis basculés vers le projet B, cela fermerait le projet A et afficherait le projet B.Si je reviens ensuite au projet A, il montrez-moi le (s) dossier (s) et les app.js et index.html tels que je les avais laissés (même les modifications non enregistrées sont là).
Si j'ai besoin d'ouvrir les deux projets en même temps, je peux simplement ouvrir deux instances de l'éditeur.
La clé est que je suis capable de conserver toutes mes affaires dans des seaux séparés et que je peux passer rapidement de l'un à l'autre.

+1

Bonjour,
J'ai lu sur cette fonctionnalité. Changer de projet sans naviguer dans Sublime Text signale certains des bons et des mauvais. Ce serait bien d'encoder peut-être les multiples dossiers ouverts dans le fichier de paramètres de l'espace de travail. Si ce fichier semble au mauvais endroit, alors quelque chose comme folders.json peut être créé pour conserver l'état actuel des dossiers et fichiers disponibles et ouverts pour l'ensemble de travail actuel. Je vous remercie. Bonne journée.

J'ai commencé à utiliser VSCode il y a quelques mois et, en général, je suis très satisfait. Je vais ajouter ma voix à la chorale et dire que cette fonctionnalité manquante est le gros grattoir pour moi. Y a-t-il _any_ d'autres éditeurs décents qui ont cette limitation? Dans tous les cas, cela devrait être corrigé. :)

Voici la configuration de mon nouvel emploi:
Un d√©p√īt pour la technologie de base. Dites que le chemin est C: / mygamengine /
Un d√©p√īt pour le code du jeu. Il est synchronis√© avec C: / mygamengine / mygame
Un d√©p√īt pour le contenu du jeu (textures, etc.): C: / mygamengine / mygame_data

Tous les trois sont git. Ils ne sont pas configur√©s en tant que sous-d√©p√īts, ils sont simplement synchronis√©s avec ces dossiers.

De préférence, je voudrais simplement ouvrir le dossier racine dans VS Code et le faire comprendre automatiquement qu'il s'agit essentiellement de trois projets différents, et que les fichiers sous mygame appartiennent à ce référentiel git et non à celui de mygameengine.

J'aimerais pouvoir définir des paramètres pour cet espace de travail qui sont différents pour chaque référentiel (par exemple, je pourrais vouloir exécuter un linter sur le projet du moteur mais pas sur le code du jeu). Ce serait également bien si les paramètres de l'espace de travail par défaut étaient définis sur les trois projets.

Wow, cela n'a toujours pas √©t√© r√©solu? J'esp√©rais remplacer Atom par VS Code car, selon les critiques, il est beaucoup plus rapide et ne tra√ģne pas comme Atom.
Mon projet principal est deux d√©p√īts Git, un back-end et l'autre un front-end. Localement, les deux sont dans le m√™me dossier mais si le code Atom ou VS ouvre ce dossier parent, aucun statut Git n'est reconnu.
Dans Atom, j'ajoute simplement les deux dossiers à mon espace de travail et fonctionne simplement.

: sparkles: mise à jour: sparkles:

Cela fait un moment depuis notre derni√®re mise √† jour, alors j'ai pens√© que je mettrais tout le monde au courant. Moi-m√™me, @bpasero et le reste de l'√©quipe ont identifi√© la plupart des probl√®mes li√©s √† la mise en Ňďuvre de la multi-racine et travaillons actuellement sur des maquettes et sur des sp√©cificit√©s plus pr√©cises de l'UX.

Pourquoi cela prend-t-il autant de temps?

Cela prend tellement de temps car cette fonctionnalit√© n'est pas notre seule responsabilit√© et le travail impliqu√© dans la r√©alisation de la multi-racine est assez immense. Pour commencer, tous les composants de VS Code ont √©t√© con√ßus en partant du principe qu'il n'y a jamais qu'un seul dossier ou aucun dossier ouvert √† un moment donn√©. Lorsque vous avez une base de code aussi grande que la n√ītre avec une hypoth√®se comme celle-ci, il faut beaucoup de travail pour la rendre plus flexible.

Pour donner quelques exemples, voici quelques-uns des plus gros problèmes que nous avons identifiés jusqu'à présent:

  • L'API d'extension expose un seul workspace.rootPath , ce qui est insuffisant lorsque nous ajoutons la prise en charge des dossiers multi-racines. Nous voulons √©viter de casser ces extensions et fournir un chemin de migration si n√©cessaire.
  • La fa√ßon dont les param√®tres de l'espace de travail interagissent dans un monde multi-racine est un peu diff√©rente. Prenez workbench.statusBar.visible par exemple, qui est actuellement autoris√© dans les param√®tres de l'espace de travail. Nous ne pourrions plus supporter cela car cela conduirait √† un comportement √©trange / bogu√© s'il √©tait d√©fini dans 2 dossiers. Nous sommes en train de d√©couvrir comment traiter ce genre de cas.
  • Le fournisseur SCM (git) a probablement besoin de la plus grande quantit√© de travail UX pour prendre en charge plusieurs dossiers: Avons-nous besoin d'introduire le concept de "projet actif"? Doit-il √™tre d√©fini explicitement (cliquez avec le bouton droit sur le dossier et d√©finissez-le) ou doit-il √™tre implicite (en regardant le dossier du fichier actif)? Doit-il s'agir d'un concept global ou limit√© √† cette caract√©ristique sp√©cifique? etc.

Nous ne voulons pas nous précipiter avec une solution mal pensée, alors nous prenons notre temps et réfléchissons vraiment aux problèmes potentiels et aux implications de la façon dont cela affectera chaque composant. Cela viendra quand il sera prêt.

Résumé des commentaires à ce jour

Je viens de passer quelques heures à parcourir l'énorme fil de discussion pour rassembler les commentaires jusqu'à présent. C'était un peu difficile de catégoriser certaines de ces choses, mais voici ce que les gens recherchaient en général (je paraphrase).

  • Je veux une int√©gration git dans plusieurs dossiers
  • Le changement de dossier actuel et / ou la gestion des fen√™tres du syst√®me d'exploitation UX est encombrant
  • Je souhaite effectuer une recherche dans plusieurs dossiers
  • Je veux d√©boguer sur plusieurs dossiers

Préoccupations

  • Les refactorisations fonctionnent-elles sur plusieurs projets ou sur un seul projet?
  • Dans quel projet suis-je engag√© sur Git?
  • Dans quel (s) dossier (s) ma recherche sera-t-elle ex√©cut√©e?
  • Ne pas casser les param√®tres de l'espace de travail
  • Ne pas casser les extensions - avertir les d√©veloppeurs d'extensions de la nouvelle API
  • Une UX √† onglets de style Slack ne me suffit pas, il s'agit essentiellement de d√©placer la gestion des fen√™tres du syst√®me d'exploitation vers VS Code - je veux pouvoir acc√©der √† tous les fichiers des projets dans une seule fen√™tre (c'est-√†-dire un ensemble de groupes d'√©diteurs)
  • "Dans mon sens, cela introduit de nombreuses autres pr√©occupations, de multiples racines de projets pour git, search ..... CECI EST TR√ąS MAUVAIS pour l'UX et introduira potentiellement des bogues et de la complexit√© pour l'√©diteur."

Autres commentaires

  • Je veux seulement ouvrir un sous-ensemble des d√©p√īts dans mon "dossier git"
  • Je veux une mani√®re agr√©able de rechercher dans un seul dossier ou d'organiser les r√©sultats de recherche par projet
  • Je veux pouvoir naviguer vers le code de d√©pendance pour le lire rapidement
  • Je souhaite ex√©cuter diff√©rentes versions de TypeScript pour diff√©rents dossiers
  • VS Code est trop lent avec les d√©p√īts g√©ants
  • Je veux garder certains projets toujours ouverts √† utiliser pour r√©f√©rence (par exemple, un th√®me / mod√®le)
  • Je veux que VS Code reconnaisse les fichiers .vscode / settings.json dans n'importe quel r√©pertoire (cela aiderait √† contourner le probl√®me)
  • Permettez-moi de d√©finir une racine de projet (recherche / d√©bogage) et une racine git
  • Sublime g√®re avec √©l√©gance l'int√©gration git multi-dossier
  • Dossiers √† onglets similaires √† l'interface utilisateur de Slack (c'est-√†-dire un paradigme de projet actif)
  • Une section distincte dans l'explorateur pour chaque dossier
  • Utilisez un dossier comme principal et le reste comme des sous-dossiers / li√©s
  • Je veux un projet de changement rapide comme dans sublime (changement rapide + conserver la disposition de l'espace de travail)
  • Ce style de gestion de l'espace de travail est particuli√®rement utile pour les √©l√©ments suivants: module npm, julia, heroku PaaS, wordpress, drupal

Solutions de contournement actuelles

Voici les principales solutions de contournement actuellement:

Quand commenter?

Veuillez √©viter: +1: ou les commentaires ¬ęJe veux √ßa¬Ľ. Lorsqu'un commentaire est fait sur ce probl√®me, les 153 personnes et le nombre de personnes qui ont comment√© le sont inform√©s en plus de nombreuses autres personnes qui ont cliqu√© sur le bouton d'inscription. Les commentaires enterreront √©galement les mises √† jour de l'√©quipe, alors essayez d'√™tre conscient de cela. Par tous les moyens, commentez si cela ajoute √† la conversation.

Une fonctionnalité qui aurait sans doute plus d'utilité que d'avoir plusieurs racines est d'ajouter la possibilité d'avoir des ensembles de travail configurables. Cela vous permettrait d'ouvrir un parent mutuel, mais d'avoir de nombreuses combinaisons de dossiers dans ce projet.

De manière générique, cela serait utile pour n'importe quel projet pour pouvoir "se concentrer" sur certains fichiers / dossiers à la fois dans des bases de code plus grandes sans avoir à changer la configuration de la racine entière à chaque fois.

AUCUN plan concernant cette fonctionnalité?

Vous pouvez voir le plan de cette fonctionnalité sur le commentaire de @Tyriar et dans ces liens connexes:
https://github.com/alefragnani/vscode-project-manager/issues/46
https://github.com/Microsoft/vscode/issues/26068

Nous aimerions partager nos conceptions pour cela et obtenir vos commentaires. Pour ce faire, nous allons mettre en place un certain nombre de conf√©rences t√©l√©phoniques o√Ļ nous passerons en revue nos conceptions et discuterons de vos r√©actions aux conceptions.

Si vous souhaitez participer à ces discussions et nous aider à obtenir le bon design, veuillez me contacter (envoyez-moi un e-mail - stevencl at microsoft dot com) et je les installerai.

Nous espérons programmer ces discussions pour le jeudi 1er juin et le vendredi 2 juin.

@Tyriar @stevencl Merci les gars! :taper:

Merci à tous d'avoir rejoint les sessions aujourd'hui. Les enregistrements des sessions ont été postés ici

Veuillez regarder les vidéos et partager tout commentaire supplémentaire que vous avez sur les conceptions.

@stevencl merci d'avoir mené les études et de les rendre disponibles!

Super vidéos, merci! Quelques remarques:

  • ūüĎćūüĎćūüĎć pour la conception globale simple et l'extension naturelle du fonctionnement actuel de VSCode. Vous avez g√©r√© de nombreuses situations complexes d'une mani√®re simple et √©l√©gante. Bravo pour √ßa!
  • J'aime la notification SCM agr√©g√©e dans le coin inf√©rieur gauche, aucun changement n'est n√©cessaire de mon point de vue √† une exception pr√®s: je sauterais la fen√™tre contextuelle apr√®s avoir cliqu√© sur la notification SCM et j'irais directement au panneau SCM. Moins de clics = toujours mieux pour moi.
  • Le codage couleur des racines comme Alexey a sugg√©r√© est une id√©e int√©ressante, pourrait aider.
  • Recherche: la port√©e d'un dossier sera importante pour moi, je suppose que le champ "fichiers √† inclure" actuel pourrait √™tre utilis√© pour cela tr√®s bien, je voulais juste m'en assurer.
  • La seule chose dont je ne suis pas s√Ľr est la persistance et l'ouverture de tous les additionalFolders lorsque j'ouvre le path . Cela a du sens avec le dernier exemple o√Ļ express-project est clairement le "projet ma√ģtre" mais je ne suis pas s√Ľr de l'exemple pr√©c√©dent: express et express-plugin sentaient √©gaux, comme de vrais fr√®res et sŇďurs, et je ne suis pas s√Ľr de penser que l'ouverture de express ouvrirait √©galement express-plugin .

    • D'une certaine mani√®re, la structure de donn√©es derri√®re cela donne l'impression qu'elle devrait √™tre juste une liste plate de chemins, pas un "chemin" puis des "dossiers suppl√©mentaires".

    • Je ne suis pas s√Ľr que le concept d'un chemin principal soit aussi utile. Dans mes projets, ce n'est probablement pas le cas.

    • Pour ouvrir un espace de travail multi-racine, je m'attendrais √† une commande de niveau sup√©rieur comme _File> Open workspace_ en plus du _File> Open folder_.

    • Dans l'ensemble, je n'en suis pas trop s√Ľr. D√©sol√©, je n'ai pas de suggestions plus concr√®tes.

Merci encore, avec cela, VSCode gagnera de nouveaux super-pouvoirs ūüėĄ.

Merci d'avoir partagé les vidéos. Je souhaite prendre en charge la conception "une section par dossier racine":

one-section-per-root-folder

Au début, je m'attendais à une autre conception (semblable à un texte sublime), mais après avoir vu l'alternative "une section par dossier racine", il m'est apparu clairement que cette approche avait les avantages suivants:

  • Distinction et s√©paration claires et sans ambigu√Įt√© entre les dossiers (surtout si j'en ai plus de 2 ou 3, ce qui est souvent le cas lorsque j'utilise d'autres √©diteurs et IDE)
  • Renforce la notion qu'un dossier racine est un (sous) projet s√©par√©
  • Acc√®s rapide aux commandes du sous-projet (telles que "nouveau fichier", "actualiser" ... et, peut-√™tre √† l'avenir, faire un clic droit pour lancer une t√Ęche (par exemple "reconstruire") sur ce sous-projet sp√©cifique;))
  • Comme mentionn√© par le 2√®me groupe, avec cette conception, il est moins probable d'avoir le probl√®me de troncature de nom de dossier

Concernant le concept "une section par dossier racine" ... je ne suis vraiment pas s√Ľr que cela fonctionnera bien pour moi et la plupart de mes cas d'utilisation. Chaque fois que j'ai une situation √† racines multiples, il est courant d'en avoir plusieurs ; pas seulement 2 ou 3.
Je ne sais pas comment cette approche évoluera?

Un autre argument en faveur de la disposition actuelle de type dossier est qu'elle est cohérente avec la façon dont un monorepo serait affiché. Par exemple, comparez:

monorepo/      <- contains .git
  project1
  project2

contre.

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

Ces deux devraient vraiment être traités de manière assez similaire par VSCode: monorepo l'est déjà (committing: naturel, recherche: "fichiers à inclure", plusieurs README: leur dossier est affiché dans l'onglet éditeur; etc.). Multi-root devrait suivre cela aussi étroitement que possible, IMO, ce que la conception actuelle fait très bien.

@stevencl Une chose que je n'ai pas complètement comprise: la solution apportera-t-elle un traitement de portée (ou même hiérarchique) des paramètres .vscode ? Par exemple, si j'avais .vscode par dossier de niveau supérieur, ces paramètres seront-ils appliqués individuellement? Seront-ils en quelque sorte agrégés à la racine du projet? Ou est-ce que seul le .vscode "principal" comptera?

Je pr√©f√®re le design "une section par dossier racine", pour les m√™mes raisons que celles list√©es par @maddouri. De plus, apr√®s avoir utilis√© l'autre alternative (dans Atom), il est visuellement plus difficile de trouver o√Ļ un nouveau dossier racine commence lorsque plusieurs dossiers hautement hi√©rarchiques sont ouverts et d√©velopp√©s.

Merci pour les mises à jour de conception, ça a l'air vraiment bien!

Est-il possible d'avoir plusieurs espaces de travail disponibles à la fois dans l'interface utilisateur? Pour que vous puissiez facilement basculer entre eux. Par exemple, vous avez quelque chose comme:

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

Et puis cliquer / double-cliquer sur le diviseur CONNECT, CONNECT-PLUGIN basculerait vers cet espace de travail actif. Cela permettrait de basculer facilement entre les espaces de travail pour les personnes qui doivent gérer plusieurs ensembles de projets. Je ne suggère pas qu'ils soient tous disponibles pour la recherche et le SCM et ainsi de suite, cela resterait avec l'espace de travail actuel qui est actuellement élargi.

Cela pourrait alors fonctionner en mettant en √©vidence les dossiers racine comme sugg√©r√© dans le premier groupe, et peut-√™tre en ayant les nouvelles ic√īnes de fichier / dossier disponibles lors du survol de ces dossiers.

Quelques commentaires sur les paramètres JSON, il pourrait être utile que les paramètres de l'espace de travail soient quelque chose comme:

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

Ainsi, le root devient la source pour ouvrir les dossiers, plut√īt que le chemin, mais la racine elle-m√™me n'est pas ouverte, seulement chaque dossier. Vous n'avez alors pas de "dossier principal", mais gardez toujours les chemins de fichiers relatifs. Cela suppose que vous pouvez ouvrir un espace de travail pr√©d√©fini via l'interface utilisateur, au lieu d'ouvrir le dossier racine et tous les dossiers suppl√©mentaires avec. Le nom peut ensuite √™tre utilis√© comme s√©parateur, emp√™chant un grand nombre de noms de dossier de le rendre trop long ou de le raccourcir inutilement.

Si la solution ¬ęune section par dossier racine¬Ľ est choisie, je voudrais sugg√©rer que le dossier racine actuellement visible ¬ęcolle¬Ľ en haut de la barre lat√©rale, au lieu de d√©filer hors de vue. Il ne d√©filerait qu'une fois que le dossier racine suivant aurait atteint le haut de la barre lat√©rale.

Le 4 juin 2017 √† 06h47, Peter Petrov [email protected] a √©crit:

Je pr√©f√®re le design "une section par dossier racine", pour les m√™mes raisons que celles list√©es par @maddouri. De plus, apr√®s avoir utilis√© l'autre alternative (dans Atom), il est visuellement plus difficile de trouver o√Ļ un nouveau dossier racine commence lorsque plusieurs dossiers hautement hi√©rarchiques sont ouverts et d√©velopp√©s.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, affichez-le sur GitHub ou désactivez le fil de discussion.

Ou nous pouvons suivre l'approche Sublime, Atom, mais changer de couleur ou montrer d'une mani√®re ou d'une autre quel dossier est la racine et / ou le coller en haut. Bien s√Ľr, les deux approches sont bonnes, mais avoir beaucoup de dossiers ouverts r√©duit l'espace, car la barre avec actualisation, cr√©er un nouveau fichier, etc. sera visible, c'est pourquoi il vaut mieux ne pas charger la barre, mais montrer d'une mani√®re ou d'une autre quel dossier est la racine. MAIS encore une fois, cette barre est vraiment bonne, car il est beaucoup plus facile de voir les dossiers racine ouverts et vous pouvez les actualiser et faire d'autres choses qui sont incluses dans la barre. Nous devons voir √† quoi cela ressemble avec par exemple 10 dossiers ouverts avec et sans barre.

@stevencl Merci d'avoir publié ces enregistrements! Dans l'ensemble, je suis enthousiasmé par la direction dans laquelle la fonctionnalité se dirige! Merci pour tout le temps et les efforts investis jusqu'à présent. Voici mes commentaires / réflexions:

  • Je pr√©f√®re la premi√®re conception avec la conception de barre de nom de dossier unique sous "EXPLORER", cependant, je crains que si tous les noms de dossier y sont r√©pertori√©s, il sera tr√®s rapidement tronqu√© afin d'afficher le "ajouter un fichier", " Ajouter un dossier ", etc., boutons. Je pense que je mettrais juste la cha√ģne "Multiple" ou quelque chose de similaire quand plus d'un dossier est ouvert; sinon, il n'y a qu'un seul dossier, alors mettez le nom du dossier comme cela se fait aujourd'hui (et cachez la racine du dossier dans l'arborescence).
  • La clarification des noms de fichiers en ajoutant le nom du dossier dans le titre de l'onglet dans l'√©diteur, IMO, n'est pas n√©cessaire √† moins que plusieurs √©diteurs soient ouverts avec le m√™me nom de fichier. Notez que ce sc√©nario n'est pas rare m√™me avec un seul dossier ouvert. Il est assez facile d'obtenir plusieurs fichiers (par exemple .gitignore ) avec le m√™me nom parmi les sous-dossiers de la m√™me racine. Donc, cette conception (en ajoutant le nom du dossier parent) devrait √™tre une fonctionnalit√© distincte, IMO, et devrait √™tre impl√©ment√©e. Parall√®lement √† cela, j'aimerais voir une bonne solution pour https://github.com/Microsoft/vscode/issues/15048 car cela rendra certains titres d'onglets encore plus longs. :)
  • Pour les r√©sultats de recherche, je pense qu'il est essentiel que la recherche fonctionne dans tous les dossiers racine. Un autre filtre pourrait √™tre ajout√© pour limiter la recherche aux racines choisies. Lors de l'affichage des r√©sultats, il peut √™tre utile de voir les r√©sultats par racine, donc peut-√™tre une option pour voir une longue liste avec les noms de dossier racine ajout√©s, ou pour voir une liste s√©par√©e en sections, une pour chaque dossier racine.
  • Je trouve √©trange que vous proposiez d'ajouter des ¬ęespaces de travail¬Ľ aux param√®tres __user__. Je m'attendais vraiment √† ce que cela finisse dans les param√®tres __workspace__. Je pense que vous dites en fait que les param√®tres de l'espace de travail peuvent √©galement contenir la nouvelle propri√©t√© 'workspaces', ce qui est bien. C'est √©galement tr√®s bien que les chemins de l'espace de travail puissent √™tre relatifs. Cela ne semble tout simplement pas appartenir aux param√®tres utilisateur. C'est une fonctionnalit√© qui semble tr√®s sp√©cifique aux espaces de travail. Ah, mais maintenant je vois pourquoi il est √©galement valable dans les param√®tres utilisateur, car cela me permet de stocker ces espaces de travail lorsque je veux des dossiers ¬ęal√©atoires¬Ľ sur mon disque dur dans un espace de travail o√Ļ il n'y a pas de racine commune.
  • Une chose qui semble se perdre dans les espaces de travail lorsqu'ils sont stock√©s dans les param√®tres utilisateur est la possibilit√© d'attribuer d'autres param√®tres sp√©cifiques au projet √† un espace de travail ou √† un autre. Par exemple, si j'avais un espace de travail o√Ļ j'avais besoin que la taille de l'onglet soit de 2 espaces et un autre o√Ļ elle devait √™tre de 3, je ne pourrais pas le faire avec les espaces de travail dans les param√®tres utilisateur. Je devrais cr√©er un dossier quelque part, puis y mettre un dossier .vscode , puis d√©finir .vscode/settings.json afin de d√©finir enfin mon espace de travail avec le remplacement de taille d'onglet appropri√©. √Ä ce stade, je pense que cr√©er un nouveau type de fichier VSCode Project qui stocke tous ces param√®tres et peut √™tre ouvert en tant que fichier sp√©cial devient beaucoup moins fastidieux que d'avoir √† cr√©er cette hi√©rarchie de dossiers pour stocker l'espace settings.json travail

Dans la première conception, pour les dossiers supplémentaires, le chemin (relatif ou absolu) entre parenthèses peut être ajouté au nom pour la différenciation. Ce sera une solution simple, je pense.

@stevencl merci pour l'enregistrement des sessions. Je voulais vraiment participer mais je n'√©tais pas disponible √† l'√©poque ūüėĘ

J'ai aimé l'interface SCM proposée. Avoir une section récapitulative et une section par dossier me donne, à mon humble avis, une interface beaucoup plus facile pour détecter et travailler avec les changements. Et j'aime l'idée d'avoir un comportement cohérent dans toute l'interface utilisateur, donc l'idée Une section par dossier doit également être utilisée dans l'onglet Recherche , au lieu de concaténer le nom du dossier à chaque résultat. Idem pour l'onglet Explorateur .

Utiliser les paramètres utilisateur pour stocker le _Multi-dossier_ est un peu étrange pour moi, car il ne semble pas être un paramètre utilisateur_: smile :. Si l'intention est d'éviter de créer de nouveaux fichiers et de faciliter le transfert / la synchronisation des projets / espaces de travail entre les ordinateurs, pourquoi ne pas oublier les _ paramètres de l'utilisateur_ et faire de l'entrée additionalFolder _ toujours_ une partie du Workspace Settings . Ce faisant, lorsque vous _Ajoutez un dossier_, il sera ajouté uniquement au Workspace Settings . Ensuite, lors de l'ouverture d'un dossier, il vous suffit de rechercher le fichier .vscode\settings.json et une entrée additionalFolders là-dedans, pour vérifier _s'il s'agit d'un espace de travail multi-dossier_. _C'est similaire au deuxième exemple que vous avez utilisé, à propos des deux repos git manquants_.

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"
    ]
}

Prenez également en charge les emplacements _user-data_ tels que ~ et $home , ce qui facilite le partage de projets entre différents ordinateurs / plates-formes.

Je n'ai manqué qu'un seul point: l' API . Comment les extensions s'intégreraient-elles à cela?

Merci pour les efforts. Dans l'attente des premi√®res versions d'initi√©s ūüĎć

Merci pour les commentaires! Je voulais suivre la direction de l'exploitation d'une nouvelle propriété de paramètres additionalFolders pour implémenter "Multi Root" parce que j'entends des commentaires à ce sujet dans les commentaires ci-dessus.

La principale motivation pour introduire un paramètre en premier lieu est en fait de garder les choses simples et de ne pas introduire trop de nouveaux concepts tout en ayant toujours une solution puissante et permettant des scénarios intéressants. Voici quelques décisions de conception et leurs conséquences:

Rester simple
Nous pensons que l'ouverture de fichiers et de dossiers est au cŇďur de VS Code. Ainsi, nous ne voudrions pas introduire un nouveau concept de haut niveau de "Projets". Par exemple, nous ne pensons pas qu'une action ¬ęOuvrir un projet¬Ľ est n√©cessaire, mais plut√īt qu'un projet est toujours un dossier et qu'il peut √©ventuellement avoir des dossiers suppl√©mentaires associ√©s. Avec cette hypoth√®se, un cadre semble √™tre la mani√®re naturelle de permettre cela. Chaque fois que vous ouvrez ce dossier, vous ouvrez les dossiers suppl√©mentaires avec. L'ajout et la suppression de dossiers est un simple geste et met √† jour directement les param√®tres.

Les paramètres sont puissants
Avoir le multi-root comme paramètre permet de nombreux scénarios intéressants. Par exemple, vous êtes libre de placer le paramètre additionalFolders dans votre espace de travail et, en tant que tel, de le partager avec d'autres personnes (en utilisant des chemins relatifs - cela est montré dans les vidéos).
En plus de cela, vous √™tes √©galement libre de configurer les projets en premier lieu: par exemple, dans certains cas, il n'y a pas de relation claire entre un dossier ma√ģtre et des dossiers suppl√©mentaires (par exemple, il se peut que certains d'entre eux ne soient m√™me pas li√©s √† L'une et l'autre). Dans ce cas, vous pouvez simplement cr√©er un dossier "projet" qui inclut juste un settings.json avec les dossiers auxquels il renvoie:

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

Maintenant, lorsque vous ouvrez allMyRandomProjects il vous montrera la liste des dossiers en fonction des paramètres. Vous pouvez même inclure certains paramètres dans settings.json qui devraient s'appliquer à tous les dossiers affichés.

Changement d'espace de travail et fenêtres multiples
Sans aucun doute, nous devons travailler sur une meilleure commutation d'espace de travail et la prise en charge de plusieurs fen√™tres dans VS Code. √Čtant donn√© que nous traitons un espace de travail multi-racine de la m√™me mani√®re que tout autre espace de travail avec un dossier, l'am√©lioration du changement d'espace de travail et de la prise en charge de plusieurs fen√™tres profitera √† tous les utilisateurs, m√™me √† ceux qui n'utilisent pas les espaces de travail multi-racines.
Nous devrons rechercher des moyens meilleurs et plus faciles de basculer entre les dossiers et les fenêtres ouvertes indépendamment de la multi-racine.

Dans mon prochain commentaire, je fournirai quelques commentaires sur les commentaires individuels.

La recherche

@maddouri @TurkeyMan @pesho , @dgileadi @stefcameron il semble clair que certaines personnes préfèrent un seul arbre et d'autres préfèrent plusieurs sections dans l'explorateur. Nous pourrions donc nous retrouver avec un paramètre pour cela, il y a des avantages et des inconvénients pour les deux solutions et il devrait appartenir à l'utilisateur de choisir celle qui convient le mieux au scénario.

@borekb comment les param√®tres s'appliquent changera un peu selon que vous soyez dans une configuration multi-racine ou non: les param√®tres utilisateur s'appliquent toujours √† tous les dossiers ouverts comme auparavant. Les param√®tres de l'espace de travail seront extraits du dossier principal (¬ęma√ģtre¬Ľ) et appliqu√©s √† tous les fichiers et dossiers qui lui sont associ√©s. D√©sormais, vous pouvez toujours d√©finir les param√®tres de l'un des dossiers suppl√©mentaires via les param√®tres de l'espace de travail, m√™me si nous ne les prenons pas tous en charge. Par exemple, un param√®tre tel que update.channel: none ne peut pas √™tre pris en charge par dossier. Ce que nous aurons √† faire est d'identifier les param√®tres que nous pouvons prendre en charge au niveau du dossier (par exemple files.exclude , tous les param√®tres de l'√©diteur) et d'apporter les modifications n√©cessaires pour les activer. C'est l'un des principaux domaines de travail dans lesquels nous devons investir, d'autant plus que les extensions peuvent √©galement d√©finir des param√®tres que nous souhaitons prendre en charge sur une port√©e par dossier.

@BTMorton il me semble que vous voulez des moyens plus simples de changer d'espace de travail. C'est quelque chose que nous devrions examiner indépendamment de la multi-racine pour toute transition de dossier qu'un utilisateur peut faire.

@stefcameron nous garderons le paramètre additionalFolders suffisamment ouvert pour éventuellement y ajouter des métadonnées supplémentaires. Par exemple, je pourrais penser à pouvoir fournir un nom pour une telle configuration afin que la commutation entre les projets se fasse par nom et non par dossier principal.

Une chose que nous n'avons pas encore abordée dans les vidéos est de savoir comment les extensions peuvent prendre en charge les dossiers multi-racines. Un autre objectif principal avec le support multi-root (en plus de "Keep it simple") est: ne pas casser les extensions

Aujourd'hui, les extensions ont une API simple pour accéder à l'espace de travail actuellement ouvert ( workspace.rootPath: string ). Cette propriété peut être null si aucun dossier n'est ouvert.

Maintenant, avec l'introduction du paramètre additionalFolders , une extension peut toujours compter sur la propriété workspace.rootPath définie (si un dossier est ouvert), ou non (quand aucun dossier n'est ouvert). Puisque additionalFolders est en fait un paramètre, une extension est libre de lire et même d'écrire dans ce paramètre avec les API que nous avons déjà autour des paramètres. Il y a même un événement émis lorsque ce paramètre change, permettant une réaction dynamique à l'utilisateur modifiant ce paramètre.

La lecture de ce paramètre permet de rendre une extension consciente des dossiers supplémentaires dans l'espace de travail. Par exemple, l'extension Travis CI pourrait choisir d'afficher un état agrégé dans tous les dossiers.

L'écriture de ce paramètre permet des scénarios intéressants pour les extensions: par exemple, vous pouvez avoir une extension de gestionnaire de projet qui ajoute et supprime dynamiquement des dossiers dans votre espace de travail et permet ainsi des transitions de projet dans la fenêtre, par exemple en affichant une liste de projets via une interface utilisateur de sélection .

À un moment donné, nous allons probablement introduire une véritable nouvelle API d'extension pour gérer les dossiers multi-racines. Enterrer cela dans un paramètre pour les extensions à lire / écrire est un peu étrange. Mais pour commencer, les extensions peuvent déjà explorer le paramètre additionalFolders pour en tirer parti si possible. Nous travaillerons également en étroite collaboration avec les auteurs d'extensions pour comprendre leurs scénarios et comment mieux les soutenir.

@bpasero Le concept de dossiers supplémentaires sera-t-il également ajouté à LSP, ou VS Code démarrera-t-il simplement un serveur de langue par dossier supplémentaire?

@felixfbecker c'est quelque chose que nous devons encore investir et explorer pour trouver une bonne solution pour les extensions linguistiques. Une fois que nous pensons aux API supplémentaires pour les extensions, nous devons également réfléchir à ce que cela signifie pour le LSP.

Il convient cependant de mentionner qu'aujourd'hui, vous pouvez d√©j√† avoir des situations o√Ļ les utilisateurs ouvrent un fichier √† partir d'un dossier qui n'est pas ouvert en tant qu'espace de travail (par exemple, Fichier> Ouvrir> somefile.xyz). Id√©alement, une extension de langue peut afficher le m√™me niveau de fonctionnalit√©s de langue pour un tel fichier m√™me si le dossier de ce fichier n'est pas ouvert.

Au début, l'ouverture d'un fichier à partir de l'un des additionalFolders se comporterait de manière très similaire à l'ouverture d'un fichier qui ne se trouve pas dans le dossier que vous avez ouvert initialement. TypeScript, par exemple, peut bien gérer ce cas: ils marchent simplement du fichier actuellement ouvert jusqu'à ce qu'un fichier tsconfig.json soit trouvé, puis le traitent comme un projet. Des fonctionnalités telles que la recherche de références fonctionnent sans problème:

image

Ce serait bien si une extension de langage pouvait fonctionner en partant simplement du fichier actuellement actif au lieu de forcer à avoir un contexte de projet explicite.

@bpasero merci pour les commentaires. Il semble donc que dans le mod√®le actuel, il y aura toujours un dossier "ma√ģtre" : m√™me dans l'exemple allMyRandomProjects , il s'agit essentiellement du dossier ma√ģtre, bien que la plupart du temps vide. Cela a des implications subtiles, mais j'aurais besoin d'y r√©fl√©chir un peu plus pour fournir des commentaires utiles.

Dans l'ensemble, je pense que VSCode devrait prendre en charge monorepo par rapport à plusieurs référentiels d'une manière assez similaire, comme indiqué dans le commentaire ci-dessus: https://github.com/Microsoft/vscode/issues/396#issuecomment -306040485.

BTW, comment définissez-vous "root", exactement? Si j'ouvre le dossier A qui contient les sous-dossiers B et C, en quoi est-ce différent de définir A comme path et B et C comme additionalFolders ? L'intention de VSCode est-elle de traiter ces deux situations de manière assez différente ou fondamentalement la même? (Je pense que cela devrait être une expérience très similaire.)

@bpasero

Au début, l'ouverture d'un fichier à partir de l'un des dossiers supplémentaires se comporterait de manière très similaire à l'ouverture d'un fichier qui ne se trouve pas dans le dossier que vous avez ouvert initialement. TypeScript, par exemple, peut bien gérer ce cas: ils sortent du fichier actuellement ouvert jusqu'à ce qu'un fichier tsconfig.json soit trouvé, puis le traitent comme un projet. Des fonctionnalités telles que la recherche de références fonctionnent sans problème:

Cependant, TypeScript n'utilise pas LSP. Dans LSP, les serveurs de langues ont un rootUri , et par exemple PHP utilisera ce rootUri pour rechercher les fichiers qui doivent √™tre index√©s. Il n'a pas de fichier comme tsconfig.json qui d√©noterait un "projet". Donc, s'il y a des fichiers qui ne sont pas ouverts via didOpen mais √©galement pas sous rootUri , ils ne seront pas pris en compte pour l'intelligence du code, d'o√Ļ ma question de savoir si LSP sera √©tendu pour cela.

Juste pour clarifier, l'ouverture de plusieurs racines créerait-elle un fichier ./.vscode/settings.json s'il n'existait pas déjà?
D'après ce que j'ai lu ici jusqu'à présent, il semble que nous disions que ce serait le cas.

Je comprends pourquoi il est utile d'√©viter d'ajouter le concept de projets, mais il serait peut-√™tre bon de rendre la sauvegarde d'un espace de travail facultative - m√™me si dans ce cas, ¬ęenregistrer¬Ľ signifie simplement cr√©er un fichier de param√®tres dans le dossier racine.

Je pense que cela pourrait surprendre un utilisateur qui n'a pas suivi ce fil de discussion s'il a ouvert un deuxième dossier et qu'il a créé un fichier de paramètres. L'ouverture de dossiers est le genre de chose que je pense que la plupart des utilisateurs s'attendent à être en lecture seule.

Merci pour tous les commentaires à tous, c'est très utile.

@saborrie - bonne question sur la mesure dans laquelle les gens seraient surpris par la création d'un paramètre lors de l'ajout d'un dossier. Nous devrons enquêter sur cela pour voir si c'est le cas (évidemment avec des personnes qui n'ont pas suivi ce fil :-)).

@borekb - nous avons parlé du scénario que vous avez mentionné (ouvrir un dossier contenant un ou plusieurs sous-dossiers) et nous nous sommes efforcés de traiter cela de la même manière que d'ouvrir un espace de travail multi-racine. Le défi consiste cependant à déterminer quand traiter une telle situation comme multi-racine et pas seulement comme un dossier contenant d'autres dossiers.

Je serais également intéressé par ce que les autres pensent de cela.

@borekb vous additionalFolders propriété. Je pense que nous pouvons commencer à explorer cette évolution de l'interface utilisateur avec des dossiers contenant des paramètres additionalFolders , puis l'étendre à davantage de cas d'utilisation. Un autre scénario intéressant et connexe est la façon dont nous avons choisi de présenter des sous-modules dans un référentiel.

Je pense également que nous voulons finalement prendre en charge les paramètres .vscode à n'importe quel niveau de hiérarchie de dossiers une fois que nous aurons résolu les défis qui l'accompagnent.

Je parlerais moins de la relation ma√ģtre-d√©tails en parlant de multi-racine car la plupart des UX traiteront le dossier principal de la m√™me mani√®re que les dossiers suppl√©mentaires. Le dossier principal n'est en r√©alit√© que le conteneur des param√®tres des dossiers suppl√©mentaires et sera le pilote principal des param√®tres globaux de l'espace de travail. Pour la r√©trocompatibilit√©, ce sera √©galement celui que nous enverrons aux extensions en tant que rootPath .

@felixfbecker cela signifie-t-il que je ne peux pas faire de "Rechercher des références" ou des fonctionnalités de langage similaires lors de l'ouverture d'un seul fichier PHP de mon projet, j'ai besoin d'ouvrir ce dossier pour obtenir ces fonctionnalités? Je ne suis pas profondément en PHP, mais s'il existe un concept de dépendances entre fichiers, je ne pourrais pas naviguer vers un autre fichier PHP à partir d'un seul fichier, je dois d'abord ouvrir le dossier?

@saborrie nous n'ajouterions PAS de paramètre d'espace de travail par défaut lorsque vous ajoutez des dossiers. L'une des raisons pour lesquelles nous décidons de mettre cela dans les paramètres utilisateur est que l'espace de travail ne devienne pas "sale" avec la configuration multi-root. Il est possible de placer ce paramètre dans l'espace de travail, mais vous devrez le faire manuellement. Cela ne se produira pas par défaut.

@bpasero Ok oui, s'en tenir √† l'enregistrement dans les param√®tres utilisateur plut√īt que dans les param√®tres de l'espace de travail emp√™cherait la salet√© des dossiers de l'espace de travail - je suppose que cela enregistrerait toujours avant d'exiger de l'utilisateur qu'il effectue explicitement une action d'enregistrement, mais oui?

Cela me laisse avec deux questions complémentaires:

1) Que se passerait-il lorsqu'un utilisateur ouvre un espace de travail avec additionalFolders défini dans ses paramètres d'espace de travail? Cela serait-il synchronisé dans leurs paramètres utilisateur? et remplacerait-il l'entrée de cette racine d'espace de travail si elle existait dans la liste des espaces de travail des paramètres utilisateur? Ou vice versa?

2) Mettre cette liste d'espaces de travail dans les paramètres utilisateur est-il une meilleure option que d'éviter initialement de stocker les espaces de travail dans l'un de ces fichiers de paramètres JSON? Dans le système actuel à dossier unique, lorsqu'un dossier est rouvert à partir de l'élément de menu File > Open Recent , les onglets qui étaient ouverts précédemment sont mémorisés - pour autant que je sache, cela n'est stocké chez aucun utilisateur - fichier de paramètres modifiable, les chemins supplémentaires ne pourraient-ils pas être stockés de la même manière, jusqu'à ce qu'un utilisateur les enregistre explicitement?

- Désolé pour l'anglais, j'ai utilisé Google Translator -

Eh bien, je suis allé sur la mise en page, (oui - un peu de difficulté à comprendre l'anglais). Désolé alors...

Je n'ai pas aimé la mise en page présentée par @maddouri , principalement à cause des problèmes rencontrés dans ce numéro (# 25352, # 25354). Je pense que ce sera plus complexe même si vous devez utiliser le clavier pour accéder aux dossiers dans le modèle affiché.

Je préfère ce modèle, qui par l'idée je peux naviguer entre les différents dossiers de projet à l'aide des touches fléchées et si je dois créer un dossier / fichier dans le dossier principal, je peux utiliser la touche menu du clavier, directement dans le dossier.

explorernew

Et / ou avec les options de nouveau fichier, nouvelle mise à jour de dossier et Réduire tout.

explorernew2

En ce qui concerne le titre qui appara√ģt en haut, je pr√©f√®re qu'il se concentre sur le fichier actuel avec le dossier dans lequel il se trouve, ou au lieu d'afficher tous les dossiers principaux ouverts plus le fichier actuel, similaire √† cette image.

explorernew3

Et une question: les Open Editores existent-ils toujours?

@bpasero

cela signifie-t-il que je ne peux pas faire un "Rechercher des références" ou des fonctionnalités de langage similaires lors de l'ouverture d'un seul fichier PHP de mon projet, j'ai besoin d'ouvrir ce dossier pour obtenir ces fonctionnalités? Je ne suis pas profondément en PHP, mais s'il existe un concept de dépendances entre fichiers, je ne pourrais pas naviguer vers un autre fichier PHP à partir d'un seul fichier, je dois d'abord ouvrir le dossier?

C'est correct, si vous ouvrez simplement un seul fichier, vous ne pouvez pas accéder à la définition d'un fichier dans un autre fichier qui n'est pas ouvert, mais uniquement à ceux situés en dessous de rootUri . En effet, en PHP, chaque fichier peut vider des symboles dans l'espace de noms global, et les espaces de noms ne sont en réalité que des préfixes de nom pour les classes. Il n'y a aucune restriction sur la façon dont les espaces de noms et les noms de classes doivent correspondre aux répertoires et aux noms de fichiers (seulement quelques conventions), et il n'y a pas d'instructions d'importation comme dans TS, seulement des alias d'espace de noms. Le chargement des classes se produit au moment de l'exécution via des "autoloaders" enregistrés. Cela signifie que pour un serveur de langue sur go-to-definition, un symbole peut être défini dans n'importe quel fichier. Ainsi, le serveur de langue indexera tous les fichiers dans rootUri au démarrage, puis travaillera avec l'index pour répondre aux demandes. Ce qui fonctionne, c'est si vous avez un projet ouvert et que vous créez un nouveau fichier non enregistré - vous obtiendrez des informations pour cela, car vous avez obtenu le rootUri et le nouveau fichier via textDocument/didOpen . Mais tous les symboles définis dans des fichiers non ouverts qui ne sont pas inférieurs à rootUri ne seront pas pris en compte.

Les param√®tres de l'espace de travail additionalFolders dans l'espace de travail a toujours la priorit√©. Compte tenu de la nature de ce param√®tre cependant, vous ne pouvez remplacer les dossiers suppl√©mentaires du dossier actuellement ouvert que lorsque ce param√®tre est sp√©cifi√© dans l'espace de travail (cela est indiqu√© dans les vid√©os en ayant path: "." pour le "ma√ģtre").

Avoir cet état de l'interface utilisateur stocké de la même manière que par exemple le nombre d'onglets ouverts était une option dont nous avons discuté, mais nous n'avons pas trouvé qu'elle présente de nombreux avantages par rapport à un paramètre. Certaines raisons:

  • ce n'est pas partageable (ni via les param√®tres de l'espace de travail, ni via une extension de synchronisation des param√®tres)
  • ce n'est pas quelque chose que les extensions peuvent acc√©der facilement aujourd'hui (l'API de param√®tres existe, l'API d'√©tat de l'interface utilisateur ne le fait pas)

Y a-t-il une raison particulière pour laquelle vous ne voudriez pas ces paramètres internes?

@Tekbr oui, "Open Editors" fonctionnera comme avant

@felixfbecker est- ce que l'extension PHP pourrait facilement adopter quelque chose comme rootUri: string[] ? Ou préférez-vous que le serveur de langage PHP démarre plusieurs fois pour chaque dossier ouvert (par exemple, VS Code serait multi-plex au niveau des dossiers ouverts vers N serveurs de langue?)

@bpasero PHP pourrait fonctionner avec rootUris: string[] assez facilement. Cependant, d'autres serveurs linguistiques peuvent ne pas l'être. Générer plusieurs serveurs de langue signifierait que chaque dossier fonctionne de manière isolée (pas de saut à la définition, de recherche de toutes les références entre eux). Peut-être qu'une approche serait un nouveau ServerCapability qui décide si VS Code engendrera un ou plusieurs serveurs de langue.

J'aime le concept du réglage des dossiers supplémentaires. Pour moi, avoir un seul dossier racine suffit. Si je veux une fonctionnalité de développement complète sur un projet associé, je peux ouvrir une nouvelle fenêtre vscode.

Ce dont j'ai besoin dans les dossiers supplémentaires, ce sont simplement des fonctionnalités limitées. Par exemple, je pourrais vouloir une définition de symbole d'un projet associé à utiliser dans le projet racine mais pas besoin ou vouloir la possibilité de le renommer ou de trouver toutes les références pour celui-ci dans le dossier supplémentaire.

@bpasero Je préconise simplement d'envisager de rendre la création d'un espace de travail dans les paramètres facultative (et opt-in). Essentiellement, au lieu de modifier automatiquement les paramètres lorsqu'un utilisateur ajoute un dossier, commencez par celui-ci uniquement dans l'état de l'interface utilisateur, puis autorisez les utilisateurs à enregistrer cela dans les paramètres d'une manière ou d'une autre. Peut-être aussi permettre de choisir entre les paramètres de l'espace de travail ou les paramètres utilisateur.

Je ne suis pas compl√®tement contre le stockage enti√®rement dans les param√®tres, je fais juste ma part pour remettre en question la d√©cision de ne pas utiliser l'√©tat de l'interface utilisateur, juste au cas o√Ļ cela aurait √©t√© n√©glig√©.

@bpasero @saborrie Si nous

# 396 (commentaire)

@Tekbr oui, "Open Editors" fonctionnera comme avant

Merci pour la réponse, @bpasero.

TL; DR: Utilisez une arborescence chaque fois que cela a du sens au lieu d'ajouter le nom des racines à chaque élément.

Peu de choses, je n'aime vraiment pas la façon dont vous ajoutez le dossier à la fin, j'aimerais vraiment que ce soit une option car j'aimerais probablement l'avoir comme ça express\.editorconfig et express-plugin\.editorconfig donc peut-être pouvez-vous offrir l'option suivante: editor.tabName: "${root}\${filename}"

Une autre chose que je voudrais et que vous mentionnez dans la vid√©o est la coloration sur les racines pour correspondre aux onglets, donc ūüĎć pour cela.

Chercher:

Dans la vue Search , je pense en fait que vous faites une erreur en ce qui concerne l'expérience, dans mon esprit, elle devrait être affichée sous forme d'arbre, comme ceci:

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

Les raisons en sont:

  1. Vous pouvez facilement voir o√Ļ se trouvent les fichiers quelle que soit la longueur de leurs noms.

  2. Vous pouvez réduire les racines que vous ne voulez pas voir.

Je pense que cela correspond également plus au type de design que vous avez appliqué au Explorer .

T√Ęches:

Pour Tasks je préférerais avoir ce genre de vue:

express
    Compile
    Run Tests
express-plugin
    Compile
    Run Tests

Quelques points:

  1. À mon avis, vous ne devriez pas toucher / changer les noms de dossier, ce qui signifie que "express-plugin" devrait être affiché exactement comme il est affiché dans le Explorer et non comme "Express Plugin".

  2. Le d√©placement entre les t√Ęches avec le clavier peut √©galement √™tre fait de telle mani√®re qu'il ignore la s√©lection des racines, donc si vous descendez de express\"Run Tests" dans l'exemple, l'√©l√©ment suivant qui serait s√©lectionn√© est express-plugin\Compile comme par opposition √† express-plugin

ps Je n'ai pas encore vu toute la vidéo, mais ce sont juste des choses qui me sont venues à l'esprit.

Que faire si tous les dossiers racine que vous incluez dans votre espace de travail portent le même nom?
par exemple

  • / dev / project / public / src
  • / dev / framework / src
  • / dev / un-composant / src

Vous auriez alors un espace de travail avec:

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

Conformément à la manière _sublime_ d'inclure des dossiers dans un espace de travail, chaque racine de dossier virtuel a:

  • Chemin
  • Nom (facultatif) - il s'agit du nom du dossier s'il est exclu, mais peut √™tre affich√© comme n'importe quoi
  • Filtre d'exclusion pour les fichiers / dossiers

Voir la note https://github.com/Microsoft/vscode/issues/396#issuecomment -283541760 (ci-dessus) pour par exemple les métadonnées associées à cette façon de faire.

J'aimerais savoir que cette fonctionnalité est encore en phase de développement?

@ifzm C'est le cas et si vous lisez les dernières notes de publication (mai 2017 (version 1.13)), vous saurez qu'elles y travaillent activement.

@eyalsk Désolé, je n'ai pas regardé attentivement, c'est une fonctionnalité intéressante: D

Je ne suis pas fou du concept additionalFolders , même si je comprends le désir de garder les choses simples.

Il me semble étrange que l'un des dossiers stocke la configuration de l '"espace de travail".

Imaginez les dossiers racine suivants:

  • site Internet
  • api
  • mobile

... quel dossier doit contenir le paramètre additionalFolders ? Pourquoi?

Je pr√©f√®re l'id√©e d'un espace de travail / chef de projet, o√Ļ les param√®tres sont stock√©s dans un emplacement partag√© / g√©n√©ral. Je ne pense vraiment pas que cela soit compliqu√© d'un point de vue UX, et la terminologie existante workspace pourrait √™tre r√©utilis√©e / √©tendue.


Sans rapport: Je suis entièrement d'accord avec les commentaires de @eyalsk concernant les listes imbriquées (et la dénomination des onglets).

@ glen-84 dans ce cas, vous êtes libre d'avoir un quatrième dossier sur le disque appelé "my-mobile-website-project" qui a ce paramètre et des liens vers tous les autres dossiers.

@bpasero Je comprends cela, mais ce n'est vraiment qu'un hack.

√Člaborer:

Je suis occup√© √† travailler sur le website , et je d√©cide que je veux apporter des modifications au api . Si je clique sur Add Folder , cela va associer le api au website , de sorte que l'ouverture du website √† l'avenir ouvre le api ainsi que. J'ai besoin de comprendre comment cela fonctionne, et quand je le fais, je dois ouvrir une instance distincte de VSC, cr√©er un dossier vide correctement nomm√©, y ajouter les deux dossiers ¬ęprojet¬Ľ, puis fermer l'instance initiale.

En revanche, je pourrais simplement aller Add Folder , et cela pourrait (facultativement) me demander un nom d'espace de travail à utiliser à l'avenir pour ouvrir les deux dossiers en même temps.

workspaces.json (exemple)

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

Je me sens simplement plus flexible et moins gênant pour moi.

@ glen-84 compris. aller avec votre solution proposée rend l'utilisation de VS Code plus complexe, c'est pourquoi nous avons choisi de ne pas utiliser un tel concept. La raison principale est que tout à coup il n'y a pas seulement "Open File" et "Open Folder" mais aussi "Open Project". Rester avec les primitives que nous avons est l'approche la plus simple sans introduire de nouveaux concepts.

Cela dit, tout le travail que nous faisons maintenant pour prendre en charge plusieurs dossiers est également un bon travail pour des scénarios comme celui que vous proposez. Si jamais nous voulons soutenir votre scénario, les étapes pour y parvenir sont beaucoup moins lourdes car l'interface utilisateur est déjà adaptée. Je pourrais également imaginer qu'une extension pourrait peut-être introduire une telle notion d'espaces de travail et nous ajoutons simplement les API nécessaires pour prendre en charge cela.

Commençons par réussir l'expérience utilisateur sans introduire de nouveaux concepts, puis réfléchissons à d'autres scénarios autour des multi-dossiers. Il y a beaucoup de choses à regarder en premier (extensions, paramètres, interface utilisateur SCM, etc.).

la solution proposée rend l'utilisation de VS Code plus complexe

Je ne suis pas d'accord avec cela. Si un utilisateur est d√©rout√© par une fonctionnalit√© optionnelle ¬ęOpen Project¬Ľ (ou espace de travail), il est susceptible d'√™tre confondu par de nombreuses fonctionnalit√©s existantes dans VSCode. Ce n'est pas compliqu√© du point de vue de l'utilisateur (si quelqu'un lisant ceci n'est pas d'accord, veuillez le dire).

Je pourrais également imaginer qu'une extension pourrait peut-être introduire une telle notion d'espaces de travail et nous ajoutons simplement les API nécessaires pour prendre en charge cela.

L' extension existe déjà et a déjà été mentionnée à quelques reprises. L'auteur a même un support multi-dossier de suivi de ticket ouvert . Cette extension a plus de 370 000 installations et une note de 4,7. Même avec une interface utilisateur simpliste utilisant la palette de commandes, il y a peu de signes de confusion à en juger par les commentaires.

Commen√ßons par ma√ģtriser l'UX sans introduire de nouveaux concepts, puis r√©fl√©chissons √† d'autres sc√©narios autour des multi-dossiers

C'est assez juste. Quoi qu'il en soit, il s'agit de prendre en charge plusieurs dossiers racine dans la même fenêtre - la méthode réelle de gestion de ces groupes de dossiers pourrait être abordée ultérieurement.

Envisageriez-vous de créer un sondage public pour recueillir les opinions des utilisateurs sur le sujet (je connais les vidéos YouTube, mais je fais référence à cet aspect seul), ou la décision a-t-elle déjà été prise pour aller avec le additionalFolders concept?

Je suis d'accord avec @ glen-84. Je ne comprends pas le problème de la complexité. Oui, cela peut rendre les choses plus complexes, mais c'est un éditeur de code. Je pense que ce sont 95% des programmeurs qui l'utilisent, ce qui pourrait facilement comprendre l'idée de projets. Il ne devrait pas y avoir de souci de dérouter les gens de tous les jours parce que tous les jours, les gens ne l'utilisent pas.

Alors qu'une extension est en quelque sorte une solution, les extensions sont également de second ordre par rapport aux améliorations implémentées nativement (c'est-à-dire ne peuvent pas ajouter d'options aux menus, uniquement la palette de commandes, etc.).

@ glen-84, la décision a été prise d'utiliser le paramètre additionalFolders basé sur le sentiment de l'équipe de développement, les études utilisateur que nous avons effectuées (ces 2 vidéos) et les commentaires que nous avons reçus dans ce numéro.

@pltrant cela rend l'utilisation de multi-root plus complexe car vous devez constamment penser à ouvrir un dossier ou à ouvrir un projet. Des choses comme "Ouvrir Récent" nécessiteraient soudain plus d'attention si l'entrée choisie est un dossier ou un projet, ou pire, vous auriez même 2 sélecteurs et devez décider lequel utiliser.

Je ne sais pas en quoi le fait d'avoir un cadre est plus complexe. En gros, vous n'avez pas à vous soucier du paramètre, il vous suffit d'ajouter et de supprimer des dossiers à votre configuration et le paramètre est mis à jour en arrière-plan. Je dirais que vous ne regardez jamais la valeur de ce paramètre dans la plupart des cas.

@ glen-84 En ce qui concerne votre exemple de projet avec 3 dossiers de même importance, je pense que celui qui devrait contenir les paramètres additionalFolders devrait être décidé en fonction de la dépendance. Si le dossier API ne dépend pas d'un autre projet, lorsqu'il est ouvert, il doit être ouvert en tant que dossier unique et ne doit pas contenir de paramètres supplémentaires. Mais lorsque vous ouvrez le dossier mobile , je suppose qu'il dépend du dossier API. Ainsi, vous ajoutez les paramètres dans le dossier mobile pour ouvrir l'API en tant que dossier supplémentaire lorsqu'il est ouvert dans vscode. Il en va de même pour le site Web. Si cela dépend de l'API, ajoutez-y des paramètres. Sinon, aucun paramètre n'est nécessaire.

Je ne pense pas qu'il y aura une ouverture de dossier supplémentaire récursive ou en cascade. J'aime aussi l'idée d'extensions lisant d'autres formats de projet comme Visual Studio Solutions et suggérant / mettant en place des paramètres de dossier supplémentaires. Et vous pouvez toujours ouvrir le dossier parent commun de tous.

@stevencl a regardé les deux vidéos.

  1. La variante 2 avec l'homonymie semble la plus claire. Il semble que cela pourrait être pliable (c'est-à-dire l'une des racines de l'arbre), ce qui permettrait de voir de nombreux projets à la fois. Si vous avez besoin d'une maquette, faites-le moi savoir.

  2. La variante 2 est plus efficace du point de vue de l'immobilier sur écran. Vous n'aurez pas les mêmes informations (nom du projet) répétées en haut - comme dans l'option 1, puis affichées à la racine de chaque projet.

  3. Les résultats de la recherche et Git pourraient se comporter de la même manière ... qu'un arbre réductible. Les résultats seraient regroupés (selon w / statut) sous leur rubrique appropriée. Je suppose que si vous voulez un résumé navigable (comme vous l'avez montré pour GIT, ce serait une option qui pourrait exister à travers la recherche (combien de fichiers vous avez trouvé) et la zone du projet (cela pourrait abriter les boutons d'action).

Donc, en résumé, je suis fan des racines réductibles individuelles avec l'ajout éventuel du résumé navigable. Sorte d'une combinaison de l'Alternative 2 et de cet exemple

J'espère que, quoi que vous choisissiez, que vous fassiez une expérience similaire dans les différents mécanismes. Vous dites qu'il y avait deux alternatives, mais il y en a vraiment 4 puisque GIT et Search étaient tous deux différents. Je suis d ’accord avec celui qui a fait ce commentaire

Re: partage des informations multi-projets. Je pense que ce serait utile - comment vous l'avez serait raisonnable au d√©part - je lui ferais simplement utiliser des t√Ęches gulp - ou des t√Ęches que VS Code pourrait comprendre.

Merci pour tous vos efforts à ce sujet.

La mise en Ňďuvre de l'espace de travail multi-racine est en cours de suivi au # 28344 et dans ce jalon de juin.

@gulshan ,

Il peut y avoir des cas o√Ļ il n'y a pas de d√©pendances. Par exemple, si je travaille sur website et que je d√©cide d'ajouter mobile pour travailler dessus en m√™me temps. Il n'y a pas de d√©pendance entre les deux, mais maintenant website devient le "parent". Si je travaillais d'abord sur mobile , alors il deviendrait le parent. C'est juste un peu arbitraire. Les dossiers peuvent √©galement √™tre destin√©s √† des projets totalement ind√©pendants.

Quoi qu'il en soit, je respecte la décision des développeurs VSC, même si je ne suis pas forcément d'accord avec elle.

Merci pour tous les commentaires continus. Comme mentionné ci-dessus, nous suivons le travail dans le numéro 28344. Nous tiendrons compte de ces commentaires pendant que nous continuerons à travailler là-dessus, en particulier lors de la conception de l'expérience SCM. Comme cela a été discuté dans les vidéos et comme cela a été mentionné ci-dessus à plusieurs reprises, nous voulons assurer la cohérence tout au long de l'expérience.

En ce qui concerne le problème de complexité soulevé par @ glen-84,

La discussion √† ce sujet a √©t√© tr√®s utile et nous a donn√© quelques √©l√©ments √† consid√©rer pour notre conception actuelle. Par exemple, nous devrions peut-√™tre envisager d'autoriser les utilisateurs √† choisir le dossier ¬ęprincipal¬Ľ lorsqu'ils ajoutent un deuxi√®me dossier √† un espace de travail. Peut-√™tre que nous demandons cela lorsque l'espace de travail est ferm√©, peut-√™tre que c'est un param√®tre. Beaucoup de choses auxquelles nous devons r√©fl√©chir pour rationaliser l'exp√©rience.

Comme le mentionne @bpasero , nous sommes toujours très réticents à ajouter de nouveaux concepts (tels que des projets) à VS Code. Ce n'est pas parce que nous pensons que cela rendrait VS Code inutilisable, c'est davantage que des concepts supplémentaires ajoutent au poids ou au poids de VS Code, ce qui le rend plus complexe. De tels concepts seraient une autre chose à laquelle les développeurs doivent consacrer des ressources mentales.

De plus, une fois que quelque chose est dans VS Code, il est beaucoup plus difficile de le retirer (avec le temps, les gens s'y habituent et en d√©pendent). Nous passons donc beaucoup de temps √† r√©fl√©chir attentivement √† ce que nous ajoutons √† VS Code et √† ajouter quelque chose uniquement lorsque nous sommes convaincus que le co√Ľt de l'ajout de nouveaux concepts en vaudra la peine. Donc, pour l'instant, nous voulons d√©terminer le succ√®s d'une conception pour multi-racine qui n'ajoute pas de nouveaux concepts.

Encore une fois, merci pour les commentaires incroyablement précieux. Sans un dialogue comme celui-ci, il serait beaucoup plus difficile d'essayer de concevoir cette expérience.

Génial à quel point vous êtes attentionné et réactif à tous; c'est vraiment apprécié!

Ce qui n'a probablement pas encore été dit en ce qui concerne la complexité, c'est que vous en ajoutez de toute façon. Je pense que ces deux options sont actuellement discutées:

  1. Projets explicites.
  2. Quelque chose qui ressemble √† de simples dossiers multiples mais qui ne l'est pas - il existe un concept important de dossier principal qui concerne des choses comme rootUrl pour les extensions et √©ventuellement d'autres choses (h√©ritage des param√®tres de l'espace de travail, par exemple). Je pense que g√©n√©ralement, l'utilisateur de VSCode devra comprendre ce concept et qu'il serait peut-√™tre plus facile d'√™tre clair et franc √† ce sujet plut√īt que d'essayer de l'abstraire.

En fait, je pr√©f√©rerais la troisi√®me fa√ßon, vraiment ne rien introduire de nouveau, juste g√©rer des choses comme plusieurs .git d√©p√īts et recherches et t√Ęches et des choses comme √ßa de mani√®re transparente - en quelque sorte ce que les deux premiers tiers des vid√©os sugg√©r√© (j'ai beaucoup aim√© les wireframes). Cependant, j'ai r√©alis√© que rootUrl devait √™tre pris en compte pour les extensions, ce qui est probablement la principale raison pour laquelle cela est compliqu√©.

Si ce n'était pas pour rootUrl , je commencerais simplement par les mises à jour de l'interface utilisateur proposées dans les wireframes plus la persistance locale de l'espace de travail multi-racine, de la même manière que tous les autres dossiers sont conservés dans "Open Recent".

Je voudrais r√©p√©ter que de mon point de vue, l'√©tat id√©al est o√Ļ VSCode fonctionne avec plusieurs dossiers, qu'ils soient des racines SCM ou non (monorepo ou plusieurs d√©p√īts, voir ci-dessus). Je crois que les wireframes propos√©s ainsi que quelques travaux de base suppl√©mentaires comme l'h√©ritage des param√®tres .vscode seraient suffisants pour la "v1" du support multi-root. "Projets" ou "dossiers primaires + suppl√©mentaires" pourraient venir plus tard, l'OMI. Cependant, ce que je dis pourrait tomber avec rootUrl , je n'en suis pas s√Ľr, je veux juste transmettre mon sentiment g√©n√©ral √† ce sujet.

C'est formidable que vous essayiez de résoudre ce problème difficile et de garder la simplicité autant que possible!

J'ai un projet de noeud backend et frontend, et j'ai 2 éditeurs VisualCode ouverts, ce qui représente une contrainte de ressources importante.

J'ai regardé les deux vidéos et je suis d'accord avec un commentaire ci-dessus selon lequel ces multiples projets n'ont rien à voir l'un avec l'autre. Peut-être que l'un pourrait être un projet nodejs tandis que l'autre est C ++.

Je n'aimais pas l'id√©e qu'un des projets devienne le projet "ma√ģtre", avec les projets suppl√©mentaires ajout√©s. Chaque projet doit √™tre √©gal et ind√©pendant.

Je me serais attendu √† pouvoir ouvrir un dossier, puis ouvrir un autre dossier (pas ADD). Le dossier sera simplement ajout√© comme dans la vid√©o 1, les racines apparaissant simplement (mais afficher les chemins complets dans une info-bulle lors du survol du dossier racine). Ces projets n'auraient aucun lien. S√©lectionner l'un ou l'autre entra√ģnerait un changement de contexte. Ce serait comme si je basculais entre 2 instances de Visual Code, les deux param√®tres, les jeux de couleurs, etc.

La façon de conserver ces multiples projets serait de les enregistrer en tant que nouveau fichier de projet, qui référence les deux autres projets, mais sans modifier aucun des 2 projets eux-mêmes. En d'autres termes, les 2 projets restent indépendants, autonomes et ignorent le 3ème projet (fichier de paramètres) qui les référence.

Une fois ce 3ème fichier enregistré / créé, il devrait être possible de créer des paramètres qui remplacent les paramètres des projets A et B. Les paramètres non créés dépendront à nouveau du projet actif.

Lors du partage du projet, on peut partager le fichier de projet qui fait référence aux deux autres. Lorsqu'ils sont absents du système de fichiers, mais qu'ils contiennent une référence à leurs URL github, il doit demander à l'utilisateur s'il veut les récupérer (par défaut en tant que sous-dossier à la racine de ce fichier de projet principal, mais l'utilisateur peut rechercher un emplacement pour chacun).

La possibilité de rechercher dans plusieurs projets devrait être facultative, et la capacité d'exécuter et de déboguer plusieurs projets simultanément serait très utile, mais semble vraiment trop complexe pour une première version, et peut-être qu'un tel cas d'utilisation devrait de toute façon nécessiter l'exécution de 2 instances. Au moins pour l'instant.

À quoi cela devrait ressembler dans l'interface utilisateur est la deuxième étape, mais fonctionnellement, c'est ainsi que je m'attendrais à ce que cela fonctionne. Je n'aime pas l'idée de modifier le projet A pour faire référence à B ou vice versa, et c'est un peu ce que j'ai compris comme l'intention. Pour le développeur Agile, je serais simplement heureux si je pouvais travailler sur 2 projets dans 1 fenêtre sans avoir à exécuter 2 instances, mais pas plus que cela pour le moment. Peut-être même pas avec le 3ème fichier de projet prioritaire, mais uniquement avec le changement de contexte.

Merci pour les commentaires continus. Il existe un thème précis concernant le retard de la persistance d'un espace de travail à plusieurs dossiers jusqu'à une action explicite de l'utilisateur (comme enregistrer). Nous devrons réfléchir davantage à ce sujet et approfondir nos recherches.

Je sugg√©rerais √©galement aux d√©veloppeurs de jeter un Ňďil √† Eclipse IDE sur la fa√ßon dont il
gère cette fonctionnalité, ils l'ont compris il y a longtemps et cela fonctionne
génial.

Le mar 13 juin 2017 √† 9 h 11, Steven Clarke [email protected]
a écrit:

Merci pour les commentaires continus. Il y a un thème précis sur
retarder la persistance d'un espace de travail à plusieurs dossiers jusqu'à ce que certains
action de l'utilisateur (comme enregistrer). Nous devrons y réfléchir davantage
et enquêter plus avant.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-308110390 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAQsBWywBoe2KQRGuXKHv179MmugstCfks5sDop7gaJpZM4Gm3nX
.

-
Daniel Sokolowski
Architecte technique

Groupe Stantive Technologies Inc.
Téléphone: +1 (613) 634-7410
http://www.stantive.com

Avis de confidentialité:
Les informations transmises sont destinées uniquement à la personne ou entité à
auquel il est adressé et peut contenir des informations confidentielles et / ou privilégiées
Matériel. Toute diffusion de retransmission d'avis ou toute autre utilisation de ou
prendre des mesures en se fondant sur ces informations par des personnes ou
les entités autres que le destinataire prévu est interdite. Si vous avez reçu
ceci par erreur veuillez contacter immédiatement l'expéditeur par retour électronique
transmission, puis supprimez immédiatement cette transmission, y compris tous
les pièces jointes sans copier, distribuer ou divulguer les mêmes.

Projet principal
Je suis contre un projet MASTER. Le changement de contexte se produit fréquemment lorsque vous travaillez avec différents microservices. Ceci s'applique aux points suivants sur le peluchage et le SCM.

Persistance de l'espace de travail
Je pense que lors de la première itération, nous ne devrions pas avoir à persister dans l'espace de travail. Je préférerais des itérations sur une ou deux versions pour cette fonctionnalité avant d'introduire des paramètres ou des couches de persistance pour minimiser toute sorte de migrations complexes ou destructives.

Peluches / Réglages
Les peluches spécifiques au projet doivent être espacées de noms dans les fichiers des répertoires correspondants. Par exemple, le projet A utilise plus joli tandis que le projet B utilise la norme. La commutation entre les deux contextes doit être transparente sans que les règles de peluchage ne soient en conflit les unes avec les autres.

Chercher
J'ai ador√© certains des wireframes de celui-ci o√Ļ les r√©sultats de recherche √©taient sur tous les projets et tri√©s par projet.

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

_Project B_
file3: matched substring
file4: matched substring

SCM
Dans ce cas, je penche davantage vers l'affichage d'une ventilation par projet à chaque changement de scm.

_Project A_
file1: added
file2: removed
...

_Project B_
file3: moved
file4: added
file5: added

J'ai l'impression que ces approches sont plus transparentes et intuitives.

Le consensus (basé sur des commentaires récents et d'autres problèmes) semble être contre l'idée de additionalFolders , du moins dans la version initiale.

Bien que je sache que la d√©cision a d√©j√† √©t√© prise, envisageriez-vous de tenter d'impl√©menter cette fonctionnalit√© en tant qu'ensemble d'API, tout en laissant la persistance pour une it√©ration ult√©rieure? Ainsi, des API pour ajouter / ouvrir des dossiers et des mises √† jour de l'explorateur, de la recherche, des t√Ęches et des vues SCM pour prendre en charge cela.

Vous avez parlé de la difficulté de supprimer quelque chose du produit (si un concept de projet / espace de travail a échoué), mais la réalité est que cela s'applique également (sinon plus) au concept additionalFolders .

Implémenter à la fois additionalFolders et "projets / espaces de travail" en tant qu'extensions vous permettrait de collecter des données d'utilisation sans vous engager dans un seul modèle. L'une de ces extensions (ou une solution hybride) pourrait ultérieurement être intégrée au produit.

Les probl√®mes d'environnement ont-ils √©t√© r√©solus sur Mac OS? Je suis toujours incapable d'utiliser Homebrew npm et autres sans ouvrir VSCode depuis la ligne de commande via code et cela va s√Ľrement faire des ravages avec le support multi-root?

Ouais, c'est un must pour moi aussi. Je ne comprends pas les problèmes des gens. Ce n'est peut-être pas la façon dont une personne travaille, mais cela ne signifie pas que la gestion de l'espace de travail préférée d'une autre personne est moins valide. Je déteste simplement les réponses "Pourquoi voulez-vous faire ça?" au lieu de "Voyons comment ajouter une fonctionnalité que tous les autres éditeurs de code dans le monde ont."

De retour à Atom, je suppose.

@saborrie https://github.com/Microsoft/vscode/issues/24961 (j'obtiens le même problème sur les Insiders et les versions régulières). Si je peux aider à le déboguer, je suis partant.

@akutz, ces gars-là ont déployé beaucoup d'efforts pour concevoir un système multi-racine décent, ils ont même mis en place des vidéos de leurs sessions de conception (c'était dans les dernières notes de publication). Cela arrive, mais ils s'assurent de bien faire les choses :-) (https://code.visualstudio.com/updates/v1_13)

Salut @cliffrowley ,

Ravi de l'entendre. J'ai récemment jeté un autre regard sur VSCode car j'utilise Atom depuis toujours (et Sublime avant cela). Récemment, Atom a posé problème et dans un fil Reddit, j'ai vu que VSCode était vraiment une excellente option ces jours-ci. J'ai donc été surpris qu'il ne prenne pas en charge une fonctionnalité de base.

Je ne fais qu'empiler ici - c'est vraiment la seule fonctionnalit√© qui m'emp√™che d'envisager de passer d'IntelliJ / WebStorm √† VSCode √† plein temps ... principalement parce que, comme l'a mentionn√© un pr√©c√©dent poster, je travaille avec des architectures distribu√©es toute la journ√©e et j'ai besoin de plusieurs gestionnaires Git int√©gr√©s √† mon √©diteur (parce que je suis trop paresseux ūüėÜ)

J'adore le fait que vous travaillez tous l√†-dessus, et j'ai h√Ęte de le voir en action.

J'aime vscode mais cette "fonctionnalité manquante" m'empêche de passer complètement de l'atome au vscode

Une première version est déjà dans la version Insiders. Va le chercher :)

+1 Besoin de cette fonctionnalité

La première version de prévisualisation est très gentille!
Il y a déjà un petit problème avant même de commencer à tester correctement ...
Quand j'ajoute deux dossiers ¬ęracine¬Ľ avec le m√™me nom de deux projets s√©par√©s, il n'y a rien pour distinguer ces dossiers.

par exemple j'ajoute /dev/www/myproject/src puis j'ajoute /dev/libraries/mycomponent/src
Tout ce que je vois, ce sont deux dossiers racine appelés src .

> src
> src

Je pense que nous avons besoin d'un moyen de changer le nom d'affichage des dossiers racine.
Ce qui afficherait alors:

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

Pensées?

VSCode affiche une partie du nom du dossier lorsque vous ouvrez deux fichiers avec le même nom, qui pourraient également fonctionner avec des dossiers?

@doublehelix nous en avons discut√© r√©cemment, mais nous n'avions aucun suivi du probl√®me. J'ai cr√©√© https://github.com/Microsoft/vscode/issues/29871 , merci ūüėĄ

@Tyriar Je trouve vraiment la fonctionnalité de recherche déroutante pour le moins et je pense qu'elle devrait afficher les résultats de la même manière que celle affichée dans le Explorer comme je l'ai déjà dit .

Je ne sais pas si vous avez regardé ce que moi et certaines personnes avons dit ci-dessus ou s'il y a d'autres changements à venir, mais personnellement, je n'aime pas la façon dont vous ajoutez le nom de la racine à chaque fois par opposition à trier les choses dans un arbre - comme vue lorsque cela est possible.

@eyalsk C'est un travail en cours, je regarderai plus les résultats de recherche en juillet: # 29977

Le projet vscode est basé sur un dossier.
Ainsi, vous pouvez configurer la configuration de chaque projet séparément, et vous pouvez utiliser le Git intégré directement, ou non vous ne pouvez pas.

PyCharm: coeur:: coeur:: coeur:

+1

Je dois vous féliciter, chère équipe VSCode.
Enfin, je peux abandonner Atom depuis que les espaces de travail multi-racines ont atterri dans les versions Insiders!
Depuis deux ans .gitignore etc. ne sont pas respectés dans Atom lors de la recherche dans les espaces de travail multi-root et vous l'avez compris dès le début!

La persistance des espaces de travail est-elle suivie dans un autre problème?

Hier, l'√©quipe VS Code a publi√© une nouvelle version de VS Code avec la fonctionnalit√© Espaces de travail multi-racines ūüéČ.

Le r√©sultat de ce travail est ce que nous appelons un ¬ęproduit minimum viable¬Ľ (MVP) pour permettre les tests sur plusieurs espaces de travail de dossiers racine.

En fait, n'est disponible que dans la version Insiders, vous pouvez donc le télécharger ici Télécharger VS Code Insiders

Explorateur de fichiers

Chercher

Supposons que chaque dossier ajout√© √† l'espace de travail soit un r√©f√©rentiel git distinct - la version actuelle des espaces de travail multi-racines g√®re-t-elle le contr√īle de source diff√©renci√© de ces r√©f√©rentiels?

@Weyzu, nous travaillons à l'adoption de SCM pour les scénarios multi-racines à cette étape. Notre réflexion initiale est que la vue SCM doit devenir compatible avec le multi-référentiel, ce qui n'est pas nécessairement la même chose que la prise en charge du multi-dossier comme dans l'explorateur et la recherche: déjà lorsque vous ouvrez un seul dossier dans VS Code, vous pouvez avoir plusieurs référentiels dans . Nous pensons que la vue SCM devrait afficher ces référentiels de manière adéquate afin que vous puissiez voir les changements sortants / entrants pour chaque référentiel ainsi que pour pouvoir valider les fichiers de chaque référentiel.

Le r√©sultat devrait offrir une meilleure exp√©rience pour les sc√©narios multi-racines ainsi que pour les sc√©narios de racine unique o√Ļ plusieurs r√©f√©rentiels sont contenus dans une racine.

Le r√©sultat devrait offrir une meilleure exp√©rience pour les sc√©narios multi-racines ainsi que pour les sc√©narios de racine unique o√Ļ plusieurs r√©f√©rentiels sont contenus dans une racine.

Excellente approche, vous êtes rock!

@bpasero g√©nial! Je serais certainement int√©ress√© de voir le point de vue de vos gars. IntelliJ / WebStorm a quelque chose de similaire o√Ļ il d√©tecte automatiquement les racines Git et les aligne pour vous de mani√®re appropri√©e en bas √† droite, et j'ai personnellement ador√© l'utiliser.

image

Avez-vous pensé à quelque chose de ce genre ou à quelque chose d'un peu plus élaboré?

Nous sommes toujours en train de trier l'UX pour cela et vous tiendrons au courant des résultats.

Une racine de système de fichiers virtuel ne pourrait-elle pas fonctionner ici? Cela agirait effectivement comme si la racine VFS était le répertoire parent de plusieurs chemins disparates.

Je voulais donner une mise √† jour sur notre travail multi-root parce qu'aujourd'hui est le premier jour o√Ļ notre UX multi-racine r√©vis√© est sorti d'initi√© et beaucoup d'entre vous qui se sont habitu√©s √† l '¬ęancien¬Ľ comportement pourraient √™tre confus ce qui se passe.

Les défauts de l'ancienne solution
L'ancienne solution pour multi-racine introduirait un nouveau param√®tre workspace (dans le global settings.json ) qui permet d'ajouter des dossiers suppl√©mentaires √† un seul dossier racine. Le param√®tre ressemblait √† ceci au cas o√Ļ vous ne l'auriez pas remarqu√©:

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

Nous appelons cette solution le dossier ¬ęma√ģtre¬Ľ avec des dossiers suppl√©mentaires (¬ęd√©tail¬Ľ).

C'était la solution la plus simple sans introduire beaucoup de nouveaux concepts mais avec aussi des défauts:

  • vous ne pouviez plus jamais ouvrir le dossier ma√ģtre en tant que dossier unique car le param√®tre persistait
  • vous n'avez pas pu supprimer le dossier ma√ģtre de l'explorateur
  • certains param√®tres du dossier ma√ģtre appliqu√©s √† tous les autres dossiers
  • vos param√®tres sont pollu√©s par des √©l√©ments de configuration multi-racine
  • il est difficile d'autoriser l'ouverture de quelques dossiers en m√™me temps (par exemple, lorsque vous ouvrez 3, quel dossier ma√ģtre devons-nous prendre?)

Notre solution
Nous pensons qu'un concept d'espace de travail plus explicite est n√©cessaire pour les sc√©narios multi-racines et, en tant que tel, dans l'initi√© d'aujourd'hui, vous verrez une nouvelle interface utilisateur appara√ģtre:

image

L'id√©e est que les espaces de travail multi-racines n√©cessitent la cr√©ation d'une action explicite. De la m√™me mani√®re que vous pouvez √™tre dans un espace de travail vide (aucun dossier ouvert, barre d'√©tat violette) ou dans un espace de travail √† un seul dossier (barre d'√©tat bleu clair), vous pouvez √©galement √™tre dans un espace de travail multi-racine (√©tat bleu fonc√© bar). Cette troisi√®me fa√ßon d'ouvrir un espace de travail dans VS Code permet d'avoir autant de dossiers que vous le souhaitez. Ces espaces de travail peuvent √™tre enregistr√©s dans un fichier (par exemple myWorkspace.code ) et inclure √©galement des param√®tres d'espace de travail. Cependant, vous n'√™tes pas oblig√© de les enregistrer, tant que vous ne souhaitez pas les enregistrer, ils appara√ģtront sous la forme "Espaces de travail sans titre".

Pour ouvrir un espace de travail, vous pouvez soit ouvrir le fichier d'espace de travail enregistré, soit choisir dans la liste récemment ouverte:

image

Tout cela est du code très jeune et très jeune UX, alors attendez-vous à des changements au cours des prochaines semaines. Nous savons qu'il y a encore des choses à régler (par exemple, comment pouvons-nous rendre la transition d'un dossier unique à plusieurs dossiers plus fluide).

Quelques changements qui ont déjà été apportés aujourd'hui et qui toucheront la publication d'initiés de demain en fonction des commentaires:

  • renommer .code en .code-workspace comme extension pour les espaces de travail
  • avoir une liste unifi√©e de dossiers et d'espaces de travail (par exemple dans Fichier> Ouvrir r√©cent) au lieu de faire la distinction entre les dossiers et les espaces de travail

Restez √† l'√©coute pour plus √† venir ūüĎć

En plus de cela, nous avons maintenant un dossier .vscode par dossier de projet contenant le fichier settings.json . Ce fichier peut contenir les éléments suivants:

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

Le problème ici est que lorsque nous voulons travailler avec plusieurs utilisateurs (session RDP différente) sur le serveur sur les mêmes dossiers de projet, nous partageons les mêmes paramètres. Ce n'est peut-être pas le comportement prévu. Je pourrais aimer que ma taille de police soit plus grande que celle de mon collègue.

Donc, à mon avis, vous devez également prendre en compte le fait que différents utilisateurs peuvent travailler sur les mêmes dossiers mais avec des paramètres différents dans settings.json .

@ DarkLite1 vous

Votre exemple concerne le paramètre editor.fontSize que nous prenons en charge par dossier même dans un espace de travail multi-racine. Je pense que cela pourrait être un scénario valide qu'un utilisateur souhaite avoir une taille de police plus grande pour un dossier contenant beaucoup de documentation de démarquage (même une police différente peut-être?). Je pense donc qu'il ne faut pas empêcher de respecter ce paramètre par dossier également dans un environnement multi-root.

Si vous souhaitez conserver editor.fontSize comme paramètre d'espace de travail personnel, je pense qu'il ne devrait pas être archivé dans le référentiel.

Avec le nouveau concept d'espaces de travail, vous pouvez effectuer les opérations suivantes:

  • Fichier> Espaces de travail> Nouvel espace de travail
  • Choisissez votre dossier
  • Ouvrir les param√®tres de l'espace de travail
  • Changer editor.fontSize: 15

À partir de là, votre espace de travail portera ce paramètre, mais vous ne le forcez à personne d'autre.

Du point de vue UX, ce serait pratique si je peux glisser-déposer des dossiers dans une fenêtre VS Code sans avoir à créer explicitement un espace de travail au préalable (c'est quelque chose que je fais tout le temps dans Sublime). Je travaille invariablement sur plusieurs projets en même temps, et en fonction de ce sur quoi je travaille, ce sera un ensemble de projets différent (qui se chevauchent) chaque jour.

Les espaces de travail introduiraient un concept qui n'est pas natif de ma façon de travailler, et je devrais suivre les différentes configurations d'espace de travail (si je comprends bien), ce qui semble créer un encombrement de configuration dans mes dossiers de projet.

De plus, je pense que je parle au nom de nombreux utilisateurs si je soutiens que des choses comme la recherche, la configuration sont globales par défaut (s'appliquent à tous les dossiers ouverts) - même si ce serait bien si j'aurais la possibilité de rechercher localement dans un dossier ( J'ai toujours trouvé cela délicat dans Sublime).

@SanderMertens Vous avez peut-être manqué ceci mais @bpasero a écrit;

Ces espaces de travail peuvent √™tre enregistr√©s dans un fichier (par exemple myWorkspace.code) et inclure √©galement des param√®tres d'espace de travail. Cependant, vous n'√™tes pas oblig√© de les enregistrer, tant que vous ne souhaitez pas les enregistrer, ils appara√ģtront sous la forme "Espaces de travail sans titre".

Maintenant, je ne sais pas si vous auriez la possibilité de faire glisser et déposer des dossiers, mais d'après ce que j'obtiens, les gens auraient la possibilité d'ouvrir des dossiers arbitraires sans créer d'espace de travail.

J'ai h√Ęte que cette fonctionnalit√© soit incluse dans la version stable.

Yay! ūüėĄ

Actuellement, vous ne pouvez pas faire glisser un dossier dans l'explorateur pour l'ajouter, mais c'est dans notre backlog. La complication avec cette interaction est que nous ne connaissons pas l'intention de l'utilisateur: ouvrir le dossier dans la fenêtre ou l'ajouter à l'espace de travail?

La transition d'un dossier vers de nombreux dossiers est actuellement une étape plus explicite par rapport à ce que font les autres éditeurs (vous devez aller via Fichier> Espaces de travail> Enregistrer l'espace de travail et choisir les dossiers que vous voulez). Il y a plusieurs raisons pour lesquelles nous voulons adopter le comportement actuel jusqu'à ce que la multi-racine se stabilise. La raison principale est que le multi-root est un changement majeur pour toutes nos extensions. Bien que l'explorateur fonctionne et que vous puissiez rechercher dans tous les dossiers, la plupart des extensions ne fonctionneront pas correctement tant que la nouvelle API multi-racine ne sera pas adoptée. En tant que tel, nous ne voulons pas rendre trop facile au début l'entrée multi-racine par accident. C'est un geste utilisateur explicite pour entrer dans des espaces de travail multi-racines et dans ce mode, nous pourrions vouloir attirer l'attention sur le fait que certaines extensions ne fonctionnent pas encore.

Une autre raison est les paramètres de l'espace de travail: imaginez ce flux:

  • vous commencez avec 1 dossier qui a des param√®tres d'espace de travail
  • vous ajoutez un deuxi√®me dossier (supposons que cela fonctionne sans changement de contexte et sans rechargement de fen√™tre)
  • vous ouvrez les param√®tres de l'espace de travail
    => les paramètres de l'espace de travail en multi-racine sont maintenant stockés dans un emplacement en dehors des dossiers car vous pouvez avoir plusieurs
    => nous devons probablement demander à l'utilisateur si l'utilisateur souhaite migrer les paramètres de l'espace de travail vers ce nouvel emplacement

Donc, quoi qu'il arrive, entrer en multi-racine n'est pas une opération légère actuellement. Nous pourrions revoir cela lorsque la poussière retombera et que le multi-racine sera largement adopté, mais pour l'instant, nous pensons que ce modèle est meilleur et évite la frustration.

@bpasero Je pense que par d√©faut, une fois que vous faites glisser un dossier dans l'explorateur, il ne devrait pas l' enregistrer automatiquement dans l'espace de travail m√™me s'il en existe un et cela devrait √™tre une action explicite o√Ļ l'utilisateur clique sur le (s) dossier (s) il / elle gliss√© puis ajoutez-le explicitement √† l'espace de travail et si vous avez peu de dossiers non li√©s, il peut √™tre judicieux de fournir une autre action pour les enregistrer tous √† la fois.

Tout dépend des cas d'utilisation que l'on souhaite couvrir. J'ai découvert par expérience que KISS est toujours la meilleure approche. L'introduction de Workspaces sonne bien comme feature mais quel est le véritable avantage et quels sont les inconvénients?

Un inconvénient qui vient à l'esprit lors de l'introduction et de l'utilisation de Workspaces est qu'il doit stocker ses données (paramètres) quelque part et qu'il nécessite une maintenance / sensibilisation de l'utilisateur.

Supposons que le seul objectif soit de donner aux utilisateurs la possibilité de travailler avec plusieurs dossiers dans une session VS Code. Rien de moins, rien de plus.

Cas d'utilisation le plus courant:
Il n'y a pas Workspaces concept @SanderMertens , moi et probablement d'autres là-bas aussi.

Défis / problèmes / questions:

  • Pourquoi existe-t-il des fichiers de param√®tres diff√©rents? Param√®tres utilisateur, param√®tres de l'espace de travail? Il devrait IMHO tous √™tre stock√©s dans un seul et m√™me endroit. De pr√©f√©rence dans l'utilisateur son dossier / profil personnel, ainsi chaque utilisateur sur le syst√®me peut avoir ses propres param√®tres. Bonus suppl√©mentaire. ils n'encombrent pas les fichiers du projet et plusieurs utilisateurs peuvent faire leur propre travail. Effacer le profil? G√©nial! Clean Slate pour VS Code aussi.

Je pense que Workspaces sont un peu trop techniques si vous voulez:
Rapidit√©, simplicit√© et √©diteur qui fonctionne, pas de complication excessive ni de compr√©hension de concepts suppl√©mentaires. Si les utilisateurs de Sublime ou d'autres √©diteurs n'utilisent pas ce concept dans leur flux de travail, cela devrait indiquer qu'ils r√©fl√©chissent trop. Ou cela pourrait signifier que quelque chose de vraiment g√©nial a √©t√© invent√© que d'autres √©diteurs mettront √©galement en Ňďuvre, mais j'ai des doutes.

Je suis désolé si cela semble comme une diatribe, ce n'est absolument pas mon intention. Mais je pense que nous pouvons faire mieux en ce qui concerne l'accès multi-racine / dossier.

@ DarkLite1 merci d'avoir pris le temps de fournir des commentaires sur notre nouvelle stratégie pour les espaces de travail.

Je suis d'accord avec tous vos points et je souhaite √©galement une solution simple. Les espaces de travail en tant que concept est notre premier pas vers une solution multi-racine qui fonctionne avec nos mod√®les existants (param√®tres d'espace de travail, extensions, etc.). Comme il s'agit de la premi√®re √©tape, attendez-vous √† des bords plus rugueux (par exemple, la transition de 1 √† N dossiers n'est pas aussi l√©g√®re qu'elle pourrait l'√™tre). Notre objectif est de faciliter cette transition et de ne pas la rendre plus complexe qu'elle ne le sera √† l'avenir. Et nous ne voulons pas non plus forcer un utilisateur √† g√©rer ces espaces de travail (c'est pourquoi nous avons des "espaces de travail sans titre" qui durent tant que la fen√™tre est ouverte et dispara√ģtront une fois que vous aurez ferm√© cette fen√™tre).

Il y a quelques choses à garder à l'esprit concernant les espaces de travail multi-racines qui ne sont peut-être pas si évidentes. J'espère que l'explication détaillée suivante aidera à comprendre notre processus de conception:

Paramètres de l'espace de travail
Nous prenons en charge les paramètres dans un dossier d'espace de travail (dossier .vscode ). Même si certains utilisateurs peuvent ne pas aimer ce type de paramètres qui se retrouvent dans des fichiers .gitignore ou dans le référentiel, il y en a beaucoup qui dépendent de cette fonctionnalité. Nous ne pouvons pas simplement arrêter de prendre en charge les paramètres qui résident dans des dossiers parce que les utilisateurs comptent sur eux. Désormais, pour les scénarios multi-racines, il est clair que nous devons trouver un nouvel emplacement pour les paramètres de l'espace de travail. Nous avons proposé le concept d'un fichier d'espace de travail contenant ces paramètres. Tant que l'espace de travail n'est enregistré nulle part, il réside dans un dossier contenant d'autres données spécifiques à VS Code et lorsque vous enregistrez le fichier, les paramètres seront dans ce fichier.

Imaginez maintenant que vous démarrez avec 1 dossier dans VS Code qui a des paramètres d'espace de travail définis et que vous souhaitez ajouter un deuxième dossier. Que devons-nous faire maintenant? Ignorer les paramètres de l'espace de travail du premier dossier? Demander à l'utilisateur de migrer les paramètres? Nous avons décidé d'en faire un changement de contexte explicite pour indiquer clairement que l'ouverture d'un espace de travail comporte ses propres paramètres d'espace de travail dans un emplacement différent.

Et maintenant, imaginez que vous êtes passé de 1 dossier à 2 dossiers et que nous avons déplacé les paramètres de l'espace de travail vers un autre endroit. Imaginez que vous modifiez ces paramètres de l'espace de travail. Maintenant que vous souhaitez revenir de 2 dossiers à 1, vous attendez-vous à migrer les paramètres de l'espace de travail dans le dossier?

Autre exemple: vous passez de 1 à 2 dossiers et configurez les paramètres de l'espace de travail. Maintenant vous fermez la fenêtre. Je pense que vous seriez en colère contre nous si vous ne pouviez pas revenir à cet espace de travail d'une manière ou d'une autre parce que vous avez soigneusement configuré les paramètres de cet espace de travail. Donc, même si vous n'aimez pas le concept d'espace de travail, une fois que vous en avez configuré les paramètres, je pense que vous voulez que cet espace de travail vive.

J'espère que ces exemples vous permettront de comprendre un peu plus facilement pourquoi KISS n'est pas aussi facile pour nous qu'on pourrait le penser.

Extensions
Toutes nos extensions fonctionnaient toujours avec une API qui fournit un seul chemin d'espace de travail car jusqu'à présent, nous ne prenions pas en charge les espaces de travail multi-racines. En tant qu'utilisateur, vous pourriez penser que passer d'un dossier à deux dossiers est une opération très simple et légère, mais pour les extensions, cela peut signifier beaucoup de choses: les extensions de langue qui jusqu'à présent supposaient qu'il n'y avait qu'un seul dossier doivent soudainement être conscientes de plusieurs Dossiers. Et en plus de cela, ces dossiers peuvent aller et venir de manière très dynamique à tout moment.

L'introduction d'un véritable concept d'espace de travail nous donne plus d'espace et de temps pour nous étendre et aide les extensions à adopter ce concept. Nous pourrions par exemple désactiver les extensions qui n'ont pas encore adopté les espaces de travail multi-racines pour éviter que des choses étranges ne se produisent (par exemple, une extension de langue ne fonctionne que sur un dossier et signale des erreurs erronées sur l'autre).

Essayons de nous stabiliser sur le support multi-root avec ces nouveaux espaces de travail, puis revisitons à quel point nous pouvons faire les transitions en toute légèreté. Une fois que nous avons des extensions à bord et que nous avons compris notre histoire de paramètres, je pense que nous pouvons passer à une expérience plus légère.

PS: puisque vous faites référence à d'autres éditeurs en ce qui concerne leur support multi-racine, je voulais juste souligner que ces éditeurs sont également livrés avec un espace de travail ou un concept de projet que vous pouvez enregistrer dans un fichier et partager avec d'autres. En général, vous ne voyez pas ces concepts car passer de 1 à N dossiers est une opération très légère. Je dirais cependant que les personnes qui s'appuient sur cette fonctionnalité commencent à se déplacer vers des espaces de travail / projets enregistrés pour gérer le travail. Par exemple, sauf si vous enregistrez l'espace de travail / projet et fermez la fenêtre, toutes ces informations sont perdues.

@bpasero merci de revenir vers moi et pour l'explication détaillée, j'apprécie vraiment cela.

Comme je ne connais pas parfaitement Sublime, j'ai pris la liberté de vérifier comment ils gèrent cela. Et vous avez raison, ils utilisent aussi des fichiers Workspaces et même Project . La seule chose qui me dérange un peu, c'est qu'il met des fichiers VS Code entre mon projet. Mais comme vous l'avez mentionné, si d'autres s'appuient sur cela, il faut tenir compte du fait que c'est peut-être ce qu'il y a de mieux. Je me demande seulement pourquoi ces fichiers de paramètres ne sont pas spécifiques à l'utilisateur? Je peux imaginer un collègue ouvrant VS Code sur la même structure de dossiers, mais souhaitant avoir ses propres paramètres.

Si Workspaces sont la voie à suivre, et il semble que ce soit le cas, il serait logique à l'ouverture de l'application qu'elle rechargera les derniers paramètres utilisés. Même s'il s'agit d'un Workspace non enregistré. Cela rend la vie un peu plus simple, je suppose.

Pourquoi ai-je choisi VS Code? Parce que c'est multiplateforme, comme j'utilise Linux √† la maison et Windows au travail, cela pourrait vraiment devenir mon √©diteur par d√©faut! En prime, je suis un d√©veloppeur PowerShell et il existe √©galement une extension. Donc deux grosses victoires l√†-bas! En plus de cela, pour le cours Java que je suis, Red Hat cr√©e √©galement une extension pour VS Code. Donc, une fois que vous aurez mieux conna√ģtre VS Code, avec ses raccourcis et tout, vous en b√©n√©ficierez √† tous les niveaux.

L'application et ses extensions sont encore un peu en version bêta ou même alpha à certains moments, mais tout de même, excellent travail les gars! J'apprécie vraiment les efforts et les progrès réalisés chaque jour dans Insider. Continuez votre excellent travail et passez un bon week-end.

Merci pour cette explication @bpasero , je pense que je comprends mieux maintenant quelle est la complexité.

Une approche pourrait être de traiter conceptuellement tout ensemble de projets avec la même configuration qu'un espace de travail. En plus de cela, vous pouvez vous abstenir d'ajouter un dossier .vscode tant que le projet ne diverge pas de la configuration par défaut. Cela devrait:
1) √Čliminez la plupart des encombrements dans les projets
2) éviter la plupart des conflits de configuration lors de l'ajout de projets (dans le cas simple, il n'y aura pas de configuration)

Je pense que le concept d'espace de travail explicite tel que discut√© est une bonne solution au probl√®me mentionn√©. Avec ces deux r√®gles simples, je minimise les cas d'utilisation o√Ļ les gens se heurtent √† ce probl√®me.

Pour moi, en regardant les commentaires dans le fil, et mes cas d'utilisation, je vois _Multi-folder_ et _Workspaces_ comme deux concepts différents, et peut-être qu'il devrait également être traité séparément.

Il ne devrait pas forcer à _créer un espace de travail_ simplement pour ajouter un autre dossier à la fenêtre courante. Il devrait simplement ajouter le nouveau dossier dans l'arborescence et laisser l'espace de travail nouvellement créé comme une _information interne_. Si l'utilisateur décide d'enregistrer l'espace de travail, alors l'espace de travail est vraiment créé. Et même si je n'enregistre pas l'espace de travail, lors de la réouverture du dossier supérieur, il _ se souviendra_ de mon espace de travail temporaire_ et ouvrira également les autres dossiers, tout comme il se souvient des fichiers ouverts lorsque vous ouvrez un dossier aujourd'hui. BTW, je me demande comment je pourrais ouvrir plusieurs dossiers en ligne de commande.

Pour mes cas d'utilisation, le multi-dossier est juste un moyen de voir plus d'un dossier à la fois dans la même fenêtre, pas une approche _Project Group / Solution_. Ainsi, une solution plus simple conviendrait. Mais je comprends comment les autres ont besoin d'un _Workspace_, avec ses propres paramètres et donc: thumbsup :.

Ce qui me d√©range le plus dans ce nouveau concept d'espaces de travail (par rapport √† la premi√®re it√©ration utilisant le User Settings ) est la m√™me chose qui m'a d√©rang√© lorsque j'utilisais Sublime Text. Le fait que vous _pouvez_ enregistrer les fichiers .code-workspace _n'importe o√Ļ_, et maintenant je dois g√©rer un endroit commun pour les stocker. Ce serait beaucoup plus simple, √† mon humble avis, qu'il s'int√®gre automatiquement dans l'un de ces deux endroits:

  • dans le dossier user-data-dir , comme User Settings et Keybindings
  • dans le _Top Folder_

Pour être clair, je comprends le concept d'espace de travail plus complexe dont les autres utilisateurs ont besoin. Je voulais juste une approche plus simple pour un concept plus simple de plusieurs dossiers.

J'aime cette option, ajoutez cette option.
dddsa
Parce que le dossier à l'intérieur n'est pas très impressionnant.
default
ou ajoutez la possibilité de modifier cette option.

J'aime l'id√©e de Workspace! Des id√©es sur le moment o√Ļ cela sera pr√™t?

Est-il pr√©vu √† ce stade que les informations git dans le coin inf√©rieur gauche ne refl√®tent pas avec pr√©cision la branche git du d√©p√īt dans lequel se trouve le fichier actuellement focalis√©? Je n'ai rien vu √† propos de "plusieurs racines git" dans les notes de version v1_15.

J'utilise cette fonctionnalit√© maintenant avec la version Insider depuis quelques jours et je dois dire que c'est tout ce que je voulais. Exp√©rience utilisateur tr√®s propre et j'ai h√Ęte que ce soit dans la version principale pour pouvoir convertir toute mon √©quipe √† cela.

Lorsque vous travaillez avec NodeJS et que plusieurs modules NPM sont ouverts à la fois, la façon dont il rassemble tout dans une seule fenêtre est un gain de temps énorme.

D'énormes accessoires pour l'équipe!

Pourquoi cette fonctionnalit√© appara√ģt-elle dans mes notes de publication avec un gif et une explication, mais n'est pas disponible dans l'√©diteur actuel?!

@ShashankaNataraj qui est

Notre feuille de route pour le travail multi-racine en cours est captur√©e dans https://github.com/Microsoft/vscode/issues/28344 et se poursuivra jusqu'en ao√Ľt, septembre et probablement aussi octobre.

Nous garderons cette fonctionnalité disponible uniquement chez les initiés jusqu'à ce que:

  • nous pouvons fournir une exp√©rience SCM, de d√©bogage et de t√Ęches compatible multi-racine appropri√©e
  • nous avons adopt√© des API et des fonctionnalit√©s multi-racines pour les extensions que nous livrons et auxquelles nous contribuons activement (par exemple, Go)
  • les auteurs d'extensions ont eu suffisamment de temps (par exemple 1 jalon) pour adopter les nouvelles API multi-racines

Veuillez comprendre que nous voulons √©viter de livrer cette fonctionnalit√© √† stable et d'avoir une exp√©rience d'extensions cass√©es car nous avons pr√©cipit√© cette fonctionnalit√© trop t√īt.

Merci d'être des professionnels, excellent travail!

@bpasero Je

Merci

@FelikZ veuillez consulter notre feuille de route (https://github.com/Microsoft/vscode/issues/28344). Pour la version de septembre, nous prévoyons d'adopter les extensions que nous livrons dans VS Code et pendant que nous y travaillons, nous ajoutons les API et les utilitaires nécessaires pour le faire.

En septembre, voici le plan:

image

La mise à jour d'initiés d'aujourd'hui comporte quelques modifications du fichier .code-workspace que je voulais résumer ici. Les espaces de travail existants avec le format précédent seront automatiquement migrés vers le nouveau format.

L'ancien format ressemblait à ceci:

{
    "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"
    ]
}

Et le nouveau format est:

{
    "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 de l'espace de travail
L'ID de l'espace de travail est utilisé pour associer plusieurs éléments à l'espace de travail:

  • tout l'√©tat de l'interface utilisateur (par exemple, les fichiers ouverts)
  • tout l'√©tat de fichier sale (aka sortie √† chaud)
  • √©tat des extensions (le cas √©ch√©ant)

Nous avons décidé de supprimer la propriété id du fichier d'espace de travail et de calculer à la place le id automatiquement en fonction du chemin d'accès absolu du fichier d'espace de travail sur le disque. Cela présente quelques avantages et inconvénients, mais en fin de compte, nous pensons que les avantages en font une meilleure solution:

  • c'√©tait bizarre que vous puissiez √©diter le id dans le fichier simplement en tapant une autre valeur
  • il n'√©tait pas tr√®s clair comment traiter le id lors du partage du fichier d'espace de travail avec d'autres (faut-il changer le id ? Le id devrait-il √™tre un uuid?)
  • il n'√©tait pas possible de copier un fichier d'espace de travail et de l'ouvrir dans une fen√™tre s√©par√©e, vous deviez d'abord changer le id dans le fichier copi√©
  • par cons√©quent, l'action "Enregistrer l'espace de travail sous" devrait demander √† l'utilisateur si la copie doit avoir un id ou non

Un inconvénient de cette approche est qu'une fois que vous déplacez ou renommez un fichier d'espace de travail, l'état associé sera perdu. Les fichiers sales ("hot-exit") rouvriront toujours après un redémarrage, mais ils s'ouvriront dans une fenêtre vide et ne seront plus associés à la fenêtre de l'espace de travail. Nous pensons toujours que nous pouvons améliorer ce comportement, même s'il se comporte de manière cohérente avec ce qui se passe aujourd'hui lorsque vous renommez un dossier avec l'état de l'interface utilisateur associé et les fichiers modifiés.

Dossiers
Nous avons décidé de revoir le format de la propriété folders .

  • nous ne vous demandons plus d'utiliser des URI de ressources, mais uniquement des chemins de fichiers pour faciliter l'√©dition
  • nous avons chang√© les entr√©es de la propri√©t√© folders en objets afin que nous puissions associer des m√©tadonn√©es aux entr√©es si n√©cessaire (par exemple, chaque dossier pourrait avoir une propri√©t√© name suppl√©mentaire)

Enfin, la prise en charge des chemins relatifs a également atterri. Vous pouvez entrer un chemin de fichier relatif et il sera résolu par rapport au dossier parent du fichier d'espace de travail. Notez qu'en raison du bogue https://github.com/Microsoft/vscode/issues/33188, nous

@bpasero c'est génial. Quand la propriété supplémentaire name fonctionnera? En ce moment, j'ai deux dossiers avec le même nom dans mon espace de travail et c'est affreux.

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

Une mise à jour de la gestion des chemins relatifs : à partir de la version actuelle d'initiés, nous écrirons les chemins d'accès au fichier d'espace de travail en tant que chemin relatif si l'emplacement du fichier d'espace de travail est un parent de la cible. En d'autres termes, les chemins seront désormais toujours relatifs à moins que nous devions utiliser la notation " ../ " pour exprimer le chemin.

√Čtant donn√© que les espaces de travail sans titre r√©sident toujours dans le r√©pertoire de donn√©es de VS Code, les chemins d'acc√®s y seront toujours absolus. Mais une fois que vous avez enregistr√© un espace de travail sans titre dans un emplacement, nous r√©√©crirons les chemins si possible.

Si vous √™tes curieux de conna√ģtre les modifications apport√©es aux espaces de travail multi-racines au cours de ce sprint, consultez les notes de publication mises √† jour .

+1

+1

@bpasero √Ä mon humble avis , la fa√ßon dont les √©tats de l'interface utilisateur sont g√©r√©s (s'il utilise une cha√ģne d'ID dans le fichier .code-workspace , ou en utilisant le chemin du fichier comme ID √† la place) n'est pas ad√©quate.
Renommer un fichier .code-workspace , ou l'un de ses dossiers parents, ou le d√©placer, et perdre l'√©tat de l'interface utilisateur est √† mon avis totalement non intuitif. Je pense que les gens qui ne savent pas comment cela fonctionne sous le capot n'auraient absolument aucune id√©e de la raison pour laquelle ils ont perdu leur ancien statut d'assurance-ch√īmage et de la fa√ßon de le r√©cup√©rer.
Cela ne devrait pas du tout être lié au chemin absolu des fichiers dans le système de fichiers!

Cela s'applique également à la façon dont l'état de l'interface utilisateur est lié au chemin du dossier actuellement dans la version stable. J'étais très confus à ce sujet au début, jusqu'à ce que je fasse quelques recherches sur Google.

IMO Dans le cas o√Ļ nous avons affaire √† un seul dossier, l'√©tat de l'interface utilisateur doit √™tre enregistr√© dans le dossier .vscode . Si nous avons affaire √† un espace de travail multi-racine, l'√©tat de l'interface utilisateur doit √™tre enregistr√© en tant que fichier s√©par√© dans le m√™me dossier que le fichier .code-workspace en utilisant les conventions de d√©nomination appropri√©es (ou peut-√™tre dans ce fichier lui-m√™me, bien que les param√®tres de m√©lange et l'√©tat n'est peut-√™tre pas une bonne id√©e).

S'il est correctement mis en Ňďuvre, cela permettrait aux utilisateurs d'avoir un acc√®s complet aux √©tats de l'interface utilisateur, d'attacher de nouveaux √©tats d'interface utilisateur √† un espace de travail donn√© (multi-racine ou non), etc.
J'adorerais pouvoir synchroniser l'√©tat de l'interface utilisateur entre diff√©rents ordinateurs, par exemple travailler au bureau, puis rentrer √† la maison, prendre un ordinateur portable ou autre et continuer exactement l√† o√Ļ je m'√©tais arr√™t√©.
Avoir plusieurs états d'interface utilisateur attachés à un espace de travail et basculer facilement entre eux (menu / liaison de touches / commande / etc.) lorsque vous travaillez sur différentes fonctionnalités serait également génial. Peut-être différents fichiers .code-uistate à l'intérieur de .vscode répertoriés automatiquement, ou de nombreux fichiers .code-uistate préfixés selon le principal .code-workspace , ou répertoriés dans un tableau.

Je pense à cela comme une extension du fonctionnement des projets et des espaces de travail sur Sublime Text. Même fonctionnalité, design différent. Dans ce cas, un espace de travail VS Code serait similaire à un projet Sublime, et les différents états de l'interface utilisateur VS Code seraient similaires aux espaces de travail Sublime.

Concernant ces problèmes:

c'était bizarre que vous puissiez modifier l'identifiant dans le fichier simplement en tapant une autre valeur

Oui tout à fait. Supprimer l'ID de là était le bon choix.

il n'était pas très clair comment traiter l'id lors du partage du fichier de l'espace de travail avec d'autres (l'id doit-il être changé? l'id doit-il être un uuid?)

Eh bien, si nous avons myproject.code-workspace et myproject.code-uistate c'est à l'utilisateur de décider de partager ou non l'état de son interface utilisateur. Plus besoin de penser à ce que signifie cet identifiant, comment il est généré, s'il doit être un UUID pour éviter les conflits lors du partage, etc.
Vous souhaitez partager la configuration et les paramètres des dossiers? Envoyez myproject.code-workspace , ne vous inquiétez pas.
Envie de tout partager? Envoyez les deux fichiers.

il n'était pas possible de copier un fichier d'espace de travail et de l'ouvrir dans une fenêtre séparée, vous deviez d'abord changer l'id dans le fichier copié

Si vous souhaitez commencer avec un nouvel état de l'interface utilisateur avec la même configuration de dossier et les mêmes paramètres, dupliquez simplement votre fichier .code-workspace .

par conséquent, l'action "Enregistrer l'espace de travail sous" devrait demander à l'utilisateur si la copie doit avoir un identifiant différent ou non

C'était délicat car l'utilisateur ne savait pas ce qu'était cet identifiant. Il serait peut-être plus simple d'avoir deux options "Cloner l'espace de travail avec l'état actuel" et "Nouvel espace de travail vide". Mais c'est UX et vous devrez faire une analyse à ce sujet.

D'accord avec Franc, conservez tous les fichiers de configuration du projet dans les paramètres
dans les projets, jetez un Ňďil √† Eclipse IDE qui a le droit
approche. Il a le concept de paramètres de projet et d'espace de travail avec
les valeurs par défaut d'écrasement du projet dans l'espace de travail. Workspace est juste un dossier avec
dossiers représentant des projets. Ayez donc le dossier .vscode dans l'espace de travail
dossier, et chaque projet a son propre dossier .vscode . Et s'il te pla√ģt ne le fais pas
votez simplement pour mentionner Eclipse IDE.

Le lun 18 sept. 2017 à 20:52, Franco Gallardo Grazio <
[email protected]> a √©crit:

@bpasero https://github.com/bpasero IMHO, la façon dont les états de l'interface utilisateur sont gérés
(si c'est en utilisant une cha√ģne d'ID dans le fichier .code-workspace, ou en utilisant
le chemin du fichier comme ID à la place) ne convient pas.
Renommer un fichier .code-workspace, ou l'un de ses dossiers parents, ou déplacer
autour, et la perte de l'état de l'interface utilisateur est à mon avis totalement inutile. je
pense que les gens qui ne savent pas comment cela fonctionne sous le capot auraient absolument
aucun indice sur la raison pour laquelle ils ont perdu leur ancien état d'interface utilisateur et comment obtenir
il revient.
Cela ne doit pas être lié au chemin absolu des fichiers dans le fichier
système du tout!

Cela s'applique à la manière dont l'état de l'interface utilisateur est lié au chemin du dossier actuellement dans le
version stable également. J'étais très confus à ce sujet au début, jusqu'à ce que je
fait quelques recherches sur Google.

IMO Dans le cas o√Ļ nous avons affaire √† un seul dossier, l'√©tat de l'interface utilisateur doit √™tre enregistr√©
dans le dossier .vscode. Si nous avons affaire à un espace de travail multi-racine,
L'état de l'interface utilisateur doit être enregistré dans un fichier distinct dans le même dossier que le
.code-workspace en utilisant les conventions de dénomination appropriées (ou peut-être
dans ce fichier lui-même, bien que le mélange des paramètres et de l'état puisse ne pas être
bonne idée).

S'il est correctement mis en Ňďuvre, cela permettrait aux utilisateurs d'avoir un acc√®s complet
aux états de l'interface utilisateur, attachez de nouveaux états de l'interface utilisateur à un espace de travail donné (
non), etc.
J'aimerais pouvoir synchroniser l'état de l'interface utilisateur entre différents ordinateurs, par exemple
travailler au bureau, puis rentrer à la maison, prendre un ordinateur portable ou autre et
continuer exactement l√† o√Ļ je me suis arr√™t√©.
Avoir plusieurs états d'interface utilisateur attachés à un espace de travail et basculer facilement entre
(menu / raccourci clavier / commande / etc.) lorsque vous travaillez sur différentes fonctionnalités
être génial aussi. Peut-être différents fichiers .code-uistate dans .vscode
listés automatiquement ou de nombreux fichiers .code-uistate préfixés selon
l'espace de travail principal .code, ou répertorié dans un tableau.

Je pense à cela comme une extension de la façon dont les projets et les espaces de travail
travailler sur Sublime Text. Même fonctionnalité, design différent. Dans ce cas, un
L'espace de travail VS Code serait similaire à un projet Sublime, et les différents
Les états de l'interface utilisateur de VS Code seraient similaires aux espaces de travail Sublime.

Concernant ces problèmes:

c'était bizarre que vous puissiez modifier l'identifiant dans le fichier simplement en tapant
une autre valeur

Oui tout à fait. Supprimer l'ID de là était le bon choix.

il n'était pas très clair comment traiter l'identifiant lors du partage du fichier d'espace de travail
avec d'autres (l'id doit-il être changé? l'id doit-il être un uuid?)

Eh bien, si nous avons myproject.code-workspace et myproject.code-uistate
Ensuite, c'est à l'utilisateur de décider de partager ou non l'état de son interface utilisateur.
Plus besoin de penser à ce que signifie cet identifiant, comment il est généré, s'il le faut
un UUID pour éviter les conflits lors du partage, etc.
Vous souhaitez partager la configuration et les paramètres des dossiers? Envoyez myproject.code-workspace,
pas besoin de s'inquiéter.
Envie de tout partager? Envoyez les deux fichiers.

il n'était pas possible de copier un fichier d'espace de travail et de l'ouvrir dans un autre
fenêtre, vous deviez d'abord changer l'id dans le fichier copié

Si vous souhaitez démarrer avec un nouvel état de l'interface utilisateur avec la même configuration de dossier et
Les paramètres dupliquent simplement votre fichier .code-workspace.

par conséquent, l'action "Enregistrer l'espace de travail sous" devrait demander au
utilisateur si la copie doit avoir un identifiant différent ou non

C'était délicat car l'utilisateur ne savait pas ce qu'était cet identifiant. Peut-être que ça
√™tre plus simple d‚Äôavoir deux options ¬ęCloner l‚Äôespace de travail avec
√Čtat "et" Nouvel espace de travail vide ". Mais c'est UX et vous devrez faire un
analyse à ce sujet.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-330396242 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAQsBQ5rdj3VGoNwy77jfSQ7V_tqWFOfks5sjxBYgaJpZM4Gm3nX
.

-
Daniel Sokolowski
Architecte technique

Groupe Stantive Technologies Inc.
Téléphone: +1 (613) 634-7410
http://www.stantive.com

Avis de confidentialité:
Les informations transmises sont destinées uniquement à la personne ou entité à
auquel il est adressé et peut contenir des informations confidentielles et / ou privilégiées
Matériel. Toute diffusion de retransmission d'avis ou toute autre utilisation de ou
prendre des mesures en se fondant sur ces informations par des personnes ou
les entités autres que le destinataire prévu est interdite. Si vous avez reçu
ceci par erreur veuillez contacter immédiatement l'expéditeur par retour électronique
transmission, puis supprimez immédiatement cette transmission, y compris tous
les pièces jointes sans copier, distribuer ou divulguer les mêmes.

@danielsokolowski Je comprends la notion de projet √©crasant un espace de travail pour les param√®tres. Dans vscode, vous avez les param√®tres g√©n√©raux, les param√®tres utilisateur (sur l'√©criture g√©n√©rale) et les param√®tres de l'espace de travail (sur l'√©criture utilisateur ou g√©n√©ral). Chaque projet a d√©j√† la possibilit√© d'avoir son propre dossier .vscode (les param√®tres de l'espace de travail y r√©sident). Proposez-vous un dossier suppl√©mentaire qui imbriquerait des projets uniquement pour partager les informations de param√®tres? Cela semblerait similaire √† un fichier / dossier ¬ę solution ¬Ľ en termes de studio visuel.

@fgallardograzio Avoir une configuration de projet mélangée avec des paramètres dans le même fichier forcera le couplage. Le contenu de l'interface utilisateur sonne beaucoup mieux en tant qu'autre fonctionnalité distincte de ce ticket de problème. Maintenant que la compilation Insiders a une belle disposition des racines supplémentaires dans le fichier, peut-être qu'une extension peut combler le vide pour la partie ui. Je vous remercie. Bonne journée.

@Yemi , oui, donc Elcipse me permet d'ouvrir différents espaces de travail qui sont
simplement des dossiers contenant divers sous-dossiers pour représenter les projets. je
utilisent personnellement deux espaces de travail, un pour développer Eclipse IDE et un pour
tous mes projets liés au travail. Le principal avantage est que les paramètres ne sont que
fichiers lisibles par l'homme stockés dans leurs dossiers de paramètres respectifs - http://wiki.eclipse.org/IRC_FAQ#Where_are_Eclipse_preferences_stored.3F -
c'est très logique pour moi.

Un commentaire / astuce √† mentionner pour tout IDE, dans les situations o√Ļ vous avez
projets autonomes, dites workspace/your-awesome-library que vous souhaitez
inclure dans le cadre d'un autre projet dire
workspace/my-wiget/libraries/your-awesome-library on peut utiliser des jonctions
ou hardlinking selon le système d'exploitation - je trouve cela plus propre que git / hg subrepos
concepts.

Le mar 19 septembre 2017 √† 10 h 33, Yemi Bedu @ P&R [email protected]
a écrit:

@danielsokolowski https://github.com/danielsokolowski Je comprends le
notion de projet écrasant un espace de travail pour les paramètres. Dans vscode vous
avoir des paramètres généraux, des paramètres utilisateur (sur l'écriture générale) et un espace de travail
paramètres (sur écriture utilisateur ou général). Chaque projet a déjà le
possibilité d'avoir son propre dossier .vscode (les paramètres de l'espace de travail y résident).
Proposez-vous un dossier supplémentaire qui imbriquerait des projets uniquement pour
partager des informations sur les paramètres? Cela ressemblerait à une " solution "
fichier / dossier en termes de studio visuel.

@fgallardograzio https://github.com/fgallardograzio Avoir un projet
la configuration mêlée aux paramètres du même fichier forcera
couplage. Le truc de l'interface utilisateur sonne beaucoup mieux en tant qu'autre fonctionnalité distincte de
ce ticket d'émission. Maintenant que la version Insiders a une belle disposition du
racines supplémentaires dans le fichier, peut-être qu'une extension peut combler le vide pour l'interface utilisateur
partie. Je vous remercie. Bonne journée.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-330558669 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAQsBajECULDuQiqUZj6SRdfwJG-Bcw0ks5sj9CfgaJpZM4Gm3nX
.

-
Daniel Sokolowski
Architecte technique

Groupe Stantive Technologies Inc.
Téléphone: +1 (613) 634-7410
http://www.stantive.com

Avis de confidentialité:
Les informations transmises sont destinées uniquement à la personne ou entité à
auquel il est adressé et peut contenir des informations confidentielles et / ou privilégiées
Matériel. Toute diffusion de retransmission d'avis ou toute autre utilisation de ou
prendre des mesures en se fondant sur ces informations par des personnes ou
les entités autres que le destinataire prévu est interdite. Si vous avez reçu
ceci par erreur veuillez contacter immédiatement l'expéditeur par retour électronique
transmission, puis supprimez immédiatement cette transmission, y compris tous
les pièces jointes sans copier, distribuer ou divulguer les mêmes.

Cette fonctionnalité n'est-elle toujours pas ajoutée?

C'est très important pour moi. Je travaille sur un projet composé de 2 référentiels distincts: le frontend web et l'API. Ce serait bien si je pouvais ouvrir ces deux dossiers dans un seul "projet".

Bien s√Ľr, je pourrais r√©soudre ce probl√®me en clonant les 2 d√©p√īts dans un seul dossier et en ouvrant ce dossier, mais cela ne fonctionne pas pour tous les cas. Surtout si vous avez plusieurs projets qui d√©pendent d'un seul r√©f√©rentiel (c'est-√†-dire partagent la m√™me API).

Cette fonctionnalité serait également utile pour ceux qui utilisent le code comme documentation.

@JamesTheHacker utilise pendant un certain temps vscode-insiders qui prend en charge plusieurs projets en même temps. Et vous pouvez suggérer des fonctionnalités en fonction de ce que vous ressentez avec la version d'initié pour l'améliorer

À la livraison, la version VSCode devrait probablement passer à 2.0. Je dis juste :)

Question rapide concernant cette fonctionnalité:

Cette fonctionnalité prend en charge l'ajout de plusieurs dossiers avec des référentiels à un espace de travail existant. Est-ce que cela prendrait également en charge une configuration mono-repo, dans laquelle je veux ouvrir plusieurs projets dans un mono-repo, mais comme ils sont dans un seul repo, ils n'ont pas leur propre repo git. Donc, du point de vue du projet, ils n'ont pas .git dossier

Vous pourriez vous demander pourquoi ne pas ouvrir le dossier mono-repo comme un seul grand dossier et y travailler simplement? Il y a deux réponses:

  1. (moins intéressant pour moi) il y a trop de projets dans le mono-repo, et je ne m'intéresse qu'à certains d'entre eux.
  2. De nombreux plugins supposent qu'un projet ne contient qu'un seul ... projet. Par exemple, un seul package npm. Ils recherchent donc des éléments dans la racine du projet. Exemples: le plugin npm pour VSCode, le plugin mocha pour vscode et de nombreuses fonctionnalités dans VSCode lui-même - par exemple, je ne peux pas spécifier un chemin dans le launch.json qui est relatif au fichier courant, c'est-à-dire "le dossier node_modules qui est l'ancêtre le plus proche du fichier courant".

Après cette explication contextuelle, ma question est simple: cette fonctionnalité prendrait-elle en charge les projets dont le dossier .git est un ancêtre de leur racine? Si tel est le cas, il serait alors possible d'utiliser cette fonctionnalité dans un mono-repo.

@borekb Ouais. Je ne sais pas comment les gens de Microsoft gèrent leurs versions, mais je pense que c'est une fonctionnalité assez massive pour un

Après cette explication contextuelle, ma question est simple: cette fonctionnalité prendrait-elle en charge les projets dont le dossier .git est un ancêtre de leur racine? Si tel est le cas, il serait alors possible d'utiliser cette fonctionnalité dans un mono-repo.

Ceci est d√©j√† pris en charge depuis assez longtemps, si vous ouvrez simplement un sous-dossier d'un d√©p√īt git.

+1

Sublime et Atom le font vous devriez le faire. Pas de meilleure raison. C'est le NOUVEAU MS, faites-le les gars, j'ai entièrement confiance en vous. :)

Bonjour,
@inestyne si vous lisez des articles précédents comme de @Jeyanthinath, vous seriez déjà conscient d'utiliser VSCode Insiders pour évaluer cette fonctionnalité. Il y a même une feuille de

Lisez simplement le fil et utilisez Insiders OMG. Je vais me désinscrire ... vous les trolls qui ne lisent pas sont impossibles. Merci @ pr-yemibedu

Sensible

√Čtant donn√© que ce fil dure 2 ans et que la fonctionnalit√© semble √™tre dans la version Insiders maintenant, existe-t-il un moyen de marquer ce fil de sorte que ce soit plus √©vident que de lire le fil entier par le haut?

Une chose qui manque est la possibilité d'ouvrir une nouvelle fenêtre avec un nouvel espace de travail à partir de la CLI.

@jearle Une nouvelle fenêtre / espace de travail doit être créé comme avant avec code-insiders <folder> , non?
code-insiders -a <folder> est nécessaire pour ajouter le dossier à la fenêtre courante.

@Jeyanthinath merci! J'ai fait la même chose que @JamesTheHacker et cela m'aidera!

@Tyriar pour obtenir la fonctionnalité que je voulais, je dois exécuter les commandes suivantes:

code .; code -a .

code . ouvre le dossier en tant qu'espace non de travail, puis le code -a . s'attache à la fenêtre précédemment ouverte en tant qu'espace de travail me permettant d'ouvrir le même dossier plus d'une fois.

Je pense personnellement que cela doit √©galement √™tre chang√©. Je travaille avec ionic et un serveur personnalis√© dans deux d√©p√īts git diff√©rents et ce n'est pas tr√®s facile. La possibilit√© d'avoir au moins deux "onglets de projet" s√©par√©s ou quelque chose serait g√©nial.

Je suis passé d'Atom à cause de son buggy et de sa lenteur.

@ dark-swordsman vous pouvez activer nativeTabs sur mac

@felixfbecker est-ce possible sous Windows?

Edit: J'ai parcouru complètement le fichier de paramètres et il n'y a pas d'option pour cela. C'est pourquoi je demande.

Edit2: De plus, il n'y a pas de ressource claire sur la façon d'activer vs insiders

Bonjour,
@ dark-swordsman vous n'activez pas VS Insiders. C'est une version de VSCode qui a des fonctionnalit√©s suppl√©mentaires qui ne sont pas finalis√©es √† stable et qui vous donne en quelque sorte un espace de noms d'√©diteur suppl√©mentaire pour travailler (vous pouvez les installer c√īte √† c√īte sans conflits de param√®tres ou d'extensions). Je vous remercie. Bonne journ√©e.

La prise en charge des espaces de travail multi-racines est désormais activée par défaut dans la version stable.

panel-red2

Veuillez consulter notre documentation pour une explication complète de toutes les fonctionnalités qui l'accompagnent. Les auteurs d'extensions doivent se référer à notre wiki qui explique les nouvelles API d'extension pour préparer votre extension aux espaces de travail multi-root. Nous sommes heureux que de nombreuses extensions aient déjà commencé à adopter la nouvelle API multi-racine, merci pour cela!

N'hésitez pas à signaler les problèmes de multi-racine lorsque vous les rencontrez, nous prévoyons toujours de faire des ajustements et de fournir des API supplémentaires pour que les extensions fonctionnent avec des espaces de travail multi-racines à l'avenir.

C'est g√©nial, mais quand sera-t-il disponible? Vous dites que c'est dans la version stable, mais j'ai la derni√®re version stable (1.17.2) et je ne peux pas la mettre √† jour. De plus, dans la documentation que vous venez de citer, il est indiqu√© qu'il est toujours dans la version d'Insider et qu'il sera bient√īt dans la version stable.

Je comprends qu'il faudra peut-être un peu de temps avant la sortie de la prochaine version, mais j'ai vu cette notification m'attendre à ce qu'elle soit disponible.

Edit: je m'excuse pour mon impatience. J'essayais juste d'ouvrir une nouvelle fen√™tre de mani√®re manuelle (appelez √† nouveau le .exe) et cela ne fonctionnait pas, mais je n'ai pas regard√© dans Fichier> Ouvrir une nouvelle fen√™tre. Cela fonctionnera pour le moment. Dans l'attente de la sortie de la prochaine version. ūüĎć

@bpasero Veuillez fermer ce problème ouvert # 35849 car la fonctionnalité attendue a été effectuée dans le cadre de cette fonction # 396.

Juste une petite question. Est-il possible, après avoir ouvert plus de dossiers, de changer le dossier que je veux compiler? Pour le moment, c'est toujours le premier en version stable.

EDIT: Cela pourrait √™tre pour le cr√©ateur de l'extension PlatformIO, mais je demande des deux c√īt√©s. Au cas o√Ļ...

@DJManas, il semble que ce soit à l'extension que vous utilisez pour décider, vous devriez donc demander à l'auteur de l'extension.

@bpasero Ok, je l'ai fait en parallèle, merci pour la réponse.

Cette page vous a été utile?
0 / 5 - 0 notes