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

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.

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.

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:

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.

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!

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.

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

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:

• Ouverture d'un parent commun
• Chef de projet Git
• Gestionnaire de projet
• Reliez les dossiers en tant que sous-répertoires du "dossier maître"

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

• groupe 1 - https://youtu.be/48Y6tB3DN1g
• groupe 2 - https://youtu.be/kHL6Rt-dLm0

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":

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:

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.

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

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.

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.

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:

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:

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.

Parce que le dossier à l'intérieur n'est pas très impressionnant.

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:

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.

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.