Vscode: Добавить поддержку открытия нескольких папок проекта в одном окне

Созданный на 21 нояб. 2015  ·  380Комментарии  ·  Источник: microsoft/vscode

Прямо сейчас кажется невозможным открыть несколько папок проекта в одном окне, что, по-моему, немного ограничивает. Если вы работаете над модульными современными проектами, это должно быть продуктивно.

feature-request workbench-multiroot

Самый полезный комментарий

Sublime, Atom, Webstorm - они также являются «легковесными» редакторами кода (кроме, возможно, Webstorm) и позволяют открывать несколько корневых папок из разных мест. Эти редакторы, вероятно, на 99% используются веб-разработчиками.
Код может конкурировать с ними благодаря гораздо лучшей поддержке Typescript (и это будет очень популярно, учитывая, что Angular 2 скоро появится), но только в том случае, если он даст разработчикам то, что они используют сейчас в качестве базовой функциональности.

Все 380 Комментарий

согласен, но может это решение для оптимизации памяти

+1

Я не уверен, что понимаю вопрос; это легкий редактор кода, а не IDE ... зачем вам открывать несколько папок «проекта», которые не являются иерархическими (где вы можете установить рабочий путь к общему родителю)?

Если вы работаете над модулями, которые разрозненно хранятся на диске, которые каким-то образом взаимодействуют друг с другом до такой степени, то они слишком тесно связаны, чтобы начать с ... являются ли ваши проекты родственниками? Если это так, просто откройте родительскую папку или родительскую / родительскую папку ... где бы ни был корень вашего "решения".

Что ж, если у вас есть несколько модулей (которые находятся в собственном репозитории git), которые не зависят друг от друга, но у вас есть один репозиторий, который использует эти зависимости, имеет смысл иметь возможность открывать эти независимые папки и вносить изменения, которые быть отраженным, чтобы вы могли протестировать его локально. Это все равно будет легкий редактор кода, но, имхо, более полезный!

Основная проблема с установкой проекта в качестве родителя заключается в том, что интеграция с git прекращается, однако есть и другие допустимые варианты использования, помимо наличия общего родителя.

@stoffeastrom звучит как вариант использования подмодулей; Я не уверен, как ваш проект будет ссылаться на другой, если только вы не использовали псевдонимы с каким-либо механизмом, таким как связывание npm и т. Д. Это проблема, которую менеджеры пакетов в основном предназначены для решения. Если модули тесно связаны, то это действительно не изолированные модули. Вы не сможете надежно внести изменения для поддержки одного проекта, не беспокоясь о том, что изменение будет иметь последствия для других потребителей в будущем. Даже с подмодулями они по умолчанию доступны только для чтения именно по этой причине.

В любом случае, то, что только что упомянул @Tyriar, является одной из причин, по которой я

Если я использую интеграцию git для фиксации, я фиксирую проект A или проект B?
Если я реорганизую имя класса в TypeScript, следует ли проводить рефакторинг в проекте A или проекте B, или в обоих? Что, если одно и то же имя класса существует в обоих проектах с разными значениями? Что, если одно слабо ссылается на другое?

Это всего лишь несколько примеров того, как что-то, казалось бы, простое может очень быстро стать очень сложным. Я думаю, что это было бы более запутанно и, честно говоря, менее полезно, чем использование alt-tab / cmd + tab между несколькими отдельными экземплярами VSCode, каждый из которых успешно управляет своим собственным изолированным рабочим путем без дополнительных усилий и проблем с граничными случаями.

Я не говорю, что это невозможно решить, но я не совсем понимаю, почему переключение между несколькими окнами и / или экземплярами является проблемой. Может я что-то упускаю ...

Sublime, Atom, Webstorm - они также являются «легковесными» редакторами кода (кроме, возможно, Webstorm) и позволяют открывать несколько корневых папок из разных мест. Эти редакторы, вероятно, на 99% используются веб-разработчиками.
Код может конкурировать с ними благодаря гораздо лучшей поддержке Typescript (и это будет очень популярно, учитывая, что Angular 2 скоро появится), но только в том случае, если он даст разработчикам то, что они используют сейчас в качестве базовой функциональности.

+1

+1

Как разработчик Go я считаю эту функцию чрезвычайно полезной в Sublime или IntelliJ Idea. Например, мой небольшой проект импортирует код из основной библиотеки Go или может импортировать какую-то стороннюю библиотеку. Поэтому мне нужно иметь возможность быстро переходить к ним и читать этот код.

+1. Решения для микросервисов репозитория с несколькими git очень болезненны в VS Code прямо сейчас, поскольку вместо этого думают найти другую IDE с поддержкой Typescript.

Нам определенно нужно какое-то «решение». Я нативный разработчик, и это почти всегда включает в себя создание набора библиотек / dll и последующее обращение к ним из какого-либо проекта основного приложения.
Если у нас есть несколько проектов, нам также понадобится «запускаемый проект», когда мы нажимаем «запустить».

Я также хотел бы поддерживать проекты и несколько корней git. Код, который я часто использую, находится в нескольких репозиториях git, и невозможность переключаться между ними, не закрывая текущую рабочую область и не открывая другую, просто чтобы развернуться и закрыть ее, чтобы открыть предыдущую, утомляет. Если я добавлю родительскую папку, в которой размещены все мои репозитории, я получу возможность перемещаться и искать среди моих файлов, но теряю интеграцию с git. Это настоящий облом.

Граница между «текстовым редактором» и «IDE» чертовски размыта, и мне все равно, что обозначено как VS Code. Что меня действительно волнует, так это то, на что способен инструмент и насколько безболезненно его использовать. Я думаю, что добавление поддержки проекта облегчило бы множество проблем для таких людей, как я.

Я также хотел бы увидеть работу интеграции с git, когда ваше рабочее пространство содержит несколько репозиториев, но я просто хочу убедиться, что такие люди, как @ Loren-Johnson, понимают, что они могут одновременно открывать несколько окон vs code.

Это ответ на: «невозможно переключиться между ними, не закрывая текущую рабочую область»

Вы имеете в виду, что № 2686 является дубликатом этого?

Извините, я неправильно прочитал описание и снова открыл это.

+1

Есть ли прогресс в этом вопросе или, по крайней мере, какое-то заявление, если это когда-нибудь будет реализовано? Есть ли в коде какие-то низкоуровневые решения, предотвращающие множественные корни в одном проекте?

Это практически единственная причина, по которой я не перехожу с ST3 на VSCode.

+1

+1

+1

+1 это было бы очень полезно. Предложение использовать подмодули git очень неудобно. Хотелось бы иметь эту функцию.

Первоначальный легкий подход был бы чем-то похожим на то, что делает расширение git-project-manager . Подход может заключаться в основном переключении контекста / корня для того, что git видит как изменения, но без изменения контекста / корня для того, что видит браузер файлов. Это расширение работает идеально, просто требуется более тесная интеграция, чтобы переключение было быстрее.

+1

+1 - Я начал использовать подмодули git, но это больше похоже на взлом, чем на реальное решение.

+1

+1

Я использую расширение git-project-manager для переключения между папками, но мне бы очень хотелось иметь возможность открывать сразу несколько папок.
+1

Сразу хочу сказать, что владелец расширения Project Manager тоже ожидает решения этой проблемы.

Что касается некоторых комментариев (выше), я просто хочу сказать, что мы все разные, у всех есть свои особые способы выполнения нашей работы над нашими конкретными проектами. Этот факт делает UX более важным, чем он есть сейчас.

Все мы знали, что «Открыть папку ...» - это всего лишь первый детский шаг к неизбежному включению управления проектами в vscode с такими вещами, как «Открыть проект ...» и так далее. Как и все другие редакторы, особенно SublimeText (откуда я родом).

Для меня эта проблема является улучшением UX продукта. И все мы знаем, что UX - король.

Я почти чувствую, что подобные вещи должны быть законом, и поэтому тег «запрос функции» должен быть вместо этого «напоминанием о функции».

Эта проблема должна иметь приоритет перед любыми другими проблемами в vscode. Не только потому, что UX - король, но и потому, что у меня сейчас нет никаких других проблем с vscode, кроме этой ... технически.

Изначально я просил Microsoft просто взять на себя эти проектные расширения и напрямую интегрировать их в VSCode, а также улучшить его UX, скажем, например, добавив «Проекты ...» в меню.

Благодаря,
+1

+1

Мой пример использования этой функции описан здесь: # 9515. (Он был закрыт как дубликат этой проблемы.)

Надеюсь, такая особенность появится!

+1

@ poidl, @ mastrauckas , @mdedgjonaj , @alanleite , @Xcorpio , @mibanez , @josebalius и @brusbilis :
Некоторое время назад GitHub представил прекрасную функцию «Добавить свою реакцию» (видите смайлы в каждом верхнем правом углу комментария или саму проблему?).
Они служат для информирования команды VSCode о вашем интересе, но предотвращают бессмысленные комментарии +1 . Это также предотвращает получение уведомления другими людьми, подписавшимися на определенную проблему или MR, и, следовательно, экономит драгоценное время. Еще один бонус заключается в том, что проблемы / MR могут быть отсортированы по most reaction что делает его мгновенно видимым для команды VSCode, что важно для пользователей. Вдобавок к этому есть даже резервуар для VSCode .

Этот комментарий сам по себе является мета, а значит, тоже бессмысленным. Мне очень жаль, но я думал, что это было необходимо в образовательных целях. Каждый прямой ответ на этот комментарий (= больше мета) приведет к тому, что я заблокирую пользователя.
Давайте поупражняемся, реагируя только на этот комментарий с помощью функции reaction !

На ответ @poidl : Тогда вообще не отвечайте!

Я не вижу этого смайлика. По крайней мере, на мобильном телефоне. Удачной блокировки!

@poidl да, к сожалению, функция реакции недоступна на мобильном сайте GitHub (наряду со многими другими функциями). Вы можете перейти к нему на мобильном телефоне, нажав кнопку «Версия для ПК» внизу сайта.

Однако совет @dj-hedgehog уместен, реакция GitHub позволяет нам более эффективно оценивать интерес сообщества к чему-то, чем количество комментариев. Кроме того, мы планируем отказаться от поддержки User Voice, поэтому проблемы и реакции GitHub являются нашим источником достоверной информации для запросов функций.

+1

+1

Мое решение этой проблемы: создать символическую ссылку на корень моего проекта.
Итак, если у меня есть:
project/modules/gitmodule

Я захожу в свою папку gitmodule и делаю:
ln -s ../../../project .project

Теперь я могу открыть папку gitmodule в vscode и по-прежнему иметь доступ к папке родительского проекта.
Я использую точку в имени файла, чтобы он находился в верхней части моего списка в проводнике.
Очевидно, я бы предпочел не делать этого, но я подумал, что это может быть полезно для некоторых из вас.

Чуть не забыл: не забудьте добавить символическую ссылку в свой .gitignore

+1

Это действительно важная функция для современного текстового редактора. Пожалуйста, решите эту "проблему".
Какое-то время мне приходилось копировать и вставлять все каталоги, которые используются в мою фактическую рабочую папку, и это в Sublime Text настолько тривиально.

Проект> Добавить папку в проект в Sublime Text увеличивает новый путь к структуре Json.

Посмотрите ниже:
{ "folders": [ { "path": "~/cpp" }, { "path": "~/python" } ] }

Например, при работе с поваром можно увидеть такую ​​структуру папок:

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

Где поваренные книги (например, cookbook1) в корневой папке (поваренные книги) являются независимыми репозиториями git. Это очень часто. Теперь вам нужно поработать над cookbook4, но она включает cookbook2 и cookbook3. Часто вам нужно будет открыть все 3 кода, чтобы просто сослаться на код, либо для редактирования или рефакторинга кода во всех 3.

Два обычных варианта (не взлома символических ссылок) представляют проблемы, которые не нужны ни одному разработчику:

  1. Как уже много раз упоминалось выше, теперь вам придется открывать несколько окон (не очень хорошо)
  2. Если вы откроете кулинарные книги как root, чтобы увидеть все 3, вы потеряете интеграцию с git, поскольку папка с кулинарными книгами не является репозиторием (также не очень хорошо)

+1, пользователь Eclipse IDE здесь, у которого есть полный контроль над «рабочим пространством».

Visual Studio Code не является IDE. Это легкий кроссплатформенный редактор, такой как Atom или Sublime. Eclipse, Xcode, Visual Studio и др. все по сравнению с ними чудовища.

Извините, я не уверен, возражаете вы против или за эту функцию ... Atom, Sublime, VIM, Emacs позволяют вам открывать несколько папок в одном экземпляре. Небольшой вес или нет, это хорошая функция, например, IntelliJ IDEA - IDE - не позволяет вам открывать несколько проектов.

@dmccaffery Запрошенные здесь функции - это не просто функции IDE.

Atom, Sublime и другие легкие редакторы могут открывать несколько папок.

Меня лично не волнует, попадет ли эта функция в продукт или нет - я понимаю, почему некоторые люди этого хотят, но я хотел бы отметить, что это делает все немного более запутанным. Например: при поиске с использованием выражения регулярного выражения - в каком рабочем пространстве я ищу? один? все?

Что делать, если у меня есть одна папка, содержащая проект nodejs, где ширина вкладки обычно составляет 2 пробела, а одна папка - проект dotnet, где ширина вкладки составляет 4 пробела? Код должен знать настройки рабочего пространства для каждой папки и поддерживать контекст повсюду.

Это всего лишь несколько примеров, когда несколько рабочих пространств в одном экземпляре могут быть затруднены. Все, что я говорю, это то, что эта функция гораздо сложнее, чем просто отображение нескольких путей в проводнике.

@dmccaffery не более запутанный, чем возвышенное и атом. Все это должно быть настраиваемым, даже ширину вкладок для каждой рабочей области. Искать в атоме и возвышенном можно только в текущем файле, в этой рабочей области и т. Д. Это ваш выбор.

Вот факт, нравится вам это или нет, и он не имеет ничего общего с тем, что вы или я хотим. Если другое аналогичное программное обеспечение по аналогичной цене (в данном случае бесплатное) имеет лучшие или более функциональные возможности, и разработчик пренебрегает этим фактом, .. это программное обеспечение останется позади.

Я лично не хотел бы, чтобы это случилось с этим редактором. Я думаю, что у этого редактора очень хороший потенциал, и он может оставаться актуальным в течение некоторого времени, если разработчики прислушиваются к пожеланиям / потребностям его пользовательской базы.

Очередной раз; Я не спорю за или против - просто имейте в виду, что это очень новый редактор с гораздо более нестандартным контекстом, чем его конкуренты - дайте ему немного времени.

Даже в вашем примере с интеграцией chef и git - как вы поддерживаете контекст относительно того, какое репо вы собираетесь использовать? Текущий пользовательский интерфейс необходимо адаптировать к постоянному переключению контекста - то же самое для OmniSharp, который использует сервер и roslyn для выделения синтаксиса и т. Д. Для проектов CoreCLR. Последствия далеко идущие, и их нужно будет очень хорошо продумать.

Нет аргументов в пользу того, что функции должны быть хорошо спланированы и продуманы. Я думаю, это данность. Я думаю, что все пользователи были бы счастливы, если бы здесь ответ был «это в дорожной карте» или «мы работаем в этом направлении». Все, что я говорю, это то, что «нет», вероятно, убьет довольно много пользователей за ночь.

Что касается переключения контекста и репозиториев git в chef, да, согласен ... все это правда, и все это уже выполнено в других редакторах с открытым исходным кодом. Вы знаете, что такое открытый исходный код, он открыт! Посмотрите на код, почерпните идеи, черт возьми, даже используйте некоторые из них (не забудьте включить лицензирование по мере необходимости). Это одна из замечательных особенностей foss (бесплатное программное обеспечение с открытым исходным кодом), сотрудничества и обмена знаниями. Поскольку этот редактор уже использует атомный код ... Я думаю, это тоже само собой разумеющееся.

Я нашел это упомянуто в https://github.com/Microsoft/vscode/wiki/Roadmap

VS Code - молодой продукт, и в нем все еще отсутствуют функции и возможности, которые вы просите и которые мы хотим предоставить.
....
....

  • Несколько папок в одной рабочей области

Я думаю, никто не говорит, что эта функция проста (поскольку все мы разработчики, мы знаем, что нужно изменить), и я приглашаю людей, комментируя этот тикет, просто хочу показать, насколько он важен, насколько он должен быть приоритетным, и как сравнить эту функцию с некоторыми братьями VS Code (например, Atom, Sublime).

Но поскольку это уже включено в дорожную карту (любой может подтвердить, что страница вики по-прежнему верна), мы должны обсудить, как это реализовать, вместо того, чтобы просто говорить, как нам нужно и насколько это важно (опять же, я полагаю, что основная команда VS Code уже знать, как нам это нужно и насколько важна эта функция).

Я не знаком с исходным кодом VS Code, может ли кто-нибудь сказать мне, хочу ли я реализовать эту функцию, где я должен искать в первую очередь? На первом этапе я просто хочу открыть несколько папок и показать их на левой панели.

@nvcnvn реализовать это не так тривиально, как может показаться, поскольку большая часть vscode предполагает, что можно открыть только одну папку. Таким образом, он должен будет пройти через UX и, вероятно, затронуть многие части кодовой базы, что потенциально также повлияет на API расширения.

Я помню, когда вышел Atom с тем же ограничением на использование одной папки. Жалобы тоже были такими же, особенно по сравнению с Sublime. Затем, когда была выпущена поддержка _multiple folder_, некоторые пакеты (расширения) были сломаны из-за нового API. Другие не сломались, но и не поддержали. Прошло некоторое время, прежде чем он стал стабильным во всей экосистеме.

Как сказал @Tyriar , будет некоторое влияние на UX и API расширений, и, вероятно, будет загружен выпуск _Insider_ для разработчиков ядра и расширений, чтобы принять новый API.

Так о чем именно здесь спорят?
Я имею в виду, что все, что я вижу, это «не делайте улучшений, потому что это может что-то сломать» ...

Подсказка:
ВСЕ УЛУЧШЕНИЯ В КОДЕ МОГУТ ЧТО-НИБУДЬ!

Это точка отладки, рефакторинга, предварительных релизов (альфа, бета, rc и т. Д.)
Давай, серьезно? Я никогда не встречал серьезного программиста, который боялся улучшать код, потому что он мог что-то сломать. Будьте осторожны, да, не торопитесь и будьте в безопасности, да, но никогда не говорите «нет, это может сломать вещи» lol

@ddreggors Я не спорю, я просто @nvcnvn не пытался построить PR для этого, поскольку это должно быть сделано командой из-за списка заинтересованных сторон.

Как отметил @nvcnvn , эта проблема находится в дорожной карте, что означает, что команда скоро ее рассмотрит. У нас относительно небольшая команда, но нам нужно охватить много вещей, поэтому некоторые вещи нужно отложить.

@Tyriar Понятно, я просто продолжаю видеть эти комментарии от нескольких людей, которые, кажется, предполагают, что по той или иной причине лучше не добавлять эту функцию. Худшее из них было связано с тем, что код не является IDE, когда другие явно сравнивали другие редакторы, а не IDE. Из-за этого мне захотелось добраться до корня страха перед этим изменением, чтобы по возможности преодолеть его.

Я могу понять беспокойство по поводу того, что этот PR не завершен, однако это могло бы быть хорошим началом ... объединить это изменение с веткой и использовать ее как основу. Используйте это, чтобы увидеть поломки и исправить их.

@ddreggors было бы потрачено зря, если бы кто-нибудь прикоснулся к этому, прежде чем он будет обсужден на одной из наших встреч по UX

Честно говоря, вам лучше знать об этом. Приятно знать, что это обсуждается. :-)

Спасибо за старания и, похоже, начало очень хорошего редактора.

Также кажется напрасной потерей усилий предлагать эту тему для ваших встреч по UX :–)

Я временно переключился на Atom, так как в версии 1.9 он стал намного стабильнее. Раньше он вылетал при открытии любого большого файла, и это было основной причиной начала проверки VSCode в какой-то момент. На самом деле с нетерпением жду возможности увидеть несколько проектов в одном окне - похоже, что до тех пор мне нечего делать, кроме как следовать этой теме.

Почему люди Microsoft не концентрируются на этом?

+1

+1

Мне очень нравится VS Code. Он стал моим основным редактором, но сложность работы более чем над 2 проектами одновременно становится затруднительной. По этим двум открытым вопросам есть двойной удар: этот и настройка информации в строке заголовка .

Любая из этих функций решит проблему (хотя в идеале мне хотелось бы и то, и другое!). Я не против поместить все, с чем я работаю, в одну папку и открыть ее, но тогда интеграция с git не работает, и нет тривиального способа поиска только в одном проекте или организации результатов по проектам.

Я не против открывать каждый проект в другом физическом окне VS Code и позволять моей ОС управлять экземплярами, но поскольку в строке заголовка сначала отображается имя открытого файла, а не идентификатор корневой папки / проекта, невозможно переключиться на другой конкретный открытый проект без открытия и просмотра каждого активного экземпляра. Это превращает то, что должно быть легким, в постоянное раздражение.

Пожалуйста, есть ли способ сделать добавление одной из этих двух функций приоритетной? Я пробовал все, что мог придумать, чтобы обойти это, я даже потратил час на поиски альтернативы панели задач Windows, которая позволила бы мне выбрать окна из списка, которые могли бы отображать больше текста в заголовке, но я не могу найти что-нибудь.

Если у кого-то есть предложения о том, как эффективно управлять несколькими открытыми проектами VS Code, я хотел бы их услышать.

Важная вещь, которая хорошо работает в Atom, заключается в том, что плагины, такие как eslint, по-прежнему должны работать на уровне проекта. Поэтому, если у проекта A есть свои собственные правила eslint, на проект B эти правила не должны влиять, и наоборот. Не могу дождаться появления такого UX в коде. Это определенно одно из, если не самое большое препятствие для внедрения прямо сейчас.

Это единственное, что заставляет меня принять его.

Я знаю, что у вас может быть много других проблем, которые нужно исправить, и другие функции, которые нужно реализовать, но, по крайней мере, некоторая базовая поддержка для начала работы была бы замечательной.

Спасибо за тяжелую работу над VSCode!

+1

Пока эта функция не будет реализована (если когда-либо), могу ли я предложить вам просто добавить возможность настроить строку заголовка, чтобы отображать имя проекта перед именем файла. Таким образом, по крайней мере, можно будет различать разные окна vscode, открытые для разных проектов. См. № 1723 .

Для меня это тоже шоу-пробка. Я вижу, что некоторые разработчики задаются вопросом, почему у вас сразу несколько репозиториев git. Это происходит практически с любым языком, использующим сторонние модули. Просто посмотрите на php - composer, js - bower, node - npm, golang и т. Д. Очень часто запускают проект, в котором используются некоторые из ваших модулей, и вы хотите отредактировать и зафиксировать изменения в рамках проекта.

Есть ли хотя бы поддержка распознавания .vscode/settings.json во вложенных каталогах. При работе над одним проектом могут быть поддеревья с разными наборами настроек, которые поступают из разных (git) репозиториев. например

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/

Я ожидал, что vscode примет (и, возможно, объединит) настройки ближайшего родительского каталога, как и множество файлов конфигурации ( .eslint , .gitignore , .editorconfig , tsconfig.json , 'package.json` ....).

Итак, когда я открываю /root , тогда любой файл в root/server/ должен обрабатываться так, как если бы я открывал root/server/ напрямую. Самым простым решением было бы прекратить поиск настроек в родительских каталогах при обнаружении файла .vscode/settings.json .

Это действительно необходимо.

+1. Для меня нарушитель сделок.

Это действительно необходимо. +1

есть обходной путь для вложения папок в рабочую область vscode. просто для создания символьной ссылки на папку рабочей области, например mklink /d link target

Согласен - считаю, что эта просьба - определенное требование.
У вас не всегда есть проект в одной папке - у вас могут быть вспомогательные и родственные папки, и отсутствие этой функции сейчас для меня является настоящим препятствием - вот почему я должен использовать возвышенное.
Пожалуйста, добавьте это!

Слева вы показываете папку, в которой вы находитесь, как проект. Это могло бы сработать, если бы у вас было так, чтобы вы могли видеть каждую открытую область папки (проект). Вы можете развернуть и свернуть его, как сейчас (но для нескольких областей папок).

Отличный редактор, если бы я мог переключаться между двумя проектами. Настоящий нарушитель сделок.

Привет всем, я рекомендую расширение Git Project Manager, если вы тем временем много переключаетесь между проектами. Он сканирует каталог на наличие каталогов, содержащих папку .git и позволяет быстро переключаться на них, я использую его в течение нескольких недель, и это, безусловно, упрощает работу.

Когда я переключаю проекты, я либо иду:

  1. ctrl + alt + p
  2. Введите начало проекта, например. "vsc" для vscode
  3. войти

Или, если я хочу открыть проект в другом окне, я заранее нажимаю ctrl + shift + n . Вы можете настроить расширение так, чтобы оно всегда открывалось в новом окне, если вам это тоже нравится.

untitled-1

Это снимок экрана, демонстрирующий, как легко создать несколько проектов.

@ soljohnston777 проблема в том, что интеграция git (или любая другая конфигурация кода VS) не поддерживается на уровне папки.

проблема в том, что интеграция с git (или любая другая конфигурация кода VS) не поддерживается на уровне папки.

Да правда? Повторил ли VSCode ошибки, которые были допущены затмением, когда дело доходит до концепции рабочего пространства? Это было бы удивительно, зная, что довольно много членов команды VSCode были частью основной команды eclipse ....

Повторил ли VSCode ошибки, сделанные затмением, когда дело доходит до концепции рабочего пространства?

Я не могу здесь говорить о философии архитекторов, но этот факт (эта конфигурация для каждого экземпляра, а не для папки) является единственной причиной этой проблемы и обсуждения.

Вы можете использовать отдельные окна VScode для проектов. Почему бы не реализовать это так внутри VSCode? (Отдельное окно для каждой кнопки бокового проекта - просто укажите его внутри). Это избавит от необходимости писать код внутри программы, но проекты будут отображаться внутри, и упростит интеграцию и разработку.

Git может быть независимо размещен для каждой области папки для нескольких проектов ... Я считаю, что git сбивает с толку VSCode, поэтому в любом случае я предпочитаю просто использовать командную строку (что, похоже, вы сможете сделать это в VSCode).

Наличие в родительской папке вложенных папок, которые являются независимыми репозиториями git, действительно полезно, когда все они принадлежат одному проекту. Хотелось бы, чтобы это было доступно, по крайней мере, с дополнительным флагом конфигурации в настройках.

Я также хотел бы выразить свою сильную заинтересованность в поддержке git для нескольких репозиториев git.

+1. Это основная функция, которая не позволяет мне принять VSCode в качестве основного редактора.

+1

+1 - особенно для людей, которые работают с кодовыми базами микросервисов / многих репо, это ключ. (Ключ: не открывать все сразу, а переключаться между ними, и чтобы редактор запомнил, какие файлы были открыты и в каких рабочих областях.)

+1
Наша установка - это что-то вроде основного кода в репозитории GIT, некоторого регионального кода в другом репо и конкретного кода проекта в другом репо, поэтому, когда вы работаете над проектом, вам нужно кодировать из всех трех (или более) репозиториев. Невозможность иметь «проект» с его собственными специфическими настройками и возможность добавлять несколько папок из нескольких источников - это король блокиратора.

@danechitoaie, откуда вы знаете, что изменение, которое вы вносите в основное репо, не нарушает работу кого-то еще, полагающегося на него для другого региона или базы кода проекта? Похоже на опасный способ работы; должно быть отдельное управление выпуском с использованием какой-то системы управления пакетами или чего-то подобного.

Не возражаю против некоторой реализации рабочих пространств, но полноценная система проектов добавляет изрядную сложность.

Согласитесь, это так, и они должны / могли бы сделать намного лучше, но ... это вне нашего контроля или способности принимать решения "смертными пользователями" ...

Понятно. Я люблю, когда такое случается.

b2r1ifriyaa-bnh
Как насчет этого?

Для меня такой простой кнопки переключения просто недостаточно. Если нам нужен только этот простой, откройте 2 экземпляра (ctrl shift N), а затем используйте горячую клавишу вашей ОС для переключения между окнами / рабочими пространствами.
Мне нравится иметь что-то, что упрощает сравнение файлов, структуру проектов, что-то, что помогает мне быстро вносить незначительные изменения и создавать и сохранять все различия на одном экране, что позволяет отменить изменения для всех проектов, с которыми я работаю.

+1

+1

Вид обходного пути для macOS Sierra.

Одна вкладка для каждого проекта в одном окне, установив Prefer tabs when opening documents на Always в настройках док-станции. Но это повлияет и на поведение других приложений.

+1

Это становится для меня убийцей. Мне нравится программа, но, черт возьми, мне не нравится, когда у меня только одно окно ...

Честно говоря, мне пришлось прекратить использование кода, потому что, как бы мне это ни нравилось, переключение окон стало слишком громоздким.

Если это будет исправлено в будущем, я попробую еще раз, до тех пор, пока это будет препятствием для меня и каждого человека, которого я тестировал.

+1

+1

Пожалуйста, предпочтительнее: +1: реакция на исходный комментарий к проблеме, поскольку это помогает нам расставлять приоритеты и не отправляет уведомления всем, кто слушает проблему, для получения обновлений.

+1

В настоящее время я использую Sublime и пробую Code. Он выглядит и приятен на ощупь, но интеграция с Git для одного проекта - это серьезное нарушение. У меня есть проект Hadoop / Oozie, поэтому у меня есть одно репо кода, а другое - рабочих заметок. В Sublime они оба открыты в одном окне, и я могу зафиксировать соответствующий репозиторий Git для каждого

так что будет хорошо добавить

+1 Ага, критично в мире микросервисов, обычно одновременно открываются 3..4 репозитория

Еженедельное напоминание: прекратите публиковать комментарии с помощью +1. Вместо этого дайте высокую оценку исходной проблеме, которая действительно считается.

Я знаю, что вы все имели в виду. Так что не стесняйтесь удалять свой +1 комментарий, чтобы он не занимал место и в этой важной исторической записи!

@jamietre Я пытался ... сильно:

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

Может быть, другая альтернатива - заблокировать эту проблему, но оставить ее открытой до тех пор, пока она не будет решена? Таким образом, мы знаем важность проблемы (я бы сказал, что у нас уже достаточно +1 для нее), но не можем добавить к беспорядку / избыточности (например, комментарии больше не разрешены).

Хотя я думаю, что это редко используемая функция, я столкнулся с ограничением только одного общедоступного проекта / репозитория на Github.

Блокировка может быть разблокирована, когда это будет сочтено необходимым, если когда-либо.

@daluu вот как работает репозиторий / aspnet / announcement; каждый выпуск немедленно блокируется. При этом GitHub должен что-то делать в пользовательском интерфейсе, чтобы хотя бы подтолкнуть людей к альтернативам, выходящим за рамки «+1», поскольку теперь есть реакции. 👍

Очень полезно включить многооконную функцию в целом при просмотре документов более чем двух проектов,

интересный подход к проблеме. Я много лет был программистом VB / .net, любил языки и инструменты, но несколько лет не работал в Hadoop / Spark / Scala / Intellij / Sublime-land. Я до сих пор слушаю DotNetRocks, чтобы быть в курсе того, что происходит, и мне было интересно услышать об этом приложении Code. С положительной стороны, это очень хороший редактор с некоторыми симпатичными функциями Git, но, к сожалению, это совершенно неуместно. Поскольку он не обрабатывает Git для нескольких проектов в одной рабочей области, как это очень элегантно делает Sublime, я просто не могу его использовать.

Что происходит. Что меня больше всего удивляет, так это реакция здесь, сначала на утверждение, что это не обязательная функция, а затем большая часть обсуждения теперь, похоже, ведется вокруг того, «как мы можем остановить людей, публикующих +1»

Я расскажу, как это сделать - вы решите основную проблему, которая впервые возникла год назад! Это называется «прислушиваться к обратной связи». То, что проблема не касается вас лично, не означает, что ее не существует. Если вы не хотите, чтобы определенная группа пользователей использовала приложение, то хорошо, но не давайте нам механизм обратной связи, затем оспорите нашу проблему, а затем рассердитесь на нас за то, что мы продолжаем просить об этом.

Я снова использую Sublime

Проблема "+ 1" может быть исправлена ​​с помощью следующего кода: if (post_message == "+1") {add_smiley_reaction (); delete_post_message (); }

Уважаемый GitHub, меня можно нанять.

да, это никогда не будет исправлено, не так ли. Намного проще высмеивать и игнорировать комментарии «+1», чем на самом деле решать основную проблему, поскольку программное обеспечение продается определенной группе разработчиков, которая не делает то, что необходимо для их продуктивности ...

просто прочтите этот «Каждый прямой ответ на этот комментарий (= больше мета) приведет к тому, что я заблокирую пользователя». - вот как управлять обратной связью! Засуньте пальцы в уши и скажите "тебя не слышу!"

о Боже

@ kryps1, тогда люди добавят «+1», или «++ 1», или «1+», или «удар», или «Да, пожалуйста. +1». Что бы вы ни делали, люди найдут способ обойти это. Это не так просто, как вы думаете.

Прекратите бесполезные споры о +1 , пожалуйста ... Сосредоточьтесь на том, что здесь нужно, а именно на нескольких проектах в проводнике.

Для проблемы git ее просто нужно разделить так же, как и проводник (то есть cwd).

Давайте не будем начинать войну из-за +1. Было бы неплохо, если бы этому вопросу был отдан приоритет.

Но я хотел бы упомянуть сообщество, я предполагаю, что PR и взносы приветствуются ;-) кто-то может исправить / исправить код, если основные разработчики этого не сделают. Некоторые из моих проектов были улучшены (с помощью форков), потому что пользователь / разработчик скорее сделает это сам, чем ждет, пока я внесу улучшения, которые они хотели бы мне предложить. Итак, кто-нибудь, кого раздражает эта проблема и достаточно способный / опытный, исправьте (а затем отправьте PR)? смешно

И вернемся к теме +1, поднятие проблемы и добавление своего мнения - это хорошо, но +1 - не лучший способ сделать это, если есть другие методы, такие как функция большого пальца вверх. Рассмотрим публикацию в Facebook или исходную публикацию в Google+, и пользователи / читатели добавляют комментарий +1 вместо того, чтобы нажимать «Нравится» (или одна из новых реакций Facebook) или +1 для Google+. Со временем это длинная ветка комментариев, состоящая из неубедительных +1, где, когда я читаю, я могу прокручивать интересные комментарии, но в итоге вижу кучу +1. Это то, что здесь происходило, я бы предпочел не видеть / читать эти +1, независимо от того, являюсь ли я разработчиком проекта или просто пользователем (или исследую этот проект для потенциального использования).

В связи с этим, вот глупое (но доброе намерение) использование проблемы GH, слава богу, люди не все пошли по ней +1: https://github.com/sinatra/sinatra/issues/920

Я полагаю, PR и взносы приветствуются

На самом деле, нет. См. Этот комментарий от августа: https://github.com/Microsoft/vscode/issues/396#issuecomment -241806158

Очевидно, эта проблема присутствует в дорожной карте, по крайней мере, с тех пор, но по ней не было прогресса. Было бы неплохо услышать обновление статуса от команды VSCode.

Для меня, и это попытка вернуть тему в нужное русло, необходимо несколько папок проекта.

В Atom он поддерживает GIT, и я использую его только для того, чтобы отмечать, в каких файлах есть изменения. У меня есть сервер Rackspace, который не поддерживает SSH, поэтому я загружаю его вручную. Однако у меня может быть несколько папок проекта на боковой панели, и это значительно упрощает ссылку на код, который я использовал в предыдущем проекте. Или переключитесь на другой проект, если мне нужна передышка.

С VSCode проблема, которая мешает мне переключаться, и я хочу переключиться, заключается в отсутствии нескольких папок проекта на боковой панели.

Я имею в виду, что я мог бы просто открыть корневую папку, чтобы временно решить эту проблему, но если мне нужно всего 3/20 папок, и я не хочу видеть незакрепленные файлы, тогда это должно быть легкой реализацией, верно?

Обновление: скоро появится большое обновление верстака - горячий выход (# 101), пока мы работаем над горячим выходом, мы активно обсуждали эту проблему, чтобы гарантировать, что дизайн учитывает несколько папок.

Эта проблема в настоящее время имеет номер 2 с точки зрения: +1: реакции на все проблемы (номер 1 в верстаке с длинными тегами), поэтому очень вероятно, что это следующая большая часть работы для верстака после горячего выхода.


О: +1: комментарии; они служат только для того, чтобы раздражать более 80 человек, подписавшихся на выпуск. Однако голосование по проблеме с реакцией - один из самых действенных способов повлиять на проект.

Также имейте в виду, что мы относительно небольшая команда и что чистота кодовой базы и производительность vscode очень важны, поэтому нужно время, чтобы все сделать правильно. В частности, для чего-то вроде этого, которое является фундаментальным изменением того, как vscode был создан на сегодняшний день, в этом вопросе довольно много работы.

+1

Действительно, это была бы удобная функция.

Я перешел с Atom, и он мне очень понравился, но я работаю над двумя приложениями пользовательского интерфейса и еще двумя SDK, но невозможность быстрого переключения между этими проектами (или папками) является важным недостатком, я думаю, мне следует вернуться к Atom до этого. решено

Я действительно с нетерпением жду этой функции ~~~

Я разработчик golang, использующий vscode, надеюсь, у него есть реализация, спасибо!

Я пытаюсь переключиться с Sublime на VScode. И вскоре я обнаружил, что VScode, не поддерживающий несколько папок в концепции «проекта», действительно мешает мне делать это.

Мне очень нравятся другие функции этого «легкого» редактора. Между тем я считаю, что поддержка нескольких папок в «проекте» не сделает VScode «лишним» или «подобным IDE». Это просто сделало бы более удобным для разработчиков, использующих другие редакторы, чтобы сделать переход менее болезненным.

Надеюсь на это улучшение. Благодаря!

Также, если команда может добавить возможность сохранения настроек на основе проекта, которые переопределяют настройки по умолчанию, это будет здорово. Вариант использования в том, что у меня могут быть разные интерпретаторы для разных проектов. Также поможет наличие вкладок разных размеров и т. Д. Пожалуйста, дайте мне знать, возможно ли это уже каким-либо образом.

Как разработчик, мы всегда работаем над несколькими проектами, и у нас есть собственные побочные проекты. Настройка параметров проекта (настройки рабочего пространства для vscode) каждый раз, когда я переключаю проект, является большой проблемой.

@bajubullet Вам следует попробовать https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig Не уверен, что он охватывает все, что вам нужно, но это только начало.

@danechitoaie спасибо за ответ. EditorConfig не помогает, я могу указать свойства для каждого типа файла, но если я смогу сохранить их как настройки проекта, это будет проще, и мне не нравится иметь .editorconfig для каждого проекта. Также в случае расширений, таких как расширение python, которое позволяет нам предоставить интерпретатор для использования, это не поможет, потому что python.pythonPath не поддерживается через editorconfig. Пожалуйста, дайте мне знать, если мне что-то здесь не хватает. Любые предложения приветствуются.

Я согласен, я также очень жду каких-то настроек для конкретного проекта и возможности открывать несколько «корневых» папок. Это единственное, чего мне не хватает в Sublime.

Это скоро будет реализовано!

Так что не нужно продолжать добавлять в этот пост. Если у вас есть другие проблемы, создайте новую тему. Благодаря!

Это довольно длинная цепочка, я прочитал, наверное, треть, но просто хочу выразить свою поддержку. Я только что установил VS Code с https://github.com/JuliaEditorSupport/julia-vscode в качестве возможной замены Atom / Juno. Это прекрасно! 😍

Однако при разработке кода Julia я считаю очень важным иметь возможность открывать несколько пакетов в разных папках. В принципе, я мог бы открыть папку выше, но это откроет доступ к сотням установленных мною пакетов Julia. Я также мог бы изменить свой LOAD_PATH, но я бы предпочел решение VS Code.

Я искренне надеюсь, что смогу открыть несколько папок. Спасибо за старания 👍

Всем привет! Как вы, возможно, заметили, мы изучаем реализацию этой проблемы в ходе этой итерации.

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

Изучите многокорневые рабочие пространства в различных компонентах @team

Я хочу поговорить с 3-5 из вас о ваших сценариях использования, пока мы обдумываем детали реализации. Пожалуйста, запишитесь на 15-минутный временной интервал в следующий вторник, если сможете. Я бы хотел поболтать.

переключение между моим api и ui сводит меня с ума ... :-(

@ehartford по какой-то конкретной причине у них нет общего родителя?

Да. Интеграция с Git не работает, если я просто открою родительский каталог.

@ehartford веская причина: smile:

@waderyan вы ищете только варианты использования _end user_ или _ разработчиков расширений_ тоже?

Как конечный пользователь_ поддержка нескольких папок была полезна в большинстве случаев для _поисковых целей_. Я использовал для создания проектов, добавляя разные папки из разных API, просто для упрощения поиска (унифицированного). Я бы сказал, что сегодня я не так много скучаю, и меня не беспокоит наличие нескольких окон VSCode сегодня, особенно после того, как была добавлена ​​команда Switch Window : +1:

Как _разработчик_расширений_ у меня есть некоторые расширения, основанные на _Project Context_, например context.workspaceState , activationEvents/workspaceContains . А также Project Manager , который, кстати, я уже начал рефакторинг внутреннего устройства для поддержки нескольких папок. Я хотел бы знать, как это повлияет на расширения

благодаря

Чтобы добавить к тому, что я сказал выше (https://github.com/Microsoft/vscode/issues/396#issuecomment-270326917), я действительно использую подмодули Git, поэтому, когда я работаю над своими собственными (частными) пакетами, это Имеет смысл объединить их в пакет, но поскольку Джулия все еще довольно молода (условно говоря), мне часто приходится работать над другими пакетами помимо моего собственного. Я не считаю веской причиной добавлять эти другие пакеты в качестве подмодулей (хотя я мог бы).

Как правило, при разработке пакетов Julia я постоянно переключаюсь между пакетами, поэтому было бы здорово иметь несколько папок проекта: +1:

PS: MS, пожалуйста, обратите внимание на Юлю;)

Самый простой вариант использования: микросервисы

Ха-ха. Да @saada 👍 На самом деле именно микросервисы привели нас к VS Code. Мы используем Azure Service Fabric, и мой партнер создал первые микросервисы на .NET и Rust. Я работаю над микросервисами Julia. Мой партнер - парень VS, и ему понравился VS Code for Rust. Он предложил мне попробовать VS Code для Джулии. Благодаря!

@saada определенно на радаре. Можете ли вы ответить на эти вопросы, чтобы помочь мне более четко сформулировать требования?

  1. У ваших микросервисов общая родительская папка? Почему или почему нет?
  2. Каждый микросервис разделен на отдельный репозиторий git? Почему или почему нет?
  1. Каждый микросервис разделен на отдельный репозиторий git? Почему или почему нет?

@waderyan одна из возможных причин заключается в том, что некоторые популярные платформы PaaS, такие как Heroku, требуют, чтобы каждое приложение (микросервис) находилось в отдельном репозитории Git. Развертывание через git-push стало популярной стратегией.

@waderyan Я подписался на слот завтра и с нетерпением жду его, но в том, что касается подобных вариантов использования, наш похож.

Мы крупная организация, у нас есть частный реестр npm и мы публикуем собственные модули, которые используются внутри организации. У нас есть приложение для реагирования с клиентской базой кода, которое представляет собой большое приложение, которое потребляет некоторые общие модули (например, служебные библиотеки, общие компоненты), и серверную кодовую базу, которая также состоит из нескольких модулей (экспресс-серверное приложение, компоненты службы данных серверной части, потребляемые уровень сервисов и фактические сервисы, предоставляемые клиенту). Активная разработка включает минимум два (уровень клиента и сервисов), но для устранения неполадок можно легко задействовать полдюжины модулей.

Даже при использовании общедоступных модулей npm иногда бывает полезно напрямую связать исходный код и открыть его в отдельном экземпляре VS Code для устранения сложной проблемы или даже ошибки в стороннем модуле, но в основном это наш собственный код.

Каждый из них представляет собой отдельный репозиторий git. Нет проблем с хранением их в моей файловой системе в одной корневой папке (я бы все равно). Но мне нужно, чтобы для каждого был открыт отдельный экземпляр VS Code, и переключаться туда и обратно болезненно, потому что вы можете видеть только имя файла, а не имя самого приложения. Невозможно легко определить, какое приложение / модуль / проект открыто в каком окне. Само имя файла предоставляет очень мало полезной информации для различения нескольких экземпляров VS Code.

Есть еще одна открытая проблема, связанная с возможностью настройки информации в строке заголовка, которую я также много комментировал - и она также остается нерешенной. Если бы можно было расположить имя корневой папки в строке заголовка заподлицо, проблема с открытием нескольких проектов была бы гораздо меньшей проблемой, потому что я мог бы по крайней мере видеть, какой открытый экземпляр находится в Windows при переключении задач. Кажется, что сделать настраиваемым должно быть действительно тривиально и, по крайней мере, облегчило бы боль от невозможности открыть несколько репозиториев git в одном экземпляре, пока это выясняется ...

@waderyan

  1. Мои веб-проекты управляются единственной родительской папкой. Он настроен таким образом для организации и быстрых ссылок для папок моего репозитория. Я также делаю это, так как мне легко переключиться на предыдущий / текущий проект, чтобы получить образцы кода, когда они будут использоваться повторно. В отличие от открытия другого окна, проще открыть другую вкладку, и в моем случае это более эффективно.

  2. Каждый веб-проект имеет собственную интеграцию с git, однако лично мне не требуется, чтобы .git был интегрирован в мой редактор кода. Для меня это хороший вариант, но не требование. У них есть собственная интеграция .git из-за желания хранить каждый веб-проект отдельно на моем хосте репо.

@nickmak @jamietre @pesho спасибо, что поделились своими мыслями. Это полезно, и я с нетерпением жду встречи со многими из вас завтра.

@alefragnani Я сосредоточен на сценарии конечного пользователя. Мы подошли к этой проблеме осторожно, поскольку она влияет на расширения. Мы будем действовать осторожно и сообщать обо всех изменениях API. Если хотите, напишите мне в Твиттер , и мы сразу же перезвоним, чтобы обсудить больше.

даже блокнот ++ поддерживает несколько папок. это причина не может покинуть блокнот ++.
в этот день для работы с javascript необходимо открывать несколько проектов.

Я занимаюсь встроенным программным обеспечением, и обычно я работаю с несколькими папками в системе. Например, код приложения, библиотека поставщика и код операционной системы.

Я хотел бы добавить сюда свой вариант использования для нескольких папок в одном окне.

Я разработчик игры, и для нашей текущей игры мы реализовали поддержку модов. В нашей игре есть клиентский, серверный и мастер-серверный проекты. При редактировании файлов мода обычно работают только на уровне мода игры (вместо того, что мы называем базовым или собственным уровнем фактического кода игры. Например, работа только в файлах Lua вместо файлов C ++ и C # для сервера и клиент соответственно). Папки часто могут находиться не в общей родительской папке.

В этом случае использования, когда мы работаем только с файлами мода, в прошлом мы использовали функцию мультифолдера Sublime для создания представления проекта только для папок мода верхнего уровня с Клиента и Сервера. Это позволяет нам избегать использования собственных файлов (C # и C ++) и быстро редактировать файлы Lua в этих двух проектах, которые очень сильно связаны друг с другом.

Наличие поддержки мультифолдеров в VSCode позволит нам сделать то же самое и значительно упростить принятие VSCode (который нам очень нравится).

Что произошло из звонка, состоявшегося на прошлой неделе? Я использую Mac и не могу открыть несколько экземпляров VSCode, что, как я думал, может быть обходным путем.

благодаря!

На прошлой неделе мне звонили Уэйд, очевидно и честно, что это не было
ранний приоритет, они создали действительно хороший редактор, и теперь, надеюсь,
они расширяют его для удовлетворения различных потребностей разработчиков. Команда разработчиков
слушаю, я с нетерпением жду, как они это сделают

Вск, 15 января 2017 г., 21:20 nowherenearithaca, [email protected]
написал:

Что произошло из звонка, состоявшегося на прошлой неделе? Я на Mac и не могу показаться
чтобы открыть несколько экземпляров VSCode, что, как я думал, будет обходным решением.

благодаря!

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-272724576 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AA16yEIdTFJAnqXHLs_WUvrGBIR9G7f-ks5rSo2DgaJpZM4Gm3nX
.

в большом запросе
отметка

@nowherenearithaca У меня были отличные звонки с несколькими пользователями, и я поделился тем, что узнал, с остальной командой. Мы все еще обдумываем следующие шаги, но я ожидаю, что очень скоро мы что-то сделаем в этой области.

@waderyan , извините за поздний ответ:

У ваших микросервисов общая родительская папка? Почему или почему нет?

Да, для удобства. Это упрощает поиск связанных служб, когда они находятся в одном каталоге.

Каждый микросервис разделен на отдельный репозиторий git? Почему или почему нет?

Да. У них не только разные репозитории, но и разные конфигурации линтинга и отладки. Кроме того, очень полезно использовать Cmd + P для переключения файлов между проектами. Глобальный поиск по связанным проектам, ...

С нетерпением жду возможности увидеть это в действии!

Одним из решений может быть создание ссылки на папку, в которой находятся файлы, к которым вы хотите получить доступ.
Это не идеально, но может помочь.

_Пример:_

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

У меня 3 монитора, и я хочу использовать VSCode на всех трех. Если я не могу открыть несколько экземпляров, поддержите хотя бы открепление вкладок и перетаскивание их в другие окна (аналогично Visual Studio 2015).

Согласен.

Все остальные текстовые редакторы делают это. Почему Microsoft не придумала что-то настолько простое и нужное?

@calloncampbell Эта функция находится в этом выпуске: https://github.com/Microsoft/vscode/issues/2686

@calloncampbell @rsyring Я не знаю, что делаю неправильно, но с помощью code -n я могу открыть столько экземпляров редактора, сколько захочу.

Если я правильно понимаю, это будет рассмотрено в рамках февральского плана итераций как «Первоначальное расследование внедрения« многопользовательских рабочих пространств »,« рабочих пространств с несколькими папками » :)

+1 ...
Разве это невозможно со старой версией VSCode, или я просто использовал Sublime? забыл...
но очень удобно.
Теперь мой Mac завален шестью окнами повсюду ...

И нет, я не буду открывать корневую папку всех тех 6 папок, которые я открыл, потому что проводник - это вертикальная прокрутка, и мне понадобится вечность, чтобы просматривать файлы ...

@edmundtfy это возможно в возвышенном. Visual Studio Code никогда не поддерживала эту функцию.

Решение @ min20 просто идеальное !!! проект с несколькими папками, вместо этого он будет управлять несколькими окнами с помощью кнопок

@DeeJaVu, учитывая, что ... VSCode имеет всплывающую подсказку и Ctrl + щелчок, чтобы перейти к определению. Я загрузил несколько расширений для Sublime, но наведение мыши и управление + щелчок тоже не работают ... какие-либо рекомендации?

Я очень скучаю по этому после многих лет использования Sublime. Прямо сейчас я работаю с Intershop (в качестве интерфейса) с сотнями тысяч файлов на каждый картридж. Если мне нужно загрузить полный интернет-магазин, это будет очень медленно, когда вы хотите открыть CTRL + P, чтобы быстро переключиться на файл, или когда вам нужно выполнить поиск.

Кроме того, мне просто не нужны все папки проекта в моем редакторе. Мне как фронтенд-разработчику все не нужно. Достаточно только нужных мне папок.

Другой пример: создание сайта на Wordpress и плагинов для него одновременно. Зачем мне включать полный сайт Wordpress? Это просто снижает вашу эффективность.

Еще одна проблема: наш интерфейсный фреймворк разделен на разные репозитории git. Открыть более 4 окон - настоящая боль. И SCSS intellisense тогда не работает (переменные IE. Из ядра> пакета)

TL; DR; VScode непригоден для больших / огромных проектов

+1, представьте, что вы разрабатываете wordpress или drupal с несколькими настраиваемыми модулями.

Корень вашего проекта является корнем вашего веб-сайта, но вы не хотите, чтобы весь веб-сайт был репо, вы просто хотите, чтобы ваши несколько модулей или тем были независимыми репозиториями.

Очень распространенный вариант использования в веб-разработке, который следует охватить даже самой маленькой / легкой IDE.

+1

+1, даст мне возможность редактировать проект и без проблем работать над его подмодулями

+1

Это единственная проблема, которая мешает нам перенести всю нашу команду разработчиков из 32 человек на VS.

Разработка микросервисов просто невыполнима, это болезненно.

+1

+1, определенно полезно, я решаю перейти на vscode из sublime, но из-за отсутствия этой функции я думаю, что все равно буду использовать Sublime до одного дня ..

Это очень необходимое и основное свойство. Я не могу поверить, почему разработчики этого замечательного редактора проигнорировали это. Без этой функции это бесполезно. Это мешает мне перейти на VSCode с Atom.

Пожалуйста, добавьте эту функцию. После использования Sublime, а затем Atom это для меня необходимая функция редактора. Конечно, это не так просто из-за интеграции с git, но мне это нужно в моем любимом редакторе.

+1

+1 срочная необходимость

+1 Как уже было сказано, для перехода с Atom на VSCode нам очень нужна эта функция.

ВНИМАНИЕ ДО КОММЕНТАРИИ
* ПОЖАЛУЙСТА !!!! Остановить комментарий с помощью «+1»

Каждый ваш бесполезный комментарий только этой веткой отвлекает более сотни человек !!!
Если хотите поддержать эту функцию - в первом сообщении есть эмоции!
Если вы хотите подписаться на обновления - для этого есть кнопка «Подписаться» справа от тем.
Уважайте других участников, которые вынуждены читать ваши «+1», «действительно нужны» и т. Д.

Для справки, способ, которым Sublime Text (в качестве примера) упорядочивает свои проекты, заключается в «включении» деревьев папок с уникальными параметрами для каждой «папки», включенной в ваш проект.

Чтобы визуализировать это, JSON файла проекта Sublime Text выглядит так:

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

Как видите, каждая включенная папка указана относительно пути к проекту (в случае возвышенного текста это путь к файлу *.sublime-project ). Кроме того, в каждой папке есть раздел для исключения шаблонов файлов и папок с подстановочными знаками. Отлично подходит для игнорирования (как видно выше) результатов тестов, библиотек, которые вы не должны редактировать, иллюстраций и множества других вещей.

Это последняя причина, по которой я не переключился.

Очень полезно!

+1
Пример: необходимо проверить, не реализованы ли некоторые функции в других модулях, на которые ссылается приложение, чтобы я не дублировал функциональность.

Очевидно, что модули хранятся в другом месте пути к файлу, а не в самом приложении, и использование нескольких окон затруднительно с одним экраном, когда вы просто хотите быстро получить доступ к файлу и прочитать код.
Я говорю о приложениях AngularJS, которые не требуют развертывания или чего-то еще, просто работающего сервера.
Зачем мне заниматься разработкой в ​​другой файловой структуре, если я могу просто открыть папку приложения прямо из Tomcat, и мои изменения вступят в силу в реальном времени.

И нет, родительской папки нет, если только вы не предложите открыть папку сервера Tomcat как проект (это все равно что предложить открыть весь жесткий диск как проект, потому что тогда я смогу открыть все файлы).

Ух ты, я удалил атом, чтобы попробовать VS, и эта функция не добавлялась с 2015 года.

stoffeastrom открыл этот выпуск 21 ноября 2015 г.

Это удручает. :расстроен:

PS: Открытие основной папки - не совсем решение, так как оно также открывает все нежелательные файлы, превосходя всю цель этого билета.

Это действительно удручает. Но опять же, не так удручающе, как люди, которые все еще жалуются на потрясающий бесплатный редактор с открытым исходным кодом (который постоянно добавляет несколько новых функций _ каждый месяц_). Это не так печально, как спамить всех, кто смотрит эту ветку, комментариями о своей депрессии.

(Теперь я, наверное, один из спамеров: grin :)

Обновление: текущий план состоит в том, чтобы изучить это в итерациях марта / апреля.

См. Https://github.com/Microsoft/vscode/issues/21923 план итераций марта:

Изучите многокорневые рабочие пространства с несколькими папками # 396 @bpasero @Tyriar

+1

Чтобы поделиться реальным примером, который уточняет описание функции: Пример, WordPress Theme / Plugin dev.

В других редакторах я настраивал несколько папок как «закладки», чтобы получить доступ к довольно большому и сложному дереву файлов, которым немного легче управлять. Один из них относится к корневому каталогу, который является корневым, я бы предпочел, чтобы любая функция отладки и завершения кода начинала поиск в (среде). Во-вторых, это актуальный проект, папка темы или папка плагина, которая в моем рабочем процессе является корнем системы управления версиями. Иногда я настраиваю дополнительные папки в качестве справочных, например родительскую тему, или тему шаблона, или плагин, с которым я интегрируюсь, и мне нужно часто ссылаться / читать.

Итак, набор функций здесь: 1. возможность установить корень git и корень поиска в разные места. 2. Система закладок папок, которая является чисто визуальной, чтобы упорядочить панель дерева файлов.

Для некоторых в потоке, где корень git и корень проекта совпадают, кажется, что изучения и использования подмодулей будет достаточно, и тогда это примерно 2., чтобы получить приятный, менее загроможденный вид вложенной папки.

Я уверен, что некоторые в потоке действительно просят буквальную поддержку нескольких проектов, но я предполагаю, что большинство просто просят в основном более простую идею создания закладок для папок.

Я также прошу способ определить один как корень проекта (поиск / отладка), а другой как корень git. (Не стесняйтесь игнорировать мое плохое наименование вещей.)

Мой обходной путь - просто создать родительскую папку и создать в ней символические ссылки со всеми проектами, которые мне нужны.
_например._

У меня есть эти проекты

1. my-app-api
2. мой-приложение-клиент

Я создаю папку с именем _my-app-all_ (имя здесь не имеет значения) и внутри я создаю две символьные ссылки, указывающие на my-app-api и my-app-client, тогда в VSCode мне просто нужно открыть my-app- все

Шаги

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

Ноты:
Интеграция с git не работает

@DannyFeliz, это должно быть помечено как ответ на эту проблему и размещено наверху для всеобщего
Пример использования:

  1. Откройте командную строку с правами администратора
  2. Перейдите в папку вашего проекта
    3. [необязательно] создайте папку ссылок
  3. используйте MKLINK / D "имя_ссылки" "путь к папке, на которую вы хотите сослаться"

Когда вы откроете проект в VS-коде, вы увидите указанную папку и все файлы / папки в ней.

Удачного кодирования, ребята!

Это не позволяет интеграции Git работать.

В пн, 20 марта 2017 г., в 14:42, poparazvandragos [email protected]
написал:

@DannyFeliz https://github.com/DannyFeliz это должно быть отмечено как
ответ на этот вопрос и опубликованный наверху для всеобщего обозрения ... Я тестировал
это также и в Windows с помощью команды MKLINK.
Пример использования:

  1. Откройте командную строку с правами администратора
  2. Перейдите в папку вашего проекта
    3. [необязательно] создайте папку ссылок
  3. используйте MKLINK / D "имя_ссылки" "путь к папке, на которую вы хотите сослаться"

Когда вы откроете проект в VS-коде, вы увидите указанную папку
и все файлы / папки в нем.

Удачного кодирования, ребята!

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-287907310 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ABEOBVKz2bqFsRdfvyOpcFW2e_26HV5bks5rnvLWgaJpZM4Gm3nX
.

@ehartford Я сказал ответ, а не ответ, поскольку большинство из нас искали именно эту вещь, отображая несколько каталогов в одном окне VSCode, которые находятся в разных местах.
Символические ссылки делают именно это, но при работе в Windows это не то решение, которое приходит на ум.
Прошло 2 года, и разработчик Linux / OSX пришел и показал нам простейший обходной путь.
Я рад, что наконец-то решил оставить свой комментарий по этой проблеме, так как у меня есть обходной путь для того, что я хотел
всего через 12 дней, когда мне это было нужно больше всего.

Эту проблему не следует отбрасывать, поскольку можно сделать гораздо больше, если разработчики решат вмешаться в этот вопрос.
Но для большинства из нас это удовлетворяет. Я просто предлагал как-то переместить это в начало, чтобы люди не тратили время на чтение всех других комментариев, пока не дойдут до этого комментария. Некоторые могут просто не заметить это из-за размера нити.

Я просто отредактирую это, поскольку вижу, как люди уже прыгают мне на спину, потому что я узнал, как достичь того, чего хотел, и попытался облегчить другим возможность увидеть альтернативу, даже если она не идеальна. Кстати: вы всегда можете использовать командную строку, интегрированную в VSCode, для извлечения / фиксации / отправки файлов в отдельные связанные папки, но зачем соглашаться на обходные пути.

Без интеграции с Git это вообще не запускается. Я ни в коем случае не считаю это приемлемым решением. Жду актуального решения. С уважением.

Если это поможет - клиент google appengine nodejs имеет такую ​​структуру:

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

Я бы хотел иметь возможность открывать / отлаживать / работать с таким решением (даже если это один пакет за раз). Я хотел бы иметь возможность писать проекты / библиотеки на основе Typescript в этом стиле.

Спасибо за отличную работу!

Мне нравится VSCode, но он плохо справляется с несколькими проектами. Но я могу понять, почему эта функция была отложена, поскольку она усложняет несколько вещей, таких как управление версиями, из-за вложенности и т. Д.

Я был бы рад за функцию «быстрого переключения проекта» ИЛИ возможность «вкладывать» несколько экземпляров vscode в одном окне.

Полностью согласен, пожалуйста, поддержите открытие нескольких папок проекта в одном окне. Эта функция очень важна.

@replete Это не идеальное решение вашей проблемы. Но попробуйте Project Manager , это частично помогает мне прямо сейчас.

@dariusrosendahl Ага, как ни

На боковой панели всего 5 значков. Чтобы добавить боковую панель «Проект», не потребуется много времени. Но кажется, что владельцы продуктов vscode очень привередливы в том, насколько он минимален. Слишком минимальный IMO, поскольку теперь он становится IDE.

@replete рад узнать, что это полезно 😄

Фактически, есть _experimental API_ для создания так называемого _Tree Explorer Contribution_ (как и панель Symbols - https://github.com/Microsoft/vscode/issues/15485). При этом расширение может добавить значок на панель активности.

Я добавлю проблему в свое расширение с вашим предложением, спасибо 👍

+1

@dmccaffery

Меня лично не волнует, попадет ли эта функция в продукт или нет - я понимаю, почему некоторые люди этого хотят, но я хотел бы отметить, что это делает все немного более запутанным.

Тогда, может быть, не стоит доминировать в разговоре с негативными комментариями против этой функции и о том, что VSC не является IDE? Думаю, достаточно одного ответа / отрицательного голосования, а в худшем случае - двух, если нужно уточнить позицию.

Кроме того, аргумент «не IDE» спорный. Другие не-IDE также допускают это.

Например: при поиске с использованием выражения регулярного выражения - в каком рабочем пространстве я ищу? один? все?

Не такая уж большая проблема. Либо искать все, либо иметь селектор, чтобы охватить поиск одной из открытых рабочих областей. Опять же, другие «не IDE» (а также IDE) уже обрабатывают этот (и другие) случаи.

Я исправил эту проблему в своей собственной настройке, создав каталог для каждой «рабочей области» и установив символические ссылки на проекты, которые я хочу видеть в этой рабочей области.

я видел это

Первоначальное исследование многокорневых рабочих пространств с несколькими папками # 396 @bpasero @Tyriar

выполняется в соответствии с https://github.com/Microsoft/vscode/issues/21923 какие-либо обновления по этому поводу? :)

Мы (часть команды) провели первоначальное исследование объема проделанной работы и проблем, которые мы видим, и следующие шаги - обсудить результат этого с командой и спланировать его. Мы планируем апрельский выпуск в течение этой недели, поэтому я ожидаю, что вскоре появятся более подробные элементы плана в результате этой работы.

screen shot 2017-04-06 at 12 09 26

Если я не опоздаю на вечеринку, вот хороший способ реализовать это.
Когда вы заходите в «Проводник», у нас уже есть два раздела. Один для открытых файлов и один для дерева проводника текущей открытой папки.

В идеале мы могли бы просто открывать больше папок в одном окне, и они добавлялись бы сюда, в отдельный раздел, который можно развернуть, чтобы увидеть дерево проводника.

То же самое можно сделать и для раздела «Контроль версий». Один подраздел для каждой папки, открытой в «проводнике». Итак, отношение 1 к 1.

Так, может быть, мы сможем сделать всех счастливыми. У нас есть поддержка открытия нескольких папок в одном окне, если мы хотим, а также интеграция с GIT по-прежнему работает и может обрабатывать каждый «корень проекта» отдельно.

Открывать более одного проекта в одном окне, это тоже важная функция для меня. Обычно я открываю слишком много проектов, чтобы скопировать некоторые базовые приложения. Я просто устанавливаю Visual Studio Code и по этой причине вернусь к Atom.

+1 Я хочу показать другим разработчикам значение VSCode, но невозможность открывать две папки в одном окне является нарушением правил. Надеюсь, это получит более высокий приоритет.

Всего два цента:

Пока слово "монорепо" не отображается в этой ветке.

Мой monorepo централизует проблемы конфигурации между несколькими корнями, каждый из которых отмечен файлом «.root» в папке, содержащей их.

Не каждый корень является внешним репозиторием git, но они позволяют частичное переопределение глобальной конфигурации.

Моя основная проблема заключается в том, что поиск файлов и / или символов не определяет приоритет содержимого моих корней.

Я думаю, что требование можно разделить на ~ 4 отдельных, которые могут или не могут быть напрямую связаны друг с другом (и, вероятно, реализованы независимо):

  • поддержка нескольких папок в проводнике
  • поддержка нескольких папок в поиске
  • поддержка нескольких папок в системе управления версиями
  • поддержка нескольких папок при отладке

Из того, что я видел в этом потоке, их разделение может поддерживать более широкий спектр сценариев. Конечно, должна быть какая-то «основная» папка, влияющая на то, как сохраняются настроенные / выбранные папки.

Я не понимаю, почему в большинстве комментариев говорится о решениях для работы с несколькими корнями или несколькими папками. На самом деле я думаю, что пытаться реализовать это способом IDE - это действительно плохо. Это добавляет сложности и, безусловно, влияет на производительность (время загрузки, обновление git ....).

Я думаю, что эта функция очень важна, в основном нужно иметь визуальное представление обо всех связанных проектах и ​​быстро переключаться между окнами проектов!

У нас есть два варианта:

  • Реализация в одном окне : в моем понимании это вызывает множество других проблем, несколько корней проектов для git, поиск ... ЭТО ОЧЕНЬ ПЛОХО для UX и потенциально внесет ошибки и усложнит редактор.
  • Реализуйте механизм переключения, который является визуальным, и оставляйте одно окно для каждого проекта : это самый безопасный и удобный вариант с очень меньшими затратами! @ min20 разместил наглядное Slack между группами, которые я считаю идеально подходящими для использования!

spack

Я надеюсь, что эта функция появится, но не как многокорневые решения! одно из ключевых преимуществ небольшого редактора - это простота и скорость, muti-root != simplicity & speed

Я должен полностью с вами не согласиться @ g13013 , вы видели реализацию Sublime? Это очень просто и при этом намного быстрее, чем Visual Studio Code. Даже со всеми включенными плагинами GIT.

Мы не говорим об использовании нескольких проектов в одном редакторе. Мы говорим об использовании только папок нужного вам проекта.

Я, например, работаю над магазинами Intershop. Мне многое не нужно, мне нужно отредактировать только картриджи. 80% папок и файлов для меня бесполезны и только сильно утяжеляют редактор (поверьте, он сильно тормозит).

Использование «быстрого открытия» в Visual Studio также невозможно, если имеется много повторяющихся файлов. Вы часто не уверены, откроете ли вы правильный, и снова он замедляется с МНОГО файлов.

Я понимаю, но, используя в прошлом sublime и atom, я, наконец, пришел к выводу, что ни один из них с функцией "muti-root" не решил ничего, кроме исследования файлов проекта, говоря о возвышенном, возвышенном дереве папок, очень медленно большие проекты и даже зависает при обнаружении, в Sublime нет интеграции функций "git" и "debug" из коробки .... введение muti-root приведет к появлению множества проблем, связанных с интеграцией git, поиск без влияния на производительность ... даже UX влияет, например, изучение проблем srcoll в больших проектах.

Странно, для меня все наоборот.

Может быть, потому, что в 99% случаев я включаю в Sublime или Atom только то, что мне нужно :), и это именно то, что мы хотим.

Может быть, дело в том, как вы используете редактор. Я привык использовать CMD / CTR + P и набирать именно тот файл, который мне нужен. Это невозможно, если вам нужно включить корень проекта с большим количеством повторяющихся файлов. (картриджи / файлы остались там, чтобы сравнить, что было в оригинале :)) или что-то вроде wordpress, где много файлов с одинаковыми именами.

Здравствуйте,
Да, идея с несколькими папками прекрасна, но при этом не ломает многих вещей. Каждая дополнительная папка может быть новым вложенным разделом с префиксом, указывающим, что она является чужой для основной папки. Первичный используется для отладки и Git. Пользователь может щелкнуть правой кнопкой мыши любую чужую папку и сделать ее основной . Что вы получаете:
1) возможность видеть все ваши папки и файлы и открывать их по мере необходимости.
2) переназначение того, над чем нужно работать.

Теперь, если кто-то хочет открыть сразу несколько проектов, он должен открыть новый запрос на выпуск. Это добавляет значительную сложность, описанную многими людьми. Плагины не приравниваются к встроенным. Если есть редактор, у которого есть соответствующая встроенная функция, на него следует указать, чтобы другие разработчики могли проверить, как их рабочий процесс сочетается с такой функцией. Спасибо. Добрый день.

Добавьте меня в список пользователей, которые считают это единственным нарушителем сделки, который не позволяет мне перейти на VSC. Я считаю, что реализация проектов Sublime является правильной. Если мне нужно поработать, например, с приложением «Часы волонтеров», я открываю проект, заполненный разными папками (основная папка проекта, а также другая папка, содержащая изображения). Это мой рабочий набор для этого проекта. Если мне нужно перейти к приложению «Калькулятор обмена», я могу поменять весь рабочий набор на этот проект или открыть новое окно с этим проектом в нем.
Другой вариант использования - использование CMS. Если я работаю над плагином для CMS, у меня может быть один проект для плагина, который является репозиторием Git, а другой - для всей CMS, который не Gitified. Я могу переключаться между ними по мере необходимости и разделять свои проблемы с Git.
Для меня VSC выглядит как будущее, но не без возможности хранить отдельные рабочие наборы папок.

Здравствуйте,
Я только видел, что Sublime Text поддерживает проекты с файлом проекта . Как это соотносится с тем, о чем здесь просят? Это похоже на запрос vscode для поддержки файлов проекта в рабочей области. Ранее был комментарий о расширении, которое могло бы справиться с этим для менеджера проекта .

Честно говоря, я также использую Atom, и я использую функцию нескольких папок (встроенную), которая позволяет мне одновременно открывать папки с документацией и папку моего текущего проекта. Это действительно похоже на то, чтобы просто включить первичный и кучу дополнительных. Наверное, простая стрелка или начало указывать на первичный. Спасибо. Добрый день.

image

Вот мой вариант использования. Я работаю над игрой, которая разделена на три репозитория; один репозиторий Git для движка, один репозиторий hg для кода игры + контент и один репозиторий hg для кода игры, который является общим для многих проектов. Также есть одно репозиторий hg для плагинов Sublime Text компании. Общее репо - это вспомогательное репо для игрового репо.

На моем следующем рабочем месте я планирую снова поработать со многими репозиториями.

Очень удобно иметь все это в одном экземпляре редактора, и я думаю, что для всего этого имеет смысл получить правильный SCM в VS Code.

Я ожидаю, что поиск по умолчанию будет искать во всех сопоставленных папках. Приятным бонусом будет возможность временно включать / отключать папки для поиска. (Например, когда меня интересует только поиск вещей в игровом движке)

Многие люди говорят, что VS Code не должен поддерживать это, потому что A) им это не нужно и B) VS Code - простой текстовый редактор. Первая причина никуда не годится - есть несколько функций, которыми пользуются все. Вторая причина ... VS Code - это не просто текстовый редактор, в нем есть отладка, SCM, плагины. Другие «простые текстовые редакторы», такие как Sublime, поддерживают несколько папок. И как человек, непреклонно относящийся к производительности, я не вижу, как добавление этой функции повлияет на производительность каким-либо значимым образом, особенно для людей, которые в любом случае используют только одну папку. Не могли бы мы сфокусировать обсуждение на том, как мы хотим, чтобы эта функция работала, а не на том, почему она нам не нужна.

@Srekel, можете ли вы включить снимок экрана, показывающий, как вы так работаете в ваших текущих редакторах? Это похоже на смесь папок и проектов, использующих встроенные модули и плагины. Будем надеяться, что люди из этого лагеря A вряд ли заметят изменения для включения такого рода функций. Для ребят из лагеря

Вот некоторые вещи о том, как этого добиться:

  • понимание взаимосвязи объема, контекста, сеанса, представлений и актуальности .
  • верхние пределы (больше 256 папок?)
  • ключевые затронутые области (вкладки редактора, настройки, scm, git, расширения).
  • переопределение настройки рабочей области или конфликты.

Было бы неплохо рассказать о некоторых вещах, которые VSCode считает само собой разумеющимся в этих областях, которые требуют компенсации. Спасибо. Добрый день.

+1

+1. У меня более 30 модулей, каждый из которых имеет собственный репозиторий git, к которому я хотел бы иметь доступ и работать с ним в единой среде. Я думал, что это то, что делают большинство разработчиков js / node. С VSCode это невозможно, к сожалению, нарушение сделки.

+1

Он открыт с 2015 года и до сих пор не исправлен. Это просто самая востребованная функция в любом редакторе, но, к сожалению, у vscode ее нет.

+1

Я постоянно путаю одно окно VS Code с другим при переключении команд.

Это есть в каждом другом известном мне редакторе (Atom, Sublime, Brackets ...)

Добавление символической ссылки в мой проект - это хитрость, и мне потребуется обновить мой .gitignore. Открытие родительского каталога раздражает, потому что тогда моя панель файлов заполняется другими проектами, которые меня не волнуют.

План апрельской итерации, показывающий, что задача «Исследование многокорневых рабочих пространств с несколькими папками» выполнена. Каковы результаты расследования?
@bpasero @tyriar

+1

Извини, если я слишком нетерпелив. Вы, ребята, сейчас заняты выпуском кода.

Здравствуйте,
Диалоговое окно «Открыть папку» следует рассматривать как «Открытые папки». Поэтому, если я нахожусь в определенной родительской папке, я могу в диалоговом окне выделить две или более ее подпапок для одновременного открытия. Это было бы долгожданным дополнением с включением этой функции. Спасибо. Добрый день.

+ еще один

Никогда раньше не встречал столько простых комментариев в ветке GitHub, особенно пост-смайликов. Боже мой.

Мне очень понравится эта функция. Как кто-то уже сказал, многие современные проекты являются модульными, например, интерфейс в одном репо / проекте и бэкэнд / API в другом. Вам часто захочется работать над ними вместе как одно целое.

Это единственная причина, по которой я не отказался от Atom.

Микросервисы и бессерверные платформы в сочетании с давнишней мантрой «репозиторий - дешево» - вот почему это необходимо. Нет ничего необычного в том, что ~ 30 [небольших] репозиториев открыты и работают с файлами из нескольких проектов одновременно; ожидать, что люди будут переключаться между таким количеством окон, или передать файловую структуру диспетчеру окон среды рабочего стола не сработает.

Здравствуйте,
Как вы сейчас управляете своими 30 репозиториями @martellaj ? Звучит ужасно - работать вживую с таким количеством открытых файлов. У меня, как правило, много библиотек, над которыми я работаю, но если у меня возникнет значительная потребность поработать над резервным копированием полезной функции для совместного использования, я намеренно закрываю все остальные окна редактирования. Я создаю файлы конфигурации обновлений тестов и параметры проекта, чтобы заставить меня работать, а затем возвращаюсь к своему предыдущему представлению. Это все еще может быть 3 или 4 других окна.
Вы делаете это из-за других ограничений в вашей среде? может в языке программирования нет intellisense? Может быть, поможет расширение, которое может читать API и выдавать функциональные подписи?
Такой язык, как F #, имеет функцию, называемую поставщиками типов, один из которых может делать именно это и упростить программирование в Интернете. Это не для того, чтобы уменьшить вашу потребность в нескольких папках, просто у вас, вероятно, все еще будет по крайней мере несколько других проблем с таким большим активным рабочим пространством. Спасибо. Добрый день.

@ pr-yemibedu, я думаю, что @martinjco говорит, что у него нет открытых файлов, но у него был бы быстрый доступ к репо, если бы у нас была многокорневая структура. Представьте, просто CMD + P в любой нужный вам файл;)

Проблема с текущей ситуацией заключается в том, что мы ДОЛЖНЫ открывать файлы или, по крайней мере, переключаться между 30 различными окнами, потому что VScode не поддерживает это.

Недавно я снова переключился на Atom из-за отсутствия функции. Сейчас работаю над проектом с 9 репо. Я не хочу, чтобы одновременно открывались 9 окон VScode, но я просто хочу использовать ярлык для перехода к нужному файлу.

Согласитесь с комментарием @dariusrosendahl. Я новичок в программировании, и мне нужно ссылаться на старый проект, чтобы писать новые. Надеюсь, это скоро изменится, но в возвышенном я могу легко иметь от трех до четырех папок проекта и сравнивать их, открытые в одном сеансе.
screen shot 2017-05-11 at 12 48 57 pm

Если бы мы могли получить это в визуальной студии, было бы здорово

Здравствуйте,
Я согласен с высказанными замечаниями, поскольку, как вы видите, мои предыдущие сообщения поддерживают эту функцию. Было точное заявление, которое я комментировал от martinjco:

Нет ничего необычного в том, что ~ 30 [небольших] репозиториев открыты и работают с файлами из нескольких проектов одновременно;

Nuno1895 показывает, как я использую Atom сегодня, когда мне нужно работать с несколькими папками, но с простым основным проектом. На самом деле я использую как VS2015, gedit, vim, notepad, так и notepad ++ для активной разработки. В каждом из них есть сильные стороны, которым пока нет эквивалента в аналогах.

Я просто пытался понять, есть ли ключевой момент, который можно прояснить. Мы все хотим, чтобы над этим поработали и чтобы разработчики потратили на это время. Вот почему я спрашивал, как с этим справляются сегодня. 9 против 30, вероятно, не вызвал бы у меня такого интереса, чтобы ответить, но мне нравится знать, что люди сравнивают с vscode, и стоит ли мне даже смотреть на другой инструмент.

Я видел только Atom и SublimeText в качестве основы для сравнения и с полезными скриншотами. Приветствуются дополнительные обсуждения, одобрения и отзывы, чтобы это было принято и реализовано. Спасибо. Добрый день.

Один момент, который, возможно, был недостаточно подчеркнут, - это возможность быстрого «переключения» между наборами папок (проектами). В Sublime это называется «Проект быстрого переключения». Когда вы щелкаете этот пункт меню, вы получаете всплывающее окно со списком всех ваших проектов, когда вы выбираете один из проектов, редактор отображает папки и все ваши открытые файлы в том виде, в котором вы их оставили в последний раз.
Например, если бы я работал в проекте A и открыл файлы app.js и index.html, а затем переключился на проект B, он закроет проект A и отобразит проект B. Если я затем вернусь к проекту A, он будет покажите мне папку (и), а также app.js и index.html в том виде, в каком я их оставил (есть даже несохраненные правки).
Если мне нужно, чтобы оба проекта были открыты одновременно, я могу просто открыть два экземпляра редактора.
Ключ в том, что я могу хранить все свои вещи в отдельных ведрах и могу быстро переключаться между ними.

+1

Здравствуйте,
Я читал об этой функции. Переключение проектов без просмотра в Sublime Text указывает на некоторые из хороших и плохих. Было бы неплохо, возможно, закодировать несколько папок, открытых в файле настроек рабочего пространства. Если этот файл кажется неправильным местом, то можно создать что-то вроде folder.json, чтобы сохранить текущее состояние того, какие папки и файлы доступны и открыты для текущего рабочего набора. Спасибо. Добрый день.

Я начал использовать VSCode несколько месяцев назад и в целом очень доволен. Я добавлю свой голос к хору и скажу, что эта отсутствующая функция - большая головная боль для меня. Есть ли _ какие_ другие достойные редакторы, у которых есть это ограничение? В любом случае это надо исправить. :)

Вот как устроена моя новая работа:
Одно репо для основной технологии. Скажем, путь - C: / mygamengine /
Одно репо для кода игры. Он синхронизируется с C: / mygamengine / mygame
Один репозиторий для игрового контента (текстуры и т. Д.): C: / mygamengine / mygame_data

Все три мерзавцы. Они не настроены как вспомогательные репозитории, они просто синхронизируются с этими папками.

Предпочтительно, чтобы я просто открыл корневую папку в VS Code и автоматически определил, что это, по сути, три разных проекта, и что файлы в mygame принадлежат этому репозиторию git, а не mygameengine.

Я хотел бы иметь возможность устанавливать настройки для этого рабочего пространства, которые различны для каждого репозитория (например, я могу запустить линтер для проекта движка, но не для кода игры). Также было бы неплохо, если бы настройки рабочего пространства по умолчанию были установлены для всех трех проектов.

Вау, это все еще не решено? Я надеялся заменить Atom на VS Code, поскольку, по отзывам, он намного быстрее и не отстает, как Atom.
Мой основной проект - это два репозитория Git, один серверный, а другой интерфейсный. Локально оба находятся в одной папке, но если код Atom или VS открывает эту родительскую папку, статус Git не распознается.
В Atom я просто добавляю обе папки в свою рабочую область и просто работаю.

: sparkles: Обновление: sparkles:

Прошло много времени с момента нашего последнего обновления, поэтому я подумал, что приведу всех в порядок. Я, @bpasero и остальная часть команды определили большинство проблем с внедрением multi-root и в настоящее время работают над некоторыми макетами и выясняют более специфические особенности UX.

Почему это длится так долго?

Это занимает так много времени, потому что эта функция - не единственная наша ответственность, и работа, связанная с созданием мульти-корневого доступа, довольно огромна. Во-первых, все компоненты в VS Code были разработаны с учетом того, что в любой момент времени может быть открыта только одна папка или ни одна папка не открывается. Когда у вас есть такая большая кодовая база, как наша, с таким предположением, требуется много работы, чтобы сделать ее более гибкой.

Чтобы привести несколько примеров, вот некоторые из наиболее серьезных проблем, которые мы определили до сих пор:

  • API расширения предоставляет один workspace.rootPath , этого недостаточно, когда мы добавляем поддержку многорневых папок. Мы хотим избежать поломки этих расширений и при необходимости предоставить путь миграции.
  • Взаимодействие настроек рабочего пространства в многокорневом мире немного отличается. Возьмем, к примеру, workbench.statusBar.visible которое в настоящее время разрешено в настройках рабочего пространства. Мы больше не сможем поддерживать это, так как это приведет к странному / ошибочному поведению, если будет определено в 2 папках. Мы находимся в процессе выяснения того, как поступать в подобных случаях.
  • Провайдеру SCM (git), вероятно, требуется наибольший объем работы по UX для поддержки нескольких папок: нужно ли нам вводить понятие «активный проект»? Должен быть установлен явно (щелкните папку правой кнопкой мыши и задайте его) или должен быть неявным (глядя на папку активного файла)? Должна ли это быть глобальная концепция или ограничиваться этой конкретной функцией? и т.п.

Мы не хотим торопиться с плохо продуманным решением, поэтому мы

Сводка комментариев на сегодняшний день

Я просто потратил несколько часов, просматривая огромную ветку, чтобы сопоставить полученные отзывы. Было немного сложно классифицировать некоторые из этих вещей, но вот что люди в целом искали (я перефразирую).

  • Мне нужна интеграция с git в нескольких папках
  • Текущий интерфейс переключения папок и / или управления окнами ОС громоздок
  • Я хочу искать в нескольких папках
  • Я хочу отлаживать несколько папок

Проблемы

  • Работает ли рефакторинг в разных проектах или в одном проекте?
  • В каком проекте я участвую в Git?
  • В каких папках будет выполняться мой поиск?
  • Не нарушайте настройки рабочего пространства
  • Не ломайте расширения - предупреждайте разработчиков расширений о новом API
  • UX с вкладками в стиле Slack мне недостаточно, это просто перенос управления окнами из ОС в VS Code - я хочу иметь доступ ко всем файлам из проектов в одном окне (т.е. наборе групп редакторов)
  • «В моем понимании это вызывает множество других проблем, несколько корней проектов для git, поиск ... ЭТО ОЧЕНЬ ПЛОХО для UX и потенциально может внести ошибки и усложнить редактор».

Другие комментарии

  • Я хочу открыть только часть репозиториев в моей "папке git"
  • Мне нужен удобный способ поиска в одной папке или организации результатов поиска по проектам
  • Я хочу иметь возможность переходить к коду зависимости, чтобы быстро читать
  • Я хочу запускать разные версии TypeScript для разных папок
  • VS Code работает слишком медленно с гигантскими репозиториями
  • Я хочу, чтобы некоторые проекты всегда были открыты для использования в качестве справки (например, тема / шаблон)
  • Я хочу, чтобы VS Code распознавал файлы .vscode / settings.json в любом каталоге (это помогло бы обойти)
  • Позвольте мне определить корень проекта (поиск / отладка) и корень git
  • Sublime элегантно обрабатывает интеграцию с несколькими папками git
  • Папки с вкладками, похожие на пользовательский интерфейс Slack (т.е. некоторая активная парадигма проекта)
  • Отдельный раздел в проводнике для каждой папки
  • Используйте папку как основную, а остальные как связанные / подпапки
  • Мне нужен проект быстрого переключения, как в Sublime (быстрое переключение + сохранение макета рабочего пространства)
  • Этот стиль управления рабочим пространством особенно полезен для следующего: модуль npm, julia, heroku PaaS, wordpress, drupal

Текущие обходные пути

Вот основные обходные пути в настоящее время:

Когда комментировать?

Пожалуйста, избегайте комментариев: +1: или «Я хочу это». Когда комментируется эта проблема, 153 человека, которые прокомментировали его, получают уведомление в дополнение ко многим другим, которые нажимают кнопку подписки. Комментирование также скроет обновления команды, так что помните об этом. Обязательно прокомментируйте, если это добавит к разговору.

Функция, которая, возможно, будет более полезна, чем наличие нескольких корней, - это добавить возможность иметь настраиваемые рабочие наборы. Это позволит вам открыть общий родительский объект, но в этом проекте будет много комбинаций папок.

Как правило, это было бы полезно для любого проекта, чтобы иметь возможность «сосредоточиться» на определенных файлах / папках одновременно в более крупных кодовых базах без необходимости каждый раз изменять конфигурацию для всего корня.

НЕТ планов по поводу этой функции?

Вы можете увидеть план этой функции в комментарии @Tyriar и в следующих связанных ссылках:
https://github.com/alefragnani/vscode-project-manager/issues/46
https://github.com/Microsoft/vscode/issues/26068

Мы хотели бы поделиться своими разработками и получить ваши отзывы. Для этого мы собираемся организовать несколько конференц-звонков, на которых мы рассмотрим наши проекты и обсудим вашу реакцию на проекты.

Если вы хотите принять участие в этих обсуждениях и помочь нам разработать правильный дизайн, свяжитесь со мной (отправьте мне электронное письмо - stevencl на microsoft dot com), и я настрою их.

Мы надеемся назначить эти обсуждения на четверг 1 июня и пятницу 2 июня.

@Tyriar @stevencl Спасибо, ребята! :хлопок:

Спасибо всем за то, что присоединились к сегодняшним сессиям. Записи сессий размещены здесь

Пожалуйста, посмотрите видео и поделитесь любыми дополнительными комментариями к дизайну.

@stevencl благодарит за проведение исследований и их доступность!

Отличные видео, спасибо! Некоторые отзывы:

  • 👍👍👍 за общий простой дизайн и естественное расширение того, как VSCode работает сегодня. Вы, ребята, справлялись со многими сложными ситуациями просто и элегантно. Престижность за это!
  • Мне нравится агрегированное уведомление SCM в нижнем левом углу, с моей точки зрения никаких изменений не требуется, за одним исключением: я бы пропустил всплывающее окно после нажатия на уведомление SCM и сразу перешел на панель SCM. Меньше кликов = всегда лучше для меня.
  • Цветовое кодирование корней, как предложил Алексей, - интересная идея, может помочь.
  • Поиск: для меня будет важна привязка к папке, я думаю, для этого можно использовать текущее поле «файлы для включения», просто хотел убедиться.
  • Единственное, в чем я не уверен, - это настойчивость и открытие всех additionalFolders когда я открываю path . Это имеет смысл в последнем примере, где express-project явно является «главным проектом», но я не уверен насчет предыдущего примера: express и express-plugin кажутся равными, как настоящие братья и сестры, и я не уверен, что ожидал бы открытия express также открыл бы express-plugin .

    • В некотором смысле, структура данных, стоящая за этим, кажется, что это должен быть просто плоский список путей, а не один «путь», а затем «дополнительные папки».

    • Я не уверен, насколько полезна концепция одного основного пути. В моих проектах, наверное, нет.

    • Чтобы открыть многокорневую рабочую область, я ожидал бы команды верхнего уровня, такой как _File> Open workspace_, помимо текущего _File> Open folder_.

    • В целом, я не уверен в этом. Извините, у меня нет более конкретных предложений.

Еще раз спасибо, с этим VSCode получит новые суперсилы 😄.

Спасибо, что поделились видео. Я хотел бы поддержать дизайн «один раздел на корневую папку»:

one-section-per-root-folder

Сначала я ожидал другого дизайна (наподобие возвышенного текста), но после просмотра альтернативы «один раздел на корневую папку» мне стало ясно, что этот подход имеет следующие преимущества:

  • Четкое, однозначное различие и разделение между папками (особенно, если у меня их больше 2 или 3, что часто бывает, когда я использую другие редакторы и IDE)
  • Обеспечивает представление о том, что корневая папка является отдельным (подпроектом)
  • Быстрый доступ к командам подпроекта (например, «новый файл», «обновить» ... и, возможно, в будущем, щелчок правой кнопкой мыши для запуска задачи (например, «перестроить») в этом конкретном подпроекте;))
  • Как упоминалось во второй группе, при таком дизайне менее вероятно возникновение проблемы с усечением имени папки.

Что касается концепции «один раздел на корневую папку» ... Я действительно не уверен, что это сработает для меня и для большинства моих сценариев использования. Всякий раз, когда у меня есть ситуация с несколькими корнями, обычно их много ; не просто 2 или 3.
Я не уверен, насколько масштабным будет этот подход?

Также аргументом в пользу текущего макета, подобного папкам, является то, что он согласуется с тем, как будет отображаться монорепозиторий. Например, сравните:

monorepo/      <- contains .git
  project1
  project2

vs.

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

Эти два файла действительно должны обрабатываться VSCode одинаково: monorepo уже есть (фиксация: естественный, поиск: «файлы для включения», несколько README: их папка отображается на вкладке редактора и т. Д.). Multi-root должен следовать этому как можно точнее, IMO, что очень хорошо делает текущий дизайн.

@stevencl Одна вещь, которую я не совсем понял: будет ли решение обеспечивать ограниченную (или даже иерархическую) обработку настроек .vscode ? Например, если бы у меня было .vscode на папку верхнего уровня, будут ли эти настройки применяться индивидуально? Будут ли они как-то агрегированы в корне проекта? Или будут учитываться только «основные» .vscode ?

Я предпочитаю дизайн «один раздел на корневую папку» по тем же причинам, которые указаны @maddouri. Кроме того, при использовании другой альтернативы (в Atom) визуально сложнее найти, где начинается новая корневая папка, когда открыты и раскрыты несколько папок с высокой иерархией.

Спасибо за обновления дизайна, выглядит действительно хорошо!

Есть ли возможность одновременного использования нескольких рабочих пространств в пользовательском интерфейсе? Чтобы можно было легко переключаться между ними. Например, у вас есть что-то вроде:

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

А затем щелчок / двойной щелчок по разделителю CONNECT, CONNECT-PLUGIN переключится на его активное рабочее пространство. Это позволит легко переключаться между рабочими пространствами для людей, которым приходится иметь дело с несколькими наборами проектов. Я не предлагаю, чтобы все они были доступны для поиска, SCM и прочего, это осталось бы с текущим рабочим пространством, которое в настоящее время является расширенным.

Затем это могло бы работать с выделением корневых папок, как предлагается в первой группе, и, возможно, с появлением новых значков файлов / папок, доступных при наведении курсора на эти папки.

Некоторые отзывы о настройках JSON, может быть полезно, чтобы настройки рабочего пространства были примерно такими:

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

Таким образом, root становится источником для открытия папок, а не путем, но сам корень не открывается, только каждая папка. Тогда у вас не будет «основной папки», но сохраните относительные пути к файлам. Предполагается, что вы можете открыть заранее определенное рабочее пространство через пользовательский интерфейс, а не открывать корневую папку и все дополнительные папки с ней. Имя затем можно использовать в качестве разделителя, предотвращая слишком большое количество имен папок, делая его слишком длинным или укорачивающим без всякой пользы.

Если выбрано решение «один раздел на корневую папку», то я хотел бы предложить, чтобы видимая в данный момент корневая папка «прилипала» к верхней части боковой панели, а не прокручивалась вверх из поля зрения. Он будет прокручиваться вверх только после того, как последующая корневая папка достигнет верхней части боковой панели.

4 июня 2017 г. в 06:47 Петр Петров [email protected] написал:

Я предпочитаю дизайн «один раздел на корневую папку» по тем же причинам, которые указаны @maddouri. Кроме того, при использовании другой альтернативы (в Atom) визуально сложнее найти, где начинается новая корневая папка, когда открыты и раскрыты несколько папок с высокой иерархией.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите чат.

Или мы можем следовать подходу Sublime, Atom, но изменить цвет или как-то показать, какая папка является корнем, и / или приклеить ее вверх. Конечно, оба подхода хороши, но наличие большого количества открытых папок уменьшает пространство, потому что панель с обновлением, созданием нового файла и т. Д. Будет видна, поэтому лучше не загружать панель, а как-то показать, какая папка корень. НО, опять же, эта панель действительно хороша, потому что намного легче видеть открытые корневые папки, и вы можете обновлять их и делать другие вещи, которые включены в панель. Нам нужно увидеть, как это выглядит, например, для 10 папок, открытых с полосой и без нее.

@stevencl Спасибо, что разместили эти записи! В целом, я в восторге от того, в каком направлении развивается эта функция! Спасибо за все время и усилия, вложенные до сих пор. Вот мои отзывы / мысли:

  • Я предпочитаю первый дизайн с дизайном панели имен одной папки в разделе «EXPLORER», однако меня беспокоит, что, если все имена папок перечислены там, они очень быстро будут усечены, чтобы отобразить «добавить файл», » добавить папку »и др., кнопки. Я бы просто поставил строку "Multiple" или что-то подобное, когда открыто более одной папки; в противном случае есть только одна папка, поэтому укажите в ней имя папки, как это сделано сегодня (и скройте корень папки в дереве).
  • Устранение неоднозначности имен файлов путем добавления имени папки в заголовок вкладки в редакторе IMO не требуется, если только не открыто несколько редакторов с одним и тем же именем файла. Обратите внимание, что этот сценарий не редкость даже с одной открытой папкой. Достаточно легко получить несколько файлов (например, .gitignore ) с одинаковым именем среди подпапок в одном корне. Таким образом, этот дизайн (добавление имени родительской папки) должен быть отдельной функцией, IMO, и должен быть реализован. Наряду с этим, я бы хотел увидеть хорошее решение для https://github.com/Microsoft/vscode/issues/15048, потому что это сделает некоторые заголовки вкладок еще длиннее. :)
  • Для результатов поиска я считаю важным, чтобы поиск работал во всех корневых папках. Можно добавить другой фильтр, чтобы ограничить поиск выбранными корнями. При отображении результатов может быть полезно видеть результаты для каждого корня, поэтому, возможно, есть возможность увидеть один длинный список с добавленными именами корневых папок или просмотреть список, разделенный на разделы, по одному для каждой корневой папки.
  • Мне кажется странным, что вы предлагаете добавить «рабочие области» в настройки __user__. Я действительно ожидал, что это окажется в настройках __workspace__. Я думаю, вы на самом деле говорите, что настройки рабочего пространства могут также содержать новое свойство «рабочие пространства», что хорошо. Также хорошо, что пути к рабочему пространству могут быть относительными. Это просто не похоже на то, что вообще относится к пользовательским настройкам. Эта функция очень специфична для рабочих пространств. Ах, но теперь я понимаю, почему он также действителен в пользовательских настройках, потому что он дает мне возможность хранить эти рабочие пространства, когда мне нужны «случайные» папки на моем жестком диске в одном рабочем пространстве, где нет общего корня.
  • Одна вещь, которая, кажется, теряется в рабочих пространствах, когда они хранятся в пользовательских настройках, - это возможность приписывать другие специфичные для проекта настройки тому или иному рабочему пространству. Например, если бы у меня было рабочее пространство, где мне нужно, чтобы размер вкладки составлял 2 пробела, а в другом - 3, я бы не смог сделать это с рабочими пространствами в пользовательских настройках. Мне пришлось бы где-то создать папку, а затем поместить в нее папку .vscode , а затем определить .vscode/settings.json , чтобы окончательно определить мое рабочее пространство с соответствующим переопределением размера вкладки. На этом этапе я думаю, что создание нового типа файла проекта VSCode, в котором хранятся все эти настройки и который может быть открыт как специальный файл, становится гораздо менее громоздким, чем создание этой иерархии папок для хранения рабочей области settings.json файл ...

В первом варианте для дополнительных папок путь (относительный или абсолютный) в скобках может быть добавлен к имени для различения. Думаю, это будет простое решение.

@stevencl спасибо за запись сеансов. Я действительно хотел поучаствовать, но в то время был недоступен 😢

Мне понравился предложенный интерфейс SCM. Наличие сводного раздела и одного раздела для каждой папки дает мне, IMHO, гораздо более простой интерфейс для обнаружения изменений и работы с ними. И мне нравится идея иметь единообразное поведение во всем пользовательском интерфейсе, поэтому идея « Один раздел для каждой папки» также должна использоваться на вкладке « Поиск », вместо того, чтобы объединять имя папки для каждого результата. То же самое для вкладки Explorer .

Использование пользовательских настроек для хранения _Multi-Folder_ для меня немного странно, потому что это _не похоже на пользовательские настройки_: smile :. Если цель состоит в том, чтобы избежать создания новых файлов и упростить передачу / синхронизацию проектов / рабочих пространств между компьютерами, почему бы вам просто не забыть о _пользовательских настройках_ и сделать запись additionalFolder _always_ частью Workspace Settings . При этом, когда вы _Добавляете папку_, она будет добавлена ​​только в Workspace Settings . Затем, открывая папку, вы просто ищите там .vscode\settings.json файл и запись additionalFolders , чтобы проверить _, если это рабочее пространство с несколькими папками_. _Это похоже на второй пример, который вы использовали, о двух недостающих репозиториях git_.

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

Кроме того, поддерживаются такие расположения _user-data_, как ~ и $home , что упрощает совместное использование проектов между разными компьютерами / платформами.

Я упустил только один момент: API . Как расширения будут интегрироваться с этим?

Спасибо за старания. С нетерпением жду первых инсайдерских релизов 👍

Спасибо за ответ! Я хотел проследить за направлением использования нового свойства настроек additionalFolders для реализации "Multi Root", потому что я слышал отзывы об этом из комментариев выше.

Основная мотивация для введения сеттинга в первую очередь состоит в том, чтобы упростить вещи и не вводить слишком много новых концепций, имея при этом мощное решение, допускающее некоторые интересные сценарии. Вот некоторые дизайнерские решения и последствия:

Будь проще
Мы считаем, что открытие файлов и папок лежит в основе VS Code. Таким образом, мы не хотели бы вводить новую концепцию верхнего уровня «Проекты». Например, мы не думаем, что нужно действие «Открыть проект», а думаем, что проект всегда является папкой и может иметь дополнительные связанные папки. При таком предположении настройка кажется естественным способом учесть это. Всякий раз, когда вы открываете эту папку, вы открываете с ней дополнительные папки. Добавление и удаление папок - это простой жест, который напрямую обновляет настройки.

Настройки мощные
Наличие множественного корня в качестве настройки позволяет реализовать множество интересных сценариев. Например, вы можете поместить настройку additionalFolders в свою рабочую область и поделиться ею с другими людьми (используя относительные пути - это показано в видеороликах).
Кроме того, вы также можете свободно настраивать проекты в первую очередь: например, в некоторых случаях нет четкого отношения главной папки к дополнительным папкам (например, может быть, что некоторые из них даже не связаны с друг друга). В этом случае вы можете просто создать папку «проект», которая просто включает settings.json с папками, на которые он ссылается:

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

Теперь, когда вы откроете allMyRandomProjects он покажет вам список папок на основе настроек. Вы даже можете включить некоторые настройки в settings.json которые должны применяться ко всем показанным папкам.

Переключение рабочего пространства и мультиокна
Без сомнения, нам нужно работать над улучшением переключения рабочего пространства и поддержкой нескольких окон в VS Code. Поскольку мы относимся к многокорневой рабочей области так же, как и к любой другой рабочей области с папкой, улучшение переключения рабочих областей и поддержка нескольких окон принесут пользу любому пользователю, даже тем, кто не использует многокорневые рабочие области.
Нам нужно будет найти лучшие и более простые способы переключения между папками и открытыми окнами независимо от мульти-корневого доступа.

В моем следующем комментарии я выскажу некоторые отзывы о сделанных отдельных комментариях.

Поиск @borekb будет включать опции для ограничения определенной корневой папки (или нескольких) точно так же, как вы можете настроить поиск, чтобы уже сегодня включать определенный путь.

@maddouri @TurkeyMan @pesho , @dgileadi @stefcameron кажется очевидным, что некоторые люди предпочитают одно дерево, а другие предпочитают несколько разделов в проводнике. Таким образом, мы можем в конечном итоге настроить это, есть плюсы и минусы для обоих решений, и пользователь должен решать, какое из них лучше для сценария.

@borekb способ применения настроек может немного измениться в зависимости от того, используете вы систему с несколькими корнями или нет: пользовательские настройки всегда применяются ко всем папкам, открытым, как и раньше. Настройки рабочего пространства будут взяты из основной («главной») папки и применены ко всем файлам и папкам, которые с ней связаны. Теперь вы по-прежнему можете определять настройки для любой из дополнительных папок через настройки рабочего пространства, хотя мы можем поддерживать не все из них. Например, такой параметр, как update.channel: none не может поддерживаться для отдельных папок. Что нам нужно сделать, так это определить настройки, которые мы можем поддерживать на уровне папки (например, files.exclude , все настройки редактора), и внести необходимые изменения, чтобы включить их. Это одна из основных областей работы, в которую мы должны инвестировать, тем более, что расширения также могут определять параметры, которые мы хотим поддерживать для каждой папки.

@BTMorton, мне кажется, вам нужны более простые способы переключения рабочих пространств. Это то, что мы должны изучить независимо от мульти-корневого доступа для любого перехода папки, который может сделать пользователь.

@stefcameron, мы будем держать параметр additionalFolders достаточно открытым, чтобы в конечном итоге добавить к нему дополнительные метаданные. Например, я мог бы подумать о возможности указать имя для такой конфигурации, чтобы переключение между проектами происходило по имени, а не по основной папке.

Одна вещь, которую мы еще не затронули в видео, - это то, как расширения могут поддерживать многокорневые папки. Еще одна основная цель с поддержкой множественных корней (помимо «простоты»): не нарушать расширения

Сегодня расширения имеют простой API для доступа к текущей открытой рабочей области ( workspace.rootPath: string ). Это свойство может быть null если папка не открыта.

Теперь, с введением параметра additionalFolders , расширение все еще может полагаться на установленное свойство workspace.rootPath (если папка открыта) или нет (если папка не открыта). Поскольку additionalFolders на самом деле является параметром, расширение может свободно читать и даже записывать в этот параметр с помощью API-интерфейсов, которые у нас уже есть сегодня для настроек. При изменении этого параметра даже возникает событие, позволяющее динамически реагировать на изменение этого параметра пользователем.

Чтение этого параметра позволяет сообщить расширению о дополнительных папках в рабочей области. Например, расширение Travis CI может выбрать отображение агрегированного статуса для всех папок.

Написание этого параметра позволяет реализовать некоторые интересные сценарии для расширений: например, у вас может быть расширение менеджера проекта, которое динамически добавляет и удаляет папки в вашем рабочем пространстве и, как таковое, позволяет переходить между проектами в окне, например, показывая список проектов через пользовательский интерфейс средства выбора. .

В какой-то момент мы, вероятно, представим какое-то настоящее новое расширение API для работы с многокорневыми папками. Спрятать это в настройках расширений для чтения / записи немного странно. Но для начала расширения уже могут изучить параметр additionalFolders чтобы использовать его, если это возможно. Мы также будем тесно сотрудничать с авторами расширений, чтобы понять их сценарии и способы их лучшей поддержки.

@bpasero Будет ли добавлена ​​концепция дополнительных папок в LSP, или VS Code просто запускает один языковой сервер для каждой дополнительной папки?

@felixfbecker - это то, что нам еще нужно инвестировать и изучить, чтобы найти хорошее решение для языковых расширений. Как только мы подумаем о дополнительных API для расширений, нам также необходимо подумать о том, что это означает для LSP.

Однако стоит упомянуть, что сегодня уже могут быть ситуации, когда пользователи открывают файл из папки, которая не открыта как рабочая область (например, File> Open> somefile.xyz). В идеале языковое расширение может отображать тот же уровень языковых функций для такого файла, даже если папка этого файла не открыта.

Вначале открытие файла из одного из additionalFolders будет вести себя очень похоже на открытие файла, которого нет в папке, которую вы открыли изначально. TypeScript, например, может хорошо справиться с этим случаем: они просто переходят от текущего открытого файла до тех пор, пока не будет найден файл tsconfig.json а затем рассматривают его как проект. Такие функции, как поиск ссылок, работают без проблем:

image

Было бы неплохо, если бы любое языковое расширение могло работать, просто переходя из текущего активного файла, вместо того, чтобы принудительно указывать контекст проекта.

@bpasero спасибо за комментарии. Таким образом, кажется, что в текущей модели всегда будет «главная» папка : даже в примере allMyRandomProjects это в основном главная папка, хотя в основном пустая. Это имеет некоторые тонкие последствия, но мне нужно подумать об этом еще немного, чтобы предоставить полезную обратную связь.

В целом, я думаю, что VSCode должен поддерживать монорепозиторий и несколько репозиториев очень похожим образом, как указано в комментарии выше: https://github.com/Microsoft/vscode/issues/396#issuecomment -306040485.

Кстати, как вы определяете «корень»? Если я открываю папку A, содержащую подпапки B и C, насколько это отличается от определения A как path и B и C как additionalFolders ? VSCode намерен рассматривать эти две ситуации по-разному или в основном одинаково? (Я думаю, это должен быть очень похожий опыт.)

@bpasero

Вначале открытие файла из одной из дополнительных папок будет очень похоже на открытие файла, которого нет в папке, которую вы открыли изначально. TypeScript, например, может хорошо справиться с этим случаем: они просто переходят от текущего открытого файла до тех пор, пока не будет найден файл tsconfig.json, а затем рассматривают его как проект. Такие функции, как поиск ссылок, работают без проблем:

Однако TypeScript не использует LSP. В LSP языковые серверы имеют rootUri , и, например, PHP будет использовать этот rootUri для сканирования файлов, которые необходимо проиндексировать. У него нет такого файла, как tsconfig.json, который бы обозначал «проект». Поэтому, если есть файлы, которые открываются не через didOpen но также не через rootUri , тогда они не будут учитываться для анализа кода, поэтому у меня вопрос, будет ли LSP расширен для этого.

Чтобы уточнить, будет ли открытие нескольких корней создавать файл ./.vscode/settings.json если он еще не существует?
Судя по тому, что я читал здесь, похоже, что мы говорим, что да.

Я понимаю, почему полезно избегать добавления концепции проектов, но, возможно, было бы хорошо сделать сохранение рабочего пространства необязательным - хотя в этом случае «сохранение» означает просто создание файла настроек в корневой папке.

Я думаю, что пользователя, который не следил за этой веткой, может удивить, если он откроет вторую папку и создаст файл настроек. Открытие папок - это то, что, по моему мнению, большинство пользователей ожидают только для чтения.

Спасибо всем за отзывы, это очень полезно.

@saborrie - хороший вопрос о том, насколько люди будут удивлены созданием настройки при добавлении папки. Нам нужно будет изучить это, чтобы увидеть, так ли это (очевидно, с людьми, которые не следили за этой веткой :-)).

@borekb - мы говорили о сценарии, о котором вы упомянули (открытие папки, содержащей одну или несколько подпапок), и склоняемся к тому, чтобы рассматривать это так же, как открытие многокорневой рабочей области. Однако проблема заключается в том, чтобы определить, когда рассматривать такую ​​ситуацию как мультикорневую, а не только папку, содержащую другие папки.

Мне было бы интересно, что думают об этом и другие.

@borekb, вы поднимаете хороший вопрос, я бы также сказал, что если вы откроете одну папку, содержащую несколько репозиториев git внутри, наше представление SCM сможет показать вам то же представление, которое вы получили бы, если бы вы настроили это явно через additionalFolders свойство. Я думаю, что мы можем начать изучать эту эволюцию пользовательского интерфейса с папок, в которых установлен параметр additionalFolders а затем расширить его до большего количества вариантов использования. Еще один интересный и связанный сценарий - это то, как мы решили представить подмодули в репозитории.

Я также думаю, что в конечном итоге мы захотим поддержать настройки .vscode на любом уровне иерархии папок, как только мы решим связанные с этим проблемы.

Я бы меньше говорил о взаимосвязи «мастер-детали», когда говорю о мульти-корневом, потому что большая часть пользовательского интерфейса будет рассматривать основную папку наравне с дополнительными папками. Основная папка на самом деле является просто контейнером настроек для дополнительных папок и будет основным драйвером для глобальных настроек рабочего пространства. Для обратной совместимости он также будет тем, который мы отправляем расширениям как rootPath .

@felixfbecker означает

@saborrie, мы НЕ добавляем настройку рабочего пространства по умолчанию при добавлении папок. Одна из причин, по которой мы решили добавить это в настройки пользователя, состоит в том, чтобы рабочее пространство не становилось «грязным» при настройке с несколькими корнями. Поместить этот параметр в рабочую область можно, но вам нужно будет сделать это вручную. По умолчанию этого не произойдет.

@bpasero Хорошо, да, сохранение в пользовательских настройках, а не в настройках рабочего пространства, предотвратит загрязнение папок рабочего пространства - я предполагаю, что он все равно сохранится, прежде чем потребовать от пользователя явного выполнения действия сохранения, хотя да?

Это оставляет мне два дополнительных вопроса:

1) Что произойдет, если пользователь откроет рабочее пространство с additionalFolders определенным в его настройках рабочего пространства? Будет ли это синхронизировано с их пользовательскими настройками? и переопределит ли он запись для этого корня рабочей области, если она существует в списке рабочих областей пользовательских настроек? Или наоборот?

2) Является ли размещение этого списка рабочих пространств в пользовательских настройках лучшим вариантом, чем изначально избегать хранения рабочих пространств в любом из этих файлов настроек JSON? В текущей системе с одной папкой, когда папка повторно открывается из пункта меню File > Open Recent , вкладки, которые были открыты ранее, запоминаются - насколько я могу судить, это не сохраняется ни у одного пользователя -редактируемый файл настроек, нельзя ли сохранить дополнительные пути таким же образом, пока пользователь не сохранит их явно?

- Простите за английский, я использовал Google Переводчик -

Ну, я просмотрел макет (да - небольшие трудности с пониманием английского). Тогда извини...

Мне не понравился макет, представленный @maddouri , в основном из-за проблем, обнаруженных в этом выпуске (# 25352, # 25354). Я думаю, что это будет сложнее, даже если вам придется использовать клавиатуру для доступа к папкам в отображаемой модели.

Я предпочитаю эту модель, в которой по идее я могу перемещаться между разными папками проекта с помощью клавиш со стрелками, и если мне нужно создать папку / файл в основной папке, я могу использовать клавишу меню на клавиатуре прямо в главном папка.

explorernew

И / или с параметрами нового файла, обновления новой папки и Свернуть все.

explorernew2

Что касается заголовка, который появляется вверху, я предпочитаю, чтобы он фокусировался на текущем файле с папкой, в которой он находится, или вместо отображения всех открытых основных папок плюс текущий файл, как это показано на этом изображении.

explorernew3

И вопрос: будут ли еще существовать Open Editores?

@bpasero

Означает ли это, что я не могу выполнить «Найти ссылки» или аналогичные языковые функции при открытии только одного PHP-файла моего проекта, мне нужно открыть эту папку, чтобы получить эти функции? Я не очень разбираюсь в PHP, но если есть концепция межфайловых зависимостей, я не смогу перейти к другому файлу PHP из одного файла, мне нужно сначала открыть папку?

Это правильно, если вы просто откроете один файл, вы не сможете перейти к определению файла в другом файле, который не открыт, а только тех, которые находятся ниже rootUri . Это потому, что в PHP каждый файл может сбрасывать символы в глобальном пространстве имен, а пространства имен на самом деле являются просто префиксами имен для классов. Нет никаких ограничений на то, как пространства имен и имена классов должны соответствовать каталогам и именам файлов (только некоторые соглашения), и нет операторов импорта, как в TS, только псевдонимы пространств имен. Загрузка классов происходит во время выполнения через зарегистрированные «автозагрузчики». Это означает, что для языкового сервера при переходе к определению символ может быть определен в любом файле. Таким образом, языковой сервер будет индексировать все файлы в rootUri при запуске, а затем работать с индексом, чтобы отвечать на запросы. Что действительно работает, так это если у вас открыт проект и вы создаете новый несохраненный файл - вы получите информацию об этом, потому что вы получили rootUri и новый файл через textDocument/didOpen . Но любые символы, определенные в неоткрытых файлах не ниже rootUri , не будут рассматриваться.

Настройки рабочего пространства additionalFolders внутри рабочего пространства всегда имеет приоритет. Однако, учитывая характер этого параметра, вы можете переопределить дополнительные папки для текущей открытой папки только тогда, когда этот параметр указан внутри рабочей области (это показано в видеороликах, имея path: "." в качестве «мастера»).

Мы обсуждали вариант, когда это состояние пользовательского интерфейса хранится аналогично тому, как, например, количество открытых вкладок, но мы не обнаружили, что он имеет много преимуществ перед параметром. Некоторые причины:

  • этим нельзя делиться (ни через настройку рабочего пространства, ни через расширение синхронизации настроек)
  • сегодня это не то, к чему расширения могут легко получить доступ (API настроек существует, API состояния пользовательского интерфейса нет)

Есть ли особая причина, по которой вы не хотите, чтобы это было внутри настроек?

@Tekbr да, "Открытые редакторы" будут работать как раньше

@felixfbecker, сможет ли расширение PHP легко принять что-то вроде rootUri: string[] ? Или вы бы предпочли, чтобы языковой сервер PHP запускался несколько раз для каждой открытой папки (например, VS Code будет мультиплексироваться на уровне открытых папок с N языковыми серверами?)

@bpasero PHP может довольно легко работать с rootUris: string[] . Однако серверы на других языках не могут. Создание нескольких языковых серверов будет означать, что каждая папка будет работать изолированно (без перехода к определению, поиска всех ссылок между ними). Возможно, подходом будет новый ServerCapability который решает, будет ли VS Code создавать один или несколько языковых серверов.

Мне нравится концепция настройки дополнительных папок. Для меня достаточно одной корневой папки. Если мне нужна полная функциональность разработки связанного проекта, я могу открыть новое окно vscode.

То, что мне нужно от дополнительных папок, - это просто ограниченная функциональность. Например, мне может понадобиться определение символа из связанного проекта для использования в корневом проекте, но мне не нужна или не нужна возможность переименовать его или найти все ссылки на него в дополнительной папке.

@bpasero Я просто

Я не совсем против того, чтобы хранить данные полностью в настройках, я просто делаю все, чтобы поставить под сомнение решение не использовать состояние пользовательского интерфейса, на случай, если оно было упущено.

@bpasero @saborrie Если мы пойдем по этому пути, я бы добавил, что при появлении запроса на сохранение в настройках должна быть опция «запомнить мой выбор» (для сохранения рабочих пространств в настройках, будь то настройки пользователя или настройки проекта). Я был бы разочарован, если бы открыл окно VSCode, загрузил несколько папок, заставил все работать так, как я хочу, а затем произойдет либо перезагрузка, либо сбой, и я потерял всю свою конфигурацию для этой комбинации папок, потому что рабочее пространство никогда не сохранялось на диск.

# 396 (комментарий)

@Tekbr да, "Открытые редакторы" будут работать как раньше

Спасибо за ответ, @bpasero.

TL; DR: используйте древовидное представление всякий раз, когда это имеет смысл, в отличие от добавления имени корня к каждому элементу.

Несколько вещей, мне действительно не нравится, как вы добавляете папку в конец, я бы очень хотел, чтобы это было вариантом, потому что я, вероятно, хотел бы, чтобы это было так: express\.editorconfig и express-plugin\.editorconfig так возможно, вы можете предложить следующий вариант: editor.tabName: "${root}\${filename}"

Еще одна вещь, которую я хотел бы, и вы упомянули об этом в видео, - это окраска корней, чтобы она соответствовала вкладкам, поэтому 👍 для этого.

Поиск:

В представлении Search я бы действительно подумал, что вы делаете ошибку, насколько мне кажется опыт, это должно отображаться в виде дерева, например:

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

Причины этого:

  1. Вы можете легко увидеть, где находятся файлы, независимо от длины их имен.

  2. Вы можете разрушить корни, которые не хотите видеть.

Я думаю, что это также больше подходит для дизайна, который вы применили к Explorer .

Задания:

За Tasks я бы предпочел иметь такой вид:

express
    Compile
    Run Tests
express-plugin
    Compile
    Run Tests

Несколько моментов:

  1. На мой взгляд, вы не должны касаться / изменять имена папок, это означает, что «экспресс-плагин» должен отображаться точно так, как он отображается в Explorer а не как «Экспресс-плагин».

  2. Перемещение между задачами с помощью клавиатуры также может быть выполнено таким образом, чтобы игнорировать выбор корней, поэтому, если вы переместитесь вниз с express\"Run Tests" в примере, следующий элемент, который будет выбран, будет express-plugin\Compile as в отличие от express-plugin

ps еще не видел всего видео, но это только то, что пришло в голову.

Что, если все корневые папки, которые вы включаете в свою рабочую область, имеют одинаковое имя?
например

  • / Дев / проект / общественности / SRC
  • / dev / framework / src
  • / Dev / некоторые-компоненты / SRC

Тогда у вас будет рабочее пространство с:

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

Согласно _sublime_ способу включения папок в рабочую область, каждая корневая виртуальная папка имеет:

  • Путь
  • Имя (необязательно) - это имя папки, если она исключена, но может отображаться как угодно
  • Фильтр исключения для файлов / папок

См. Примечание https://github.com/Microsoft/vscode/issues/396#issuecomment -283541760 (выше), в котором приведены метаданные, связанные с этим способом работы.

Я хотел бы знать, что эта функция все еще находится в стадии разработки?

@ifzm Это так, и если вы прочитаете примечания к последнему выпуску (май 2017 г. (версия 1.13)), то узнаете, что они активно работают над этим.

@eyalsk Извините, я не посмотрел внимательно, это интересная особенность: D

Я не без ума от концепции additionalFolders , хотя понимаю стремление к простоте.

Мне кажется странным, что в одной из наборов папок будет храниться конфигурация «рабочего пространства».

Представьте себе следующие корневые папки:

  • Веб-сайт
  • api
  • мобильный

... какая папка должна содержать настройку additionalFolders ? Почему?

Я предпочитаю идею рабочего пространства / менеджера проекта, где настройки хранятся в общем / общем месте. Я действительно не думаю, что это сложно с точки зрения UX, и существующая терминология workspace может быть повторно использована / расширена.


Несвязанный: я полностью согласен с комментариями @eyalsk относительно вложенных списков (и именования вкладок).

@ glen-84, в этом случае у вас может быть четвертая папка на диске под названием «my-mobile-website-project», которая имеет этот параметр и ссылки на все другие папки.

@bpasero Я понимаю это, но на самом деле это просто взлом.

Чтобы уточнить:

Я занят работой над website и решил, что хочу внести некоторые изменения в api . Если я нажму Add Folder , он свяжет api с website , так что открытие website в будущем открывает api также. Мне нужно понять, как это работает, и когда я это сделаю, мне придется открыть отдельный экземпляр VSC, создать пустую папку с соответствующим именем, добавить в нее обе «проектные» папки, а затем закрыть первоначальный экземпляр.

Напротив, я мог бы просто пойти Add Folder , и он мог бы (необязательно) запросить имя рабочего пространства, которое будет использоваться в будущем для одновременного открытия обеих папок.

workspaces.json (пример)

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

Я просто чувствую себя более гибким и менее неудобным.

@ glen-84 понял. Использование предложенного вами решения усложняет использование VS Code, поэтому мы отказались от такой концепции. Основная причина в том, что внезапно появляется не только «Открыть файл» и «Открыть папку», но и «Открыть проект». Оставаться с имеющимися у нас примитивами - это более простой подход без введения новых концепций.

Тем не менее, вся работа, которую мы делаем сейчас для поддержки нескольких папок, хороша также для сценариев, которые вы предлагаете. Если мы когда-либо захотим поддержать ваш сценарий, шаги по его достижению будут гораздо менее сложными, потому что пользовательский интерфейс уже подходит для этого. Я также мог предположить, что, возможно, расширение могло бы ввести такое понятие рабочих пространств, и мы просто добавили необходимые API для поддержки этого.

Давайте сначала наладим UX без введения новых концепций, а затем подумаем о других сценариях, связанных с несколькими папками. Сначала нужно посмотреть на множество вещей (расширения, настройки, SCM UI и т. Д.).

ваше предлагаемое решение делает использование VS Code более сложным

Я не согласен с этим. Если пользователя смущает необязательная функция «Открыть проект» (или рабочая область), то он, вероятно, будет сбит с толку многими существующими функциями в VSCode. Это несложно с точки зрения пользователя (если кто-то, читающий это, не согласен, скажите об этом).

Я также мог предположить, что, возможно, расширение могло бы ввести такое понятие рабочих пространств, и мы просто добавили необходимые API для поддержки этого.

Расширение уже существует и уже упоминалось несколько раз. У автора даже есть поддержка нескольких папок для отслеживания открытых тикетов . У этого расширения более 370 тысяч установок, а рейтинг - 4,7. Даже с упрощенным пользовательским интерфейсом, использующим палитру команд, судя по комментариям, нет никаких признаков путаницы.

Давайте сначала наладим UX без введения новых концепций, а затем подумаем о других сценариях, связанных с несколькими папками.

Это достаточно справедливо. В любом случае, речь идет о поддержке нескольких корневых папок в одном окне - фактический метод управления этими группами папок может быть рассмотрен на более позднем этапе.

Не могли бы вы создать публичный опрос для сбора мнений пользователей по этому вопросу (я знаю видео на YouTube, но я имею в виду этот аспект отдельно), или уже было принято решение пойти с additionalFolders концепция?

Я согласен с @ glen-84. Я не понимаю проблемы сложности. Да, можно усложнить, но это редактор кода. Я думаю, что 95% программистов используют его, и они легко могут понять идею проектов. Не следует беспокоиться о том, чтобы сбивать с толку людей каждый день, потому что люди не используют его каждый день.

Хотя расширение - это своего рода решение, расширения также являются второстепенными по сравнению с встроенными улучшениями (т.е. не могут добавлять параметры в меню, только палитру команд и т. Д.).

@ glen-84 было принято решение использовать настройку additionalFolders на основе настроений в команде разработчиков, проведенных нами исследований пользователей (эти 2 видео) и отзывов, полученных в этом выпуске.

@pltrant делает использование множественного корня более сложным, потому что вам постоянно нужно думать об открытии папки или открытия проекта. Такие вещи, как «Открыть недавние» внезапно потребуют большего внимания, если выбранная запись - это папка или проект, или, что еще хуже, у вас даже будет 2 средства выбора, и вам нужно будет решить, какой из них использовать.

Я не уверен, насколько сложнее иметь сеттинг. По сути, вам не нужно заботиться о настройке, вы просто добавляете и удаляете папки в настройках, и настройка обновляется в фоновом режиме. Я бы сказал, что в большинстве случаев вы никогда не оцениваете значение этого параметра.

@ glen-84 Что касается вашего примера проекта с 3 папками одинаковой важности, я думаю, какая из них должна содержать настройки additionalFolders , следует выбирать по зависимости. Если папка API не зависит от другого проекта, при открытии она должна открываться как отдельная папка и не должна содержать никаких дополнительных настроек папок. Но когда вы открываете мобильную папку, я предполагаю, что она зависит от папки API. Итак, вы добавляете настройки в мобильную папку для открытия API в качестве дополнительной папки при открытии в vscode. То же самое и с веб-сайтом. Если это зависит от api, добавьте туда настройки. В противном случае никаких настроек не требуется.

Я не думаю, что будет происходить рекурсивное или каскадное открытие дополнительных папок. Мне также нравится идея, что расширения читают другие форматы проектов, такие как решения Visual Studio, и предлагают / устанавливают дополнительные настройки папки. И вы всегда можете открыть общую родительскую папку для всех.

@stevencl посмотрел оба видео.

  1. Вариант 2 с устранением неоднозначности кажется наиболее ясным. Похоже, что это может быть сворачиваемый (то есть один из корней в дереве), что позволит просматривать сразу несколько проектов. Если вам нужен макет, дайте мне знать.

  2. Альтернатива 2 более эффективна с точки зрения экранной недвижимости. У вас не будет той же информации (название проекта), которая повторяется вверху - как в варианте 1, а затем отображается в корне каждого проекта.

  3. Результаты поиска и Git могут вести себя так же ... как сворачиваемое дерево. Результаты будут сгруппированы (по статусу) под соответствующими заголовками. Я предполагаю, что если вам нужна сводка с возможностью навигации (как вы показали для GIT, это была бы опция, которая могла бы существовать в поиске (сколько файлов вы нашли) и в области проекта (это может содержать кнопки действий).

Итак, в общем, я поклонник отдельных складных корней с возможным добавлением навигационного резюме. Что-то вроде комбинации Альтернативы 2 и этого примера

Я надеюсь, что что бы вы ни выбрали, вы сделаете опыт одинаковым для различных механизмов. Вы говорите, что было две альтернативы, но на самом деле их четыре, поскольку GIT и поиск были разными. Я согласен с тем, кто оставил этот комментарий

Re: обмен информацией о нескольких проектах. Я думаю, это было бы полезно - как у вас это было бы разумно для начала - я бы просто использовал задачи gulp - или задачи, которые VS Code мог бы понять.

Спасибо за все ваши усилия.

Внедрение многокорневой рабочей области отслеживается на # 28344 и в июне этого года.

@gulshan ,

Могут быть случаи, когда нет зависимостей. Например, если я работаю над website и решаю добавить mobile чтобы работать над ним одновременно. Между ними нет зависимости, но теперь website становится «родительским». Если бы я сначала работал над mobile , тогда он стал бы родительским. Это немного произвольно. Папки также могут быть для совершенно не связанных проектов.

Тем не менее, я уважаю решение разработчиков VSC, даже если я не обязательно с ним согласен.

Спасибо за все постоянные комментарии. Как уже было сказано выше, мы отслеживаем работу по выпуску №28344. Мы учтем эти комментарии, пока продолжаем работать над этим, особенно при разработке интерфейса SCM. Как обсуждалось в видеороликах и как неоднократно упоминалось выше, мы хотим добиться единообразия на протяжении всего опыта.

Что касается проблемы сложности, которую подняли @ glen-84,

Обсуждение этого вопроса было действительно полезным и дало нам кое-что, о чем следует подумать в нашем текущем дизайне. Например, возможно, нам следует подумать о том, чтобы разрешить пользователям выбирать «основную» папку при добавлении второй папки в рабочую область. Может быть, мы запрашиваем это при закрытии рабочего пространства, может быть, это настройка. Нам есть над чем подумать, чтобы упростить работу.

Однако, как упоминает

Более того, как только что-то находится в VS Code, вынести это намного сложнее (со временем люди привыкают к этому и зависят от этого). Поэтому мы уделяем много времени тщательному обдумыванию того, что мы добавляем в VS Code, и добавляем что-то только тогда, когда уверены, что затраты на добавление новых концепций окупятся. Итак, прямо сейчас мы хотим определить, насколько успешным может быть дизайн для множественного корня, который не добавляет новых концепций.

Еще раз спасибо за невероятно ценный отзыв. Без такого диалога было бы намного труднее создать такой опыт.

Удивительно, насколько внимательны и отзывчивы все вы в команде; это действительно ценится!

Что, вероятно, еще не было сказано о сложности, так это то, что вы все равно добавляете ее. Думаю, сейчас обсуждаются эти два варианта:

  1. Явные проекты.
  2. Что-то, что выглядит как несколько простых папок, но на самом деле это не так - существует важная концепция основной папки, которая касается таких вещей, как rootUrl для расширений и, возможно, других вещей (например, наследования настроек рабочего пространства). Я думаю, что, как правило, пользователю VSCode необходимо понимать эту концепцию, и, возможно, было бы проще изложить ее прямо и открыто, чем пытаться абстрагироваться от нее.

На самом деле я бы предпочел третий способ, на самом деле не вводя ничего нового, просто обрабатывая такие вещи, как несколько репозиториев .git поиск, задачи и тому подобное, прозрачным способом - вроде того, что первые две трети видео предложил (мне очень понравились вайрфреймы). Однако затем я понял, что rootUrl необходимо учитывать для расширений, что, вероятно, является основной причиной, почему это сложно.

Если бы не rootUrl , я бы просто начал с обновлений пользовательского интерфейса, как предложено в каркасах, плюс локальное сохранение многокорневой рабочей области, точно так же, как все другие папки сохраняются в «Open Recent».

Я хотел бы повторить, что, с моей точки зрения, идеальное состояние - это когда VSCode работает с несколькими папками, независимо от того, являются ли они корнями SCM или нет (монорепозиторий или несколько репозиториев, см. Выше). Я считаю, что предложенных каркасов плюс некоторая дополнительная основная работа, такая как наследование настроек .vscode , будет достаточно для "v1" поддержки множественного доступа. «Проекты» или «основные + дополнительные папки» могут появиться позже, ИМО. Однако то, что я говорю, может упасть с rootUrl , я не уверен в этом, я просто хочу выразить свое общее мнение по этому поводу.

Здорово, что вы пытаетесь решить эту непростую задачу и максимально сохранить простоту!

У меня есть проект внутреннего и внешнего узла, и у меня открыто 2 редактора VisualCode, что является значительной нагрузкой на ресурсы.

Я просмотрел оба видео и согласен с вышеприведенным комментарием о том, что эти несколько проектов не должны иметь ничего общего друг с другом. Возможно, один может быть проектом nodejs, а другой - C ++.

Мне не понравилась идея, что один из проектов станет «главным» с добавлением дополнительных проектов. Каждый проект должен быть равным и не связанным.

Я ожидал, что смогу открыть папку, а затем открыть другую папку (не ДОБАВИТЬ). Папка будет просто добавлена, как на видео 1, с отображением только корней (но при наведении курсора на корневую папку будут показаны полные пути во всплывающей подсказке). Эти проекты были бы совершенно не связаны. Выбор одного или другого вызовет переключение контекста. Это было бы так, как если бы я переключался между двумя экземплярами Visual Code, обеими настройками, цветовыми схемами и т. Д.

Чтобы сохранить эти несколько проектов, можно сохранить их как новый файл проекта, который ссылается на два других проекта, но без изменения какого-либо из двух проектов. Другими словами, 2 проекта остаются независимыми, самодостаточными и не знают о третьем проекте (файле настроек), который на них ссылается.

После того, как этот третий файл будет сохранен / создан, должна появиться возможность создавать настройки, которые отменяют настройки из проектов A и B. Не созданные настройки снова будут зависеть от активного проекта.

При совместном использовании проекта можно предоставить общий доступ к файлу проекта, который ссылается на два других. Когда они отсутствуют в файловой системе, но содержат ссылку на их URL-адреса github, он должен спросить пользователя, хочет ли он их получить (по умолчанию в виде подпапки в корне этого главного файла проекта, но пользователь может найти желаемый место для каждого).

Возможность поиска в нескольких проектах должна быть необязательной, а возможность запускать и отлаживать несколько проектов одновременно была бы очень полезной, но кажется слишком сложной для первого выпуска, и, возможно, такой вариант использования в любом случае потребует запуска двух экземпляров. По крайней мере на данный момент.

То, как это должно выглядеть в пользовательском интерфейсе, - это второй шаг, но функционально я ожидал, что это будет работать именно так. Мне не нравится идея модифицировать проект A для ссылки на B или наоборот, и я понял, что это было намерением. Что касается Agile-разработчика, я был бы просто счастлив, если бы мог работать над 2 проектами в 1 окне вместо того, чтобы запускать 2 экземпляра, но пока не более того. Возможно, даже не с 3-м переопределяющим файлом проекта, а только с переключением контекста.

Спасибо за постоянную обратную связь. Существует определенная тема об отсрочке сохранения рабочего пространства с несколькими папками до некоторых явных действий со стороны пользователя (например, сохранения). Нам нужно больше подумать об этом и продолжить расследование.

Я также предлагаю разработчикам взглянуть на Eclipse IDE, чтобы узнать, как
обрабатывает эту функциональность, они давно разобрались и работает
отличный.

Во вторник, 13 июня 2017 г., в 9:11, Стивен Кларк [email protected]
написал:

Спасибо за постоянную обратную связь. Есть определенная тема о
отложить сохранение многопапочного рабочего пространства до некоторых явных
действие от пользователя (например, сохранить). Нам нужно больше подумать об этом
и исследуем дальше.

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-308110390 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAQsBWywBoe2KQRGuXKHv179MmugstCfks5sDop7gaJpZM4Gm3nX
.

-
Даниэль Соколовски
Технический архитектор

Stantive Technologies Group Inc.
Телефон: +1 (613) 634-7410
http://www.stantive.com

Уведомление о конфиденциальности:
Передаваемая информация предназначена только для физического или юридического лица.
который адресован и может содержать конфиденциальные и / или привилегированные
материал. Любое повторное распространение обзора или другое использование или
предпринимать какие-либо действия на основании этой информации лицами или
лица, кроме предполагаемого получателя, запрещены. Если вы получили
это по ошибке, пожалуйста, немедленно свяжитесь с отправителем, отправив электронное письмо.
передачи, а затем немедленно удалить эту передачу, включая все
вложения без копирования, распространения или разглашения.

Мастер-проект
Я против МАСТЕР-проекта. Переключение контекста происходит часто при работе с разными микросервисами. Это относится к следующим пунктам о линтинге и SCM.

Постоянство рабочего пространства
Я думаю, что на первой итерации нам не нужно сохранять рабочее пространство. Я бы предпочел итерации в одном или двух выпусках этой функции, прежде чем мы представим какие-либо настройки или уровни сохраняемости, чтобы минимизировать любые виды сложных или разрушительных миграций.

Линтинг / Настройки
Линтинг для конкретного проекта должен быть помещен в пространство имен для файлов в соответствующих каталогах. Например, в Project A используется более красивый, а в Project B - стандартный. Переключение между обоими контекстами должно быть плавным, и правила линтинга не противоречат друг другу.

Поиск
Мне понравились некоторые из каркасов для этого, где результаты поиска были по всем проектам и отсортированы по проектам.

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

_Project B_
file3: matched substring
file4: matched substring

СКМ
В этом случае я больше склоняюсь к тому, чтобы показывать разбивку по проектам при каждом изменении scm.

_Project A_
file1: added
file2: removed
...

_Project B_
file3: moved
file4: added
file5: added

Мне кажется, что эти подходы более прозрачны и интуитивно понятны.

Консенсус (основанный на недавних комментариях и других проблемах), кажется, противоречит идее additionalFolders , по крайней мере, в первоначальной версии.

Хотя я понимаю, что решение уже принято, не могли бы вы попытаться реализовать эту функцию в виде набора API-интерфейсов, оставив при этом постоянство на более позднюю итерацию? Итак, API для добавления / открытия папок и обновления для проводника, поиска, задач и представлений SCM для поддержки этого.

Вы говорили о том, как сложно удалить что-то из продукта (если концепция проекта / рабочего пространства каким-то образом не удалась), но в действительности это применимо в равной степени (если не в большей степени) к концепции additionalFolders .

Внедрение additionalFolders и «проектов / рабочих пространств» в качестве расширений позволит вам собирать данные об использовании без привязки к одной модели. Одно из этих расширений (или гибридное решение) впоследствии может быть интегрировано в продукт.

Устранены ли проблемы со средой в Mac OS? Я все еще не могу использовать Homebrew npm и тому подобное, не открывая VSCode из командной строки через code и это наверняка вызовет хаос с поддержкой нескольких root?

Да, мне это тоже необходимо. Я не понимаю проблем людей с этим. Возможно, это не так, как работает один человек, но это не означает, что предпочтительное управление рабочим пространством другого человека менее актуально. Я просто ненавижу ответы на вопрос "Почему вы хотите это сделать?" вместо «Давайте выясним, как добавить функцию, которая есть в любом другом редакторе кода в мире».

Думаю, вернемся к Атому.

@saborrie https://github.com/Microsoft/vscode/issues/24961 (у меня такая же проблема как для инсайдеров, так и для обычных версий). Если я могу помочь отладить это, я играю.

@akutz: эти ребята приложили немало усилий для создания достойной многокорневой системы, они даже разместили видео о своих сессиях дизайна (это было в последних примечаниях к выпуску). Он идет, но они стараются сделать все правильно :-) (https://code.visualstudio.com/updates/v1_13)

Привет @cliffrowley!

Рад слышать. Я только недавно еще раз взглянул на VSCode, так как я всегда использовал Atom (и Sublime до этого). Недавно с Atom возникли проблемы, и в ветке Reddit я увидел, что VSCode был действительно отличным вариантом в наши дни. Поэтому я был удивлен, что он не поддерживает базовую функцию.

Просто накапливаю здесь - это действительно единственная функция, которая удерживает меня от рассмотрения перехода с IntelliJ / WebStorm на VSCode fulltime ... в основном потому, что, как упоминалось в предыдущем плакате, я работаю с распределенными архитектурами весь день и нуждаюсь в интегрированном управлении несколькими Git моему редактору (потому что я слишком ленив 😆)

Мне нравится, что вы все работаете над этим, и мне не терпится увидеть это в действии.

Мне нравится vscode, но эта "отсутствующая функция" мешает мне полностью переключиться с атома на vscode

Ранняя версия уже находится в сборке Insiders. Иди возьми это :)

+1 Нужна эта функция

Первая превью-версия - очень хорошие ребята!
Но есть небольшая проблема еще до того, как я начну как следует тестировать ...
Когда я добавляю две «корневые» папки с одинаковыми именами из двух отдельных проектов, эти папки ничем не отличаются.

например, я добавляю /dev/www/myproject/src а затем добавляю /dev/libraries/mycomponent/src
Все, что я вижу, это две корневые папки с именем src .

> src
> src

Я считаю, что нам нужен способ изменить отображаемое имя корневых папок.
Что затем отобразит:

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

Мысли?

VSCode показывает часть имени папки, когда вы открываете два файла с одинаковым именем, которые тоже могут работать с папками?

@doublehelix мы обсуждали это недавно, но нигде не отслеживали проблему. Я создал https://github.com/Microsoft/vscode/issues/29871 , спасибо 😄

@Tyriar Я действительно нахожу функциональность поиска запутанной, Explorer как я уже говорил .

Я не знаю, смотрели ли вы, ребята, на то, что я и некоторые люди сказали выше, или есть ли другие изменения, но лично мне не нравится, как вы каждый раз добавляете имя корня, в отличие от сортировки вещей в дереве -как вид, когда это возможно.

@eyalsk Работа продолжается, в июле я еще посмотрю на результаты поиска: # 29977

Проект vscode основан на папке.
Таким образом, вы можете настроить конфигурацию каждого проекта отдельно, и вы можете использовать интегрированный Git напрямую, или нет.

PyCharm: сердце:: сердце:: сердце:

+1

Я должен поблагодарить вас, уважаемая команда VSCode.
Наконец-то я могу отказаться от Atom, так как мульти-корневые рабочие области попали в сборки для инсайдеров!
Поскольку два года .gitignore и т. Д. Не соблюдаются в Atom при поиске в многокорневых рабочих областях, и вы поняли это с самого начала!

Отслеживается ли сохранение рабочих пространств в другой проблеме?

Вчера команда VS Code выпустила новую версию VS Code с функцией Multi Root Workspaces 🎉.

Результатом этой работы является то, что мы называем «минимально жизнеспособным продуктом» (MVP), позволяющим проводить тестирование в рабочих областях с несколькими корневыми папками.

На самом деле, доступен только в сборке Insiders, так что вы можете скачать ее здесь Скачать VS Code Insiders

Проводник

Поиск

Предположим, что каждая добавленная папка в рабочую область представляет собой отдельный репозиторий git - обрабатывает ли текущая версия Multi Root Workspaces дифференциацию управления исходным кодом этих репозиториев?

@Weyzu, мы работаем над внедрением SCM для мультикорневых сценариев на этом этапе. Изначально мы думали, что представление SCM должно быть осведомлено о нескольких репозиториях, что не обязательно совпадает с пониманием нескольких папок, как в проводнике и поиске: уже когда вы открываете одну папку в VS Code, у вас может быть несколько репозиториев внутри . Мы думаем, что представление SCM должно хорошо отображать эти репозитории, чтобы вы могли видеть исходящие / входящие изменения для каждого репозитория, а также иметь возможность фиксировать файлы из каждого репозитория.

Результат должен обеспечить лучший опыт как для сценариев с несколькими корнями, так и для сценариев с одним корнем, когда несколько репозиториев содержатся в одном корне.

Результат должен обеспечить лучший опыт как для сценариев с несколькими корнями, так и для сценариев с одним корнем, когда несколько репозиториев содержатся в одном корне.

Отличный подход, ребята молодцы!

@bpasero круто ! Мне определенно было бы интересно увидеть, как твои ребята взяли это на себя. В IntelliJ / WebStorm есть нечто подобное, где он автоматически определяет корни Git и выстраивает их для вас соответствующим образом в правом нижнем углу, и мне лично понравилось его использовать.

image

Вы, ребята, думали что-то в этом роде или что-то более сложное?

Мы все еще работаем над UX для этого и будем держать вас в курсе результатов.

Не мог ли здесь работать корень виртуальной файловой системы? Он будет действовать так, как если бы корень VFS был родительским каталогом для нескольких несопоставимых путей.

Я хотел дать обновленную информацию о нашей работе с множеством корней, потому что сегодня первый день, когда наш обновленный мультикорневой интерфейс UX попал в инсайдерскую версию, и многие из вас, которые привыкли к «старому» поведению, могут быть сбиты с толку тем, что происходит.

Недостатки старого решения
Старое решение для множественного корня вводит новый параметр workspace (в глобальный settings.json ), который позволяет добавлять дополнительные папки в одну корневую папку. Настройка выглядела так, если вы не заметили:

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

Мы называем это решение «главной» папкой с дополнительными папками («деталь»).

Это было наиболее простое решение без введения большого количества новых концепций, но оно также имеет недостатки:

  • вы никогда не сможете снова открыть основную папку как отдельную папку, потому что настройка сохраняется
  • вы не могли удалить основную папку из проводника
  • некоторые настройки из основной папки применяются ко всем остальным папкам
  • ваши настройки загрязняются многовариантной конфигурацией
  • трудно разрешить открывать несколько папок одновременно (например, когда вы открываете 3, какую основную папку мы должны взять?)

Наше решение
Мы считаем, что для сценариев с несколькими корнями требуется более четкая концепция рабочего пространства, и поэтому в сегодняшних инсайдерах вы увидите всплывающий новый интерфейс:

image

Идея состоит в том, что для многокорневых рабочих пространств требуется создание явного действия. Точно так же, как вы можете находиться в пустой рабочей области (папка не открыта, фиолетовая строка состояния) или в рабочей области с одной папкой (голубая строка состояния), вы также можете находиться в многокорневой рабочей области (темно-синий статус бар). Этот третий способ открытия рабочего пространства в VS Code позволяет иметь сколько угодно папок. Эти рабочие области могут быть сохранены в файл (например, myWorkspace.code ), а также включать настройки рабочего пространства. Вы не обязаны сохранять их, если вы не хотите их сохранять, они будут отображаться как «Рабочие области без названия».

Чтобы открыть рабочую область, вы можете либо открыть сохраненный файл рабочей области, либо выбрать из недавно открытого списка:

image

Это все очень молодой код и очень молодой UX, поэтому ожидайте некоторых изменений в ближайшие недели. Мы знаем, что есть еще кое-что, над чем нужно разобраться (например, как сделать переход от одной папки к нескольким папкам более плавным).

Несколько изменений, которые уже были внесены сегодня, будут добавлены в завтрашний инсайдерский релиз на основе отзывов:

  • переименуйте .code в .code-workspace как расширение для рабочих пространств
  • иметь единый список папок и рабочих пространств (например, в File> Open Recent) вместо разделения папок и рабочих пространств

Следите за новостями

Вдобавок ко всему, теперь у нас есть одна папка .vscode папку проекта, содержащую файл settings.json . Этот файл может содержать следующее:

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

Проблема здесь в том, что когда мы хотим работать с несколькими пользователями (разные сеансы RDP) на сервере в одних и тех же папках проекта, мы используем одни и те же настройки. Возможно, это не предполагаемое поведение. Мне бы хотелось, чтобы размер моего шрифта был больше, чем у моего коллеги.

Поэтому, на мой взгляд, вы также должны учитывать, что разные пользователи могут работать с одними и теми же папками, но с разными настройками в settings.json .

@ DarkLite1 вы подняли хороший вопрос. В нашем дизайне настроек для мульти-root мы пытаемся определить настройки, которые мы можем поддерживать для каждой папки, и настройки, которые мы не можем поддерживать. Обычно мы говорим, что настройки, нацеленные на редактор или конкретный ресурс, могут поддерживаться для каждой папки, потому что ясно, из какой папки был открыт редактор. Другие параметры, которые не будут поддерживаться, больше связаны с настройкой рабочего места (например, отображение строки состояния или нет).

Ваш пример касается параметра editor.fontSize который мы фактически поддерживаем для каждой папки даже в многокорневой рабочей области. Я думаю, что это может быть допустимый сценарий, когда пользователь хочет иметь больший размер шрифта для папки, которая содержит много документации по уценке (может быть, даже другой шрифт?). Поэтому я думаю, что мы не должны препятствовать соблюдению этого параметра для каждой папки также в среде с несколькими корнями.

Если вы хотите сохранить editor.fontSize в качестве настройки личного рабочего пространства, я думаю, что его не следует проверять в репозитории.

С новой концепцией рабочих пространств вы можете делать следующее:

  • Файл> Рабочие области> Новая рабочая область
  • Выберите свою папку
  • Открыть настройки рабочего пространства
  • Изменить editor.fontSize: 15

С этого момента ваше рабочее пространство будет нести эту настройку, но вы никому не навязываете ее.

С точки зрения UX было бы удобно, если бы я мог перетаскивать папки в окно VS Code без явного предварительного создания рабочего пространства (это то, что я постоянно делаю в Sublime). Я неизменно работаю над несколькими проектами одновременно, и в зависимости от того, над чем я работаю, каждый день будет новый (перекрывающийся) набор проектов.

Рабочие области представят концепцию, которая не присуща моему стилю работы, и мне придется отслеживать различные конфигурации рабочей области (как я понимаю), что звучит так, как будто это создаст некоторый беспорядок конфигурации в моих папках проекта.

Кроме того, я думаю, что говорю от имени многих пользователей, если бы я утверждал, что такие вещи, как поиск и конфигурация, по умолчанию являются глобальными (применимы ко всем открытым папкам) - хотя было бы неплохо, если бы у меня была возможность искать локально в папке ( Я всегда считал это сложным в Sublime).

@SanderMertens Вы могли пропустить это, но @bpasero написал;

Эти рабочие пространства можно сохранить в файл (например, myWorkspace.code), а также включить в них настройки рабочего пространства. Вы не обязаны сохранять их, если вы не хотите их сохранять, они будут отображаться как «Рабочие области без названия».

Я не уверен, что у вас будет возможность перетаскивать папки, но из того, что я получаю, люди будут иметь возможность открывать произвольные папки без создания рабочего пространства.

Не могу дождаться, когда эта функция будет включена в стабильную сборку.

Ура! 😄

В настоящее время вы не можете перетащить папку в проводник, чтобы добавить ее, но это у нас в журнале. Сложность этого взаимодействия заключается в том, что мы не знаем намерения пользователя: открыть папку в окне или добавить ее в рабочую область?

Переход от одной папки ко многим папкам в настоящее время является более явным шагом по сравнению с тем, что делают другие редакторы (вам нужно перейти через Файл> Рабочие области> Сохранить рабочую область и выбрать нужные папки). Есть несколько причин, по которым мы хотим придерживаться текущего поведения, пока мультикорневой не стабилизируется. Основная причина в том, что мульти-root - это серьезное изменение для всех наших расширений. Хотя проводник работает и вы можете выполнять поиск во всех папках, большинство расширений не будут работать правильно, пока не будет принят новый многокорневой API. Таким образом, мы не хотим, чтобы вначале было слишком легко ввести несколько root случайно. Это явный пользовательский жест для входа в мультикорневые рабочие области, и в этом режиме мы могли бы обратить внимание на тот факт, что некоторые расширения еще не работают.

Другая причина - настройки рабочего пространства: представьте себе этот поток:

  • вы начинаете с 1 папки, в которой есть настройки рабочего пространства
  • вы добавляете вторую папку (предположим, что это работает без переключения контекста и перезагрузки окна)
  • вы открываете настройки рабочего пространства
    => Настройки рабочего пространства в мульти-корне теперь хранятся в каком-то месте за пределами папок, потому что у вас может быть несколько
    => нам, вероятно, нужно спросить пользователя, хочет ли пользователь перенести настройки рабочего пространства в это новое место

Так что, несмотря ни на что, в настоящее время ввод мульти-root не является легкой операцией. Мы могли бы вернуться к этому, когда уляжется пыль и многокорневое распространение получит широкое распространение, но пока мы думаем, что эта модель лучше и позволяет избежать разочарований.

@bpasero Я думаю, что по умолчанию, когда вы перетаскиваете папку в проводник, она не должна автоматически сохранять ее в рабочей области, даже если она может существовать, и это должно быть явное действие, когда пользователь нажимает на папку (а), которую он / она перетащите, а затем явно добавьте его в рабочую область, и если у вас есть несколько несвязанных папок, может быть целесообразно предоставить еще одно действие для сохранения всех их сразу.

Все зависит от вариантов использования, которые вы хотите охватить. По опыту я убедился, что KISS - всегда лучший подход. Представление Workspaces звучит отлично как feature но каковы реальные преимущества и недостатки?

Один недостаток, который приходит на ум при введении и использовании Workspaces заключается в том, что он должен где-то хранить свои данные (настройки), и это требует обслуживания / осведомленности пользователя.

Предположим, единственная цель - дать пользователям возможность работать с несколькими папками в одном сеансе VS Code. Ни меньше, ни больше.

Наиболее распространенный вариант использования:
Нет концепции Workspaces . Пользователь просто открывает дополнительную папку или столько, сколько хочет, и они открываются в представлении слева, как и отдельная папка. Он ожидает, что его настройки везде будут одинаковыми. независимо от того, где находятся его файлы. И он не хочет лишнего беспорядка конфигурационных файлов VS Code между его файлами проекта, как заявил @SanderMertens , я и, возможно, другие тоже.

Вызовы / проблемы / вопросы:

  • Почему так могут быть разные файлы настроек? Пользовательские настройки, настройки рабочего пространства? ИМХО все должно храниться в одном месте. По выбору пользователя его личная папка / профиль, поэтому каждый пользователь в системе может иметь свои собственные настройки. Дополнительный бонус. они не загромождают файлы проекта, и несколько пользователей могут заниматься своими делами. Очистить профиль? Большой! Чистый лист и для VS Code.

Я думаю, что Workspaces - это немного чрезмерно инженерные вещи, если вы хотите:
Скорость, простота и просто работающий редактор, без чрезмерного усложнения или понимания лишних концепций. Если пользователи из Sublime или других редакторов не используют эту концепцию в своем рабочем процессе, это должно быть признаком чрезмерного обдумывания вещей. Или это может означать, что было изобретено что-то действительно потрясающее, что и другие редакторы будут реализовывать, но у меня есть сомнения.

Извините, если это звучит как напыщенная речь, это абсолютно не мое намерение. Но я считаю, что мы можем добиться большего успеха в отношении доступа к нескольким корням / папкам.

@ DarkLite1 благодарит за то, что

Я согласен со всеми вашими пунктами и хочу найти простое решение. Концепция рабочих пространств - это наш первый шаг к решению с несколькими корнями, которое работает с нашими существующими шаблонами (настройки рабочего пространства, расширения и т. Д.). Поскольку это первый шаг, ожидайте более грубых краев (например, переход от 1 к N папок не так легок, как мог бы быть). Наша цель - сделать этот переход плавным и не сделать его более сложным, чем он должен быть в будущем. И мы также не хотим заставлять пользователя управлять этими рабочими пространствами (вот почему у нас есть «Рабочие пространства без названия», которые существуют, пока окно открыто, и исчезнут, как только вы закроете это окно).

Следует помнить о нескольких вещах, связанных с рабочими областями с несколькими корнями, которые, возможно, не так очевидны. Я надеюсь, что следующее подробное объяснение поможет понять наш процесс проектирования:

Настройки рабочего пространства
Мы поддерживаем настройку внутри папки рабочего пространства (папка .vscode ). Хотя некоторым пользователям могут не нравиться такие настройки, которые попадают в файлы .gitignore или в репозиторий, многие полагаются на эту функциональность. Мы не можем просто перестать поддерживать настройки, которые хранятся в папках, потому что пользователи полагаются на них. Теперь, для сценариев с несколькими корнями, ясно, что нам нужно найти новое место для настроек рабочего пространства. Мы придумали концепцию файла рабочей области, который содержит эти настройки. Пока рабочая область нигде не сохраняется, она находится в папке, содержащей другие данные, специфичные для VS Code, и когда вы сохраняете файл, настройки будут внутри этого файла.

Теперь представьте, что вы начинаете с 1 папки в VS Code, в которой определены параметры рабочего пространства, и вы хотите добавить вторую папку. Что нам теперь делать? Игнорировать настройки рабочего пространства первой папки? Попросить пользователя перенести настройки? Мы решили сделать это явным переключением контекста, чтобы прояснить, что открытие рабочего пространства имеет собственные настройки рабочего пространства в другом месте.

А теперь представьте, что вы перешли из одной папки в две, а мы переместили настройки рабочего пространства в другое место. Представьте, что вы вносите изменения в эти настройки рабочего пространства. Теперь вы хотите вернуться из 2 папок в 1, ожидаете ли вы перенести настройки рабочего пространства обратно в папку?

Другой пример: вы переходите от 1 к 2 папкам и настраиваете параметры рабочего пространства. Теперь вы закрываете окно. Я думаю, вы бы рассердились на нас, если бы не смогли каким-либо образом вернуться в это рабочее пространство, потому что вы тщательно настроили параметры для этого рабочего пространства. Итак, даже если вам не нравится концепция рабочего пространства, после того, как вы настроите для него параметры, я думаю, вы захотите, чтобы это рабочее пространство продолжало жить.

Я надеюсь, что эти примеры немного помогут понять, почему KISS не так прост для нас, как можно было бы подумать.

Расширения
Все наши расширения всегда работали против API, который предоставляет единый путь к рабочему пространству, потому что до сих пор мы не поддерживали многокорневые рабочие пространства. Как пользователь, вы можете подумать, что переключение с 1 папки на 2 папки - это очень простая и легкая операция, но для расширений это может означать многое: языковые расширения, которые до сих пор предполагали, что существует только одна папка, внезапно должны знать о нескольких папки. Вдобавок ко всему, эти папки могут появляться и исчезать очень динамично в любое время.

Представление концепции реального рабочего пространства дает нам больше места и времени для расширения и помогает расширениям принять эту концепцию. Мы могли бы, например, отключить расширения, которые еще не приняли многокорневые рабочие пространства, чтобы предотвратить странные вещи (например, языковое расширение работает только в одной папке и сообщает о неправильных ошибках в другой).

Давайте сначала попробуем стабилизировать поддержку нескольких root с помощью этих новых рабочих пространств, а затем вернемся к тому, насколько легкими мы можем сделать переходы. Я думаю, что после того, как мы включим расширения и разобрались с нашей историей настроек, мы сможем сделать переход на более легкий интерфейс.

PS: поскольку вы ссылаетесь на других редакторов в отношении их поддержки множественного доступа, я просто хотел указать, что эти редакторы также имеют концепцию рабочего пространства или проекта, которые вы можете сохранить в файл и поделиться с другими. Обычно вы не видите этих концепций, потому что переход от 1 к N папок - очень легкая операция. Я бы сказал, что люди, которые полагаются на эту функцию, начинают переходить к сохраненным рабочим пространствам / проектам как способ управления работой. Например, если вы не сохраните рабочую область / проект и не закроете окно, вся эта информация будет потеряна.

@bpasero, спасибо, что

Поскольку я не полностью знаком с Sublime, я взял на себя смелость проверить, как они с этим справляются. И вы правы, они тоже используют Workspaces и даже файлы Project . Единственное, что меня немного беспокоит, это то, что он помещает файлы VS Code между моим проектом. Но, как вы упомянули, если другие полагаются на это, следует учитывать, что это может быть лучшим вариантом. Мне только интересно, почему эти файлы настроек не зависят от пользователя? Я могу представить себе коллегу, открывающего VS Code в той же структуре папок, но желающего иметь свои собственные настройки.

Если Workspaces - это путь вперед, а кажется, что они есть, было бы логично при открытии приложения перезагрузить последние использованные настройки. Даже если это несохраненный Workspace . Думаю, это делает жизнь немного проще.

Почему я выбрал VS Code? Поскольку это кроссплатформенный, я использую Linux дома и Windows на работе, поэтому он действительно может стать моим редактором по умолчанию! В качестве дополнительного бонуса я разработчик PowerShell, и для него тоже есть расширение. Итак, две большие победы! Вдобавок ко всему, для курса Java, которому я следую, Red Hat делает расширение также для VS Code. Итак, как только вы лучше познакомитесь с VS Code, с его ярлыками и всем остальным, вы получите выгоду во всех отношениях.

Приложение и его расширения все еще находятся в стадии бета-тестирования или даже альфа-тестирования, но все же, ребята, отличная работа! Действительно цените усилия и каждый день наблюдайте за прогрессом в сборках Insider. Продолжайте в том же духе и желаю вам хороших выходных.

Спасибо за это объяснение @bpasero , думаю, теперь я лучше понимаю, в чем сложность.

Один из подходов может заключаться в концептуальном рассмотрении любого набора проектов с той же конфигурацией, что и рабочее пространство. В дополнение к этому вы можете воздержаться от добавления папки .vscode пока проект не отличается от конфигурации по умолчанию. Это должно:
1) Избавьтесь от беспорядка в проектах
2) предотвратить большинство конфликтов конфигурации при добавлении проектов (в простом случае конфигурации не будет)

Я думаю, что явная концепция рабочего пространства, о которой говорилось выше, является хорошим решением упомянутой проблемы. С помощью этих двух простых правил я минимизирую варианты использования, в которых люди сталкиваются с этой проблемой.

Для меня, глядя на комментарии в потоке и мои варианты использования, я вижу _Multi-folder_ и _Workspaces_ как две разные концепции, и, возможно, их также следует рассматривать отдельно.

Это не должно заставлять _создавать рабочее пространство_ только для того, чтобы добавить другую папку в текущее окно. Он должен просто добавить новую папку в дерево и оставить только что созданное рабочее пространство как _внутреннюю информацию_. Если пользователь решает сохранить рабочее пространство, то оно действительно создается. И даже если я не сохраню рабочую область при повторном открытии верхней папки, она _ запомнит_ мою временную рабочую область_ и также откроет другие папки, точно так же, как она запоминает открытые файлы, когда вы открываете папку сегодня. Кстати, мне интересно, как я могу открыть несколько папок в командной строке.

Для моих случаев использования несколько папок - это всего лишь способ увидеть более одной папки в одном окне, а не подход _Project Group / Solution_. Итак, подойдет более простое решение. Но я понимаю, как другим нужна _Workspace_, со своими настройками и так: thumbsup :.

Больше всего меня беспокоит в этой новой концепции Workspaces (по сравнению с первой итерацией с использованием User Settings ) то же самое, что беспокоило меня, когда я использовал Sublime Text. Тот факт, что вы _ можете_ сохранять файлы .code-workspace _anywhere_, и теперь мне нужно найти общее место для их хранения. Было бы намного проще, ИМХО, чтобы он автоматически поместился в одном из этих двух мест:

  • внутри user-data-dir папки, например User Settings и Keybindings
  • внутри _Top Folder_

Чтобы быть ясным, я понимаю более сложную концепцию рабочего пространства, которая нужна другим пользователям. Мне просто нужен был более простой подход к более простой концепции нескольких папок.

Мне нравится этот вариант, добавьте этот вариант.
dddsa
Потому что папка внутри не очень впечатляет.
default
или добавьте возможность изменить эту опцию.

Мне нравится идея рабочего места! Есть идеи, когда это будет готово?

Ожидается ли на этом этапе, что информация git в нижнем левом углу не будет точно отражать ветку git любого репо, в котором находится текущий сфокусированный файл? Я ничего не видел о "множественных корнях git" в примечаниях к выпуску v1_15.

Я уже несколько дней использую эту функцию в сборке Insider и должен сказать, что это все, что я хотел. Очень чистый пользовательский интерфейс, и я не могу дождаться, пока он появится в основной сборке, чтобы я мог преобразовать всю свою команду в это.

При работе с NodeJS и одновременном открытии нескольких модулей NPM способ объединения всего в одно окно позволяет значительно сэкономить время.

Огромный реквизит команде!

Почему эта функция отображается в моих примечаниях к выпуску с гифкой и объяснением, но недоступна в реальном редакторе ?!

@ShashankaNataraj ,

Наша дорожная карта для текущей работы с несколькими корневыми каталогами отражена в https://github.com/Microsoft/vscode/issues/28344 и будет продолжаться до августа, сентября и, возможно, также октября.

Мы сохраним эту функцию доступной только для инсайдеров до:

  • мы можем предоставить надлежащую поддержку SCM с несколькими корнями, отладку и выполнение задач
  • мы внедрили многокорневые API и функции для расширений, с которыми мы поставляем и которые мы активно вносим (например, Go)
  • у авторов расширений было достаточно времени (например, 1 этап), чтобы принять новые многокорневые API

Пожалуйста, поймите, что мы не хотим выпускать эту функцию в стабильную версию и не иметь проблемных расширений, потому что мы слишком быстро ввели эту функцию.

Спасибо, что были профессиональными ребятами, отличная работа!

@bpasero Меня немного беспокоит то, что авторы расширений будут время от времени обновлять плагины. Получают ли они специальные электронные письма о предстоящих изменениях?

благодаря

@FelikZ, пожалуйста, ознакомьтесь с нашей дорожной картой (https://github.com/Microsoft/vscode/issues/28344). В сентябрьском выпуске мы планируем принять расширения, которые мы поставляем в VS Code, и пока мы работаем над этим, мы добавляем необходимые API и утилиты, необходимые для этого.

В течение сентября это план:

image

Сегодняшнее инсайдерское обновление содержит некоторые изменения в файле .code-workspace которые я хотел здесь обобщить. Существующие рабочие области с предыдущим форматом будут автоматически перенесены в новый формат.

Старый формат выглядел так:

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

И новый формат:

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

ID рабочей области
Идентификатор рабочей области используется для связывания нескольких вещей с рабочей областью:

  • все состояние пользовательского интерфейса (например, открытые файлы)
  • все грязное состояние файла (также известный как горячий выход)
  • состояние расширений (если есть)

Мы решили удалить свойство id из файла рабочей области и вместо этого вычислить id автоматически на основе абсолютного пути к файлу рабочей области на диске. У этого есть несколько преимуществ и недостатков, но, в конце концов, мы думаем, что преимущества делают это решение лучшим:

  • было странно, что вы могли редактировать id в файле, просто набрав другое значение
  • было не очень понятно, как обрабатывать id при совместном использовании файла рабочей области с другими (следует ли изменить id ? должен ли id быть uuid?)
  • невозможно было скопировать файл рабочей области и открыть его в отдельном окне, нужно было сначала изменить id в скопированном файле
  • как следствие, действие «Сохранить рабочую область как» должно было бы спросить пользователя, должна ли копия иметь другой id или нет

Одним из недостатков этого подхода является то, что при перемещении или переименовании файла рабочей области связанное состояние будет потеряно. Грязные файлы («горячий выход») все равно будут открываться после перезапуска, но они откроются в пустом окне и больше не будут связаны с окном рабочей области. Мы все еще думаем, что можем улучшить это поведение, хотя оно ведет себя в соответствии с тем, что происходит сегодня, когда вы переименовываете папку со связанным состоянием пользовательского интерфейса и грязными файлами.

Папки
Мы решили пересмотреть формат свойства folders .

  • мы больше не требуем от вас использовать URI ресурсов, а только пути к файлам, чтобы упростить редактирование
  • мы изменили записи свойства folders на объекты, чтобы мы могли связывать метаданные с записями по мере необходимости (например, каждая папка может иметь дополнительное свойство name )

Наконец, появилась поддержка относительных путей. Вы можете ввести относительный путь к файлу, и он будет сопоставлен с родительской папкой файла рабочей области. Обратите внимание, что из-за ошибки https://github.com/Microsoft/vscode/issues/33188 мы в настоящее время переписываем относительные пути на абсолютные при внесении изменений в файл рабочей области.

@bpasero, это name ? Сейчас у меня на рабочем месте две папки с одинаковым именем, и это ужасно.

@DaniloPolani см. Https://github.com/Microsoft/vscode/issues/29871

Обновление обработки относительных путей : начиная с сегодняшней инсайдерской сборки, мы будем записывать пути к файлу рабочей области как относительный путь, если расположение файла рабочей области является родительским для цели. Другими словами, пути теперь всегда будут относительными, если только нам не придется использовать нотацию « ../ » для выражения пути.

Поскольку безымянные рабочие области всегда находятся в каталоге данных VS Code, пути в них всегда будут абсолютными. Но как только вы сохраните безымянное рабочее пространство в каком-либо месте, мы по возможности перепишем пути.

Если вам интересно узнать об изменениях, произошедших в мультикорневых рабочих областях во время этого спринта, просмотрите обновленные примечания к выпуску .

+1

+1

@bpasero IMHO, способ обработки состояний пользовательского интерфейса (если он использует строку идентификатора в файле .code-workspace или вместо этого использует путь к файлу в качестве идентификатора) неадекватен.
Переименование файла .code-workspace или любой из его родительских папок, или его перемещение и потеря состояния пользовательского интерфейса, на мой взгляд, совершенно не интуитивно. Я думаю, что люди, не знающие, как это работает под капотом, не имеют абсолютно никакого представления о причине потери предыдущего состояния пользовательского интерфейса и о том, как его вернуть.
Это вообще не должно быть привязано к абсолютному пути к файлам в файловой системе!

Это относится и к тому, как состояние пользовательского интерфейса связано с путем к папке, которая в настоящее время находится в стабильной версии. Сначала я был очень смущен этим, пока не погуглил.

IMO В случае, если мы имеем дело только с одной папкой, состояние пользовательского интерфейса должно быть сохранено внутри папки .vscode . Если мы имеем дело с многокорневой рабочей областью, состояние пользовательского интерфейса должно быть сохранено как отдельный файл в той же папке, что и файл .code-workspace используя соответствующие соглашения об именах (или, возможно, внутри самого файла, хотя настройки и состояние может быть не очень хорошей идеей).

При правильной реализации это позволит пользователям иметь полный доступ к состояниям пользовательского интерфейса, присоединять новые состояния пользовательского интерфейса к заданной рабочей области (с несколькими корнями или без) и т. Д.
Я бы хотел иметь возможность синхронизировать состояние пользовательского интерфейса между разными компьютерами, скажем, работая в офисе, затем возвращаясь домой, беря ноутбук или что-то еще и продолжая именно там, где я остановился.
Было бы здорово иметь несколько состояний пользовательского интерфейса, прикрепленных к рабочему пространству, и легко переключаться между ними (меню / привязка клавиш / команда / и т.д.) при работе с различными функциями. Возможно, разные файлы .code-uistate внутри .vscode перечисляются автоматически, или многие файлы .code-uistate префиксом в соответствии с основным .code-workspace или перечисляются в массиве.

Я думаю об этом как о расширении того, как проекты и рабочие области работают с Sublime Text. Та же функциональность, другой дизайн. В этом случае рабочее пространство VS Code будет похоже на проект Sublime, а различные состояния пользовательского интерфейса VS Code будут аналогичны рабочим пространствам Sublime.

По этому поводу:

было странно, что вы могли редактировать идентификатор в файле, просто набрав другое значение

Да, конечно. Удаление оттуда идентификатора было правильным выбором.

было не очень ясно, как обращаться с идентификатором при совместном использовании файла рабочей области с другими (следует ли изменить идентификатор? должен ли идентификатор быть uuid?)

Что ж, если у нас есть myproject.code-workspace и myproject.code-uistate тогда пользователю решать, делиться своим состоянием пользовательского интерфейса или нет. Больше не нужно думать, что означает этот идентификатор, как он сгенерирован, должен ли он быть UUID, чтобы избежать конфликтов при совместном использовании и т. Д.
Хотите поделиться настройками и настройками папки? Отправьте myproject.code-workspace , не беспокойтесь.
Хотите поделиться всем? Отправьте оба файла.

невозможно было скопировать файл рабочей области и открыть его в отдельном окне, нужно было сначала изменить id в скопированном файле

Если вы хотите начать с нового состояния пользовательского интерфейса с той же настройкой папки и настройками, просто скопируйте файл .code-workspace .

как следствие, действие «Сохранить рабочую область как» должно было бы спросить пользователя, должна ли копия иметь другой идентификатор или нет.

Это было сложно, поскольку пользователь не знал, что это за идентификатор. Возможно, было бы проще иметь две опции «Клонировать рабочее пространство с текущим состоянием» и «Новое пустое рабочее пространство». Но это UX, и вам нужно будет провести анализ.

Согласны с Франком, сохраните все файлы конфигурации проекта в настройках
папку в проектах, взгляните на Eclipse IDE, у которой есть права
подход. Он имеет концепцию настройки проекта и рабочего пространства с
проект перезаписывает значения по умолчанию в рабочей области. Рабочая область - это просто папка с
папки, представляющие проекты. Так что имейте папку .vscode в рабочей области
папка, и каждый проект имеет свою собственную папку .vscode . И пожалуйста не
просто проголосуйте против этого за упоминание Eclipse IDE.

В пн, 18 сентября 2017 г., в 20:52, Franco Gallardo Grazio <
[email protected]> написал:

@bpasero https://github.com/bpasero IMHO, способ обработки состояний пользовательского интерфейса
(будет ли он использовать строку идентификатора в файле .code-workspace или использовать
вместо этого путь к файлу в качестве идентификатора) не подходит.
Переименование файла .code-workspace или любой из его родительских папок или перемещение
это вокруг, и потеря состояния пользовательского интерфейса, на мой взгляд, совершенно не интуитивно. я
думаю, что люди, не знающие, как это работает под капотом, абсолютно
понятия не имею, почему они потеряли свое предыдущее состояние пользовательского интерфейса и как получить
его обратно.
Это не должно быть привязано к абсолютному пути к файлам в файле.
система вообще!

Это относится к тому, как состояние пользовательского интерфейса связано с путем к папке, находящейся в данный момент в
стабильный выпуск. Сначала я был очень смущен, пока
погуглил.

IMO В случае, если мы имеем дело только с одной папкой, состояние пользовательского интерфейса должно быть сохранено
внутри папки .vscode. Если мы имеем дело с многокорневой рабочей областью,
Состояние пользовательского интерфейса следует сохранить в виде отдельного файла в той же папке, что и
.code-workspace файл с использованием соответствующих соглашений об именах (или, возможно,
внутри самого файла, хотя настройки и состояние микширования могут не быть
хорошая идея).

При правильной реализации это позволит пользователям иметь полный доступ
к состояниям пользовательского интерфейса, прикрепить новые состояния пользовательского интерфейса к заданной рабочей области (мульти-корневой или
нет) и т. д.
Я бы хотел иметь возможность синхронизировать состояние пользовательского интерфейса между разными компьютерами, например
работать в офисе, потом идти домой, хватать ноутбук или что-то еще и
продолжая именно там, где я остановился.
Имея несколько состояний пользовательского интерфейса, прикрепленных к рабочему пространству, и легко переключаться между
их (меню / привязка клавиш / команда / и т. д.) при работе с различными функциями
быть крутым. Возможно разные файлы .code-uistate внутри .vscode
перечисляются автоматически, или многие файлы .code-uistate с префиксом в соответствии с
основное рабочее пространство .code или перечисленные в массиве.

Я думаю об этом как о продолжении того, как проекты и рабочие пространства
работать над Sublime Text. Та же функциональность, другой дизайн. В этом случае
Рабочее пространство VS Code было бы похоже на проект Sublime, а разные
Состояния пользовательского интерфейса VS Code будут похожи на рабочие области Sublime.

По этому поводу:

было странно, что вы могли редактировать идентификатор в файле, просто набрав
другое значение

Да, конечно. Удаление оттуда идентификатора было правильным выбором.

было не очень понятно, как обращаться с id при совместном использовании файла рабочей области
с другими (следует ли изменить идентификатор? должен ли идентификатор быть uuid?)

Хорошо, если у нас есть myproject.code-workspace и myproject.code-uistate
тогда пользователь сам решает, делиться своим состоянием пользовательского интерфейса или нет.
Больше не нужно думать, что означает этот идентификатор, как он генерируется, нужно ли это
UUID, чтобы избежать конфликтов при совместном использовании и т. д.
Хотите поделиться настройками и настройками папки? Отправьте myproject.code-workspace,
не о чем беспокоиться.
Хотите поделиться всем? Отправьте оба файла.

не было возможности скопировать файл рабочего пространства и открыть его в отдельном
окно, вам нужно было сначала изменить идентификатор в скопированном файле

Если вы хотите начать со свежего состояния пользовательского интерфейса с той же настройкой папки и
настройки просто дублируют ваш файл .code-workspace.

как следствие, действие «Сохранить рабочее пространство как» должно запрашивать
пользователь, если у копии должен быть другой идентификатор или нет

Это было сложно, поскольку пользователь не знал, что это за идентификатор. Возможно, это было бы
проще иметь два варианта «Клонировать рабочее пространство с текущим
Состояние »и« Новое пустое рабочее пространство ». Но это UX, и вам придется
анализ об этом.

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-330396242 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAQsBQ5rdj3VGoNwy77jfSQ7V_tqWFOfks5sjxBYgaJpZM4Gm3nX
.

-
Даниэль Соколовски
Технический архитектор

Stantive Technologies Group Inc.
Телефон: +1 (613) 634-7410
http://www.stantive.com

Уведомление о конфиденциальности:
Передаваемая информация предназначена только для физического или юридического лица.
который адресован и может содержать конфиденциальные и / или привилегированные
материал. Любое повторное распространение обзора или другое использование или
предпринимать какие-либо действия на основании этой информации лицами или
лица, кроме предполагаемого получателя, запрещены. Если вы получили
это по ошибке, пожалуйста, немедленно свяжитесь с отправителем, отправив электронное письмо.
передачи, а затем немедленно удалить эту передачу, включая все
вложения без копирования, распространения или разглашения.

@danielsokolowski Я понимаю идею проекта, перезаписывающего рабочую область для настроек. В vscode у вас есть общие настройки, пользовательские настройки (вместо общих) и настройки рабочего пространства (вместо пользовательских или общих). У каждого проекта уже есть возможность иметь свою папку .vscode (в ней живут настройки рабочего пространства). Вы предлагаете дополнительную папку, в которую будут вкладываться проекты только для обмена информацией о настройках? Это похоже на файл / папку « решения » в терминах Visual Studio.

@fgallardograzio Перемешивание конфигурации проекта с настройками в том же файле приведет к принудительному связыванию. Материал пользовательского интерфейса звучит намного лучше как еще одна особенность, отдельная от этой проблемы. Теперь, когда сборка Insiders имеет красивую компоновку дополнительных корней в файле, возможно, расширение сможет заполнить пробел для части пользовательского интерфейса. Спасибо. Добрый день.

@Yemi , да, поэтому Elcipse позволяет мне открывать разные рабочие пространства,
просто папки, содержащие различные подпапки для представления проектов. я
лично использую две рабочие области: одну для разработки Eclipse IDE, а другую - для
все мои рабочие проекты. Главный вывод: настройки просто
удобочитаемые файлы, хранящиеся в соответствующих папках настроек - http://wiki.eclipse.org/IRC_FAQ#Where_are_Eclipse_preferences_stored.3F -
для меня это очень логично.

Комментарий / совет, который стоит упомянуть для любой IDE в ситуациях, когда у вас
автономные проекты, скажите workspace/your-awesome-library которые вы хотите
включить как часть другого проекта, скажем
workspace/my-wiget/libraries/your-awesome-library можно использовать перекрестки
или жесткое связывание в зависимости от ОС - я считаю это чище, чем подрепозиторы git / hg
концепции.

Во вторник, 19 сентября 2017 г., в 10:33, Йеми Беду @ P&R [email protected]
написал:

@danielsokolowski https://github.com/danielsokolowski Я понимаю
понятие проекта, перезаписывающего рабочую область для настроек. В vscode вы
иметь общие настройки, пользовательские настройки (вместо общих) и рабочее пространство
настройки (поверх записи пользовательских или общих). У каждого проекта уже есть
возможность иметь свою папку .vscode (в ней живут настройки рабочего пространства).
Вы предлагаете дополнительную папку, в которую будут вкладываться проекты только для
поделиться информацией о настройках? Это похоже на « решение »
файл / папка в терминах Visual Studio.

@fgallardograzio https://github.com/fgallardograzio Создание проекта
конфигурация, смешанная с настройками в том же файле, заставит
связь. Материал пользовательского интерфейса звучит намного лучше, поскольку это еще одна функция, отдельная от
этот билет выпуска. Теперь, когда сборка Insiders имеет красивую схему
дополнительные корни в файле, возможно расширение может заполнить пробел для пользовательского интерфейса
часть. Спасибо. Добрый день.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-330558669 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAQsBajECULDuQiqUZj6SRdfwJG-Bcw0ks5sj9CfgaJpZM4Gm3nX
.

-
Даниэль Соколовски
Технический архитектор

Stantive Technologies Group Inc.
Телефон: +1 (613) 634-7410
http://www.stantive.com

Уведомление о конфиденциальности:
Передаваемая информация предназначена только для физического или юридического лица.
который адресован и может содержать конфиденциальные и / или привилегированные
материал. Любое повторное распространение обзора или другое использование или
предпринимать какие-либо действия на основании этой информации лицами или
лица, кроме предполагаемого получателя, запрещены. Если вы получили
это по ошибке, пожалуйста, немедленно свяжитесь с отправителем, отправив электронное письмо.
передачи, а затем немедленно удалить эту передачу, включая все
вложения без копирования, распространения или разглашения.

Эта функция еще не добавлена?

Для меня это очень важно. Я работаю над проектом, который состоит из двух отдельных репозиториев: веб-интерфейса и api. Было бы хорошо, если бы я мог открыть обе эти папки в одном «проекте».

Конечно, я мог бы решить эту проблему, клонировав 2 репозитория в одну папку и открыв эту папку, но это работает не для всех случаев. Особенно, если у вас есть несколько проектов, которые зависят от одного репозитория (т.е. используют один и тот же API).

Эта функция также будет полезна тем, кто использует код в качестве документации.

@JamesTheHacker какое-то время использует инсайдеров vscode, которые поддерживают несколько проектов одновременно. И вы можете предлагать функции в зависимости от того, что вы чувствуете с инсайдерской версией, чтобы сделать ее лучше

Когда он будет выпущен, версия VSCode, вероятно, должна повыситься до 2.0. Просто говорю :)

Быстрый вопрос об этой функции:

Эта функция поддерживает добавление нескольких папок с репозиториями в существующую рабочую область. Будет ли он также поддерживать конфигурацию моно-репо, при которой я хочу открыть несколько проектов в монорепо, но поскольку они находятся в одном репо, у них нет собственного репозитория git. Таким образом, с точки зрения проекта у них нет папки .git - они есть в одной из папок-предков.

Вы можете спросить, почему бы не открыть папку монорепозитория как одну большую папку и просто поработать в ней? Есть два ответа:

  1. (менее интересно для меня) в монорепо слишком много проектов, и меня интересуют только некоторые из них.
  2. Многие плагины предполагают, что проект содержит только один ... проект. Например, всего один пакет npm. Поэтому они ищут вещи в _root_ проекта. Примеры: плагин npm для VSCode, плагин mocha для vscode и множество функций в самом VSCode - например, я не могу указать путь в launch.json , относящийся к текущий файл, то есть «папка node_modules, которая является ближайшим предком текущего файла».

После этого контекстного объяснения мой вопрос прост - будет ли эта функция поддерживать проекты, у которых папка .git является предком своего корня? Если так, то можно было бы использовать эту функцию в монорепо.

@borekb Ага. Я не знаю, как люди в Microsoft управляют своими версиями, но я думаю, что это достаточно масштабная функция для крупного

После этого контекстного объяснения мой вопрос прост - будет ли эта функция поддерживать проекты, папка .git которых является предком их корня? Если так, то можно было бы использовать эту функцию в монорепо.

Это уже поддерживается довольно давно, если вы просто откроете подпапку репозитория git.

+1

Sublime и Atom должны это сделать. Нет лучшей причины. Это НОВЫЙ MS, сделайте это, ребята, я полностью верю в вас. :)

Здравствуйте,
@inestyne , пожалуйста, прочтите предыдущие сообщения, например, от @Jeyanthinath, вы уже знаете об использовании инсайдеров VSCode для оценки этой функции. Есть даже дорожная карта для проверки. Поэтому, пожалуйста, используйте продукт и оставьте отзыв, прежде чем он будет переведен на стабильную версию, чтобы мы все получили лучший продукт. Спасибо. Добрый день.

Просто прочтите ветку и используйте Insiders OMG. Я отпишусь ... вы, тролли, которые не читают, невозможны. Спасибо @ pr-yemibedu

Чувствительный

Поскольку этот поток длится 2 года, и эта функция, похоже, сейчас находится в сборке инсайдеров, есть ли способ пометить эту цепочку, чтобы это было более очевидно, чем чтение всей цепочки сверху?

Одна вещь, которой не хватает, - это возможность открыть новое окно с новым рабочим пространством из интерфейса командной строки.

@jearle Новое окно / рабочее пространство должно быть создано, как и раньше, с помощью code-insiders <folder> , нет?
code-insiders -a <folder> необходим для добавления папки в текущее окно.

@Jeyanthinath, спасибо! Я делал то же самое, что и

@Tyriar, чтобы получить

code .; code -a .

code . открывает папку как не рабочую область, а затем code -a . прикрепляет ее к ранее открытому окну в качестве рабочей области, позволяя мне открывать одну и ту же папку более одного раза.

Я лично считаю, что это тоже нужно менять. Я работаю с ionic и настраиваемым сервером в двух разных репозиториях git, и это не очень просто. Было бы здорово иметь возможность хотя бы открыть две отдельные «вкладки проекта» или что-то еще.

Я перешел с Atom из-за того, насколько он глючный и медленный.

@ dark-swordsman вы можете включить nativeTabs на Mac

@felixfbecker возможно ли это в Windows?

Изменить: я полностью просмотрел файл настроек, и для этого нет возможности. Вот почему я спрашиваю.

Edit2: Кроме того, нет четкого ресурса о том, как включить vs insiders

Здравствуйте,
@ dark-swordsman вы не включаете VS Insiders. Это сборка VSCode, которая имеет некоторые дополнительные функции, которые еще не доведены до стабильной версии, и в некотором смысле дает вам дополнительное пространство имен редактора для работы (вы можете установить их бок о бок, без конфликтов настроек или расширений). Спасибо. Добрый день.

Поддержка многокорневых рабочих пространств теперь включена по умолчанию в стабильной версии.

panel-red2

Пожалуйста, обратитесь к нашей документации для полного объяснения всех функций, которые с ним поставляются. Авторам расширений следует обратиться к нашей вики, в которой объясняются новые API-интерфейсы расширений, чтобы ваше расширение было готово для работы с несколькими корнями. Мы рады, что некоторые расширения уже начали принимать новый мульти-корневой API, спасибо за это!

Пожалуйста, не стесняйтесь сообщать о проблемах с несколькими корнями по мере их возникновения, мы все еще планируем вносить изменения и предоставлять дополнительные API-интерфейсы для расширений для работы с несколькими корневыми рабочими пространствами в будущем.

Это здорово, но когда это будет доступно? Вы говорите, что это стабильная сборка, но у меня последняя стабильная сборка (1.17.2), и я не могу ее обновить. Кроме того, в документации, на которую вы только что ссылались, сказано, что она все еще находится в сборке Insider и скоро будет в стабильной версии.

Я понимаю, что до выпуска следующей сборки может пройти немного времени, но я видел это уведомление, ожидая, что оно будет доступно.

Изменить: прошу прощения за мое нетерпение. Я просто пытался открыть новое окно вручную (снова вызвать .exe), и он не работал, но не смотрел в File> Open New Window. Пока это будет работать. С нетерпением жду выхода следующей сборки. 👍

@bpasero Закройте эту открытую проблему # 35849, поскольку ожидаемая функциональность реализована как часть этой функции # 396.

Просто быстрый вопрос. Возможно ли, когда я открыл больше папок, переключить, какую папку я хочу скомпилировать? На данный момент это всегда первый в стабильной версии.

РЕДАКТИРОВАТЬ: Это может быть для создателя расширения PlatformIO, но я спрашиваю с обеих сторон. Так, на всякий случай...

@DJManas похоже, что это зависит от расширения, которое вы используете, поэтому вы должны спросить автора расширения.

@bpasero Хорошо, я делал параллельно, спасибо за ответ.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги