Vscode: Unterstützung für das Öffnen mehrerer Projektordner im selben Fenster hinzufügen

stimme zu, aber vielleicht ist es eine optimierte Lösung für den Speicher

+1

Ich bin mir nicht sicher, ob ich die Frage verstehe. Es ist ein leichtgewichtiger Code-Editor, keine IDE. Warum sollten Sie mehrere "Projekt" -Ordner öffnen müssen, die nicht hierarchisch sind (wo Sie den Arbeitspfad zu einem gemeinsamen übergeordneten Element festlegen können)?

Wenn Sie an Modulen arbeiten, die unterschiedlich auf der Festplatte gespeichert sind und in diesem Maße irgendwie miteinander interagieren, sind sie zunächst zu eng miteinander verbunden ... sind Ihre Projekte Geschwister? Wenn ja, öffnen Sie einfach den übergeordneten Ordner oder den übergeordneten / übergeordneten Ordner ... wo immer sich das Stammverzeichnis Ihrer "Lösung" befindet.

Wenn Sie eine Reihe von Modulen haben (die sich alle in ihrem eigenen Git-Repository befinden), die unabhängig voneinander sind, aber ein Repository haben, das diese Abhängigkeiten verwendet, ist es sinnvoll, diese unabhängigen Ordner öffnen und entsprechende Änderungen vornehmen zu können reflektiert werden, damit Sie es lokal testen können. Das wäre immer noch ein leichter Code-Editor, aber imho ein nützlicherer!

Das Hauptproblem beim Festlegen des Projekts als übergeordnetes Element besteht darin, dass die Git-Integration wegfällt. Es gibt jedoch auch andere gültige Anwendungsfälle, die über die gemeinsame Nutzung eines übergeordneten Projekts hinausgehen.

@stoffeastrom klingt wie ein Anwendungsfall für Submodule; Ich bin mir nicht sicher, wie Ihr Projekt auf ein anderes verweisen würde, es sei denn, Sie haben einen Aliasing mit einem Mechanismus durchgeführt, z. B. npm-Verknüpfung usw. Dieses Problem sollen hauptsächlich von Paketmanagern gelöst werden. Wenn die Module eng miteinander verbunden sind, sind sie wirklich keine isolierten Module. Sie wären nicht in der Lage, zuverlässig Änderungen vorzunehmen, um ein Projekt zu unterstützen, ohne sich Sorgen darüber zu machen, dass die Änderung später Konsequenzen für andere Verbraucher hat. Selbst bei Submodulen sind sie aus genau diesem Grund standardmäßig schreibgeschützt.

Auf jeden Fall ist das, was @Tyriar gerade erwähnt hat, einer der Gründe, warum ich vorsichtig bin, diese Art von Schnittstelle für mehrere Arbeitspfade in einer einzelnen Instanz / einem einzigen Fenster zu haben: Sie müssen Integrationen (wie Git), Erweiterungen, Refactoring, Debugging, etc, etc, etc. alles auf isolierte Weise. Zum Beispiel:

Wenn ich die Git-Integration zum Festschreiben verwende, verpflichte ich dann Projekt A oder Projekt B?
Wenn ich einen Klassennamen in TypeScript umgestalte, sollte er in Projekt A oder Projekt B oder in beiden umgestaltet werden? Was ist, wenn in beiden Projekten derselbe Klassenname mit unterschiedlichen Bedeutungen vorhanden ist? Was ist, wenn einer den anderen lose referenziert?

Dies sind nur einige Beispiele dafür, wie etwas scheinbar Einfaches sehr schnell sehr kompliziert werden kann. Ich denke, es wäre viel verwirrender und ehrlich gesagt weniger nützlich, als zwischen ein paar separaten Instanzen von VSCode Alt-Tab / Cmd + Tab zu wechseln, wobei jede ihren eigenen isolierten Arbeitspfad ohne zusätzlichen Aufwand und Randfallprobleme verwaltet.

Ich sage nicht, dass es nicht gelöst werden konnte, aber ich verstehe nicht ganz, warum das Wechseln zwischen mehreren Fenstern und / oder Instanzen ein Problem ist. Vielleicht fehlt mir etwas ...

Sublime, Atom, Webstorm - sie sind auch "leichte" Code-Editoren (außer vielleicht Webstorm) und ermöglichen das Öffnen mehrerer Stammordner von verschiedenen Orten aus. Diese Editoren sind wahrscheinlich 99% dessen, was Webentwickler verwenden.
Code kann mit ihnen mit viel besserer Typescript-Unterstützung konkurrieren (und es wird sehr beliebt sein, wenn man bedenkt, dass Angular 2 kommt), aber nur, wenn es Entwicklern das gibt, was sie jetzt als grundlegende Funktionalität verwenden.

+1

+1

Als Go-Entwickler finde ich diese Funktion in Sublime oder IntelliJ Idea äußerst nützlich. Zum Beispiel importiert mein kleines Projekt Code aus der Go-Kernbibliothek oder importiert möglicherweise eine Bibliothek eines Drittanbieters. Ich muss also in der Lage sein, schnell zu ihnen zu navigieren und diesen Code zu lesen.

+1. Multi-Git-Repo-Microservice-Lösungen sind derzeit in VS Code sehr schmerzhaft, da stattdessen eine andere Typescript-fähige IDE gefunden werden soll.

Wir brauchen definitiv eine Art "Lösung". Ich bin ein nativer Entwickler, und dies beinhaltet fast immer das Erstellen einer Reihe von Bibliotheken / DLLs und das anschließende Verweisen auf diese aus einem Host-App-Projekt.
Sobald wir mehrere Projekte haben, benötigen wir auch ein Startprojekt, wenn wir auf "Ausführen" klicken.

Ich möchte auch Unterstützung für Projekte und mehrere Git-Wurzeln. Der Code, den ich häufig verwende, befindet sich in mehreren Git-Repos und es ist anstrengend, nicht zwischen ihnen wechseln zu können, ohne meinen aktuellen Arbeitsbereich zu schließen und einen anderen zu öffnen, nur um sich umzudrehen und diesen zu schließen, um den vorherigen zu öffnen. Wenn ich den übergeordneten Ordner hinzufüge, in dem sich alle meine Repos befinden, kann ich in meinen Dateien navigieren und suchen, aber ich verliere die Git-Integration. Es ist ein echter Mist.

Die Linie zwischen "Texteditor" und "IDE" ist ziemlich verschwommen und es ist mir egal, als was VS-Code bezeichnet wird. Was mich interessiert, ist, was ein Werkzeug kann und wie schmerzlos es ist, es zu benutzen. Ich denke, das Hinzufügen von Projektunterstützung würde für Leute wie mich viel Reibung lindern.

Ich würde auch gerne sehen, dass die Git-Integration funktioniert, wenn Ihr Arbeitsbereich mehrere Repos enthält, aber ich möchte nur sicherstellen, dass Leute wie @ Loren-Johnson erkennen, dass mehrere vs-Code-Fenster gleichzeitig geöffnet sein können.

Dies ist eine Reaktion auf: "Ich kann nicht zwischen ihnen wechseln, ohne meinen aktuellen Arbeitsbereich zu schließen."

Du meinst, # 2686 ist ein Duplikat davon?

Entschuldigung, ich habe die Beschreibung falsch gelesen und diese wieder geöffnet.

+1

Gibt es Fortschritte in diesem Bereich oder zumindest eine Erklärung, ob dies jemals umgesetzt wird? Gibt es einige Entscheidungen auf niedriger Ebene im Code, die mehrere Wurzeln in einem Projekt verhindern?

Dies ist so ziemlich der einzige Grund, warum ich nicht von ST3 zu VSCode wechsle.

+1

+1

+1

+1 das wäre sehr hilfreich. Der Vorschlag, Git-Submodule zu verwenden, ist sehr unpraktisch. Würde gerne diese Funktion haben.

Ein anfänglicher leichter Ansatz wäre ähnlich wie die Erweiterung von git-project-manager . Der Ansatz könnte darin bestehen, den Kontext / das Stammverzeichnis für das zu ändern, was git als Änderungen ansieht, ohne jedoch den Kontext / das Stammverzeichnis für das zu ändern, was der Dateibrowser sieht. Diese Erweiterung funktioniert perfekt, benötigt nur eine engere Integration, um das Umschalten zu beschleunigen.

+1

+1 - Ich habe angefangen, Git-Submodule zu verwenden, aber es fühlt sich eher nach einem Hack als nach einer tatsächlichen Lösung an.

+1

+1

Ich verwende die Erweiterung git-project-manager, um zwischen Ordnern zu wechseln, würde aber gerne die Option haben, mehrere Ordner gleichzeitig zu öffnen.
+1

Ich möchte nur sagen, dass der Eigentümer der Project Manager-Erweiterung auch auf dieses Problem wartet.

In Bezug auf einige der Kommentare (oben) möchte ich nur sagen, dass wir alle unterschiedlich sind und alle unsere besonderen Möglichkeiten haben, unsere Arbeit an unseren speziellen Projekten auszuführen. Diese Tatsache macht UX wichtiger als es bereits ist.

Wir alle wussten, dass "Ordner öffnen ..." nur der erste kleine Schritt war, um unweigerlich Projektmanagement in vscode mit Dingen wie "Projekt öffnen ..." und so weiter zu haben. Genau wie alle anderen Editoren da draußen, insbesondere SublimeText (woher ich komme).

Für mich ist dieses Problem eine Verbesserung der UX des Produkts. Und wir alle wissen, dass UX König ist.

Ich bin fast der Meinung, dass solche Dinge das Gesetz sein sollten, und daher sollte das Tag "Feature Request" stattdessen "Feature Reminder" sein.

Dieses Problem sollte Vorrang vor allen anderen Problemen in vscode haben. Nicht nur, weil UX König ist, sondern weil ich momentan keine anderen Probleme mit vscode habe als dieses ... technisch.

Ursprünglich wollte ich Microsoft bitten, diese projektähnlichen Erweiterungen zu übernehmen und direkt in VSCode zu integrieren und die Benutzeroberfläche zu verbessern, beispielsweise durch Hinzufügen von "Projekte ..." zum Menü.

Vielen Dank,
+1

+1

Mein Anwendungsfall für diese Funktion wird hier beschrieben: # 9515. (Es wurde als Duplikat dieser Ausgabe geschlossen.)

Ich hoffe, dass diese Funktion passiert!

+1

@ poidl, @ mastrauckas , @mdedgjonaj , @alanleite , @Xcorpio , @mibanez , @josebalius & @brusbilis :
Vor einiger Zeit stellte GitHub die schöne Funktion "Add your react" vor (siehe den Smiley in jeder oberen rechten Ecke eines Kommentars oder das Problem selbst?).
Diese dienen dazu, das VSCode-Team über Ihr Interesse zu informieren, verhindern jedoch bedeutungslose +1 -Kommentare. Es verhindert auch, dass andere Personen, die ein bestimmtes Problem oder MR abonniert haben, eine Benachrichtigung erhalten, und spart somit wertvolle Zeit. Ein weiterer Bonus ist, dass Probleme / MRs nach most reaction sortiert werden können, wodurch für das VSCode-Team sofort sichtbar wird, was für die Benutzer relevant ist. Darüber hinaus gibt es sogar ein Uservoice für VSCode .

Dieser Kommentar selbst ist meta und daher auch bedeutungslos. Es tut mir leid, aber ich dachte, es sei für Bildungszwecke notwendig. Jede direkte Antwort auf diesen Kommentar (= mehr Meta) führt dazu, dass ich den Benutzer blockiere.
Lassen Sie uns trainieren, indem wir auf diesen Kommentar nur mit der Funktion reaction reagieren!

Zu @poidls Antwort: Dann antworte überhaupt nicht!

Ich sehe diesen Smiley nicht. Zumindest auf dem Handy. Viel Spaß beim Blockieren!

@poidl Ja, die Reaktionsfunktion ist auf der mobilen GitHub-Website leider nicht verfügbar (zusammen mit vielen anderen Funktionen). Sie können auf Mobilgeräten darauf zugreifen, indem Sie unten auf der Website auf die Schaltfläche "Desktop-Version" klicken.

@ dj-hedgehogs Rat ist jedoch genau richtig. GitHub-Reaktionen ermöglichen es uns, das Interesse der Community an etwas effektiverem als der Anzahl der Kommentare zu messen. Darüber hinaus planen wir, User Voice zu verwerfen, damit GitHub-Probleme und -Reaktionen unsere Wahrheitsquelle für Feature-Anfragen sind.

+1

+1

Meine Lösung für dieses Problem: Erstellen Sie einen symbolischen Link zu meinem Projektstamm.
Also wenn ich habe:
project/modules/gitmodule

Ich gehe in meinen Gitmodule-Ordner und mache:
ln -s ../../../project .project

Jetzt kann ich meinen gitmodule-Ordner in vscode öffnen und habe weiterhin Zugriff auf den übergeordneten Projektordner.
Ich verwende einen Punkt im Dateinamen, damit er im Explorer ganz oben auf meiner Liste steht.
Natürlich würde ich das lieber nicht tun müssen, aber ich dachte, es könnte für einige von Ihnen nützlich sein.

Fast vergessen: Vergessen Sie nicht, den symbolischen Link zu Ihrem .gitignore hinzuzufügen

+1

Dies ist eine wirklich wichtige Funktion für einen modernen Texteditor. Bitte lösen Sie dieses "Problem" bitte.
Für eine Weile musste ich alle Verzeichnisse kopieren und einfügen, die in meinem eigentlichen Arbeitsordner verwendet werden, und dies in Sublime Text ist so trivial.

Projekt> Ordner zum Projekt bei Sublime Text hinzufügen erhöht einen neuen Pfad zur Json-Struktur.

Schauen Sie unten:
{ "folders": [ { "path": "~/cpp" }, { "path": "~/python" } ] }

Wenn Sie beispielsweise mit einem Koch arbeiten, sehen Sie häufig eine Ordnerstruktur wie:

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

Wobei die Kochbücher (z. B. Kochbuch1) unter dem Stammordner (Kochbücher) die unabhängigen Git-Repos sind. Das ist sehr häufig. Jetzt müssen Sie an Kochbuch4 arbeiten, aber es enthält Kochbuch2 und Kochbuch3. Sie müssen häufig alle 3 öffnen, entweder um einfach auf Code zu verweisen oder um Code in allen 3 tatsächlich zu bearbeiten oder umzugestalten.

Die 2 normalen Optionen (keine Symlink-Hacks) stellen Probleme dar, die kein Entwickler wünscht:

1. Wie oben oft erwähnt, müssten Sie jetzt mehrere Fenster öffnen (nicht gut)
2. Wenn Sie Kochbücher als root öffnen, um alle 3 zu sehen, verlieren Sie die Git-Integration, da der Kochbuchordner kein Got-Repo ist (auch nicht gut).

+1, Eclipse IDE-Benutzer hier mit vollständiger Steuerung des Arbeitsbereichs.

Visual Studio Code ist keine IDE. Es ist ein leichter plattformübergreifender Editor wie Atom oder Sublime. Eclipse, Xcode, Visual Studio et. Alle sind im Vergleich Giganten.

Entschuldigung, ich bin mir nicht sicher, ob Sie gegen oder für diese Funktion argumentieren ... Mit Atom, Sublime, VIM und Emacs können Sie mehrere Ordner in einer Instanz öffnen. Leicht oder nicht, es ist eine gute Funktion. Mit IntelliJ IDEA - einer IDE - können Sie beispielsweise noch nicht mehrere Projekte öffnen.

@dmccaffery Die hier angeforderten Funktionen sind allen _editors_ gemeinsam, von denen Sie sagten, dass Visual Studio Code _like_ ist.

Atom, Sublime und andere leichtgewichtige Editoren können mehrere Ordner öffnen.

Es ist mir persönlich egal, ob diese Funktion im Produkt landet oder nicht - ich verstehe, warum manche Leute sie wollen, aber ich möchte darauf hinweisen, dass dadurch alles etwas komplizierter wird. Zum Beispiel: Wenn ich mit einem regulären Ausdruck suche - welchen Arbeitsbereich suche ich? einer? alle?

Was ist, wenn ich einen Ordner mit einem NodeJS-Projekt habe, in dem meine Tabulatorbreite normalerweise 2 Leerzeichen beträgt, und einen Ordner ein Dotnet-Projekt, in dem meine Tabulatorbreite 4 Leerzeichen beträgt? Der Code muss die Arbeitsbereichseinstellungen für jeden Ordner kennen und den gesamten Kontext beibehalten.

Dies sind nur einige Beispiele dafür, wo mehrere Arbeitsbereiche innerhalb einer einzelnen Instanz schwierig sein können. Ich sage nur, dass diese Funktion weitaus umfangreicher ist, als nur mehrere Pfade im Explorer anzuzeigen.

@dmccaffery nicht

Hier ist eine Tatsache, ob es Ihnen gefällt oder nicht, und es hat nichts mit dem zu tun, was Sie oder ich wollen. Wenn andere ähnliche Software zu ähnlichen Preisen (in diesem Fall kostenlos) bessere oder mehr Funktionen haben und der Entwickler diese Tatsache vernachlässigt, wird diese Software zurückgelassen.

Ich jedenfalls würde nicht wollen, dass dies diesem Editor passiert. Ich denke, dieser Editor hat ein sehr gutes Potenzial und kann für einige Zeit relevant bleiben, wenn die Entwickler auf die Wünsche / Bedürfnisse seiner Benutzerbasis hören.

Nochmal; Ich argumentiere nicht dafür oder dagegen - denken Sie nur daran, dass dies ein sehr neuer Editor ist, der weitaus mehr Out-of-the-Box-Kontext als seine Konkurrenten hat - geben Sie ihm etwas Zeit.

Selbst in Ihrem Beispiel mit der Integration von Chefkoch und Git - wie pflegen Sie den Kontext, zu welchem ​​Repo Sie sich verpflichten? Die aktuelle Benutzeroberfläche müsste sich an die ständige Kontextumschaltung anpassen - dasselbe gilt für OmniSharp, das einen Server und Roslyn verwendet, um Syntaxhervorhebungen usw. für CoreCLR-Projekte bereitzustellen. Die Auswirkungen sind weitreichend und müssen sehr gut durchdacht werden.

Kein Argument für die Idee, dass Features gut geplant und durchdacht sein müssen. Das ist eine Selbstverständlichkeit, würde ich denken. Ich denke, alle Benutzer würden sich freuen, wenn die Antwort hier "Es steht auf der Roadmap" oder "Wir arbeiten auf dieses Ziel hin" lautet. Ich sage nur, dass ein "Nein" wahrscheinlich einige Benutzer über Nacht töten würde.

In Bezug auf Kontextwechsel und Git-Repos in Chefkoch stimmte ich zu ... das ist alles wahr und alles bereits in anderen Open-Source-Editoren erreicht. Sie kennen das Tolle an Open Source, es ist offen! Schauen Sie sich den Code an, holen Sie sich Ideen, verwenden Sie sogar einen Teil davon (stellen Sie sicher, dass Sie die Lizenzierung nach Bedarf einschließen). Das ist eines der großartigen Dinge in Bezug auf Foss (kostenlose Open Source-Software), Zusammenarbeit und Wissensaustausch. Da dieser Editor bereits Atomcode verwendet ... würde ich denken, dass dies auch eine Selbstverständlichkeit ist.

Ich fand dies in https://github.com/Microsoft/vscode/wiki/Roadmap erwähnt

VS Code ist ein junges Produkt und es fehlen noch Funktionen und Erfahrungen, nach denen Sie fragen und die wir liefern möchten.
....
....

• Mehrere Ordner in einem Arbeitsbereich

Ich denke, niemand sagt, dass diese Funktion einfach ist (da wir alle Entwickler sind, können wir erkennen, was geändert werden muss), und ich als Gast kommentiere dieses Ticket nur, um zu zeigen, wie wichtig es ist, wie wichtig es sein sollte. und wie man diese Funktion mit einigen VS Code-Brüdern vergleicht (Atom, Sublime zum Beispiel).

Aber da dies bereits in der Roadmap enthalten ist (jeder kann bestätigen, dass die Wiki-Seite immer noch korrekt ist), sollten wir darüber diskutieren, wie dies implementiert werden kann, anstatt nur zu sagen, wie wir es brauchen und wie wichtig es ist (wie ich wieder denke, das VS Code-Kernteam bereits wissen, wie wir es brauchen und wie wichtig diese Funktion ist).

Ich bin mit VS Code-Quellcode nicht vertraut. Kann mir jemand sagen, ob ich diese Funktion implementieren möchte. Wo soll ich zuerst suchen? Im ersten Schritt möchte ich nur mehrere Ordner öffnen und in der linken Leiste anzeigen.

@nvcnvn Es ist nicht so trivial, wie es aussehen mag, um dies zu implementieren, da viele vscode davon ausgehen, dass nur ein einziger Ordner geöffnet werden kann. Als solches muss es UX durchlaufen und wahrscheinlich viele Teile der Codebasis berühren, was möglicherweise auch Auswirkungen auf die Erweiterungs-API hat.

Ich erinnere mich, als Atom herauskam, mit der gleichen Einschränkung für einen einzelnen Ordner. Die Beschwerden waren auch die gleichen, insbesondere die Vergleiche mit Sublime. Als dann die Unterstützung für mehrere Ordner freigegeben wurde, waren einige Pakete (Erweiterungen) aufgrund der neuen API fehlerhaft. Andere haben nicht gebrochen, aber auch nicht unterstützt. Es dauerte einige Zeit, bis es im gesamten Ökosystem stabil wurde.

Wie @Tyriar sagte, wird es einige Auswirkungen auf die

Was genau wird hier argumentiert?
Ich meine, alles was ich sehe ist "keine Verbesserungen vornehmen, weil es Dinge kaputt machen könnte" ...

Hinweis:
ALLE VERBESSERUNGEN IM CODE KÖNNEN ETWAS BRECHEN!

Das ist der Punkt des Debuggens, Refactorings, Pre-Releases (Alpha, Beta, RC, etc ...)
Komm schon, ernst? Ich habe noch nie einen ernsthaften Programmierer getroffen, der Angst hatte, Code zu verbessern, weil er etwas kaputt machen könnte. Sei vorsichtig, ja, nimm dir Zeit und sei sicher, ja, aber sag niemals "Nein, es könnte Dinge kaputt machen" lol

@ddreggors Ich gebe nur einige Informationen zu dem Problem an. Ich sagte, was ich sagte, damit @nvcnvn nicht versucht, eine PR dafür zu erstellen, da dies aufgrund der Liste der Stakeholder vom Team durchgeführt werden muss.

Wie @nvcnvn hervorhob , steht dieses Problem auf der Roadmap, was bedeutet, dass das Team es bald prüfen wird. Wir sind ein relativ kleines Team, das viel zu besprechen hat, sodass einige Dinge verzögert werden müssen.

@ Tyriar Verstanden, ich sehe immer wieder diese Kommentare von mehreren Leuten, die anscheinend darauf

Ich kann die Sorge verstehen, dass diese PR nicht vollständig ist, aber es könnte ein guter Anfang sein ... diese Änderung in einem Zweig zusammenführen und als Basis verwenden. Verwenden Sie dies, um Brüche zu erkennen und zu beheben.

@ddreggors Es wäre eine UX-Meetings besprochen wurde

Fair genug, Sie würden es am besten wissen. Es ist schön zu wissen, dass dies diskutiert wird. :-)

Vielen Dank für Ihre Bemühungen und den Start eines sehr guten Editors.

Es scheint auch eine vergebliche Anstrengung zu sein, dieses Thema für Ihre UX-Meetings vorzuschlagen :–)

Ich habe vorübergehend wieder auf Atom umgestellt, da es in Version 1.9 viel stabiler geworden ist. Es stürzte früher ab, wenn eine große Datei geöffnet wurde, und das war der Hauptgrund, warum VSCode irgendwann ausgecheckt wurde. Ich freue mich wirklich darauf, mehrere Projekte in einem Fenster zu sehen - anscheinend habe ich nichts zu tun, als diesem Thread bis dahin zu folgen.

Warum konzentrieren sich Microsoft-Leute nicht darauf?

+1

+1

Ich liebe VS Code wirklich. Es ist mein Hauptredakteur geworden, aber die Schwierigkeit, in mehr als zwei Projekten gleichzeitig zu arbeiten, wird verwirrend. Bei diesen beiden offenen Fragen gibt es einen Doppelschlag: diesen und die Konfiguration der Titelleisteninformationen .

Eine dieser Funktionen würde das Problem lösen (obwohl ich im Idealfall beide möchte!). Es macht mir nichts aus, alles, mit dem ich arbeite, unter einem einzigen Ordner abzulegen und zu öffnen - aber dann funktioniert die Git-Integration nicht und es gibt keine einfache Möglichkeit, nur innerhalb eines Projekts zu suchen oder Ergebnisse nach Projekt zu organisieren.

Es macht mir nichts aus, jedes Projekt in einem anderen physischen VS-Code-Fenster zu öffnen und mein Betriebssystem die Instanzen verwalten zu lassen. Da in der Titelleiste jedoch zuerst der Name der geöffneten Datei und nicht eine Stammordner- / Projektkennung angezeigt wird, ist ein Wechsel nicht möglich ein anderes spezifisches offenes Projekt, ohne jede aktive Instanz zu öffnen und zu betrachten. Es macht etwas, das mühelos sein sollte, zu einem ständigen Ärger.

Bitte - gibt es eine Möglichkeit, dass das Hinzufügen einer dieser beiden Funktionen zur Priorität wird? Ich habe alles versucht, was ich mir vorstellen kann, um das Problem zu umgehen. Ich habe sogar eine Stunde lang nach einer Windows-Taskleistenalternative gesucht, mit der ich Fenster aus einer Liste auswählen kann, in der möglicherweise mehr Text in der Titelleiste angezeigt wird, die ich jedoch nicht finde etwas.

Wenn jemand Vorschläge hat, wie mehrere offene VS Code-Projekte effektiv verwaltet werden können, würde ich sie gerne hören.

Wichtig in Atom ist, dass Plugins wie eslint weiterhin auf Projektebene funktionieren sollten. Wenn also Projekt A seine eigenen Eslint-Regeln hat, sollte Projekt B von diesen Regeln nicht betroffen sein und umgekehrt. Ich kann es kaum erwarten, eine solche UX im Code zu haben. Dies ist definitiv eine der derzeit größten Adoptionshürden.

Dies ist das einzige, was mich dazu bringt, es zu übernehmen.

Ich weiß, dass Sie möglicherweise viele andere Probleme beheben und andere Funktionen implementieren müssen, aber zumindest eine grundlegende Unterstützung für den Einstieg wäre fantastisch.

Vielen Dank für die harte Arbeit an VSCode!

+1

Bis diese Funktion implementiert ist (falls jemals), kann ich vorschlagen, dass Sie einfach die Möglichkeit hinzufügen, die Titelleiste so zu konfigurieren, dass der Projektname vor dem Dateinamen angezeigt wird. Auf diese Weise kann zumindest zwischen den verschiedenen vscode-Fenstern unterschieden werden, die für die verschiedenen Projekte geöffnet sind. Siehe # 1723 .

Dies ist auch für mich ein Show Stopper. Ich sehe, einige Entwickler fragen sich, warum Sie mehrere Git-Repos gleichzeitig haben. Dies geschieht mit fast jeder Sprache, die Module des dritten Teils verwendet. Schauen Sie sich einfach PHP - Composer, JS - Bower, Node - Npm, Golang usw. an. Es ist sehr üblich, ein Projekt zu starten, das einige Ihrer Module verwendet, und Sie möchten die Änderungen im Umfang des Projekts bearbeiten und festschreiben.

Gibt es zumindest Unterstützung für das Erkennen von .vscode/settings.json in verschachtelten Verzeichnissen? Wenn Sie an einem einzelnen Projekt arbeiten, gibt es möglicherweise Teilbäume mit unterschiedlichen Einstellungen, die aus unterschiedlichen (Git-) Repositorys stammen. z.B

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/

Ich würde erwarten, dass vscode die Einstellungen des nächstgelegenen übergeordneten Verzeichnisses wie viele Konfigurationsdateien übernimmt (und möglicherweise zusammenführt) ( .eslint , .gitignore , .editorconfig , tsconfig.json , 'package.json` ....).

Wenn ich also /root öffne, sollte jede Datei in root/server/ so behandelt werden, als würde ich root/server/ direkt öffnen. Die einfachste Lösung wäre, die Suche nach Einstellungen in übergeordneten Verzeichnissen zu beenden, sobald eine .vscode/settings.json -Datei gefunden wird.

Das ist wirklich nötig.

+1. Dealbreaker für mich.

Das ist wirklich nötig. +1

Es gibt eine Problemumgehung, um Ordner unter einem vscode-Arbeitsbereich zu verschachteln. Nur um einen Symbollink zum Ordner des Arbeitsbereichs zu erstellen, wie folgt: mklink /d link target

Ich stimme zu - ich denke, diese Anfrage ist eine definitive Anforderung.
Sie haben nicht immer ein Projekt in einem einzigen Ordner - Sie können Neben- und Geschwisterordner haben, und diese Funktion nicht zu haben, ist für mich gerade jetzt ein echter Deal Breaker - deshalb muss ich sublime verwenden.
Bitte füge es hinzu!

Auf der linken Seite zeigen Sie den Ordner, in dem Sie sich als Projekt befinden. Dies könnte funktionieren, wenn Sie es dort hätten, wo Sie jeden Ordnerbereich (Projekt) sehen können, der dort geöffnet ist. Sie können es wie jetzt erweitern und reduzieren (jedoch für mehrere Ordnerbereiche).

Ein großartiger Editor, wenn ich nur zwischen zwei Projekten wechseln könnte. Ein echter Dealbreaker.

Hallo zusammen, ich empfehle die Git Project Manager- Erweiterung, wenn Sie in der Zwischenzeit viel zwischen Projekten wechseln. Es durchsucht ein Verzeichnis nach Verzeichnissen, die einen .git -Ordner enthalten, und ermöglicht einen schnellen Wechsel zu diesen. Ich benutze es seit einigen Wochen und es macht es auf jeden Fall einfacher.

Wenn ich Projekte wechsle, gehe ich entweder:

1. Strg + Alt + P.
2. Geben Sie den Projektstart ein, z. "vsc" für vscode
3. eingeben

Oder wenn ich das Projekt in einem anderen Fenster öffnen möchte, drücke ich vorher Umschalt + n . Sie können die Erweiterung so konfigurieren, dass sie immer in einem neuen Fenster geöffnet wird, wenn dies auch Ihre Sache ist.

Dies ist ein Screenshot davon, wie Sie problemlos mehrere Projekte erstellen können.

@ soljohnston777 Das Problem ist, dass die Git-Integration (oder eine andere Art von VS-Code-Konfiguration) auf

Das Problem ist, dass die Git-Integration (oder eine andere Art von VS-Code-Konfiguration) auf Ordnerebene nicht unterstützt wird.

Huh wirklich? Hat VSCode die Fehler wiederholt, die Eclipse beim Arbeitsbereichskonzept gemacht hat? Das wäre überraschend, wenn man wüsste, dass einige Mitglieder des VSCode-Teams Teil des Eclipse-Kernteams waren.

Hat VSCode die Fehler wiederholt, die Eclipse beim Arbeitsbereichskonzept gemacht hat?

Ich kann hier nicht mit der Philosophie der Architekten sprechen, aber diese Tatsache (diese Konfiguration ist pro Instanz und nicht pro Ordner) ist der ganze Grund für dieses Problem und diese Diskussion.

Sie können separate VScode-Fenster für Projekte verwenden. Warum implementieren Sie es nicht so in VSCode? (Separates Fenster pro Seite Projektschaltfläche - verweisen Sie einfach darauf). Es würde den Aufwand ersparen, es innerhalb des Programms zu codieren, aber die Projekte werden darin gezeigt, und es würde einfach zu integrieren und zu entwickeln sein.

Git kann für jeden Ordnerbereich für mehrere Projekte unabhängig platziert werden ... Ich finde, dass das Git mit VSCode verwechselt wird, daher neige ich dazu, sowieso nur die Befehlszeile zu verwenden (was anscheinend in VSCode möglich sein sollte).

Ein übergeordneter Ordner mit Unterordnern, die unabhängige Git-Repositorys sind, ist sehr hilfreich, wenn sie alle zum selben Projekt gehören. Möchte dies verfügbar sehen, zumindest mit einem optionalen Konfigurationsflag in den Einstellungen.

Ich möchte auch mein starkes Interesse an der Unterstützung von Git für mehrere Git-Repos zum Ausdruck bringen.

+1. Dies ist eine Hauptfunktion, die verhindert, dass ich VSCode als Haupteditor verwende.

+1

+1 - Dies ist der Schlüssel, insbesondere für Personen, die mit Microservice- / Many-Repo-Codebasen arbeiten. (Schlüssel: Nicht alle auf einmal öffnen, sondern zwischen ihnen wechseln und den Editor merken, welche Dateien in welchen Arbeitsbereichen geöffnet waren.)

+1
Unser Setup ist so etwas wie Kerncode in GIT-Repo, regionaler Code in einem anderen Repo und projektspezifischer Code in einem anderen Repo. Wenn Sie also an einem Projekt arbeiten, müssen Sie aus allen drei (oder mehr) Repos codieren. Nicht in der Lage zu sein, ein "Projekt" mit seinen eigenen spezifischen Einstellungen zu haben und die Möglichkeit, mehrere Ordner aus mehreren Quellen hinzuzufügen, ist der König eines Blockers.

@danechitoaie Woher wissen Sie, dass eine Änderung, die Sie an Ihrem Kern-Repo vornehmen, niemanden kaputt macht, der sich für eine andere Region oder Projektcodebasis darauf verlässt? Scheint eine gefährliche Art zu arbeiten; Es sollte eine separate Versionsverwaltung unter Verwendung eines Paketverwaltungssystems oder dergleichen geben.

Nicht gegen eine Implementierung von Arbeitsbereichen zu argumentieren, aber ein vollwertiges Projektsystem erhöht die Komplexität erheblich.

Stimmen Sie zu, es ist und sie sollten / könnten viel viel besser machen, aber ... es liegt außerhalb unserer Kontrolle über "sterbliche Benutzer" oder der Fähigkeit, Entscheidungen zu treffen ...

Verstanden. Ich liebe es, wenn so etwas passiert.

Wie wäre es damit?

Für mich reicht ein einfacher Schaltknopf einfach nicht aus. Wenn wir nur so einfache, offene 2 Instanzen benötigen (Strg-Umschalttaste N), verwenden Sie Ihren Betriebssystem-Hotkey, um zwischen Fenstern / Arbeitsbereichen zu wechseln.
Ich mag es, etwas zu haben, das das Vergleichen von Dateien, die Projektstruktur und etwas erleichtert, das mir hilft, schnell kleinere Änderungen vorzunehmen und alle Unterschiede auf demselben Bildschirm zu erstellen und beizubehalten, um die Änderungen für alle Projekte, mit denen ich arbeite, rückgängig zu machen.

+1

+1

Art der Problemumgehung für macOS Sierra.

Eine Registerkarte pro Projekt in einem Fenster, indem Sie in den Dock-Einstellungen Prefer tabs when opening documents auf Always . Aber es wird auch das Verhalten anderer Apps beeinflussen.

+1

Das wird für mich zum Killer. Ich liebe das Programm, aber Mann, ich mag es nicht, wenn man nur ein Fenster hat ...

Ehrlich gesagt musste ich aufhören, Code zu verwenden, weil es, so sehr ich es mag, zu umständlich wurde, Fenster zu wechseln.

Wenn dies in Zukunft behoben wird, werde ich es erneut versuchen. Bis dahin ist dies ein Show-Stopper für mich und jede Person, die ich getestet habe.

+1

+1

Bitte bevorzugen Sie: +1: Reaktionen auf den ursprünglichen Problemkommentar, da dies uns bei der Priorisierung hilft und keine Benachrichtigungen an alle sendet, die das Problem zur Aktualisierung anhören.

+1

Ich verwende derzeit Sublime und probiere Code aus. Es sieht gut aus und fühlt sich gut an, aber die Git-Integration eines einzelnen Projekts ist ein Deal Breaker. Ich habe ein Hadoop / Oozie-Projekt und daher ein Repo mit Code und ein weiteres mit Arbeitsnotizen. In Sublime habe ich beide im selben Fenster geöffnet und kann für jedes das entsprechende Git-Repo festlegen

es wird also gut sein, hinzuzufügen

+1 Ja, kritisch in der Microservice-Welt ist es üblich, dass 3..4 Repos gleichzeitig geöffnet sind

Wöchentliche Erinnerung: Veröffentlichen Sie keine Kommentare mehr mit +1. Geben Sie stattdessen einen Daumen hoch bis zur ersten Ausgabe, die tatsächlich gezählt wird.

Ich weiß, dass Sie alle gut gemeint haben. Sie können also Ihren + 1-Kommentar löschen, damit er auch in diesem wichtigen historischen Datensatz keinen Platz beansprucht!

@ Jamietre Ich habe versucht ... hart:

Vielleicht besteht eine andere Alternative darin, dieses Problem zu beheben, aber offen zu bleiben, bis es behoben ist? Auf diese Weise wissen wir, wie wichtig das Problem ist (ich würde sagen, wir haben bereits genug +1 dafür), können aber die Unordnung / Redundanz nicht erhöhen (z. B. kein Kommentieren mehr zulässig).

Obwohl dies meiner Meinung nach eine selten verwendete Funktion ist, bin ich nur auf die Sperrung eines öffentlichen Projekts / Repos auf Github gestoßen.

Die Sperre kann bei Bedarf entsperrt werden, wenn dies als notwendig erachtet wird.

@daluu so funktioniert das / aspnet / ansage repo; Jedes Problem wird sofort gesperrt. Abgesehen davon sollte GitHub etwas in der Benutzeroberfläche tun, um die Leute zumindest zu Alternativen zu bewegen, die über "+1" hinausgehen, da jetzt Reaktionen bestehen. 👍

Es ist sehr hilfreich, die Multi-Fenster-Funktion insgesamt zu betrachten, wenn Sie die Dokumente von mehr als zwei Projekten betrachten.

interessante Herangehensweise an das Problem. Ich war viele Jahre ein VB / .net-Programmierer, liebte die Sprachen und Werkzeuge, war aber einige Jahre in Hadoop / Spark / Scala / Intellij / Sublime-Land unterwegs. Ich höre immer noch DotNetRocks, möchte auf dem Laufenden bleiben und war interessiert, von dieser Code-App zu hören. Positiv zu vermerken ist, dass es sich um einen sehr netten Editor mit einigen gut aussehenden Git-Funktionen handelt, aber das ist leider völlig irrelevant. Da Git nicht für mehrere Projekte im selben Arbeitsbereich verarbeitet wird, wie es Sublime sehr elegant tut, kann ich es einfach nicht verwenden

Das passiert. Was mich am meisten überrascht, ist die Reaktion hier, zuerst zu behaupten, dass dies kein notwendiges Feature ist, und dann scheint der größte Teil der Diskussion jetzt um "Wie können wir verhindern, dass Leute +1 posten?"

Ich werde Ihnen sagen, wie Sie das tun - Sie beheben ein grundlegendes Problem, das vor einem ganzen Jahr zum ersten Mal angesprochen wurde! Es heißt "Feedback hören". Nur weil Sie nicht persönlich von einem Problem betroffen sind, heißt das nicht, dass es nicht existiert. Wenn Sie nicht möchten, dass eine bestimmte Gruppe von Benutzern die App verwendet, dann ist das in Ordnung, aber geben Sie uns keinen Feedback-Mechanismus. Dann bestreiten Sie unser Problem und ärgern Sie sich darüber, dass wir immer wieder danach gefragt haben.

Ich benutze wieder Sublime

Das Problem "+ 1" kann mit dem folgenden Code behoben werden: if (post_message == "+1") {add_smiley_reaction (); delete_post_message (); }}

Lieber GitHub, ich kann gemietet werden.

Ja, das wird niemals behoben, oder? Es ist weitaus einfacher, "+1" -Kommentare zu verspotten und zu ignorieren, als das Kernproblem tatsächlich anzugehen. Software wird an einen bestimmten Teil der Entwickler vermarktet, der nicht das tut, was er braucht, um produktiv zu sein ...

Lesen Sie einfach diesen Artikel. "Jede direkte Antwort auf diesen Kommentar (= mehr Meta) führt dazu, dass ich den Benutzer blockiere." - So verwalten Sie Feedback! Stecke deine Finger in deine Ohren und sage "Ich kann dich nicht hören!"

lieber Herr

@ kryps1 dann fügen die Leute "+ 1" oder "++ 1" oder "1+" oder "Stoß" oder "Ja, bitte. +1" hinzu. Was auch immer Sie tun würden, die Leute werden einen Weg finden, das zu umgehen. Ist nicht so einfach wie du denkst.

Stoppen Sie mit der nutzlosen Debatte über +1 bitte ... Konzentrieren Sie sich auf das, was hier benötigt wird, nämlich mehrere Projekte im Explorer.

Für das git -Problem muss es nur so aufgeteilt werden, wie es der Explorer ist (dh per cwd).

Beginnen wir keinen Flammenkrieg um das +1 Zeug. Es wäre auf jeden Fall schön, wenn diesem Thema Vorrang eingeräumt würde.

Aber ich möchte der Community mitteilen, dass PRs und Beiträge willkommen sind ;-) Jemand kann den Code patchen / reparieren, wenn die Kernentwickler nicht dazu kommen. Ich habe einige meiner Projekte verbessern lassen (mit Gabeln), weil der Benutzer / Entwickler es lieber selbst macht, als auf mich zu warten, um Verbesserungen vorzunehmen, die er mir vorschlagen möchte. Also, wer sich über dieses Problem geärgert hat und fähig / geschickt genug ist, bitte beheben (dann eine PR einreichen)? lol

Und zurück zum Thema +1: Es ist gut, das Problem zu lösen und Ihre Meinung hinzuzufügen, aber die +1 ist eine lahme Methode, wenn andere Methoden wie die Daumen hoch-Funktion verfügbar sind. Betrachten Sie einen Facebook-Beitrag oder den ursprünglichen Google+ Beitrag, und Benutzer / Leser fügen einen + 1-Kommentar hinzu, anstatt auf "Gefällt mir" (oder eine der neuen Reaktionen von Facebook) oder +1 für Google+ zu klicken. Mit der Zeit ist das ein langer Kommentarthread von lahmen + 1s, in dem ich als Leser möglicherweise scrolle, um interessante Kommentare anzuzeigen, aber am Ende sehe ich eine Reihe von + 1s. Dies ist, was hier geschah. Ich würde es vorziehen, diese +1 nicht zu sehen / durchzulesen, egal ob ich ein Projektentwickler oder nur ein Benutzer bin (oder dieses Projekt auf mögliche Verwendung recherchiere).

In einem ähnlichen Zusammenhang ist hier eine dumme (aber gute Absicht) Verwendung eines GH-Problems, Gott sei Dank, die Leute haben jedoch nicht alle +1 darauf gesetzt: https://github.com/sinatra/sinatra/issues/920

Ich gehe davon aus, dass PRs und Beiträge willkommen sind

Nicht wirklich. Siehe diesen Kommentar vom August: https://github.com/Microsoft/vscode/issues/396#issuecomment -241806158

Anscheinend ist dieses Problem zumindest seitdem in der Roadmap enthalten , aber es wurden keine Fortschritte erzielt. Es wäre schön, eine Statusaktualisierung vom VSCode-Team zu hören.

Für mich, und dies versucht, das Thema wieder in Gang zu bringen, werden mehrere Projektordner benötigt.

In Atom unterstützt es GIT, und ich verwende es nur, um festzustellen, welche Dateien Änderungen aufweisen. Ich habe einen Rackspace-Server, der SSH nicht zulässt, also gehe ich zum manuellen Hochladen. Ich kann jedoch mehrere Projektordner in der Seitenleiste haben, und es macht es so viel einfacher, auf Code zu verweisen, den ich in einem früheren Projekt verwendet habe. Oder schalten Sie auf ein anderes Projekt um, wenn ich eine Verschnaufpause brauche.

Bei VSCode ist das Problem, das mich am Wechseln hindert, und der Mann, den ich wechseln möchte, das Fehlen mehrerer Projektordner in der Seitenleiste.

Ich denke, ich könnte einfach den Stammordner öffnen, um ihn vorübergehend aufzulösen, aber wenn ich nur 3/20 Ordner benötige und die losen Dateien nicht sehen möchte, sollte dies eine einfache Implementierung sein, oder?

Update: Das große Workbench-Update, das in Kürze verfügbar sein wird, ist Hot Exit (Nr. 101). Während wir an Hot Exit arbeiten, haben wir dieses Problem aktiv diskutiert, um sicherzustellen, dass das Design mehrere Ordner berücksichtigt.

Dieses Problem ist derzeit die Nummer 2 in Bezug auf: +1: Reaktionen aller Probleme (Nummer 1 bei weitem als Workbench gekennzeichnet). Daher ist dies sehr wahrscheinlich die nächste große Arbeit für die Workbench nach dem Hot-Exit.

Ein: +1: Kommentare; Sie dienen nur dazu, die über 80 Abonnenten des Problems zu ärgern. Die Abstimmung über das Thema mit einer Reaktion ist jedoch eines der mächtigsten Dinge, die Sie tun können, um das Projekt zu beeinflussen.

Denken Sie auch daran, dass wir ein relativ kleines Team sind und dass die Sauberkeit der Codebasis und die Leistung von vscode sehr wichtig sind. Daher brauchen die Dinge Zeit, um richtig zu arbeiten. Insbesondere für so etwas, das eine grundlegende Änderung der bisherigen Erstellung von vscode darstellt, gibt es in dieser Ausgabe einiges an Arbeit.

+1

In der Tat wäre das eine praktische Funktion.

Ich habe von Atom gewechselt und es hat mir sehr gut gefallen, aber ich arbeite an zwei UI-Anwendungen und zwei weiteren SDKs, aber die Unfähigkeit, schnell zwischen diesen Projekten (oder Ordnern) zu wechseln, ist ein wichtiger Mangel. Ich denke, ich sollte bis dahin zu Atom zurückkehren wurde gelöst

Ich freue mich sehr auf dieses Feature ~~~

Ich bin ein Golang-Entwickler, der vscode verwendet. Ich hoffe, dies hat ein Gerät, danke!

Ich versuche von Sublime zu VScode zu wechseln. Und bald stellte ich fest, dass VScode, der nicht mehrere Ordner in einem "Projekt" -Konzept unterstützt, wirklich ein Problem darstellt, das mich daran hindert, dies zu tun.

Ich liebe die anderen Funktionen dieses "leichten" Editors wirklich. In der Zwischenzeit glaube ich, dass die Unterstützung mehrerer Ordner in einem "Projekt" VScode nicht "übergewichtig" oder "IDE-ähnlich" machen würde. Dies würde es Entwicklern, die andere Editoren verwenden, nur bequemer machen, den Übergang weniger schmerzhaft zu gestalten.

Ich hoffe auf diese Verbesserung. Vielen Dank!

Auch wenn das Team die Möglichkeit hinzufügen kann, projektbasierte Einstellungen zu speichern, die Standardeinstellungen überschreiben, ist dies großartig. Der Anwendungsfall ist, wenn ich verschiedene Dolmetscher für verschiedene Projekte haben kann. In ähnlicher Weise helfen auch unterschiedliche Registerkartengrößen usw. Bitte lassen Sie mich wissen, ob dies bereits auf irgendeine Weise erreicht werden kann.

Als Entwickler arbeiten wir immer an mehreren Projekten und haben eigene Nebenprojekte. Das Anpassen der Projekteinstellungen (Arbeitsbereichseinstellungen für vscode) bei jedem Projektwechsel ist ein großes Problem.

@bajubullet Sie sollten https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig ausprobieren. Sie sind sich nicht sicher, ob es alles abdeckt, was Sie benötigen, aber es ist ein Anfang.

@ Danechitoaie danke für die Antwort. EditorConfig hilft zwar nicht, ich kann Eigenschaften pro Dateityp angeben, aber wenn ich sie als Projekteinstellungen speichern kann, wird es einfacher und ich mag es nicht, .editorconfig für jedes Projekt zu haben. Auch bei Erweiterungen wie der Python-Erweiterung, mit der wir den zu verwendenden Interpreter bereitstellen, hilft dies nicht, da python.pythonPath nicht über editorconfig unterstützt wird. Bitte lassen Sie mich wissen, wenn mir hier etwas fehlt. Anregungen sind herzlich willkommen.

Ich stimme zu, ich freue mich auch sehr auf projektspezifische Einstellungen und darauf, mehrere "Root" -Ordner öffnen zu können. Es sind die einzigen Dinge, die ich von Sublime vermisse.

Dies wird bald implementiert!

Sie müssen diesen Beitrag also nicht ständig ergänzen. Wenn Sie andere Probleme haben, erstellen Sie einen neuen Thread. Vielen Dank!

Dies ist ein ziemlich langer Thread, und ich habe vielleicht ein Drittel davon durchgelesen, möchte aber nur meine Unterstützung aussprechen. Ich habe gerade VS Code mit https://github.com/JuliaEditorSupport/julia-vscode als möglichen Ersatz für Atom / Juno installiert. Es ist wunderschön! 😍

Bei der Entwicklung von Julia-Code halte ich es jedoch für ziemlich wichtig, mehrere Pakete in verschiedenen Ordnern öffnen zu können. Im Prinzip könnte ich den Ordner oben öffnen, aber das würde die Hunderte von Julia-Paketen offenlegen, die ich installiert habe. Ich könnte auch mein LOAD_PATH ändern, aber ich würde eine VS-Code-Lösung sehr bevorzugen.

Ich hoffe aufrichtig, mehrere Ordner öffnen zu können. Vielen Dank für die Bemühungen 👍

Hallo allerseits, wie Sie vielleicht bemerkt haben, untersuchen wir die Implementierung dieses Problems während dieser Iteration.

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

Untersuchen Sie Multi-Root-Arbeitsbereiche in den verschiedenen Komponenten @team

Ich möchte mit 3-5 von Ihnen über Ihre Anwendungsfälle sprechen, während wir die Implementierungsdetails durchdenken. Bitte melden Sie sich für ein 15 - minütigen Zeitfenster am nächsten Dienstag , wenn Sie können. Ich würde gerne plaudern.

Das Wechseln zwischen meiner API und UI macht mich verrückt ... :-(

@ehartford Gibt es einen Grund, warum sie keinen gemeinsamen Elternteil haben?

Ja. Die Git-Integration funktioniert nicht, wenn ich nur das übergeordnete Verzeichnis öffne.

@ehartford guter Grund: Lächeln:

@waderyan suchen Sie nur _end user_ Anwendungsfälle oder _extension Entwickler_ auch?

Als Endbenutzer war die Unterstützung für mehrere Ordner meistens für Suchzwecke nützlich. Ich habe Projekte erstellt, in denen verschiedene Ordner aus verschiedenen APIs hinzugefügt wurden, um die Suche zu vereinfachen (einheitlich). Ich würde sagen, ich vermisse heute nicht so viel und störe mich nicht, heute mehrere VSCode-Fenster zu haben, insbesondere nachdem der Befehl Switch Window hinzugefügt wurde: +1:

Als _Erweiterungsentwickler_ habe ich einige Erweiterungen, die auf _Project Context_ basieren, wie context.workspaceState , activationEvents/workspaceContains . Und auch Project Manager , der übrigens bereits damit begonnen hat, die Interna so umzugestalten, dass sie mehrere Ordner unterstützen. Ich würde gerne wissen, wie sich dies auf die Erweiterungen auswirkt

Vielen Dank

Um das oben Gesagte zu ergänzen (https://github.com/Microsoft/vscode/issues/396#issuecomment-270326917), verwende ich tatsächlich Git-Submodule. Wenn ich also an meinen eigenen (privaten) Paketen arbeite, ist dies der Fall Es macht durchaus Sinn, sie zu bündeln, aber da Julia noch relativ jung ist (relativ gesehen), muss ich oft neben meinen eigenen an anderen Paketen arbeiten. Ich sehe keinen zwingenden Grund, diese anderen Pakete als Submodule hinzuzufügen (obwohl ich könnte).

Im Allgemeinen hüpfe ich bei der Entwicklung von Julia-Paketen ständig über Pakete, sodass es großartig wäre, mehrere Projektordner zu haben: +1:

PS: MS, bitte schenke Julia mehr Aufmerksamkeit;)

Einfachster Anwendungsfall: Microservices

Haha. Ja @saada 👍 Es waren tatsächlich Microservices, die uns zu VS Code gebracht haben. Wir verwenden Azure Service Fabric und mein Partner hat die ersten Microservices in .NET und Rust erstellt. Ich arbeite an den Julia Microservices. Mein Partner ist ein VS-Typ und mochte VS Code for Rust. Er schlug vor, VS Code für Julia auszuprobieren. Vielen Dank!

@saada definitiv auf dem Radar. Können Sie diese Fragen beantworten, damit ich die Anforderungen besser erfüllen kann?

1. Teilen Ihre Mikrodienste einen übergeordneten Ordner? Warum oder warum nicht?
2. Ist jeder Microservice in ein eigenes Git-Repository unterteilt? Warum oder warum nicht?

1. Ist jeder Microservice in ein eigenes Git-Repository unterteilt? Warum oder warum nicht?

@waderyan Ein möglicher Grund ist, dass einige beliebte PaaS-Plattformen wie Heroku erfordern, dass sich jede App (Microservice) in einem separaten Git-Repo befindet. Deploy-via-Git-Push ist zu einer beliebten Strategie geworden.

@waderyan Ich Bezug auf solche Anwendungsfälle ist unser ähnlich.

Wir sind eine große Organisation, haben eine private npm-Registrierung und veröffentlichen unsere eigenen Module, die innerhalb der Organisation gemeinsam genutzt werden. Wir haben eine Reaktions-App mit einer Client-Codebasis, bei der es sich um eine große App handelt, die einige gängige Module verwendet (z. B. Dienstprogrammbibliotheken, gemeinsam genutzte Komponenten), und eine Server-Codebasis, die ebenfalls aus mehreren Modulen besteht (Express-Server-App, Backend-Datendienstkomponenten, die von der Service-Schicht und die tatsächlichen Services, die dem Client zur Verfügung gestellt werden). Die aktive Entwicklung umfasst mindestens zwei (Client- und Serviceschicht), die Fehlerbehebung kann jedoch leicht ein halbes Dutzend Module umfassen.

Selbst wenn öffentliche npm-Module verwendet werden, ist es gelegentlich nützlich, den Quellcode direkt zu verknüpfen und in einer separaten VS-Code-Instanz zu öffnen, um ein schwieriges Problem oder sogar einen Fehler in einem Modul eines Drittanbieters zu beheben. Meistens handelt es sich jedoch um unseren eigenen Code.

Jedes sind separate Git-Repos. Es ist kein Problem, sie in meinem Dateisystem unter einem einzigen Stammordner zu halten (ich würde es sowieso tun). Ich muss jedoch für jede Instanz eine separate Instanz von VS Code öffnen, und das Hin- und Herwechseln ist schmerzhaft, da nur der Dateiname angezeigt wird - nicht der Name der Anwendung selbst. Es gibt keine Möglichkeit herauszufinden, welche Anwendung / welches Modul / welches Projekt in welchem ​​Fenster geöffnet ist. Der Dateiname selbst liefert nur sehr wenige nützliche Informationen zur Unterscheidung zwischen mehreren VS-Code-Instanzen.

Es gibt ein weiteres offenes Problem im Zusammenhang mit der Konfigurierbarkeit der Titelleisteninformationen, das ich ebenfalls viel kommentiert habe - und das auch ungelöst bleibt. Wenn es möglich wäre, den Namen des Stammordners in der Titelleiste linksbündig zu lassen, wäre das Problem, dass mehrere Projekte geöffnet sind, weitaus weniger problematisch, da ich beim Wechseln von Aufgaben zumindest sehen konnte, welche offene Instanz welche in Windows war. Dies scheint wirklich trivial zu sein, um konfigurierbar zu machen, und würde zumindest den Schmerz lindern, nicht in der Lage zu sein, mehrere Git-Repos in einer einzigen Instanz zu öffnen, während dies herausgefunden wird ...

@ Waderyan

1. Meine Webprojekte werden von einem einzigen übergeordneten Ordner verwaltet. Es ist auf diese Weise für die Organisation eingerichtet und enthält schnelle Links für meine Repository-Ordner. Ich mache das auch, da es für mich einfach ist, in ein vorheriges / aktuelles Projekt zu wechseln, um Codebeispiele abzurufen, wenn sie wiederverwendet werden sollen. Im Gegensatz zum Öffnen eines anderen Fensters ist es einfacher, einen anderen Tab zu öffnen, und in meinem Fall zeiteffizienter.

2. Jedes Webprojekt hat seine eigene Git-Integration. Für mich persönlich ist es jedoch nicht erforderlich, dass .git in meinen Code-Editor integriert wird. Es ist eine schöne Option für mich, aber keine Voraussetzung. Sie haben ihre eigene .git-Integration, weil sie jedes Webprojekt in meinem Repo-Host getrennt halten möchten.

@nickmak @jamietre @pesho Danke, dass du deine Gedanken geteilt hast. Dies ist hilfreich und ich freue mich darauf, morgen mit vielen von Ihnen mehr zu chatten.

@alefragnani Ich konzentriere mich auf das Endbenutzerszenario. Wir haben dieses Problem aufgrund der Auswirkungen auf Erweiterungen vorsichtig angegangen. Wir werden vorsichtig vorgehen und alle API-Änderungen mitteilen. Pingen Sie mich auf Twitter an, wenn Sie möchten, und wir können einen Anruf tätigen, um weitere Informationen zu erhalten.

Sogar Notepad ++ unterstützt mehrere Ordner. Aus diesem Grund kann Notepad ++ nicht verlassen werden.
An diesem Tag muss die Arbeit mit Javascript mehrere Projekte öffnen.

Ich arbeite mit eingebetteter Software und normalerweise arbeite ich systemweit an einigen Ordnern. Zum Beispiel Anwendungscode, Herstellerbibliothek und Betriebssystemcode.

Ich möchte hier meinen Anwendungsfall für mehrere Ordner im selben Fenster hinzufügen.

Ich bin ein Spieleentwickler und für unser aktuelles Spiel haben wir Mod-Unterstützung implementiert. Unser Spiel hat Client-, Server- und Master-Server-Projekte. Während der Bearbeitung der Mod-Dateien wird häufig nur auf der Mod-Ebene des Spiels gearbeitet (anstelle der Kern- oder Native-Ebene des eigentlichen Spielcodes, z. B. nur in den Lua-Dateien anstelle von C ++ - und C # -Dateien für Server und Client jeweils). Die Ordner befinden sich häufig nicht in einem gemeinsamen übergeordneten Ordner.

In diesem Anwendungsfall haben wir in der Vergangenheit, wenn wir nur innerhalb der Mod-Dateien arbeiten, die Multifolder-Funktionalität von Sublime verwendet, um eine Projektansicht nur der Mod-Ordner der obersten Ebene von Client und Server zu erstellen. Dies ermöglicht es uns, die nativen Dateien (C # und C ++) zu vermeiden und Lua-Dateien in diesen beiden Projekten, die sehr eng miteinander verbunden sind, schnell zu bearbeiten.

Die Unterstützung mehrerer Ordner in VSCode würde es uns ermöglichen, dasselbe zu tun und die Einführung von VSCode (das wir sehr lieben) erheblich zu vereinfachen.

Was kam aus dem Anruf, der letzte Woche stattfand? Ich bin auf einem Mac und kann nicht mehrere Instanzen von VSCode öffnen, was meiner Meinung nach eine Problemumgehung wäre.

Vielen Dank!

Ich hatte letzte Woche einen Anruf bei Wade, es ist offensichtlich und fair, dass dies kein war
frühe Priorität, sie haben einen wirklich guten Editor gebaut, und jetzt hoffentlich
Sie erweitern es, um den unterschiedlichen Anforderungen der Entwickler gerecht zu werden. Das Entwicklerteam ist
Ich freue mich darauf zu sehen, wie sie vorgehen

Am Sonntag, den 15. Januar 2017 um 21:20 Uhr nowherenearithaca, [email protected]
schrieb:

Was kam aus dem Anruf, der letzte Woche stattfand? Ich bin auf Mac und kann nicht scheinen
mehrere Instanzen von VSCode zu öffnen, was ich für eine Problemumgehung hielt.

Vielen Dank!

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/Microsoft/vscode/issues/396#issuecomment-272724576 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AA16yEIdTFJAnqXHLs_WUvrGBIR9G7f-ks5rSo2DgaJpZM4Gm3nX
.

auf große Anfrage
Kennzeichen

@nowherenearithaca Ich hatte tolle Anrufe mit einer Reihe von Benutzern und teilte das, was ich gelernt habe, mit dem Rest des Teams. Wir überlegen uns noch die nächsten Schritte, aber ich würde erwarten, dass wir bald etwas in diesem Bereich unternehmen werden.

@ Waderyan , Entschuldigung für die späte Antwort:

Teilen Ihre Mikrodienste einen übergeordneten Ordner? Warum oder warum nicht?

Ja, der Einfachheit halber. Dies erleichtert das Auffinden verwandter Dienste, wenn sie sich im selben Verzeichnis befinden.

Ist jeder Microservice in ein eigenes Git-Repository unterteilt? Warum oder warum nicht?

Ja. Sie haben nicht nur unterschiedliche Repos, sondern auch unterschiedliche Flusen- und Debugging-Konfigurationen. Die Verwendung von Cmd + P zum Wechseln von Dateien zwischen Projekten ist außerdem sehr nützlich. Globale Suche über verwandte Projekte hinweg, ...

Ich freue mich darauf, dies in Aktion zu sehen!

Eine Lösung wäre, einen Link zu dem Ordner zu erstellen, in dem sich die Dateien befinden, auf die Sie zugreifen möchten.
Es ist nicht ideal, aber es kann helfen.

_Beispiel:_

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

Ich habe 3 Monitore und möchte VSCode für alle drei verwenden. Wenn ich nicht mehrere Instanzen öffnen kann, unterstützen Sie zumindest das Abdocken der Registerkarten und das Ziehen in andere Fenster (ähnlich wie in Visual Studio 2015).

Zustimmen.

Alle anderen Texteditoren machen das. Warum hat Microsoft nicht an etwas so Einfaches und Notwendiges gedacht?

@calloncampbell Diese Funktion ist in dieser Ausgabe enthalten: https://github.com/Microsoft/vscode/issues/2686

@calloncampbell @rsyring Ich weiß nicht, was ich falsch mache, aber mit code -n kann ich so viele Editorinstanzen öffnen, wie ich möchte.

Wenn ich das richtig verstehe, wird dies im Iterationsplan vom "Erste Untersuchung zur Implementierung von 'Multi-Root-Arbeitsbereichen', 'Multi-Ordner'-Arbeitsbereichen" untersucht :)

+1 ...
Ist das nicht mit einer alten Version von VSCode möglich oder habe ich nur Sublime verwendet? vergessen...
aber sehr praktisch.
Jetzt ist mein Mac überall mit 6 Fenstern übersät ...

Und nein, ich werde den Stammordner aller 6 Ordner, die ich geöffnet habe, nicht öffnen, da der Explorer eine vertikale Schriftrolle ist und ich ewig brauchen würde, um die Dateien zu durchsuchen ...

@edmundtfy es ist in erhaben möglich. Visual Studio Code hat diese Funktionalität nie unterstützt.

@ min20 Lösung ist einfach perfekt !!! Multi-Ordner-Projekt, es würde stattdessen Multi-Windows über Schaltflächen verwaltet

@DeeJaVu in Anbetracht dessen , dass ... VSCode diese Mouseover-QuickInfo und Steuerung + Klick hat, um zur Definition zu gelangen. Ich habe einige Erweiterungen für Sublime heruntergeladen, aber das Mouseover- und Control + Click-Material funktioniert nicht so gut. Irgendwelche Empfehlungen?

Ich vermisse das wirklich, nachdem ich Sublime jahrelang benutzt habe. Im Moment arbeite ich mit Intershop (als Front-End) mit Hunderttausenden Dateien pro Kartusche. Wenn ich einen vollständigen Webshop laden muss, ist es sehr langsam, wenn Sie STRG + P öffnen möchten, um schnell zu einer Datei zu wechseln, oder wenn Sie suchen müssen.

Außerdem möchte ich einfach nicht jeden Ordner eines Projekts in meinem Editor haben. Als Front-End-Entwickler brauche ich nicht alles. Nur die Ordner, die ich brauche, sind genug.

Ein weiteres Beispiel: Erstellen einer Wordpress-Site und gleichzeitiger Plugins dafür. Warum sollte ich eine vollständige Wordpress-Site hinzufügen müssen? Es verlangsamt nur Ihre Effizienz.

Ein weiteres Problem, das wir haben: Unser Front-End-Framework ist in verschiedene Git-Repos aufgeteilt. Mehr als 4 geöffnete Fenster zu haben, ist ein echtes Problem. Und SCSS Intellisense funktioniert dann nicht (IE. Variablen aus core> package)

TLDR; VScode ist für große / große Projekte unbrauchbar

+1, stellen wir uns vor, Sie entwickeln ein WordPress oder ein Drupal mit mehreren benutzerdefinierten Modulen.

Ihr Projektstamm ist der Stamm Ihrer Website, aber Sie möchten nicht, dass die gesamte Website ein Repo ist, sondern nur, dass Ihre verschiedenen Module oder Themen jeweils als eigenständiges Repo fungieren.

Sehr häufiger Anwendungsfall in der Webentwicklung, der auch von der kleinsten / leichtesten IDE abgedeckt werden sollte.

+1

+1 würde es mir ermöglichen, ein Projekt zu bearbeiten und nahtlos an seinen Submodulen zu arbeiten

+1

Dies ist das einzige Problem, das uns davon abhält, unser gesamtes 32-köpfiges Entwicklerteam auf VS zu migrieren.

Die Entwicklung von Mikrodiensten ist einfach nicht machbar, es ist schmerzhaft.

+1

+1, definitiv nützlich, ich entscheide mich, von sublime zu vscode zu wechseln, aber da diese Funktion fehlt, denke ich, dass ich sublime noch bis zu einem Tag verwenden würde.

Es ist eine sehr notwendige und grundlegende Funktion. Ich kann nicht glauben, warum Entwickler dieses großartigen Editors es ignoriert haben. Ohne diese Funktion ist es nutzlos. Dies hindert mich daran, von Atom zu VSCode zu wechseln.

Bitte fügen Sie diese Funktion hinzu. Nach der Verwendung von Sublime und dann Atom ist dies für mich eine notwendige Funktion eines Editors. Natürlich ist es wegen der Git-Integration nicht so einfach, aber es ist etwas, das ich in meinem Lieblingseditor brauche.

+1

+1 dringender Bedarf

+1 Wie bereits gesagt, benötigen wir diese Funktion wirklich, um von Atom zu VSCode zu wechseln.

ACHTUNG VOR KOMMENTAR
* BITTE !!!! Stoppen Sie den Kommentar mit einem "+1"

Jeder Ihrer nutzlosen Kommentare lenkt nur mit diesem Thread mehr als hundert Menschen ab !!!
Wenn Sie diese Funktion unterstützen möchten, hat sie Emotionen in der ersten Nachricht!
Wenn Sie Updates abonnieren möchten, klicken Sie auf die Schaltfläche "Abonnieren" rechts neben den Themen
Respektieren Sie die anderen Mitglieder, die gezwungen sind, Ihre "+1", "wirklich gebraucht" usw. Zu lesen

Als Referenz ist die Art und Weise, wie Sublime Text (als Beispiel) seine Projekte anordnet, das "Einschließen" von Ordnerbäumen mit eindeutigen Optionen pro "Ordner", die in Ihrem Projekt enthalten sind.

Um dies zu veranschaulichen, sieht der JSON einer Sublime Text-Projektdatei folgendermaßen aus:

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

Wie Sie sehen können, ist jeder enthaltene Ordner relativ zum Projektpfad (im Fall von erhabenem Text ist dies der Pfad der Datei *.sublime-project ). Außerdem verfügt jeder Ordner über einen Abschnitt zum Ausschließen von Datei- und Ordnermustern mit Platzhaltern. Hervorragend geeignet, um Testergebnisse, Bibliotheken, die Sie nicht bearbeiten sollten, Grafiken und viele andere Dinge zu ignorieren (wie oben zu sehen).

Dies ist der letzte Grund, warum ich nicht gewechselt habe.

Es ist sehr nützlich!

+1
Beispiel: Sie müssen überprüfen, ob einige Funktionen in anderen Modulen, auf die die App verweist, noch nicht implementiert sind, damit ich keine Funktionen dupliziere

Offensichtlich werden die Module an anderer Stelle im Dateipfad gespeichert, nicht in der App selbst, und die Verwendung mehrerer Fenster ist mit nur einem Bildschirm schwierig, wenn Sie nur schnell auf eine Datei zugreifen und den Code lesen möchten
Ich spreche von AngularJS-Apps, die keine Bereitstellung oder ähnliches benötigen, sondern nur einen laufenden Server.
Warum sollte ich mich die Mühe machen, eine andere Dateistruktur zu entwickeln, wenn ich den App-Ordner direkt von Tomcat aus öffnen und meine Änderungen in Echtzeit wirksam werden lassen kann?

Und nein, es gibt keinen übergeordneten Ordner, es sei denn, Sie schlagen vor, den Tomcat-Serverordner als Projekt zu öffnen (was so ist, als würde ich meine gesamte Festplatte als Projekt öffnen, da ich dann alle Dateien öffnen kann).

Wow, ich habe atom deinstalliert, um VS auszuprobieren, und diese Funktion wurde seit 2015 nicht mehr hinzugefügt.

stoffeastrom hat diese Ausgabe am 21. November 2015 eröffnet

Das ist deprimierend. :enttäuscht:

PS: Das Öffnen des Hauptordners ist nicht gerade eine Lösung, da es auch alle unerwünschten Dateien öffnet und den gesamten Zweck dieses Tickets übertrifft.

Das ist in der Tat deprimierend. Aber andererseits nicht so deprimierend wie die Leute, die sich immer noch über einen erstaunlichen, kostenlosen OpenSource- Editor beschweren (der jeden Monat eine Handvoll neuer Funktionen hinzufügt). Noch so deprimierend wie das Spammen aller, die diesen Thread mit Kommentaren zur eigenen Depression ansehen.

_{(Jetzt bin ich einer der Spammer, denke ich: grinsen :)}

Update: Der aktuelle Plan sieht vor, dies in den Iterationen März / April zu untersuchen.

Den Iterationsplan für März finden Sie unter https://github.com/Microsoft/vscode/issues/21923 :

Untersuchen Sie Arbeitsbereiche mit mehreren Stammverzeichnissen @bpasero @Tyriar

+1

So teilen Sie ein Beispiel aus der Praxis, in dem die Funktionsbeschreibung verfeinert wird: Beispiel: WordPress Theme / Plugin dev.

In anderen Editoren habe ich mehrere Ordner als "Lesezeichen" eingerichtet, um zu einem ziemlich großen und komplexen Dateibaum zu gelangen, der etwas einfacher zu verwalten ist. Eine davon ist die Webroot, die die Wurzel ist. Ich würde es vorziehen, wenn eine Debug- und Code-Vervollständigungsfunktion nachschlagen würde (die Umgebung). An zweiter Stelle steht das eigentliche Projekt, ein Themenordner oder ein Plugin-Ordner, der in meinem Workflow das Stammverzeichnis der Versionskontrolle ist. Gelegentlich richte ich zusätzliche Ordner als Referenz ein, z. B. ein übergeordnetes Thema oder ein Vorlagenthema oder ein Plugin, in das ich integriere und das ich häufig referenzieren / lesen muss.

Das hier festgelegte Feature ist also: 1. die Möglichkeit, das Git-Stammverzeichnis und das Suchstammverzeichnis an verschiedenen Orten festzulegen. 2. Ein Ordner-Lesezeichen-System, das rein visuell ist, um das Dateibaumfenster zu entschlüsseln.

Für einige im Thread, in dem das Git-Stammverzeichnis und das Projektstammverzeichnis identisch sind, scheint es ausreichend zu sein, Submodule zu lernen und zu verwenden, und dann ist es nur etwa 2., um eine schöne, weniger überfüllte Ansicht eines verschachtelten Ordners zu erhalten.

Ich bin mir sicher, dass einige im Thread tatsächlich nach buchstäblicher Unterstützung für mehrere Projekte fragen, aber ich würde annehmen, dass die meisten nur nach der einfacheren Idee für das Lesezeichen von Ordnern fragen.

Ich frage außerdem nach einer Möglichkeit, eine als Projektstamm (Suche / Debug) und eine andere als Git-Wurzel zu definieren. (Fühlen Sie sich frei, meine schlechte Benennung der Dinge zu ignorieren.)

Meine Problemumgehung besteht darin, einfach einen übergeordneten Ordner zu erstellen und darin die symbolischen Links zu allen gewünschten Projekten zu erstellen.
_z.B._

Ich habe diese Projekte

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

Ich erstelle einen Ordner mit dem Namen _my-app-all_ (der Name spielt hier keine Rolle) und erstelle zwei symbolische Links, die auf meine App-API und meinen App-Client verweisen. In VSCode muss ich nur öffnen. alle

Schritte

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

Anmerkungen:
Die Git-Integration funktioniert nicht

@DannyFeliz Dies sollte als Antwort auf dieses Problem markiert und oben veröffentlicht werden, damit jeder es sehen kann ... Ich habe dies auch unter Windows mit dem Befehl MKLINK getestet.
Anwendungsbeispiel:

1. Öffnen Sie die Eingabeaufforderung mit Administratorrechten
2. Gehen Sie zu Ihrem Projektordner
   3. [optional] Erstellen Sie einen Linkordner
3. Verwenden Sie MKLINK / D "Linkname" "Pfad zu Ordner, auf den Sie verweisen möchten"

Wenn Sie das Projekt in VS-Code öffnen, werden der Ordner, auf den verwiesen wird, und alle darin enthaltenen Dateien / Ordner angezeigt.

Viel Spaß beim Codieren!

Dadurch kann die Git-Integration nicht funktionieren.

Am Montag, den 20. März 2017 um 14:42 Uhr, poparazvandragos [email protected]
schrieb:

@DannyFeliz https://github.com/DannyFeliz Dies sollte als markiert werden
Antwort auf dieses Problem und oben für alle sichtbar gepostet ... Ich habe getestet
Dies auch unter Windows mit dem Befehl MKLINK.
Anwendungsbeispiel:

1. Öffnen Sie die Eingabeaufforderung mit Administratorrechten
2. Gehen Sie zu Ihrem Projektordner
   3. [optional] Erstellen Sie einen Linkordner
3. Verwenden Sie MKLINK / D "Linkname" "Pfad zu Ordner, auf den Sie verweisen möchten"

Wenn Sie das Projekt in VS-Code öffnen, wird der Ordner angezeigt, auf den verwiesen wird
und alle Dateien / Ordner darin.

Viel Spaß beim Codieren!

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/Microsoft/vscode/issues/396#issuecomment-287907310 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ABEOBVKz2bqFsRdfvyOpcFW2e_26HV5bks5rnvLWgaJpZM4Gm3nX
.

@ehartford Ich sagte eine Antwort, nicht DIE Antwort, da die meisten von uns genau nach genau dieser Sache suchten und mehrere Verzeichnisse im selben VSCode-Fenster anzeigten, die sich an verschiedenen Orten befanden.
Symbolische Links tun genau das, aber wenn Sie unter Windows arbeiten, ist dies nicht die Lösung, die Ihnen in den Sinn kommt.
Es musste 2 Jahre dauern, bis ein Linux / OSX-Entwickler kam und uns die einfachste Problemumgehung zeigte.
Ich bin froh, dass ich mich entschlossen habe, endlich meinen Kommentar zu diesem Thema abzugeben, da ich eine Problemumgehung für das habe, was ich wollte
Nach nur 12 Tagen, als ich es am meisten brauchte.

Das Problem sollte nicht fallen gelassen werden, da viel mehr getan werden kann, wenn die Entwickler sich dafür entscheiden, in die Angelegenheit einzugreifen.
Aber für die meisten von uns ist das befriedigend. Ich habe nur vorgeschlagen, dies irgendwie nach oben zu verschieben, damit die Leute keine Zeit damit verschwenden, alle anderen Kommentare zu lesen, bis sie diesen Kommentar erreichen. Einige übersehen es möglicherweise nur aufgrund der Größe des Threads.

Ich werde dies nur bearbeiten, wenn ich sehe, dass Leute bereits auf meinen Rücken springen, weil ich herausgefunden habe, wie ich das erreichen kann, was ich wollte, und versucht habe, es anderen leichter zu machen, eine Alternative zu sehen, auch wenn sie nicht perfekt ist. Übrigens: Sie können jederzeit die in VSCode integrierte Eingabeaufforderung verwenden, um Dateien in einzelnen verknüpften Ordnern abzurufen / festzuschreiben / zu verschieben. Warum sollten Sie sich jedoch mit Problemumgehungen zufrieden geben?

Ohne Git-Integration ist es ein totaler Nichtstarter. Ich halte dies keineswegs für eine akzeptable Lösung. Ich freue mich auf eine konkrete Lösung. Freundliche Grüße.

Wenn es hilft - Google Appengine NodeJS Client ist wie folgt aufgebaut:

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

Ich würde gerne in der Lage sein, in einer solchen Lösung zu öffnen / zu debuggen / zu arbeiten (auch wenn es sich jeweils um ein Paket handelt). Ich würde gerne Typescript-basierte Projekte / Bibliotheken in diesem Stil schreiben können.

Danke für die tolle Arbeit!

Ich liebe VSCode, aber es ist Mist, mehrere Projekte zu bearbeiten. Aber ich kann verstehen, warum die Funktion verschoben wurde, da dadurch mehrere Dinge wie die Quellcodeverwaltung aufgrund von Verschachtelungen usw. komplizierter werden.

Ich würde mich über eine Funktion zum schnellen Wechseln des Projekts oder über die Möglichkeit freuen, mehrere vscode-Instanzen in einem Fenster zu tabulieren.

Stimmen Sie vollständig zu, unterstützen Sie das Öffnen mehrerer Projektordner im selben Fenster. Diese Funktion ist sehr wichtig.

@replete Es ist keine perfekte Lösung für Ihr Problem. Aber probieren Sie den Projektmanager aus , das hilft mir momentan teilweise.

@dariusrosendahl Ja , heute Morgen lustig genug entdeckt! Erledigt den Job vorerst.

Die Seitenleiste hat nur 5 Symbole. Das Hinzufügen einer Seitenleiste "Projekt" würde nicht viel kosten. Aber es scheint, dass vscode-Produktbesitzer sehr pingelig sind, wie minimal es ist. Zu minimale IMO, da sie jetzt zu einer IDE wird.

@replete froh zu wissen, dass es hilfreich ist 😄

Tatsächlich gibt es in einer experimentellen API einen so genannten _Tree Explorer Contribution_ (genau wie in einem Symbolbedienfeld - https://github.com/Microsoft/vscode/issues/15485). Damit könnte die Erweiterung der Aktivitätsleiste ein Symbol hinzufügen.

Ich werde meiner Erweiterung mit Ihrem Vorschlag ein Problem hinzufügen, danke 👍

+1

@dmccaffery

Es ist mir persönlich egal, ob diese Funktion im Produkt landet oder nicht - ich verstehe, warum manche Leute sie wollen, aber ich möchte darauf hinweisen, dass dadurch alles etwas komplizierter wird.

Dann dominieren Sie das Gespräch vielleicht nicht mit negativen Kommentaren gegen die Funktion und darüber, wie VSC keine IDE ist? Ich denke, eine einzige Antwort / negative Abstimmung ist genug oder im schlimmsten Fall zwei, wenn man eine Position weiter klären muss.

Außerdem ist das Argument "keine IDE" umstritten. Andere Nicht-IDEs berücksichtigen dies ebenfalls.

Zum Beispiel: Wenn ich mit einem regulären Ausdruck suche - welchen Arbeitsbereich suche ich? einer? alle?

Kein so großes Problem. Entweder alle durchsuchen oder einen Selektor haben, um die Suche auf einen der offenen Arbeitsbereiche zu beschränken. Wiederum behandeln andere "Nicht-IDEs" (sowie IDEs) diesen (und andere) Fälle bereits.

Ich habe dieses Problem in meinem eigenen Setup behoben, indem ich für jeden "Arbeitsbereich" ein Verzeichnis erstellt und eine Verknüpfung zu den Projekten hergestellt habe, die in diesem Arbeitsbereich angezeigt werden sollen.

das habe ich gesehen

Erste Untersuchung von Multi-Root-Arbeitsbereichen mit mehreren Ordnern # 396

Wird laut https://github.com/Microsoft/vscode/issues/21923 irgendwelche Updates dazu durchgeführt? :) :)

Wir (Teilmenge des Teams) haben eine erste Untersuchung des Arbeitsaufwands und der Herausforderungen durchgeführt, die wir sehen. Der nächste Schritt besteht darin, das Ergebnis mit dem Team zu besprechen und es zu planen. Wir planen für die Veröffentlichung im April in dieser Woche, daher würde ich aufgrund dieser bald erscheinenden Arbeit feinkörnigere Planelemente erwarten.

Wenn ich nicht zu spät zur Party komme, ist dies eine gute Möglichkeit, dies umzusetzen.
Wenn Sie zu "Explorer" gehen, haben wir bereits zwei Abschnitte. Eine für geöffnete Dateien und eine für den Explorer-Baum des aktuell geöffneten Ordners.

Im Idealfall könnten wir einfach mehr Ordner im selben Fenster öffnen und sie würden hier in einem eigenen Abschnitt hinzugefügt, der erweitert werden kann, um den Explorer-Baum anzuzeigen.

Das Gleiche könnte für den Bereich Quellcodeverwaltung getan werden. Ein Unterabschnitt für jeden Ordner, der im "Explorer" geöffnet wird. Also eine 1 zu 1 Beziehung.

Auf diese Weise können wir vielleicht alle glücklich machen. Wir unterstützen das Öffnen mehrerer Ordner in demselben Fenster, wenn wir möchten, und auch die GIT-Integration funktioniert weiterhin und kann jeden "Projektstamm" separat behandeln.

Öffnen Sie mehr als ein Projekt im selben Fenster. Dies ist auch für mich eine wichtige Funktion. Normalerweise öffne ich auch Projekte, um einige Basis-Apps zu kopieren. Ich installiere nur Visual Studio Code und werde aus diesem Grund zu Atom zurückkehren

+1 Ich möchte anderen Entwicklern den Wert von VSCode zeigen, aber nicht zwei Ordner im selben Fenster öffnen zu können, ist ein Dealbreaker. Ich hoffe das bekommt eine höhere Priorität.

Nur meine zwei Cent:

Bisher wird das Wort "monorepo" in diesem Thread nicht angezeigt

Mein Monorepo zentralisiert Konfigurationsprobleme zwischen mehreren Roots, wobei jedes durch eine ".root" -Datei in dem Ordner gekennzeichnet ist, der sie enthält.

Nicht jeder Stamm ist ein externes Git-Repository, aber sie ermöglichen eine teilweise Überschreibung der globalen Konfiguration.

Mein Hauptschmerzpunkt ist, dass die Suche nach Dateien und / oder Symbolen den Inhalt meiner Wurzeln nicht priorisiert

Ich denke, die Anforderung kann in ~ 4 separate aufgeteilt werden, die direkt miteinander verbunden sein können oder nicht (und wahrscheinlich unabhängig implementiert werden):

• unterstützt mehrere Ordner im Explorer
• unterstützt mehrere Ordner bei der Suche
• unterstützt mehrere Ordner in der Quellcodeverwaltung
• unterstützt mehrere Ordner beim Debuggen

Nach dem, was ich in diesem Thread gesehen habe, kann das Trennen dieser Szenarien eine größere Anzahl von Szenarien unterstützen. Natürlich sollte es noch einen "Haupt" -Ordner geben, der sich darauf auswirkt, wie die konfigurierten / ausgewählten Ordner beibehalten werden.

Ich verstehe nicht, warum die meisten Kommentare über Multi-Root- oder Multi-Folder-Explorer-Lösungen sprechen. Eigentlich finde ich es wirklich schlecht, es auf IDE-Art zu implementieren. Es erhöht die Komplexität und wirkt sich sicherlich auf die Leistung aus (Ladezeit, Git-Aktualisierung ...).

Ich denke, dass diese Funktion sehr wichtig ist. Grundsätzlich müssen alle zugehörigen Projekte visuell dargestellt und schnell zwischen den Projektfenstern gewechselt werden.

Wir haben zwei Möglichkeiten:

• Implementierung in einem einzigen Fenster : In meinem Sinne bringt es viele andere Probleme mit sich, mehrere Projektwurzeln für Git, Suche ..... Dies ist für die UX SEHR SCHLECHT und führt möglicherweise zu Fehlern und Komplexität im Editor.
• Implementieren Sie einen visuellen Schaltmechanismus und behalten Sie ein Fenster pro Projekt : Dies ist die sicherste und bequemste Wahl zu sehr geringen Kosten! @ min20 hat ein Bild über die Schaltflächen von Slack zwischen Gruppen gepostet, die ich für perfekt

Ich hoffe, diese Funktion wird landen, aber nicht als Multi-Root-Lösung! Einer der Hauptvorteile eines kleinen Editors ist seine Einfachheit und Geschwindigkeit, muti-root != simplicity & speed

Ich muss Ihnen überhaupt nicht zustimmen @ g13013 Haben Sie die Implementierung von Sublime gesehen? Es ist sehr einfach und immer noch viel schneller als Visual Studio Code. Auch wenn alle GIT-Plugins aktiviert sind.

Wir sprechen nicht über die Verwendung mehrerer Projekte in einem Editor. Wir sprechen davon, nur die Ordner eines Projekts zu verwenden, die Sie benötigen.

Ich arbeite zum Beispiel an Intershop-Shops. Es gibt eine Menge, die ich nicht brauche, nur die Patronen, die ich bearbeiten muss. 80% der Ordner und Dateien sind für mich nutzlos und machen den Editor nur viel schwerer (glauben Sie mir, es verlangsamt sich sehr).

Die Verwendung der "Schnellöffnung" in Visual Studio ist auch unbrauchbar, wenn viele doppelte Dateien vorhanden sind. Sie sind sich oft nicht sicher, ob Sie das richtige öffnen und es verlangsamt sich mit einer Menge Dateien.

Ich verstehe, aber nachdem ich in der Vergangenheit Sublime und Atom verwendet hatte, kam ich schließlich zu dem Schluss, dass keine von ihnen mit "Muti-Root" -Funktion etwas anderes gelöst hat, als Projektdateien zu erforschen, die von Sublime, Sublime Folder Tree sprechen Große Projekte und friert sogar ein, wenn entdeckt wird, dass sublime keine sofort einsatzbereiten "git" - und "debug" -Funktionen bietet. Die Einführung von muti-root führt zu einer Reihe von Problemen im Zusammenhang mit der git-Integration, bei denen ohne Auswirkungen gesucht wird Leistung ... sogar UX ist betroffen, wie das Erforschen von srcoll-Problemen in großen Projekten.

Seltsam, für mich ist es das Gegenteil.

Vielleicht liegt es daran, dass ich in 99% der Fälle nur das, was ich brauche, in Sublime oder Atom einbeziehe :) und genau das wollen wir.

Vielleicht verwenden Sie den Editor nur so. Ich bin es gewohnt, CMD / CTR + P zu verwenden und genau die gewünschte Datei einzugeben. Dies ist nicht möglich, wenn Sie das Stammverzeichnis eines Projekts mit vielen doppelten Dateien einschließen müssen. (Patronen / Dateien dort gelassen, um zu vergleichen, was das Original war :)) oder so etwas wie WordPress, wo es viele Dateien mit dem gleichen Namen gibt.

Hallo,
Ja, die Idee mit mehreren Ordnern ist in Ordnung, ohne viele Dinge zu beschädigen. Jeder zusätzliche Ordner kann ein neuer Unterabschnitt mit einem Präfix sein, das angibt, dass er dem primären Ordner fremd ist. Primary wird zum Debuggen und Git verwendet. Ein Benutzer kann mit der rechten Maustaste auf einen beliebigen fremden Ordner klicken und ihn zum primären Ordner machen. Was Sie gewinnen:
1) Sie können alle Ihre Ordner und Dateien anzeigen und bei Bedarf öffnen.
2) Umsiedlung dessen, woran primär gearbeitet werden soll.

Wenn jemand mehrere Projekte gleichzeitig öffnen möchte, sollte eine neue Problemanforderung geöffnet werden. Dies führt zu einer erheblichen Komplexität, die von zahlreichen Personen beschrieben wird. Plugins entsprechen nicht Builtins. Wenn es einen Editor gibt, der über eine passende integrierte Funktion verfügt, sollte darauf hingewiesen werden, damit andere Entwickler untersuchen können, wie ihr Workflow zu einer solchen Funktion passt. Vielen Dank. Schönen Tag.

Fügen Sie mich zur Liste der Benutzer hinzu, die dies als den einzigen Deal Breaker betrachten, der mich daran hindert, zu VSC zu wechseln. Ich finde die großartige Implementierung von Projekten genau richtig. Wenn ich beispielsweise an der App "Volunteer Hours" arbeiten muss, öffne ich das Projekt, das ich mit verschiedenen Ordnern gefüllt habe (den Hauptprojektordner sowie einen anderen Ordner, der Bilder enthält). Das ist mein Arbeitsset für dieses Projekt. Wenn ich zur App "Exchange Calculator" wechseln muss, kann ich den gesamten Arbeitssatz gegen dieses Projekt austauschen oder ein neues Fenster mit diesem Projekt öffnen.
Ein weiterer Anwendungsfall ist die Verwendung eines CMS. Wenn ich an einem Plugin für das CMS arbeite, kann ich ein Projekt für das Plugin haben, das ein Git-Repository ist, und ein anderes für das gesamte CMS, das nicht Gitified ist. Ich kann nach Bedarf zwischen den beiden wechseln und meine Git-Bedenken getrennt halten.
VSC sieht für mich wie die Zukunft aus, aber nicht ohne die Möglichkeit, separate Arbeitssätze von Ordnern zu führen.

Hallo,
Ich habe nur gesehen, dass Sublime Text Projekte mit einer Projektdatei unterstützt . Wie entspricht das dem, wonach hier gefragt wird? Es klingt wie eine Anforderung an vscode, Projektdateien in einem Arbeitsbereich zu unterstützen. Es gab früher einen Kommentar zu einer Erweiterung, die diesbezügliche Dinge für einen Projektmanager behandeln könnte .

Ich verwende ehrlich gesagt auch Atom und die integrierte Funktion für mehrere Ordner, mit der ich Dokumentationsordner und meinen aktuellen Projektordner gleichzeitig öffnen kann. Es scheint wirklich wie eine niedrig hängende Frucht, nur Primär- und eine Reihe von Sekundärfrüchten zu ermöglichen. Wahrscheinlich ein einfacher Pfeil oder ein Start, um die primäre anzuzeigen. Vielen Dank. Schönen Tag.

Für das, was es wert ist, hier ist mein Anwendungsfall. Ich arbeite an einem Spiel, das in drei Repositories unterteilt ist. Ein Git-Repo für die Engine, ein HG-Repo für den Spielcode + Inhalt und ein HG für den Spielcode, der für viele Projekte generisch ist. Es gibt auch ein HG-Repo für die Sublime Text-Plugins des Unternehmens. Das generische Repo ist ein Subrepo zum Game-Repo.

An meinem nächsten Arbeitsplatz werde ich voraussichtlich wieder mit vielen Repositories arbeiten.

Es ist sehr praktisch, alle diese Elemente in derselben Editorinstanz zu haben, und ich denke, es wäre sinnvoll, wenn alle diese Elemente in VS Code korrektes SCM erhalten.

Ich würde erwarten, dass die Suche standardmäßig alle zugeordneten Ordner durchsucht. Ein schöner Bonus wäre, vorübergehend ein- und ausschalten zu können, nach welchen Ordnern gesucht werden soll. (Zum Beispiel, wenn ich nur daran interessiert bin, Dinge in der Spiel-Engine zu finden)

Es gibt viele Leute, die sagen, dass VS Code dies nicht unterstützen sollte, weil A) sie es nicht brauchen und B) VS Code ein einfacher Texteditor ist. Der erste Grund ist nicht gut - es gibt nur wenige Funktionen, die von jedem genutzt werden. Der zweite Grund ... VS Code ist nicht nur ein einfacher Texteditor, sondern verfügt über Debugging-, SCM- und Plugins. Andere "einfache Texteditoren" wie Sublime unterstützen mehrere Ordner. Und als jemand, der unerbittlich in Bezug auf die Leistung ist, kann ich nicht sehen, wie sich das Hinzufügen dieser Funktion auf die Leistung in irgendeiner sinnvollen Weise auswirkt, insbesondere für Personen, die ohnehin nur einen Ordner verwenden. Können wir die Diskussion bitte darauf konzentrieren, wie die Funktion funktionieren soll, anstatt warum wir sie nicht wollen?

@Srekel können Sie einen Screenshot davon, wie Sie so arbeiten, in Ihre aktuellen Editoren aufnehmen? Es klingt wie eine Mischung aus Ordnern und Projekten, die integrierte Funktionen und Plugins verwenden. Hoffentlich würden die Leute in diesem A- Camp kaum Änderungen bemerken, um diese Art von Funktion zu integrieren. Für die B- Camp-Leute sind sie richtig. Mit der sofort einsatzbereiten Anwendung können Sie schnell arbeiten, wenn Sie nicht festsitzen müssen. Wenn Sie sich daran halten, können Sie wahrscheinlich so schnelle Aktualisierungszyklen und übersichtliche Schnittstellenelemente erzielen.

Einige Dinge, wie dies erreicht werden kann, sind:

• Verständnis der Beziehung zwischen Umfang, Kontext, Sitzung, Ansichten und Aktualität .
• die Obergrenzen (mehr als 256 Ordner?)
• wichtige betroffene Bereiche (Editor-Registerkarten, Einstellungen, scm, git, Erweiterungen).
• Überschreiben oder Konflikte bei der Einstellung des Arbeitsbereichs.

Es wäre schön, hier einige Dinge zu besprechen, die VSCode in diesen Bereichen als selbstverständlich ansieht und die kompensiert werden müssen. Vielen Dank. Schönen Tag.

+1

+1. Ich habe mehr als 30 Module mit jeweils einem eigenen Git-Repository, auf das ich in einer einzigen Umgebung zugreifen und daran arbeiten möchte. Ich dachte, das machen die meisten js / node-Entwickler. Mit VSCode ist dies unmöglich, ein Deal Breaker für mich leider.

+1

Es ist seit 2015 geöffnet und noch nicht repariert. Es ist einfach die meistgesuchte Funktion in jedem Editor, aber leider hat vscode sie nicht.

+1

Ich verwechsle ständig ein VS-Code-Fenster mit einem anderen, wenn ich einen Befehlstab.

Jeder andere mir bekannte Editor hat dies (Atom, Sublime, Brackets ...)

Das Hinzufügen eines Symlinks zu meinem Projekt ist ein Hack und würde erfordern, dass ich meinen .gitignore aktualisiere. Das Öffnen des übergeordneten Verzeichnisses ist ärgerlich, da dann mein Dateibereich mit anderen Projekten überflutet wird, die mir egal sind.

Iterationsplan für April mit der Aufgabe "Untersuchen von Arbeitsbereichen mit mehreren Stammverzeichnissen und mehreren Ordnern". Was sind die Ergebnisse der Untersuchung?
@bpasero @tyriar

+1

Entschuldigung, wenn ich zu eifrig bin. Ihr seid gerade damit beschäftigt, Code zu veröffentlichen.

Hallo,
Das Dialogfeld "Ordner öffnen" sollte als "Offene Ordner" betrachtet werden. Wenn ich mich also unter einem bestimmten übergeordneten Ordner befinde, kann ich im Dialogfeld zwei oder mehr seiner Unterordner markieren, um sie gleichzeitig zu öffnen. Dies wäre eine willkommene Ergänzung bei der Integration dieser Funktion. Vielen Dank. Schönen Tag.

+ noch einer

Noch nie zuvor so viele Kommentare mit geringem Aufwand in einem GitHub-Thread gesehen, insbesondere Post-Emojis. Meine Güte.

Ich würde diese Funktion wirklich mögen. Wie bereits jemand anderes gesagt hat, sind viele moderne Projekte modular aufgebaut, z. B. Frontend in einem Repo / Projekt und Backend / API in einem anderen. Sie werden oft gemeinsam daran arbeiten wollen.

Dies ist der einzige Grund, warum ich Atom nicht aufgegeben habe.

Microservices und serverlose Plattformen, kombiniert mit dem langjährigen Mantra "Repos sind billig", sind der Grund, warum dies ein Muss ist. Es ist nicht ungewöhnlich, dass ~ 30 [kleine] Repositorys geöffnet sind und gleichzeitig an Dateien aus mehreren Projekten arbeiten. Es wird nicht funktionieren, zu erwarten, dass Benutzer zwischen so vielen Fenstern wechseln oder die Dateiansichtsanordnung in den Fenstermanager der Desktop-Umgebung verlagern.

Hallo,
Wie verwalten Sie Ihre 30 Repos jetzt @martellaj ? Es klingt schrecklich, mit so vielen geöffneten Dateien live zu arbeiten. Ich habe in der Regel viele Bibliotheken, an denen ich arbeite, aber da ich dringend daran arbeiten musste, eine nützliche Funktion für die Freigabe zurück zu portieren, schließe ich absichtlich alle meine anderen Bearbeitungsfenster. Ich erstelle Konfigurationsdateien und Projektoptionen für Testaktualisierungen, damit ich arbeite, und kehre dann zu meiner vorherigen Ansicht zurück. Das sind vielleicht noch 3 oder 4 andere Fenster.
Tun Sie dies aufgrund anderer Einschränkungen in Ihrer Umgebung? Vielleicht hat die Programmiersprache kein Intellisense? Vielleicht hilft eine Erweiterung, die die API lesen kann, um Ihnen funktionale Signaturen zu geben?
Eine Sprache wie F # verfügt über eine Funktion namens Typanbieter, von denen einer genau das kann und die Programmierung des Webs erleichtert. Dies soll Ihren Bedarf an mehreren Ordnern nicht verringern, nur dass Sie wahrscheinlich immer noch mindestens eine Handvoll anderer Probleme mit einem so großen aktiven Arbeitsbereich haben würden. Vielen Dank. Schönen Tag.

@ pr-yemibedu, ich denke, was @martinjco sagt, ist, dass er die Dateien nicht geöffnet hat, aber er hätte schnellen Zugriff auf die Repos, wenn wir eine Multi-Root-Struktur hätten. Stellen Sie sich vor, nur CMD + P zu jeder Datei, die Sie benötigen;)

Das Problem mit der aktuellen Situation ist, dass wir die Dateien geöffnet haben oder zumindest zwischen den 30 verschiedenen Fenstern wechseln MÜSSEN, da VScode dies nicht unterstützt.

Ich bin kürzlich wegen der fehlenden Funktion wieder zu Atom gewechselt. Ich arbeite gerade an einem Projekt mit 9 Repos. Ich möchte nicht, dass 9 VScode-Witwen gleichzeitig geöffnet werden, aber ich möchte nur eine Verknüpfung verwenden, um zu der gewünschten Datei zu gelangen.

Stimmen Sie dem Kommentar von @dariusrosendahl zu. Ich bin ein Neuling-Programmierer und muss auf ältere Projekte verweisen, um neue zu schreiben. Hoffentlich wird sich das bald ändern, aber im Großen und Ganzen kann ich problemlos drei bis vier Projektordner haben und vergleichen, wenn sie in derselben Sitzung geöffnet sind

Wenn wir das im Visual Studio bekommen können, wäre das großartig

Hallo,
Ich bin mit den gemachten Punkten einverstanden, da Sie sehen können, dass meine vorherigen Beiträge diese Funktion befürworten. Es gab eine genaue Aussage, die ich von Martinjco kommentierte:

Es ist nicht ungewöhnlich, dass ~ 30 [kleine] Repositorys geöffnet sind und gleichzeitig an Dateien aus mehreren Projekten arbeiten.

Nuno1895 zeigt, wie ich Atom heute verwende, wenn ich an mehreren Ordnern arbeiten muss, aber an einem einfachen Hauptfokusprojekt. Tatsächlich verwende ich sowohl VS2015 als auch gedit, vim, notepad und notepad ++ für die aktive Entwicklung. Es gibt Stärken in jedem, die noch kein Äquivalent in ihren Gegenstücken haben.

Ich habe nur versucht zu verstehen, ob es einen Kernpunkt gibt, der klargestellt werden kann. Wir alle möchten, dass dies von den Entwicklern, die Zeit damit verbringen würden, bearbeitet und bevorzugt wird. Deshalb habe ich gefragt, wie das heute gehandhabt wird. 9 gegen 30 hätte mein Interesse wahrscheinlich nicht so sehr geweckt, aber ich möchte wissen, was die Leute mit vscode vergleichen und ob es sich lohnt, mir ein anderes Tool anzuschauen.

Ich habe nur Atom und SublimeText als Vergleichsgrundlage und mit nützlichen Screenshots gesehen. Weitere Diskussionen, Daumen und Rückmeldungen sind willkommen, damit dies akzeptiert und umgesetzt wird. Vielen Dank. Schönen Tag.

Ein Punkt, der möglicherweise nicht genug betont wurde, ist die Möglichkeit, schnell zwischen Ordnersätzen (Projekten) zu "wechseln". Es heißt "Quick Switch Project" in Sublime. Wenn Sie auf diesen Menüpunkt klicken, wird ein Popup mit einer Liste aller Ihrer Projekte angezeigt. Wenn Sie eines der Projekte auswählen, zeigt der Editor die Ordner und alle geöffneten Dateien so an, wie Sie sie zuletzt verlassen haben.
Wenn ich beispielsweise in Projekt A gearbeitet habe und die Dateien app.js und index.html geöffnet und dann zu Projekt B gewechselt habe, wird Projekt A geschlossen und Projekt B angezeigt. Wenn ich dann wieder zu Projekt A wechsle, wird dies der Fall sein Zeigen Sie mir die Ordner und die Datei app.js und index.html, wie ich sie verlassen habe (auch nicht gespeicherte Änderungen sind vorhanden).
Wenn beide Projekte gleichzeitig geöffnet sein müssen, kann ich nur zwei Instanzen des Editors öffnen.
Der Schlüssel ist, dass ich alle meine Sachen in getrennten Eimern aufbewahren und schnell zwischen ihnen wechseln kann.

+1

Hallo,
Ich habe über diese Funktion gelesen. Projekte wechseln, ohne in Sublime Text zu surfen , zeigt einige der guten und schlechten auf. Es wäre schön, die mehreren Ordner zu codieren, die in der Arbeitsbereichseinstellungsdatei geöffnet sind. Wenn diese Datei an der falschen Stelle zu sein scheint, kann so etwas wie folders.json erstellt werden, um den aktuellen Status der verfügbaren Ordner und Dateien beizubehalten und für den aktuellen Arbeitssatz zu öffnen. Vielen Dank. Schönen Tag.

Ich habe vor einigen Monaten angefangen, VSCode zu verwenden, und bin im Allgemeinen sehr zufrieden. Ich werde dem Chor meine Stimme hinzufügen und sagen, dass dieses fehlende Feature der große Kratzer für mich ist. Gibt es andere anständige Redakteure, die diese Einschränkung haben? In jedem Fall sollte es behoben werden. :) :)

Hier ist das Setup für meinen neuen Job:
Ein Repo für die Kerntechnologie. Angenommen, der Pfad lautet C: / mygamengine /
Ein Repo für den Spielcode. Es ist mit C: / mygamengine / mygame synchronisiert
Ein Repo für den Inhalt des Spiels (Texturen usw.): C: / mygamengine / mygame_data

Alle drei sind Schwachköpfe. Sie sind nicht als Sub-Repos eingerichtet, sondern nur mit diesen Ordnern synchronisiert.

Am liebsten möchte ich nur den Stammordner in VS Code öffnen und automatisch herausfinden lassen, dass es sich im Wesentlichen um drei verschiedene Projekte handelt und dass Dateien unter mygame zu diesem Git-Repository gehören und nicht zu dem in mygameengine.

Ich möchte in der Lage sein, Einstellungen für diesen Arbeitsbereich festzulegen, die für jedes Repository unterschiedlich sind (z. B. möchte ich möglicherweise einen Linter für das Engine-Projekt ausführen, jedoch nicht für den Spielcode). Es wäre auch schön, wenn für alle drei Projekte standardmäßig Arbeitsbereichseinstellungen festgelegt würden.

Wow, das ist noch nicht gelöst? Ich hatte gehofft, Atom durch VS-Code zu ersetzen, da es laut Bewertungen viel schneller ist und nicht so lange zurückbleibt wie Atom.
Mein Hauptprojekt sind zwei Git-Repos, ein Backend und ein Frontend. Lokal befinden sich beide im selben Ordner. Wenn jedoch Atom- oder VS-Code diesen übergeordneten Ordner öffnet, wird kein Git-Status erkannt.
In Atom füge ich einfach beide Ordner zu meinem Arbeitsbereich hinzu und es funktioniert einfach.

: funkelt: Update: funkelt:

Es ist eine Weile her seit unserem letzten Update, also dachte ich, ich würde alle auf den neuesten Stand bringen. Ich selbst, @bpasero und der Rest des Teams haben die meisten Probleme bei der Implementierung von Multi-Root identifiziert und arbeiten derzeit an einigen

Warum dauert das so lange?

Es dauert so lange, weil diese Funktion nicht unsere einzige Verantwortung ist und die Arbeit, die erforderlich ist, um Multi-Root zu ermöglichen, immens ist. Für den Anfang wurden alle Komponenten in VS Code unter der Annahme entworfen, dass immer nur ein einzelner Ordner oder kein Ordner zu einem bestimmten Zeitpunkt geöffnet ist. Wenn Sie eine so große Codebasis wie unsere mit einer solchen Annahme haben, ist viel Arbeit erforderlich, um sie flexibler zu gestalten.

Um einige Beispiele zu nennen, hier sind einige der größeren Schmerzpunkte, die wir bisher identifiziert haben:

• Die Erweiterungs-API macht ein einzelnes workspace.rootPath verfügbar. Dies ist nicht ausreichend, wenn wir Unterstützung für Ordner mit mehreren Stammverzeichnissen hinzufügen. Wir möchten vermeiden, dass diese Erweiterungen beschädigt werden, und bei Bedarf einen Migrationspfad bereitstellen.
• Die Art und Weise, wie Arbeitsbereichseinstellungen in einer Welt mit mehreren Wurzeln interagieren, ist etwas anders. Nehmen Sie zum Beispiel workbench.statusBar.visible das derzeit in den Arbeitsbereichseinstellungen zulässig ist. Wir könnten dies nicht mehr unterstützen, da dies zu einem seltsamen / fehlerhaften Verhalten führen würde, wenn es in 2 Ordnern definiert würde. Wir sind gerade dabei herauszufinden, wie wir mit solchen Fällen umgehen sollen.
• Der SCM-Anbieter (git) benötigt wahrscheinlich die größte Menge an UX-Arbeit, um mehrere Ordner zu unterstützen: Müssen wir das Konzept eines "aktiven Projekts" einführen? Sollte es explizit festgelegt werden (klicken Sie mit der rechten Maustaste auf den Ordner und legen Sie es fest) oder sollte es implizit festgelegt werden (siehe Ordner der aktiven Datei)? Sollte es sich um ein globales Konzept handeln oder auf dieses spezielle Merkmal beschränkt sein? usw.

Wir möchten uns nicht mit einer schlecht durchdachten Lösung beeilen, also nehmen wir uns Zeit und überlegen wirklich, welche potenziellen Probleme und Auswirkungen dies auf die einzelnen Komponenten haben wird. Es wird kommen, wenn es fertig ist.

Zusammenfassung der bisherigen Kommentare

Ich habe nur ein paar Stunden damit verbracht, den riesigen Thread durchzugehen, um das bisherige Feedback zusammenzustellen. Es war ein wenig schwierig, einige dieser Dinge zu kategorisieren, aber hier ist, wonach die Leute im Allgemeinen suchten (ich paraphrasiere).

• Ich möchte die Git-Integration über mehrere Ordner hinweg
• Die aktuelle Ordnerumschaltung und / oder OS-Fensterverwaltung UX ist umständlich
• Ich möchte über mehrere Ordner hinweg suchen
• Ich möchte über mehrere Ordner debuggen

Sorgen

• Funktionieren Refactorings projektübergreifend oder für ein einzelnes Projekt?
• Für welches Projekt begebe ich mich auf Git?
• In welchen Ordnern wird meine Suche ausgeführt?
• Unterbrechen Sie nicht die Arbeitsbereichseinstellungen
• Unterbrechen Sie keine Erweiterungen - warnen Sie Erweiterungsentwickler vor neuer API
• Eine UX mit Registerkarten im Slack-Stil reicht mir nicht aus, sondern verschiebt im Wesentlichen nur die Fensterverwaltung vom Betriebssystem auf VS-Code. Ich möchte in einem einzigen Fenster (dh einer Reihe von Editorgruppen) auf alle Dateien aus den Projekten zugreifen können.
• "In meinem Sinne bringt es viele andere Probleme mit sich, mehrere Projektwurzeln für Git, Suche ... DAS IST SEHR SCHLECHT für die UX und wird möglicherweise Fehler und Komplexität für den Editor mit sich bringen."

Andere Kommentare

• Ich möchte nur eine Teilmenge der Repos in meinem "Git-Ordner" öffnen.
• Ich möchte eine gute Möglichkeit, in einem einzelnen Ordner zu suchen oder Suchergebnisse nach Projekt zu organisieren
• Ich möchte in der Lage sein, zum Abhängigkeitscode zu navigieren, um schnell lesen zu können
• Ich möchte verschiedene Versionen von TypeScript für verschiedene Ordner ausführen
• VS Code ist mit riesigen Repos zu langsam
• Ich möchte einige Projekte immer offen halten, um sie als Referenz zu verwenden (z. B. ein Thema / eine Vorlage).
• Ich möchte, dass VS Code .vscode / settings.json-Dateien in einem beliebigen Verzeichnis erkennt (dies würde helfen, das Problem zu umgehen).
• Lassen Sie mich einen Projektstamm (Suche / Debug) und einen Git-Stamm definieren
• Sublime handhabt die Git-Integration mit mehreren Ordnern elegant
• Ordner mit Registerkarten, die der Benutzeroberfläche von Slack ähneln (dh ein aktives Projektparadigma)
• Ein separater Abschnitt im Explorer für jeden Ordner
• Verwenden Sie einen Ordner als primären und den Rest als verknüpfte / Unterordner
• Ich möchte ein Schnellwechselprojekt wie in sublime (Schnellwechsel + Beibehaltung des Arbeitsbereichslayouts)
• Diese Art der Arbeitsbereichsverwaltung ist besonders nützlich für Folgendes: npm-Modul, Julia, Heroku PaaS, WordPress, Drupal

Aktuelle Problemumgehungen

Hier sind die wichtigsten Problemumgehungen:

• Ein gemeinsames Elternteil öffnen
• Git Projektmanager
• Projektmanager
• Verknüpfen Sie die Ordner als Unterverzeichnisse des "Hauptordners"

Wann kommentieren?

Bitte vermeiden Sie: +1: oder "Ich will das" -Kommentare. Wenn ein Kommentar zu diesem Problem abgegeben wird, werden die 153 und die zählenden Personen, die das kommentiert haben, zusätzlich zu vielen weiteren Personen benachrichtigt, die auf die Schaltfläche "Abonnieren" klicken. Durch das Kommentieren werden auch Team-Updates begraben. Versuchen Sie also, dies zu berücksichtigen. Kommentieren Sie auf jeden Fall, wenn es zur Konversation beiträgt.

Eine Funktion, die wohl mehr Nutzen hätte als mehrere Wurzeln, besteht darin, die Möglichkeit hinzuzufügen, konfigurierbare Arbeitssätze zu haben. Auf diese Weise können Sie ein gemeinsames übergeordnetes Element öffnen, haben jedoch viele Kombinationen von Ordnern in diesem Projekt.

Generell wäre dies für jedes Projekt nützlich, um sich in größeren Codebasen gleichzeitig auf bestimmte Dateien / Ordner "konzentrieren" zu können, ohne jedes Mal die Konfiguration für den gesamten Stamm ändern zu müssen.

KEIN Plan für diese Funktion?

Sie können den Plan für diese Funktion im Kommentar von @Tyriar und in den zugehörigen Links sehen:
https://github.com/alefragnani/vscode-project-manager/issues/46
https://github.com/Microsoft/vscode/issues/26068

Wir möchten unsere Entwürfe dafür teilen und Ihr Feedback erhalten. Zu diesem Zweck werden wir eine Reihe von Telefonkonferenzen einrichten, in denen wir unsere Entwürfe durchgehen und Ihre Reaktionen auf die Entwürfe besprechen.

Wenn Sie an diesen Diskussionen teilnehmen und uns helfen möchten, das richtige Design zu finden, kontaktieren Sie mich bitte (senden Sie mir eine E-Mail - stevencl at microsoft dot com) und ich werde diese einrichten.

Wir hoffen, diese Diskussionen für Donnerstag, den 1. Juni und Freitag, den 2. Juni planen zu können.

@ Tyriar @ Stevencl Danke Jungs! :klatschen:

Vielen Dank an alle, die heute an den Sitzungen teilgenommen haben. Die Aufzeichnungen der Sitzungen wurden hier veröffentlicht

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

Bitte schauen Sie sich die Videos an und teilen Sie weitere Kommentare zu den Designs mit.

@stevencl danke, dass hast !

Tolle Videos, danke! Einige Rückmeldungen:

• 👍👍👍 für das insgesamt einfache Design und die natürliche Erweiterung der heutigen Funktionsweise von VSCode. Ihr habt auf einfache, elegante Weise mit vielen komplexen Situationen umgegangen. Ein großes Lob dafür!
• Ich mag die aggregierte SCM-Benachrichtigung in der unteren linken Ecke. Aus meiner Sicht ist keine Änderung erforderlich, mit einer Ausnahme: Ich würde das Popup überspringen, nachdem ich auf die SCM-Benachrichtigung geklickt habe, und direkt zum SCM-Bereich gehen. Weniger Klicks = immer besser für mich.
• Farbcodierung Wurzeln wie Alexey vorgeschlagen ist eine interessante Idee, könnte helfen.
• Suche: Das Scoping in einem Ordner wird mir wichtig sein. Ich denke, das aktuelle Feld "Zu enthaltende Dateien" könnte dafür verwendet werden. Ich wollte nur sicherstellen, dass dies der Fall ist.
• Das einzige, bei dem ich mir nicht sicher bin, ist die Beharrlichkeit und das Öffnen aller additionalFolders wenn ich die path öffne. Es macht irgendwie Sinn mit dem letzten Beispiel, in dem express-project eindeutig das "Master-Projekt" ist, aber ich bin mir nicht sicher über das vorherige Beispiel: express und express-plugin fühlten sich gleich an, wie echte Geschwister, und ich bin nicht sicher, ob ich erwarten würde, dass das Öffnen von express auch express-plugin öffnen würde.
  
  
  
  • In gewisser Weise scheint die Datenstruktur dahinter nur eine flache Liste von Pfaden zu sein, nicht ein "Pfad" und dann "zusätzliche Ordner".
  
  
  • Ich bin mir nicht sicher, ob das Konzept eines Masterpfads so nützlich ist. In meinen Projekten ist es wahrscheinlich nicht.
  
  
  • Um einen Arbeitsbereich mit mehreren Stammverzeichnissen zu öffnen, würde ich neben der aktuellen Datei> Ordner öffnen> einen Befehl der obersten Ebene wie _Datei> Arbeitsbereich öffnen_ erwarten.
  
  
  • Insgesamt bin ich mir da nicht sicher. Entschuldigung, ich habe keine konkreteren Vorschläge.
  
  

Nochmals vielen Dank, damit erhält VSCode neue Superkräfte 😄.

Danke, dass du die Videos geteilt hast. Ich möchte das Design "Ein Abschnitt pro Stammordner" unterstützen:

Zuerst hatte ich das andere (erhabene, textähnliche) Design erwartet, aber nachdem ich die Alternative "Ein Abschnitt pro Stammordner" gesehen hatte, wurde mir klar, dass dieser Ansatz die folgenden Vorteile hatte:

• Klare, eindeutige Unterscheidung und Trennung zwischen Ordnern (insbesondere wenn ich mehr als 2 oder 3 davon habe, was häufig der Fall ist, wenn ich andere Editoren und IDEs verwende)
• Erzwingt die Vorstellung, dass ein Stammordner ein separates (Unter-) Projekt ist
• Schneller Zugriff auf Unterprojektbefehle (wie "Neue Datei", "Aktualisieren" ... und möglicherweise in Zukunft mit der rechten Maustaste, um eine Aufgabe (z. B. "Neu erstellen") für dieses bestimmte Unterprojekt zu starten;))
• Wie von der 2. Gruppe erwähnt, ist es bei diesem Entwurf weniger wahrscheinlich, dass das Problem des Abschneidens von Ordnernamen auftritt

In Bezug auf das Konzept "Ein Abschnitt pro Stammordner" ... Ich bin mir wirklich nicht sicher, ob dies für mich und die meisten meiner Anwendungsfälle gut funktioniert. Immer wenn ich eine Situation mit mehreren Wurzeln habe, ist es üblich, dass ich viele habe . nicht nur 2 oder 3.
Ich bin nicht sicher, wie sich dieser Ansatz skalieren lässt.

Ein Argument für das aktuelle ordnerähnliche Layout ist auch, dass es mit der Anzeige eines Monorepo übereinstimmt. Vergleichen Sie zum Beispiel:

monorepo/      <- contains .git
  project1
  project2

vs.

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

Diese beiden sollten von VSCode wirklich ziemlich ähnlich behandelt werden: monorepo ist es bereits (Festschreiben: natürlich, Suche: "einzuschließende Dateien", mehrere READMEs: ihr Ordner wird auf der Registerkarte "Editor" angezeigt; usw.). Multi-Root sollte dies so genau wie möglich verfolgen, IMO, was das aktuelle Design sehr gut macht.

@stevencl Eine Sache, die ich nicht vollständig verstanden habe: Wird die Lösung eine begrenzte (oder sogar hierarchische) Behandlung von .vscode -Einstellungen ermöglichen? Wenn ich .vscode pro Ordner der obersten Ebene hätte, werden diese Einstellungen dann einzeln angewendet? Werden sie irgendwie am Projektstamm aggregiert? Oder zählt nur das "primäre" .vscode ?

Ich bevorzuge das Design "Ein Abschnitt pro Stammordner" aus den gleichen Gründen, die von @maddouri aufgeführt werden. Nachdem Sie die andere Alternative (in Atom) verwendet haben, ist es visuell schwieriger zu finden, wo ein neuer Stammordner beginnt, wenn mehrere hoch hierarchische Ordner geöffnet und erweitert werden.

Vielen Dank für die Design-Updates, es sieht wirklich gut aus!

Gibt es die Möglichkeit, mehrere Arbeitsbereiche gleichzeitig in der Benutzeroberfläche verfügbar zu haben? Damit Sie leicht zwischen ihnen wechseln können. Zum Beispiel haben Sie so etwas wie:

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

Wenn Sie dann auf den Teiler CONNECT, CONNECT-PLUGIN klicken / doppelklicken, wird dieser Teil zum aktiven Arbeitsbereich. Dies würde einen einfachen Wechsel zwischen Arbeitsbereichen für Personen ermöglichen, die sich mit mehreren Projekten befassen müssen. Ich schlage nicht vor, dass sie alle für die Suche und SCM verfügbar sind, und so weiter, das würde beim aktuellen Arbeitsbereich bleiben, der der derzeit erweiterte ist.

Dies könnte dann funktionieren, wenn die Stammordner wie in der ersten Gruppe vorgeschlagen hervorgehoben werden und möglicherweise die neuen Datei- / Ordnersymbole verfügbar sind, wenn Sie den Mauszeiger über diese Ordner bewegen.

Einige Rückmeldungen zu den Einstellungen JSON, möglicherweise ist es hilfreich, wenn die Einstellungen für den Arbeitsbereich wie folgt aussehen:

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

Dann wird das root zur Quelle für das Öffnen der Ordner und nicht des Pfads, aber das Stammverzeichnis selbst wird nicht geöffnet, sondern nur jeder Ordner. Sie haben dann keinen "primären Ordner", behalten aber die relativen Dateipfade bei. Dies setzt voraus, dass Sie einen vordefinierten Arbeitsbereich über die Benutzeroberfläche öffnen können, anstatt den Stammordner und alle zusätzlichen Ordner damit zu öffnen. Der Name kann dann als Teiler verwendet werden, um zu verhindern, dass eine große Anzahl von Ordnernamen zu lang oder nicht hilfreich verkürzt wird.

Wenn die Lösung "Ein Abschnitt pro Stammordner" ausgewählt ist, möchte ich vorschlagen, dass der aktuell sichtbare Stammordner oben in der Seitenleiste "haftet", anstatt aus der Ansicht nach oben zu scrollen. Es würde nur nach oben scrollen, wenn der nachfolgende Stammordner den oberen Rand der Seitenleiste erreicht hätte.

Am 4. Juni 2017, um 6:47 Uhr, schrieb Peter Petrov [email protected] :

Ich bevorzuge das Design "Ein Abschnitt pro Stammordner" aus den gleichen Gründen, die von @maddouri aufgeführt werden. Nachdem Sie die andere Alternative (in Atom) verwendet haben, ist es visuell schwieriger zu finden, wo ein neuer Stammordner beginnt, wenn mehrere hoch hierarchische Ordner geöffnet und erweitert werden.

- -
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

Oder wir können dem Sublime, Atom-Ansatz folgen, aber die Farbe ändern oder irgendwie zeigen, welcher Ordner das Stammverzeichnis ist, und / oder ihn oben anbringen. Natürlich sind beide Ansätze gut, aber viele geöffnete Ordner reduzieren den Speicherplatz, da Balken mit Aktualisierung, Erstellen einer neuen Datei usw. sichtbar sind. Deshalb ist es besser, keine Balken zu laden, sondern irgendwie anzuzeigen, welcher Ordner ist die Wurzel. ABER wieder ist diese Leiste wirklich gut, weil es viel einfacher ist, geöffnete Stammordner zu sehen und Sie sie aktualisieren und andere Dinge tun können, die in der Leiste enthalten sind. Wir müssen sehen, wie es aussieht, wenn beispielsweise 10 Ordner mit und ohne Balken geöffnet werden.

@stevencl Danke, dass du diese Aufnahmen

• Ich bevorzuge das erste Design mit dem Design der einzelnen Ordnernamenleiste unter "EXPLORER". Ich bin jedoch besorgt, dass wenn alle Ordnernamen dort aufgelistet sind, es sehr schnell abgeschnitten wird, um die "Datei hinzufügen" anzuzeigen. " Ordner hinzufügen "usw. Schaltflächen. Ich denke, ich würde einfach die Zeichenfolge "Multiple" oder ähnliches einfügen, wenn mehr als ein Ordner geöffnet ist. Andernfalls gibt es nur einen Ordner. Geben Sie den Namen des Ordners wie heute ein (und verstecken Sie das Ordnerstammverzeichnis im Baum).
• Die Disambiguierung von Dateinamen durch Anhängen des Ordnernamens an den Tabulatortitel im Editor, IMO, ist nur erforderlich, wenn mehrere Editoren mit demselben Dateinamen geöffnet sind. Beachten Sie, dass dieses Szenario auch bei geöffnetem Ordner nicht ungewöhnlich ist. Es ist ziemlich einfach, mehrere Dateien (z. B. .gitignore ) mit demselben Namen unter Unterordnern im selben Stammverzeichnis abzurufen. Daher sollte dieses Design (Anhängen des übergeordneten Ordnernamens) eine separate Funktion, IMO, sein und implementiert werden. Außerdem würde ich gerne eine gute Lösung für https://github.com/Microsoft/vscode/issues/15048 sehen, da dadurch einige Tab-Titel noch länger werden. :) :)
• Für Suchergebnisse ist es meiner Meinung nach wichtig, dass die Suche in allen Stammordnern funktioniert. Ein weiterer Filter könnte hinzugefügt werden, um die Suche auf ausgewählte Wurzeln zu beschränken. Bei der Anzeige von Ergebnissen kann es hilfreich sein, die Ergebnisse pro Stamm anzuzeigen. Daher besteht möglicherweise die Möglichkeit, eine lange Liste mit angehängten Stammordnernamen oder eine in Abschnitte getrennte Liste für jeden Stammordner anzuzeigen.
• Ich finde es seltsam, dass Sie vorschlagen, 'Arbeitsbereiche' zu den __Benutzereinstellungen__ hinzuzufügen. Ich habe wirklich erwartet, dass dies in __workspace settings__ endet. Ich denke, Sie sagen tatsächlich, dass die Arbeitsbereichseinstellungen auch die neue Eigenschaft 'Arbeitsbereiche' enthalten können, was gut ist. Es ist auch sehr gut, dass Arbeitsbereichspfade relativ sein können. Es scheint einfach überhaupt nicht in die Benutzereinstellungen zu gehören. Diese Funktion fühlt sich für Arbeitsbereiche sehr spezifisch an. Ah, aber jetzt verstehe ich, warum es auch in Benutzereinstellungen gültig ist, da ich diese Arbeitsbereiche speichern kann, wenn ich "zufällige" Ordner auf meiner Festplatte in einem Arbeitsbereich haben möchte, in dem es kein gemeinsames Stammverzeichnis gibt.
• Eine Sache, die in den Arbeitsbereichen verloren zu gehen scheint, wenn sie in Benutzereinstellungen gespeichert werden, ist die Möglichkeit, andere projektspezifische Einstellungen dem einen oder anderen Arbeitsbereich zuzuordnen. Wenn ich beispielsweise einen Arbeitsbereich hätte, in dem die Tabulatorgröße 2 Leerzeichen und in einem anderen 3 Leerzeichen betragen müsste, wäre dies mit Arbeitsbereichen in den Benutzereinstellungen nicht möglich. Ich müsste irgendwo einen Ordner erstellen und dann einen .vscode -Ordner darin ablegen und dann .vscode/settings.json definieren, um schließlich meinen Arbeitsbereich mit der entsprechenden Überschreibung der Registerkartengröße zu definieren. An dieser Stelle denke ich, dass das Erstellen eines neuen VSCode Project-Dateityps, in dem alle diese Einstellungen gespeichert sind und der als spezielle Datei geöffnet werden kann, weniger umständlich ist als das Erstellen dieser Ordnerhierarchie zum Speichern des Arbeitsbereichs settings.json file ...

Im ersten Entwurf kann für zusätzliche Ordner der Pfad (relativ oder absolut) in Klammern zur Unterscheidung an den Namen angehängt werden. Das wird eine einfache Lösung sein, denke ich.

@stevencl danke für die Aufzeichnung der Sitzungen. Ich wollte unbedingt teilnehmen, war aber zu diesem Zeitpunkt nicht verfügbar 😢

Mir hat die vorgeschlagene SCM-Schnittstelle gefallen. Mit einem Zusammenfassungsabschnitt und einem Abschnitt pro Ordner habe ich meiner Meinung nach eine viel einfachere Oberfläche, um die Änderungen zu erkennen und damit zu arbeiten. Und ich mag die Idee, ein konsistentes Verhalten in der gesamten Benutzeroberfläche zu haben, daher sollte die Idee " Ein Abschnitt pro Ordner" auch auf der Registerkarte " Suchen" verwendet werden , anstatt den Ordnernamen bei jedem Ergebnis zu verketten. Gleiches gilt für die Registerkarte Explorer .

Die Verwendung der Benutzereinstellungen zum Speichern des Mehrfachordners ist für mich etwas seltsam, da es sich anscheinend nicht um eine Benutzereinstellung handelt: smile:. Wenn Sie vermeiden möchten, neue Dateien zu erstellen und das Übertragen / Synchronisieren von Projekten / Arbeitsbereichen zwischen Computern zu vereinfachen, vergessen Sie nicht einfach die Benutzereinstellungen und machen den Eintrag additionalFolder immer Teil des Workspace Settings . Wenn Sie einen Ordner hinzufügen, wird dieser nur zu Workspace Settings hinzugefügt. Wenn Sie dann einen Ordner öffnen, suchen Sie einfach nach einer .vscode\settings.json -Datei und einem additionalFolders -Eintrag, um zu überprüfen, ob es sich um einen Arbeitsbereich mit mehreren Ordnern handelt. Es ähnelt dem zweiten Beispiel, das Sie verwendet haben, über die zwei fehlenden Git-Repos.

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

Unterstützen Sie außerdem _user-data_-Speicherorte wie ~ und $home , um die gemeinsame Nutzung von Projekten zwischen verschiedenen Computern / Plattformen zu vereinfachen.

Ich habe nur einen Punkt verpasst: API . Wie würden sich Erweiterungen damit integrieren?

Danke für die Bemühungen. Ich freue mich auf die ersten Insider-Veröffentlichungen 👍

Danke für die Rückmeldung! Ich wollte die Richtung verfolgen, in der eine neue Einstellungseigenschaft additionalFolders für die Implementierung von "Multi Root" genutzt wird, da ich aus den obigen Kommentaren einige Rückmeldungen dazu höre.

Die Hauptmotivation für die Einführung einer Umgebung besteht darin, die Dinge einfach zu halten und nicht zu viele neue Konzepte einzuführen, während dennoch eine leistungsstarke Lösung vorhanden ist, die einige interessante Szenarien ermöglicht. Hier sind einige Entwurfsentscheidungen und Konsequenzen:

Halte es einfach
Wir sind der Meinung, dass das Öffnen von Dateien und Ordnern das Kernstück von VS Code ist. Daher möchten wir kein neues Top-Level-Konzept für "Projekte" einführen. Wir würden beispielsweise nicht glauben, dass eine Aktion "Projekt öffnen" erforderlich ist, sondern dass ein Projekt immer ein Ordner ist und optional zusätzliche Ordner zugeordnet werden können. Mit dieser Annahme scheint eine Einstellung der natürliche Weg zu sein, dies zuzulassen. Wann immer Sie diesen Ordner öffnen, öffnen Sie die zusätzlichen Ordner damit. Das Hinzufügen und Entfernen von Ordnern ist eine einfache Geste und aktualisiert die Einstellungen direkt.

Einstellungen sind mächtig
Multi-Root als Einstellung ermöglicht viele interessante Szenarien. Sie können beispielsweise die Einstellung additionalFolders in Ihren Arbeitsbereich einfügen und diese als solche mit anderen Personen teilen (indem Sie relative Pfade verwenden - dies wird in den Videos gezeigt).
Darüber hinaus können Sie zunächst frei festlegen, wie Sie Projekte einrichten: In einigen Fällen besteht beispielsweise keine eindeutige Beziehung zwischen einem Hauptordner und zusätzlichen Ordnern (z. B. kann es sein, dass einige von ihnen nicht einmal in Beziehung stehen gegenseitig). In diesem Fall können Sie einfach einen "Projekt" -Ordner erstellen, der nur ein settings.json mit den Ordnern enthält, auf die er verweist:

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

Wenn Sie jetzt allMyRandomProjects öffnen, wird die Liste der Ordner angezeigt, die auf den Einstellungen basieren. Sie können sogar einige Einstellungen in settings.json einfügen, die für alle angezeigten Ordner gelten sollen.

Arbeitsbereichsumschaltung und mehrere Fenster
Ohne Zweifel müssen wir an einer besseren Umschaltung des Arbeitsbereichs und der Unterstützung mehrerer Fenster in VS Code arbeiten. Da wir einen Multi-Root-Arbeitsbereich wie jeden anderen Arbeitsbereich mit einem Ordner behandeln, kommt die Verbesserung der Arbeitsbereichsumschaltung und der Unterstützung mehrerer Fenster jedem Benutzer zugute, auch solchen, die keine Multi-Root-Arbeitsbereiche nutzen.
Wir müssen nach besseren und einfacheren Möglichkeiten suchen, um unabhängig von Multi-Root zwischen Ordnern und geöffneten Fenstern zu wechseln.

In meinem nächsten Kommentar werde ich einige Rückmeldungen zu einzelnen Kommentaren geben.

Die @ borkb- Suche würde Optionen zum Beschränken auf einen bestimmten Stammordner (oder mehrere) enthalten, genauso wie Sie die Suche so konfigurieren können, dass sie bereits heute einen bestimmten Pfad enthält.

@maddouri @TurkeyMan @pesho , @dgileadi @stefcameron Es scheint klar zu sein, dass einige Leute einen einzelnen Baum bevorzugen und andere mehrere Abschnitte im Explorer bevorzugen. Wir könnten also eine Einstellung dafür haben, es gibt Vor- und Nachteile für beide Lösungen und es sollte dem Benutzer überlassen bleiben, welche für das Szenario besser ist.

@borekb, wie Einstellungen update.channel: none nicht für jeden Ordner unterstützt werden. Was wir tun müssen, ist, Einstellungen zu identifizieren, die wir auf Ordnerebene unterstützen können (z. B. files.exclude , alle Editoreinstellungen) und die erforderlichen Änderungen vorzunehmen, um sie zu aktivieren. Dies ist einer der Hauptarbeitsbereiche, in die wir investieren müssen, zumal Erweiterungen auch Einstellungen definieren können, die wir für einen Bereich pro Ordner unterstützen möchten.

@BTMorton Es scheint mir, dass Sie einfachere Möglichkeiten zum

@stefcameron Wir werden die Einstellung additionalFolders offen genug halten, um eventuell zusätzliche Metadaten hinzuzufügen. Zum Beispiel könnte ich mir vorstellen, einen Namen für eine solche Konfiguration angeben zu können, damit der Wechsel zwischen Projekten nach Namen und nicht nach Hauptordner erfolgt.

Eine Sache, die wir in den Videos noch nicht angesprochen haben, ist, wie Erweiterungen Multi-Root-Ordner unterstützen können. Ein weiteres primäres Ziel mit Multi-Root-Unterstützung (neben "Keep it Simple") ist: Brechen Sie keine Erweiterungen

Heutzutage verfügen Erweiterungen über eine einfache API, um Zugriff auf den aktuell geöffneten Arbeitsbereich zu erhalten ( workspace.rootPath: string ). Diese Eigenschaft kann null falls kein Ordner geöffnet ist.

Mit der Einführung der Einstellung additionalFolders kann sich eine Erweiterung weiterhin darauf verlassen, dass die Eigenschaft workspace.rootPath festgelegt wird (wenn ein Ordner geöffnet ist) oder nicht (wenn kein Ordner geöffnet ist). Da additionalFolders tatsächlich eine Einstellung ist, kann eine Erweiterung diese Einstellung mit den APIs, die wir heute bereits für Einstellungen haben, kostenlos lesen und sogar schreiben. Wenn sich diese Einstellung ändert, wird sogar ein Ereignis ausgegeben, das eine dynamische Reaktion auf den Benutzer ermöglicht, der diese Einstellung ändert.

Durch Lesen dieser Einstellung kann eine Erweiterung auf zusätzliche Ordner im Arbeitsbereich aufmerksam gemacht werden. Beispielsweise könnte die Travis CI-Erweiterung einen aggregierten Status in allen Ordnern anzeigen.

Das Schreiben dieser Einstellung ermöglicht einige interessante Szenarien für Erweiterungen: Sie könnten beispielsweise eine Projektmanager-Erweiterung haben, die Ihrem Arbeitsbereich dynamisch Ordner hinzufügt und daraus entfernt und als solche Projektübergänge innerhalb des Fensters ermöglicht, z. B. indem eine Liste von Projekten über eine Auswahloberfläche angezeigt wird .

An einem Punkt werden wir wahrscheinlich eine echte neue Erweiterungs-API für Multi-Root-Ordner einführen. Es ist etwas seltsam, dies in einer Einstellung für Lese- / Schreib-Erweiterungen zu vergraben. Zu Beginn können Erweiterungen jedoch bereits die Einstellung additionalFolders , um sie nach Möglichkeit zu nutzen. Wir werden auch eng mit den Autoren von Erweiterungen zusammenarbeiten, um deren Szenarien zu verstehen und sie besser zu unterstützen.

@bpasero Wird das Konzept zusätzlicher Ordner auch zu LSP hinzugefügt, oder startet VS Code einfach einen Sprachserver pro zusätzlichem Ordner?

@felixfbecker Dies ist etwas, was wir noch investieren und erforschen müssen, um eine gute Lösung für Spracherweiterungen zu finden. Sobald wir über zusätzliche APIs für Erweiterungen nachdenken, müssen wir auch darüber nachdenken, was dies für den LSP bedeutet.

Es ist jedoch erwähnenswert, dass es bereits heute Situationen geben kann, in denen Benutzer eine Datei aus einem Ordner öffnen, der nicht als Arbeitsbereich geöffnet ist (z. B. Datei> Öffnen> somefile.xyz). Im Idealfall kann eine Spracherweiterung die gleichen Sprachfunktionen für eine solche Datei anzeigen, auch wenn der Ordner dieser Datei nicht geöffnet ist.

Am Anfang verhält sich das Öffnen einer Datei von einem der additionalFolders sehr ähnlich wie das Öffnen einer Datei, die sich nicht in dem Ordner befindet, den Sie ursprünglich geöffnet haben. TypeScript kann sich beispielsweise gut mit diesem Fall befassen: Sie gehen einfach von der aktuell geöffneten Datei auf, bis eine tsconfig.json -Datei gefunden wird, und behandeln diese dann als Projekt. Funktionen wie Referenzen finden funktionieren ohne Probleme:

Es wäre schön, wenn eine Spracherweiterung funktionieren könnte, indem Sie einfach von der aktuell aktiven Datei ausgehen, anstatt einen expliziten Projektkontext zu erzwingen.

@bpasero danke für die Kommentare. Es scheint also, dass es im aktuellen Modell immer einen "Master" -Ordner geben wird : Selbst im Beispiel allMyRandomProjects ist dies im Grunde der Master-Ordner, obwohl er größtenteils leer ist. Dies hat einige subtile Auswirkungen, aber ich muss noch etwas darüber nachdenken, um nützliches Feedback zu geben.

Insgesamt denke ich, dass VSCode Monorepo im Vergleich zu mehreren Repositorys auf ziemlich ähnliche Weise unterstützen sollte, wie im obigen Kommentar angegeben: https://github.com/Microsoft/vscode/issues/396#issuecomment -306040485.

Übrigens, wie definieren Sie "root" genau? Wenn ich Ordner A öffne, der die Unterordner B und C enthält, wie sehr unterscheidet er sich von der Definition von A als path und B und C als additionalFolders ? Ist die Absicht von VSCode, diese beiden Situationen ziemlich unterschiedlich oder grundsätzlich gleich zu behandeln? (Ich denke, es sollte eine sehr ähnliche Erfahrung sein.)

@bpasero

Am Anfang verhält sich das Öffnen einer Datei aus einem der zusätzlichen Ordner sehr ähnlich wie das Öffnen einer Datei, die sich nicht in dem Ordner befindet, den Sie ursprünglich geöffnet haben. TypeScript kann sich beispielsweise gut mit diesem Fall befassen: Sie gehen einfach von der aktuell geöffneten Datei auf, bis eine tsconfig.json-Datei gefunden wird, und behandeln diese dann als Projekt. Funktionen wie Referenzen finden funktionieren ohne Probleme:

TypeScript verwendet jedoch kein LSP. In LSP haben Sprachserver ein rootUri , und PHP verwendet dieses rootUri , um nach Dateien zu suchen, die indiziert werden müssen. Es gibt keine Datei wie tsconfig.json, die ein "Projekt" bezeichnen würde. Wenn es also Dateien gibt, die nicht über didOpen geöffnet werden, sondern auch nicht unter rootUri , werden diese für die Code-Intelligenz nicht berücksichtigt, daher meine Frage, ob LSP dafür erweitert wird.

Würde das Öffnen mehrerer Roots eine Datei ./.vscode/settings.json erstellen, wenn sie nicht bereits vorhanden wäre?
Nach dem, was ich hier bisher gelesen habe, sieht es so aus, als würden wir es sagen.

Ich verstehe, warum es nützlich ist, das Hinzufügen von Projektkonzepten zu vermeiden, aber vielleicht wäre es gut, das Speichern eines Arbeitsbereichs optional zu machen - obwohl in diesem Fall "Speichern" nur das Erstellen einer Einstellungsdatei im Stammordner bedeutet.

Ich denke, es könnte einen Benutzer überraschen, der diesem Thread nicht gefolgt ist, wenn er einen zweiten Ordner geöffnet und eine Einstellungsdatei erstellt hat. Das Öffnen von Ordnern ist die Art von Dingen, von denen ich glaube, dass die meisten Benutzer erwarten, dass sie schreibgeschützt sind.

Vielen Dank für das Feedback an alle, das ist sehr nützlich.

@saborrie - eine gute Frage, inwieweit die

@borekb - Wir haben über das von Ihnen erwähnte Szenario gesprochen (Öffnen eines Ordners, der einen oder mehrere Unterordner enthält), und wir haben versucht, dies genauso zu behandeln wie das Öffnen eines Multi-Root-Arbeitsbereichs. Die Herausforderung besteht jedoch darin, zu bestimmen, wann eine solche Situation als Multi-Root behandelt werden soll und nicht nur als Ordner, der andere Ordner enthält.

Mich würde auch interessieren, was andere darüber denken.

@borekb Sie additionalFolders Eigenschaft. Ich denke, wir können beginnen, diese UI-Entwicklung mit Ordnern zu untersuchen, für die die Einstellung additionalFolders festgelegt ist, und sie später auf weitere Anwendungsfälle erweitern. Ein weiteres interessantes und verwandtes Szenario ist die Art und Weise, wie wir Submodule in einem Repository präsentieren.

Ich würde auch denken, dass wir irgendwann .vscode -Einstellungen auf jeder Ebene der Ordnerhierarchie unterstützen möchten, sobald wir die damit verbundenen Herausforderungen gelöst haben.

Ich würde weniger über die Master-Detail-Beziehung sprechen, wenn ich über Multi-Root spreche, da die meisten UX-Dateien den Hauptordner gleich den zusätzlichen Ordnern behandeln. Der Hauptordner ist eigentlich nur der Container mit den Einstellungen für zusätzliche Ordner und wird der Haupttreiber für die globalen Arbeitsbereichseinstellungen sein. Aus Gründen der Abwärtskompatibilität wird dies auch als rootPath an Erweiterungen

@felixfbecker bedeutet das, dass ich beim Öffnen nur einer PHP-Datei meines Projekts keine "Referenzen Sprachfunktionen ausführen kann.

@saborrie Beim Hinzufügen von Ordnern wird standardmäßig KEINE Arbeitsbereichseinstellung hinzugefügt. Einer der Gründe, warum wir uns dazu entschließen, dies in die Benutzereinstellungen aufzunehmen, besteht darin, dass ein Arbeitsbereich beim Multi-Root-Setup nicht "schmutzig" wird. Das Einfügen dieser Einstellung in den Arbeitsbereich ist möglich, muss jedoch manuell erfolgen. Dies wird standardmäßig nicht geschehen.

@bpasero Ok, ja, das Festhalten am Speichern in Benutzereinstellungen anstelle von Arbeitsbereichseinstellungen würde das Verschmutzen der Arbeitsbereichsordner verhindern. Ich vermute, dass es immer noch gespeichert wird, bevor der Benutzer explizit eine Speicheraktion ausführen muss, obwohl ja?

Damit habe ich zwei Anschlussfragen:

1) Was würde passieren, wenn ein Benutzer einen Arbeitsbereich mit additionalFolders öffnet, der in seinen Arbeitsbereichseinstellungen definiert ist? Würde dies mit ihren Benutzereinstellungen synchronisiert werden? und würde es den Eintrag für diesen Arbeitsbereich-Stamm überschreiben, wenn er in der Arbeitsbereichsliste für Benutzereinstellungen vorhanden wäre? Oder umgekehrt?

2) Ist das Einfügen dieser Liste von Arbeitsbereichen in Benutzereinstellungen eine bessere Option, als zunächst das Speichern von Arbeitsbereichen in einer dieser JSON-Einstellungsdateien zu vermeiden? Wenn im aktuellen Einzelordnersystem ein Ordner File > Open Recent Menüpunkt

- Entschuldigung für das Englisch, ich habe Google Übersetzer verwendet -

Nun, ich habe das Layout durchgesehen (ja - ein wenig Schwierigkeiten beim Verstehen von Englisch). Dann bitte ich um Entschuldigung...

Das von @maddouri vorgestellte Layout hat mir nicht

Ich bevorzuge dieses Modell, bei dem ich mit den Pfeiltasten zwischen den verschiedenen Projektordnern navigieren kann. Wenn ich einen Ordner / eine Datei im Hauptordner erstellen muss, kann ich die Menütaste auf der Tastatur direkt im Hauptordner verwenden Mappe.

Und / oder mit den Optionen "Neue Datei", "Neue Ordneraktualisierung" und "Alle reduzieren".

Was den Titel betrifft, der oben angezeigt wird, bevorzuge ich, dass er sich auf die aktuelle Datei mit dem Ordner konzentriert, in dem er sich befindet, oder anstatt alle geöffneten Hauptordner plus die aktuelle Datei anzuzeigen, ähnlich wie in diesem Bild.

Und eine Frage: Wird es noch Open Editores geben?

@bpasero

Bedeutet das, dass ich beim Öffnen nur einer PHP-Datei meines Projekts keine "Referenzen suchen" oder ähnliche Sprachfunktionen ausführen kann. Ich muss diesen Ordner öffnen, um diese Funktionen zu erhalten. Ich bin nicht tief in PHP vertieft, aber wenn es ein Konzept für dateiübergreifende Abhängigkeiten gibt, kann ich nicht von einer einzigen Datei zu einer anderen PHP-Datei navigieren. Muss ich zuerst den Ordner öffnen?

Das ist richtig. Wenn Sie nur eine einzelne Datei öffnen, können Sie nicht zu einer Datei in einer anderen Datei wechseln, die nicht geöffnet ist, sondern nur zu Dateien unterhalb von rootUri . Das liegt daran, dass in PHP jede Datei Symbole im globalen Namespace ausgeben kann und Namespaces eigentlich nur Namenspräfixe für Klassen sind. Es gibt keine Einschränkung, wie Namespaces und Klassennamen Verzeichnissen und Dateinamen entsprechen müssen (nur einige Konventionen), und es gibt keine Importanweisungen wie in TS, nur Namespace-Aliase. Das Laden von Klassen erfolgt zur Laufzeit über registrierte "Autoloader". Das bedeutet, dass für einen Sprachserver mit Go-to-Definition ein Symbol in jeder Datei definiert werden kann. Der Sprachserver indiziert also beim Start alle Dateien in rootUri und arbeitet dann mit dem Index, um Anfragen zu beantworten. Was funktioniert, ist, wenn Sie ein Projekt geöffnet haben und eine neue nicht gespeicherte Datei erstellen - Sie erhalten Informationen dafür, weil Sie die rootUri und die neue Datei über textDocument/didOpen . Symbole, die in nicht geöffneten Dateien definiert sind, die nicht unter rootUri werden jedoch nicht berücksichtigt.

Die Arbeitsbereichseinstellungen von additionalFolders -Einstellung im Arbeitsbereich hat immer Vorrang. Aufgrund der Art dieser Einstellung können Sie die zusätzlichen Ordner für den aktuell geöffneten Ordner nur überschreiben, wenn diese Einstellung im Arbeitsbereich angegeben ist (dies wird in den Videos angezeigt, indem für den "Master" path: "." ).

Dies als UI-Status zu speichern, ähnlich wie z. B. wie viele Registerkarten geöffnet sind, war eine Option, die wir besprochen haben, aber wir haben nicht festgestellt, dass sie viele Vorteile gegenüber einer Einstellung hat. Einige Gründe:

• Dies ist nicht gemeinsam nutzbar (weder über die Arbeitsbereichseinstellung noch über eine Einstellungssynchronisierungserweiterung).
• Dies ist nicht etwas, auf das Erweiterungen heute leicht zugreifen können (Einstellungs-API existiert, UI-Status-API nicht)

Gibt es einen bestimmten Grund, warum Sie dies nicht in den Einstellungen wünschen würden?

@Tekbr ja, "Open Editors" funktioniert wie bisher

@felixfbecker Würde die PHP-Erweiterung so etwas wie rootUri: string[] leicht übernehmen können? Oder möchten Sie lieber, dass der PHP-Sprachserver für jeden geöffneten Ordner mehrmals gestartet wird (z. B. würde VS Code auf der Ebene der geöffneten Ordner zu N Sprachservern mehrere Plexe ausführen?)

@bpasero PHP könnte ganz einfach mit rootUris: string[] . Andere Sprachserver können dies jedoch nicht. Das Laichen mehrerer Sprachserver würde bedeuten, dass jeder Ordner isoliert funktioniert (kein Sprung zur Definition, alle Referenzen zwischen ihnen finden). Vielleicht wäre ein Ansatz ein neuer ServerCapability , der entscheidet, ob VS Code einen oder mehrere Sprachserver erzeugt.

Ich mag das Konzept der Einstellung für zusätzliche Ordner. Für mich reicht es, einen einzigen Stammordner zu haben. Wenn ich die volle Entwicklungsfunktionalität für ein zugehöriges Projekt möchte, kann ich ein neues vscode-Fenster öffnen.

Was ich von den zusätzlichen Ordnern benötige, ist nur eine eingeschränkte Funktionalität. Zum Beispiel möchte ich möglicherweise eine Symboldefinition aus einem zugeordneten Projekt zur Verwendung im Stammprojekt, benötige oder möchte jedoch nicht die Möglichkeit, sie umzubenennen oder alle Referenzen dafür im zusätzlichen Ordner zu finden.

@bpasero Ich befürworte nur, die Erstellung eines Arbeitsbereichs in den Einstellungen optional zu machen (und zu aktivieren). Anstatt Einstellungen automatisch zu ändern, wenn ein Benutzer einen Ordner hinzufügt, beginnen Sie im Wesentlichen nur im UI-Status und erlauben Sie den Benutzern, diese in irgendeiner Weise in den Einstellungen zu speichern. Möglicherweise können Sie auch auswählen, ob die Einstellungen für den Arbeitsbereich oder die Benutzereinstellungen vorgenommen werden sollen.

Ich bin nicht ganz dagegen, vollständig in Einstellungen zu speichern. Ich trage nur meinen Teil dazu bei, die Entscheidung in Frage zu stellen, den UI-Status nicht zu verwenden, nur für den Fall, dass er übersehen wurde.

@bpasero @saborrie Wenn wir diesen Weg gehen, würde ich hinzufügen, dass es bei Aufforderung zum Speichern in Einstellungen eine Option geben sollte, sich "an meine Wahl zu erinnern" (um Arbeitsbereiche in Einstellungen zu speichern, entweder Benutzereinstellungen oder Projekteinstellungen). Ich wäre enttäuscht, ein VSCode-Fenster zu öffnen, ein paar Ordner zu laden, alles so zu machen, wie ich es möchte, und dann tritt entweder ein Neustart oder ein Absturz auf, und ich habe meine gesamte Konfiguration für diese Kombination von Ordnern verloren, weil der Arbeitsbereich nie gespeichert wurde auf die Festplatte.

# 396 (Kommentar)

@Tekbr ja, "Open Editors" funktioniert wie bisher

Danke für die Antwort, @bpasero.

TL; DR: Verwenden Sie eine Baumansicht, wann immer dies sinnvoll ist, anstatt den Namen der Wurzeln an jedes Element anzuhängen.

Einige Dinge, ich mag es wirklich nicht, wie Sie den Ordner an das Ende anhängen. Ich möchte wirklich, dass es eine Option ist, weil ich es wahrscheinlich so haben möchte: express\.editorconfig und express-plugin\.editorconfig also Vielleicht können Sie die folgende Option anbieten: editor.tabName: "${root}\${filename}"

Eine andere Sache, die ich gerne hätte und die Sie im Video erwähnen, ist die Färbung über den Wurzeln, um sie an die Registerkarten anzupassen.

Suche:

In der Search -Ansicht würde ich tatsächlich denken, dass Sie einen Fehler machen, was die Erfahrung betrifft. Meiner Meinung nach sollte er als Baum angezeigt werden, wie folgt:

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

Die Gründe dafür sind:

1. Sie können leicht sehen, wo sich die Dateien befinden, unabhängig von der Länge ihrer Namen.

2. Sie können die Wurzeln kollabieren, die Sie nicht sehen möchten.

Ich denke, dass es auch mehr zu der Art von Design passt, die Sie auf die Explorer angewendet haben.

Aufgaben:

Für Tasks hätte ich lieber diese Art von Ansicht:

express
    Compile
    Run Tests
express-plugin
    Compile
    Run Tests

Einige Punkte:

1. Meiner Meinung nach sollten Sie die Ordnernamen nicht berühren / ändern, was bedeutet, dass "Express-Plugin" genau so angezeigt werden sollte, wie es im Explorer angezeigt wird, und nicht als "Express Plugin".

2. Das Wechseln zwischen Aufgaben mit der Tastatur kann auch so erfolgen, dass die Auswahl der Wurzeln ignoriert wird. Wenn Sie also im Beispiel von express\"Run Tests" nach unten wechseln, wird als nächstes express-plugin\Compile as ausgewählt im Gegensatz zu express-plugin

ps Ich habe das ganze Video noch nicht gesehen, aber nur diese Dinge, die mir in den Sinn kamen.

Was ist, wenn alle Stammordner, die Sie in Ihren Arbeitsbereich aufnehmen, denselben Namen haben?
z.B

• / dev / project / public / src
• / dev / framework / src
• / dev / some-component / src

Sie hätten dann einen Arbeitsbereich mit:

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

Gemäß der _sublime_ Methode zum Einfügen von Ordnern in einen Arbeitsbereich verfügt jeder virtuelle Ordnerstamm über:

• Pfad
• Name (optional) - Dies ist der Name des Ordners, falls ausgeschlossen, kann aber als beliebig angezeigt werden
• Ausschlussfilter für Dateien / Ordner

Im Hinweis https://github.com/Microsoft/vscode/issues/396#issuecomment -283541760 (oben) finden Sie beispielsweise die Metadaten, die mit dieser Vorgehensweise verbunden sind.

Ich möchte wissen, dass sich diese Funktion noch in der Entwicklungsphase befindet.

@ifzm Es ist und wenn Sie die neuesten Versionshinweise (Mai 2017 (Version 1.13)) lesen, wissen Sie, dass sie aktiv daran arbeiten.

@eyalsk Entschuldigung, ich habe nicht genau

Ich bin nicht verrückt nach dem additionalFolders -Konzept, obwohl ich den Wunsch verstehe, die Dinge einfach zu halten.

Es scheint mir seltsam, dass in einem Ordner die Konfiguration des "Arbeitsbereichs" gespeichert wird.

Stellen Sie sich folgende Stammordner vor:

• Webseite
• api
• Handy, Mobiltelefon

... welcher Ordner sollte die Einstellung additionalFolders ? Warum?

Ich bevorzuge die Idee eines Arbeitsbereichs / Projektmanagers, in dem die Einstellungen an einem gemeinsamen / allgemeinen Ort gespeichert werden. Ich denke wirklich nicht, dass dies aus UX-Sicht kompliziert ist und die vorhandene workspace -Terminologie wiederverwendet / erweitert werden könnte.

Unabhängig: Ich stimme den Kommentaren von @eyalsk in Bezug auf verschachtelte Listen (und die Benennung von Registerkarten) voll und ganz zu.

@ glen-84 In diesem Fall steht es Ihnen frei, einen vierten Ordner auf der Festplatte mit dem Namen "my-mobile-website-project" zu haben, der diese Einstellung und Links zu allen anderen Ordnern enthält.

@bpasero Ich verstehe das, aber es ist wirklich nur ein Hack.

Um näher darauf einzugehen:

Ich arbeite gerade an den website und entscheide, dass ich einige Änderungen an den api vornehmen möchte. Wenn ich auf Add Folder klicke, werden die api mit den website verknüpft, sodass das Öffnen der website in Zukunft die api öffnet auch. Ich muss verstehen, wie dies funktioniert, und wenn ich dies tue, muss ich eine separate Instanz von VSC öffnen, einen leeren Ordner mit dem entsprechenden Namen erstellen, beide "Projekt" -Ordner hinzufügen und dann die ursprüngliche Instanz schließen.

Im Gegensatz dazu könnte ich einfach Add Folder und (optional) nach einem Arbeitsbereichsnamen fragen, der in Zukunft zum gleichzeitigen Öffnen beider Ordner verwendet werden soll.

workspaces.json (Beispiel)

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

Ich fühle mich einfach flexibler und weniger unangenehm für mich.

@ Glen-84 verstanden. Wenn Sie sich für Ihre vorgeschlagene Lösung entscheiden, wird die Verwendung von VS-Code komplexer. Deshalb haben wir uns gegen ein solches Konzept entschieden. Der Hauptgrund ist, dass es plötzlich nicht nur "Open File" und "Open Folder" gibt, sondern auch "Open Project". Bei den Grundelementen zu bleiben, die wir haben, ist der einfachere Ansatz, ohne neue Konzepte einzuführen.

Die gesamte Arbeit, die wir jetzt zur Unterstützung mehrerer Ordner leisten, ist jedoch auch für Szenarien wie die von Ihnen vorgeschlagene eine gute Arbeit. Wenn wir Ihr Szenario jemals unterstützen möchten, sind die Schritte, um dorthin zu gelangen, viel weniger schwer, da die Benutzeroberfläche bereits dafür geeignet ist. Ich könnte mir auch vorstellen, dass eine Erweiterung möglicherweise einen solchen Begriff von Arbeitsbereichen einführt, und wir fügen einfach die erforderlichen APIs hinzu, um dies zu unterstützen.

Lassen Sie uns zuerst die UX richtig machen, ohne neue Konzepte einzuführen, und dann über andere Szenarien rund um mehrere Ordner nachdenken. Zuerst müssen viele Dinge beachtet werden (Erweiterungen, Einstellungen, SCM-Benutzeroberfläche usw.).

Ihre vorgeschlagene Lösung macht die Verwendung von VS-Code komplexer

Dem muss ich nicht zustimmen. Wenn ein Benutzer durch eine optionale Funktion "Projekt öffnen" (oder Arbeitsbereich) verwirrt ist, wird er wahrscheinlich durch viele vorhandene Funktionen in VSCode verwirrt. Dies ist aus Anwendersicht nicht kompliziert (wenn jemand, der dies liest, anderer Meinung ist, sagen Sie es bitte).

Ich könnte mir auch vorstellen, dass eine Erweiterung möglicherweise einen solchen Begriff von Arbeitsbereichen einführt, und wir fügen einfach die erforderlichen APIs hinzu, um dies zu unterstützen.

Die Erweiterung existiert bereits und wurde bereits einige Male erwähnt. Der Autor hat sogar eine offene Ticketverfolgung für mehrere Ordner. Diese Erweiterung verfügt über mehr als 370.000 Installationen und eine Bewertung von 4,7. Selbst bei einer vereinfachten Benutzeroberfläche, die die Befehlspalette verwendet, gibt es nach den Kommentaren kaum Anzeichen von Verwirrung.

Lassen Sie uns zuerst die UX richtig machen, ohne neue Konzepte einzuführen, und dann über andere Szenarien rund um mehrere Ordner nachdenken

Das ist gerecht genug. In beiden Fällen geht es darum, mehrere Stammordner in demselben Fenster zu unterstützen. Die eigentliche Methode zum Verwalten dieser Ordnergruppen könnte zu einem späteren Zeitpunkt in Angriff genommen werden.

Würden Sie eine öffentliche Umfrage erstellen, um Meinungen von Nutzern zu diesem Thema zu sammeln (mir sind die YouTube-Videos bekannt, aber ich beziehe mich allein auf diesen Aspekt), oder wurde bereits die Entscheidung getroffen, sich für das additionalFolders Konzept?

Ich stimme @ glen-84 zu. Ich verstehe das Problem der Komplexität nicht. Ja, es kann es komplexer machen, aber dies ist ein Code-Editor. Ich würde denken, dass 95% der Programmierer es verwenden, was die Idee von Projekten leicht verstehen könnte. Es sollte wenig Bedenken geben, jeden Tag Menschen zu verwirren, weil die Menschen es nicht jeden Tag benutzen.

Während eine Erweiterung eher eine Lösung darstellt, sind Erweiterungen im Vergleich zu nativ implementierten Erweiterungen ebenfalls zweitklassig (dh es können keine Optionen zu den Menüs hinzugefügt werden, nur die Befehlspalette usw.).

@ glen-84 Die Entscheidung wurde getroffen, um die Einstellung additionalFolders wählen, basierend auf der Stimmung im Entwicklungsteam, den von uns durchgeführten Benutzerstudien (diese 2 Videos) und dem Feedback, das wir in dieser Ausgabe erhalten haben.

@pltrant macht die Verwendung von Multi Root komplexer, da Sie ständig darüber nachdenken müssen, einen Ordner oder ein Projekt zu öffnen. Dinge wie "Open Recent" erfordern plötzlich mehr Aufmerksamkeit, wenn der ausgewählte Eintrag ein Ordner oder ein Projekt ist, oder schlimmer noch, Sie hätten sogar zwei Auswahlmöglichkeiten und müssten sich entscheiden, welche Sie verwenden möchten.

Ich bin mir nicht sicher, wie komplex eine Einstellung ist. Grundsätzlich müssen Sie sich nicht um die Einstellung kümmern, sondern fügen einfach Ordner zu Ihrem Setup hinzu und entfernen sie. Die Einstellung wird im Hintergrund aktualisiert. Ich würde argumentieren, dass Sie in den meisten Fällen nie den Wert dieser Einstellung betrachten.

@ glen-84 In Bezug auf Ihr Beispiel eines Projekts mit 3 Ordnern gleicher Wichtigkeit denke ich, welcher die additionalFolders -Einstellungen enthalten sollte, sollte von der Abhängigkeit entschieden werden. Wenn der API- Ordner beim Öffnen nicht von einem anderen Projekt abhängig ist, sollte er als einzelner Ordner geöffnet werden und keine zusätzlichen Ordnereinstellungen enthalten. Aber wenn Sie den mobilen Ordner öffnen, hängt er vermutlich vom API-Ordner ab. Sie fügen also die Einstellungen im mobilen Ordner zum Öffnen der API als zusätzlichen Ordner hinzu, wenn Sie in vscode geöffnet werden. Gleiches gilt für die Website. Wenn es von der API abhängt, fügen Sie dort Einstellungen hinzu. Wenn nicht, sind keine Einstellungen erforderlich.

Ich denke nicht, dass es rekursive oder kaskadierende zusätzliche Ordneröffnungen geben wird. Ich mag auch die Idee, dass Erweiterungen andere Projektformate wie Visual Studio Solutions lesen und zusätzliche Ordnereinstellungen vorschlagen / einfügen. Und Sie können jederzeit den gemeinsamen übergeordneten Ordner aller öffnen.

@stevencl hat beide Videos gesehen.

1. Alternative 2 mit der Begriffsklärung scheint am klarsten zu sein. Es scheint, dass dies zusammenklappbar sein könnte (dh eine der Wurzeln im Baum), wodurch viele Projekte gleichzeitig gesehen werden könnten. Wenn Sie ein Modell benötigen, lassen Sie es mich wissen.

2. Alternative 2 ist aus Sicht der Bildschirmimmobilien effizienter. Sie werden nicht die gleichen Informationen (Name des Projekts) oben wiederholen lassen - wie in Option 1 und dann im Stammverzeichnis jedes Projekts angezeigt.

3. Suchergebnisse und Git können sich genauso verhalten ... wie ein zusammenklappbarer Baum. Die Ergebnisse würden (entlang des Status) unter der entsprechenden Überschrift zusammengefasst. Ich denke, wenn Sie eine navigierbare Zusammenfassung wünschen (wie Sie für GIT gezeigt haben, wäre dies eine Option, die für die Suche (wie viele Dateien Sie gefunden haben) und den Projektbereich (hier könnten die Aktionsschaltflächen enthalten sein) vorhanden sein könnte.

Zusammenfassend bin ich also ein Fan der einzelnen zusammenklappbaren Wurzeln mit der möglichen Hinzufügung der navigierbaren Zusammenfassung. Eine Art Kombination aus Alternative 2 und diesem Beispiel

Ich hoffe, dass Sie, was auch immer Sie wählen, die Erfahrung über die verschiedenen Mechanismen hinweg ähnlich machen. Sie sagen, dass es zwei Alternativen gab, aber es gibt wirklich 4, da GIT und Search beide unterschiedlich waren. Ich stimme dem zu, der diesen Kommentar abgegeben hat

Betreff: Weitergabe der Multiprojektinformationen. Ich denke, es wäre nützlich - wie Sie es haben, wäre zunächst vernünftig - ich würde dafür sorgen, dass nur Schluckaufgaben verwendet werden - oder Aufgaben, die VS Code verstehen könnte.

Vielen Dank für all Ihre Bemühungen.

Die Implementierung des Multi-Root-Arbeitsbereichs wird unter # 28344 und in diesem Juni-Meilenstein verfolgt.

@ Gulshan ,

Es kann Fälle geben, in denen keine Abhängigkeiten bestehen. Zum Beispiel, wenn ich an website arbeite und beschließe, mobile hinzuzufügen, um gleichzeitig daran zu arbeiten. Es gibt keine Abhängigkeiten zwischen den beiden, aber jetzt wird website zum "Elternteil". Wenn ich zufällig auf zu arbeiten mobile zuerst, dann wäre es die Eltern geworden. Es ist nur ein bisschen willkürlich. Die Ordner können auch für völlig unabhängige Projekte sein.

Unabhängig davon respektiere ich die Entscheidung der VSC-Entwickler, auch wenn ich nicht unbedingt damit einverstanden bin.

Vielen Dank für alle weiteren Kommentare. Wie oben erwähnt, verfolgen wir die Arbeit in Ausgabe Nr. 28344. Wir werden diese Kommentare berücksichtigen, während wir weiter daran arbeiten, insbesondere bei der Gestaltung der SCM-Erfahrung. Wie in den Videos besprochen und wie bereits mehrfach erwähnt, möchten wir während der gesamten Erfahrung Konsistenz erreichen.

In Bezug auf das Komplexitätsproblem, das @ glen-84, @pltrant und andere vielen Dank für die detaillierten Vorschläge und Antworten. Wir verstehen das Feedback und werden es weiterhin überwachen, während wir an der Funktion arbeiten.

Die Diskussion darüber war sehr hilfreich und hat uns einige Denkanstöße für unser aktuelles Design gegeben. Vielleicht sollten wir beispielsweise in Betracht ziehen, Benutzern die Auswahl des primären Ordners zu ermöglichen, wenn sie einem Arbeitsbereich einen zweiten Ordner hinzufügen. Vielleicht werden wir dazu aufgefordert, wenn der Arbeitsbereich geschlossen ist, vielleicht ist es eine Einstellung. Viele Dinge, über die wir nachdenken müssen, um die Erfahrung zu optimieren.

Wie @bpasero jedoch erwähnt, zögern wir immer sehr, VS Code um neue Konzepte (z. B. Projekte) zu erweitern. Das liegt nicht daran, dass wir glauben, dass VS Code dadurch unbrauchbar wird, sondern vielmehr daran, dass zusätzliche Konzepte das Gewicht oder die Stärke von VS Code erhöhen und ihn komplexer wirken lassen. Solche Konzepte wären etwas anderes, dem Entwickler mentale Ressourcen widmen müssen.

Sobald sich etwas in VS Code befindet, ist es außerdem viel schwieriger, es herauszunehmen (mit der Zeit gewöhnen sich die Leute daran und sind darauf angewiesen). Daher verbringen wir viel Zeit damit, sorgfältig zu überlegen, was wir zu VS Code hinzufügen, und fügen nur dann etwas hinzu, wenn wir sicher sind, dass sich die Kosten für das Hinzufügen neuer Konzepte lohnen werden. Im Moment wollen wir also herausfinden, wie erfolgreich ein Design für Multi-Root sein kann, das keine neuen Konzepte hinzufügt.

Nochmals vielen Dank für das unglaublich wertvolle Feedback. Ohne einen solchen Dialog wäre es viel schwieriger, diese Erfahrung zu gestalten.

Genial, wie nachdenklich und reaktionsschnell Sie alle im Team sind. es wird wirklich geschätzt!

Was in Bezug auf die Komplexität wahrscheinlich noch nicht gesagt wurde, ist, dass Sie sowieso einige hinzufügen. Ich denke, diese beiden Optionen werden derzeit diskutiert:

1. Explizite Projekte.
2. Etwas, das wie mehrere Ordner aussieht, es aber nicht ist - es gibt ein wichtiges Konzept eines primären Ordners, das Dinge wie rootUrl für Erweiterungen und möglicherweise andere Dinge betrifft (z. B. Vererbung von Arbeitsbereichseinstellungen). Ich denke, dass VSCode-Benutzer dieses Konzept normalerweise verstehen müssen und es möglicherweise einfacher ist, klar und offen darüber zu sein, als zu versuchen, es zu abstrahieren.

Eigentlich würde ich den dritten Weg bevorzugen, wirklich nichts Neues einführen, nur Dinge wie mehrere .git Repos und Suchvorgänge und Aufgaben und solche Dinge auf transparente Weise behandeln - so wie in den ersten zwei Dritteln der Videos vorgeschlagen (ich mochte die Drahtgitter sehr). Dann wurde mir jedoch klar, dass rootUrl für Erweiterungen berücksichtigt werden muss, was wahrscheinlich der Hauptgrund ist, warum dies kompliziert ist.

Wenn es nicht rootUrl gäbe, würde ich einfach mit UI-Updates beginnen, wie in den Wireframes vorgeschlagen, plus lokaler Persistenz des Multi-Root-Arbeitsbereichs, genauso wie alle anderen Ordner in "Zuletzt geöffnet" beibehalten werden.

Ich möchte wiederholen, dass aus meiner Sicht der ideale Zustand darin besteht, dass VSCode mit mehreren Ordnern arbeitet, unabhängig davon, ob es sich um SCM-Roots handelt oder nicht (Monorepo vs. mehrere Repos, siehe oben). Ich glaube, dass die vorgeschlagenen Wireframes und einige zusätzliche Kernaufgaben wie das Erben von .vscode -Einstellungen für "v1" der Multi-Root-Unterstützung ausreichen würden. "Projekte" oder "primäre + zusätzliche Ordner" könnten später kommen, IMO. Was ich jedoch sage, könnte mit rootUrl , da bin ich mir nicht sicher, ich möchte nur meine allgemeine Meinung dazu vermitteln.

Es ist großartig, dass Sie versuchen, dieses schwierige Problem zu lösen und die Einfachheit so weit wie möglich beizubehalten!

Ich habe ein Backend- und Frontend-Knotenprojekt und 2 VisualCode-Editoren geöffnet, was eine erhebliche Ressourcenbelastung darstellt.

Ich habe mir beide Videos angesehen und stimme dem obigen Kommentar zu, dass diese mehreren Projekte nichts miteinander zu tun haben müssen. Vielleicht könnte eines ein NodeJS-Projekt sein, während das andere C ++ ist.

Die Idee, dass eines der Projekte zum "Master" -Projekt wird, mit den zusätzlichen Projekten, hat mir nicht gefallen. Jedes Projekt sollte gleich und unabhängig sein.

Ich hätte erwartet, einen Ordner öffnen und dann einen anderen Ordner öffnen zu können (nicht ADD). Der Ordner wird einfach wie in Video 1 hinzugefügt, wobei die Roots nur angezeigt werden (wenn Sie den Mauszeiger über den Root-Ordner bewegen, werden jedoch die vollständigen Pfade in einem Tooltip angezeigt). Diese Projekte wären völlig unabhängig. Die Auswahl des einen oder anderen würde einen Kontextwechsel verursachen. Es wäre, als würde ich zwischen zwei Instanzen von Visual Code wechseln, beiden Einstellungen, Farbschemata und was nicht.

Die Möglichkeit, diese mehreren Projekte beizubehalten, besteht darin, diese als neue Projektdatei zu speichern, die auf die beiden anderen Projekte verweist, ohne jedoch eines der beiden Projekte selbst zu ändern. Mit anderen Worten, die beiden Projekte bleiben unabhängig, autark und kennen das dritte Projekt (Einstellungsdatei), auf das sie verweisen, nicht.

Sobald diese dritte Datei gespeichert / erstellt wurde, sollte es möglich sein, Einstellungen zu erstellen, die Einstellungen aus Projekt A und B überschreiben. Nicht erstellte Einstellungen hängen wieder vom aktiven Projekt ab.

Wenn Sie das Projekt freigeben, können Sie die Projektdatei freigeben, die auf die beiden anderen verweist. Wenn sie im Dateisystem fehlen, aber einen Verweis auf ihre Github-URLs enthalten, sollte der Benutzer gefragt werden, ob er sie abrufen möchte (standardmäßig als Unterordner im Stammverzeichnis dieser Master-Projektdatei, der Benutzer kann jedoch nach einem gewünschten Ordner suchen Ort für jeden).

Die Möglichkeit, über mehrere Projekte hinweg zu suchen, sollte optional sein, und die Möglichkeit, mehrere Projekte gleichzeitig auszuführen und zu debuggen, wäre sehr nützlich, scheint jedoch für eine erste Version wirklich zu komplex zu sein, und möglicherweise sollte für einen solchen Anwendungsfall ohnehin die Ausführung von 2 Instanzen erforderlich sein. Zumindest für jetzt.

Wie dies in der Benutzeroberfläche aussehen sollte, ist Schritt zwei, aber funktionell würde ich erwarten, dass es so funktioniert. Ich mag die Idee nicht, entweder Projekt A zu Referenz B zu modifizieren oder umgekehrt, und das war genau die Absicht, die ich verstanden habe. Für Agile Developent wäre ich nur froh, wenn ich an 2 Projekten in einem Fenster arbeiten könnte, anstatt 2 Instanzen ausführen zu müssen, aber vorerst nicht mehr. Vielleicht nicht einmal mit der 3. überschreibenden Projektdatei, sondern nur mit Kontextwechsel.

Vielen Dank für das fortgesetzte Feedback. Es gibt ein bestimmtes Thema, wie die Persistenz eines Arbeitsbereichs mit mehreren Ordnern bis zu einer expliziten Aktion des Benutzers (z. B. Speichern) verzögert werden kann. Wir müssen mehr darüber nachdenken und weiter nachforschen.

Ich würde den Entwicklern auch vorschlagen, sich Eclipse IDE anzuschauen
handhabt diese Funktionalität, sie haben es vor langer Zeit herausgefunden und es funktioniert
großartig.

Am Dienstag, den 13. Juni 2017 um 9:11 Uhr meldete Steven Clarke [email protected]
schrieb:

Vielen Dank für das fortgesetzte Feedback. Es gibt ein bestimmtes Thema
Verzögern der Persistenz eines Arbeitsbereichs mit mehreren Ordnern bis zu einem expliziten
Aktion des Benutzers (z. B. Speichern). Wir müssen mehr darüber nachdenken
und weiter untersuchen.

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/Microsoft/vscode/issues/396#issuecomment-308110390 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AAQsBWywBoe2KQRGuXKHv179MmugstCfks5sDop7gaJpZM4Gm3nX
.

- -
Daniel Sokolowski
Technischer Architekt

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

Vertraulichkeitserklärung:
Die übermittelten Informationen sind nur für die Person oder Organisation bestimmt
welche es angesprochen wird und vertraulich und / oder privilegiert enthalten kann
Material. Jegliche Überprüfung der Weiterverbreitung oder sonstigen Verwendung von oder
Ergreifen von Maßnahmen in Abhängigkeit von diesen Informationen durch Personen oder
andere Stellen als der beabsichtigte Empfänger sind verboten. Wenn Sie erhalten haben
In diesem Fall wenden Sie sich bitte umgehend elektronisch an den Absender
Übertragung und löschen Sie dann sofort diese Übertragung einschließlich aller
Anhänge ohne Kopieren, Verteilen oder Offenlegen.

Masterprojekt
Ich bin gegen ein MASTER-Projekt. Kontextwechsel treten häufig auf, wenn mit verschiedenen Mikrodiensten gearbeitet wird. Dies gilt für die folgenden Punkte zu Flusen und SCM.

Persistenz des Arbeitsbereichs
Ich denke, dass wir bei der ersten Iteration den Arbeitsbereich nicht beibehalten müssen. Ich würde Iterationen für ein oder zwei Releases für diese Funktion bevorzugen, bevor wir Einstellungen oder Persistenzschichten einführen, um komplexe oder destruktive Migrationen zu minimieren.

Flusen / Einstellungen
Projektspezifisches Flusen sollte in Dateien in den entsprechenden Verzeichnissen benannt werden. Zum Beispiel verwendet Projekt A hübscher, während Projekt B Standard verwendet. Das Wechseln zwischen beiden Kontexten sollte nahtlos sein, ohne dass sich die Regeln widersprechen.

Suche
Liebte einige der Wireframes für dieses, bei denen die Suchergebnisse über alle Projekte verteilt und nach Projekten sortiert waren.

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

_Project B_
file3: matched substring
file4: matched substring

SCM
In diesem Fall neige ich eher dazu, mit jeder scm-Änderung eine Aufschlüsselung nach Projekten anzuzeigen.

_Project A_
file1: added
file2: removed
...

_Project B_
file3: moved
file4: added
file5: added

Ich denke, diese Ansätze sind transparenter und intuitiver.

Der Konsens (basierend auf jüngsten Kommentaren und anderen Themen) scheint zumindest in der ersten Version gegen die Idee von additionalFolders zu sein .

Obwohl ich verstehe, dass die Entscheidung bereits getroffen wurde, würden Sie in Betracht ziehen, diese Funktion als eine Reihe von APIs zu implementieren, während Sie die Persistenz für eine spätere Iteration belassen? APIs zum Hinzufügen / Öffnen von Ordnern und Aktualisierungen des Explorers, der Suche, der Aufgaben und der SCM-Ansichten, um dies zu unterstützen.

Sie haben darüber gesprochen, wie schwierig es ist, etwas aus dem Produkt zu entfernen (wenn ein Projekt- / Arbeitsbereichskonzept irgendwie fehlgeschlagen ist), aber die Realität ist, dass dies gleichermaßen (wenn nicht mehr) für das additionalFolders -Konzept gilt.

Wenn Sie sowohl additionalFolders als auch "Projekte / Arbeitsbereiche" als Erweiterungen implementieren, können Sie Nutzungsdaten erfassen, ohne sich auf ein einzelnes Modell festlegen zu müssen. Eine dieser Erweiterungen (oder eine Hybridlösung) könnte später in das Produkt integriert werden.

Wurden die Probleme mit der Umgebung unter Mac OS behoben? Ich bin immer noch nicht in der Lage, Homebrew npm und dergleichen zu verwenden, ohne VSCode über die Befehlszeile über code zu öffnen, und dies wird sicherlich Chaos mit Multi-Root-Unterstützung bringen?

Ja, das ist auch für mich ein Muss. Ich verstehe die Probleme der Leute damit nicht. Es ist möglicherweise nicht die Art und Weise, wie eine Person arbeitet, aber das bedeutet nicht, dass die bevorzugte Arbeitsbereichsverwaltung einer anderen Person weniger gültig ist. Ich hasse nur die Antworten von "Warum willst du das tun?" statt "Lassen Sie uns herausfinden, wie Sie eine Funktion hinzufügen können, die jeder andere Code-Editor auf der Welt hat."

Zurück zu Atom, denke ich.

@saborrie https://github.com/Microsoft/vscode/issues/24961 (Ich habe das gleiche Problem sowohl bei Insidern als auch bei regulären Versionen). Wenn ich beim Debuggen helfen kann, bin ich ein Spiel.

@akutz Diese Leute haben sich sehr viel Mühe gegeben, ein anständiges Multi-Root-System zu entwerfen. Sie haben sogar Videos ihrer Design-Sessions erstellt (es war in den neuesten Versionshinweisen). Es kommt, aber sie stellen sicher, dass sie es richtig machen :-) (https://code.visualstudio.com/updates/v1_13)

Hallo @cliffrowley ,

Gut zu hören. Ich habe mir VSCode erst kürzlich noch einmal angesehen, da ich Atom schon immer verwendet habe (und Sublime zuvor). Vor kurzem war Atom problematisch und in einem Reddit-Thread habe ich gesehen, dass VSCode heutzutage wirklich eine großartige Option ist. Daher war ich überrascht, dass es keine Grundfunktion unterstützt.

Ich staple mich hier an - dies ist wirklich die einzige Funktion, die mich davon abhält, ganztägig von IntelliJ / WebStorm auf VSCode umzusteigen ... hauptsächlich, weil ich, wie bereits erwähnt, den ganzen Tag mit verteilten Architekturen arbeite und mehrere integrierte Git-Verwaltungsfunktionen benötige an meinen Redakteur (weil ich zu faul bin 😆)

Ich liebe es, dass Sie daran arbeiten, und ich kann es kaum erwarten, es in Aktion zu sehen.

Ich mag vscode, aber diese "fehlende Funktion" hält mich davon ab, vollständig von Atom zu vscode zu wechseln

Eine frühe Version befindet sich bereits im Insider-Build. Holen Sie es :)

+1 Benötige diese Funktion

Erste Vorschau-Version ist sehr nette Leute!
Es gibt bereits ein kleines Problem, bevor ich überhaupt anfange, richtig zu testen ...
Wenn ich zwei "Stamm" -Ordner mit dem gleichen Namen aus zwei separaten Projekten hinzufüge, gibt es nichts, was diese Ordner voneinander unterscheidet.

zB füge ich /dev/www/myproject/src und füge dann /dev/libraries/mycomponent/src
Ich sehe nur zwei Stammordner mit dem Namen src .

> src
> src

Ich glaube, wir brauchen eine Möglichkeit, den Anzeigenamen der Stammordner zu ändern.
Welches würde dann anzeigen:

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

Gedanken?

VSCode zeigt einen Teil des Ordnernamens an, wenn Sie zwei Dateien mit demselben Namen öffnen, die auch mit Ordnern funktionieren könnten.

@doublehelix Wir haben dies kürzlich besprochen, hatten aber nirgendwo die https://github.com/Microsoft/vscode/issues/29871 erstellt , danke 😄

@ Tyriar Ich finde die Suchfunktion, gelinde Explorer anzeigen sollte, wie ich bereits sagte .

Ich weiß nicht, ob ihr euch angesehen habt, was ich und einige Leute oben gesagt haben, oder ob weitere Änderungen kommen, aber ich persönlich mag es nicht, wie ihr den Namen der Wurzel jedes Mal anfügt, anstatt Dinge in einem Baum zu sortieren -ähnliche Ansicht, wenn möglich.

@eyalsk Es ist in Arbeit, ich werde mir die Suchergebnisse im Juli genauer ansehen: # 29977

Das vscode-Projekt basiert auf einem Ordner.
Sie können also die Konfiguration jedes Projekts separat konfigurieren und das integrierte Git direkt verwenden oder nicht.

PyCharm: Herz :: Herz :: Herz:

+1

Ich muss Sie loben, liebes VSCode-Team.
Endlich kann ich Atom loswerden, da Multi-Root-Arbeitsbereiche in den Insider-Builds gelandet sind!
Seit zwei Jahren werden .gitignore usw. in Atom bei der Suche in Multi-Root-Arbeitsbereichen nicht mehr beachtet und Sie haben es von Anfang an richtig verstanden!

Wird die Persistenz von Arbeitsbereichen in einem anderen Problem verfolgt?

Gestern hat das VS Code Team eine neue Version von VS Code mit der Funktion Multi Root Workspaces 🎉 veröffentlicht.

Das Ergebnis dieser Arbeit ist das sogenannte "Minimum Viable Product" (MVP), um Tests in mehreren Arbeitsbereichen für Stammordner zu ermöglichen.

Tatsächlich ist es nur im Insider-Build verfügbar, sodass Sie es hier herunterladen können. Laden Sie

Dateimanager

Suche

Angenommen, jeder dem Arbeitsbereich hinzugefügte Ordner ist ein separates Git-Repository. Behandelt die aktuelle Version von Multi Root Workspaces die differenzierte Quellcodeverwaltung dieser Repositorys?

@Weyzu Wir arbeiten daran, SCM für Multi-Root-Szenarien in diesem Meilenstein

Das Ergebnis sollte sowohl für Multi-Root-Szenarien als auch für Single-Root-Szenarien, in denen mehrere Repositorys in einem Root enthalten sind, eine bessere Erfahrung bieten.

Das Ergebnis sollte sowohl für Multi-Root-Szenarien als auch für Single-Root-Szenarien, in denen mehrere Repositorys in einem Root enthalten sind, eine bessere Erfahrung bieten.

Exzellenter Ansatz, ihr rockt!

@bpasero super ! Es würde mich auf jeden Fall interessieren, wie sich eure Jungs darum kümmern. IntelliJ / WebStorm hat etwas Ähnliches, bei dem Git-Roots automatisch erkannt und unten rechts für Sie entsprechend ausgerichtet werden. Ich persönlich habe es geliebt, es zu verwenden.

Habt ihr etwas in diese Richtung gedacht oder etwas ausgefeilteres?

Wir sortieren noch die UX dafür und werden Sie über die Ergebnisse auf dem Laufenden halten.

Könnte ein virtuelles Dateisystem-Root hier nicht funktionieren? Es würde effektiv so tun, als wäre der VFS-Stamm das übergeordnete Verzeichnis für mehrere unterschiedliche Pfade.

Ich wollte ein Update zu unserer Multi-Root-Arbeit geben, da heute der erste Tag ist, an dem unsere überarbeitete Multi-Root-UX die Insider-Version erreicht hat und viele von Ihnen, die sich an das "alte" Verhalten gewöhnt haben, möglicherweise verwirrt sind, was los ist.

Mängel der alten Lösung
Die alte Lösung für Multi-Root würde eine neue Einstellung workspace (in das globale settings.json ) einführen, mit der einem einzelnen Root-Ordner zusätzliche Ordner hinzugefügt werden können. Die Einstellung sah folgendermaßen aus, falls Sie es nicht bemerkt haben:

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

Wir nennen diese Lösung "Master" -Ordner mit zusätzlichen Ordnern ("Detail").

Dies war die einfachste Lösung, ohne viele neue Konzepte einzuführen, hat aber auch Mängel:

• Sie konnten den Hauptordner nie wieder als Einzelordner öffnen, da die Einstellung beibehalten wurde
• Sie konnten den Hauptordner nicht aus dem Explorer entfernen
• Einige Einstellungen aus dem Hauptordner wurden auf alle anderen Ordner angewendet
• Ihre Einstellungen werden durch Konfigurationsmaterial mit mehreren Wurzeln verschmutzt
• Es ist schwierig zuzulassen, dass mehrere Ordner gleichzeitig geöffnet werden (z. B. wenn Sie 3 öffnen, welchen Hauptordner sollten wir verwenden?).

Unsere Lösung
Wir sind der Meinung, dass für Szenarien mit mehreren Wurzeln ein expliziteres Arbeitsbereichskonzept erforderlich ist. Daher werden im heutigen Insider einige neue Benutzeroberflächen auftauchen:

Die Idee ist, dass für Multi-Root-Arbeitsbereiche eine explizite Aktion erstellt werden muss. So wie Sie sich in einem leeren Arbeitsbereich (kein Ordner geöffnet, lila Statusleiste) oder in einem Einzelordner-Arbeitsbereich (hellblaue Statusleiste) befinden können, können Sie sich auch in einem Arbeitsbereich mit mehreren Wurzeln befinden (dunkelblauer Status) Bar). Diese dritte Möglichkeit, einen Arbeitsbereich in VS Code zu öffnen, ermöglicht es, so viele Ordner zu haben, wie Sie möchten. Diese Arbeitsbereiche können in einer Datei gespeichert werden (z. B. myWorkspace.code ) und enthalten auch Arbeitsbereichseinstellungen. Sie sind jedoch nicht gezwungen, sie zu speichern. Solange Sie sie nicht speichern möchten, werden sie als "Arbeitsbereiche ohne Titel" angezeigt.

Um einen Arbeitsbereich zu öffnen, können Sie entweder die gespeicherte Arbeitsbereichsdatei öffnen oder aus der zuletzt geöffneten Liste auswählen:

Dies ist alles sehr junger Code und sehr junges UX. Erwarten Sie daher in den nächsten Wochen einige Änderungen. Wir wissen, dass noch einige Dinge zu klären sind (z. B. wie können wir den Übergang von Einzelordnern zu Mehrordnern reibungsloser gestalten).

Einige Änderungen, die bereits heute vorgenommen wurden und die Insider-Veröffentlichung von morgen aufgrund von Rückmeldungen treffen werden:

• Benennen Sie .code in .code-workspace als Erweiterung für Arbeitsbereiche um
• eine einheitliche Liste von Ordnern und Arbeitsbereichen haben (z. B. unter Datei> Zuletzt geöffnet), anstatt zwischen Ordnern und Arbeitsbereichen zu unterscheiden

Bleib dran, damit noch mehr kommt 👍

Darüber hinaus haben wir jetzt einen Ordner .vscode pro Projektordner, der die Datei settings.json . Diese Datei kann Folgendes enthalten:

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

Das Problem hierbei ist, dass wir dieselben Einstellungen verwenden, wenn wir mit mehreren Benutzern (unterschiedliche RDP-Sitzungen) auf dem Server in denselben Projektordnern arbeiten möchten. Dies ist möglicherweise nicht das beabsichtigte Verhalten. Ich möchte vielleicht, dass meine Schriftgröße größer ist als die meines Kollegen.

Meiner Meinung nach sollten Sie auch berücksichtigen, dass verschiedene Benutzer möglicherweise an denselben Ordnern arbeiten, jedoch mit unterschiedlichen Einstellungen in settings.json .

@ DarkLite1 Sie

In Ihrem Beispiel geht es um die Einstellung editor.fontSize , die wir sogar in einem Arbeitsbereich mit mehreren Stammverzeichnissen pro Ordner unterstützen. Ich denke, es könnte ein gültiges Szenario sein, dass ein Benutzer eine größere Schriftgröße für einen Ordner haben möchte, der viele Markdown-Dokumentationen enthält (vielleicht sogar eine andere Schriftart?). Daher würde ich denken, dass wir nicht verhindern sollten, dass diese Einstellung pro Ordner auch in einer Umgebung mit mehreren Stammverzeichnissen eingehalten wird.

Wenn Sie editor.fontSize als persönliche Arbeitsbereichseinstellung behalten möchten, sollte es meiner Meinung nach nicht in das Repository eingecheckt werden.

Mit dem neuen Arbeitsbereichskonzept können Sie Folgendes tun:

• Datei> Arbeitsbereiche> Neuer Arbeitsbereich
• Wählen Sie Ihren Ordner
• Öffnen Sie die Arbeitsbereichseinstellungen
• Ändern Sie editor.fontSize: 15

Von da an wird Ihr Arbeitsbereich diese Einstellung übernehmen, aber Sie erzwingen sie nicht für andere.

Aus UX-Sicht wäre es praktisch, wenn ich Ordner per Drag & Drop in ein VS-Code-Fenster ziehen könnte, ohne vorher explizit einen Arbeitsbereich erstellen zu müssen (dies ist etwas, was ich in Sublime ständig mache). Ich arbeite immer an mehreren Projekten gleichzeitig und je nachdem, woran ich arbeite, wird es jeden Tag eine andere (überlappende) Gruppe von Projekten geben.

Arbeitsbereiche würden ein Konzept einführen, das nicht meiner Arbeitsweise entspricht, und ich müsste verschiedene Arbeitsbereichskonfigurationen (so wie ich es verstehe) im Auge behalten, was so klingt, als würde dies zu Konfigurationsstörungen in meinen Projektordnern führen.

Außerdem denke ich, dass ich für viele Benutzer spreche, wenn ich argumentieren würde, dass Dinge wie Suche und Konfiguration standardmäßig global sind (gilt für alle geöffneten Ordner) - obwohl es schön wäre, wenn ich die Option hätte, lokal in einem Ordner zu suchen ( Ich hatte das in Sublime immer als schwierig empfunden.

@SanderMertens Sie haben das vielleicht verpasst, aber @bpasero hat geschrieben;

Diese Arbeitsbereiche können in einer Datei (z. B. myWorkspace.code) gespeichert werden und enthalten auch Arbeitsbereichseinstellungen. Sie sind jedoch nicht gezwungen, sie zu speichern. Solange Sie sie nicht speichern möchten, werden sie als "Arbeitsbereiche ohne Titel" angezeigt.

Jetzt bin ich mir nicht sicher, ob Sie Ordner ziehen und ablegen können, aber nach dem, was ich bekomme, können Benutzer beliebige Ordner öffnen, ohne einen Arbeitsbereich zu erstellen.

Ich kann es kaum erwarten, dass diese Funktion in den stabilen Build aufgenommen wird.

Yay! 😄

Derzeit können Sie keinen Ordner in den Explorer ziehen, um ihn hinzuzufügen. Dies befindet sich jedoch in unserem Backlog. Die Komplikation bei dieser Interaktion besteht darin, dass wir die Absicht des Benutzers nicht kennen: den Ordner im Fenster zu öffnen oder ihn dem Arbeitsbereich hinzuzufügen?

Der Übergang von einem Ordner zu vielen Ordnern ist derzeit ein expliziterer Schritt als bei anderen Editoren (Sie müssen über Datei> Arbeitsbereiche> Arbeitsbereich speichern die gewünschten Ordner auswählen). Es gibt mehrere Gründe, warum wir vorerst mit dem aktuellen Verhalten fortfahren möchten, bis sich die Mehrfachwurzel stabilisiert. Der Hauptgrund ist, dass Multi-Root eine wichtige Änderung für alle unsere Erweiterungen darstellt. Während der Explorer funktioniert und Sie alle Ordner durchsuchen können, funktionieren die meisten Erweiterungen erst dann ordnungsgemäß, wenn die neue Multi-Root-API übernommen wurde. Daher möchten wir es am Anfang nicht zu einfach machen, versehentlich in Multi-Root einzusteigen. Es ist eine explizite Benutzergeste, mehrere Root-Arbeitsbereiche aufzurufen. In diesem Modus möchten wir möglicherweise darauf aufmerksam machen, dass einige Erweiterungen noch nicht funktionieren.

Ein weiterer Grund sind die Einstellungen des Arbeitsbereichs: Stellen Sie sich diesen Ablauf vor:

• Sie beginnen mit 1 Ordner mit Arbeitsbereichseinstellungen
• Sie fügen einen zweiten Ordner hinzu (vorausgesetzt, dies funktioniert ohne Kontextwechsel und erneutes Laden des Fensters).
• Sie öffnen Arbeitsbereichseinstellungen
  => Arbeitsbereichseinstellungen in Multi Root werden jetzt an einem Ort außerhalb der Ordner gespeichert, da Sie mehrere haben können
  => Wir müssen den Benutzer wahrscheinlich fragen, ob der Benutzer die Arbeitsbereichseinstellungen an diesen neuen Speicherort migrieren möchte

Unabhängig davon ist die Eingabe von Multi-Root derzeit keine einfache Operation. Wir werden dies vielleicht noch einmal überprüfen, wenn sich der Staub gelegt hat und die Mehrwurzel weit verbreitet ist, aber im Moment denken wir, dass dieses Modell besser ist und Frustrationen vermeidet.

@bpasero Ich denke, dass ein Ordner, der einmal in den Explorer gezogen wurde, standardmäßig nicht automatisch im Arbeitsbereich gespeichert werden sollte , obwohl einer vorhanden sein könnte. Dies sollte eine explizite Aktion sein, bei der der Benutzer auf die Ordner klickt, die er / sie hat Ziehen Sie es und fügen Sie es dann explizit zum Arbeitsbereich hinzu. Wenn Sie nur wenige nicht verwandte Ordner haben, ist es möglicherweise sinnvoll, eine weitere Aktion bereitzustellen, um alle auf einmal zu speichern.

Es hängt alles von den Anwendungsfällen ab, die abgedeckt werden sollen. Ich habe aus Erfahrung herausgefunden, dass KISS immer der beste Ansatz ist. Die Einführung von Workspaces klingt großartig als feature aber was ist der wahre Vorteil und was sind die Nachteile?

Ein Nachteil, der bei der Einführung und Verwendung von Workspaces in den Sinn kommt, besteht darin, dass die Daten (Einstellungen) irgendwo gespeichert werden müssen und die Wartung / Kenntnis des Benutzers erforderlich ist.

Angenommen, das einzige Ziel besteht darin, Benutzern die Möglichkeit zu geben, mit mehreren Ordnern in einer VS-Code-Sitzung zu arbeiten. Nicht weniger, nicht mehr.

Häufigster Anwendungsfall:
Es gibt kein Workspaces -Konzept. Der Benutzer öffnet nur einen zusätzlichen Ordner oder so viele, wie er möchte, und sie öffnen sich in der Ansicht links wie ein einzelner Ordner. Er erwartet, dass seine Einstellungen überall gleich sind. unabhängig davon, wo sich seine Dateien befinden. Und er möchte keine zusätzliche Unordnung von VS-Code-Konfigurationsdateien zwischen seinen Projektdateien, wie von @SanderMertens , mir und wahrscheinlich auch anderen da draußen angegeben.

Herausforderungen / Probleme / Fragen:

• Warum gibt es so unterschiedliche Einstellungsdateien? Benutzereinstellungen, Arbeitsbereichseinstellungen? Es sollte meiner Meinung nach alle an ein und demselben Ort aufbewahrt werden. Nach Belieben im Benutzer seinen persönlichen Ordner / Profil, so dass jeder Benutzer im System seine eigenen Einstellungen haben kann. Extrabonus. Sie überladen die Projektdateien nicht und mehrere Benutzer können ihr eigenes Ding machen. Profil löschen? Großartig! Reinigen Sie den Schiefer auch für VS-Code.

Ich denke, Workspaces sind ein bisschen übertrieben, wenn Sie wollen:
Geschwindigkeit, Einfachheit und ein Editor, der einfach funktioniert. Keine übermäßigen Komplikationen oder das Verständnis zusätzlicher Konzepte. Wenn Benutzer von Sublime oder anderen Editoren dieses Konzept nicht in ihrem Workflow verwenden, sollte dies ein Hinweis auf überdenkende Dinge sein. Oder es könnte bedeuten, dass etwas wirklich Fantastisches erfunden wird, das auch andere Editoren implementieren werden, aber ich habe meine Zweifel.

Es tut mir leid, wenn das so laut klingt, das ist absolut nicht meine Absicht. Aber ich glaube, wir können es beim Zugriff auf mehrere Stamm- / Ordner besser machen.

@ DarkLite1 Vielen Dank, dass Sie sich die Zeit genommen haben, Feedback zu unserer neuen Strategie für Arbeitsbereiche zu geben.

Ich stimme all Ihren Punkten zu und möchte auch eine einfache Lösung. Workspaces als Konzept ist unser erster Schritt in Richtung einer Multi-Root-Lösung, die mit unseren vorhandenen Mustern (Arbeitsbereichseinstellungen, Erweiterungen usw.) funktioniert. Da dies der erste Schritt ist, sollten Sie mit etwas raueren Kanten rechnen (z. B. ist der Übergang von 1 zu N Ordnern nicht so einfach wie er sein könnte). Unser Ziel ist es, diesen Übergang reibungslos und nicht komplexer zu gestalten, als es in Zukunft sein muss. Außerdem möchten wir einen Benutzer nicht zwingen, diese Arbeitsbereiche zu verwalten (aus diesem Grund haben wir "Arbeitsbereiche ohne Titel", die so lange aktiv sind, wie das Fenster geöffnet ist und nach dem Schließen des Fensters nicht mehr angezeigt wird).

Bei Multi-Root-Arbeitsbereichen sind einige Dinge zu beachten, die möglicherweise nicht so offensichtlich sind. Ich hoffe, die folgende ausführliche Erklärung hilft, unseren Entwurfsprozess zu verstehen:

Arbeitsbereichseinstellungen
Wir unterstützen Einstellungen in einem Arbeitsbereichsordner ( .vscode Ordner). So sehr einige Benutzer diese Art von Einstellungen, die in .gitignore -Dateien oder im Repository landen, möglicherweise nicht mögen, gibt es viele, die sich auf diese Funktionalität verlassen. Wir können nicht einfach aufhören, Einstellungen zu unterstützen, die sich in Ordnern befinden, weil Benutzer sich auf sie verlassen. Für Multi-Root-Szenarien ist es jetzt klar, dass wir einen neuen Ort für die Einstellungen des Arbeitsbereichs finden müssen. Wir haben das Konzept einer Arbeitsbereichsdatei entwickelt, die diese Einstellungen enthält. Solange der Arbeitsbereich nirgendwo gespeichert ist, befindet er sich in einem Ordner, in dem andere VS-Code-spezifische Daten enthalten sind. Wenn Sie die Datei speichern, befinden sich die Einstellungen in dieser Datei.

Stellen Sie sich nun vor, Sie beginnen mit 1 Ordner in VS Code, für den Arbeitsbereichseinstellungen definiert sind, und möchten einen zweiten Ordner hinzufügen. Was sollen wir jetzt tun? Arbeitsbereichseinstellungen des ersten Ordners ignorieren? Bitten Sie den Benutzer, die Einstellungen zu migrieren? Wir haben beschlossen, dies zu einem expliziten Kontextwechsel zu machen, um zu verdeutlichen, dass das Öffnen eines Arbeitsbereichs seine eigenen Arbeitsbereichseinstellungen an einem anderen Ort enthält.

Stellen Sie sich vor, Sie sind von 1 Ordner zu 2 Ordnern gewechselt und haben die Einstellungen für den Arbeitsbereich an einen anderen Ort verschoben. Stellen Sie sich vor, Sie nehmen Änderungen an diesen Arbeitsbereichseinstellungen vor. Wenn Sie jetzt von 2 Ordnern zu 1 zurückkehren möchten, möchten Sie die Arbeitsbereichseinstellungen wieder in den Ordner migrieren?

Ein weiteres Beispiel: Sie wechseln von 1 zu 2 Ordnern und konfigurieren die Arbeitsbereichseinstellungen. Jetzt schließen Sie das Fenster. Ich denke, Sie würden sauer auf uns werden, wenn Sie nicht auf irgendeine Weise zu diesem Arbeitsbereich zurückkehren könnten, weil Sie die Einstellungen für diesen Arbeitsbereich sorgfältig konfiguriert haben. Auch wenn Ihnen das Konzept eines Arbeitsbereichs nicht gefällt, möchten Sie, nachdem Sie die Einstellungen dafür konfiguriert haben, dass dieser Arbeitsbereich weiterlebt.

Ich hoffe, diese Beispiele machen es ein bisschen einfacher zu verstehen, warum KISS für uns nicht so einfach ist, wie man denkt.

Erweiterungen
Alle unsere Erweiterungen arbeiteten immer mit einer API, die einen einzelnen Arbeitsbereichspfad bereitstellt, da wir bisher keine Multi-Root-Arbeitsbereiche unterstützten. Als Benutzer könnte man denken, dass das Wechseln von 1 Ordner zu 2 Ordnern ein sehr einfacher und einfacher Vorgang ist, aber für Erweiterungen kann dies eine Menge bedeuten: Spracherweiterungen, bei denen bisher nur ein Ordner angenommen wurde, müssen plötzlich mehrere kennen Ordner. Darüber hinaus können diese Ordner jederzeit sehr dynamisch ein- und ausgehen.

Die Einführung eines echten Arbeitsbereichskonzepts gibt uns mehr Raum und Zeit für die Breite und hilft Erweiterungen, dieses Konzept zu übernehmen. Wir könnten beispielsweise Erweiterungen deaktivieren, die noch keine Multi-Root-Arbeitsbereiche verwendet haben, um zu verhindern, dass seltsame Dinge passieren (z. B. funktioniert eine Spracherweiterung nur in einem Ordner und meldet falsche Fehler in dem anderen).

Lassen Sie uns zunächst versuchen, die Multi-Root-Unterstützung mit diesen neuen Arbeitsbereichen zu stabilisieren, und dann erneut prüfen, wie leicht wir die Übergänge vornehmen können. Sobald wir Erweiterungen an Bord haben und unsere Einstellungsgeschichte herausgefunden haben, können wir den Flip zu einem leichteren Erlebnis machen.

PS: Da Sie in Bezug auf ihre Multi-Root-Unterstützung auf andere Editoren verweisen, wollte ich nur darauf hinweisen, dass diese Editoren auch einen Arbeitsbereich oder ein Projektkonzept enthalten, das Sie in einer Datei speichern und mit anderen teilen können. In der Regel werden diese Konzepte nicht angezeigt, da das Wechseln von 1 zu N Ordnern ein sehr einfacher Vorgang ist. Ich würde jedoch argumentieren, dass Personen, die sich auf diese Funktion verlassen, beginnen, in gespeicherte Arbeitsbereiche / Projekte zu wechseln, um die Arbeit zu verwalten. Wenn Sie beispielsweise den Arbeitsbereich / das Projekt nicht speichern und das Fenster schließen, gehen alle diese Informationen verloren.

@bpasero Danke, dass Sie sich bei mir

Da ich Sublime nicht vollständig kenne, habe ich mir erlaubt, zu überprüfen, wie sie damit umgehen. Und Sie haben Recht, sie verwenden auch Workspaces und sogar Project Dateien. Das einzige, was mich ein bisschen stört, ist, dass es VS-Code-Dateien zwischen mein Projekt legt. Aber wie Sie bereits erwähnt haben, muss berücksichtigt werden, dass dies möglicherweise das Beste ist, wenn sich andere darauf verlassen. Ich frage mich nur, warum diese Einstellungsdateien nicht benutzerspezifisch sind. Ich kann mir vorstellen, dass ein Kollege VS Code in derselben Ordnerstruktur öffnet, aber seine eigenen Einstellungen haben möchte.

Wenn Workspaces der richtige Weg ist und es scheint, dass dies der Fall ist, ist es beim Öffnen der App logisch, dass die zuletzt verwendeten Einstellungen neu geladen werden. Auch wenn dies ein nicht gespeichertes Workspace . Es macht das Leben ein bisschen einfacher, denke ich.

Warum habe ich mich für VS Code entschieden? Da es plattformübergreifend ist, da ich Linux zu Hause und Windows bei der Arbeit verwende, könnte dies wirklich mein Standardeditor werden! Als zusätzlichen Bonus bin ich ein PowerShell-Entwickler und es gibt auch eine Erweiterung dafür. Also zwei große Siege! Darüber hinaus macht Red Hat für den Java-Kurs, den ich verfolge, eine Erweiterung auch für VS Code. Wenn Sie VS Code mit seinen Verknüpfungen und allem besser kennenlernen, profitieren Sie auf ganzer Linie.

Die App und ihre Erweiterungen befinden sich an einigen Stellen noch in der Beta- oder sogar Alpha-Phase, aber trotzdem großartige Arbeit, Leute! Schätzen Sie wirklich die Bemühungen und sehen Sie jeden Tag die Fortschritte in den Insider-Builds. Mach weiter so und wünsche dir ein schönes Wochenende.

Vielen Dank für diese Erklärung @bpasero , ich glaube, ich verstehe jetzt besser, was die Komplexität ist.

Ein Ansatz könnte darin bestehen, alle Projekte mit derselben Konfiguration wie ein Arbeitsbereich konzeptionell zu behandeln. Darüber hinaus können Sie keinen .vscode -Ordner hinzufügen, solange das Projekt nicht von der Standardkonfiguration abweicht. Das sollte:
1) Beseitigen Sie die meisten Unordnung in Projekten
2) Verhindern Sie die meisten Konfigurationskonflikte beim Hinzufügen von Projekten (im einfachen Fall gibt es keine Konfiguration).

Ich denke, das besprochene explizite Arbeitsbereichskonzept ist eine gute Lösung für das erwähnte Problem. Mit diesen beiden einfachen Regeln minimiere ich die Anwendungsfälle, in denen Menschen auf dieses Problem stoßen.

Wenn ich mir die Kommentare im Thread und meine Anwendungsfälle anschaue, sehe ich _Multi-Ordner_ und _Workspaces_ als zwei verschiedene Konzepte, und vielleicht sollte es auch separat behandelt werden.

Es sollte nicht erzwungen werden, einen Arbeitsbereich zu erstellen, nur um dem aktuellen Fenster einen weiteren Ordner hinzuzufügen. Es sollte nur den neuen Ordner in den Baum einfügen und den neu erstellten Arbeitsbereich als _interne Info_ belassen. Wenn der Benutzer beschließt, den Arbeitsbereich zu speichern, wird der Arbeitsbereich tatsächlich erstellt. Und selbst wenn ich den Arbeitsbereich beim erneuten Öffnen des obersten Ordners nicht speichere, würde er sich an meinen temporären Arbeitsbereich erinnern und auch die anderen Ordner öffnen, so wie er sich an die geöffneten Dateien erinnert, wenn Sie heute einen Ordner öffnen. Übrigens frage ich mich, wie ich mehrere Ordner in der Befehlszeile öffnen könnte.

Für meine Anwendungsfälle ist Multi-Ordner nur eine Möglichkeit, mehr als einen Ordner gleichzeitig im selben Fenster anzuzeigen, kein _Project Group / Solution_-Ansatz. Eine einfachere Lösung würde also passen. Aber ich verstehe, wie andere einen Arbeitsbereich mit eigenen Einstellungen benötigen und so: thumbsup:.

Das, was mich an diesem neuen Workspaces-Konzept am meisten stört (im Vergleich zur ersten Iteration mit User Settings ), ist das gleiche, was mich bei der Verwendung von Sublime Text gestört hat. Die Tatsache, dass Sie die .code-workspace -Dateien überall speichern können, und jetzt muss ich einen gemeinsamen Ort verwalten, um sie zu speichern. Es wäre viel einfacher, IMHO, dass es automatisch an eine dieser beiden Stellen passt:

• innerhalb des Ordners user-data-dir , wie User Settings und Keybindings
• im _Top Ordner_

Um ganz klar zu sein, ich verstehe das komplexere Arbeitsbereichskonzept, das andere Benutzer benötigen. Ich wollte nur einen einfacheren Ansatz für ein einfacheres Konzept mit mehreren Ordnern.

Ich mag diese Option, füge diese Option hinzu.

Weil der Ordner darin nicht sehr beeindruckend ist.

oder fügen Sie die Möglichkeit hinzu, diese Option zu ändern.

Ich mag die Workspace-Idee! Irgendwelche Ideen, wann dies fertig sein wird?

Wird an dieser Stelle erwartet, dass die Git-Informationen in der unteren linken Ecke den Git-Zweig des Repos, in dem sich die aktuell fokussierte Datei befindet, nicht genau wiedergeben? Ich habe in den Versionshinweisen zu v1_15 nichts über "multiple Git Roots" gesehen.

Ich benutze diese Funktion jetzt seit einigen Tagen mit dem Insider-Build und ich muss sagen, es ist alles, was ich wollte. Sehr saubere Benutzererfahrung und ich kann es kaum erwarten, bis es im Haupt-Build ist, damit ich mein gesamtes Team darauf umstellen kann.

Wenn Sie mit NodeJS arbeiten und mehrere NPM-Module gleichzeitig geöffnet haben, spart die Art und Weise, wie alles in einem Fenster zusammengefasst wird, viel Zeit.

Riesige Requisiten an das Team!

Warum wird diese Funktion in meinen Versionshinweisen mit einem GIF und einer Erklärung angezeigt, ist aber im aktuellen Editor nicht verfügbar?!

@ShashankaNataraj , das auf Insidern

Unsere Roadmap für die laufende Multi-Root-Arbeit ist unter https://github.com/Microsoft/vscode/issues/28344 erfasst und wird bis August, September und wahrscheinlich auch Oktober fortgesetzt.

Wir werden diese Funktion nur für Insider verfügbar halten, bis:

• Wir können eine ordnungsgemäße Multi-Root-fähige SCM-, Debug- und Aufgabenerfahrung bereitstellen
• Wir haben Multi-Root-APIs und -Funktionalitäten für die Erweiterungen übernommen, mit denen wir ausgeliefert werden und zu denen wir aktiv beitragen (z. B. Go).
• Die Autoren der Erweiterung hatten genügend Zeit (z. B. 1 Meilenstein), um die neuen Multi-Root-APIs zu übernehmen

Bitte haben Sie Verständnis dafür, dass wir vermeiden möchten, dass diese Funktion an Stable ausgeliefert wird und dass die Erweiterungserfahrung fehlerhaft ist, da wir diese Funktion zu früh eingeführt haben.

Danke, dass ihr professionelle Jungs seid, tolle Arbeit!

@bpasero Ich gegebener Zeit aktualisieren werden. Erhalten sie spezielle E-Mails mit Änderungen?

Vielen Dank

@FelikZ Bitte schauen Sie sich unsere Roadmap an (https://github.com/Microsoft/vscode/issues/28344). Für die September-Version planen wir, die Erweiterungen zu übernehmen, die wir in VS Code ausliefern, und während wir daran arbeiten, fügen wir die dafür erforderlichen APIs und Dienstprogramme hinzu.

Im September ist dies der Plan:

Das heutige Insider-Update enthält einige Änderungen an der Datei .code-workspace , die ich hier zusammenfassen wollte. Bestehende Arbeitsbereiche mit dem vorherigen Format werden automatisch in das neue Format migriert.

Das alte Format sah folgendermaßen aus:

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

Und das neue Format ist:

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

Arbeitsbereich-ID
Die Arbeitsbereich-ID wird verwendet, um dem Arbeitsbereich einige Dinge zuzuordnen:

• alle UI-Status (zB geöffnete Dateien)
• alle schmutzigen Dateistatus (auch bekannt als Hot-Exit)
• Erweiterungsstatus (falls vorhanden)

Wir haben beschlossen, die Eigenschaft id aus der Arbeitsbereichsdatei zu entfernen und stattdessen die id automatisch basierend auf dem absoluten Dateipfad der Arbeitsbereichsdatei auf der Festplatte zu berechnen. Dies hat einige Vor- und Nachteile, aber letztendlich denken wir, dass die Vorteile dies zu einer besseren Lösung machen:

• Es war seltsam, dass Sie die id in der Datei bearbeiten konnten, indem Sie einfach einen anderen Wert eingeben
• Es war nicht sehr klar, wie die id wenn die Arbeitsbereichsdatei mit anderen geteilt wird (sollte die id geändert werden? Sollte die id eine UUID sein?)
• Es war nicht möglich, eine Arbeitsbereichsdatei zu kopieren und in einem separaten Fenster zu öffnen. Sie mussten zuerst die id in der kopierten Datei ändern
• Infolgedessen müsste die Aktion "Arbeitsbereich speichern unter" den Benutzer fragen, ob die Kopie ein anderes id oder nicht

Ein Nachteil dieses Ansatzes besteht darin, dass beim Verschieben oder Umbenennen einer Arbeitsbereichsdatei der zugehörige Status verloren geht. Schmutzige Dateien ("Hot-Exit") werden nach einem Neustart weiterhin geöffnet, sie werden jedoch in einem leeren Fenster geöffnet und sind nicht mehr dem Arbeitsbereichfenster zugeordnet. Wir sind immer noch der Meinung, dass wir dieses Verhalten verbessern können, obwohl es im Einklang mit dem steht, was heute passiert, wenn Sie einen Ordner mit dem zugehörigen UI-Status und fehlerhaften Dateien umbenennen.

Ordner
Wir haben uns entschlossen, das Format der folders -Eigenschaft zu überdenken.

• Sie müssen keine Ressourcen-URIs mehr verwenden, sondern nur noch Dateipfade, um die Bearbeitung zu vereinfachen
• Wir haben die Einträge der folders -Eigenschaft in Objekte geändert, damit wir den Einträgen nach Bedarf Metadaten zuordnen können (z. B. könnte jeder Ordner eine zusätzliche name -Eigenschaft haben).

Schließlich ist auch die Unterstützung für relative Pfade gelandet. Sie können einen relativen Dateipfad eingeben, der im übergeordneten Ordner der Arbeitsbereichsdatei aufgelöst wird. Beachten Sie, dass wir aufgrund des Fehlers https://github.com/Microsoft/vscode/issues/33188 derzeit relative Pfade in absolute Pfade umschreiben, wenn wir Änderungen an der Arbeitsbereichsdatei vornehmen.

@bpasero es ist großartig. Wann funktioniert die zusätzliche Eigenschaft name ? Derzeit habe ich zwei gleichnamige Ordner in meinem Arbeitsbereich und es ist schrecklich.

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

Eine Aktualisierung der Behandlung relativer Pfade : Ab dem heutigen Insider-Build werden Pfade als relativer Pfad in die Arbeitsbereichsdatei geschrieben, wenn der Speicherort der Arbeitsbereichsdatei ein übergeordnetes Element des Ziels ist. Mit anderen Worten, Pfade sind jetzt immer relativ, es sei denn, wir müssten die Notation " ../ " verwenden, um den Pfad auszudrücken.

Da Arbeitsbereiche ohne Titel immer im Datenverzeichnis von VS Code gespeichert sind, sind die Pfade dort immer absolut. Sobald Sie jedoch einen Arbeitsbereich ohne Titel an einem Speicherort gespeichert haben, werden die Pfade nach Möglichkeit neu geschrieben.

Wenn Sie neugierig auf die Änderungen an Multi-Root-Arbeitsbereichen sind, die während dieses Sprints vorgenommen wurden, lesen Sie die aktualisierten Versionshinweise .

+1

+1

@bpasero IMHO ist die Art und Weise, wie UI-Zustände behandelt werden ( .code-workspace verwendet wird oder stattdessen der Dateipfad als ID verwendet wird), nicht ausreichend.
Das Umbenennen einer .code-workspace -Datei oder eines ihrer übergeordneten Ordner oder das Verschieben dieser Datei und das Verlieren des UI-Status ist meiner Meinung nach völlig unintuitiv. Ich denke, Leute, die nicht wissen, wie das unter der Haube funktioniert, haben absolut keine Ahnung, warum sie ihren vorherigen UI-Status verloren haben und wie sie ihn zurückbekommen können.
Das sollte überhaupt nicht an den absoluten Pfad der Dateien im Dateisystem gebunden sein!

Dies gilt auch für die Art und Weise, wie sich der UI-Status auf den Ordnerpfad bezieht, der sich derzeit in der stabilen Version befindet. Ich war zuerst sehr verwirrt darüber, bis ich ein bisschen googelte.

IMO Wenn es sich nur um einen Ordner handelt, sollte der UI-Status im Ordner .vscode gespeichert werden. Wenn es sich um einen Multi-Root-Arbeitsbereich handelt, sollte der UI-Status als separate Datei im selben Ordner wie die .code-workspace -Datei unter Verwendung geeigneter Namenskonventionen (oder möglicherweise in dieser Datei selbst, obwohl Einstellungen und gemischt werden) gespeichert werden Staat könnte keine gute Idee sein).

Bei korrekter Implementierung erhalten Benutzer vollständigen Zugriff auf UI-Status, können neue UI-Status an einen bestimmten Arbeitsbereich anhängen (Multi-Root oder nicht) usw.
Ich würde gerne in der Lage sein, den UI-Status zwischen verschiedenen Computern zu synchronisieren, beispielsweise im Büro zu arbeiten, dann nach Hause zu gehen, einen Laptop oder was auch immer zu nehmen und genau dort fortzufahren, wo ich aufgehört habe.
Es wäre auch fantastisch, wenn mehrere UI-Status an einen Arbeitsbereich angehängt wären und einfach zwischen ihnen wechseln könnten (Menü / Tastenkombination / Befehl / usw.), wenn an verschiedenen Funktionen gearbeitet wird. Möglicherweise werden automatisch verschiedene .code-uistate -Dateien in .vscode aufgelistet oder viele .code-uistate -Dateien, denen das Hauptpräfix .code-workspace vorangestellt oder in einem Array aufgeführt ist.

Ich denke darüber nach, als Erweiterung der Funktionsweise von Projekten und Arbeitsbereichen in Sublime Text. Gleiche Funktionalität, anderes Design. In diesem Fall ähnelt ein VS-Code-Arbeitsbereich einem Sublime-Projekt, und die verschiedenen VS-Code-UI-Zustände ähneln Sublime-Arbeitsbereichen.

Zu diesen Themen:

Es war seltsam, dass Sie die ID in der Datei einfach durch Eingabe eines anderen Werts bearbeiten konnten

Ja, total. Das Entfernen der ID von dort war die richtige Wahl.

Es war nicht sehr klar, wie die ID behandelt werden soll, wenn die Arbeitsbereichsdatei für andere freigegeben wird (sollte die ID geändert werden? Sollte die ID eine UUID sein?).

Wenn wir myproject.code-workspace und myproject.code-uistate haben, muss der Benutzer entscheiden, ob er seinen UI-Status teilt oder nicht. Sie müssen nicht mehr darüber nachdenken, was diese ID bedeutet, wie sie generiert wird, ob es sich um eine UUID handeln muss, um Konflikte beim Teilen zu vermeiden usw.
Möchten Sie die Ordnereinstellungen und -einstellungen freigeben? Senden Sie myproject.code-workspace , kein Grund zur Sorge.
Willst du alles teilen? Senden Sie beide Dateien.

Es war nicht möglich, eine Arbeitsbereichsdatei zu kopieren und in einem separaten Fenster zu öffnen. Sie mussten zuerst die ID in der kopierten Datei ändern

Wenn Sie mit einem neuen UI-Status mit demselben Ordner-Setup und denselben Einstellungen beginnen möchten, duplizieren Sie einfach Ihre .code-workspace -Datei.

Infolgedessen müsste die Aktion "Arbeitsbereich speichern unter" den Benutzer fragen, ob die Kopie eine andere ID haben soll oder nicht

Das war schwierig, da der Benutzer nicht wusste, was diese ID war. Vielleicht wäre es einfacher, zwei Optionen zu haben: "Arbeitsbereich mit aktuellem Status klonen" und "Neuer leerer Arbeitsbereich". Aber das ist UX und Sie müssten eine Analyse darüber durchführen.

Wenn Sie mit Franc einverstanden sind, behalten Sie alle Projektkonfigurationsdateien in den Einstellungen
Ordner in den Projekten, werfen Sie einen Blick auf Eclipse IDE, die das Recht hat
Ansatz. Es hat das Konzept der Projekt- und Arbeitsbereichseinstellungen mit
Standardeinstellungen für das Überschreiben von Projekten im Arbeitsbereich. Der Arbeitsbereich ist nur ein Ordner mit
Ordner, die Projekte darstellen. Haben Sie also den Ordner .vscode im Arbeitsbereich
Ordner, und jedes Projekt hat seinen eigenen Ordner .vscode . Und bitte nicht
Stimmen Sie dies einfach ab, um Eclipse IDE zu erwähnen.

Am Montag, den 18. September 2017 um 20:52 Uhr hat Franco Gallardo Grazio <
[email protected]> schrieb:

@bpasero https://github.com/bpasero IMHO, wie UI-Zustände behandelt werden
(Wetter, es wird eine ID-Zeichenfolge in der .code-workspace-Datei verwendet oder verwendet
Der Dateipfad als ID ist nicht ausreichend.
Umbenennen einer .code-workspace-Datei oder eines ihrer übergeordneten Ordner oder Verschieben
Es ist meiner Meinung nach völlig unintuitiv, den UI-Status zu verlieren. ich
Ich denke, Leute, die nicht wissen, wie das unter der Haube funktioniert, hätten es absolut
Keine Ahnung, warum sie ihren vorherigen UI-Status verloren haben und wie sie zu bekommen sind
es zurück.
Das sollte nicht an den absoluten Pfad der Dateien in der Datei gebunden sein
System überhaupt!

Dies gilt für die Art und Weise, in der sich der UI-Status auf den Ordnerpfad bezieht, der sich derzeit in befindet
stabile Freisetzung auch. Ich war zuerst sehr verwirrt, bis ich
googelte ein bisschen.

IMO Wenn es sich nur um einen Ordner handelt, sollte der UI-Status gespeichert werden
im .vscode-Ordner. Wenn es sich um einen Arbeitsbereich mit mehreren Wurzeln handelt,
Der UI-Status sollte als separate Datei im selben Ordner wie der gespeichert werden
.code-workspace-Datei unter Verwendung geeigneter Namenskonventionen (oder vielleicht
in dieser Datei selbst, obwohl das Mischen von Einstellungen und Status möglicherweise nicht a ist
gute Idee).

Bei korrekter Implementierung erhalten Benutzer vollständigen Zugriff
Fügen Sie an UI-Zustände neue UI-Zustände an einen bestimmten Arbeitsbereich an (Multi-Root oder
nicht) usw.
Ich würde gerne in der Lage sein, den UI-Status zwischen verschiedenen Computern zu synchronisieren
im Büro arbeiten, dann nach Hause gehen, sich einen Laptop schnappen oder was auch immer und
weiter genau dort, wo ich aufgehört habe.
Mehrere UI-Status an einen Arbeitsbereich angehängt haben und einfach zwischen diesen wechseln
sie (Menü / Tastenkombination / Befehl / etc) bei der Arbeit an verschiedenen Funktionen würden
Sei auch großartig. Möglicherweise andere .code-uistate-Dateien in .vscode
automatisch aufgelistet oder viele .code-uistate-Dateien mit dem Präfix entsprechend
der Haupt-Code-Arbeitsbereich oder in einem Array aufgelistet.

Ich denke darüber als Erweiterung dessen, wie Projekte und Arbeitsbereiche
Arbeit an erhabenem Text. Gleiche Funktionalität, anderes Design. In diesem Fall a
Der VS Code-Arbeitsbereich ähnelt einem Sublime-Projekt und unterscheidet sich
Die Status der VS-Code-Benutzeroberfläche ähneln den Sublime-Arbeitsbereichen.

Zu diesen Themen:

Es war seltsam, dass Sie die ID in der Datei einfach durch Eingabe bearbeiten konnten
ein anderer Wert

Ja, total. Das Entfernen der ID von dort war die richtige Wahl.

Es war nicht sehr klar, wie die ID beim Freigeben der Arbeitsbereichsdatei zu behandeln ist
mit anderen (sollte die ID geändert werden? Sollte die ID eine UUID sein?)

Nun, wenn wir myproject.code-workspace und myproject.code-uistate haben
Dann muss der Benutzer entscheiden, ob er seinen UI-Status freigibt oder nicht.
Sie müssen nicht mehr darüber nachdenken, was diese ID bedeutet, wie sie generiert wird, wenn es sein muss
eine UUID, um Konflikte beim Teilen usw. zu vermeiden.
Möchten Sie die Ordnereinstellungen und -einstellungen freigeben? Senden Sie myproject.code-workspace,
kein Grund zur Sorge.
Willst du alles teilen? Senden Sie beide Dateien.

Es war nicht möglich, eine Arbeitsbereichsdatei zu kopieren und in einer separaten zu öffnen
Fenster mussten Sie zuerst die ID in der kopierten Datei ändern

Wenn Sie mit einem neuen UI-Status mit demselben Ordner-Setup und beginnen möchten
Einstellungen duplizieren einfach Ihre .code-workspace-Datei.

Infolgedessen müsste die Aktion "Arbeitsbereich speichern unter" die
Benutzer, ob die Kopie eine andere ID haben soll oder nicht

Das war schwierig, da der Benutzer nicht wusste, was diese ID war. Vielleicht würde es
Es ist einfacher, zwei Optionen zu haben: "Arbeitsbereich mit aktuell klonen"
State "und" New Blank Workspace ". Aber das ist UX und Sie müssten eine machen
Analyse darüber.

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/Microsoft/vscode/issues/396#issuecomment-330396242 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AAQsBQ5rdj3VGoNwy77jfSQ7V_tqWFOfks5sjxBYgaJpZM4Gm3nX
.

- -
Daniel Sokolowski
Technischer Architekt

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

Vertraulichkeitserklärung:
Die übermittelten Informationen sind nur für die Person oder Organisation bestimmt
welche es angesprochen wird und vertraulich und / oder privilegiert enthalten kann
Material. Jegliche Überprüfung der Weiterverbreitung oder sonstigen Verwendung von oder
Ergreifen von Maßnahmen in Abhängigkeit von diesen Informationen durch Personen oder
andere Stellen als der beabsichtigte Empfänger sind verboten. Wenn Sie erhalten haben
In diesem Fall wenden Sie sich bitte umgehend elektronisch an den Absender
Übertragung und löschen Sie dann sofort diese Übertragung einschließlich aller
Anhänge ohne Kopieren, Verteilen oder Offenlegen.

@danielsokolowski Ich verstehe die Vorstellung eines Projekts, das einen Arbeitsbereich für Einstellungen überschreibt. In vscode haben Sie allgemeine Einstellungen, Benutzereinstellungen (über das Schreiben von allgemeinen) und Arbeitsbereichseinstellungen (über das Schreiben von Benutzern oder allgemeinen). Jedes Projekt hat bereits die Möglichkeit, einen eigenen .vscode-Ordner zu haben (darin befinden sich die Arbeitsbereichseinstellungen). Schlagen Sie einen zusätzlichen Ordner vor, in dem Projekte nur zum Teilen von Einstellungsinformationen verschachtelt werden? Das scheint in Visual Studio-Begriffen einer " Lösungs " -Datei / einem "

@fgallardograzio Wenn eine Projektkonfiguration mit Einstellungen in derselben Datei vermischt wird, wird die Kopplung

@Yemi , ja, mit Elcipse kann ich verschiedene Arbeitsbereiche öffnen
einfach Ordner, die verschiedene Unterordner enthalten, um Projekte darzustellen. ich
Verwenden Sie persönlich zwei Arbeitsbereiche, einen für die Entwicklung der Eclipse-IDE und einen für
Alle meine arbeitsbezogenen Projekte. Das Hauptproblem ist, dass die Einstellungen gerecht sind
Vom Menschen lesbare Dateien, die in ihren jeweiligen Einstellungsordnern gespeichert sind - http://wiki.eclipse.org/IRC_FAQ#Where_are_Eclipse_preferences_stored.3F -
das ist sehr logisch für mich.

Ein Kommentar / Tipp, der für jede IDE erwähnenswert ist, wenn Sie dies getan haben
Standalone-Projekte, sagen Sie workspace/your-awesome-library , die Sie möchten
als Teil eines anderen Projekts sagen
workspace/my-wiget/libraries/your-awesome-library man kann Junctions verwenden
oder Hardlinking je nach Betriebssystem - ich finde das sauberer als Git / HG-Subrepos
Konzepte.

Am Dienstag, 19. September 2017, um 10:33 Uhr, Yemi Bedu @ P & R [email protected]
schrieb:

@danielsokolowski https://github.com/danielsokolowski Ich verstehe das
Vorstellung eines Projekts, das einen Arbeitsbereich für Einstellungen überschreibt. In vscode du
haben allgemeine Einstellungen, Benutzereinstellungen (überschreiben allgemein) und Arbeitsbereich
Einstellungen (überschreiben Benutzer oder allgemein). Jedes Projekt hat bereits die
Möglichkeit, einen eigenen .vscode-Ordner zu haben (Arbeitsbereichseinstellungen befinden sich darin).
Schlagen Sie einen zusätzlichen Ordner vor, in den Projekte nur verschachtelt werden sollen?
Einstellungsinformationen teilen? Das scheint einer " Lösung " ähnlich zu sein
Datei / Ordner in Visual Studio-Begriffen.

@fgallardograzio https://github.com/fgallardograzio Ein Projekt haben
Die Konfiguration, die mit den Einstellungen in derselben Datei vermischt ist, wird erzwungen
Kupplung. Das UI-Zeug klingt viel besser als ein anderes Feature, das von getrennt ist
diese Ausgabe Ticket. Jetzt, wo der Insider-Build ein schönes Layout hat
Zusätzliche Wurzeln in der Datei, möglicherweise kann eine Erweiterung die Lücke für die Benutzeroberfläche füllen
Teil. Vielen Dank. Schönen Tag.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/Microsoft/vscode/issues/396#issuecomment-330558669 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AAQsBajECULDuQiqUZj6SRdfwJG-Bcw0ks5sj9CfgaJpZM4Gm3nX
.

- -
Daniel Sokolowski
Technischer Architekt

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

Vertraulichkeitserklärung:
Die übermittelten Informationen sind nur für die Person oder Organisation bestimmt
welche es angesprochen wird und vertraulich und / oder privilegiert enthalten kann
Material. Jegliche Überprüfung der Weiterverbreitung oder sonstigen Verwendung von oder
Ergreifen von Maßnahmen in Abhängigkeit von diesen Informationen durch Personen oder
andere Stellen als der beabsichtigte Empfänger sind verboten. Wenn Sie erhalten haben
In diesem Fall wenden Sie sich bitte umgehend elektronisch an den Absender
Übertragung und löschen Sie dann sofort diese Übertragung einschließlich aller
Anhänge ohne Kopieren, Verteilen oder Offenlegen.

Wird diese Funktion noch nicht hinzugefügt?

Das ist sehr wichtig für mich. Ich arbeite an einem Projekt, das aus zwei separaten Repositories besteht: dem Web-Frontend und der API. Es wäre schön, wenn ich beide Ordner in einem einzigen "Projekt" öffnen könnte.

Sicher, ich könnte das lösen, indem ich die 2 Repos in einen einzigen Ordner klone und diesen Ordner öffne, aber das funktioniert nicht in jedem Fall. Insbesondere, wenn Sie mehrere Projekte haben, die von einem einzigen Repository abhängen (dh dieselbe API verwenden).

Diese Funktion ist auch für Benutzer nützlich, die Code als Dokumentation verwenden.

@JamesTheHacker verwendet für eine Weile vscode-Insider, die mehrere Projekte gleichzeitig unterstützen. Und Sie können Funktionen vorschlagen, je nachdem, was Sie mit der Insider-Version denken, um sie besser zu machen

Wenn dies ausgeliefert wird, sollte die VSCode-Version wahrscheinlich auf 2.0 stoßen. Nur sagen :)

Kurze Frage zu dieser Funktion:

Diese Funktion unterstützt das Hinzufügen mehrerer Ordner mit Repositorys zu einem vorhandenen Arbeitsbereich. Würde es auch eine Mono-Repo-Konfiguration unterstützen, bei der ich mehrere Projekte in einem Mono-Repo öffnen möchte, aber da sie sich in einem Repo befinden, haben sie kein eigenes Git-Repo. Aus Projektsicht haben sie also keinen .git -Ordner - einer der Ahnenordner hat sie.

Sie könnten sich fragen, warum Sie den Mono-Repo-Ordner nicht als einen großen Ordner öffnen und einfach dort arbeiten sollten. Es gibt zwei Antworten:

1. (für mich weniger interessant) Es gibt zu viele Projekte im Mono-Repo, und ich interessiere mich nur für einige davon.
2. Viele Plugins gehen davon aus, dass ein Projekt nur ein ... Projekt enthält. Zum Beispiel nur ein npm-Paket. Also suchen sie nach Dingen in der Wurzel des Projekts. Beispiele: das Plugin npm für VSCode, das Mokka-Plugin für vscode und viele Funktionen in VSCode selbst - ich kann beispielsweise keinen Pfad in launch.json angeben, der relativ zum ist aktuelle Datei, dh "der Ordner node_modules, der der nächste Vorfahr der aktuellen Datei ist".

Nach dieser kontextbezogenen Erklärung ist meine Frage einfach: Würde diese Funktion Projekte unterstützen, deren Ordner .git ein Vorfahr ihres Stamms ist? Wenn ja, wäre es möglich, diese Funktion in einem Mono-Repo zu verwenden.

@ Borekb Ja. Ich weiß nicht, wie die Leute bei Microsoft ihre Versionen verwalten, aber ich denke, es ist eine Funktion, die für einen Major groß genug ist

Nach dieser kontextbezogenen Erklärung ist meine Frage einfach: Würde diese Funktion Projekte unterstützen, deren .git-Ordner ein Vorfahr ihres Stamms ist? Wenn ja, wäre es möglich, diese Funktion in einem Mono-Repo zu verwenden.

Dies wird schon seit geraumer Zeit unterstützt, wenn Sie einfach einen Unterordner eines Git-Repos öffnen.

+1

Sublime und Atom tun es, was Sie sollten. Kein besserer Grund. Dies ist die NEUE MS, Leute, ich habe volles Vertrauen in dich. :) :)

Hallo,
@inestyne Wenn Sie @Jeyanthinath lesen, VSCode Insider verwenden , um diese Funktion bereits zu bewerten. Es gibt sogar eine Roadmap zu überprüfen. Verwenden Sie daher das Produkt und geben Sie Feedback, bevor es zu Stable migriert wird, damit wir alle das bestmögliche Produkt erhalten. Vielen Dank. Schönen Tag.

Lesen Sie einfach den Thread und verwenden Sie Insiders OMG. Ich werde mich abmelden ... ihr Trolle, die nicht lesen, seid unmöglich. Danke @ pr-yemibedu

Empfindlich

Da dieser Thread 2 Jahre lang ist und die Funktion derzeit im Insider-Build enthalten zu sein scheint, gibt es eine Möglichkeit, diesen Thread so zu markieren, dass dies offensichtlicher ist, als den gesamten Thread von oben zu lesen?

Eine Sache, die fehlt, ist die Möglichkeit, ein neues Fenster mit einem neuen Arbeitsbereich über die CLI zu öffnen.

@jearle Ein neues Fenster / Arbeitsbereich sollte wie zuvor mit code-insiders <folder> , nein?
code-insiders -a <folder> wird benötigt, um den Ordner zum aktuellen Fenster hinzuzufügen.

@Jeyanthinath danke! Ich habe das Gleiche getan wie

@Tyriar Um die gewünschte Funktionalität zu erhalten, muss ich die folgenden Befehle ausführen:

code .; code -a .

code . öffnet den Ordner als Nicht-Arbeitsbereich, und das code -a . hängt sich selbst an das zuvor geöffnete Fenster als Arbeitsbereich an, sodass ich denselben Ordner mehr als einmal öffnen kann.

Ich persönlich denke, das muss auch geändert werden. Ich arbeite mit ionic und einem benutzerdefinierten Server in zwei verschiedenen Git-Repos und es ist nicht sehr einfach. Die Möglichkeit, mindestens zwei separate "Projektregisterkarten" zu öffnen oder so, wäre großartig.

Ich habe von Atom gewechselt, weil es so fehlerhaft und langsam war.

@ dark-swordsman kannst du nativeTabs auf dem Mac aktivieren

@felixfbecker ist das unter Windows möglich?

Bearbeiten: Ich habe die Einstellungsdatei vollständig durchsucht und es gibt keine Option dafür. Deshalb frage ich.

Edit2: Außerdem gibt es keine eindeutige Ressource zum Aktivieren von vs insiders

Hallo,
@ dark-swordsman aktivierst du VS Insider nicht. Es handelt sich um einen VSCode-Build, der einige zusätzliche Funktionen enthält, die noch nicht stabil sind, und Ihnen in gewisser Weise einen zusätzlichen Editor-Namespace bietet, mit dem Sie arbeiten können (Sie können sie ohne Konflikte bei Einstellungen oder Erweiterungen nebeneinander installieren). Vielen Dank. Schönen Tag.

Die Unterstützung für Multi-Root-Arbeitsbereiche ist jetzt in der stabilen Version standardmäßig aktiviert.

In unserer Dokumentation finden Sie eine vollständige Erläuterung aller damit verbundenen Funktionen. Autoren von Erweiterungen sollten sich auf unser Wiki beziehen, in dem die neuen Erweiterungs-APIs erläutert werden, um Ihre Erweiterung für Multi-Root-Arbeitsbereiche vorzubereiten. Wir freuen uns, dass bereits einige Erweiterungen mit der Einführung der neuen Multi-Root-API begonnen haben. Vielen Dank dafür!

Bitte zögern Sie nicht, Probleme für Multi-Root einzureichen, wenn Sie darauf stoßen. Wir planen weiterhin Optimierungen und die Bereitstellung zusätzlicher APIs für Erweiterungen, die in Zukunft mit Multi-Root-Arbeitsbereichen arbeiten sollen.

Das ist großartig, aber wann wird es verfügbar sein? Sie sagen, es befindet sich im Stable-Build, aber ich habe den neuesten Stable-Build (1.17.2) und kann nicht darauf aktualisieren. In der Dokumentation, auf die Sie gerade verwiesen haben, heißt es außerdem, dass sie sich noch im Insider-Build befindet und bald in der stabilen Version enthalten sein wird.

Ich verstehe, dass es eine Weile dauern kann, bis der nächste Build veröffentlicht wird, aber ich habe gesehen, dass diese Benachrichtigung erwartet, dass er verfügbar ist.

Edit: Ich entschuldige mich für meine Ungeduld. Ich habe nur versucht, ein neues Fenster manuell zu öffnen (rufen Sie die EXE-Datei erneut auf), und es hat nicht funktioniert, aber nicht in Datei> Neues Fenster öffnen gesucht. Dies wird vorerst funktionieren. Ich freue mich auf die Veröffentlichung des nächsten Builds. 👍

@bpasero Bitte schließen Sie dieses offene Problem mit # 35849, da die erwartete Funktionalität als Teil dieser # 396-Funktion ausgeführt wurde.

Nur eine kurze Frage. Kann ich, wenn ich mehr Ordner geöffnet habe, wechseln, welchen Ordner ich kompilieren möchte? Im Moment ist es immer das erste in stabiler Version.

BEARBEITEN: Dies könnte für den Ersteller der PlatformIO-Erweiterung sein, aber ich frage auf beiden Seiten. Nur für den Fall ...

@DJManas Es hört sich so an, als ob dies an der Erweiterung liegt, mit der Sie sich entscheiden. Fragen Sie daher den Autor der Erweiterung.

@bpasero Ok, ich habe parallel getan, danke für die Antwort.