Vscode: أضف دعمًا لفتح مجلدات مشروع متعددة في نفس النافذة

توافق ، ولكن ربما يكون هذا الحل الأمثل للذاكرة

+1

لست متأكدًا من فهمي لهذا السؤال ؛ إنه محرر كود خفيف الوزن ، وليس IDE ... لماذا تحتاج إلى فتح مجلدات "مشروع" متعددة ليست هرمية (حيث يمكنك تعيين مسار العمل إلى أحد الوالدين المشتركين)؟

إذا كنت تعمل على وحدات يتم تخزينها بشكل متباين على القرص والتي تتفاعل بطريقة ما مع بعضها البعض إلى هذه الدرجة ، فهي مرتبطة بإحكام شديد لتبدأ بها ... هل مشاريعك أشقاء؟ إذا كان الأمر كذلك ، فما عليك سوى فتح المجلد الأصلي ، أو المجلد الأصل / الأصل ... أينما كان جذر "الحل" الخاص بك.

حسنًا ، إذا كان لديك عدد من الوحدات (وكلها في مستودع git الخاص بها) مستقلة عن بعضها البعض ولكن لديك مستودع واحد يستخدم تلك التبعيات ، فمن المنطقي أن تكون قادرًا على فتح هذه المجلدات المستقلة وإجراء تغييرات من شأنها تنعكس حتى تتمكن من اختبارها محليًا. سيظل هذا محرر كود خفيف الوزن ولكنه أكثر فائدة imho!

تكمن المشكلة الرئيسية في تعيين المشروع باعتباره الوالد في أن تكامل git يختفي ، وهناك حالات استخدام أخرى صالحة بخلاف وجود أحد الوالدين المشتركين أيضًا.

يبدو stoffeastrom كحالة استخدام

على أي حال ، ما ذكرتهTyriar للتو هو أحد الأسباب التي

إذا استخدمت تكامل git للالتزام ، فهل ألتزم بالمشروع أ أم المشروع ب؟
إذا قمت بإعادة تشكيل اسم فئة في TypeScript ، فهل يجب إعادة بنائه في المشروع A أو المشروع B ، أو كليهما؟ ماذا لو كان نفس اسم الفئة موجودًا في كلا المشروعين بمعانٍ مختلفة؟ ماذا لو كان أحدهم يشير إلى الآخر بشكل فضفاض؟

هذه فقط بعض الأمثلة على كيف يمكن لشيء يبدو بسيطًا أن يصبح معقدًا للغاية وبسرعة كبيرة. أعتقد أنه سيكون أكثر إرباكًا ، وبصراحة ، أقل فائدة من علامة التبويب alt / cmd + tab بين بضع حالات منفصلة من VSCode ، كل منها يدير لحسن الحظ مسار العمل المعزول الخاص به دون كل الجهد الإضافي وقضايا الحالة.

أنا لا أقول أنه لا يمكن حلها ، لكنني لا أفهم تمامًا سبب كون التبديل بين النوافذ المتعددة و / أو المثيلات مشكلة. ربما أفتقد شيئًا ...

Sublime و Atom و Webstorm - هم أيضًا محررات تعليمات برمجية "خفيفة الوزن" (ربما باستثناء Webstorm) وتسمح بفتح مجلدات جذر متعددة من مواقع مختلفة. هؤلاء المحررين هم على الأرجح 99٪ مما يستخدمه مطورو الويب.
يمكن للكود أن ينافسهم مع دعم Typescript أفضل بكثير (وسيكون شائعًا جدًا بالنظر إلى أن Angular 2 قادم) ولكن فقط إذا كان سيعطي المطورين ما يستخدمونه الآن كوظيفة أساسية.

+1

+1

بصفتي مطور Go ، أجد هذه الميزة مفيدة للغاية في Sublime أو IntelliJ Idea. على سبيل المثال ، يستورد مشروعي الصغير رمزًا من مكتبة Go core أو قد يستورد بعض مكتبات الجهات الخارجية. لذلك أحتاج إلى أن أكون قادرًا على التنقل بسرعة وقراءة هذا الرمز.

+1. تعد حلول الخدمات المصغرة متعددة البوابات مؤلمة للغاية في VS Code في الوقت الحالي ، والتفكير في العثور على IDE آخر قادر على Typescript.

نحن بالتأكيد بحاجة إلى نوع من "الحل". أنا مطور أصلي ، وهذا دائمًا ما يتضمن إنشاء مجموعة من libs / dll ثم الرجوع إليها من بعض مشاريع التطبيقات المضيفة.
بمجرد أن يكون لدينا عدة مشاريع ، نحتاج أيضًا إلى "مشروع بدء التشغيل" عندما نضغط على "تشغيل".

أود أيضًا الحصول على دعم لمشاريع وجذور بوابة متعددة. تم العثور على الكود الذي أستخدمه بشكل متكرر في عدة مستودعات git وعدم القدرة على التبديل بينها دون إغلاق مساحة العمل الحالية وفتح مساحة أخرى فقط للالتفاف وإغلاق ذلك لفتح السابق أمر مرهق. إذا أضفت المجلد الأصلي حيث توجد جميع المستودعات الخاصة بي ، فحينئذٍ سأكتسب القدرة على التنقل والبحث بين ملفاتي ولكني أفقد تكامل git. إنها مشكلة حقيقية.

الخط الفاصل بين "محرر النصوص" و "IDE" ضبابي جدًا ولا يهمني حقًا ما يسمى رمز VS. ما يهمني هو ما يمكن أن تفعله الأداة ومدى سهولة استخدامها. أعتقد أن إضافة دعم المشروع من شأنه أن يخفف الكثير من الاحتكاك لأشخاص مثلي.

أود أيضًا أن أرى عمل تكامل git عندما تحتوي مساحة العمل الخاصة بك على العديد من المستودعات ، لكني أريد فقط التأكد من أن الأشخاص مثل @ Loren-Johnson يدركون أنه يمكنهم فتح نوافذ متعددة مقابل الأكواد في وقت واحد.

هذا استجابة لـ: "غير قادر على التبديل بينهما دون إغلاق مساحة العمل الحالية"

تقصد # 2686 هو نسخة مكررة من هذا؟

عذرًا ، لقد أخطأت في قراءة الوصف وأعدت فتح هذا الوصف.

+1

هل هناك أي تقدم في هذه القضية ، أو على الأقل بيان ما إذا كان سيتم تنفيذ ذلك؟ هل توجد بعض القرارات منخفضة المستوى في الكود تمنع تعدد الجذور في مشروع واحد؟

هذا هو السبب الوحيد إلى حد كبير لعدم الانتقال من ST3 إلى VSCode.

+1

+1

+1

+1 هذا سيكون مفيدًا جدًا. اقتراح استخدام وحدات git الفرعية غير مريح للغاية. أحب أن يكون لديك هذه الميزة.

قد يكون النهج الخفيف الأولي شيئًا مشابهًا لما يفعله ملحق git-project-manager . يمكن أن يكون الأسلوب هو تبديل السياق / الجذر بشكل أساسي لما يراه git كتغييرات ، ولكن دون تغيير السياق / الجذر لما يراه متصفح الملفات. يعمل هذا الامتداد بشكل مثالي ، ويحتاج فقط إلى تكامل أقوى لجعل التبديل أسرع.

+1

+1 - بدأت في السير في طريق استخدام وحدات git الفرعية ، لكن يبدو الأمر وكأنه اختراق أكثر منه حلاً فعليًا.

+1

+1

أنا أستخدم ملحق git-project-manager للتبديل بين المجلدات ، لكني أرغب حقًا في أن يكون لديك خيار لفتح عدة مجلدات في وقت واحد.
+1

فقط أريد أن أقول إن مالك امتداد Project Manager ينتظر هذا العدد أيضًا.

فيما يتعلق ببعض التعليقات (أعلاه) ، أود فقط أن أقول إننا جميعًا مختلفون ، فلدينا جميعًا طرقنا الخاصة في تنفيذ عملنا في مشاريعنا الخاصة. هذه الحقيقة تجعل تجربة المستخدم أكثر أهمية مما هي عليه بالفعل.

كنا نعلم جميعًا أن "فتح مجلد ..." كان مجرد خطوة صغيرة أولية لوجود إدارة مشروع حتمًا في vscode بأشياء مثل "فتح مشروع ..." ، وما إلى ذلك. تمامًا مثل جميع المحررين الآخرين ، وخاصة SublimeText (من حيث أتيت).

بالنسبة لي ، تعد هذه المشكلة تحسينًا لتجربة المستخدم للمنتج. ونعلم جميعًا أن UX هو الملك.

أشعر تقريبًا أن هذا النوع من الأشياء يجب أن يكون هو القانون ، وبالتالي يجب أن تكون العلامة "طلب الميزة" بدلاً من ذلك "تذكير الميزة".

يجب أن تكون هذه المشكلة ذات أولوية قصوى على أية مشكلات أخرى في vscode. ليس فقط لأن UX هو الملك ، ولكن لأنني لا أواجه أي مشكلات أخرى مع vscode في الوقت الحالي بخلاف هذا ... تقنيًا.

كنت أتصفح في الأصل لأطلب من Microsoft تولي هذه الإضافات التي تشبه المشروع والاندماج في VSCode مباشرةً ، وتحسين تجربة المستخدم ، على سبيل المثال عن طريق إضافة "مشاريع ..." إلى القائمة.

شكر،
+1

+1

تم وصف حالة الاستخدام الخاصة بي لهذه الميزة هنا: # 9515. (تم إغلاقه كنسخة مكررة من هذه المشكلة.)

آمل أن تحدث هذه الميزة!

+1

@ poidl، @ mastrauckas ، mdedgjonaj ، alanleite ، Xcorpio ، mibanez ، josebalius & brusbilis :
بعد فترة من الزمن ، قدم GitHub ميزة "أضف رد فعلك" الجميلة (انظر الابتسامة في كل زاوية اليمنى العليا من التعليق أو المشكلة نفسها؟).
يخدم هؤلاء غرض إبلاغ فريق VSCode عن اهتماماتك ولكن يمنعون التعليقات التي لا معنى لها +1 . كما أنه يمنع الأشخاص الآخرين الذين اشتركوا في مشكلة معينة أو MR من تلقي إشعار وبالتالي يوفر وقتًا ثمينًا. المكافأة الأخرى هي أنه يمكن فرز المشكلات / MR بواسطة most reaction مما يجعلها مرئية على الفور لفريق VSCode ما هو ملائم للمستخدمين. علاوة على ذلك ، هناك حتى Uservoice لـ VSCode .

هذا التعليق في حد ذاته ميتا وبالتالي لا معنى له أيضًا. أنا آسف لذلك ولكني اعتقدت أنه ضروري للأغراض التعليمية. سيؤدي كل رد مباشر على هذا التعليق (= المزيد من التعريف) إلى حظر المستخدم.
دعونا نتدرب فقط على الرد على هذا التعليق باستخدام ميزة reaction !

إلى إجابة poidl : إذن لا ترد مطلقًا!

أنا لا أرى هذا الابتسامة. على الأقل على الهاتف المحمول. حظر سعيد!

poidl نعم ، ميزة ردود الفعل غير متوفرة على موقع جيثب للهاتف المحمول للأسف (إلى جانب العديد من الميزات الأخرى). يمكنك الوصول إليه على الهاتف المحمول عن طريق الضغط على زر "إصدار سطح المكتب" أسفل الموقع.

ومع ذلك ، فإن نصيحة @ dj-hedgehog متاحة على الفور ، وتسمح لنا ردود فعل GitHub بقياس اهتمام المجتمع بشيء أكثر فعالية من عدد التعليقات. بالإضافة إلى ذلك ، نحن نخطط لإهمال User Voice لذا فإن مشكلات GitHub وردود الفعل هي مصدر الحقيقة لطلبات الميزات.

+1

+1

الحل الخاص بي لهذه المشكلة: إنشاء رابط رمزي لجذر مشروعي.
لذلك إذا كان لدي:
project/modules/gitmodule

أذهب إلى مجلد gitmodule الخاص بي وأقوم بما يلي:
ln -s ../../../project .project

الآن يمكنني فتح مجلد gitmodule الخاص بي في vscode ولا يزال بإمكاني الوصول إلى مجلد المشروع الأصلي.
أستخدم نقطة في اسم الملف بحيث يتم فرزها إلى أعلى قائمتي في المستكشف.
من الواضح أنني لا أفضل القيام بذلك ، لكنني اعتقدت أنه قد يكون مفيدًا لبعضكم.

نسيت تقريبًا: لا تنسَ إضافة الرابط الرمزي إلى ملف .gitignore الخاص بك

+1

هذه ميزة مهمة حقًا لمحرر النصوص الحديث. الرجاء حل هذه "المشكلة" من فضلك.
لفترة من الوقت ، اضطررت إلى نسخ ولصق جميع الدلائل المستخدمة في مجلد العمل الفعلي وهذا في Sublime Text تافه للغاية.

مشروع> إضافة مجلد إلى Project at Sublime Text يعمل على زيادة مسار جديد إلى بنية Json.

انظر أدناه:
{ "folders": [ { "path": "~/cpp" }, { "path": "~/python" } ] }

عند العمل مع الشيف على سبيل المثال ، من الشائع رؤية بنية مجلد مثل:

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

حيث تكون كتب الطهي (كتاب الطبخ 1 على سبيل المثال) الموجودة ضمن المجلد الجذر (كتب الطبخ) بمثابة مستودعات git المستقلة. هذا شائع جدا. الآن عليك العمل على كتاب الطبخ 4 ولكنه يتضمن كتاب الطبخ 2 وكتاب الطبخ 3. ستحتاج غالبًا إلى فتح الثلاثة ، إما للإشارة ببساطة إلى الكود أو لتعديل أو إعادة بناء الكود في جميع الثلاثة.

يمثل الخياران العاديان (وليس اختراقات الارتباط الرمزي) مشكلات لا يريدها أي مطور:

1. كما ذكرنا أعلاه عدة مرات ، سيتعين عليك الآن فتح نوافذ متعددة (ليس جيدًا)
2. إذا فتحت كتب الطبخ كجذر لرؤية كل 3 ، فستفقد تكامل git لأن مجلد كتب الطبخ ليس مستودعاً (ليس جيدًا أيضًا)

+1 ، مستخدم Eclipse IDE هنا والذي يتمتع بميزة التحكم الكامل في "مساحة العمل".

Visual Studio Code ليس IDE. إنه محرر خفيف الوزن متعدد المنصات ، مثل Atom أو Sublime. إكليبس ، إكس كود ، فيجوال ستوديو ، وآخرون. كلهم عملاقون بالمقارنة.

عذرًا ، لست متأكدًا مما إذا كنت تتجادل مع هذه الميزة أم لا ... تسمح لك Atom و Sublime و VIM و Emacs بفتح مجلدات متعددة في حالة واحدة. خفيفة الوزن أم لا ، إنها ميزة جيدة ، IntelliJ IDEA - IDE - على سبيل المثال لا يسمح لك بفتح العديد من المشاريع.

dmccaffery ، الميزات التي يتم طلبها هنا ليست فقط ميزات IDE ، الميزات المطلوبة مشتركة لجميع _المحررين_ التي قلتها إن Visual Studio Code _like_.

يمكن لمحرري Atom و Sublime وغيرهم من برامج التحرير خفيفة الوزن فتح مجلدات متعددة.

أنا شخصياً لا أهتم إذا انتهى الأمر بهذه الميزة في المنتج أم لا - أفهم لماذا يريدها بعض الناس ، لكنني أود أن أشير إلى أنها تجعل كل شيء أكثر تعقيدًا. على سبيل المثال: عند البحث باستخدام تعبير regex - ما مساحة العمل التي أبحث عنها؟ واحد؟ الكل؟

ماذا لو كان لدي مجلد واحد يحتوي على مشروع nodejs حيث يكون عرض علامة التبويب الخاص بي عادةً مسافتين ، ومجلد واحد هو مشروع dotnet حيث يكون عرض علامة التبويب الخاص بي 4 مسافات؟ يجب أن يكون الرمز على دراية بإعدادات مساحة العمل لكل مجلد والحفاظ على السياق طوال الوقت.

هذه مجرد أمثلة قليلة على الأماكن التي يمكن أن تكون فيها مساحات العمل المتعددة داخل مثيل واحد صعبة. كل ما أقوله هو أن هذه الميزة متورطة أكثر بكثير من مجرد ظهور مسارات متعددة في المستكشف.

dmccaffery ليس أكثر من سامية وذرة. يجب أن يكون كل هذا قابلاً للتكوين ، حتى عرض علامة التبويب لكل مساحة عمل. يمكن أن يكون البحث في atom و sublime في الملف الحالي فقط ، في مساحة العمل هذه ، إلخ ... إنه اختيارك.

هذه حقيقة ، شئنا أم أبينا ، ولا علاقة لها بما تريده أو أريده. إذا كانت البرامج الأخرى المماثلة بنقاط سعر مماثلة (مجانية في هذه الحالة) بها ميزات أفضل أو أكثر ، ويتجاهل المطور هذه الحقيقة ، .. سيتم ترك هذا البرنامج وراءه.

أنا شخصياً لا أريد أن أرى ذلك يحدث لهذا المحرر. أعتقد أن هذا المحرر لديه إمكانات جيدة جدًا ويمكن أن يظل وثيق الصلة لبعض الوقت _إذا كان المطورون يستمعون إلى رغبات / احتياجات قاعدة مستخدميه.

مرة أخرى؛ أنا لا أجادل مع أو ضد - فقط ضع في اعتبارك أن هذا محرر جديد للغاية به سياق خارج الصندوق أكثر بكثير من منافسيه - امنحه بعض الوقت.

حتى في مثالك مع تكامل الشيف و git - كيف تحافظ على سياق الريبو الذي تلتزم به؟ ستحتاج واجهة المستخدم الحالية إلى التكيف مع تبديل السياق المستمر - نفس الشيء بالنسبة لـ OmniSharp ، الذي يستخدم خادمًا و roslyn لتوفير تمييز بناء الجملة ، وما إلى ذلك لمشاريع CoreCLR. الآثار بعيدة المدى وستحتاج إلى التفكير جيدًا.

لا جدال حول فكرة أن الميزات تحتاج إلى تخطيط جيد ومدروس. أعتقد أن هذا أمر مفروغ منه. أعتقد أن جميع المستخدمين سيكونون سعداء إذا كانت الإجابة هنا "إنها على خريطة الطريق" أو "نحن نعمل لتحقيق هذه الغاية". كل ما أقوله هو أن "لا" من المحتمل أن تقتل عددًا قليلاً من المستخدمين خلال الليل.

فيما يتعلق بتبديل السياق و git repos في chef ، نعم وافق ... هذا كله صحيح وقد تم إنجازه جميعًا في برامج تحرير أخرى مفتوحة المصدر. أنت تعرف الشيء العظيم في المصدر المفتوح ،،، إنه مفتوح! انظر إلى الكود ، احصل على أفكار ، بل تحقق من استخدام بعضها (تأكد من تضمين الترخيص حسب الحاجة). هذا أحد الأشياء الرائعة حول foss (برنامج مجاني مفتوح المصدر) والتعاون ومشاركة المعرفة. نظرًا لأن هذا المحرر يستخدم بالفعل كود atom ... أعتقد أن هذا سيكون أيضًا معطى.

لقد وجدت هذا مذكورًا في https://github.com/Microsoft/vscode/wiki/Roadmap

يعد VS Code منتجًا جديدًا ولا يزال هناك نقص في الميزات والتجارب التي تطلبها والتي نريد تقديمها.
....
....

• مجلدات متعددة داخل مساحة عمل واحدة

لا أعتقد أن أحدًا يقول إن هذه الميزة بسيطة (نظرًا لأننا جميعًا مطورون ، يمكننا أن ندرك ما الذي يجب تغييره) وأنا ضيف يعلق على هذه التذكرة فقط أريد فقط إظهار مدى أهميتها ، وما هي الأولوية التي يجب أن تكون عليها ، وكيفية مقارنة هذه الميزة مع بعض الإخوة VS Code (Atom ، Sublime على سبيل المثال).

ولكن نظرًا لأن هذا موجود بالفعل في خريطة الطريق (يمكن لأي شخص أن يؤكد أن صفحة wiki لا تزال صحيحة) ، يجب أن نناقش كيفية تنفيذ ذلك بدلاً من مجرد قول كيف نحتاج ومدى أهميته (مرة أخرى ، أعتقد أن فريق VS Code الأساسي بالفعل تعرف كيف نحتاجها ومدى أهمية هذه الميزة).

لست على دراية بالشفرة المصدرية لـ VS Code ، فهل يمكن لأي شخص أن يخبرني إذا كنت أرغب في تنفيذ هذه الميزة ، أين يجب أن أنظر أولاً؟ في الخطوة الأولى ، أريد فقط فتح مجلدات متعددة وإظهارها على الشريط الأيسر.

nvcnvn ليس أمرًا تافهًا لأنه قد يتطلع إلى تطبيق هذا لأن الكثير من vscode يفترض أنه يمكن فتح مجلد واحد فقط. على هذا النحو ، ستحتاج إلى المرور عبر UX ومن المحتمل أن تلمس العديد من أجزاء قاعدة الكود ، ومن المحتمل أن يكون لها تأثيرات على واجهة برمجة تطبيقات الامتداد أيضًا.

أتذكر عندما خرج Atom ، مع نفس قيود المجلد الفردي. كانت الشكاوى هي نفسها أيضًا ، خاصة المقارنات مع Sublime. بعد ذلك ، عندما تم إصدار دعم _multiple folder_ ، تم كسر بعض الحزم (الامتدادات) بسبب واجهة برمجة التطبيقات الجديدة. لم ينكسر الآخرون لكنهم لم يؤيدوه أيضًا. استغرق الأمر بعض الوقت حتى أصبحت _ مستقرة _ في النظام البيئي بأكمله.

كما قال Tyriar ، سيكون هناك بعض تأثير واجهة برمجة تطبيقات UX والامتداد ، ومن المحتمل أن يكون إصدارًا مشغولًا من الداخل للمطورين الأساسيين والإضافات ، لاعتماد واجهة برمجة التطبيقات الجديدة.

إذن ما الذي يدور هنا بالضبط؟
أعني كل ما أراه هو "عدم إجراء تحسينات لأنه قد يؤدي إلى كسر الأشياء" ...

ملحوظة:
جميع التحسينات في الرمز يمكن أن تكسر شيئًا ما!

هذه هي نقطة التصحيح وإعادة البناء والإصدارات السابقة (ألفا ، بيتا ، RC ، إلخ ...)
تعال ، بجدية؟ لم أقابل مطلقًا مبرمجًا جادًا كان يخشى تحسين الكود لأنه قد يكسر شيئًا ما. كن حذرا نعم ، خذ وقتك وكن بأمان نعم ، ولكن لا تقل "لا ، يمكن أن يكسر الأشياء" لول

ddreggors أنا لا أجادل ، أنا ببساطة أذكر بعض المعلومات حول هذه القضية. لقد قلت ما قلته حتى لا يحاول nvcnvn إنشاء علاقات عامة لهذا الأمر حيث سيتعين على الفريق القيام بذلك بسبب قائمة أصحاب المصلحة.

كما أشار nvcnvn ، هذه المشكلة على خريطة الطريق مما يعني أن الفريق سيبحثها قريبًا. نحن فريق صغير نسبيًا على الرغم من وجود الكثير من الأشياء التي يجب تغطيتها ، لذا يجب تأخير بعض الأشياء.

Tyriar مفهوم ، ما زلت أرى هذه التعليقات من عدة أشخاص يبدو أنهم يقترحون أنه من الأفضل عدم إضافة هذه الميزة لسبب أو لآخر. كان أسوأ ما في الأمر هو حقيقة أن الكود ليس IDE ، عندما قارن الآخرون بوضوح بين المحررين الآخرين وليس IDE. جعلني ذلك أرغب في الوصول إلى جذور الخوف من هذا التغيير لتجاوزه إن أمكن.

أستطيع أن أفهم القلق من عدم اكتمال العلاقات العامة ، ولكن يمكن أن تكون بداية جيدة ... ادمج هذا التغيير في فرع واستخدمه كقاعدة. استخدم ذلك لرؤية الكسور وإصلاحها.

ddreggors ، اجتماعات UX الخاصة بنا

عادل بما يكفي ، ستعرف أفضل ما في هذه الغاية. من الجيد معرفة أن هذا يجري مناقشته رغم ذلك. :-)

شكرًا على الجهود ، وما يبدو أنه بداية محرر جيد جدًا.

يبدو أيضًا أنه جهد ضائع لاقتراح هذا الموضوع لاجتماعات UX الخاصة بك: --)

لقد عدت مؤقتًا إلى Atom حيث أصبح أكثر استقرارًا في الإصدار 1.9. كان يتعطل عند فتح أي ملف كبير وكان هذا هو السبب الرئيسي لبدء التحقق من VSCode في مرحلة ما. أتطلع حقًا إلى رؤية مشاريع متعددة في نافذة واحدة - يبدو أنه ليس لدي ما أفعله سوى اتباع هذا الموضوع حتى ذلك الحين.

لماذا مايكروسوفت الناس لا تركز على هذا؟

+1

+1

أنا حقًا أحب VS Code. لقد أصبح المحرر الأساسي لدي ، لكن صعوبة العمل في أكثر من مشروعين في وقت واحد أصبحت مربكة. هناك ضربة مزدوجة على هاتين المسألتين المفتوحتين: هذه المشكلة ، وتكوين معلومات شريط العنوان .

ستحل أي من هاتين الميزتين المشكلة (على الرغم من أنه من الناحية المثالية ، أود كليهما!). لا أمانع في وضع كل شيء أعمل معه ضمن مجلد واحد وفتحه - ولكن بعد ذلك لا يعمل تكامل git ، ولا توجد طريقة تافهة للبحث داخل مشروع واحد فقط أو تنظيم النتائج حسب المشروع.

لا أمانع في فتح كل مشروع في نافذة VS Code فعلية مختلفة والسماح لنظام التشغيل الخاص بي بإدارة المثيلات - ولكن نظرًا لأن شريط العنوان يعرض اسم الملف المفتوح أولاً ، بدلاً من بعض معرف المجلد الجذر / المشروع ، فمن المستحيل التبديل إلى مشروع مفتوح آخر محدد دون فتح والنظر إلى كل مثيل نشط. إنه يجعل شيئًا يجب أن يكون سهلاً في إزعاج دائم.

من فضلك - هل هناك طريقة يمكن أن تصبح فيها إضافة إحدى هاتين الميزتين أولوية؟ لقد جربت كل ما يمكنني التفكير فيه للتغلب عليه ، حتى أنني أمضيت ساعة في البحث عن بعض بدائل شريط مهام Windows التي تسمح لي باختيار النوافذ من قائمة يمكن أن تعرض المزيد من النص في شريط العنوان ولكن لا يمكنني العثور عليه اى شى.

إذا كان لدى أي شخص أي اقتراحات حول كيفية إدارة العديد من مشاريع VS Code المفتوحة بشكل فعال ، فأنا أحب سماعها.

الشيء المهم الذي يعمل بشكل جيد في Atom هو أن المكونات الإضافية ، مثل eslint ، يجب أن تظل تعمل على مستوى المشروع. لذلك إذا كان للمشروع أ قواعده الخاصة ، فلا ينبغي أن يتأثر المشروع ب بهذه القواعد والعكس صحيح. لا يمكن أن تنتظر الحصول على مثل هذا UX في Code. هذه بالتأكيد واحدة من ، إن لم تكن أكبر عقبات التبني في الوقت الحالي.

هذا هو الشيء الوحيد الذي يدفعني إلى تبنيها.

أعلم أنه قد يكون لديك الكثير من المشكلات الأخرى التي يجب إصلاحها والميزات الأخرى التي يجب تنفيذها ، ولكن على الأقل بعض الدعم الأساسي للبدء سيكون رائعًا.

شكرا للعمل الشاق على 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. Dealbreaker بالنسبة لي.

هذا حقا مطلوب. +1

هناك حل بديل لتداخل المجلدات ضمن مساحة عمل vscode. فقط لإنشاء رابط رمز إلى مجلد مساحة العمل ، مثل هذا mklink /d link target

أوافق - أعتقد أن هذا الطلب مطلب محدد.
ليس لديك دائمًا مشروع في مجلد واحد - يمكن أن يكون لديك مجلدات فرعية وإخوة ، وعدم امتلاك هذه الميزة يعد بمثابة كسر حقيقي للصفقة بالنسبة لي الآن - ولهذا السبب يتعين علي استخدام سامية.
الرجاء إضافته!

على الجانب الأيسر ، تظهر المجلد الذي تعمل فيه كمشروع. يمكن أن يعمل هذا إذا كان لديك حيث يمكنك رؤية كل منطقة مجلد (مشروع) مفتوحة هناك. يمكنك توسيعها وطيها كما تفعل الآن (ولكن لمناطق المجلدات المتعددة).

محرر رائع إذا كان بإمكاني فقط التبديل بين مشروعين. صفقة حقيقية.

مرحبًا بالجميع ، أوصي بامتداد Git Project Manager إذا كنت تقوم بالكثير من التبديل بين المشاريع في هذه الأثناء. يقوم بمسح دليل للأدلة التي تحتوي على مجلد .git ويسمح بالتبديل السريع إليها ، لقد كنت أستخدمه لبضعة أسابيع وهو بالتأكيد يجعل الأمر أسهل.

عندما أقوم بتبديل المشاريع إما أن أذهب:

1. ctrl + alt + p
2. اكتب بداية المشروع ، على سبيل المثال. "vsc" لـ vscode
3. أدخل

أو إذا كنت أرغب في فتح المشروع في نافذة أخرى ، فاضغط على ctrl + shift + n مسبقًا. يمكنك تكوين الامتداد ليتم فتحه دائمًا في نافذة جديدة إذا كان هذا هو الشيء الذي تفضله أيضًا.

هذه لقطة شاشة توضح كيف يمكنك بسهولة تنفيذ مشاريع متعددة.

@ soljohnston777 المشكلة هي أن تكامل git (أو أي نوع آخر من تكوين كود VS) غير مدعوم على مستوى المجلد.

تكمن المشكلة في أن تكامل git (أو أي نوع آخر من تكوين رمز VS) غير مدعوم على مستوى المجلد.

هاه حقا؟ هل كرر VSCode الأخطاء التي حدثت عندما يتعلق الأمر بمفهوم مساحة العمل؟ سيكون ذلك مفاجئًا ، مع العلم أن عددًا قليلاً من أعضاء فريق VSCode كانوا جزءًا من فريق الكسوف الأساسي ...

هل كرر VSCode الأخطاء التي حدثت عندما يتعلق الأمر بمفهوم مساحة العمل

لا يمكنني التحدث إلى فلسفة المهندسين المعماريين هنا ، ولكن هذه الحقيقة (هذا التكوين لكل مثيل وليس لكل مجلد) هو السبب الكامل لهذه المشكلة والمناقشة.

يمكنك استخدام نوافذ VScode منفصلة للمشاريع. لماذا لا يتم تنفيذه بهذه الطريقة داخل VSCode؟ (نافذة منفصلة لكل زر مشروع جانبي - فقط قم بالإشارة إليه بالداخل). سيوفر عناء الترميز داخل البرنامج ، ومع ذلك تظهر المشاريع في الداخل ، ويسهل دمجها وتطويرها.

يمكن وضع Git بشكل مستقل لكل منطقة مجلد لمشاريع متعددة ... أجد أن git مربكًا مع VSCode ، لذلك أميل إلى القيام بسطر الأوامر على أي حال (والذي يبدو أنه يجب أن تكون قادرًا على القيام بذلك في VSCode).

إن وجود مجلدات فرعية تضم مجلدًا أصليًا وهي مستودعات git مستقلة مفيدة حقًا عندما تنتمي جميعها إلى نفس المشروع. هل ترغب في رؤية هذا متاحًا ، على الأقل مع علامة تكوين اختيارية في الإعدادات.

أود أيضًا أن أعبر عن اهتمامي القوي بالحصول على دعم git لعدة مستودعات git.

+1. هذه ميزة رئيسية تمنع تبني VSCode كمحرر رئيسي.

+1

+1 - خاصة بالنسبة للأشخاص الذين يعملون مع قواعد أكواد الخدمات المصغرة / العديد من الريبو ، هذا هو المفتاح. (المفتاح: عدم فتحها جميعًا مرة واحدة ، ولكن التبديل بينها ، وجعل المحرر يتذكر الملفات التي كانت مفتوحة وفي أي مساحات عمل.)

+1
إعدادنا هو شيء مثل الكود الأساسي في GIT repo ، وبعض الكود الإقليمي في repo آخر ، ورمز خاص بالمشروع في repo آخر ، لذلك عندما تعمل في مشروع ، تحتاج إلى الترميز من جميع المستودعات الثلاثة (أو أكثر). عدم القدرة على أن يكون لديك "مشروع" بإعداداته الخاصة والقدرة على إضافة مجلدات متعددة من مصادر متعددة فهو ملك مانع.

@ danechitoaie كيف تعرف أن التغيير الذي تقوم به على الريبو الأساسي الخاص بك لا يكسر شخصًا آخر يعتمد عليه لمنطقة مختلفة أو قاعدة رمز مشروع مختلفة؟ تبدو طريقة عمل خطيرة ؛ يجب أن تكون هناك إدارة إصدار منفصلة باستخدام نوع من نظام إدارة الحزم أو ما شابه.

عدم الجدال ضد تنفيذ بعض مساحات العمل ، لكن نظام مشروع كامل يضيف قدراً لا بأس به من التعقيد.

موافق ، إنه كذلك ويجب عليهم / يمكنهم القيام بالكثير من الأشياء بشكل أفضل بكثير ولكن ... هذا خارج عن سيطرة "المستخدمين الفانين" أو قدرتنا على اتخاذ القرارات ...

فهمت. أحبه عندما يحدث هذا النوع من الأشياء.

وماذا عن هذا؟

بالنسبة لي ، زر تبديل بسيط مثل هذا لا يكفي. إذا احتجنا إلى هذه البساطة ، فافتح حالتين (ctrl shift N) ، ثم استخدم مفتاح التشغيل السريع لنظام التشغيل للتبديل بين windows / workspaces هو نفسه تمامًا.
أحب أن يكون لدي شيء يسهل مقارنة الملفات ، وهيكل المشاريع ، وهو شيء يساعدني على إجراء تغييرات طفيفة بسرعة وبناء جميع الاختلافات والاحتفاظ بها في نفس الشاشة ، وقادر على عكس التغييرات لجميع المشاريع التي أعمل معها.

+1

+1

نوع من الحل البديل لنظام التشغيل macOS Sierra.

علامة تبويب واحدة لكل مشروع داخل نافذة واحدة عن طريق تعيين Prefer tabs when opening documents إلى Always في إعدادات الإرساء. لكنه سيؤثر على سلوك تطبيقات الآخرين أيضًا ..

+1

هذا أصبح قاتلا بالنسبة لي. انا احب البرنامج لكن الرجل لا يعجبني واحد فقط له نافذة واحدة ...

بصراحة ، اضطررت إلى التوقف عن استخدام Code لأنه بقدر ما يعجبني ، فقد أصبح تبديل النوافذ مرهقًا للغاية.

إذا تم إصلاح هذا في المستقبل ، فسأحاول مرة أخرى ، حتى ذلك الحين ، سيكون هذا سدادة عرض بالنسبة لي ولكل شخص قمت باختباره.

+1

+1

يُرجى تفضيل: +1: ردود الفعل على تعليق المشكلة الأصلي حيث يساعدنا ذلك في تحديد الأولويات ولا يرسل إشعارات إلى كل شخص يستمع إلى المشكلة للحصول على تحديثات.

+1

أنا أستخدم حاليًا Sublime ، وأقوم بتجربة Code. يبدو الأمر لطيفًا ويشعر به ، لكن تكامل Git للمشروع الفردي يعد بمثابة كسر للصفقة. لديّ مشروع Hadoop / Oozie ، ولديّ مستودع رمز واحد وآخر من ملاحظات العمل. في Sublime ، لديهما مفتوحان في نفس النافذة ، ويمكنني الالتزام بـ Git repo المناسب لكل منهما

لذلك ، سيكون من الجيد إضافة

+1 نعم ، أمر بالغ الأهمية في عالم الخدمات المصغرة ، من المعتاد أن يكون لديك 3..4 مستودعات مفتوحة في نفس الوقت

تذكير أسبوعي: توقف عن نشر التعليقات باستخدام +1. بدلاً من ذلك ، أعطِ إعجابًا بالمسألة الأولية ، والتي يتم احتسابها بالفعل.

أنا أعلم أنك قصدت جيدًا. لذا لا تتردد في حذف تعليق 1+ حتى لا يشغل مساحة في هذا السجل التاريخي المهم أيضًا!

jamietre لقد حاولت ... بجد:

ربما يكون البديل الآخر هو إغلاق هذه المشكلة مع الإبقاء عليها مفتوحة حتى يتم حلها؟ بهذه الطريقة ، نعرف أهمية المشكلة (أقول إننا حصلنا بالفعل على عدد كافٍ من +1 لها) ، ولكن لا يمكننا إضافة المزيد من الفوضى / التكرار (على سبيل المثال ، لا يُسمح بمزيد من التعليقات).

على الرغم من أن هذه ميزة نادرة الاستخدام على ما أعتقد ، إلا أنني واجهت الإغلاق في مشروع / ريبو عام واحد على جيثب.

يمكن إلغاء قفل الإغلاق عند الضرورة ، إذا حدث ذلك.

daluu هذه هي الطريقة التي يعمل بها / aspnet / إعلان الريبو ؛ يتم قفل كل قضية على الفور. ومع ذلك ، يجب على 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 فضلك ... ركز على ما هو مطلوب هنا ، وهو مشاريع متعددة في المستكشف.

بالنسبة لمشكلة git ، يجب تقسيمها فقط بنفس طريقة المستكشف (أي بواسطة cwd).

دعونا لا نبدأ حربًا نارية على عناصر +1. سيكون من الرائع بالتأكيد أن يتم إعطاء الأولوية لهذه المشكلة.

لكن أود أن أذكر للمجتمع ، أفترض أن العلاقات العامة والمساهمات مرحب بها ؛-) يمكن لأي شخص أن يقوم بتصحيح / إصلاح الكود إذا لم يصل المطورون الأساسيون إليه. لقد تم تحسين بعض مشاريعي (باستخدام مفترقات) لأن المستخدم / المطور يفضل القيام بذلك بنفسه بدلاً من الانتظار لإجراء التحسينات التي يودون اقتراحها لي. إذن أي شخص منزعج من هذه المشكلة وقادر / ماهر بدرجة كافية ، يرجى الإصلاح (ثم إرسال PR)؟ هههه

وبالعودة إلى موضوع 1+ ، فإن طرح المشكلة وإضافة رأيك أمر جيد ، ولكن إجراء 1+ يعد طريقة ضعيفة للقيام بذلك إذا كانت هناك طرق أخرى متاحة مثل ميزة الإعجاب. ضع في اعتبارك منشورًا على Facebook ، أو منشور Google+ الأصلي ، ويذهب المستخدمون / القراء لإضافة تعليق +1 بدلاً من النقر فوق إعجاب (أو أحد ردود أفعال Facebook الجديدة) ، أو +1 لـ Google+. بمرور الوقت ، يكون هذا عبارة عن سلسلة تعليق طويلة من إجراءات 1+ lame ، حيث قد أقوم بالتمرير لعرض التعليقات المثيرة للاهتمام ، لكنني في النهاية أرى مجموعة من إجراءات 1+. هذا ما كان يحدث هنا ، أفضل عدم رؤية / قراءة إجراءات 1+ هذه ، سواء كنت مطور مشروع أو مجرد مستخدم (أو أبحث في هذا المشروع للاستخدام المحتمل).

في ملاحظة ذات صلة ، إليك استخدام سخيف (ولكن حسن النية) لقضية GH ، الحمد لله ، لم يجر جميع الأشخاص إجراء +1 على الرغم من ذلك: https://github.com/sinatra/sinatra/issues/920

أفترض أن العلاقات العامة والمساهمات مرحب بها

ليس صحيحا. راجع هذا التعليق من أغسطس: https://github.com/Microsoft/vscode/issues/396#issuecomment -241806158

يبدو أن هذه القضية مطروحة في " خارطة الطريق" منذ ذلك الحين على الأقل ، ولكن لم يتم إحراز أي تقدم بشأنها. سيكون من الجيد سماع تحديث الحالة من فريق VSCode.

بالنسبة لي ، وهذا يحاول إعادة الموضوع إلى المسار الصحيح ، هناك حاجة إلى مجلدات متعددة للمشروع.

في Atom ، يدعم GIT ، والطريقة الوحيدة التي استخدمها هي ملاحظة الملفات التي بها تغييرات. لدي خادم Rackspace لا يسمح لـ SSH لذا أذهب للتحميلات اليدوية. ومع ذلك ، يمكنني الحصول على مجلدات متعددة للمشروع في الشريط الجانبي ، مما يجعل من السهل جدًا الرجوع إلى الكود الذي استخدمته في مشروع سابق. أو تبديل التروس إلى مشروع آخر إذا كنت بحاجة إلى استراحة.

مع VSCode ، المشكلة التي تمنعني من التبديل ، والرجل الذي أريد التبديل ، هي عدم وجود مجلدات متعددة للمشروع في الشريط الجانبي.

أعني أنه يمكنني فقط فتح المجلد الجذر لحل المشكلة مؤقتًا ، ولكن إذا كنت بحاجة فقط إلى مجلدات 3/20 ، ولا أريد رؤية الملفات السائبة ، فيجب أن يكون هذا تنفيذًا سهلاً ، أليس كذلك؟

تحديث: التحديث الكبير لمنضدة العمل قريبًا هو الخروج السريع (# 101) ، أثناء العمل على الخروج السريع ، كنا نناقش هذه المشكلة بنشاط للتأكد من أن التصميم يأخذ عدة مجلدات في الاعتبار.

هذه المشكلة هي حاليًا رقم 2 من حيث: +1: ردود أفعال جميع المشكلات (رقم 1 من خلال علامات طويلة على طاولة العمل) ، على هذا النحو من المحتمل جدًا أن يكون هذا هو الجزء الكبير التالي من العمل لمنضدة العمل بعد الخروج السريع.

On: +1: التعليقات ؛ إنهم يخدمون فقط لإزعاج أكثر من 80 شخصًا مشتركًا في المشكلة. ومع ذلك ، فإن التصويت على المشكلة مع رد الفعل هو أحد أقوى الأشياء التي يمكنك القيام بها للتأثير على المشروع.

ضع في اعتبارك أيضًا أننا فريق صغير نسبيًا وأن نظافة قاعدة الكود وأداء vscode أمران مهمان للغاية ، لذلك تستغرق الأمور وقتًا للقيام بها بشكل صحيح. خاصة بالنسبة لشيء مثل هذا والذي يعد تغييرًا أساسيًا لكيفية إنشاء vscode حتى الآن ، هناك قدر كبير من العمل في هذه المشكلة.

+1

في الواقع ستكون هذه ميزة مفيدة.

لقد قمت بالتبديل من Atom وأعجبني حقًا ، لكنني أعمل على تطبيقين لواجهة المستخدم و 2 SDK آخر ، لكن عدم القدرة على التغيير بين تلك المشاريع (أو المجلدات) بسرعة هو نقص مهم ، أعتقد أنه يجب أن أعود إلى Atom حتى هذا تم حلها

أنا أتطلع حقًا إلى هذه الميزة ~~~

أنا golang develper باستخدام vscode ، آمل أن يكون لهذا التطبيق ، thx!

أحاول التبديل من Sublime إلى VScode. وسرعان ما اكتشفت أن VScode لا يدعم مجلدات متعددة في مفهوم "المشروع" هو في الحقيقة مشكلة تمنعني من القيام بذلك.

حقا أحب الميزات الأخرى لهذا المحرر "خفيف الوزن". وفي الوقت نفسه ، أعتقد أن دعم مجلدات متعددة في "مشروع" لن يجعل VScode "زائد الوزن" أو "يشبه IDE". سيجعل الأمر أكثر ملاءمة للمطورين الذين يستخدمون المحررين الآخرين لجعل الانتقال أقل إيلامًا.

نأمل في الحصول على هذا التحسن. شكر!

أيضًا إذا كان بإمكان الفريق إضافة القدرة على حفظ الإعدادات المستندة إلى المشروع والتي تتجاوز الإعدادات الافتراضية التي ستكون رائعة. حالة الاستخدام هي إذا كان بإمكاني الحصول على مترجمين مختلفين لمشاريع مختلفة. وبالمثل ، فإن وجود أحجام علامات تبويب مختلفة وما إلى ذلك سيساعد أيضًا. واسمحوا لي أن أعرف ما إذا كان يمكن بالفعل تحقيق ذلك بطريقة ما.

بصفتنا مطورًا ، نعمل دائمًا على مشاريع متعددة ولدينا مشاريع جانبية خاصة بنا. يعد تخصيص إعدادات المشروع (إعدادات مساحة العمل لـ vscode) في كل مرة أقوم فيها بتبديل المشروع بمثابة ألم كبير.

bajubullet يجب أن تجرب https://marketplace.visualstudio.com/items؟itemName=EditorConfig.EditorConfig لست متأكدًا مما إذا كان يغطي كل ما تحتاجه ، لكنها بداية.

@ danechitoaie شكرا على الرد. لا يساعد EditorConfig على الرغم من ذلك ، يمكنني تحديد الخصائص لكل نوع ملف ولكن إذا كان بإمكاني حفظها كإعدادات للمشروع ، فسيكون ذلك أسهل ولا أحب أن يكون لدي محرر. أيضًا في حالة الامتدادات مثل ملحق python الذي يتيح لنا توفير المترجم الفوري لاستخدامه ، فلن يساعد ذلك لأن python.pythonPath غير مدعوم من خلال editorconfig. يرجى إعلامي إذا فاتني شيء ما هنا. أي اقتراحات هي موضع ترحيب.

أوافق ، أنا أيضًا أتطلع حقًا إلى نوع من الإعدادات الخاصة بالمشروع والقدرة على فتح مجلدات "جذر" متعددة. إنها الأشياء الوحيدة التي أفتقدها من Sublime.

يتم تنفيذ هذا قريبًا!

لذلك لا داعي للاستمرار في الإضافة إلى هذا المنشور. إذا كان لديك مشاكل أخرى ، قم بإنشاء موضوع جديد. شكر!

هذا خيط طويل جدًا وقد قرأت خلاله ربما ثلثه ، لكنني أريد فقط التعبير عن دعمي. لقد قمت للتو بتثبيت VS Code باستخدام https://github.com/JuliaEditorSupport/julia-vscode كبديل محتمل لـ Atom / Juno. جميل! 😍

ومع ذلك ، عند تطوير كود جوليا ، أشعر أنه من المهم جدًا أن تكون قادرًا على فتح حزم متعددة في مجلدات مختلفة. من حيث المبدأ ، يمكنني فتح المجلد أعلاه ، لكن هذا من شأنه أن يعرض مئات حزم جوليا التي قمت بتثبيتها. يمكنني أيضًا تغيير LOAD_PATH ، لكنني أفضل حل VS Code.

آمل بصدق أن أتمكن من فتح مجلدات متعددة. شكرا على المجهودات 👍

مرحبًا بالجميع ، ربما لاحظت أننا نستكشف تنفيذ هذه المشكلة أثناء هذا التكرار.

من https://github.com/Microsoft/vscode/issues/17608

تحقق من مساحات عمل متعددة الجذور عبر المكونات المختلفةteam

أتطلع إلى الدردشة مع 3-5 منكم حول حالات الاستخدام الخاصة بك كما نفكر في تفاصيل التنفيذ. يرجى التسجيل للحصول على فترة زمنية مدتها 15 دقيقة يوم الثلاثاء المقبل إذا استطعت. احب ان ادردش.

التبديل بين واجهتي API و ui يجعلني مجنونة ... :-(

ehartford لأي سبب على وجه الخصوص أنهم لا يشاركون

نعم. لا يعمل تكامل Git إذا قمت فقط بفتح الدليل الأصلي.

سبب وجيه ehartford : ابتسم:

waderyan هل تبحث عن _نهاية حالات استخدام المستخدم_ فقط ، أم _ مطوري الإضافات_ أيضًا؟

بصفتك مستخدمًا إضافيًا ، كان دعم المجلدات المتعددة مفيدًا في معظم الأوقات لأغراض البحث. اعتدت على إنشاء مشاريع بإضافة مجلدات مختلفة من واجهات برمجة تطبيقات مختلفة ، فقط لتسهيل عمليات البحث (الموحدة). أود أن أقول إنني لا أفتقد الكثير اليوم ، ولا يزعجني أن يكون لدي العديد من نوافذ VSCode اليوم ، خاصة بعد إضافة الأمر Switch Window : +1:

بصفتي مطورًا للإضافات_ لدي بعض الإضافات التي تستند إلى سياق المشروع _ ، مثل context.workspaceState ، activationEvents/workspaceContains . وأيضًا مدير المشروع ، والذي بالمناسبة بدأت بالفعل في إعادة هيكلة الأجزاء الداخلية لدعم المجلدات المتعددة. أود أن أعرف كيف سيؤثر ذلك على الامتدادات

شكر

للإضافة إلى ما قلته أعلاه (https://github.com/Microsoft/vscode/issues/396#issuecomment-270326917) ، فأنا بالفعل أستخدم وحدات Git الفرعية ، لذلك عندما أعمل على حزمتي (الخاصة) ، من المنطقي تمامًا تجميعها ، ولكن نظرًا لأن جوليا لا تزال صغيرة إلى حد ما (بشكل نسبي) ، فغالبًا ما أحتاج إلى العمل على حزم أخرى إلى جانب حزمتي الخاصة. لا أشعر بوجود سبب مقنع لإضافة هذه الحزم الأخرى كوحدات فرعية (على الرغم من أنني أستطيع ذلك).

بشكل عام ، من أجل تطوير حزمة Julia ، أقوم بالتنقل باستمرار عبر الحزم ، لذا فإن وجود مجلدات متعددة للمشروع سيكون أمرًا رائعًا: +1:

ملاحظة: MS ، يرجى إيلاء المزيد من الاهتمام لجوليا ؛)

أبسط حالة استخدام: خدمات مصغرة

هاها. نعم saada 👍 لقد كانت الخدمات المصغرة هي التي أوصلتنا إلى VS Code. نحن نستخدم Azure Service Fabric وقد أنشأ شريكي الخدمات المصغرة الأولى في .NET و Rust. أنا أعمل على خدمات جوليا المصغرة. شريكي هو رجل VS وأحب VS Code for Rust. اقترح أن أحاول VS Code لجوليا. شكر!

saada بالتأكيد على الرادار. هل يمكنك الإجابة على هذه الأسئلة لمساعدتي في أن أكون أكثر هشاشة فيما يتعلق بالمتطلبات؟

1. هل تشترك خدماتك الصغيرة في مجلد رئيسي؟ لما و لما لا؟
2. هل يتم فصل كل خدمة مصغرة في مستودع git الخاص بها؟ لما و لما لا؟

1. هل يتم فصل كل خدمة مصغرة في مستودع git الخاص بها؟ لما و لما لا؟

waderyan أحد الأسباب المحتملة هو أن بعض منصات PaaS الشهيرة مثل Heroku تتطلب أن يكون كل تطبيق (خدمة مصغرة) في مستودع Git منفصل. أصبح Deploy-via-git-push استراتيجية شائعة.

waderyan لقد اشتركت في الفتحة غدًا وأتطلع إليها - ولكن على غرار حالات الاستخدام مثل هذه ، فإن حالاتنا متشابهة.

نحن مؤسسة كبيرة ، ولدينا سجل npm خاص ، وننشر الوحدات النمطية الخاصة بنا التي يتم مشاركتها داخل المنظمة. لدينا تطبيق تفاعل مع قاعدة بيانات العميل وهو تطبيق كبير يستهلك بعض الوحدات الشائعة (مثل libs المساعدة والمكونات المشتركة) وقاعدة كود الخادم التي تتكون من عدة وحدات أيضًا (تطبيق الخادم السريع ومكونات خدمة البيانات الخلفية التي يستهلكها طبقة الخدمة والخدمات الفعلية التي يتعرض لها العميل). يتضمن التطوير النشط ما لا يقل عن اثنين (طبقة العميل والخدمات) ولكن استكشاف الأخطاء وإصلاحها يمكن أن يتضمن بسهولة نصف دزينة من الوحدات النمطية.

حتى عند استخدام وحدات npm العامة ، من المفيد أحيانًا ربط كود المصدر الخاص به بشكل مباشر وفتح في مثيل VS Code منفصل لاستكشاف مشكلة صعبة ، أو حتى خطأ في وحدة نمطية تابعة لجهة خارجية ، ولكنه في الغالب هو رمزنا الخاص.

كل منها عبارة عن مستودعات بوابة منفصلة. لا توجد مشكلة في الاحتفاظ بها في نظام الملفات الخاص بي ضمن مجلد جذر واحد (سأفعل على أي حال). لكني أحتاج إلى وجود مثيل منفصل من VS Code مفتوح لكل واحد ، والتبديل للخلف وللأمام مؤلم لأنه لا يمكنك رؤية سوى اسم الملف - وليس اسم التطبيق نفسه. لا توجد طريقة لمعرفة التطبيق / الوحدة / المشروع المفتوح في أي نافذة بسهولة. يوفر اسم الملف نفسه القليل جدًا من المعلومات المفيدة في التمييز بين مثيلات VS Code المتعددة.

هناك مشكلة أخرى مفتوحة تتعلق بالسماح بأن تكون معلومات شريط العنوان قابلة للتكوين والتي علقت أيضًا عليها كثيرًا - ولا تزال دون حل. إذا كان من الممكن أن يكون اسم المجلد الجذر مسطحًا لليسار في شريط العنوان ، فإن مشكلة فتح عدة مشاريع ستكون مشكلة أقل بكثير ، لأنني على الأقل يمكنني رؤية المثيل المفتوح الذي كان موجودًا داخل Windows عند تبديل المهام. يبدو هذا وكأنه يجب أن يكون تافهًا حقًا لجعله قابلاً للتكوين وسيخفف على الأقل من ألم عدم القدرة على فتح عدة مستودعات git في حالة واحدة أثناء اكتشاف ذلك ...

waderyan

1. تتم إدارة مشاريع الويب الخاصة بي بواسطة مجلد أصل واحد. تم إعداده بهذه الطريقة للتنظيم ، وروابط سريعة لمجلدات المستودعات الخاصة بي. أفعل هذا أيضًا ، لأنه من السهل بالنسبة لي التبديل إلى مشروع سابق / حالي لسحب عينات من التعليمات البرمجية عندما يتم إعادة استخدامها. على عكس فتح نافذة أخرى ، من الأسهل فتح علامة تبويب أخرى وتوفير وقت أكثر في حالتي.

2. يحتوي كل مشروع ويب على تكامل git الخاص به ، ولكن بالنسبة لي شخصيًا ، لا أطلب دمج .git في محرر التعليمات البرمجية الخاص بي. إنه خيار جيد بالنسبة لي ، لكنه ليس شرطًا. لديهم تكامل git الخاص بهم بسبب الرغبة في الاحتفاظ بكل مشروع ويب منفصلًا في مضيف الريبو الخاص بي.

nickmakjamietrepesho شكرا لتقاسم أفكارك. هذا مفيد وأنا أتطلع إلى الدردشة مع العديد منكم غدًا.

alefragnani أركز على سيناريو المستخدم النهائي. لقد تعاملنا مع هذه المشكلة بحذر بسبب تأثيرها على الإضافات. سوف نتعامل بحذر ونبلغ عن أي تغييرات في واجهة برمجة التطبيقات. اتصل بي على Twitter إذا كنت تريد ويمكننا القفز على مكالمة لمناقشة المزيد.

حتى برنامج notepad ++ يدعم مجلدات متعددة. هذا هو السبب في عدم ترك برنامج notepad ++.
يحتاج العمل في هذا اليوم مع جافا سكريبت إلى فتح مشاريع متعددة.

أقوم بعمل برنامج مضمّن وعادة ما يكون هناك عدد قليل من المجلدات التي أعمل بها عبر النظام. على سبيل المثال رمز التطبيق ومكتبة البائع ورمز نظام التشغيل.

أود إضافة حالة الاستخدام الخاصة بي هنا لمجلدات متعددة في نفس النافذة.

أنا مطور ألعاب ، وبالنسبة للعبتنا الحالية ، قمنا بتنفيذ دعم التعديل. تحتوي لعبتنا على مشاريع عميل وخادم وخادم رئيسي. أثناء تحرير ملفات التعديل ، من الشائع أن تعمل فقط في مستوى تعديل اللعبة (بدلاً من ما نسميه المستوى الأساسي أو المستوى الأصلي لرمز اللعبة الفعلي. على سبيل المثال ، العمل فقط في ملفات Lua بدلاً من ملفات C ++ و C # للخادم و العميل على التوالي). غالبًا لا يمكن وضع المجلدات داخل مجلد رئيسي مشترك.

في حالة الاستخدام هذه ، عند العمل فقط داخل ملفات التعديل ، استخدمنا في الماضي وظيفة Sublime متعددة المجلدات لإنشاء عرض مشروع لمجلدات تعديل المستوى الأعلى فقط من العميل والخادم. هذا يسمح لنا بتجنب الملفات الأصلية (C # و C ++) وتعديل ملفات Lua بسرعة عبر هذين المشروعين المرتبطين ببعضهما البعض.

سيسمح لنا الحصول على دعم متعدد المجلدات في VSCode بالقيام بنفس الشيء وتسهيل اعتمادنا لـ VSCode (الذي نحبه كثيرًا).

ماذا جاء من المكالمة التي عقدت الأسبوع الماضي؟ أنا على نظام Mac ولا يبدو أنه يمكنني فتح مثيلات متعددة من VSCode ، والتي اعتقدت أنها ستكون حلاً.

شكر!

تلقيت مكالمة الأسبوع الماضي مع Wade ، من الواضح ومن العدل أن هذا لم يكن
أولوية مبكرة ، لقد أنشأوا محررًا جيدًا حقًا ، ونأمل الآن
يقومون بتوسيعه لتلبية احتياجات المطورين المختلفة. فريق التطوير
الاستماع ، وأنا أتطلع إلى رؤية كيف يفعلون ذلك

يوم الأحد ، 15 يناير 2017 الساعة 21:20 الآن قريبًا ، [email protected]
كتب:

ماذا جاء من المكالمة التي عقدت الأسبوع الماضي؟ أنا على ماك ولا أستطيع أن أبدو
لفتح مثيلات متعددة من 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

rsyringcalloncampbell أنا لا أعرف ما أقوم به خطأ ولكن باستخدام code -n أستطيع فتح عن العديد من حالات المحرر كما أريد.

إذا فهمت بشكل صحيح ، فسيتم التحقيق في هذا الأمر ضمن خطة التكرار لشهر فبراير على أنها "تحقيق أولي في تنفيذ مساحات عمل" متعددة الجذور "، ومساحات عمل" متعددة المجلدات " :)

+1 ...
أليس هذا ممكنًا مع الإصدار القديم من VSCode أم أنني كنت أستخدم Sublime فقط؟ نسيت ...
لكن سهل جدا.
الآن أصبح جهاز Mac الخاص بي مليئًا بـ 6 نوافذ في كل مكان ...

ولا ، لن أفتح المجلد الجذر لجميع تلك المجلدات الستة التي فتحتها ، لأن المستكشف عبارة عن تمرير عمودي وسيستغرق الأمر مني إلى الأبد لتصفح الملفات ...

edmundtfy هذا ممكن في سامية. لم يكن Visual Studio Code يدعم هذه الوظيفة مطلقًا.

@ min20 حل مثالي فقط !!! مشروع متعدد المجلدات ، فإنه سيتم بدلاً من ذلك إدارة نوافذ متعددة عبر الأزرار

DeeJaVu مع الأخذ في الاعتبار أن ... VSCode لديه تلميح أدوات الماوس والتحكم + انقر للانتقال إلى التعريف. لقد قمت بتنزيل بعض الامتدادات لـ Sublime ولكن تمرير الماوس والتحكم + النقر فوق الأشياء لا يعملان كذلك .. أي توصيات؟

أفتقد هذا حقًا بعد استخدام Sublime لسنوات. أعمل الآن مع Intershop (كواجهة أمامية) بمئات الآلاف من الملفات لكل بطاقة. إذا اضطررت إلى تحميل متجر ويب كامل ، فسيكون الأمر بطيئًا حقًا عندما تريد فتح CTRL + P للتبديل بسرعة إلى ملف أو عندما يتعين عليك البحث.

أيضا ، أنا ببساطة لا أريد كل مجلد من المشروع في المحرر الخاص بي. لست بحاجة إلى كل شيء كمطور للواجهة الأمامية. فقط المجلدات التي أحتاجها كافية.

مثال آخر: إنشاء موقع Wordpress وإضافاته في نفس الوقت. لماذا أحتاج إلى تضمين موقع Wordpress كامل؟ إنه فقط يبطئ من كفاءتك.

مشكلة أخرى لدينا: إطار عمل الواجهة الأمامية الخاص بنا مقسم إلى مستودعات git مختلفة. وجود أكثر من 4 نوافذ مفتوحة هو ألم حقيقي. و SCSS intellisense لا يعمل بعد ذلك (IE. variables from core> package)

TLDR ؛ VScode غير قابل للاستخدام للمشاريع الكبيرة / الضخمة

+1 ، دعنا نتخيل أنك تطور ووردبريس أو دروبال مع عدة وحدات مخصصة.

جذر مشروعك هو جذر موقع الويب الخاص بك ، لكنك لا تريد أن يكون موقع الويب الكامل بمثابة ريبو ، فأنت تريد فقط العديد من الوحدات أو السمات الخاصة بك كمستقل لكلٍ منها.

حالة استخدام شائعة جدًا في تطوير الويب يجب تغطيتها ، حتى من خلال IDE الأصغر / الأخف.

+1

+1 ، تجعلني قادرًا على تحرير مشروع والعمل على وحداته الفرعية بسلاسة

+1

إنها المشكلة الوحيدة التي تمنعنا من ترحيل فريق التطوير المكون من 32 شخصًا بالكامل إلى VS.

تطوير الخدمات الصغيرة ليس مجديًا ، إنه مؤلم.

+1

+1 ، مفيدة بالتأكيد ، أقرر الانتقال إلى vscode من سامية ، ولكن بسبب هذه الميزة مفقودة ، أعتقد أنني سأظل أستخدم سامية حتى يوم واحد ..

إنها ميزة ضرورية للغاية وأساسية. لا أصدق كيف تجاهلها مطورو هذا المحرر الرائع. لا فائدة منه بدون هذه الميزة. هذا يمنعني من التبديل إلى VSCode من Atom.

الرجاء إضافة هذه الميزة. بعد استخدام Sublime ثم Atom ، هذه ميزة ضرورية للمحرر. بالطبع ليس الأمر بهذه السهولة بسبب تكامل git ، لكنه شيء أحتاجه في المحرر المفضل لدي.

+1

+1 حاجة ملحة

+1 كما قيل من قبل ، للانتقال من Atom إلى VSCode ، نحتاج حقًا إلى هذه الميزة.

الانتباه قبل التعليق
* من فضلك !!!! وقف التعليق باستخدام "+1"

كل تعليق عديم الفائدة يصرف انتباه أكثر من مائة شخص فقط بهذا الموضوع !!!
إذا كنت ترغب في دعم هذه الميزة - لديها عاطفة في الرسالة الأولى!
إذا كنت ترغب في الاشتراك في التحديثات - لهذا هو زر "اشتراك" على يمين المواضيع
احترم الأعضاء الآخرين ، الذين يجبرون على قراءة "+1" ، "مطلوب حقًا" ، إلخ

كمرجع ، الطريقة التي يرتب بها Sublime Text (كمثال) مشاريعه هي "بما في ذلك" شجرات المجلدات ، مع خيارات فريدة لكل "مجلد" مضمن في مشروعك.

لتصور هذا ، يبدو JSON لملف مشروع نص Sublime كما يلي:

{
    "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 كمشروع (وهو ما يشبه اقتراح فتح محرك الأقراص الثابتة بالكامل كمشروع ، لأنني سأتمكن من فتح جميع الملفات بعد ذلك).

رائع ، لقد قمت بإلغاء تثبيت atom لتجربة VS ، ولم تتم إضافة هذه الميزة منذ عام 2015.

افتتح stoffeastrom هذه القضية في 21 نوفمبر 2015

هذا محبط. :خائب الامل:

ملاحظة: فتح المجلد الرئيسي ، ليس حلاً تمامًا لأنه يفتح جميع الملفات غير المرغوب فيها أيضًا ، متغلبًا على الغرض الكامل من هذه البطاقة.

هذا محبط بالفعل. ولكن مرة أخرى ليس محبطًا مثل الأشخاص الذين ما زالوا يشتكون من محرر مدهش ومجاني ومفتوح المصدر (والذي يضيف باستمرار عددًا قليلاً من الميزات الجديدة _ كل شهر_). وليس محبطًا مثل إرسال رسائل غير مرغوب فيها إلى كل شخص يشاهد هذا الموضوع بتعليقات حول اكتئاب المرء.

_{(الآن أنا أحد مرسلي البريد العشوائي ، أعتقد: ابتسامة :)}

تحديث: الخطة الحالية هي النظر في هذا في تكرارات مارس / أبريل.

راجع https://github.com/Microsoft/vscode/issues/21923 للتعرف على خطة التكرار لشهر مارس:

التحقيق في عدة الجذر، متعدد مجلد مساحات # 396bpaseroTyriar

+1

لمشاركة مثال من العالم الحقيقي يعمل على تحسين وصف الميزة: مثال ، WordPress Theme / Plugin dev.

في برامج التحرير الأخرى ، قمت بإعداد العديد من المجلدات كـ "إشارات مرجعية" ، للوصول إلى شجرة ملفات كبيرة ومعقدة إلى حد ما بحيث يسهل إدارتها قليلاً. أحدهما هو webroot ، وهو الجذر الذي أفضله لبدء أي وظيفة تصحيح أخطاء وإكمال التعليمات البرمجية (البيئة). الثاني هو المشروع الفعلي ، مجلد سمة أو مجلد ملحق والذي ، في سير العمل الخاص بي ، هو جذر التحكم في الإصدار. من حين لآخر ، أقوم بإعداد مجلدات إضافية كمرجع ، مثل سمة رئيسية ، أو سمة قالب ، أو مكون إضافي أقوم بدمجه وأحتاج إلى الرجوع إليه / قراءته بشكل متكرر.

إذن ، مجموعة الميزات هنا هي ، 1. القدرة على تعيين جذر git وجذر البحث في مواقع مختلفة. 2. نظام إشارات مرجعية للمجلد يكون مرئيًا بحتًا لإزالة الفوضى في لوحة شجرة الملفات.

بالنسبة للبعض في الخيط ، حيث يكون جذر git وجذر المشروع هو نفسه ، يبدو أن تعلم واستخدام الوحدات الفرعية سيكون كافيًا ، وبعد ذلك يكون حوالي 2. للحصول على عرض لطيف أقل تشوشًا لمجلد متداخل.

أنا متأكد من أن البعض في سلسلة الرسائل يطلبون في الواقع دعمًا حرفيًا متعدد المشاريع ، لكنني أفترض أن معظمهم يطلبون فقط فكرة إنشاء إشارات مرجعية أبسط للمجلد.

بالإضافة إلى ذلك ، أطلب طريقة لتعريف أحدهما كجذر مشروع (بحث / تصحيح أخطاء) والآخر كجذر git. (لا تتردد في تجاهل التسمية السيئة للأشياء.)

الحل الخاص بي لهذا هو ببساطة إنشاء مجلد أصل وداخل إنشاء روابط رمزية مع جميع المشاريع التي أريدها.
_e.g._

لدي هذه المشاريع

1. my-app-api
2. التطبيق الخاص بي

أقوم بإنشاء مجلد يسمى _my-app-all_ (الاسم غير ذي صلة هنا) وداخله ، أقوم بإنشاء رابطين رمزيين يشيران إلى my-app-api و my-app-client ثم في VSCode ، أحتاج فقط إلى فتح تطبيقي- الكل

خطوات

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

ملاحظات:
لن يعمل تكامل git

DannyFeliz يجب وضع علامة على هذا كإجابة لهذه المشكلة ونشرها في الأعلى ليراها الجميع ... لقد اختبرت هذا على Windows أيضًا ، باستخدام أمر MKLINK.
مثال على الاستخدام:

1. افتح موجه الأوامر بامتيازات المسؤول
2. انتقل إلى مجلد المشروع الخاص بك
   3. [اختياري] أنشئ مجلد روابط
3. استخدم MKLINK / D "link_name" "مسار المجلد الذي تريد الرجوع إليه"

عند فتح المشروع برمز VS ، سترى المجلد المشار إليه وجميع الملفات / المجلدات الموجودة فيه.

سعداء يا شباب!

هذا لا يمكّن تكامل Git من العمل.

يوم الاثنين ، 20 مارس 2017 الساعة 2:42 مساءً ، poparazvandragos [email protected]
كتب:

DannyFeliz https://github.com/DannyFeliz يجب وضع علامة على هذا كملف
الإجابة على هذه المشكلة ونشرها في أعلى الصفحة ليراها الجميع ... لقد اختبرت
هذا على نظام Windows أيضًا ، باستخدام أمر MKLINK.
مثال على الاستخدام:

1. افتح موجه الأوامر بامتيازات المسؤول
2. انتقل إلى مجلد المشروع الخاص بك
   3. [اختياري] أنشئ مجلد روابط
3. استخدم MKLINK / D "link_name" "مسار المجلد الذي تريد الرجوع إليه"

عند فتح المشروع في رمز VS ، سترى المجلد المشار إليه
وجميع الملفات / المجلدات الموجودة فيه.

سعداء يا شباب!

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/396#issuecomment-287907310 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ABEOBVKz2bqFsRdfvyOpcFW2e_26HV5bks5rnvLWgaJpZM4Gm3nX
.

ehartford لقد قلت إجابة ، وليس الإجابة ، لأن معظمنا كان يبحث فقط عن هذا الشيء بالضبط ، ويعرض العديد من الدلائل في نفس نافذة VSCode ، الموجودة في مواقع مختلفة.
الروابط الرمزية تفعل ذلك بالضبط ، ولكن عند العمل على Windows ، ليس هذا هو الحل الذي يتبادر إلى الذهن.
كان لا بد من مرور عامين ولكي يأتي مطور Linux / OSX ويظهر لنا أبسط حل بديل.
أنا سعيد لأنني قررت أخيرًا أن أسقط تعليقي على هذه المشكلة لأنني حصلت على حل بديل لما أردت
بعد 12 يومًا فقط ، عندما كنت في أمس الحاجة إليها.

لا ينبغي إسقاط المشكلة ، حيث يمكن عمل الكثير إذا اختار المطورون التدخل في الأمر.
لكن بالنسبة لمعظمنا هذا مرض. كنت أقترح فقط نقل هذا إلى الأعلى بطريقة ما ، حتى لا يضيع الناس الوقت في قراءة جميع التعليقات الأخرى ، حتى يصلوا إلى هذا التعليق. قد يتغاضى البعض عنها بسبب حجم الخيط.

سأقوم بتحرير هذا فقط لأنني أرى الناس يقفزون بالفعل على ظهري لأنني اكتشفت كيفية تحقيق ما أريد وحاولت أن أجعل من السهل على الآخرين رؤية بديل حتى لو لم يكن مثاليًا. راجع للشغل: يمكنك دائمًا استخدام موجه الأوامر المدمج في VSCode لسحب / تنفيذ / دفع الملفات في مجلدات مرتبطة فردية ولكن لماذا تستقر على الحلول البديلة.

بدون تكامل Git ، إنه غير ناجح تمامًا. لا أعتبر هذا حلاً مقبولاً بأي حال من الأحوال. نتطلع إلى حل حقيقي. تحياتي الحارة.

إذا كان يساعد - يتم تنظيم عميل google appengine nodejs على النحو التالي:

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

أحب أن أكون قادرًا على فتح / تصحيح / العمل في حل مثل هذا (حتى لو كانت حزمة واحدة في كل مرة). أرغب في أن أكون قادرًا على كتابة مشاريع / libs تستند إلى Typescript بهذا الأسلوب.

شكرا لجميع العمل العظيم!

أحب VSCode ، لكنه هراء في التعامل مع مشاريع متعددة. لكن يمكنني أن أفهم سبب تأجيل الميزة ، لأنها تجعل أشياء متعددة مثل التحكم في المصدر أكثر تعقيدًا بسبب التداخل وما إلى ذلك.

يسعدني وجود ميزة "التبديل السريع للمشروع" أو القدرة على "جدولة" مثيلات vscode المتعددة في نافذة واحدة.

موافق تمامًا ، يرجى دعم فتح مجلدات متعددة للمشروع في نفس النافذة. هذه الوظيفة مهمة جدا.

replete إنه ليس حلاً مثاليًا لمشكلتك. لكن جرّب مدير المشروع ، فهذا يساعدني جزئيًا الآن.

dariusrosendahl نعم ، اكتشف هذا الصباح بشكل مضحك بما فيه الكفاية! يقوم بالعمل في الوقت الحالي.

يحتوي الشريط الجانبي على 5 رموز فقط ، ولن يتطلب الأمر الكثير لإضافة شريط جانبي "مشروع". ولكن يبدو أن مالكي منتجات vscode متحمسون للغاية بشأن الحد الأدنى من ذلك. الحد الأدنى من IMO لأنه أصبح الآن IDE.

replete سعيد لمعرفة أنه مفيد

في الواقع ، يوجد في _experimental API_ لإنشاء ما يسمى _Tree Explorer Contribution_ (تمامًا مثل لوحة Symbols - https://github.com/Microsoft/vscode/issues/15485). مع ذلك ، يمكن أن يضيف الامتداد رمزًا إلى شريط النشاط.

سأضيف مشكلة إلى التمديد الخاص بي مع اقتراحك ، شكرًا 👍

+1

تضمين التغريدة

أنا شخصياً لا أهتم إذا انتهى الأمر بهذه الميزة في المنتج أم لا - أفهم لماذا يريدها بعض الناس ، لكنني أود أن أشير إلى أنها تجعل كل شيء أكثر تعقيدًا.

ثم ربما لا تهيمن على المحادثة بالتعليقات السلبية ضد الميزة وحول كيف أن VSC ليس IDE؟ أعتقد أن الرد الفردي / التصويت السلبي كافٍ ، أو في أسوأ الأحوال اثنين ، إذا احتاج المرء إلى توضيح موقف أكثر.

إلى جانب ذلك ، فإن حجة "ليس IDE" هي موضع نقاش. تسمح أيضًا غيرها من غير IDE بذلك.

على سبيل المثال: عند البحث باستخدام تعبير regex - ما مساحة العمل التي أبحث عنها؟ واحد؟ الكل؟

ليست مشكلة كبيرة. إما أن تقوم بالبحث في الكل ، أو أن يكون لديك محدد لتوسيع نطاق البحث إلى إحدى مساحات العمل المفتوحة. مرة أخرى ، تتعامل "غير IDEs" الأخرى (بالإضافة إلى IDEs) بالفعل مع هذه الحالات (وغيرها).

لقد أصلحت هذه المشكلة في الإعداد الخاص بي عن طريق إنشاء مسار لكل "مساحة عمل" والربط الرمزي بالمشاريع التي أريد رؤيتها في مساحة العمل المذكورة.

رأيت ذلك

التحقيق الأولي في مساحات العمل متعددة الجذور والمجلدات # 396 @ bpaseroTyriar

يتم وفقًا لـ https://github.com/Microsoft/vscode/issues/21923 أي تحديثات على هذا؟ :)

لقد أجرينا (مجموعة فرعية من الفريق) تحقيقًا أوليًا في حجم العمل المتضمن والتحديات التي نراها والخطوات التالية هي مناقشة نتيجة ذلك مع الفريق والتخطيط لذلك. نخطط لإصدار أبريل خلال هذا الأسبوع ، لذا أتوقع المزيد من عناصر الخطة الدقيقة نتيجة لعرض هذا العمل قريبًا.

إذا لم أتأخر عن الحفلة ، فهذه طريقة لطيفة يمكن تنفيذها.
عندما تذهب إلى "Explorer" لدينا قسمان بالفعل. واحد للملفات المفتوحة والآخر لشجرة المستكشف للمجلد المفتوح الحالي.

من الناحية المثالية ، يمكننا فقط فتح المزيد من المجلدات في نفس النافذة وستتم إضافتها هنا في القسم الخاص بها والتي يمكن توسيعها لرؤية شجرة المستكشف.

يمكن عمل نفس الشيء لقسم التحكم في المصدر. قسم فرعي واحد لكل مجلد يتم فتحه في "المستكشف". إذن علاقة 1to1.

بهذه الطريقة يمكننا أن نجعل الجميع سعداء. لدينا دعم لفتح مجلدات متعددة في نفس النافذة إذا أردنا ذلك ، كما أن تكامل GIT لا يزال يعمل ويمكنه التعامل مع كل "جذر مشروع" بشكل منفصل.

فتح أكثر من مشروع في نفس النافذة إنها ميزة مهمة بالنسبة لي أيضًا. عادةً ما أقوم بفتح مشاريع لنسخ بعض التطبيقات الأساسية. أنا فقط أقوم بتثبيت Visual Studio Code وسأعود إلى Atom لهذا السبب

+1 أريد إظهار قيمة VSCode للمطورين الآخرين ، لكن عدم القدرة على فتح مجلدين في نفس النافذة يعد بمثابة كسر للصفقات. آمل أن يحصل هذا على أولوية أعلى.

جمعية البناء الخيرية:

حتى الآن لا تظهر كلمة "monorepo" في هذا الموضوع

يقوم monorepo الخاص بي بتركيز اهتمامات التهيئة بين الجذور المتعددة ، حيث يتم تمييز كل منها بملف ".root" في المجلد الذي يحتوي عليها.

ليس كل جذر عبارة عن مستودع git خارجي ، لكنها تسمح بتجاوز جزئي للتكوين العام.

نقطة الألم الرئيسية هي أن البحث عن الملفات و / أو الرموز لا يعطي الأولوية لمحتوى جذوري

أعتقد أنه يمكن تقسيم المطلب إلى 4 متطلبات منفصلة ، والتي قد تكون مرتبطة أو لا ترتبط ببعضها البعض (وربما يتم تنفيذها بشكل مستقل):

• دعم مجلدات متعددة في المستكشف
• دعم مجلدات متعددة في البحث
• دعم مجلدات متعددة في التحكم بالمصادر
• دعم مجلدات متعددة في التصحيح

مما رأيته في هذا الموضوع ، يمكن أن يؤدي فصلها إلى دعم مجموعة أكبر من السيناريوهات. بالطبع يجب أن يكون هناك بعض المجلدات "الرئيسية" ، مما يؤثر على كيفية استمرار المجلدات المكونة / المحددة.

لا أفهم لماذا تتحدث معظم التعليقات عن حلول المستكشف متعدد الجذر أو متعدد المجلدات. في الواقع أعتقد أنه من السيئ حقًا محاولة تنفيذه بطريقة IDE. يضيف تعقيدًا ويؤثر بالتأكيد على الأداء (وقت التحميل ، تحديث البوابة ...).

أعتقد أن هذه الميزة مهمة جدًا ، فالحاجة في الأساس هي الحصول على صورة مرئية حول جميع المشاريع ذات الصلة والتبديل بين نوافذ المشاريع بسرعة!

لدينا خياران:

• التنفيذ في نافذة واحدة : من
• قم بتطبيق آلية تبديل مرئية واحتفظ بنافذة واحدة لكل مشروع : هذا هو الخيار الأكثر أمانًا والأكثر ملاءمة بتكلفة أقل! نشر @ min20 صورة مرئية عن أزرار تبديل

آمل أن تهبط هذه الميزة ، ولكن ليس كحلول متعددة الجذور! إحدى الفوائد الرئيسية للمحرر الصغير هي البساطة والسرعة ، muti-root != simplicity & speed

يجب أن أختلف معك تمامًا @ g13013 هل رأيت تنفيذ Sublime؟ إنه بسيط للغاية ولا يزال أسرع بكثير من Visual Studio Code. حتى مع تمكين جميع ملحقات GIT.

نحن لا نتحدث عن استخدام مشاريع متعددة في محرر واحد. نحن نتحدث فقط عن استخدام مجلدات المشروع الذي تحتاجه.

أنا أعمل في متاجر Intershop على سبيل المثال. هناك الكثير الذي لست بحاجة إليه ، فقط الخراطيش التي يجب علي تعديلها. 80٪ من المجلدات والملفات عديمة الفائدة بالنسبة لي وتجعل المحرر أثقل كثيرًا (صدقني ، إنه يبطئ كثيرًا).

استخدام "Quick Open" في Visual Studio غير قابل للاستخدام أيضًا إذا كان هناك الكثير من الملفات المكررة. غالبًا ما تكون غير متأكد مما إذا كنت ستفتح الملف الصحيح ومرة ​​أخرى ، فإنه يتباطأ مع الكثير من الملفات.

أفهم ذلك ، ولكن بعد استخدام سامية وذرة في الماضي ، انتهيت أخيرًا إلى استنتاج مفاده أن أيًا منهم مع ميزة "muti-root" لم يحل أي شيء آخر غير استكشاف ملفات المشروع ، والتحدث عن شجرة مجلد سامية وسامية بطيئة جدًا في المشاريع الكبيرة وحتى حالات التجمد عند الاكتشاف ، لا تحتوي ميزة sublime على تكامل ميزات "git" و "debug" خارج الصندوق .... سيؤدي إدخال الجذر المعزز إلى تقديم الكثير من المشكلات المتعلقة بتكامل git ، والبحث بدون تأثيرات على الأداء ... حتى UX يتأثر ، مثل استكشاف مشكلات srcoll في المشاريع الكبيرة.

غريب بالنسبة لي هو عكس ذلك.

ربما يرجع السبب في ذلك إلى أن 99٪ من الوقت أقوم فقط بتضمين ما أحتاجه في Sublime أو Atom :) وهذا بالضبط ما نريده.

ربما تكون هذه هي الطريقة التي تستخدم بها المحرر فقط. أنا معتاد على استخدام CMD / CTR + P وكتابة الملف الذي أريده بالضبط. هذا مستحيل إذا كان عليك تضمين جذر مشروع مع الكثير من الملفات المكررة. (خراطيش / ملفات تركت هناك لمقارنة الأصل :)) أو شيء مثل ووردبريس حيث يوجد الكثير من الملفات بنفس الاسم.

مرحبا،
نعم ، فكرة المجلدات المتعددة جيدة دون كسر العديد من الأشياء. يمكن أن يكون كل مجلد إضافي قسمًا فرعيًا جديدًا ببادئة للإشارة إلى أنه غريب عن المجلد الأساسي. يستخدم الأساسي لتصحيح الأخطاء و Git. يمكن للمستخدم النقر بزر الماوس الأيمن فوق أي مجلد خارجي وجعله أساسيًا . ماذا تكسب:
1) القدرة على رؤية جميع المجلدات والملفات الخاصة بك وفتحها حسب الحاجة.
2) إعادة توجيه ما هو أساسي للعمل عليه.

الآن إذا أراد شخص ما فتح عدة مشاريع في وقت واحد ، فيجب أن يكون لديه طلب مشكلة جديد مفتوح. يضيف ذلك تعقيدًا كبيرًا حدده العديد من الأشخاص. الإضافات لا تعادل المكونات المضمنة. إذا كان هناك محرر يحتوي على ميزة مضمنة مطابقة ، فيجب الإشارة إليه حتى يتمكن المطورون الآخرون من فحص كيف يتناسب سير العمل مع هذه الميزة. شكرا لك. يوم جيد.

أضفني إلى قائمة المستخدمين الذين يعتبرون هذا هو العامل الوحيد الذي يمنعني من الانتقال إلى VSC. أجد التنفيذ الرائع للمشاريع على الفور. إذا كنت بحاجة إلى العمل على تطبيق "Volunteer Hours" على سبيل المثال ، فسأفتح المشروع الذي ملأته بمجلدات مختلفة (مجلد المشروع الرئيسي بالإضافة إلى مجلد آخر يحتوي على صور). هذا هو عملي لهذا المشروع. إذا كنت بحاجة إلى الانتقال إلى تطبيق "Exchange Calculator" ، فيمكنني تبديل مجموعة العمل بالكامل إلى هذا المشروع أو فتح نافذة جديدة بها هذا المشروع.
حالة استخدام أخرى هي عند استخدام CMS. إذا كنت أعمل على مكون إضافي لـ CMS ، فيمكنني الحصول على مشروع واحد للمكوِّن الإضافي وهو مستودع Git وآخر لنظام CMS بالكامل ، وهو ليس Gitified. يمكنني التقليب بين الاثنين حسب الحاجة وإبقاء مخاوف Git منفصلة.
يبدو VSC بمثابة المستقبل بالنسبة لي ، ولكن ليس بدون القدرة على الاحتفاظ بمجموعات عمل منفصلة من المجلدات.

مرحبا،
لقد رأيت فقط أن Sublime Text لديه دعم للمشاريع مع ملف مشروع . كيف يعادل ذلك ما يُطلب هنا؟ يبدو أنه طلب لـ vscode لدعم ملفات المشروع داخل مساحة العمل. كان هناك تعليق في وقت سابق على امتداد يمكنه التعامل مع الأمور في هذا الصدد لمدير المشروع .

أنا بصراحة أستخدم Atom أيضًا وأستخدم وظيفة المجلدات المتعددة (المضمنة) التي تسمح لي بفتح مجلدات التوثيق ومجلد مشروعي الحالي في نفس الوقت. يبدو حقًا مثل الفاكهة المعلقة السفلية لتمكين الأساسي ومجموعة من الثانوية. ربما يكون سهمًا بسيطًا أو يبدأ في الإشارة إلى الأساسي. شكرا لك. يوم جيد.

لما يستحق ، إليك حالة الاستخدام الخاصة بي. أعمل على لعبة مقسمة إلى ثلاثة مستودعات ؛ Git repo للمحرك ، وواحد hg repo لكود اللعبة + محتوى و hg واحد لرمز اللعبة العام على العديد من المشاريع. هناك أيضًا مستودع hg واحد لمكونات الشركة Sublime Text. الريبو العام هو إعادة فرعية للعبة الريبو.

في مكان عملي التالي ، أتوقع العمل مع العديد من المستودعات مرة أخرى.

من المريح جدًا أن يكون لديك كل هذه الأشياء في نفس نسخة المحرر ، وأعتقد أنه سيكون من المنطقي أن يحصل كل هؤلاء على SCM مناسب في VS Code.

أتوقع أن يبحث البحث في جميع المجلدات المعينة افتراضيًا. ستكون المكافأة الرائعة هي القدرة على تشغيل / إيقاف تشغيل المجلدات التي تبحث عنها مؤقتًا. (على سبيل المثال ، عندما أهتم فقط بالعثور على أشياء في محرك اللعبة)

هناك الكثير من الناس يقولون إن VS Code لا ينبغي أن يدعم هذا لأن أ) لا يحتاجون إليه و ب) VS Code هو محرر نصوص بسيط. السبب الأول ليس جيدًا - فهناك القليل من الميزات التي يستخدمها الجميع. السبب الثاني ... إن VS Code ليس مجرد محرر نصوص بسيط ، فهو يحتوي على تصحيح أخطاء ، SCM ، ملحقات. تحتوي "برامج تحرير النصوص البسيطة" الأخرى مثل Sublime على دعم مجلدات متعددة. وباعتباري شخصًا عازمًا على الأداء ، لا يمكنني رؤية كيف ستؤثر إضافة هذه الميزة على الأداء بأي طريقة ذات معنى ، خاصة للأشخاص الذين يستخدمون مجلدًا واحدًا فقط على أي حال. هل يمكننا من فضلك تركيز المناقشة على الكيفية التي نريد أن تعمل بها الميزة بدلاً من سبب عدم رغبتنا في ذلك.

Srekel هل يمكنك تضمين لقطة شاشة لكيفية عملك بهذه الطريقة في المحررين الحاليين؟ يبدو أنه مزيج من المجلدات والمشاريع باستخدام المكونات المدمجة والمكونات الإضافية. الناس ونأمل في هذا المخيم وبالكاد التغييرات إشعار لإدراج هذا النوع من الميزة. بالنسبة لأهل المخيم B ، فهم على حق. يمكنك القيام بالأشياء بسرعة مع التطبيق خارج الصندوق إذا لم تكن بحاجة إلى التعثر. ربما يساعد الاحتفاظ بالقرب من ذلك في الحصول على دورات تحديث سريعة وعناصر واجهة مرتبة.

تتضمن بعض الأشياء حول كيفية تحقيق ذلك ما يلي:

• فهم العلاقة بين النطاق والسياق والجلسة ووجهات النظر والحاضر .
• الحدود العليا (أكثر من 256 مجلدًا؟)
• المجالات المؤثرة الرئيسية (علامات تبويب المحرر ، الإعدادات ، scm ، git ، الامتدادات).
• تجاوز إعداد مساحة العمل أو التعارضات.

سيكون من الجيد أن تتحدث هنا عن بعض الأشياء التي يأخذها VSCode كأمر مسلم به في هذه المناطق التي تحتاج إلى تعويض. شكرا لك. يوم جيد.

+1

+1. لدي أكثر من 30 وحدة لكل منها مستودع git خاص به أود الوصول إليه والعمل عليه في بيئة واحدة. اعتقدت أن هذا ما يفعله معظم مطوري js / node. مع VSCode ، هذا مستحيل ، كسر صفقة بالنسبة لي للأسف.

+1

تم فتحه منذ عام 2015 ولم يتم إصلاحه بعد. إنها ببساطة الميزة الأكثر طلبًا في أي محرر ، ولكن للأسف لا توجد ميزة vscode لها.

+1

أنا دائمًا أخلط بين نافذة VS Code وأخرى عند استخدام علامات الجدولة.

كل محرر آخر أعرفه لديه هذا (Atom ، Sublime ، Brackets ...)

تعد إضافة رابط رمزي إلى مشروعي اختراقًا وسيتطلب مني تحديث .gitignore الخاص بي. يعد فتح الدليل الأصلي أمرًا مزعجًا لأنه بعد ذلك يتم غمر جزء ملفاتي بمشاريع أخرى لا أهتم بها.

تعرض خطة التكرار لشهر أبريل مهمة "التحقيق في مساحات عمل متعددة الجذور ومجلدات متعددة" كما فعلت. ما هي نتائج التحقيق؟
تضمين التغريدة

+1

آسف إذا كنت حريصة جدا. أنتم يا رفاق مشغولون بإصدار الكود الآن.

مرحبا،
يجب اعتبار مربع حوار فتح مجلد على أنه فتح مجلدات. لذلك إذا كنت ضمن مجلد أصلي معين ، يمكنني في مربع الحوار تحديد اثنين أو أكثر من مجلداته الفرعية لفتحها في نفس الوقت. سيكون ذلك إضافة مرحب بها مع دمج هذه الميزة. شكرا لك. يوم جيد.

+ واحد آخر

لم يسبق أن رأيت الكثير من التعليقات منخفضة الجهد في سلسلة رسائل GitHub من قبل ، خاصةً ما بعد الرموز التعبيرية. بشرني.

أنا حقا أحب هذه الميزة. كما قال شخص آخر بالفعل ، فإن العديد من المشاريع الحديثة معيارية ، على سبيل المثال الواجهة الأمامية في الريبو / المشروع والخلفية / واجهة برمجة التطبيقات في آخر. سترغب غالبًا في العمل عليها معًا كواحد.

هذا هو السبب الوحيد الذي يجعلني لم أتخلى عن Atom.

الخدمات المصغرة والمنصات التي لا تحتاج إلى خادم ، جنبًا إلى جنب مع شعار "مستودعات إعادة الشراء رخيصة" طويلة الأمد ، هي السبب في أن هذا أمر لا بد منه. ليس من غير المعتاد أن يكون لديك حوالي 30 مستودعات [صغيرة] مفتوحة وتعمل على ملفات من مشاريع متعددة في وقت واحد ؛ توقع قيام الأشخاص بالتبديل بين العديد من النوافذ ، أو إلغاء تحميل ترتيب عرض الملف إلى مدير نافذة بيئة سطح المكتب لن ينجح.

مرحبا،
كيف تدير 30 مستودعات الآن
هل تفعل هذا بسبب قيود أخرى في بيئتك؟ ربما لغة البرمجة ليس لديها حساسية؟ ربما يساعد الامتداد الذي يمكنه قراءة واجهة برمجة التطبيقات (API) لمنحك توقيعات وظيفية؟
تحتوي لغة مثل F # على ميزة تسمى موفري النوع ، يمكن لأحدهم فعل ذلك تمامًا وجعل برمجة الويب أسهل. هذا لا يقلل من حاجتك إلى مجلدات متعددة ، فقط لأنه ربما لا يزال لديك على الأقل عدد قليل من المشكلات الأخرى مع مساحة العمل النشطة الكبيرة هذه. شكرا لك. يوم جيد.

@ pr-yemibedu ، أعتقد أن ما يقوله martinjco هو أنه ليس لديه الملفات مفتوحة ولكن سيكون لديه إمكانية الوصول السريع إلى الريبو إذا كان لدينا بنية متعددة الجذور. تخيل ، فقط CMD + P لأي ملف تحتاجه ؛)

تكمن مشكلة الوضع الحالي في أنه يتعين علينا فتح الملفات أو التبديل على الأقل بين 30 نافذة مختلفة لأن VScode لا يدعمها.

لقد عدت بالفعل إلى Atom مؤخرًا بسبب الميزة المفقودة. أنا أعمل في مشروع مع 9 repo في الوقت الحالي. لن أرغب في فتح 9 أرامل VScode في نفس الوقت ، لكني أريد فقط استخدام اختصار للانتقال إلى الملف الذي أحتاجه.

أتفق مع التعليق بواسطةdariusrosendahl. أنا مبرمج مبتدئ ويجب أن أشير إلى مشروع قديم لكتابة مشاريع جديدة. آمل أن يتغير ذلك قريبًا ولكن في سامية يمكنني بسهولة الحصول على ثلاثة إلى أربعة مجلدات للمشروع ومقارنتها بفتحها في نفس الجلسة

إذا تمكنا من الحصول على ذلك في الاستوديو المرئي فسيكون ذلك رائعًا

مرحبا،
أوافق على النقاط التي تم إجراؤها حيث يمكنك رؤية مشاركاتي السابقة تفضل هذه الميزة. كان هناك بيان دقيق كنت أعلق عليه من قبل مارتينجكو:

ليس من غير المعتاد أن يكون لديك حوالي 30 مستودعات [صغيرة] مفتوحة وتعمل على ملفات من مشاريع متعددة في وقت واحد ؛

ما يُظهره nuno1895 هو كيف أستخدم Atom اليوم عندما أحتاج إلى العمل على مجلدات متعددة ولكن مشروع تركيز رئيسي بسيط. أنا في الواقع أستخدم كلاً من VS2015 و gedit و vim و notepad و notepad ++ للتطوير النشط. هناك نقاط قوة في كل منها لا مثيل لها حتى الآن في نظيراتها.

كنت أحاول فقط أن أفهم ما إذا كانت هناك نقطة أساسية يمكن توضيحها. نرغب جميعًا في الحصول على هذا العمل وتفضيله من قبل المطورين الذين سيقضون وقتًا في العمل عليه. لهذا السبب كنت أسأل كيف يتم التعامل مع هذا اليوم. من المحتمل ألا يكون 9 مقابل 30 قد أثار اهتمامي كثيرًا للرد ولكني أحب أن أعرف ما الذي يقارن الناس بـ vscode وما إذا كان الأمر يستحق حتى النظر إلى أداة أخرى.

لقد رأيت فقط Atom و SublimeText يتحدثان عنهما كأساس للمقارنة ولقطات شاشة مفيدة. نرحب بالمزيد من المناقشة والإبهام والتعليقات للحصول على هذا القبول والتنفيذ. شكرا لك. يوم جيد.

إحدى النقاط التي ربما لم يتم التأكيد عليها بشكل كافٍ هي القدرة على "التنقل" بسرعة بين مجموعات المجلدات (المشاريع). يطلق عليه "مشروع التبديل السريع" في Sublime. عند النقر فوق عنصر القائمة هذا ، تحصل على نافذة منبثقة تحتوي على قائمة بجميع مشاريعك ، وعندما تحدد أحد المشاريع ، يعرض المحرر المجلد (المجلدات) وجميع الملفات المفتوحة كما تركتها آخر مرة.
على سبيل المثال ، إذا كنت أعمل في مشروع أ وكان ملفي app.js و index.html مفتوحين ثم تحولت إلى Project B ، فسيتم إغلاق المشروع A وعرض المشروع B. إذا عدت بعد ذلك إلى Project A ، فسيتم أرني المجلد (المجلدات) و app.js و index.html كما تركتها (حتى التعديلات غير المحفوظة موجودة هناك).
إذا كنت بحاجة إلى فتح كلا المشروعين في نفس الوقت ، فيمكنني فقط فتح مثيلين من المحرر.
المفتاح هو أنني قادر على الاحتفاظ بكل أشيائي في دلاء منفصلة ويمكنني التبديل بينها بسرعة.

+1

مرحبا،
قرأت عن تلك الميزة. تبديل المشاريع دون تصفح في Sublime Text يشير إلى بعض

لقد بدأت في استخدام VSCode منذ بضعة أشهر ، وبشكل عام ، أنا راضٍ جدًا. سأضيف صوتي إلى الجوقة وأقول إن هذه الميزة المفقودة هي خدش الرأس الكبير بالنسبة لي. هل هناك _ أي _ محررين لائقين آخرين لديهم هذا القيد؟ على أي حال ، يجب إصلاحه. :)

هذا هو الإعداد في وظيفتي الجديدة:
ريبو واحد للتكنولوجيا الأساسية. قل المسار هو C: / mygamengine /
ريبو واحد لرمز اللعبة. تمت مزامنته مع C: / mygamengine / mygame
مستودع واحد لمحتوى اللعبة (القوام إلخ): C: / mygamengine / mygame_data

الثلاثة هم بوابة. لم يتم إعدادها كمستودعات فرعية ، بل تمت مزامنتها مع تلك المجلدات فقط.

على نحو مفضل ، أود فقط فتح المجلد الجذر في VS Code وجعله يكتشف تلقائيًا أنه في الأساس ثلاثة مشاريع مختلفة ، وأن الملفات الموجودة ضمن mygame تنتمي إلى مستودع git هذا وليس ذلك الموجود في mygameengine.

أرغب في أن أكون قادرًا على ضبط إعدادات مساحة العمل هذه التي تختلف لكل مستودع (على سبيل المثال ، قد أرغب في تشغيل linter على مشروع المحرك وليس على رمز اللعبة) سيكون من الجيد أيضًا أن يتم تعيين إعدادات مساحة العمل افتراضيًا على جميع المشاريع الثلاثة.

واو ، ما زال هذا لم يتم حله؟ كنت آمل في استبدال Atom بـ VS Code لأنه ، وفقًا للمراجعات ، أسرع بكثير ولا يتأخر كما يفعل Atom.
مشروعي الرئيسي هو اثنين من مستودعات Git ، أحدهما نهاية خلفية والآخر واجهة أمامية. محليًا كلاهما موجودان في نفس المجلد ولكن إذا فتح رمز Atom أو VS المجلد الأصلي ، فلن يتم التعرف على حالة Git.
في Atom ، أضفت كلا المجلدين إلى مساحة العمل الخاصة بي وأعمل فقط.

: Sparkles: Update: Sparkles:

لقد مر وقت طويل منذ آخر تحديث لدينا ، لذلك اعتقدت أنني سأقوم بإطلاع الجميع على السرعة. لقد حددت أنا و bpasero وبقية الفريق معظم المشكلات المتعلقة بتنفيذ الجذور المتعددة ويعملون حاليًا على بعض النماذج ويكتشفون المزيد من تفاصيل تجربة المستخدم.

لماذا يأخذ وقتا طويلا؟

يستغرق الأمر وقتًا طويلاً لأن هذه الميزة ليست مسؤوليتنا الوحيدة والعمل الذي ينطوي عليه تحقيق الجذور المتعددة ضخم جدًا. بالنسبة للمبتدئين ، تم تصميم جميع المكونات داخل VS Code على افتراض أنه لا يوجد سوى مجلد واحد أو لا يوجد مجلد مفتوح في أي وقت. عندما يكون لديك قاعدة بيانات كبيرة مثل قاعدتنا بافتراض مثل هذا ، فإن الأمر يتطلب الكثير من العمل لجعلها أكثر مرونة.

لإعطاء بعض الأمثلة ، إليك بعض أكبر نقاط الألم التي حددناها حتى الآن:

• يكشف الملحق API عن workspace.rootPath واحدًا ، وهذا غير كافٍ عندما نضيف دعمًا للمجلدات متعددة الجذر. نريد تجنب كسر هذه الامتدادات وتوفير مسار الترحيل إذا لزم الأمر.
• تختلف الطريقة التي تتفاعل بها إعدادات مساحة العمل في عالم متعدد الجذور قليلاً. خذ workbench.statusBar.visible على سبيل المثال المسموح به حاليًا في إعدادات مساحة العمل. لن نتمكن بعد الآن من دعم هذا لأنه سيؤدي إلى سلوك غريب / عربات التي تجرها الدواب إذا تم تحديده في مجلدين. نحن بصدد اكتشاف كيفية التعامل مع هذه الأنواع من الحالات.
• ربما يحتاج موفر SCM (git) إلى أكبر قدر من عمل UX من أجل دعم مجلدات متعددة: هل نحتاج إلى تقديم مفهوم "مشروع نشط"؟ هل يجب تعيينه صراحة (انقر بزر الماوس الأيمن فوق المجلد وقم بتعيينه) أم يجب أن يكون ضمنيًا (بالنظر إلى مجلد الملف النشط)؟ هل يجب أن يكون مفهومًا عالميًا أم مقصورًا على تلك الميزة المحددة؟ إلخ

لا نريد التسرع في حل غير مدروس جيدًا ، لذا فنحن نأخذ وقتنا ونفكر حقًا في المشكلات والآثار المحتملة مع كيفية تأثير ذلك على كل مكون. سيأتي عندما يكون جاهزًا.

ملخص التعليقات حتى الآن

لقد أمضيت للتو بضع ساعات في استعراض الخيط الهائل لجمع التعليقات حتى الآن. كان من الصعب بعض الشيء تصنيف بعض هذه الأشياء ، ولكن هذا ما كان يسعى إليه الناس بشكل عام (أنا أعيد الصياغة).

• أريد تكامل git عبر مجلدات متعددة
• يعد التبديل الحالي للمجلد و / أو إدارة نافذة نظام التشغيل UX مرهقًا
• أريد البحث عبر مجلدات متعددة
• أريد التصحيح عبر مجلدات متعددة

اهتمامات

• هل تعمل عمليات إعادة البناء عبر المشاريع أم في مشروع واحد؟
• ما المشروع الذي ألتزم به على Git؟
• في أي مجلد (مجلدات) سيتم تشغيل بحثي؟
• لا تكسر إعدادات مساحة العمل
• لا تكسر الامتدادات - حذر مطوري الإضافات من واجهة برمجة التطبيقات الجديدة
• لا تكفي تجربة المستخدم المبوبة بنمط Slack ، فهذا في الأساس مجرد نقل إدارة النوافذ من نظام التشغيل إلى VS Code - أريد أن أكون قادرًا على الوصول إلى جميع الملفات من المشاريع في نافذة واحدة (أي مجموعة من مجموعات المحررين)
• "من وجهة نظري ، فإنه يقدم العديد من الاهتمامات الأخرى ، وجذور مشاريع متعددة لـ git ، والبحث ..... هذا سيء جدًا لتجربة المستخدم ومن المحتمل أن يعرض الأخطاء والتعقيد للمحرر."

تعليقات أخرى

• أريد فقط فتح مجموعة فرعية من المستودعات في "مجلد git"
• أريد طريقة رائعة للبحث في مجلد واحد أو تنظيم نتائج البحث حسب المشروع
• أريد أن أكون قادرًا على الانتقال إلى رمز التبعية للقراءة بسرعة
• أريد تشغيل إصدارات مختلفة من TypeScript لمجلدات مختلفة
• VS Code بطيء جدًا مع عمليات إعادة الشراء العملاقة
• أريد أن أبقي بعض المشاريع مفتوحة دائمًا لاستخدامها كمرجع (على سبيل المثال ، موضوع / قالب)
• أريد أن يتعرف رمز VS على ملفات .vscode / settings.json في أي دليل (قد يساعد هذا في الحل البديل)
• اسمحوا لي أن أحدد جذر المشروع (بحث / تصحيح) وجذر git
• يتعامل Sublime مع تكامل git متعدد المجلدات بأناقة
• المجلدات المبوبة مشابهة لواجهة مستخدم Slack (على سبيل المثال ، بعض نماذج المشاريع النشطة)
• قسم منفصل في المستكشف لكل مجلد
• استخدم مجلدًا كمجلد أساسي والباقي كمجلدات مرتبطة / فرعية
• أريد مشروع التبديل السريع كما هو الحال في سامية (التبديل السريع + الاحتفاظ بتخطيط مساحة العمل)
• هذا النمط من إدارة مساحة العمل مفيد بشكل خاص لما يلي: وحدة npm ، جوليا ، heroku PaaS ، ووردبريس ، دروبال

الحلول الحالية

فيما يلي الحلول الرئيسية حاليًا:

• فتح أحد الوالدين المشتركين
• مدير مشروع جيت
• مدير المشروع
• الارتباط الرمزي للمجلدات كأدلة فرعية "للمجلد الرئيسي"

متى تعلق؟

الرجاء تجنب: +1: أو تعليق "أريد هذا". عند إبداء تعليق على هذه المشكلة ، يتم إخطار 153 شخصًا وعدد الأشخاص الذين علقوا على هذه المشكلة بالإضافة إلى العديد من الأشخاص الذين قاموا بالضغط على زر الاشتراك. سيؤدي التعليق أيضًا إلى دفن تحديثات الفريق ، لذا حاول أن تضع ذلك في اعتبارك. بكل الوسائل ، قم بالتعليق إذا كان يضيف إلى المحادثة.

الميزة التي قد يكون لها استخدام أكثر من وجود جذور متعددة هي إضافة القدرة على الحصول على مجموعات عمل قابلة للتكوين. سيمكنك هذا من فتح أحد الوالدين المشتركين ، ولكن لديك العديد من مجموعات المجلدات داخل هذا المشروع.

بشكل عام ، سيكون هذا مفيدًا لأي مشروع لأنه قادر على "التركيز" على ملفات / مجلدات معينة في وقت واحد في قواعد أكواد أكبر دون الحاجة إلى تغيير التكوين للجذر بالكامل في كل مرة.

لا توجد خطة حول هذه الميزة؟

يمكنك رؤية خطة هذه الميزة في تعليق Tyriar وفي الروابط ذات الصلة:
https://github.com/alefragnani/vscode-project-manager/issues/46
https://github.com/Microsoft/vscode/issues/26068

نود أن نشارك تصميماتنا لهذا والحصول على ملاحظاتك. للقيام بذلك ، سنقوم بإعداد عدد من المكالمات الجماعية حيث سنتعرف على تصميماتنا ونناقش ردود أفعالك على التصميمات.

إذا كنت ترغب في المشاركة في هذه المناقشات ومساعدتنا في الحصول على التصميم الصحيح ، فيرجى الاتصال بي (أرسل لي بريدًا إلكترونيًا - stevencl at microsoft dot com) وسأقوم بإعدادها.

نأمل في تحديد موعد هذه المناقشات ليوم الخميس 1 يونيو والجمعة 2 يونيو.

stevenclTyriar شكرا يا رفاق! : تصفيق:

شكرا للجميع على حضور الجلسات اليوم. تم نشر تسجيلات الجلسات هنا

• المجموعة 1 - https://youtu.be/48Y6tB3DN1g
• المجموعة 2 - https://youtu.be/kHL6Rt-dLm0

يرجى مشاهدة مقاطع الفيديو ومشاركة أي تعليقات إضافية لديك على التصميمات.

stevencl شكرًا على إجراء الدراسات وإتاحتها!

فيديوهات رائعة ، شكرا! بعض الملاحظات:

• 👍👍👍 للتصميم البسيط الشامل والتمديد الطبيعي لكيفية عمل VSCode اليوم. تعاملتم مع العديد من المواقف المعقدة بطريقة بسيطة وأنيقة. مجد لذلك!
• يعجبني إخطار SCM المجمع في الزاوية اليسرى السفلية ، ولا حاجة إلى تغيير من وجهة نظري باستثناء واحد: لقد تخطيت النافذة المنبثقة بعد النقر فوق إشعار SCM والانتقال مباشرة إلى لوحة SCM. نقرات أقل = أفضل دائمًا بالنسبة لي.
• جذور الترميز اللوني مثل اقتراح أليكسي فكرة مثيرة للاهتمام ، يمكن أن تساعد.
• البحث: سيكون تحديد النطاق لمجلد مهمًا بالنسبة لي ، أعتقد أن حقل "الملفات المراد تضمينها" الحالي يمكن استخدامه لذلك على ما يرام ، فقط أردت التأكد.
• الشيء الوحيد الذي لست متأكدًا منه هو المثابرة وفتح كل additionalFolders عندما أفتح path . من المنطقي نوعًا ما مع المثال الأخير حيث من الواضح أن express-project هو "المشروع الرئيسي" ولكني لست متأكدًا من المثال السابق: شعرت express و express-plugin بالتساوي ، مثل الأشقاء الحقيقيين ، ولست متأكدًا من أنني أتوقع فتح express سيفتح أيضًا express-plugin .
  
  
  
  • بطريقة ما ، يبدو أن بنية البيانات وراء ذلك يجب أن تكون مجرد قائمة مسطحة من المسارات ، وليس "مسارًا" واحدًا ثم "مجلدات إضافية".
  
  
  • لست متأكدًا مما إذا كان مفهوم مسار رئيسي واحد مفيدًا. في مشاريعي ، ربما لا يكون الأمر كذلك.
  
  
  • لفتح مساحة عمل متعددة الجذر ، أتوقع أمرًا من المستوى الأعلى مثل _File> Open workspace_ إلى جانب _File الحالي> Open folder_.
  
  
  • بشكل عام ، لست متأكدًا جدًا من هذا. آسف ليس لدي المزيد من الاقتراحات الملموسة.
  
  

شكرًا مرة أخرى ، بهذا ، سيكتسب VSCode قوى خارقة جديدة 😄.

شكرا لتقاسم الفيديو. أرغب في دعم تصميم "قسم واحد لكل مجلد جذر":

في البداية ، كنت أتوقع تصميمًا آخر (يشبه النص الرائع) ، ولكن بعد رؤية البديل "قسم واحد لكل مجلد جذر" ، أصبح من الواضح لي أن هذا الأسلوب يتمتع بالمزايا التالية:

• تمييز وفصل واضح لا لبس فيه بين المجلدات (خاصة إذا كان لدي أكثر من 2 أو 3 منها ، وهو ما يحدث غالبًا عندما أستخدم المحررين و IDEs الآخرين)
• يفرض فكرة أن المجلد الجذر هو مشروع منفصل (فرعي)
• وصول سريع إلى أوامر المشروع الفرعي (مثل "ملف جديد" ، "تحديث" ... وربما في المستقبل ، النقر بزر الماوس الأيمن لبدء مهمة (مثل "إعادة البناء") في هذا المشروع الفرعي المحدد ؛))
• كما ذكرت المجموعة الثانية ، مع هذا التصميم ، من غير المحتمل أن يكون لديك مشكلة اقتطاع اسم المجلد

فيما يتعلق بمفهوم "قسم واحد لكل مجلد جذر" ... لست متأكدًا من أن هذا سيعمل بشكل جيد بالنسبة لي ومعظم حالات الاستخدام الخاصة بي. كلما كان لدي موقف متعدد الجذور ، من الشائع أن لدي الكثير ؛ ليس فقط 2 أو 3.
لست متأكدًا من كيفية توسيع نطاق هذا النهج؟

هناك أيضًا بعض الحجج المتعلقة بالتخطيط الشبيه بالمجلد الحالي وهو أنه يتوافق مع كيفية عرض monorepo. على سبيل المثال ، قارن:

monorepo/      <- contains .git
  project1
  project2

ضد.

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

يجب التعامل مع هذين النوعين بشكل مشابه تمامًا بواسطة VSCode: monorepo بالفعل (الالتزام: طبيعي ، بحث: "الملفات المراد تضمينها" ، READMEs المتعددة: يتم عرض مجلدهم في علامة تبويب المحرر ؛ إلخ). يجب أن تتبع الجذور المتعددة هذا بأكبر قدر ممكن ، 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 ، الساعة 6:47 صباحًا ، كتب Peter Petrov [email protected] :

أفضل تصميم "قسم واحد لكل مجلد جذر" لنفس الأسباب التي ذكرهاmaddouri. بالإضافة إلى ذلك ، بعد استخدام البديل الآخر (في Atom) ، من الصعب بصريًا العثور على مكان بدء مجلد جذر جديد عند فتح مجلدات متعددة ذات تسلسل هرمي عالي وتوسيعها.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بكتم صوت الموضوع.

أو يمكننا اتباع نهج Sublime ، Atom ، ولكن نغير اللون أو نظهر بطريقة ما المجلد الذي هو الجذر و / أو نلصقه في الأعلى. بالطبع كلا الطريقتين جيدتان ، لكن وجود الكثير من المجلدات المفتوحة يقلل المساحة ، لأن الشريط مع التحديث ، وإنشاء ملف جديد ، وما إلى ذلك سيكون مرئيًا ، ولهذا السبب من الأفضل عدم تحميل الشريط ، ولكن بطريقة ما تظهر المجلد الذي الجذر. ولكن مرة أخرى ، هذا الشريط جيد حقًا ، لأنه من الأسهل بكثير رؤية مجلدات الجذر المفتوحة ويمكنك تحديثها والقيام بأشياء أخرى مضمنة في الشريط. نحتاج أن نرى كيف يبدو مع على سبيل المثال 10 مجلدات مفتوحة مع وبدون شريط.

stevencl شكرا لك على نشر تلك التسجيلات! بشكل عام ، أنا متحمس للاتجاه الذي تتجه إليه الميزة! شكرًا لك على كل الوقت والجهد الذي بذلته حتى الآن. ها هي ملاحظاتي / أفكاري:

• أفضل التصميم الأول مع تصميم شريط اسم المجلد الفردي ضمن "EXPLORER" ، ومع ذلك ، أشعر بالقلق من أنه إذا تم إدراج جميع أسماء المجلدات هناك ، فسيتم اقتطاعها بسرعة كبيرة لعرض "إضافة ملف" ، " إضافة مجلد "، إلخ ، الأزرار. أعتقد أنني سأضع السلسلة "متعدد" أو شيء مشابه عندما يكون أكثر من مجلد مفتوح ؛ بخلاف ذلك ، هناك مجلد واحد فقط ، لذا ضع اسم المجلد هناك كما هو الحال اليوم (وإخفاء جذر المجلد في الشجرة).
• إن توضيح أسماء الملفات عن طريق إلحاق اسم المجلد في عنوان علامة التبويب في المحرر ، IMO ، ليس ضروريًا ما لم يكن هناك عدة برامج تحرير مفتوحة بنفس اسم الملف. لاحظ أن هذا السيناريو ليس نادرًا حتى مع فتح مجلد واحد. من السهل جدًا الحصول على ملفات متعددة (مثل .gitignore ) بنفس الاسم بين المجلدات الفرعية داخل نفس الجذر. لذلك يجب أن يكون هذا التصميم (إلحاق اسم المجلد الأصلي) ميزة منفصلة ، IMO ، ويجب تنفيذه. إلى جانب هذا ، أود أن أرى حلاً جيدًا لـ https://github.com/Microsoft/vscode/issues/15048 لأن هذا سيجعل بعض عناوين علامات التبويب أطول. :)
• بالنسبة لنتائج البحث ، أعتقد أنه من الضروري أن يعمل البحث عبر جميع مجلدات الجذر. يمكن إضافة عامل تصفية آخر لقصر البحث على الجذور المختارة. عند عرض النتائج ، قد يكون من المفيد رؤية النتائج لكل جذر ، لذلك ربما يكون هناك خيار لرؤية قائمة طويلة واحدة مع أسماء مجلد جذر ملحقة ، أو لرؤية قائمة منفصلة في أقسام ، واحدة لكل مجلد جذر.
• أجد أنه من الغريب أنك تقترح إضافة "مساحات عمل" إلى __إعدادات المستخدم__. كنت أتوقع حقًا أن ينتهي هذا الأمر في __إعدادات مساحة العمل__. أعتقد أنك تقول في الواقع أن إعدادات مساحة العمل يمكن أن تحتوي أيضًا على خاصية "مساحات العمل" الجديدة ، وهذا أمر جيد. من الجيد أيضًا أن تكون مسارات مساحة العمل نسبية. لا يبدو أنه شيء ينتمي على الإطلاق إلى إعدادات المستخدم. إنها ميزة تبدو خاصة جدًا بمساحات العمل. آه ، لكنني الآن أرى سبب صلاحيتها أيضًا في إعدادات المستخدم ، لأنها توفر لي طريقة لتخزين مساحات العمل هذه عندما أريد مجلدات "عشوائية" على محرك الأقراص الثابتة في مساحة عمل واحدة حيث لا يوجد جذر مشترك.
• أحد الأشياء التي يبدو أنها تضيع في مساحات العمل عند تخزينها في إعدادات المستخدم هو القدرة على إحالة الإعدادات الأخرى الخاصة بالمشروع إلى مساحة عمل واحدة أو أخرى. على سبيل المثال ، إذا كانت لدي مساحة عمل حيث كنت بحاجة إلى أن يكون حجم علامة التبويب مسافتين وأخرى حيث يجب أن يكون 3 ، فلن أتمكن من القيام بذلك باستخدام مساحات العمل في إعدادات المستخدم. سأضطر إلى إنشاء مجلد في مكان ما ، ثم وضع مجلد .vscode بداخله ، ثم تحديد .vscode/settings.json أجل تحديد مساحة العمل الخاصة بي أخيرًا مع تجاوز حجم علامة التبويب المناسب. في هذه المرحلة ، أعتقد أن إنشاء نوع ملف مشروع VSCode جديد يخزن كل هذه الإعدادات ويمكن فتحه كملف خاص يصبح أقل تعقيدًا من الاضطرار إلى إنشاء هذا التسلسل الهرمي للمجلدات لتخزين مساحة العمل settings.json ملف

في التصميم الأول ، بالنسبة للمجلدات الإضافية ، يمكن إلحاق المسار (النسبي أو المطلق) الموجود بين قوسين باسم التمايز. سيكون هذا حلاً بسيطًا على ما أعتقد.

stevencl شكرا لتسجيل الجلسات. أردت حقًا المشاركة لكن لم يكن متاحًا في ذلك الوقت 😢

أعجبتني واجهة SCM المقترحة. يمنحني وجود قسم ملخص وقسم واحد لكل مجلد ، IMHO ، واجهة أسهل بكثير لاكتشاف التغييرات والعمل معها. وأحب فكرة أن يكون لديك سلوك ثابت في واجهة المستخدم بأكملها ، لذلك يجب استخدام فكرة قسم واحد لكل مجلد في علامة التبويب " بحث" أيضًا ، بدلاً من ربط اسم المجلد في كل نتيجة. الشيء نفسه بالنسبة لعلامة التبويب Explorer .

يعد استخدام إعدادات المستخدم لتخزين _Multi-Folder_ أمرًا غريبًا بعض الشيء بالنسبة لي ، لأنه _ لا يبدو أنه إعداد مستخدم _: ابتسامة :. إذا كان القصد هو تجنب إنشاء ملفات جديدة وتسهيل نقل / مزامنة المشاريع / مساحات العمل بين أجهزة الكمبيوتر ، فلماذا لا تنسى _ إعدادات المستخدم _ وجعل إدخال additionalFolder _ دائمًا_ جزءًا من 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 خيارات للحد من مجلد جذر معين (أو عدة

maddouriTurkeyManpesho،dgileadistefcameron يبدو واضحا أن بعض الناس يفضلون شجرة واحدة والبعض يفضل مقاطع متعددة في المستكشف. لذلك قد ينتهي بنا الأمر بإعداد لهذا ، فهناك إيجابيات وسلبيات لكلا الحلين ويجب أن يعود الأمر للمستخدم أيهما أفضل للسيناريو.

ستتغير طريقة تطبيق الإعدادات update.channel: none على أساس كل مجلد. ما يتعين علينا القيام به هو تحديد الإعدادات التي يمكننا دعمها على مستوى المجلد (على سبيل المثال files.exclude ، جميع إعدادات المحرر) وإجراء التغييرات اللازمة لتمكينها. هذا هو أحد مجالات العمل الرئيسية التي يتعين علينا الاستثمار فيها ، خاصة وأن الإضافات يمكنها أيضًا تحديد الإعدادات التي نريد دعمها في نطاق كل مجلد.

BTMorton يبدو لي أنك تريد طرقًا أسهل لتبديل مساحات العمل. هذا شيء يجب أن ننظر فيه بشكل مستقل عن الجذور المتعددة لأي عملية نقل مجلد يمكن للمستخدم القيام به.

stefcameron سنبقي إعداد additionalFolders مفتوحًا بما يكفي لإضافة بيانات تعريف إضافية إليه في النهاية. على سبيل المثال ، يمكنني التفكير في القدرة على توفير اسم لمثل هذا التكوين بحيث يتم التبديل بين المشاريع بالاسم وليس المجلد الرئيسي.

أحد الأشياء التي لم نتطرق إليها بعد في مقاطع الفيديو هو كيف يمكن أن تدعم الإضافات المجلدات متعددة الجذر. هدف أساسي آخر مع دعم متعدد الجذور (إلى جانب "الحفاظ على البساطة") هو: عدم كسر الامتدادات

اليوم ، تحتوي الإضافات على واجهة برمجة تطبيقات بسيطة للوصول إلى مساحة العمل المفتوحة حاليًا ( workspace.rootPath: string ). يمكن أن تكون هذه الخاصية null في حالة عدم فتح مجلد.

الآن ، مع إدخال إعداد additionalFolders ، لا يزال بإمكان الامتداد الاعتماد على الخاصية workspace.rootPath التي يتم تعيينها (إذا تم فتح مجلد) ، أو لا (عند عدم فتح مجلد). نظرًا لأن additionalFolders هو في الواقع إعداد ، فإن الإضافة مجانية للقراءة وحتى الكتابة إلى هذا الإعداد مع واجهات برمجة التطبيقات التي لدينا اليوم حول الإعدادات بالفعل. حتى أن هناك حدثًا ينبعث عند تغيير هذا الإعداد ، مما يسمح برد فعل ديناميكي للمستخدم الذي يغير هذا الإعداد.

تتيح قراءة هذا الإعداد جعل الامتداد على علم بالمجلدات الإضافية في مساحة العمل. على سبيل المثال ، يمكن أن يختار امتداد Travis CI إظهار حالة مجمعة عبر جميع المجلدات.

تتيح كتابة هذا الإعداد بعض السيناريوهات المثيرة للاهتمام للإضافات: على سبيل المثال ، يمكن أن يكون لديك ملحق مدير المشروع الذي يضيف ويزيل بشكل ديناميكي المجلدات إلى مساحة العمل الخاصة بك وعلى هذا النحو يسمح بانتقالات المشروع داخل النافذة ، على سبيل المثال عن طريق إظهار قائمة المشاريع عبر منتقي UI .

في مرحلة ما ، من المحتمل أن نقدم بعض واجهة برمجة تطبيقات الامتداد الجديدة الحقيقية للتعامل مع المجلدات متعددة الجذر. إن دفن هذا داخل إعداد لتمديدات القراءة / الكتابة أمر غريب بعض الشيء. ولكن بادئ ذي بدء ، يمكن للإضافات بالفعل استكشاف الإعداد additionalFolders للاستفادة منه إن أمكن. سنعمل أيضًا بشكل وثيق مع مؤلفي الإضافات لفهم سيناريوهاتهم وكيفية دعمهم بشكل أفضل.

bpasero هل

felixfbecker هذا شيء لا يزال يتعين علينا استثماره واستكشافه لإيجاد حل جيد لملحقات اللغة. بمجرد أن نفكر في واجهات برمجة التطبيقات الإضافية للإضافات ، نحتاج أيضًا إلى التفكير فيما يعنيه هذا لـ LSP.

من الجدير بالذكر أنه يمكن أن يكون لديك اليوم مواقف حيث يفتح المستخدمون ملفًا من مجلد لم يتم فتحه كمساحة عمل (على سبيل المثال ملف> فتح> somefile.xyz). من الناحية المثالية ، يمكن أن يُظهر امتداد اللغة نفس المستوى من ميزات اللغة لمثل هذا الملف حتى إذا لم يتم فتح مجلد هذا الملف.

في البداية ، سيكون فتح ملف من أحد additionalFolders مشابهًا جدًا لفتح ملف غير موجود في المجلد الذي فتحته في البداية. يمكن أن يتعامل TypeScript على سبيل المثال جيدًا مع هذه الحالة: فهم يتقدمون فقط من الملف المفتوح حاليًا حتى يتم العثور على ملف tsconfig.json ثم يتعاملون مع هذا كمشروع. ميزات مثل البحث عن مراجع تعمل بدون مشاكل:

سيكون من الجيد أن يعمل أي امتداد للغة بمجرد الانتقال من الملف النشط حاليًا بدلاً من فرض سياق مشروع واضح.

bpasero شكرا على التعليقات. لذلك يبدو أنه في النموذج الحالي ، سيكون هناك دائمًا مجلد "رئيسي" : حتى في المثال allMyRandomProjects ، هذا هو المجلد الرئيسي بشكل أساسي ، على الرغم من أن معظمه فارغ. هذا له بعض الآثار الدقيقة ولكني سأحتاج إلى التفكير في الأمر أكثر لتقديم ملاحظات مفيدة.

بشكل عام ، أعتقد أن VSCode يجب أن تدعم monorepo مقابل مستودعات متعددة بطريقة مشابهة جدًا ، وفقًا للتعليق أعلاه: https://github.com/Microsoft/vscode/issues/396#issuecomment -306040485.

راجع للشغل ، كيف تعرف "الجذر" بالضبط؟ إذا فتحت المجلد A الذي يحتوي على المجلدات الفرعية B و C ، فما مدى اختلافه عن تحديد A كـ path و B و C كـ additionalFolders ؟ هل نية VSCode معالجة هاتين الحالتين بشكل مختلف إلى حد ما أو نفس الشيء بشكل أساسي؟ (أعتقد أنه يجب أن تكون تجربة مشابهة جدًا).

تضمين التغريدة

في البداية ، سيؤدي فتح ملف من أحد المجلدات الإضافية إلى سلوك مشابه جدًا لفتح ملف غير موجود في المجلد الذي فتحته في البداية. يمكن أن يتعامل 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 على أي مستوى من مستويات التسلسل الهرمي للمجلدات بمجرد حل التحديات التي تصاحب ذلك.

أود أن أتحدث أقل عن علاقة التفاصيل الرئيسية عند الحديث عن الجذور المتعددة لأن معظم UX سيعامل المجلد الرئيسي على قدم المساواة مع المجلدات الإضافية. المجلد الرئيسي هو في الحقيقة مجرد حاوية لإعدادات المجلدات الإضافية وسيكون المحرك الرئيسي لإعدادات مساحة العمل العامة. للتوافق مع الإصدارات السابقة ، سيكون أيضًا هو الذي نرسله إلى الامتدادات كـ rootPath .

felixfbecker هل هذا يعني أنه لا يمكنني عمل "بحث عن مراجع" أو ميزات لغة مشابهة عند فتح ملف PHP واحد فقط من مشروعي ، فأنا بحاجة إلى فتح هذا المجلد للحصول على هذه الميزات؟ لست عميقًا في PHP ، ولكن إذا كان هناك مفهوم للتبعيات عبر الملفات ، فلن أتمكن من الانتقال إلى ملف PHP آخر من ملف واحد فقط ، فأنا بحاجة إلى فتح المجلد أولاً؟

saborrie ، لن نضيف إعداد مساحة عمل افتراضيًا عند إضافة مجلدات. أحد الأسباب التي دفعتنا إلى وضع هذا في إعدادات المستخدم هو أن مساحة العمل لا تصبح "قذرة" مع الإعداد متعدد الجذر. من الممكن وضع هذا الإعداد في مساحة العمل ، لكنك ستحتاج إلى القيام بذلك يدويًا. لن يحدث بشكل افتراضي.

bpasero حسنًا ، إن التمسك

هذا يترك لي سؤالين للمتابعة:

1) ماذا سيحدث عندما يفتح المستخدم مساحة عمل مع تعريف additionalFolders في إعدادات مساحة العمل الخاصة به؟ هل ستتم مزامنة هذا مع إعدادات المستخدم الخاصة بهم؟ وهل سيتجاوز الإدخال الخاص بجذر مساحة العمل هذا إذا كان موجودًا في قائمة مساحة عمل إعدادات المستخدم؟ أو العكس؟

2) هل يعد وضع قائمة مساحات العمل هذه في إعدادات المستخدم خيارًا أفضل من تجنب تخزين مساحات العمل في البداية في أي من ملفات إعدادات JSON هذه؟ في نظام المجلد الفردي الحالي ، عند إعادة فتح مجلد من عنصر القائمة File > Open Recent ، يتم تذكر علامات التبويب التي تم فتحها سابقًا - بقدر ما يمكنني معرفة أن هذا لم يتم تخزينه في أي مستخدم -ملف إعدادات قابل للتعديل ، ألا يمكن تخزين المسارات الإضافية بنفس الطريقة ، حتى يحفظها المستخدم بشكل صريح؟

- آسف للغة الإنجليزية ، لقد استخدمت مترجم Google -

حسنًا ، لقد تجاوزت التصميم ، (نعم - صعوبة بسيطة في فهم اللغة الإنجليزية). آسف إذن ...

لم يعجبني التصميم الذي قدمه maddouri ، ويرجع ذلك أساسًا إلى المشكلات الموجودة في هذا العدد (# 25352 ، # 25354). أعتقد أنه سيكون أكثر تعقيدًا حتى إذا كان عليك استخدام لوحة المفاتيح للوصول إلى المجلدات الموجودة في النموذج المعروض.

أفضل هذا النموذج ، والذي من خلال الفكرة يمكنني التنقل بين مجلدات المشروع المختلفة باستخدام مفاتيح الأسهم وإذا كنت بحاجة إلى إنشاء مجلد / ملف في المجلد الرئيسي ، فيمكنني استخدام مفتاح القائمة على لوحة المفاتيح ، مباشرة مجلد.

و / أو مع خيارات الملف الجديد ، تحديث المجلد الجديد وطي الكل.

أما بالنسبة للعنوان الذي يظهر في الأعلى ، فأفضل أن يركز على الملف الحالي مع المجلد الموجود فيه ، أو بدلاً من إظهار جميع المجلدات الرئيسية المفتوحة بالإضافة إلى الملف الحالي ، على غرار هذه الصورة.

وسؤال: هل ستظل Open Editores موجودة؟

تضمين التغريدة

هل يعني ذلك أنه لا يمكنني عمل "بحث عن مراجع" أو ميزات لغة مشابهة عند فتح ملف PHP واحد فقط لمشروعي ، فأنا بحاجة إلى فتح هذا المجلد للحصول على هذه الميزات؟ لست عميقًا في PHP ، ولكن إذا كان هناك مفهوم للتبعيات عبر الملفات ، فلن أتمكن من الانتقال إلى ملف PHP آخر من ملف واحد فقط ، فأنا بحاجة إلى فتح المجلد أولاً؟

هذا صحيح ، إذا فتحت ملفًا واحدًا فقط ، فلا يمكنك الانتقال إلى تعريف ملف في ملف مختلف غير مفتوح ، ولكن فقط لمن هم أقل من rootUri . هذا لأنه في PHP يمكن لكل ملف تفريغ الرموز في مساحة الاسم العالمية ، ومساحات الأسماء هي في الحقيقة مجرد بادئات أسماء للفئات. لا توجد قيود على كيفية توافق مساحات الأسماء وأسماء الفئات مع الدلائل وأسماء الملفات (فقط بعض الاصطلاحات) ، ولا توجد عبارات استيراد مثل TS ، فقط الأسماء المستعارة لمساحة الأسماء. يتم تحميل الفئات في وقت التشغيل من خلال "برامج التحميل التلقائي" المسجلة. هذا يعني أنه بالنسبة لخادم اللغة عند الانتقال إلى التعريف ، يمكن تحديد رمز في أي ملف. لذلك سيقوم خادم اللغة بفهرسة جميع الملفات في rootUri عند بدء التشغيل ثم العمل مع الفهرس للإجابة على الطلبات. ما ينجح هو إذا كان لديك مشروع مفتوح ، وقمت بإنشاء ملف جديد غير محفوظ - ستحصل على معلومات عن ذلك ، لأنك حصلت على rootUri والملف الجديد من خلال textDocument/didOpen . ولكن لن يتم النظر في أي رموز محددة في الملفات غير المفتوحة التي لا تقل عن rootUri .

تتجاوز إعدادات مساحة العمل saborrie إعدادات المستخدم ، كما كانت من قبل. الإعداد additionalFolders داخل مساحة العمل هو الأسبقية دائمًا. نظرًا لطبيعة هذا الإعداد ، يمكنك فقط تجاوز المجلدات الإضافية للمجلد المفتوح حاليًا عندما يتم تحديد هذا الإعداد داخل مساحة العمل (يظهر هذا في مقاطع الفيديو من خلال وجود path: "." لـ "الرئيسي").

إن تخزين هذه الحالة كواجهة مستخدم بشكل مشابه ، على سبيل المثال ، عدد علامات التبويب المفتوحة كان خيارًا ناقشناه ولكننا لم نجد أنه يحتوي على الكثير من المزايا مقارنة بالإعداد. بعض الأسباب:

• هذا غير قابل للمشاركة (لا عبر إعداد مساحة العمل ولا عبر امتداد مزامنة الإعدادات)
• هذا ليس شيئًا يمكن للإضافات الوصول إليه اليوم بسهولة (توجد واجهة برمجة تطبيقات الإعدادات ، ولا توجد واجهة برمجة تطبيقات لحالة واجهة المستخدم)

هل هناك سبب معين لعدم رغبتك في ذلك داخل الإعدادات؟

Tekbr نعم ،

felixfbecker هل يستطيع امتداد PHP اعتماد شيء مثل rootUri: string[] بسهولة؟ أو هل تفضل أن يبدأ خادم لغة PHP عدة مرات لكل مجلد مفتوح (على سبيل المثال ، سيكون VS Code متعدد plex على مستوى المجلدات المفتوحة لخوادم اللغة N؟)

bpasero PHP يمكن أن تعمل مع rootUris: string[] بسهولة تامة. قد لا تكون خوادم اللغات الأخرى على الرغم من ذلك. إن إنتاج خوادم متعددة اللغات يعني أن كل مجلد يعمل بشكل منفصل (لا يوجد انتقال سريع إلى التعريف ، والعثور على جميع المراجع فيما بينها). ربما يكون الأسلوب هو ServerCapability جديدًا يقرر ما إذا كان VS Code سينتج خوادم لغة واحدة أو متعددة.

يعجبني مفهوم إعداد المجلدات الإضافية. بالنسبة لي ، يكفي وجود مجلد جذر واحد. إذا كنت أريد وظائف التطوير الكاملة في مشروع مرتبط ، يمكنني فتح نافذة vscode جديدة.

ما أحتاجه من المجلدات الإضافية هو مجرد وظائف محدودة. على سبيل المثال ، قد أرغب في تعريف رمز من مشروع مرتبط لاستخدامه في المشروع الجذر ولكن لا أحتاج أو أريد القدرة على إعادة تسميته أو العثور على جميع المراجع الخاصة به في المجلد الإضافي.

bpasero أنا وقيد الاشتراك). بشكل أساسي بدلاً من تغيير الإعدادات تلقائيًا عندما يضيف المستخدم مجلدًا ، ابدأ به فقط في حالة واجهة المستخدم ، ثم السماح للمستخدمين بحفظ هذا في الإعدادات بطريقة ما. ربما يسمح أيضًا باختيار ما إذا كان ينتقل إلى إعدادات مساحة العمل أو في إعدادات المستخدم.

أنا لا أعارض تمامًا التخزين في الإعدادات تمامًا ، فأنا أفعل ما بوسعي للتشكيك في قرار عدم استخدام حالة واجهة المستخدم ، فقط في حالة التغاضي عنها.

bpaserosaborrie إذا ذهبنا إلى هذا الطريق ، فسأضيف ذلك عند مطالبتك بالحفظ في الإعدادات ، يجب أن يكون هناك خيار "تذكر خياري" (لحفظ مساحات العمل في الإعدادات ، إما إعدادات المستخدم أو إعدادات المشروع). سأشعر بخيبة أمل عند فتح نافذة VSCode ، وتحميل بعض المجلدات ، وجعلها تعمل بالطريقة التي أريدها ، ثم يحدث إما إعادة تشغيل أو تعطل ، وقد فقدت تهيئتي الكاملة لهذه المجموعة من المجلدات لأن مساحة العمل لم يتم حفظها مطلقًا إلى القرص.

# 396 (تعليق)

Tekbr نعم ،

شكرا على الرد ، bpasero.

TL ؛ DR: استخدم عرض الشجرة كلما كان ذلك منطقيًا بدلاً من إلحاق اسم الجذور بكل عنصر.

أشياء قليلة ، أنا لا أحب الطريقة التي تُلحق بها المجلد بالنهاية ، أود حقًا أن يكون خيارًا لأنني ربما أرغب في الحصول عليه مثل هذا express\.editorconfig و express-plugin\.editorconfig لذا ربما يمكنك عرض الخيار التالي: editor.tabName: "${root}\${filename}"

شيء آخر أود ذكره في الفيديو هو التلوين على الجذور لتتناسب مع علامات التبويب لذا so لهذا الغرض.

بحث:

في عرض 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 وليس كـ "Express Plugin".

2. يمكن أيضًا إجراء التنقل بين المهام باستخدام لوحة المفاتيح بطريقة تتجاهل تحديد الجذور ، لذا إذا انتقلت لأسفل من express\"Run Tests" في المثال ، فإن العنصر التالي الذي سيتم تحديده هو express-plugin\Compile مثل مقابل express-plugin

ملاحظة: لم أشاهد الفيديو كاملاً حتى الآن ولكن هذه مجرد أشياء خطرت على بالي.

ماذا لو كانت جميع مجلدات الجذر التي تقوم بتضمينها في مساحة العمل الخاصة بك تحمل الاسم نفسه؟
على سبيل المثال

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

سيكون لديك بعد ذلك مساحة عمل بها:

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

وفقًا لطريقة _sublime_ لتضمين المجلدات في مساحة العمل ، يحتوي كل جذر افتراضي للمجلد على:

• مسار
• الاسم (اختياري) - هذا هو اسم المجلد إذا تم استبعاده ، ولكن يمكن عرضه على أنه أي شيء
• عامل تصفية الاستبعاد للملفات / المجلدات

راجع الملاحظة https://github.com/Microsoft/vscode/issues/396#issuecomment -283541760 (أعلاه) على سبيل المثال البيانات الوصفية المرتبطة بهذه الطريقة في القيام بالأشياء.

أود أن أعرف أن هذه الميزة لا تزال في مرحلة التطوير؟

ifzm إنه كذلك ، وإذا قرأت أحدث ملاحظات إصدار (مايو 2017 (الإصدار 1.13)) ،

eyalsk آسف ، لم أنظر بعناية ، فهذه ميزة مثيرة: د

لست مجنونًا بمفهوم 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 أكثر تعقيدًا ، ولهذا اخترنا ضد هذا المفهوم. السبب الرئيسي هو أنه فجأة لا يوجد فقط "فتح ملف" و "فتح مجلد" ولكن أيضًا "فتح مشروع". البقاء مع الأوليات التي لدينا هو النهج الأكثر وضوحًا دون تقديم مفاهيم جديدة.

ومع ذلك ، فإن كل العمل الذي نقوم به الآن لدعم مجلدات متعددة هو عمل جيد أيضًا للسيناريوهات مثل تلك التي تقترحها. إذا أردنا في أي وقت دعم السيناريو الخاص بك ، فإن خطوات الوصول إلى هناك ستكون أقل ثقلاً لأن واجهة المستخدم مناسبة بالفعل لذلك. يمكنني أيضًا أن أتخيل أنه ربما يمكن أن يقدم الامتداد فكرة مساحات العمل هذه ونضيف فقط واجهات برمجة التطبيقات الضرورية لدعم ذلك.

دعنا أولاً نحصل على UX بشكل صحيح دون تقديم مفاهيم جديدة ثم نفكر في سيناريوهات أخرى حول المجلدات المتعددة. هناك الكثير من الأشياء التي يجب النظر إليها أولاً (الامتدادات ، الإعدادات ، واجهة مستخدم SCM ، إلخ).

الحل الذي تقترحه يجعل استخدام رمز VS أكثر تعقيدًا

لا بد لي من الاختلاف مع هذا. إذا كان المستخدم مرتبكًا من خلال ميزة "Open Project" (أو مساحة العمل) الاختيارية ، فمن المحتمل أن يتم الخلط بينه وبين العديد من الميزات الموجودة في VSCode. هذا ليس معقدًا من منظور المستخدم (إذا لم يوافق أي شخص يقرأ هذا ، يرجى ذكر ذلك).

يمكنني أيضًا أن أتخيل أنه ربما يمكن أن يقدم الامتداد فكرة مساحات العمل هذه ونضيف فقط واجهات برمجة التطبيقات الضرورية لدعم ذلك.

الامتداد موجود بالفعل ، وقد تم ذكره عدة مرات بالفعل. المؤلف لديه حتى دعم متعدد المجلدات لتعقب التذاكر المفتوحة . يحتوي هذا الامتداد على أكثر من 370 ألف عملية تثبيت ، وتقييم 4.7. حتى مع وجود واجهة مستخدم مبسطة تستخدم لوحة الأوامر ، هناك القليل من علامات الارتباك إذا حكمنا من خلال التعليقات.

دعنا أولاً نحصل على UX بشكل صحيح دون تقديم مفاهيم جديدة ثم نفكر في سيناريوهات أخرى حول المجلدات المتعددة

هدا يبدو عادلا. في كلتا الحالتين ، يتعلق الأمر بدعم مجلدات جذر متعددة في نفس النافذة - يمكن معالجة الطريقة الفعلية لإدارة مجموعات المجلدات هذه في مرحلة لاحقة.

هل تفكر في إنشاء استطلاع عام لجمع آراء المستخدمين حول هذا الموضوع (أنا على دراية بمقاطع فيديو YouTube ، لكنني أشير إلى هذا الجانب من تلقاء نفسه) ، أو هل تم اتخاذ القرار بالفعل بالتوافق مع additionalFolders مفهوم؟

أتفق مع @ glen-84. لا أفهم مشكلة التعقيد. نعم ، يمكن أن يجعل الأمر أكثر تعقيدًا ، لكن هذا محرر كود. أعتقد أن 95٪ من المبرمجين هم من يستخدمونه ، الذين يمكنهم بسهولة فهم فكرة المشاريع. يجب أن يكون هناك القليل من القلق بشأن إرباك الناس كل يوم لأن الناس لا يستخدمونها كل يوم.

بينما يعد الامتداد حلاً إلى حد ما ، فإن الامتدادات هي أيضًا معدل ثانٍ مقارنةً بالتحسينات التي تم تنفيذها محليًا (على سبيل المثال ، لا يمكن إضافة خيارات إلى القوائم ، فقط لوحة الأوامر ، إلخ).

@ glen-84 تم اتخاذ القرار بالانتقال إلى إعداد additionalFolders بناءً على المشاعر السائدة في فريق التطوير ، ودراسات المستخدم التي أجريناها (مقطعي الفيديو هذين) والتعليقات التي حصلنا عليها في هذه المشكلة.

pltrant فإنه يجعل استخدام الجذور المتعددة أكثر تعقيدًا لأنه يتعين عليك باستمرار التفكير في فتح مجلد أو فتح مشروع. قد تتطلب أشياء مثل "فتح حديثًا" مزيدًا من الاهتمام فجأة إذا كان الإدخال الذي تم اختياره عبارة عن مجلد أو مشروع ، أو الأسوأ من ذلك أنه سيكون لديك منتقيان وعليك تحديد أيهما تريد استخدامه.

لست متأكدًا من مدى تعقيد الإعداد. ليس عليك في الأساس أن تهتم بالإعداد ، ما عليك سوى إضافة المجلدات وإزالتها إلى الإعداد الخاص بك ويتم تحديث الإعداد في الخلفية. أود أن أزعم أنك لا تنظر أبدًا إلى قيمة هذا الإعداد في معظم الحالات.

@ glen-84 فيما يتعلق بمثالك عن مشروع يحتوي على 3 مجلدات بنفس الأهمية ، أعتقد أن أي واحد يجب أن يحتوي على إعدادات additionalFolders يجب تحديده على أساس التبعية. إذا كان مجلد API لا يعتمد على مشروع آخر ، عند فتحه ، يجب فتحه كمجلد واحد ويجب ألا يحتوي على أي إعدادات للمجلدات الإضافية. ولكن عند فتح مجلد الهاتف المحمول ، أعتقد أنه يحتوي على تبعية لمجلد API. لذلك ، يمكنك إضافة الإعدادات في مجلد المحمول لفتح API كمجلد إضافي عند فتحه في vscode. الشيء نفسه ينطبق على الموقع. إذا كان يعتمد على api ، أضف الإعدادات هناك. إذا لم يكن كذلك ، فلا حاجة إلى إعدادات.

لا أعتقد أنه سيكون هناك فتح مجلد إضافي متكرر أو متتالي. تعجبني أيضًا فكرة الملحقات ، اقرأ تنسيقات المشروع الأخرى مثل Visual Studio Solutions واقترح / ضع إعدادات مجلد إضافية في مكانها. ويمكنك دائمًا فتح المجلد الأصل المشترك للجميع.

stevencl شاهد كلا الفيديوين.

1. البديل 2 مع توضيح يبدو أكثر وضوحًا. يبدو أن هذا يمكن أن يكون قابلاً للانهيار (أي أحد الجذور في الشجرة) مما يسمح بمشاهدة العديد من المشاريع في وقت واحد. إذا كنت بحاجة إلى نموذج بالحجم الطبيعي ، فأعلمني بذلك.

2. البديل 2 أكثر كفاءة من منظور العقارات المعروضة على الشاشة. لن تتكرر نفس المعلومات (اسم المشروع) في الأعلى - كما في الخيار 1 ثم تظهر في جذر كل مشروع.

3. يمكن أن تتصرف نتائج البحث و Git بنفس الطريقة ... كشجرة قابلة للطي. سيتم تجميع النتائج (جنبًا إلى جنب مع الحالة) تحت عنوانها المناسب. أعتقد أنك إذا كنت تريد ملخصًا قابلاً للتنقل (كما أوضحت لـ GIT ، فسيكون هذا خيارًا يمكن أن يكون موجودًا عبر البحث (عدد الملفات التي عثرت عليها) ومنطقة المشروع (يمكن أن يستوعب هذا أزرار الإجراءات).

باختصار ، أنا معجب بالجذور الفردية القابلة للطي مع الإضافة المحتملة للملخص القابل للتنقل. نوع من مزيج من البديل 2 وهذا المثال

آمل أنه مهما كان اختياركم ، فإنكم تجعلون التجربة متشابهة عبر الآليات المختلفة. أنت تقول أنه كان هناك بديلان ، ولكن هناك 4 بالفعل منذ أن كان كل من GIT والبحث مختلفين. أنا أتفق مع من أدلى بهذا التعليق

رد: تقاسم معلومات المشاريع المتعددة. أعتقد أنه سيكون مفيدًا - كيف سيكون ذلك منطقيًا كبداية - سأجعله مجرد استخدام مهام gulp - أو المهام التي يمكن لـ VS Code فهمها.

شكرا لكل جهودك في هذا

يتم تتبع تنفيذ مساحة العمل متعددة الجذور في # 28344 وفي هذا الإنجاز في يونيو.

@ gulshan ،

يمكن أن تكون هناك حالات لا توجد فيها تبعيات. على سبيل المثال ، إذا كنت أعمل على website وقررت إضافة mobile للعمل عليه في نفس الوقت. لا توجد تبعيات بين الاثنين ، ولكن الآن أصبح website "الأصل". إذا حدث لي أن نعمل على mobile لأول مرة، فإنه سيكون تصبح الأم. إنه تعسفي بعض الشيء. يمكن أن تكون المجلدات أيضًا لمشاريع غير ذات صلة تمامًا.

بغض النظر ، أنا أحترم قرار مطوري VSC ، حتى لو لم أتفق معه بالضرورة.

شكرا لجميع التعليقات المستمرة. كما ذكرنا أعلاه ، نحن نتتبع العمل في الإصدار رقم 28344. سنأخذ هذه التعليقات في الاعتبار بينما نواصل العمل على ذلك ، خاصة أثناء تصميم تجربة SCM. كما تمت مناقشته في مقاطع الفيديو وكما ذكر أعلاه عدة مرات ، نريد تحقيق الاتساق طوال التجربة.

فيما يتعلق بقضية التعقيد التي أثارها @ glen-84 و نشكرك على الاقتراحات والردود المفصلة. نحن نتفهم التعليقات وسنواصل مراقبة ذلك أثناء عملنا على الميزة.

كان النقاش حول هذا مفيدًا حقًا وأعطانا بعض الأشياء التي يجب التفكير فيها لتصميمنا الحالي. على سبيل المثال ، ربما يتعين علينا التفكير في السماح للمستخدمين باختيار المجلد "الأساسي" عند إضافة مجلد ثانٍ إلى مساحة العمل. ربما نطالب بذلك عندما تكون مساحة العمل مغلقة ، ربما يكون إعدادًا. الكثير من الأشياء التي يجب أن نفكر فيها لتبسيط التجربة.

كما ذكر bpasero ، نحن دائمًا مترددون جدًا في إضافة مفاهيم جديدة (مثل المشاريع) إلى VS Code. ليس لأننا نعتقد أنه سيجعل VS Code غير قابل للاستخدام ، بل لأن المفاهيم الإضافية تضيف إلى وزن أو ثقل كود VS ، مما يجعله أكثر تعقيدًا. قد تكون مثل هذه المفاهيم شيئًا آخر يجب على المطورين تكريس الموارد العقلية له.

علاوة على ذلك ، بمجرد وجود شيء ما في VS Code ، يكون من الصعب جدًا إزالته (بمرور الوقت يعتاد الناس عليه ويعتمدون عليه). لذلك نقضي الكثير من الوقت في التفكير بعناية فيما نضيفه إلى VS Code ونضيف شيئًا فقط عندما نكون واثقين من أن تكلفة إضافة مفاهيم جديدة ستكون مجدية. لذا نريد الآن تحديد مدى نجاح تصميم لجذر متعدد لا يضيف مفاهيم جديدة.

مرة أخرى ، شكرًا على التعليقات القيمة بشكل لا يصدق. بدون حوار مثل هذا ، سيكون من الصعب جدًا محاولة تصميم هذه التجربة.

من الرائع مدى تفكيرك واستجابتك جميعًا في الفريق ؛ إنه حقًا موضع تقدير!

ما لم يُقال بعد فيما يتعلق بالتعقيد هو أنك تضيف البعض على أي حال. أعتقد أن هذين الخيارين تمت مناقشتهما حاليًا:

1. مشاريع صريحة.
2. شيء يشبه المجلدات المتعددة العادية ولكنه ليس كذلك في الواقع - هناك مفهوم مهم للمجلد الأساسي الذي يتعلق بأشياء مثل rootUrl للإضافات وربما أشياء أخرى (وراثة إعدادات مساحة العمل ، على سبيل المثال). أعتقد أنه عادةً ، سيحتاج مستخدم VSCode إلى فهم هذا المفهوم وربما يكون من الأسهل أن نكون واضحين وصريحين بشأنه بدلاً من محاولة تجريده بعيدًا.

أفضل الطريقة الثالثة حقًا ، عدم تقديم أي شيء جديد ، فقط التعامل مع أشياء مثل .git إعادة الشراء المتعددة والبحث والمهام وأشياء من هذا القبيل بطريقة شفافة - نوع ما في الثلثين الأولين من مقاطع الفيديو اقترح (أحببت كثيرا الإطارات السلكية). ومع ذلك ، أدركت بعد ذلك أن rootUrl يحتاج إلى النظر في الإضافات التي ربما تكون السبب الرئيسي وراء تعقيد هذا الأمر.

إذا لم يكن الأمر يتعلق بـ rootUrl ، كنت سأبدأ للتو بتحديثات واجهة المستخدم كما هو مقترح في الإطارات الشبكية بالإضافة إلى الثبات المحلي لمساحة العمل متعددة الجذور ، بنفس الطريقة التي يتم بها الاحتفاظ بجميع المجلدات الأخرى في "Open Recent"

أود أن أكرر ذلك من وجهة نظري ، الحالة المثالية هي حيث يعمل VSCode مع مجلدات متعددة بغض النظر عما إذا كانت جذور SCM أم لا (monorepo مقابل repos متعددة ، انظر أعلاه). أعتقد أن الإطارات الشبكية المقترحة بالإضافة إلى بعض الأعمال الأساسية الإضافية مثل وراثة إعدادات .vscode ستكون كافية لـ "v1" للدعم متعدد الجذر. يمكن أن تأتي "المشاريع" أو "المجلدات الأساسية + الإضافية" لاحقًا ، IMO. ومع ذلك ، فإن ما أقوله قد ينخفض ​​إلى rootUrl ، لست متأكدًا من ذلك ، أريد فقط أن أنقل شعوري العام حول هذا الأمر.

إنه لأمر رائع أنك تحاول حل هذه المشكلة الصعبة والحفاظ على البساطة قدر الإمكان!

لديّ مشروع عقدة للواجهة الخلفية والواجهة الأمامية ، ولديّ محررا 2 VisualCode مفتوحان ، وهو ما يمثل إجهادًا كبيرًا للموارد.

لقد شاهدت مقطعي الفيديو وأوافق على التعليق أعلاه بأن هذه المشاريع المتعددة لا تحتاج إلى أي علاقة بواحد آخر. ربما يكون أحدهما مشروع nodejs والآخر هو C ++.

لم تعجبني فكرة أن يصبح أحد المشاريع مشروع "رئيسي" مع إضافة المشاريع الإضافية. يجب أن يكون كل مشروع متساويًا وغير ذي صلة.

كنت أتوقع أن أتمكن من فتح مجلد ، ثم فتح مجلد آخر (وليس إضافة). ستتم إضافة المجلد ببساطة كما في الفيديو 1 ، مع ظهور الجذور فقط (لكن تظهر المسارات الكاملة في تلميح الأدوات عند تحريك المجلد الجذر). ستكون هذه المشاريع غير ذات صلة على الإطلاق. قد يؤدي تحديد أحدهما أو الآخر إلى تبديل السياق. سيكون الأمر كما لو كنت أقوم بالتبديل بين مثيلين من Visual Code ، وكلا الإعدادات وأنظمة الألوان ، وما إلى ذلك.

تتمثل طريقة استمرار هذه المشاريع المتعددة في حفظ هذا كملف مشروع جديد ، يشير إلى المشروعين الآخرين ، ولكن دون تعديل أي من المشروعين أنفسهم. بمعنى آخر ، يظل المشروعان مستقلين ومكتفين ذاتيًا وغير مدركين للمشروع الثالث (ملف الإعدادات) الذي يشير إليهما.

بمجرد حفظ / إنشاء هذا الملف الثالث ، يجب أن يكون من الممكن إنشاء إعدادات تتجاوز الإعدادات من المشروع A و B. ستعتمد الإعدادات التي لم يتم إنشاؤها مرة أخرى على المشروع النشط.

عند مشاركة المشروع ، يمكن للمرء مشاركة ملف المشروع الذي يشير إلى الاثنين الآخرين. عندما تكون مفقودة من نظام الملفات ، ولكنها تحتوي على مرجع لعناوين url الخاصة بـ github ، يجب أن يسأل المستخدم عما إذا كان يريد جلبها (افتراضيًا كمجلد فرعي في جذر ملف المشروع الرئيسي هذا ، ولكن يمكن للمستخدم التصفح بحثًا عن الملف المطلوب موقع لكل).

يجب أن تكون القدرة على البحث عبر مشاريع متعددة اختيارية ، وستكون القدرة على تشغيل وتصحيح عدة مشاريع في نفس الوقت مفيدة للغاية ، ولكنها تبدو معقدة للغاية بالنسبة للإصدار الأول ، وربما تتطلب حالة الاستخدام هذه تشغيل مثيلين على أي حال. على الأقل لغاية الآن.

كيف يجب أن يبدو هذا في واجهة المستخدم هو الخطوة الثانية ، ولكن وظيفيًا هذه هي الطريقة التي أتوقع أن تعمل بها. لا أحب فكرة تعديل أي من المشروعين (أ) للإشارة إلى (ب) أو العكس بالعكس ، وهذا نوع مما فهمته هو النية. بالنسبة إلى مطور Agile ، سأكون سعيدًا فقط إذا كان بإمكاني العمل على مشروعين في نافذة واحدة ليس أكثر من الاضطرار إلى تشغيل مثيلين ، ولكن ليس أكثر من ذلك في الوقت الحالي. ربما ليس حتى مع ملف المشروع المهيمن الثالث ، ولكن فقط مع تبديل السياق.

شكرا لردود الفعل المستمرة. هناك سمة محددة حول تأخير استمرار مساحة عمل متعددة المجلدات حتى اتخاذ إجراء صريح من المستخدم (مثل الحفظ). سنحتاج إلى التفكير أكثر في هذا الأمر وإجراء مزيد من التحقيق.

أود أيضًا أن أقترح على المطورين إلقاء نظرة على Eclipse IDE حول كيفية القيام بذلك
يتعامل مع هذه الوظيفة ، لقد اكتشفوها منذ فترة طويلة وهي تعمل
عظيم.

في الثلاثاء 13 حزيران (يونيو) 2017 الساعة 9:11 صباحًا ، ستيفن كلارك إخطارات @
كتب:

شكرا لردود الفعل المستمرة. هناك موضوع محدد حول
تأخير استمرار وجود مساحة عمل متعددة المجلدات حتى يتم توضيح بعضها
إجراء من المستخدم (مثل حفظ). سنحتاج إلى التفكير أكثر في هذا الأمر
والتحقيق أكثر.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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

إشعار السرية:
المعلومات المنقولة مخصصة فقط للشخص أو الكيان
التي تم تناولها وقد تحتوي على سرية و / أو مميزة
مواد. أي مراجعة إعادة نشر أو استخدام آخر أو
اتخاذ أي إجراء بالاعتماد على هذه المعلومات من قبل الأشخاص أو
الكيانات الأخرى غير المتلقي المقصود محظور. إذا تلقيت
هذا عن طريق الخطأ يرجى الاتصال بالمرسل على الفور عن طريق العودة الإلكترونية
الإرسال ثم حذف هذا الإرسال على الفور بما في ذلك الكل
المرفقات دون نسخ توزيع أو إفشاء.

مشروع رئيسي
أنا ضد وجود مشروع رئيسي. يحدث تبديل السياق بشكل متكرر عند العمل مع خدمات مصغرة مختلفة. ينطبق هذا على النقاط التالية في Linting و SCM.

ثبات مساحة العمل
أعتقد أنه في التكرار الأول ، لا ينبغي علينا الاستمرار في مساحة العمل. أفضل التكرارات على إصدار واحد أو إصدارين لهذه الميزة قبل أن نقدم أي إعدادات أو طبقات دائمة لتقليل أي أنواع من عمليات الترحيل المعقدة أو المدمرة.

الفحص / الإعدادات
يجب وضع الفحص الخاص بالمشروع في نطاق أسماء الملفات الموجودة في الدلائل المقابلة. على سبيل المثال ، يستخدم المشروع أ أجمل بينما يستخدم المشروع ب المعيار. يجب أن يكون التبديل بين السياقين سلسًا دون أن تتعارض قواعد الفحص مع بعضها البعض.

بحث
أحببت بعض الإطارات الشبكية لهذا الإطار حيث كانت نتائج البحث عبر جميع المشاريع وفرزها حسب المشروع.

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

_Project B_
file3: matched substring
file4: matched substring

SCM
في هذه الحالة ، أميل أكثر نحو إظهار التقسيم حسب المشروع مع كل تغيير scm.

_Project A_
file1: added
file2: removed
...

_Project B_
file3: moved
file4: added
file5: added

أشعر أن هذه الأساليب أكثر شفافية وبديهية.

يبدو أن الإجماع (استنادًا إلى التعليقات الأخيرة والقضايا الأخرى) يتعارض مع فكرة additionalFolders ، على الأقل في الإصدار الأولي.

بينما أفهم أنه تم اتخاذ القرار بالفعل ، فهل تفكر في محاولة تنفيذ هذه الميزة كمجموعة من واجهات برمجة التطبيقات ، مع ترك المثابرة لتكرار لاحق؟ لذلك ، واجهات برمجة التطبيقات لإضافة / فتح المجلدات ، وتحديثات المستكشف ، والبحث ، والمهام ، وطرق عرض SCM لدعم ذلك.

لقد تحدثت عن مدى صعوبة إزالة شيء ما من المنتج (إذا فشل مفهوم المشروع / مساحة العمل بطريقة ما) ، ولكن الحقيقة هي أن هذا ينطبق بالتساوي (إن لم يكن أكثر من ذلك) على مفهوم additionalFolders .

سيسمح لك تنفيذ كل من additionalFolders و "المشاريع / مساحات العمل" كملحقات بجمع بيانات الاستخدام دون الالتزام بنموذج واحد. يمكن لاحقًا دمج أحد هذه الامتدادات (أو الحل المختلط) في المنتج.

هل تم إصلاح المشكلات المتعلقة بالبيئة على نظام التشغيل Mac OS؟ ما زلت غير قادر على استخدام Homebrew npm وما إلى ذلك بدون فتح VSCode من سطر الأوامر عبر code وهذا سيلعب الفوضى مع دعم الجذور المتعددة بالتأكيد؟

نعم ، هذا أمر لا بد منه بالنسبة لي أيضًا. أنا لا أفهم مشاكل الناس معها. قد لا تكون الطريقة التي يعمل بها شخص ما ، لكن هذا لا يعني أن إدارة مساحة العمل المفضلة لشخص آخر أقل صحة. أنا فقط أكره إجابات "لماذا تريد أن تفعل ذلك؟" بدلاً من "دعنا نتعرف على كيفية إضافة ميزة يمتلكها كل محرر كود آخر في العالم."

العودة إلى أتوم على ما أعتقد.

saborrie https://github.com/Microsoft/vscode/issues/24961 (أحصل على نفس المشكلة على كل من المطلعين والإصدارات العادية). إذا كان بإمكاني المساعدة في تصحيحه ، فأنا لعبة.

akutz لقد

مرحبًا cliffrowley ،

عظيم أن نسمع. لقد ألقيت نظرة أخرى مؤخرًا على VSCode حيث كنت أستخدم Atom إلى الأبد (و Sublime قبل ذلك). لقد كان Atom مؤخرًا مشكلة وفي سلسلة Reddit رأيت أن VSCode كان حقًا خيارًا رائعًا هذه الأيام. لذلك فوجئت أنه لا يدعم ميزة أساسية.

فقط تتراكم هنا - هذه حقًا الميزة الوحيدة التي تمنعني من التفكير في التبديل من IntelliJ / WebStorm إلى VSCode بدوام كامل ... ويرجع ذلك أساسًا ، كما ذكر ملصق سابق ، إلى أنني أعمل مع البنى الموزعة طوال اليوم وأحتاج إلى إدارة Git متعددة متكاملة إلى محرري (لأنني كسول جدًا 😆)

أنا أحب أنكم جميعًا تعملون على هذا ، ولا أطيق الانتظار لرؤيته أثناء العمل.

أنا أحب vscode ولكن هذه "الميزة المفقودة" تمنعني من التبديل الكامل من atom إلى vscode

هناك إصدار قديم موجود بالفعل في إصدار Insider. إذهب واجلبه :)

+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 إنه عمل قيد التقدم ،

يعتمد مشروع vscode على مجلد.
لذلك ، يمكنك تكوين تكوين كل مشروع على حدة ، ويمكنك استخدام Git المدمج مباشرة ، أو لا يمكنك ذلك.

PyCharm: القلب: القلب: القلب:

+1

يجب أن أثني عليك ، فريق VSCode العزيز.
أخيرًا ، أصبحت قادرًا على التخلص من Atom منذ أن هبطت مساحات العمل متعددة الجذر في مباني المطلعين!
منذ عامين ، لم يتم احترام ملفات .gitignore وما إلى ذلك في Atom عند البحث في مساحات عمل متعددة الجذور وقد حصلت عليها منذ البداية!

هل يتم تتبع استمرار مساحات العمل في قضية أخرى؟

أصدر فريق VS Code بالأمس إصدارًا جديدًا من VS Code مع ميزة مساحات عمل الجذر المتعددة 🎉.

نتيجة هذا العمل هو ما نسميه "الحد الأدنى للمنتج القابل للتطبيق" (MVP) لتمكين الاختبار على مساحات عمل متعددة لمجلدات الجذر.

في الواقع ، متاح فقط من إصدار Insiders لذا يمكنك تنزيله هنا تنزيل VS Code Insiders

مستكشف الملفات

بحث

لنفترض أن كل مجلد مضاف إلى مساحة العمل هو مستودع git منفصل - هل الإصدار الحالي من Multi Root Workspaces يتعامل مع التحكم في المصادر المختلفة لتلك المستودعات؟

Weyzu ، نحن نعمل على اعتماد SCM لسيناريوهات الجذور المتعددة لهذا المعلم. تفكيرنا الأولي هو أن طريقة عرض SCM يجب أن تكون مدركًا لمستودعات التخزين المتعددة ، وهو ليس بالضرورة نفس الوعي متعدد المجلدات كما هو الحال في المستكشف والبحث: بالفعل عند فتح مجلد واحد في VS Code ، يمكن أن يكون لديك مستودعات متعددة داخل . نعتقد أن عرض SCM يجب أن يُظهر هذه المستودعات بطريقة جيدة بحيث ترى التغييرات الصادرة / الواردة لكل مستودع بالإضافة إلى القدرة على تثبيت الملفات من كل مستودع.

يجب أن توفر النتيجة تجربة أفضل لكل من السيناريوهات متعددة الجذور وكذلك سيناريوهات الجذر الفردي حيث توجد مستودعات متعددة في جذر واحد.

يجب أن توفر النتيجة تجربة أفضل لكل من السيناريوهات متعددة الجذور وكذلك سيناريوهات الجذر الفردي حيث توجد مستودعات متعددة في جذر واحد.

نهج ممتاز ، يا رفاق صخرة!

تضمين التغريدة سأكون بالتأكيد مهتمًا برؤية رفاقك يتعاملون معها. لدى IntelliJ / WebStorm شيئًا مشابهًا حيث يكتشف تلقائيًا جذور Git ويصطفها لك بشكل مناسب في أسفل اليمين ، وقد أحببت استخدامه شخصيًا.

هل كنتم تفكرون في شيء من هذا القبيل أو شيء أكثر تفصيلاً؟

ما زلنا نفرز UX لهذا الأمر وسنطلعك على النتائج.

ألا يمكن أن يعمل جذر نظام الملفات الافتراضي هنا؟ سيتصرف بشكل فعال كما لو كان جذر VFS هو الدليل الأصلي للعديد من المسارات المتباينة.

كنت أرغب في تقديم تحديث حول عملنا متعدد الجذور لأن اليوم هو اليوم الأول الذي وصلت فيه تجربة المستخدم المعدلة متعددة الجذور إلى الإصدار الداخلي وقد يكون الكثير منكم الذين اعتادوا على السلوك "القديم" في حيرة من أمرهم.

عيوب الحل القديم
الحل القديم للجذور المتعددة سيقدم إعدادًا جديدًا workspace (في settings.json ) الذي يسمح بإضافة مجلدات إضافية إلى مجلد جذر واحد. بدا الإعداد على هذا النحو في حال لم تكن قد لاحظت:

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

نسمي هذا الحل المجلد "الرئيسي" مع مجلدات إضافية ("التفاصيل").

كان هذا هو الحل الأكثر وضوحًا دون تقديم الكثير من المفاهيم الجديدة ولكن به أيضًا عيوب:

• لا يمكنك أبدًا فتح المجلد الرئيسي كمجلد واحد مرة أخرى لأن الإعداد استمر
• لا يمكنك إزالة المجلد الرئيسي من المستكشف
• تم تطبيق بعض الإعدادات من المجلد الرئيسي على كافة المجلدات الأخرى
• تتلوث إعداداتك باستخدام عناصر التكوين متعددة الجذور
• من الصعب السماح بفتح مجلدين في نفس الوقت (على سبيل المثال ، عند فتح 3 ، ما هو المجلد الرئيسي الذي يجب أن نأخذه؟)

حلنا
نعتقد أن هناك حاجة إلى مفهوم مساحة عمل أكثر وضوحًا لسيناريوهات الجذور المتعددة ، وعلى هذا النحو في المطلعين اليوم ، سترى بعض واجهة المستخدم الجديدة تظهر:

الفكرة هي أن مساحات العمل متعددة الجذور تتطلب إجراءً واضحًا ليتم إنشاؤه. بنفس الطريقة التي يمكن أن تكون بها في مساحة عمل فارغة (لا يوجد مجلد مفتوح ، شريط حالة أرجواني) أو في مساحة عمل ذات مجلد واحد (شريط الحالة أزرق فاتح) ، يمكنك أيضًا أن تكون في مساحة عمل متعددة الجذور (حالة زرقاء داكنة شريط). تسمح هذه الطريقة الثالثة لفتح مساحة عمل في VS Code بالحصول على أكبر عدد تريده من المجلدات. يمكن حفظ مساحات العمل هذه في ملف (على سبيل المثال myWorkspace.code ) وتتضمن أيضًا إعدادات مساحة العمل. لست مجبرًا على حفظها ، طالما أنك لا تريد حفظها ، فسوف تظهر على أنها "مساحات عمل بلا عنوان".

لفتح مساحة عمل ، يمكنك إما فتح ملف مساحة العمل المحفوظ أو الاختيار من القائمة المفتوحة مؤخرًا:

هذا كود صغير جدًا وتجربة مستخدم صغيرة جدًا ، لذا توقع بعض التغييرات خلال الأسابيع المقبلة. نعلم أنه لا تزال هناك بعض الأشياء التي يجب حلها (على سبيل المثال ، كيف يمكننا جعل الانتقال من مجلد واحد إلى مجلد متعدد أكثر سلاسة).

تم إجراء بعض التغييرات التي تم إجراؤها بالفعل اليوم والتي ستظهر غدًا في الإصدار الداخلي بناءً على التعليقات:

• إعادة تسمية .code إلى .code-workspace كملحق لمساحات العمل
• لديك قائمة موحدة من المجلدات ومساحات العمل (على سبيل المثال في ملف> فتح الأخيرة) بدلاً من التمييز بين المجلدات ومساحات العمل

ترقبوا المزيد في المستقبل 👍

علاوة على ذلك ، لدينا الآن مجلد .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 تطرح نقطة جيدة. في تصميم إعداداتنا للجذور المتعددة نحاول تحديد الإعدادات التي يمكننا دعمها لكل مجلد والإعدادات التي لا يمكننا دعمها. نقول عادةً أنه يمكن دعم الإعدادات التي تستهدف المحرر أو موردًا معينًا لكل مجلد لأنه من الواضح من أي مجلد تم فتح المحرر. الإعدادات الأخرى التي لن يتم دعمها تدور حول تخصيص طاولة العمل (مثل إظهار شريط الحالة أم لا).

يتعلق المثال الخاص بك بإعداد editor.fontSize الذي ندعمه بالفعل لكل مجلد حتى في مساحة عمل متعددة الجذور. أعتقد أنه قد يكون سيناريو صالحًا هو أن المستخدم يريد أن يكون له حجم خط أكبر لمجلد يحتوي على الكثير من وثائق تخفيض السعر (ربما حتى خط مختلف؟). لذلك أعتقد أنه لا ينبغي لنا منع احترام هذا الإعداد لكل مجلد أيضًا في بيئة متعددة الجذر.

إذا كنت تريد الاحتفاظ بـ editor.fontSize كإعداد لمساحة العمل الشخصية ، فأنا أعتقد أنه لا ينبغي إيداعه في المستودع.

باستخدام مفهوم مساحات العمل الجديدة ، يمكنك القيام بما يلي:

• ملف> مساحات العمل> مساحة عمل جديدة
• اختر المجلد الخاص بك
• افتح إعدادات مساحة العمل
• تغيير editor.fontSize: 15

من الآن فصاعدًا ، ستحمل مساحة العمل الخاصة بك هذا الإعداد ، لكنك لا تجبره على أي شخص آخر.

من منظور UX ، سيكون من الملائم أن أتمكن من سحب المجلدات وإفلاتها في نافذة VS Code دون الحاجة إلى إنشاء مساحة عمل أولاً (إنه شيء أقوم به طوال الوقت في Sublime). أنا أعمل دائمًا على مشاريع متعددة في نفس الوقت ، واعتمادًا على ما أعمل عليه ، ستكون مجموعة مختلفة (متداخلة) من المشاريع كل يوم.

ستقدم مساحات العمل مفهومًا ليس أصليًا في طريقتي في العمل ، وسأضطر إلى تتبع تكوينات مساحة العمل المختلفة (كما أفهمها) والتي تبدو وكأنها ستخلق بعض فوضى التكوين في مجلدات مشروعي.

بالإضافة إلى ذلك ، أعتقد أنني أتحدث نيابة عن العديد من المستخدمين إذا كنت أزعم أن أشياء مثل البحث والتكوين تكون عامة بشكل افتراضي (تنطبق على جميع المجلدات المفتوحة) - على الرغم من أنه سيكون من الجيد أن يكون لدي خيار البحث محليًا في مجلد ( لطالما وجدت هذا صعبًا في Sublime).

SanderMertens ربما فاتك هذا ولكن bpasero كتب ؛

يمكن حفظ مساحات العمل هذه في ملف (على سبيل المثال ، myWorkspace.code) وتشمل أيضًا إعدادات مساحة العمل. لست مجبرًا على حفظها ، طالما أنك لا تريد حفظها ، فسوف تظهر على أنها "مساحات عمل بلا عنوان".

الآن ، لست متأكدًا مما إذا كان لديك القدرة على سحب المجلدات وإفلاتها ، ولكن مما أحصل عليه سيكون لدى الأشخاص القدرة على فتح مجلدات عشوائية دون إنشاء مساحة عمل.

لا أطيق الانتظار حتى يتم تضمين هذه الميزة في البنية المستقرة.

ياي! 😄

لا يمكنك حاليًا سحب مجلد إلى المستكشف لإضافته ، ولكن هذا موجود في سجلنا المتأخر. التعقيد في هذا التفاعل هو أننا لا نعرف نية المستخدم: فتح المجلد في النافذة أو إضافته إلى مساحة العمل؟

يعد الانتقال من مجلد واحد إلى العديد من المجلدات حاليًا خطوة أكثر وضوحًا مقارنة بما يفعله المحررون الآخرون (تحتاج إلى الانتقال عبر ملف> مساحات العمل> حفظ مساحة العمل واختيار المجلدات التي تريدها). هناك عدة أسباب وراء رغبتنا في اتباع السلوك الحالي في الوقت الحالي حتى يستقر الجذور المتعددة. السبب الرئيسي هو أن تعدد الجذور هو تغيير رئيسي لجميع امتداداتنا. أثناء عمل المستكشف ويمكنك البحث في جميع المجلدات ، لن تعمل معظم الملحقات بشكل صحيح حتى يتم اعتماد واجهة برمجة التطبيقات الجديدة متعددة الجذور. على هذا النحو ، لا نريد أن نجعل الأمر سهلاً للغاية في البداية لإدخال جذر متعدد عن طريق الصدفة. إنها لفتة مستخدم صريحة للدخول إلى مساحات عمل متعددة الجذور وفي هذا الوضع قد نرغب في لفت الانتباه إلى حقيقة أن بعض الإضافات لا تعمل بعد.

سبب آخر هو إعدادات مساحة العمل: تخيل هذا التدفق:

• تبدأ بمجلد واحد به إعدادات مساحة العمل
• أضفت مجلدًا ثانيًا (افترض أن هذا يعمل بدون تبديل السياق وإعادة تحميل النافذة)
• تفتح إعدادات مساحة العمل
  => يتم الآن تخزين إعدادات مساحة العمل في جذر متعدد في مكان ما خارج المجلدات لأنه يمكن أن يكون لديك عدة جذر
  => ربما نحتاج إلى سؤال المستخدم عما إذا كان المستخدم يريد ترحيل إعدادات مساحة العمل إلى هذا الموقع الجديد

لذا ، بغض النظر عن أي شيء ، فإن إدخال جذر متعدد ليس عملية خفيفة الوزن حاليًا. قد نعيد النظر في هذا عندما يستقر الغبار ويتم اعتماد الجذور المتعددة على نطاق واسع ، ولكن في الوقت الحالي نعتقد أن هذا النموذج أفضل ويتجنب الإحباط.

bpasero أعتقد أنه بمجرد قيامك بسحب مجلد إلى المستكشف ، لا يجب حفظه تلقائيًا في مساحة العمل على الرغم من احتمال وجوده

كل هذا يتوقف على حالات الاستخدام التي يريد المرء تغطيتها. لقد اكتشفت من التجربة أن KISS هو دائمًا أفضل نهج. تقديم Workspaces يبدو رائعًا مثل feature لكن ما هي الفائدة الحقيقية وما هي عيوبها؟

أحد العيوب التي تتبادر إلى الذهن عند تقديم واستخدام Workspaces هو أنه يحتاج إلى تخزين بياناته (الإعدادات) في مكان ما ويتطلب صيانة / وعي المستخدم.

لنفترض أن الهدف الوحيد هو منح المستخدمين القدرة على العمل مع مجلدات متعددة في جلسة VS Code واحدة. لا أقل ولا اكثر.

حالة الاستخدام الأكثر شيوعًا:
لا يوجد مفهوم Workspaces . يفتح المستخدم فقط مجلدًا إضافيًا ، أو أي مجلد يريده ، ويفتح في العرض على اليسار تمامًا كما يفعل مجلد واحد. يتوقع أن تكون إعداداته هي نفسها في كل مكان. بغض النظر عن مكان ملفاته. وهو لا يريد أي فوضى إضافية لملفات تهيئة VS Code بين ملفات مشروعه كما هو مذكور بواسطة SanderMertens وأنا وربما الآخرين هناك أيضًا.

التحديات / المشاكل / الأسئلة:

• لماذا توجد ملفات إعداد مختلفة؟ إعدادات المستخدم ، إعدادات مساحة العمل؟ يجب أن يتم تخزين IMHO جميعًا في نفس المكان. من خلال تفضيل المستخدم لمجلده الشخصي / ملفه الشخصي ، بحيث يمكن لكل مستخدم على النظام أن يكون له إعداداته الخاصة. مكافأة اضافية. لا يقومون بفوضى في ملفات المشروع ويمكن لعدة مستخدمين القيام بأشياءهم الخاصة. مسح الملف الشخصي؟ عظيم! سجل نظيف لـ VS Code أيضًا.

أعتقد أن Workspaces أشياء أكثر من اللازم إذا كنت تريد:
السرعة والبساطة ومحرر يعمل فقط. ، لا يزيد الأمور تعقيدًا أو فهم مفاهيم إضافية. إذا كان المستخدمون من Sublime أو غيرهم من المحررين لا يستخدمون هذا المفهوم في سير العمل الخاص بهم ، فيجب أن يكون ذلك مؤشرًا على الإفراط في التفكير في الأشياء. أو قد يعني أنه تم اختراع شيء رائع حقًا سينفذه المحررون الآخرون أيضًا ، لكن لدي شكوك.

أنا آسف إذا كان هذا يبدو صاخبًا ، فهذا ليس في نيتي مطلقًا. لكنني أعتقد أنه يمكننا القيام بعمل أفضل فيما يتعلق بالوصول إلى جذر / مجلد متعدد.

@ DarkLite1 نشكرك على الوقت الذي

أنا أتفق مع جميع نقاطك وأريد حلاً بسيطًا أيضًا. مساحات العمل كمفهوم هي خطوتنا الأولى نحو حل متعدد الجذور يعمل مع أنماطنا الحالية (إعدادات مساحة العمل ، والإضافات ، وما إلى ذلك). نظرًا لأن هذه هي الخطوة الأولى ، فتوقع بعض الحواف الأكثر خشونة (على سبيل المثال ، الانتقال من مجلد واحد إلى مجلد N ليس خفيفًا كما يمكن أن يكون). هدفنا هو جعل هذا الانتقال سلسًا وألا نجعله أكثر تعقيدًا مما يجب أن يكون في المستقبل. كما أننا لا نرغب في إجبار المستخدم على إدارة مساحات العمل هذه (ولهذا السبب لدينا "مساحات عمل بلا عنوان" تظل قائمة طالما كانت النافذة مفتوحة وستختفي بمجرد إغلاق تلك النافذة).

هناك بعض الأشياء حول مساحات العمل متعددة الجذور يجب أن تضعها في اعتبارك والتي ربما لا تكون واضحة جدًا. آمل أن يساعد الشرح التفصيلي التالي في فهم عملية التصميم لدينا:

إعدادات مساحة العمل
نحن ندعم وجود إعدادات داخل مجلد مساحة العمل (مجلد .vscode ). بقدر ما قد لا يحب بعض المستخدمين هذا النوع من الإعدادات التي تنتهي في ملفات .gitignore أو المستودع ، فهناك العديد ممن يعتمدون على هذه الوظيفة. لا يمكننا ببساطة التوقف عن دعم الإعدادات التي تعيش داخل المجلدات لأن المستخدمين يعتمدون عليها. الآن ، بالنسبة للسيناريوهات متعددة الجذور ، من الواضح أنه يتعين علينا إيجاد مكان جديد لإعدادات مساحة العمل. توصلنا إلى مفهوم ملف مساحة العمل الذي يحتوي على هذه الإعدادات. طالما لم يتم حفظ مساحة العمل في أي مكان ، فإنها تتواجد في مجلد يحتوي على بيانات أخرى خاصة برمز VS مضمنة وعندما تقوم بحفظ الملف ، ستكون الإعدادات داخل هذا الملف.

تخيل الآن أنك تبدأ بمجلد واحد في VS Code به إعدادات مساحة عمل محددة وتريد إضافة مجلد ثان. ماذا يجب أن نفعل الآن؟ هل تتجاهل إعدادات مساحة العمل للمجلد الأول؟ اطلب من المستخدم ترحيل الإعدادات؟ قررنا أن نجعل هذا تبديلًا واضحًا للسياق لتوضيح أن فتح مساحة عمل يحمل إعدادات مساحة العمل الخاصة به في موقع مختلف.

والآن تخيل أنك انتقلت من مجلد واحد إلى مجلدين وقمنا بنقل إعدادات مساحة العمل إلى مكان آخر. تخيل أنك أجريت تغييرات على إعدادات مساحة العمل هذه. الآن تريد الرجوع من مجلدين إلى مجلد واحد ، هل تتوقع ترحيل إعدادات مساحة العمل مرة أخرى إلى المجلد؟

مثال آخر: يمكنك الانتقال من مجلد إلى مجلدين وتكوين إعدادات مساحة العمل. الآن تقوم بإغلاق النافذة. أعتقد أنك ستغضب منا إذا لم تتمكن من العودة إلى مساحة العمل هذه بطريقة ما لأنك قمت بتكوين الإعدادات بعناية لمساحة العمل هذه. لذا ، على الرغم من أنك لا تحب مفهوم مساحة العمل ، فبمجرد تكوين الإعدادات لها ، أعتقد أنك تريد أن تعيش مساحة العمل هذه.

آمل أن تجعل هذه الأمثلة من الأسهل قليلاً فهم سبب عدم سهولة KISS بالنسبة لنا كما قد يعتقد المرء.

ملحقات
تعمل جميع امتداداتنا دائمًا مع واجهة برمجة تطبيقات توفر مسارًا واحدًا لمساحة العمل لأننا حتى الآن لم ندعم مساحات العمل متعددة الجذور. بصفتك مستخدمًا ، قد تعتقد أن التبديل من مجلد واحد إلى مجلدين هو عملية بسيطة جدًا وخفيفة الوزن ، ولكن بالنسبة للإضافات ، فقد يعني ذلك الكثير من الأشياء: امتدادات اللغة التي افترضت حتى الآن أن هناك مجلدًا واحدًا فقط يجب أن تكون على دراية بعدة المجلدات. علاوة على ذلك ، يمكن أن تأتي هذه المجلدات وتذهب بشكل ديناميكي للغاية في أي وقت.

إن تقديم مفهوم مساحة العمل الحقيقي يمنحنا مزيدًا من المساحة والوقت للتوسع ومساعدة الامتدادات في تبني هذا المفهوم. يمكننا على سبيل المثال تعطيل الامتدادات التي لم تعتمد بعد مساحات عمل متعددة الجذور لمنع حدوث أشياء غريبة (على سبيل المثال ، يعمل ملحق اللغة على مجلد واحد فقط ويبلغ عن أخطاء خاطئة على الآخر).

دعنا نحاول الاستقرار على الدعم متعدد الجذور باستخدام مساحات العمل الجديدة هذه أولاً ثم نعيد النظر في مدى خفة الوزن التي يمكننا من خلالها إجراء التحولات. بمجرد أن يكون لدينا امتدادات على متن الطائرة واكتشاف قصة إعداداتنا ، أعتقد أنه يمكننا أن نجعل الوجه تجربة أكثر خفة.

ملاحظة: نظرًا لأنك تشير إلى المحررين الآخرين فيما يتعلق بدعمهم متعدد الجذر ، أردت فقط أن أشير إلى أن هؤلاء المحررين يأتون أيضًا مع مساحة عمل أو مفهوم مشروع يمكنك حفظه في ملف ومشاركته مع الآخرين. عادةً لا ترى هذه المفاهيم لأن الانتقال من مجلد واحد إلى مجلد 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 :.

الشيء الذي يزعجني أكثر بشأن مفهوم مساحات العمل الجديد هذا (مقارنة بالتكرار الأول باستخدام User Settings ) هو نفس الشيء الذي أزعجني عندما كنت أستخدم Sublime Text. حقيقة أنك _يمكنك_ حفظ ملفات .code-workspace مكان ، والآن يجب أن أدير مكانًا مشتركًا لتخزينها. سيكون الأمر أبسط بكثير ، IMHO أنه سيتناسب تلقائيًا ، في أحد هذين المكانين:

• داخل المجلد user-data-dir ، مثل User Settings و Keybindings
• داخل _Top Folder_

فقط لأكون واضحًا ، أفهم مفهوم مساحة العمل الأكثر تعقيدًا الذي يحتاجه المستخدمون الآخرون. أردت فقط اتباع نهج أبسط لمفهوم أبسط متعدد المجلدات.

يعجبني هذا الخيار ، أضف هذا الخيار.

لأن المجلد بالداخل ليس مؤثرًا جدًا.

أو إضافة القدرة على تغيير هذا الخيار.

تعجبني فكرة مساحة العمل! أي أفكار حول متى سيكون هذا جاهزًا؟

هل من المتوقع في هذه المرحلة ألا تعكس معلومات git الموجودة في الزاوية اليسرى السفلية بدقة فرع git لأي ريبو يوجد به الملف المركز حاليًا؟ لم أر أي شيء حول "جذور بوابة متعددة" في ملاحظات إصدار v1_15.

لقد كنت أستخدم هذه الميزة الآن مع إصدار Insider لبضعة أيام ويجب أن أقول إنه كل ما أردت أن يكون. تجربة مستخدم نظيفة جدًا ولا يمكنني الانتظار حتى يتم إدخالها في التصميم الرئيسي حتى أتمكن من تحويل فريقي بالكامل إلى هذا.

عند العمل مع NodeJS وفتح وحدات NPM متعددة في وقت واحد ، فإن الطريقة التي تجمع بها كل شيء معًا في نافذة واحدة هي توفير كبير للوقت.

دعائم ضخمة للفريق!

لماذا تظهر هذه الميزة في ملاحظات الإصدار الخاصة بي بصيغة gif وشرح ، ولكنها غير متوفرة في المحرر الفعلي ؟!

ShashankaNataraj الذي

تم تسجيل خارطة الطريق الخاصة بنا للعمل المستمر متعدد الجذور في https://github.com/Microsoft/vscode/issues/28344 وستستمر خلال أغسطس وسبتمبر وربما أكتوبر أيضًا.

سنبقي هذه الميزة متاحة فقط في المطلعين حتى:

• يمكننا توفير تجربة SCM مناسبة متعددة الجذور ، وتصحيح الأخطاء والمهام
• اعتمدنا واجهات برمجة تطبيقات ووظائف متعددة الجذور للإضافات التي نشحن معها والتي نساهم فيها بنشاط (مثل Go)
• كان لدى مؤلفي الإضافات الوقت الكافي (على سبيل المثال 1 معلم) لاعتماد واجهات برمجة التطبيقات متعددة الجذور الجديدة

يرجى تفهم أننا نريد تجنب شحن هذه الميزة إلى حالة مستقرة ولدينا تجربة ملحقات معطلة لأننا استعجلنا هذه الميزة في وقت قريب جدًا.

شكرا لكونهم رجال محترفين ، عمل رائع!

bpasero أنا قلق بعض الشيء بشأن مؤلفي الإضافات الذين سيقومون بتحديث المكونات الإضافية في الوقت المناسب. هل يتلقون بعض رسائل البريد الإلكتروني الخاصة بالتغييرات العاجلة القادمة؟

شكر

FelikZ يرجى إلقاء نظرة على خارطة الطريق الخاصة بنا (https://github.com/Microsoft/vscode/issues/28344). بالنسبة لإصدار سبتمبر ، نخطط لاعتماد الامتدادات التي نشحنها في VS Code وأثناء عملنا على ذلك نضيف واجهات برمجة التطبيقات والأدوات المساعدة اللازمة للقيام بذلك.

خلال شهر سبتمبر هذه هي الخطة:

يأتي التحديث الداخلي اليوم مع بعض التغييرات على ملف .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 uuid؟)
• لم يكن من الممكن نسخ ملف مساحة العمل وفتحه في نافذة منفصلة ، كان عليك تغيير id أولاً في الملف المنسوخ
• نتيجة لذلك ، يجب أن يسأل إجراء "حفظ مساحة العمل باسم" المستخدم ما إذا كان يجب أن تحتوي النسخة على id أم لا

تتمثل إحدى عيوب هذا الأسلوب في أنه بمجرد نقل ملف مساحة العمل أو إعادة تسميته ، ستفقد الحالة المرتبطة به. ستستمر إعادة فتح الملفات المتسخة ("الخروج السريع") بعد إعادة التشغيل ، ولكنها ستفتح في نافذة فارغة ولن تكون مرتبطة بعد ذلك بنافذة مساحة العمل. ما زلنا نعتقد أنه يمكننا تحسين هذا السلوك ، على الرغم من أنه يتصرف وفقًا لما يحدث اليوم عند إعادة تسمية مجلد بحالة واجهة المستخدم والملفات المتسخة المرتبطة به.

المجلدات
قررنا إعادة زيارة تنسيق الخاصية folders .

• لم نعد نطلب منك استخدام محددات الموارد المنتظمة (URIs) ، ولكننا نطلب منك فقط استخدام مسارات الملفات لتسهيل التحرير
• قمنا بتغيير إدخالات خاصية 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 ، أو أي من مجلداته الأصلية ، أو نقله ، وفقدان حالة واجهة المستخدم هو في رأيي غير بديهي تمامًا. أعتقد أن الأشخاص غير المدركين لكيفية عمل ذلك تحت الغطاء لن يكون لديهم أي فكرة على الإطلاق عن سبب فقدهم حالة واجهة المستخدم السابقة وكيفية استعادتها.
لا ينبغي ربط ذلك بالمسار المطلق للملفات في نظام الملفات على الإطلاق!

ينطبق هذا على الطريقة التي ترتبط بها حالة واجهة المستخدم بمسار المجلد الموجود حاليًا في الإصدار الثابت أيضًا. كنت في حيرة من أمري حيال ذلك في البداية ، إلى أن قمت ببعض البحث على Google.

IMO في حالة تعاملنا مع مجلد واحد فقط ، يجب حفظ حالة واجهة المستخدم داخل المجلد .vscode . إذا كنا نتعامل مع مساحة عمل متعددة الجذور ، فيجب حفظ حالة واجهة المستخدم كملف منفصل في نفس المجلد مثل ملف .code-workspace باستخدام اصطلاحات التسمية المناسبة (أو ربما داخل هذا الملف نفسه ، على الرغم من خلط الإعدادات و الدولة قد لا تكون فكرة جيدة).

إذا تم تنفيذه بشكل صحيح ، فسيتيح ذلك للمستخدمين الوصول الكامل إلى حالات واجهة المستخدم ، وإرفاق حالات واجهة مستخدم جديدة بمساحة عمل معينة (متعددة الجذور أم لا) ، إلخ.
أرغب في أن أكون قادرًا على مزامنة حالة واجهة المستخدم بين أجهزة كمبيوتر مختلفة ، مثل العمل في المكتب ، ثم العودة إلى المنزل ، والحصول على جهاز كمبيوتر محمول أو أي شيء آخر والاستمرار بالضبط من حيث توقفت.
سيكون وجود العديد من حالات واجهة المستخدم المرفقة بمساحة عمل والتبديل بينها بسهولة (القائمة / ربط المفاتيح / الأمر / إلخ) عند العمل على ميزات مختلفة أمرًا رائعًا أيضًا. ربما يتم إدراج ملفات مختلفة من .code-uistate داخل .vscode تلقائيًا ، أو العديد من ملفات .code-uistate مسبوقة وفقًا لـ .code-workspace ، أو مدرجة في مصفوفة.

أفكر في هذا على أنه امتداد لكيفية عمل المشاريع ومساحات العمل على Sublime Text. نفس الوظائف ، تصميم مختلف. في هذه الحالة ، ستكون مساحة عمل VS Code مشابهة لمشروع Sublime ، وستكون حالات VS Code UI المختلفة مماثلة لمساحات العمل Sublime.

بخصوص هذه القضايا:

كان من الغريب أنه يمكنك تحرير المعرف في الملف ببساطة عن طريق كتابة قيمة أخرى

نعم تماما. كان إزالة المعرف من هناك هو الخيار الصحيح.

لم يكن من الواضح تمامًا كيفية التعامل مع المعرف عند مشاركة ملف مساحة العمل مع الآخرين (هل يجب تغيير المعرف؟ هل يجب أن يكون المعرف uuid؟)

حسنًا ، إذا كان لدينا myproject.code-workspace و myproject.code-uistate فالأمر متروك للمستخدم ليقرر مشاركة حالة واجهة المستخدم الخاصة به أم لا. لا مزيد من التفكير في معنى هذا المعرف ، وكيف يتم إنشاؤه ، وما إذا كان يحتاج إلى أن يكون UUID لتجنب التعارضات عند المشاركة ، وما إلى ذلك.
هل تريد مشاركة إعداد المجلد والإعدادات؟ أرسل myproject.code-workspace ، لا داعي للقلق.
هل تريد مشاركة كل شيء؟ أرسل كلا الملفين.

لم يكن من الممكن نسخ ملف مساحة العمل وفتحه في نافذة منفصلة ، كان عليك تغيير المعرف أولاً في الملف المنسوخ

إذا كنت تريد أن تبدأ بحالة واجهة مستخدم جديدة مع نفس إعداد المجلد والإعدادات ، فقم فقط بتكرار ملف .code-workspace .

نتيجة لذلك ، يجب أن يسأل إجراء "Save Workspace As" المستخدم عما إذا كان يجب أن تحتوي النسخة على معرف مختلف أم لا

كان ذلك صعبًا لأن المستخدم لم يكن يعرف ما هو هذا المعرف. ربما يكون من الأسهل أن يكون لديك خياران "استنساخ مساحة العمل بالحالة الحالية" و "مساحة عمل فارغة جديدة". ولكن هذا هو تجربة المستخدم وسيتعين عليك إجراء تحليل حول ذلك.

بالاتفاق مع فرانك ، احتفظ بجميع ملفات تكوين المشروع داخل الإعدادات
مجلد في المشاريع ، ألق نظرة على Eclipse IDE الذي لديه الحق
مقاربة. لديها مفهوم إعدادات المشروع ومساحة العمل مع
مشروع الكتابة الافتراضية في مساحة العمل. مساحة العمل هي مجرد مجلد به
المجلدات التي تمثل المشاريع. لذلك يكون لديك مجلد .vscode في مساحة العمل
مجلد ، ولكل مشروع مجلده .vscode . ورجاء لا تفعل
فقط لأسفل التصويت هذا لذكر بيئة تطوير متكاملة الكسوف.

يوم الإثنين 18 سبتمبر 2017 الساعة 8:52 مساءً ، فرانكو غالاردو غراتسيو <
[email protected]> كتب:

bpasero https://github.com/bpasero IMHO ، طريقة التعامل مع حالات واجهة المستخدم
(سواء كانت تستخدم سلسلة معرف في ملف .code-workspace ، أو تستخدم
مسار الملف باعتباره المعرف بدلاً من ذلك) غير مناسب.
إعادة تسمية ملف .code-workspace ، أو أي من مجلداته الأصلية ، أو نقله
حوله ، وفقدان حالة واجهة المستخدم هو في رأيي غير بديهي تمامًا. أنا
أعتقد أن الناس غير مدركين لكيفية عمل ذلك تحت الغطاء سيكون بالتأكيد
لا يوجد دليل حول سبب فقدهم حالة واجهة المستخدم السابقة وكيفية الحصول عليها
يعود.
لا ينبغي ربط ذلك بالمسار المطلق للملفات الموجودة في الملف
النظام على الإطلاق!

ينطبق هذا على الطريقة التي ترتبط بها حالة واجهة المستخدم بمسار المجلد حاليًا في ملف
إطلاق مستقر كذلك. كنت في حيرة من أمري حول ذلك في البداية ، حتى
فعل بعض البحث على Google.

IMO في حالة تعاملنا مع مجلد واحد فقط ، يجب حفظ حالة واجهة المستخدم
داخل مجلد .vscode. إذا كنا نتعامل مع مساحة عمل متعددة الجذور ،
يجب حفظ حالة واجهة المستخدم كملف منفصل في نفس المجلد مثل ملف
ملف .code-workspace باستخدام اصطلاحات التسمية المناسبة (أو ربما
داخل هذا الملف نفسه ، على الرغم من أن خلط الإعدادات والحالة قد لا يكون ملف
فكره جيده).

إذا تم تنفيذه بشكل صحيح ، سيسمح هذا للمستخدمين بالحصول على وصول كامل
إلى حالات واجهة المستخدم ، قم بإرفاق حالات واجهة مستخدم جديدة بمساحة عمل معينة (متعددة الجذر أو
لا) ، إلخ.
أود أن أكون قادرًا على مزامنة حالة واجهة المستخدم بين أجهزة كمبيوتر مختلفة ، على سبيل المثال
العمل في المكتب ، ثم العودة إلى المنزل ، والحصول على جهاز كمبيوتر محمول أو أي شيء آخر
تواصل بالضبط حيث توقفت.
وجود عدة حالات لواجهة المستخدم متصلة بمساحة عمل والتبديل بينها بسهولة
لهم (القائمة / ربط المفاتيح / الأمر / إلخ) عند العمل على ميزات مختلفة
كن رائعًا أيضًا. ربما تكون ملفات .code-uistate مختلفة داخل .vscode
مدرج تلقائيًا ، أو العديد من ملفات .code-uistate مسبوقة وفقًا لـ
مساحة العمل الرئيسية ، أو المدرجة في مصفوفة.

أنا أفكر في هذا على أنه امتداد لكيفية المشاريع ومساحات العمل
العمل على نص سامية. نفس الوظائف ، تصميم مختلف. في هذه الحالة أ
ستكون مساحة عمل VS Code مشابهة لمشروع Sublime ، والمختلفة
ستكون حالات VS Code UI مشابهة لمساحات العمل Sublime.

بخصوص هذه القضايا:

كان من الغريب أنه يمكنك تحرير المعرف في الملف ببساطة عن طريق الكتابة
قيمة أخرى

نعم تماما. كان إزالة المعرف من هناك هو الخيار الصحيح.

لم يكن من الواضح تمامًا كيفية التعامل مع المعرف عند مشاركة ملف مساحة العمل
مع الآخرين (هل يجب تغيير المعرف؟ هل يجب أن يكون المعرف uuid؟)

حسنًا ، إذا كان لدينا myproject.code-workspace و myproject.code-uistate
ثم يعود الأمر للمستخدم ليقرر مشاركة حالة واجهة المستخدم الخاصة به أم لا.
لا مزيد من التفكير في معنى هذا المعرف ، وكيف يتم إنشاؤه ، إذا لزم الأمر
UUID لتجنب التعارضات عند المشاركة وما إلى ذلك.
هل تريد مشاركة إعداد المجلد والإعدادات؟ أرسل myproject.code-workspace ،
لا داعى للقلق.
هل تريد مشاركة كل شيء؟ أرسل كلا الملفين.

لم يكن من الممكن نسخ ملف مساحة العمل وفتحه في ملف منفصل
نافذة ، كان عليك تغيير المعرف أولاً في الملف المنسوخ

إذا كنت تريد أن تبدأ بحالة واجهة مستخدم جديدة بنفس إعداد المجلد و
الإعدادات مجرد تكرار ملف .code-workspace الخاص بك.

نتيجة لذلك ، يجب أن يطلب إجراء "حفظ مساحة العمل باسم" من
المستخدم إذا كان يجب أن تحتوي النسخة على معرف مختلف أم لا

كان ذلك صعبًا لأن المستخدم لم يكن يعرف ما هو هذا المعرف. ربما
كن أكثر وضوحًا للحصول على خيارين "Clone Workspace with Current
State "و" New Blank 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 خاص به (توجد فيه إعدادات مساحة العمل). هل تقترح مجلدًا إضافيًا من شأنه أن يدمج المشاريع لمجرد مشاركة معلومات الإعدادات؟ قد يبدو هذا مشابهًا لملف / مجلد " حل " في مصطلحات الاستوديو المرئي.

fgallardograzio سيؤدي وجود تكوين مشروع

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 subrepos
المفاهيم.

يوم الثلاثاء ، 19 سبتمبر 2017 الساعة 10:33 صباحًا ، Yemi Bedu @ P&R [email protected]
كتب:

danielsokolowski https://github.com/danielsokolowski أنا أفهم
فكرة مشروع الكتابة فوق مساحة عمل للإعدادات. في vscode لك
لديك إعدادات عامة ، وإعدادات المستخدم (الكتابة العامة) ، ومساحة العمل
الإعدادات (كتابة المستخدم أو عام). كل مشروع لديه بالفعل
فرصة أن يكون لديك مجلد .vscode خاص به (توجد فيه إعدادات مساحة العمل).
هل تقترح مجلدًا إضافيًا من شأنه أن يدمج المشاريع فقط في
مشاركة معلومات الإعدادات؟ قد يبدو هذا مشابهًا لـ " الحل "
ملف / مجلد في شروط الاستوديو المرئي.

fgallardograzio https://github.com/fgallardograzio وجود مشروع
التكوين الممزوج بالإعدادات في نفس الملف سيفرض
اقتران. تبدو عناصر واجهة المستخدم أفضل كثيرًا كميزة أخرى منفصلة عن
هذه التذكرة. الآن بعد أن أصبح لدى إصدار Insider بعض التخطيط الجميل لملف
جذور إضافية في الملف ، ربما يمكن أن يملأ الامتداد فجوة واجهة المستخدم
جزء. شكرا لك. يوم جيد.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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

إشعار السرية:
المعلومات المنقولة مخصصة فقط للشخص أو الكيان
التي تم تناولها وقد تحتوي على سرية و / أو مميزة
مواد. أي مراجعة إعادة نشر أو استخدام آخر أو
اتخاذ أي إجراء بالاعتماد على هذه المعلومات من قبل الأشخاص أو
الكيانات الأخرى غير المتلقي المقصود محظور. إذا تلقيت
هذا عن طريق الخطأ يرجى الاتصال بالمرسل على الفور عن طريق العودة الإلكترونية
الإرسال ثم حذف هذا الإرسال على الفور بما في ذلك الكل
المرفقات دون نسخ توزيع أو إفشاء.

هل ما زالت هذه الميزة غير مضافة؟

هذا مهم جدا بالنسبة لي. أنا أعمل على مشروع يتكون من مستودعين منفصلين: واجهة الويب وواجهة برمجة التطبيقات. سيكون من الرائع لو تمكنت من فتح هذين المجلدين في "مشروع" واحد.

بالتأكيد ، يمكنني حل هذا عن طريق استنساخ 2 repos في مجلد واحد وفتح هذا المجلد ولكن هذا لا يعمل مع كل حالة. خاصة إذا كان لديك عدة مشاريع تعتمد على مستودع واحد (أي مشاركة نفس واجهة برمجة التطبيقات).

ستكون هذه الميزة مفيدة أيضًا لأولئك الذين يستخدمون الكود كتوثيق.

JamesTheHacker لفترة من الوقت استخدم vscode-insiders التي تدعم مشاريع متعددة في نفس الوقت. ويمكنك اقتراح ميزات بناءً على ما تشعر به مع الإصدار الداخلي لتحسينه

عند الشحن ، من المحتمل أن يرتفع إصدار VSCode إلى 2.0. فقط أقول :)

سؤال سريع بخصوص هذه الميزة:

تدعم هذه الميزة إضافة مجلدات متعددة مع مستودعات إلى مساحة عمل موجودة. هل ستدعم أيضًا تكوين أحادي الريبو ، حيث أرغب في فتح مشاريع متعددة في ريبو أحادي ، ولكن نظرًا لوجودهم في مستودع واحد ، فليس لديهم git repo خاص بهم. لذلك من وجهة نظر المشروع ، ليس لديهم مجلد .git - يحتوي أحد مجلدات السلف على هذه المجلدات.

قد تسأل لماذا لا تفتح مجلد mono-repo كمجلد واحد كبير وتعمل فيه فقط؟ هناك إجابتان:

1. (أقل إثارة للاهتمام بالنسبة لي) هناك العديد من المشاريع في mono-repo ، وأنا مهتم فقط ببعض منها.
2. تفترض العديد من المكونات الإضافية أن المشروع يحتوي على مشروع واحد فقط. على سبيل المثال ، حزمة npm واحدة فقط. لذلك يبحثون عن الأشياء في _جذر_ المشروع. أمثلة: المكوِّن الإضافي npm لـ VSCode ، والمكوِّن الإضافي mocha لـ vscode ، والكثير من الوظائف في VSCode نفسه - على سبيل المثال ، لا يمكنني تحديد مسار في launch.json المرتبط بـ الملف الحالي ، أي "مجلد node_modules الذي هو أقرب سلف للملف الحالي".

بعد هذا الشرح السياقي ، سؤالي بسيط - هل ستدعم هذه الميزة المشاريع التي يكون المجلد .git هو أصل جذرها؟ إذا كان الأمر كذلك ، فسيكون من الممكن استخدام هذه الميزة في إعادة أحادية.

تضمين التغريدة لا أعرف كيف يدير الأشخاص في Microsoft إصداراتهم ، لكنني أعتقد أنها ميزة ضخمة بما يكفي للتخصص

بعد هذا الشرح السياقي ، سؤالي بسيط - هل ستدعم هذه الميزة المشاريع من هو مجلد .git هو أصل جذرها؟ إذا كان الأمر كذلك ، فسيكون من الممكن استخدام هذه الميزة في إعادة أحادية.

هذا مدعوم بالفعل منذ وقت طويل جدًا ، إذا قمت ببساطة بفتح مجلد فرعي من git repo.

+1

سامية وأتوم تفعل ذلك ما عليك. لا يوجد سبب أفضل. هذا هو MS NEW ، أنجزه يا رفاق ، لدي إيمان كامل بكم. :)

مرحبا،
inestyne إذا كنت تفضل قراءة Jeyanthinath ، فستكون على دراية باستخدام VSCode Insiders لتقييم هذه الميزة بالفعل. حتى أن هناك خارطة طريق يجب التحقق منها. لذا يرجى استخدام المنتج وتقديم الملاحظات قبل أن ينتقل إلى حالة الاستقرار حتى نحصل جميعًا على أفضل منتج ممكن. شكرا لك. يوم جيد.

ما عليك سوى قراءة الموضوع واستخدام Insiders OMG. سأقوم بإلغاء الاشتراك ... أيها المتصيدون الذين لا يقرأون مستحيل. شكرا @ pr-yemibedu

حساس

نظرًا لأن هذا الموضوع مدته سنتان ، ويبدو أن الميزة موجودة في إصدار Insider الآن ، فهل هناك طريقة لتمييز هذا الموضوع بحيث يكون أكثر وضوحًا من قراءة الموضوع بالكامل من الأعلى؟

الشيء الوحيد المفقود هو القدرة على فتح نافذة جديدة بمساحة عمل جديدة من CLI.

jearle يجب إنشاء نافذة / مساحة عمل جديدة كما كان من قبل باستخدام code-insiders <folder> ، أليس كذلك؟
مطلوب code-insiders -a <folder> لإضافة المجلد إلى النافذة الحالية.

تضمين التغريدة تم القيام بنفس الشيء مثل JamesTheHacker وسيساعدني ذلك!

Tyriar للحصول على الوظيفة التي أردتها ، يجب أن أقوم بتنفيذ الأوامر التالية:

code .; code -a .

يفتح code . المجلد على أنه ليس مساحة عمل ، ثم يقوم code -a . بإرفاقه بالنافذة المفتوحة سابقًا كمساحة عمل تسمح لي بفتح نفس المجلد أكثر من مرة.

أنا شخصياً أعتقد أن هذا يحتاج أيضًا إلى التغيير. أنا أعمل مع أيوني وخادم مخصص في مستودعات git مختلفة وهذا ليس بالأمر السهل. القدرة على فتح "علامتي تبويب مشروع" منفصلتين على الأقل أو شيء ما سيكون رائعًا.

لقد تحولت من Atom بسبب بطئها وخطورتها.

@ dark-swordsman ، يمكنك تمكين nativeTabs على نظام Mac

felixfbecker هل هذا ممكن على Windows؟

تحرير: لقد بحثت في ملف الإعدادات بالكامل ولا يوجد خيار لذلك. ثت يسأل لماذا ايم.

تحرير 2: أيضًا ، لا يوجد مورد واضح حول كيفية تمكين vs insiders

مرحبا،
@ dark-swordsman أنت لا تقوم بتمكين VS Insiders. إنه بناء من VSCode يحتوي على بعض الميزات الإضافية التي لم يتم الانتهاء منها لتصبح مستقرة ويمنحك بطريقة ما مساحة اسم محرر إضافية للعمل بها (يمكنك تثبيتها جنبًا إلى جنب دون تعارض في الإعدادات أو الامتدادات). شكرا لك. يوم جيد.

يتم الآن تمكين دعم مساحات العمل متعددة الجذور افتراضيًا في الإصدار الثابت.

يرجى الرجوع إلى وثائق للحصول على شرح كامل لجميع الميزات التي تأتي معها. يجب على مؤلفي الإضافات الرجوع إلى موقع wiki الخاص بنا الذي يشرح واجهات برمجة تطبيقات الإضافة الجديدة لجعل الإضافة جاهزة لمساحات العمل متعددة الجذور. يسعدنا أن بعض الإضافات قد بدأت بالفعل في اعتماد واجهة برمجة التطبيقات الجديدة متعددة الجذور ، شكرًا على ذلك!

يُرجى عدم التردد في تقديم مشكلات للجذور المتعددة عند مواجهتها ، فنحن لا نزال نخطط لإجراء تعديلات وتوفير واجهات برمجة تطبيقات إضافية للإضافات للعمل مع مساحات العمل متعددة الجذور في المستقبل.

هذا رائع ، لكن متى سيكون متاحًا؟ أنت تقول إنه موجود في البنية المستقرة ، لكن لدي أحدث بنية مستقرة (1.17.2) ولا يمكنني التحديث إليه. أيضًا ، في الوثائق التي أشرت إليها للتو ، قال إنه لا يزال في إصدار Insider وسيكون في الإصدار الثابت قريبًا.

أتفهم أنه قد يستغرق وقتًا قصيرًا قبل إصدار الإصدار التالي ، لكنني رأيت هذا الإشعار يتوقع أن يكون متاحًا.

تحرير: أعتذر عن نفاد صبري. كنت أحاول فقط فتح نافذة جديدة بالطريقة اليدوية (اتصل بـ exe. مرة أخرى) ولم يكن يعمل ، لكن لم أبحث في ملف> فتح نافذة جديدة. هذا سوف يعمل الآن. نتطلع إلى إصدار البناء القادم. 👍

bpasero الرجاء إغلاق هذه المشكلة المفتوحة #

مجرد سؤال سريع. هل من الممكن ، عندما أفتح المزيد من المجلدات ، التبديل إلى المجلد الذي أريد تجميعه؟ في الوقت الحالي ، هو دائمًا أول واحد في إصدار ثابت.

تحرير: قد يكون هذا لمنشئ امتداد PlatformIO ، لكنني أسأل كلا الجانبين. فقط في حالة...

DJManas يبدو أن هذا يرجع إلى الامتداد الذي تستخدمه لاتخاذ القرار ، لذا يجب أن تسأل مؤلف الامتداد.

bpasero حسنًا ، لقد فعلت ذلك بالتوازي ، شكرًا لك على الرد.