Vscode: एक ही विंडो में कई प्रोजेक्ट फ़ोल्डर खोलने के लिए समर्थन जोड़ें

सहमत हैं, लेकिन शायद यह स्मृति के लिए एक अनुकूलन समाधान है

+1

मुझे यकीन नहीं है कि मैं पूछना समझता हूं; इसका एक हल्का कोड संपादक, आईडीई नहीं ... आपको कई "प्रोजेक्ट" फ़ोल्डर खोलने की आवश्यकता क्यों है जो पदानुक्रमित नहीं हैं (जहां आप एक पारस्परिक माता-पिता के लिए काम करने का रास्ता तय कर सकते हैं)?

यदि आप ऐसे मॉड्यूल पर काम कर रहे हैं जो डिस्क पर असमान रूप से संग्रहीत हैं जो किसी तरह एक-दूसरे के साथ उस डिग्री पर बातचीत कर रहे हैं, तो वे शुरू करने के लिए बहुत कसकर युग्मित हैं ... क्या आपके प्रोजेक्ट भाई बहन हैं? यदि हां, तो मूल फ़ोल्डर, या माता-पिता / मूल फ़ोल्डर खोलें ... जहाँ भी आपके "समाधान" की जड़ है।

ठीक है, अगर आपके पास कई मॉड्यूल हैं (जो सभी अपने स्वयं के गिट रिपॉजिटरी में हैं) जो एक दूसरे से स्वतंत्र हैं लेकिन आपके पास एक रिपॉजिटरी है जो उन निर्भरता का उपयोग करता है जो इन स्वतंत्र फ़ोल्डरों को खोलने में सक्षम होने और बदलाव करने में सक्षम बनाता है परिलक्षित होता है ताकि आप इसे स्थानीय स्तर पर परख सकें। यह अभी भी एक हल्का कोड संपादक होगा, लेकिन एक अधिक उपयोगी एक imho!

माता-पिता के रूप में इस परियोजना को स्थापित करने के साथ मुख्य मुद्दा यह है कि गिट एकीकरण दूर हो जाता है, दोनों के अलावा अन्य वैध उपयोग के मामले हैं, हालांकि दोनों एक ही माता-पिता हैं।

@stoffeastrom submodules के लिए उपयोग के मामले की तरह लगता है; मुझे यकीन नहीं है कि आपकी परियोजना किसी अन्य का संदर्भ कैसे देगी, जब तक कि आप कुछ तंत्र के साथ एलियासिंग नहीं कर रहे थे, जैसे कि एनपीएम लिंकिंग, आदि। यह समस्या पैकेज प्रबंधकों को बड़े पैमाने पर हल करने के लिए है। यदि मॉड्यूल कसकर युग्मित हैं, तो वे वास्तव में पृथक मॉड्यूल नहीं हैं। आप सड़क के नीचे अन्य उपभोक्ताओं के लिए होने वाले परिवर्तन के बारे में चिंता किए बिना एक परियोजना का समर्थन करने के लिए मज़बूती से बदलाव करने में सक्षम नहीं होंगे। सबमोड्यूल्स के साथ भी, वे केवल उसी कारण से डिफ़ॉल्ट रूप से पढ़े जाते हैं।

किसी भी दर पर, जिस @Tyriar का उल्लेख किया गया है, वह एक कारण है कि मैं इस प्रकार के बहु-कार्य पथ इंटरफ़ेस को एकल उदाहरण / विंडो में रखने से सावधान हूं: आपको एकीकरण (जैसे गिट), एक्सटेंशन, रीफैक्टरिंग, डीबगिंग को संभालना होगा। आदि, आदि सभी कुछ अलग-थलग फैशन में। उदाहरण के लिए:

यदि मैं प्रतिबद्ध करने के लिए git एकीकरण का उपयोग करता हूं, तो क्या मैं प्रोजेक्ट A या प्रोजेक्ट B कर रहा हूं?
यदि मैं टाइपस्क्रिप्ट में एक वर्ग का नाम रिफैक्ट करता हूं, तो क्या यह प्रोजेक्ट ए या प्रोजेक्ट बी, या दोनों में रिफ्लेक्टर होना चाहिए? क्या होगा यदि दोनों परियोजनाओं में एक ही वर्ग का नाम अलग-अलग अर्थों में मौजूद हो? क्या होगा अगर एक दूसरे को शिथिल कर रहा है?

ये सिर्फ कुछ उदाहरण हैं कि कैसे कुछ सरल प्रतीत होता है बहुत जटिल हो सकता है, बहुत जल्दी। मुझे लगता है कि यह अधिक भ्रमित करने वाला तरीका होगा, और स्पष्ट रूप से, VSCode के कुछ अलग-अलग उदाहरणों के बीच alt-tab / cmd + टैब की तुलना में कम उपयोगी होगा, प्रत्येक खुशी से सभी अतिरिक्त प्रयास और किनारे के मामलों के मुद्दों के बिना अपने स्वयं के पृथक कार्य पथ का प्रबंधन करेगा।

Im यह नहीं कह रहा है कि इसे हल नहीं किया जा सकता है, लेकिन मुझे समझ में नहीं आता है कि कई खिड़कियों और / या उदाहरणों के बीच स्विच करना एक मुद्दा क्यों है। हो सकता है कि मुझसे कुछ छूट रहा हो...

उदात्त, एटम, वेबस्टॉर्म - वे "हल्के" कोड संपादक (शायद वेबस्टॉर्म को छोड़कर) भी हैं और वे विभिन्न स्थानों से कई रूट फ़ोल्डर खोलने की अनुमति देते हैं। ये संपादक शायद 99% हैं जो वेब डेवलपर उपयोग करते हैं।
कोड उनके साथ बहुत बेहतर टाइपस्क्रिप्ट समर्थन के साथ प्रतिस्पर्धा कर सकता है (और यह बहुत लोकप्रिय माना जाएगा कि कोणीय 2 आ रहा है) लेकिन केवल अगर यह डेवलपर्स को एक बुनियादी कार्यक्षमता के रूप में उपयोग करने के लिए क्या देगा।

+1

+1

एक गो डेवलपर के रूप में, मुझे यह फीचर सबलेम या इंटेलीज आइडिया में बेहद उपयोगी लगता है। उदाहरण के लिए, मेरा छोटा प्रोजेक्ट गो कोर लाइब्रेरी से कोड आयात करता है या कुछ 3 पार्टी लाइब्रेरी आयात कर सकता है। इसलिए मुझे उन्हें जल्दी से नेविगेट करने और उस कोड को पढ़ने में सक्षम होने की आवश्यकता है।

+1। इसके बजाय एक और टाइपस्क्रिप्ट-सक्षम आईडीई खोजने के बारे में अभी, वीएस कोड में मल्टी-गिट रेपो माइक्रोसवर्क समाधान बहुत दर्दनाक हैं।

हमें निश्चित रूप से किसी तरह के 'समाधान' की जरूरत है। मैं एक देशी देव हूं, और इसमें लगभग हमेशा एक लिब / dll का सेट बनाना शामिल है और फिर कुछ होस्ट ऐप प्रोजेक्ट से उनका जिक्र करना है।
एक बार जब हमारे पास कई परियोजनाएं होती हैं, तो जब हम 'रन' दबाते हैं, तो हमें 'स्टार्टअप प्रोजेक्ट' की भी आवश्यकता होती है।

मैं परियोजनाओं और कई गिट जड़ों के लिए समर्थन भी चाहूंगा। मेरे द्वारा अक्सर उपयोग किए जाने वाला कोड कई git repos में पाया जाता है और मेरे वर्तमान कार्यक्षेत्र को बंद किए बिना उन दोनों के बीच स्विच करने में असमर्थ होने के कारण और दूसरे को खोलने के लिए केवल एक को खोलने के लिए बंद कर दिया जाता है और पिछले को खोलने के लिए बंद किया जाता है। यदि मैं मूल फ़ोल्डर को जोड़ता हूं, जहां मेरे सभी प्रतिनिधि रखे गए हैं, तो मैं अपनी फ़ाइलों के बीच नेविगेट और खोज करने की क्षमता हासिल करता हूं, लेकिन मैं गिट एकीकरण खो देता हूं। यह असली बमर है।

"टेक्स्ट एडिटर" और "आईडीई" के बीच की रेखा बहुत ख़तरनाक धुंधली है और मुझे वास्तव में परवाह नहीं है कि वीएस कोड क्या है। मुझे क्या परवाह है कि एक उपकरण क्या कर सकता है और इसका उपयोग करने के लिए कितना दर्द रहित है। मुझे लगता है कि परियोजना का समर्थन मेरे जैसे लोगों के लिए बहुत सारे घर्षण को कम करेगा।

जब आपके वर्कस्पेस में मल्टीपल रिपोज होते हैं, तो मैं भी जीआईटी इंटीग्रेशन का काम देखना चाहूंगा, लेकिन मैं सिर्फ @ लोरेन-जॉनसन जैसे लोगों को यह सुनिश्चित करना चाहता हूं कि वे एक साथ कई बनाम कोड विंडो खोल सकते हैं।

यह प्रतिक्रिया में है: "मेरे वर्तमान कार्यक्षेत्र को बंद किए बिना उनके बीच स्विच करने में असमर्थ"

आपका मतलब है # 2686 इसका एक डुप्लिकेट है?

क्षमा करें, मैंने वर्णन को गलत बताया और इसे फिर से खोल दिया।

+1

क्या इस मुद्दे पर कोई प्रगति हुई है, या कम से कम कुछ बयान अगर यह कभी लागू किया जाएगा? क्या कोड में कुछ निम्न-स्तरीय निर्णय हैं जो एक परियोजना में कई जड़ों को रोकते हैं?

यह बहुत ही एकमात्र कारण है जो मैं ST3 से VSCode पर नहीं जा रहा हूं।

+1

+1

+1

+1 यह बहुत मददगार होगा। गिट सबमॉड्यूल का उपयोग करने का सुझाव बहुत असुविधाजनक है। इस सुविधा को पसंद करेंगे।

एक प्रारंभिक हल्का दृष्टिकोण कुछ इसी तरह का होगा जो गिट-प्रोजेक्ट-मैनेजर एक्सटेंशन करता है। दृष्टिकोण मूल रूप से संदर्भ / रूट को स्विच करने के लिए हो सकता है जो परिवर्तन के रूप में देखता है, लेकिन जो फ़ाइल ब्राउज़र देखता है उसके लिए संदर्भ / रूट को बदले बिना। यह एक्सटेंशन सही काम करता है, स्विचिंग को तेज़ बनाने के लिए बस एक सख्त एकीकरण की आवश्यकता है।

+1

+1 - मैंने git सबमॉड्यूल का उपयोग करने के रास्ते पर जाना शुरू कर दिया है, लेकिन यह वास्तविक समाधान की तुलना में हैक की तरह महसूस करता है।

+1

+1

मैं फ़ोल्डर्स के बीच स्विच करने के लिए git-project-manager एक्सटेंशन का उपयोग कर रहा हूं, लेकिन वास्तव में एक बार में कई फ़ोल्डर्स खोलने का विकल्प रखना पसंद करेंगे।
+1

केवल इतना कहना चाहता हूं कि प्रोजेक्ट मैनेजर एक्सटेंशन का मालिक इस मुद्दे पर भी इंतजार कर रहा है।

कुछ टिप्पणियों (ऊपर) के संबंध में, मैं सिर्फ यह कहना चाहता हूं कि हम सभी अलग हैं, हम सभी के पास हमारे विशेष परियोजनाओं पर हमारे काम को निष्पादित करने के हमारे विशेष तरीके हैं। यह तथ्य UX को पहले से अधिक महत्वपूर्ण बनाता है।

हम सभी जानते थे कि "ओपन फोल्डर ...", "ओपन प्रोजेक्ट ..." जैसी चीजों के साथ vscode में अनिवार्य रूप से प्रोजेक्ट मैनेजमेंट करने वाला पहला बेबी स्टेप था, और आगे भी। बस वहाँ से बाहर अन्य सभी संपादकों की तरह, विशेष रूप से SublimeText (जो कि मैं कहाँ से आया हूँ)।

मेरे लिए, यह समस्या उत्पाद के UX में सुधार है। और हम सभी जानते हैं कि यूएक्स राजा है।

मैं लगभग महसूस करता हूं कि इस तरह का सामान कानून होना चाहिए, और इसलिए टैग "सुविधा अनुरोध" के बजाय "सुविधा अनुस्मारक" होना चाहिए।

इस मुद्दे को vscode में किसी भी अन्य मुद्दों पर सर्वोच्च प्राथमिकता होनी चाहिए। केवल इसलिए कि UX राजा नहीं है, लेकिन क्योंकि मैं अभी इस एक के अलावा vscode के साथ किसी अन्य मुद्दे का अनुभव नहीं कर रहा हूं ... तकनीकी रूप से।

मैं मूल रूप से यह पूछने के लिए ब्राउज़ कर रहा था कि Microsoft केवल इन प्रोजेक्ट-जैसे एक्सटेंशन को ले सकता है और सीधे VSCode में एकीकृत कर सकता है, और इसे UX में सुधार कर सकता है, उदाहरण के लिए मेनू में "प्रोजेक्ट ..." जोड़कर।

धन्यवाद,
+1

+1

इस सुविधा के लिए मेरा उपयोग मामला यहाँ वर्णित है: # 9515। (इसे इस मुद्दे के डुप्लिकेट के रूप में बंद कर दिया गया था।)

मुझे उम्मीद है कि यह सुविधा होती है!

+1

@ poidl, @ mastrauckas , @mdedgjonaj , @alanleite , @Xcorpio , @mibanez , @josebalius & @brusbilis :
कुछ समय पहले GitHub ने प्यारे "अपनी प्रतिक्रिया जोड़ें" -feature (किसी टिप्पणी या मुद्दे के प्रत्येक ऊपरी दाएं कोने पर स्माइली देखें?) का परिचय दिया।
वे आपकी रुचि के बारे में VSCode टीम को सूचित करने के उद्देश्य से सेवा करते हैं लेकिन व्यर्थ +1 टिप्पणियों को रोकते हैं। यह अन्य लोगों को भी रोकता है जिन्होंने एक निश्चित अंक या एमआर को एक अधिसूचना प्राप्त करने के लिए सदस्यता ली है और इसलिए मूल्यवान समय बचाता है। एक और बोनस यह है कि मुद्दों / एमआर को most reaction द्वारा हल किया जा सकता है जो इसे VSCode टीम के लिए तुरंत दिखाई देता है जो उपयोगकर्ताओं के लिए प्रासंगिक है। उस के शीर्ष पर VSCode के लिए एक

यह टिप्पणी स्वयं मेटा है और इसलिए अर्थहीन भी है। मुझे इसके बारे में खेद है लेकिन मुझे लगा कि यह शैक्षिक उद्देश्यों के लिए आवश्यक है। इस टिप्पणी का हर सीधा जवाब (= अधिक मेटा) मुझे उपयोगकर्ता को अवरुद्ध करने में परिणाम देगा।
reaction सुविधा का उपयोग करके केवल इस टिप्पणी पर प्रतिक्रिया करके व्यायाम करें!

@Poidl के उत्तर के लिए: फिर बिल्कुल भी उत्तर न दें!

मैं उस स्माइली को नहीं देखता। कम से कम मोबाइल पर। खुश अवरुद्ध!

@poidl हाँ प्रतिक्रिया सुविधा GitHub मोबाइल साइट पर दुर्भाग्य से (कई अन्य सुविधाओं के साथ) उपलब्ध नहीं है। साइट के नीचे "डेस्कटॉप संस्करण" बटन दबाकर आप इसे मोबाइल पर प्राप्त कर सकते हैं।

@ dj-hedgehog की सलाह हालांकि मौके पर है, GitHub प्रतिक्रियाएं हमें टिप्पणी की गिनती के लिए अधिक प्रभावी रूप से सामुदायिक हित में कुछ करने की अनुमति देती हैं। इसके अतिरिक्त, हम उपयोगकर्ता की आवाज को हटाने की योजना बना रहे हैं ताकि GitHub मुद्दे और प्रतिक्रियाएं हमारे फ़ीचर अनुरोधों के लिए सच्चाई का स्रोत हों।

+1

+1

इस समस्या का मेरा समाधान: मेरी परियोजना की जड़ का एक प्रतीकात्मक लिंक बनाएं।
तो अगर मेरे पास है:
project/modules/gitmodule

मैं अपने gitmodule फ़ोल्डर में जाता हूं और करता हूं:
ln -s ../../../project .project

अब मैं अपना gitmodule फ़ोल्डर vscode में खोल सकता हूं और अभी भी पैरेंट प्रोजेक्ट फ़ोल्डर तक पहुंच सकता हूं।
मैं फ़ाइल नाम में एक डॉट का उपयोग करता हूं, इसलिए यह एक्सप्लोरर में मेरी सूची के शीर्ष पर स्थित है।
जाहिर है, मुझे ऐसा नहीं करना होगा, लेकिन मुझे लगा कि यह आप में से कुछ के लिए उपयोगी हो सकता है।

लगभग भूल गया: अपने .gitignore के लिए प्रतीकात्मक लिंक जोड़ने के लिए मत भूलना

+1

यह एक आधुनिक पाठ संपादक के लिए एक बहुत महत्वपूर्ण विशेषता है। कृपया उस "समस्या" का समाधान करें।
कुछ समय के लिए, मुझे उन सभी निर्देशिकाओं को कॉपी और पेस्ट करना पड़ा है जो मेरे वास्तविक कार्य फ़ोल्डर के लिए उपयोग की जाती हैं और यह Sublime Text में इतना सामान्य है।

परियोजना> उदात्त पाठ में प्रोजेक्ट के लिए फ़ोल्डर जोड़ें जोसन संरचना में एक नया रास्ता बढ़ाता है।

देखिए साथी:
{ "folders": [ { "path": "~/cpp" }, { "path": "~/python" } ] }

उदाहरण के लिए शेफ के साथ काम करते समय, एक फ़ोल्डर संरचना को देखना आम है:

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

जहां रूट फ़ोल्डर (कुकबुक) के तहत कुकबुक (कुकबुक 1 उदाहरण के लिए) स्वतंत्र गिट रिपोज हैं। यह बहुत आम है। अब आपको कुकबुक 4 पर काम करना होगा लेकिन इसमें कुकबुक 2 और कुकबुक 3 शामिल हैं। आपको प्रायः सभी 3 को खोलने की आवश्यकता होगी, या तो केवल कोड को संदर्भित करना होगा या वास्तव में सभी 3 में कोड को संपादित करना होगा या रिफलेक्टर करना होगा।

2 सामान्य (सिम्प्लेक्स हैक्स नहीं) विकल्प उन मुद्दों को प्रस्तुत करते हैं जो कोई डेवलपर नहीं चाहता है:

1. जैसा कि ऊपर कई बार बताया गया है, आपको अब कई विंडो खोलनी होंगी (अच्छी नहीं)
2. यदि आप सभी 3 को देखने के लिए कुकबुक को रूट के रूप में खोलते हैं, तो आप गिट इंटीग्रेशन खो देते हैं क्योंकि कुकबुक फ़ोल्डर एक रीपो नहीं है (यह भी नहीं है)

+1, ग्रहण आईडीई उपयोगकर्ता यहाँ है जिसमें पूर्ण 'कार्यक्षेत्र' नियंत्रण है।

विजुअल स्टूडियो कोड एक आईडीई नहीं है। यह एक लाइट-वेट क्रॉस-प्लेटफॉर्म एडिटर है, जैसे एटम या सबलाइम। ग्रहण, Xcode, विज़ुअल स्टूडियो, एट। सभी की तुलना में किन्नर हैं।

क्षमा करें, मुझे यकीन नहीं है कि आप इस सुविधा के खिलाफ या इसके लिए बहस कर रहे हैं ... एटम, उदात्त, VIM, Emacs आपको एक उदाहरण में कई फ़ोल्डर खोलने की अनुमति देते हैं। हल्के वजन या नहीं यह एक अच्छी सुविधा है, IntelliJ IDEA - एक IDE - उदाहरण के लिए आपको कई प्रोजेक्ट अभी भी खोलने की अनुमति नहीं देता है।

@ यहाँ सुविधाओं के लिए कहा जा रहा है सिर्फ आईडीई सुविधाएँ नहीं हैं, सुविधाओं के लिए कहा जा रहा है सभी _editors_ के लिए आम हैं आप ने कहा कि Visual Studio कोड _like_ है।

परमाणु, उदात्त, और अन्य हल्के संपादक सभी कई फ़ोल्डर्स खोल सकते हैं।

मैं, व्यक्तिगत रूप से, परवाह नहीं करता हूं कि क्या यह विशेषता उत्पाद में समाप्त होती है या नहीं - मुझे समझ में आता है कि कुछ लोग इसे क्यों चाहते हैं, लेकिन मैं यह कहना चाहूंगा कि यह सब कुछ थोड़ा और जटिल बनाता है। उदाहरण के लिए: जब रेगेक्स एक्सप्रेशन का उपयोग करके खोज करते हैं - मैं कौन सा कार्यक्षेत्र खोज रहा हूं? एक? सब?

क्या होगा यदि मेरे पास एक फ़ोल्डर है जिसमें एक नोडज परियोजना है जहां मेरी टैब चौड़ाई आम तौर पर 2 स्थान है, और एक फ़ोल्डर एक डॉटनेट परियोजना है जहां मेरी टैब चौड़ाई 4 रिक्त स्थान है? कोड को प्रत्येक फ़ोल्डर के लिए कार्यक्षेत्र सेटिंग्स के बारे में पता होना चाहिए और पूरे संदर्भ को बनाए रखना होगा।

ये केवल कुछ उदाहरण हैं जहां एक ही उदाहरण के भीतर कई कार्यक्षेत्र मुश्किल हो सकते हैं। मैं बस इतना ही कह रहा हूं कि यह सुविधा केवल खोजकर्ता के कई रास्ते दिखाने की तुलना में अधिक शामिल है।

@ कपट और उदात्त और परमाणु से अधिक

यहाँ एक तथ्य है, यह पसंद है या नहीं और इसका आपके या मेरे चाहने वालों से कोई लेना-देना नहीं है। यदि समान मूल्य बिंदुओं (इस मामले में मुफ़्त) पर अन्य समान सॉफ़्टवेयर में बेहतर या अधिक सुविधाएँ हैं, और डेवलपर इस तथ्य की उपेक्षा करता है, तो .. यह सॉफ़्टवेयर पीछे रह जाएगा।

मैं इस संपादक के साथ ऐसा नहीं देखना चाहता। मुझे लगता है कि इस संपादक में बहुत अच्छी क्षमता है और कुछ समय के लिए प्रासंगिक रह सकता है _if_ डेवलपर्स इसके उपयोगकर्ता आधार की चाह / जरूरतों को सुनते हैं।

फिर; मैं इसके लिए या इसके खिलाफ बहस नहीं कर रहा हूं - बस ध्यान रखें कि यह बहुत नया संपादक है जो अपने प्रतियोगियों की तुलना में कहीं अधिक बॉक्स संदर्भ से बाहर है - इसे कुछ समय दें।

शेफ और गिट इंटीग्रेशन के साथ आपके उदाहरण में भी - आप किस तरह से रेपो को कमिट कर रहे हैं? वर्तमान यूआई को निरंतर संदर्भ-स्विचिंग के लिए अनुकूल करने की आवश्यकता होगी - ओमनीशरप के लिए, जो कि कोरसीएलआर परियोजनाओं के लिए सिंटैक्स हाइलाइटिंग आदि प्रदान करने के लिए एक सर्वर और रसलिन का उपयोग कर रहा है। निहितार्थ बहुत दूर तक पहुंच रहे हैं और बहुत अच्छी तरह से सोचा जाना चाहिए।

इस विचार पर कोई तर्क नहीं है कि सुविधाओं को अच्छी तरह से योजनाबद्ध करने और विचार करने की आवश्यकता है। मुझे लगता है कि एक दिया है। मुझे लगता है कि सभी उपयोगकर्ता खुश होंगे यदि यहां जवाब "यह रोडमैप पर है" या "हम उस छोर की ओर काम कर रहे हैं"। मैं केवल इतना कह रहा हूं कि एक "नहीं" शायद रात भर में कुछ उपयोगकर्ताओं को मार देगा।

संदर्भ के रूप में स्विच और शेफ में गिट रिपोस, हाँ सहमत हुए ... यह सब सच है और सभी पहले से ही अन्य खुले स्रोत संपादकों में पूरा किया गया है। आप खुले स्रोत के बारे में महान बात जानते हैं ,,, यह खुला है! कोड को देखें, विचार प्राप्त करें, बिल्ली भी इसमें से कुछ का उपयोग करें (लाइसेंस को आवश्यकतानुसार शामिल करना सुनिश्चित करें)। यह फॉस (फ्री ओपन सोर्स सॉफ्टवेयर), सहयोग और ज्ञान साझा करने के बारे में महान चीजों में से एक है। चूंकि यह संपादक पहले से ही एटम कोड का उपयोग कर रहा है ... मुझे लगता है कि यह भी एक दिया जाएगा।

मुझे यह उल्लेख https://github.com/Microsoft/vscode/wiki/Roadmap में मिला

वीएस कोड एक युवा उत्पाद है और अभी भी लापता विशेषताएं और अनुभव हैं जो आप के लिए पूछ रहे हैं और जिसे हम वितरित करना चाहते हैं।
....
....

• एक कार्यक्षेत्र के अंदर कई फ़ोल्डर

मुझे लगता है कि कोई भी यह नहीं कहता है कि यह सुविधा सरल है (जैसा कि हम सभी डेवलपर हैं, हम जान सकते हैं कि बदलाव की आवश्यकता क्या है) और मैं अतिथि लोगों को इस टिकट पर टिप्पणी करता हूं कि यह दिखाना है कि यह कितना महत्वपूर्ण है, यह कितनी प्राथमिकता होनी चाहिए। और इस सुविधा की तुलना कुछ VS कोड भाइयों (एटम, उदाहरण के लिए उदात्त) से कैसे की जाए।

लेकिन क्योंकि यह पहले से ही रोड मैप में है (कोई भी इस बात की पुष्टि कर सकता है कि विकी पेज अभी भी सही है) हमें इस बारे में चर्चा करनी चाहिए कि इसे कैसे लागू करने के बजाय सिर्फ यह कहा जाए कि हमें इसकी आवश्यकता कैसे है और यह कितना महत्वपूर्ण है (फिर से, मुझे लगता है कि वीएस कोड कोर टीम पहले से ही है जानते हैं कि हमें इसकी आवश्यकता कैसे है और यह सुविधा कितनी महत्वपूर्ण है)।

मैं वीएस कोड स्रोत कोड से परिचित नहीं हूं, क्या कोई मुझे बता सकता है कि क्या मैं इस सुविधा को लागू करना चाहता हूं, मुझे पहले कहां देखना चाहिए? पहले चरण में मैं केवल कई फ़ोल्डर खोलना चाहता हूं और इसे बाईं पट्टी पर दिखाना चाहता हूं।

@nvcnvn यह उतना तुच्छ नहीं है जितना कि इसे लागू करने के लिए लग सकता है क्योंकि बहुत सारे vscode मानते हैं कि केवल एक ही फ़ोल्डर खोला जा सकता है। जैसे कि इसे UX से गुजरने और कोडबेस के कई हिस्सों को छूने की संभावना होगी, संभावित रूप से विस्तार एपीआई पर भी प्रभाव पड़ेगा।

मुझे याद है जब एटम बाहर आया था, उसी _single फ़ोल्डर_ सीमा के साथ। शिकायतें भी वही थीं, विशेष रूप से उदात्त के साथ तुलना। फिर, जब _multiple फ़ोल्डर_ समर्थन जारी किया गया था, तो नए एपीआई के कारण कुछ पैकेज (एक्सटेंशन) टूट गए थे। अन्य लोग नहीं टूटे, लेकिन साथ ही साथ इसका समर्थन भी नहीं किया। पूरे पारिस्थितिकी तंत्र में _stable_ बनने तक कुछ समय लगा।

जैसा कि @Tyriar ने कहा, कुछ UX और एक्सटेंशन API प्रभाव होंगे, और संभवतः नए API को अपनाने के लिए कोर और एक्सटेंशन डेवलपर्स के लिए एक व्यस्त _Insider_ रिलीज़ होगा।

तो यहाँ वास्तव में क्या तर्क दिया जा रहा है?
मेरा मतलब है कि मैं देख रहा हूँ "सुधार नहीं है क्योंकि यह चीजों को तोड़ सकता है" ...

संकेत:
CODE में सभी इम्प्लॉइमेंट्स सिमेटिंग कर सकते हैं!

यह डिबगिंग, रीफैक्टरिंग, पूर्व-रिलीज़ (अल्फा, बीटा, आरसी, आदि ...) का बिंदु है
गंभीरता से आओ? मैं कभी भी एक गंभीर प्रोग्रामर से नहीं मिला जो कोड में सुधार करने से डरता था क्योंकि यह कुछ तोड़ सकता है। सतर्क रहें हां, अपना समय लें और सुरक्षित रहें हां, लेकिन कभी भी "नहीं" कहें, यह चीजों को तोड़ सकता है

@ddreggors मैं बहस नहीं कर रहा हूँ, मैं बस मुद्दे के बारे में कुछ जानकारी बता रहा हूँ। मैंने कहा कि मैंने क्या कहा ताकि @nvcnvn इस के लिए एक पीआर बनाने की कोशिश न करे क्योंकि हितधारकों की सूची के कारण टीम को यह करना होगा।

जैसा कि @nvcnvn ने बताया, यह मुद्दा रोडमैप पर है जिसका अर्थ है कि टीम जल्द ही इसे देख लेगी। हम अपेक्षाकृत छोटी टीम हैं, हालांकि बहुत सी चीजों को ढंकने के लिए इसलिए कुछ चीजों में देरी की जरूरत है।

@ टियारर अंडरस्टूड , मैं बस कई लोगों के इन टिप्पणियों को देख रहा हूं जो यह सुझाव देते हैं कि यह एक कारण या किसी अन्य के लिए इस सुविधा को नहीं जोड़ना सबसे अच्छा है। इनमें से सबसे बुरा इस तथ्य के कारण था कि कोड एक आईडीई नहीं है, जब दूसरों ने स्पष्ट रूप से अन्य संपादकों की तुलना आईडीई से नहीं की थी। इसने मुझे इस बदलाव की आशंका की जड़ में ले जाना चाहा, यदि संभव हो तो इसे अतीत में बदल दिया जाए।

मैं उस पीआर की चिंता को पूरा नहीं होने के बारे में समझ सकता हूं, हालांकि यह एक अच्छी शुरुआत हो सकती है ... उस बदलाव को एक शाखा में मर्ज करें और इसे आधार के रूप में उपयोग करें। इसका उपयोग टूट-फूट को देखने और उन्हें ठीक करने के लिए करें।

इससे पहले कि यह हमारी UX मीटिंग्स में चर्चा में आए , किसी को भी इसे छूने के लिए

पर्याप्त रूप से, आप उस छोर पर सबसे अच्छे से जानते होंगे। यह जानना अच्छा है कि इस पर चर्चा की जा रही है। :-)

प्रयासों के लिए धन्यवाद, और एक बहुत अच्छे संपादक की शुरुआत की तरह क्या दिखता है।

यह आपकी UX बैठकों के लिए इस विषय पर सुझाव देने के लिए एक व्यर्थ प्रयास प्रतीत होता है:

मैं अस्थायी रूप से एटम पर वापस चला गया क्योंकि यह 1.9 रिलीज में बहुत अधिक स्थिर हो गया है। किसी भी बड़ी फ़ाइल को खोलने पर यह क्रैश हो जाता था और कुछ बिंदु पर VSCode की जाँच शुरू करने का मुख्य कारण यही था। वास्तव में एक खिड़की में कई परियोजनाओं को देखने के लिए उत्सुक हैं - ऐसा लगता है कि मुझे कुछ भी नहीं मिला है, लेकिन तब तक इस धागे का पालन करना।

Microsoft लोग इस पर ध्यान केंद्रित क्यों नहीं कर रहे हैं?

+1

+1

मुझे वास्तव में वीएस कोड बहुत पसंद है। यह मेरा प्राथमिक संपादक बन गया है, लेकिन एक समय में 2 से अधिक परियोजनाओं में काम करना मुश्किल हो गया है। इन दो खुले मुद्दों पर एक दोहरी मार है: यह एक, और शीर्षक बार जानकारी कॉन्फ़िगर करना ।

या तो इन सुविधाओं में से एक समस्या का समाधान करेगा (हालांकि आदर्श रूप से, मैं दोनों को पसंद करूंगा!)। मुझे लगता है कि मैं एक भी फ़ोल्डर के तहत काम करने और इसे खोलने के साथ सब कुछ डालने का मन नहीं करता हूं - लेकिन फिर गिट एकीकरण काम नहीं करता है, और केवल एक परियोजना के भीतर खोज करने या परियोजना द्वारा परिणामों को व्यवस्थित करने का कोई तुच्छ तरीका नहीं है।

मुझे लगता है कि प्रत्येक प्रोजेक्ट को एक अलग भौतिक वीएस कोड विंडो में खोलने का मन नहीं करता है और मेरे ओएस को इंस्टेंस का प्रबंधन करने देता है - लेकिन क्योंकि टाइटल बार खुली फाइल का नाम दिखाता है, बजाय कुछ रूट फ़ोल्डर / प्रोजेक्ट आइडेंटिफायर के, इसे स्विच करना असंभव है प्रत्येक सक्रिय उदाहरण को खोलने और देखने के बिना एक और विशिष्ट ओपन प्रोजेक्ट। यह कुछ ऐसा बनाता है जो निरंतर झुंझलाहट में सहज होना चाहिए।

कृपया - क्या ऐसा कोई तरीका है जो इन दोनों विशेषताओं में से किसी एक को जोड़ना प्राथमिकता बन सकता है? मैंने वह सब कुछ आज़माया है जिसके बारे में मैं सोच सकता हूँ कि मैं इसके चारों ओर काम कर सकूँ, मैंने एक घंटे का समय दिया जिसमें कुछ विंडोज टास्कबार के विकल्प की तलाश थी जो मुझे एक सूची से विंडोज़ चुनने देता था जो कि शीर्षक में अधिक पाठ दिखा सकता था लेकिन मुझे नहीं मिल रहा था कुछ भी।

अगर किसी के पास कई खुले वीएस कोड परियोजनाओं को प्रभावी ढंग से प्रबंधित करने का कोई सुझाव है तो मैं उन्हें सुनना पसंद करूंगा।

एटम में अच्छी तरह से काम करने वाली महत्वपूर्ण बात यह है कि प्लगइन्स, जैसे कि एस्लेंट, को अभी भी परियोजना स्तर पर काम करना चाहिए। इसलिए यदि प्रोजेक्ट ए के अपने स्वयं के नियम हैं, तो प्रोजेक्ट बी उन नियमों से प्रभावित नहीं होना चाहिए और इसके विपरीत। कोड में ऐसे UX होने का इंतजार नहीं कर सकता। यह निश्चित रूप से एक है, अगर अभी सबसे बड़ा दत्तक बाधा नहीं है।

यही एक चीज है जो मुझे इसे अपनाने के लिए पकड़ रही है।

मुझे पता है कि आपके पास ठीक करने के लिए कई अन्य मुद्दे हो सकते हैं और अन्य सुविधाओं को लागू करने के लिए, लेकिन, आरंभ करने के लिए कम से कम कुछ मूल समर्थन भयानक होंगे।

VSCode पर कड़ी मेहनत के लिए धन्यवाद!

+1

जब तक यह सुविधा लागू नहीं होती है (यदि कभी भी), तो क्या मैं सुझाव दे सकता हूं कि आप फ़ाइल नाम से पहले प्रोजेक्ट का नाम दिखाने के लिए टाइटल बार को कॉन्फ़िगर करने की क्षमता जोड़ें। इस तरह से कम से कम अलग-अलग vscode विंडो के बीच अंतर करना संभव होगा जो विभिन्न परियोजनाओं के लिए खुले हैं। # 1723 देखें।

मेरे लिए भी यह शो स्टॉपर है। मैं देख रहा हूँ कि कुछ देवता आश्चर्यचकित हैं कि आपके पास एक ही बार में कई git repos क्यों हैं। यह लगभग किसी भी भाषा के साथ होता है जो तीसरे भाग के मॉड्यूल का उपयोग करता है। बस php - कंपोज़र, js - बोवर, नोड - npm, गोलंग आदि को देखें। यह एक प्रोजेक्ट शुरू करने के लिए बहुत आम है जो आपके कुछ मॉड्यूल का उपयोग करता है और आप प्रोजेक्ट के दायरे में बदलावों को संपादित और प्रतिबद्ध करना चाहते हैं।

नेस्टेड निर्देशिकाओं में .vscode/settings.json को पहचानने के लिए कम से कम समर्थन है। किसी एक परियोजना पर काम करते समय, सेटिंग्स के विभिन्न सेटों के साथ उपप्रकार हो सकते हैं और जो अलग-अलग (गिट) रिपॉजिटरी बनते हैं। जैसे

root/
    server/
        .vscode/
            settings.json // <== affects all files in the server/ directory
        code/
            tsconfig.json
            foo.ts
    client/
        .vscode/
            settings.json // <== affects all files in the client/ directory
        code/
            tsconfig.json
            foo.ts
    .vscode/
        settings.json // for any file not in server/ or client/

मुझे उम्मीद है कि vscode ले जाएगा (और शायद विलय) निकटतम फ़ाइल की तरह बहुत सारी मूल निर्देशिका की सेटिंग्स ( .eslint , .gitignore , .editorconfig , tsconfig.json , 'package.json` ....)।

इसलिए, जब मैं /root खोलता हूं, तो root/server/ में किसी भी फ़ाइल को संभालना चाहिए जैसे कि मैं root/server/ सीधे खोलूंगा। सबसे सरल उपाय यह होगा कि पेरेंट डायरेक्टरीज़ में सेटिंग्स की खोज एक .vscode/settings.json फ़ाइल को मिले।

यह वास्तव में जरूरत है।

+1। मेरे लिए डीलब्रेकर।

यह वास्तव में जरूरत है। +1

एक vscode कार्यक्षेत्र के तहत घोंसले फ़ोल्डर्स के लिए एक समाधान है। बस इस mklink /d link target कार्यक्षेत्र के फ़ोल्डर में एक प्रतीक लिंक बनाने के लिए

मैं सहमत हूँ - मुझे लगता है कि यह अनुरोध एक निश्चित आवश्यकता है।
आपके पास हमेशा एक फ़ोल्डर में एक परियोजना नहीं होती है - आपके पास सहायक और भाई के फ़ोल्डर हो सकते हैं और इस सुविधा का न होना मेरे लिए अभी के लिए एक वास्तविक सौदा ब्रेकर है - यही कारण है कि मुझे उदात्त का उपयोग करना होगा।
कृपया इसे जोड़ें!

बाईं ओर आप उस फ़ोल्डर को दिखाते हैं जो आप एक परियोजना के रूप में हैं। यह काम कर सकता है यदि आपके पास यह था जहां आप प्रत्येक फ़ोल्डर क्षेत्र (परियोजना) को वहां देख सकते हैं। आप इसे विस्तारित कर सकते हैं और इसे वैसे ही ध्वस्त कर सकते हैं जैसे आप करते हैं (लेकिन कई फ़ोल्डर क्षेत्रों के लिए)।

एक भयानक संपादक अगर केवल मैं दो परियोजनाओं के बीच स्विच कर सकता था। एक वास्तविक डीलब्रेकर।

हाय सब, मैं गिट परियोजना प्रबंधक विस्तार की सलाह देते हैं अगर आप इस बीच में परियोजनाओं के बीच स्विच कर रहे हैं। यह .git फ़ोल्डर वाली निर्देशिकाओं के लिए एक निर्देशिका को स्कैन करता है और उन्हें त्वरित स्विचिंग की अनुमति देता है, मैं कुछ हफ्तों से इसका उपयोग कर रहा हूं और यह निश्चित रूप से इसे आसान बनाता है।

जब मैं प्रोजेक्ट स्विच करता हूं तो या तो मैं जाता हूं:

1. ctrl + alt + p
2. परियोजना का प्रकार प्रारंभ, उदा। vscode के लिए "vsc"
3. दर्ज

या अगर मैं एक और विंडो में प्रोजेक्ट खोलना चाहता हूं तो मैंने ctrl + shift + n को पहले ही हिट कर दिया। यदि आप अपनी चीज़ को भी खोल सकते हैं, तो आप एक्सटेंशन को हमेशा एक नई विंडो में खोल सकते हैं।

यह एक स्क्रीन शॉट है जिस पर आप आसानी से कई प्रोजेक्ट बना सकते हैं।

@ soljohnston777 समस्या यह है कि git इंटीग्रेशन (या किसी अन्य प्रकार का VS कोड

समस्या यह है कि गिट एकीकरण (या किसी अन्य प्रकार का वीएस कोड कॉन्फिगरेशन) एक फ़ोल्डर स्तर पर समर्थित नहीं है।

हुह सच में? क्या VSCode ने ग्रहण त्रुटियों को दोहराया जब यह कार्यक्षेत्र अवधारणा के लिए आता है? यह जानकर आश्चर्य होगा, कि VSCode टीम के कुछ सदस्य कोर एक्लिप्स टीम का हिस्सा रहे हैं ...।

क्या VSCode ने त्रुटियों को दोहराया जब यह कार्यक्षेत्र अवधारणा पर आता है

मैं यहाँ वास्तुकारों के दर्शन के लिए बात नहीं कर सकता, लेकिन यह तथ्य (यह प्रति-विन्यास है और प्रति फ़ोल्डर नहीं) इस मुद्दे और चर्चा का पूरा कारण है।

आप परियोजनाओं के लिए अलग-अलग वीएसकोड विंडो का उपयोग कर सकते हैं। इसे VSCode के अंदर क्यों लागू नहीं किया गया है? (साइड प्रोजेक्ट बटन प्रति अलग विंडो - बस इसे अंदर देखें)। यह कार्यक्रम के अंदर इसे कोड करने की परेशानी से बचाएगा, फिर भी परियोजनाएं अंदर दिखाती हैं, और एकीकृत और विकसित करना आसान बनाती हैं।

Git को स्वतंत्र रूप से कई प्रोजेक्ट्स के लिए प्रत्येक फ़ोल्डर क्षेत्र के लिए रखा जा सकता है ... मुझे GSC को VSCode के साथ भ्रमित करने वाला लगता है, इसलिए मैं बस कमांड लाइन को वैसे भी करने की प्रवृत्ति रखता हूं (जो आपको लगता है कि आपको VSCode में ऐसा करने में सक्षम होना चाहिए)।

एक पैरेंट फोल्डर हाउसिंग सबफ़ोल्डर्स के पास जो स्वतंत्र गिट रिपॉजिटरी हैं, वास्तव में सहायक हैं जब वे सभी एक ही प्रोजेक्ट से संबंधित होते हैं। यह उपलब्ध देखना पसंद करेंगे, सेटिंग्स में एक वैकल्पिक कॉन्फ़िगरेशन ध्वज के साथ कम से कम।

मैं भी कई git repos के लिए git समर्थन करने में अपनी मजबूत रुचि व्यक्त करना पसंद करता हूं।

+1। यह एक मुख्य विशेषता है जो मेरे मुख्य संपादक के रूप में VSCode को अपनाने से रोकता है।

+1

+1 - विशेष रूप से उन लोगों के लिए जो माइक्रोसेवा / कई-रेपो कोडबेस के साथ काम करते हैं, यह कुंजी है। (कुंजी: उन सभी को एक साथ नहीं खोलना, लेकिन उनके बीच स्विच करना, और संपादक को याद रखना कि कौन सी फाइलें खुली थीं और कौन से कार्यस्थल हैं।)

+1
हमारा सेटअप जीआईटी रेपो पर कोर कोड की तरह कुछ है, एक अन्य रेपो में कुछ क्षेत्रीय कोड, और एक अन्य रेपो में विशिष्ट कोड प्रोजेक्ट करते हैं इसलिए जब आप किसी प्रोजेक्ट पर काम करते हैं तो आपको तीनों (या अधिक) रेपो से कोड की आवश्यकता होती है। यह एक "प्रोजेक्ट" करने में सक्षम नहीं होने के साथ ही इसकी अपनी विशिष्ट सेटिंग्स और कई स्रोतों से कई फ़ोल्डरों को जोड़ने की क्षमता है जो एक अवरोधक के राजा हैं।

@danechitoaie आपको कैसे पता चलेगा कि आप अपने कोर रेपो में जो बदलाव करते हैं, वह किसी दूसरे क्षेत्र या प्रोजेक्ट कोड आधार के लिए उस पर निर्भर किसी और को नहीं तोड़ता है? काम करने के लिए एक खतरनाक तरीके की तरह लगता है; कुछ प्रकार के पैकेज प्रबंधन प्रणाली या जैसे का उपयोग करके अलग-अलग रिलीज प्रबंधन होना चाहिए।

कार्यस्थानों के कुछ कार्यान्वयन के खिलाफ बहस नहीं कर रहे हैं, लेकिन एक पूर्ण विकसित परियोजना प्रणाली काफी हद तक जटिलता को जोड़ती है।

सहमत हैं, यह है और उन्हें बहुत कुछ करना चाहिए / बेहतर कर सकती है लेकिन ... यह हमारे "नश्वर उपयोगकर्ताओं" के नियंत्रण या निर्णय लेने की क्षमता से बाहर है ...

समझ लिया। मुझे अच्छा लगता है जब उस तरह की बात होती है।

इस बारे में कैसा है?

मेरे लिए इस तरह एक साधारण स्विच बटन पर्याप्त नहीं है। अगर हमें बस उस सरल, खुले 2 उदाहरणों (ctrl shift N) की आवश्यकता है, तो विंडोज़ / वर्कस्पेस के बीच स्विच करने के लिए अपने OS हॉटकी का उपयोग करें।
मुझे कुछ ऐसा करना पसंद है जो फ़ाइलों, परियोजनाओं की संरचना की तुलना करना आसान बनाता है, कुछ मुझे छोटे बदलावों को जल्दी से करने और बनाने में मदद करता है और एक ही स्क्रीन में सभी फ़र्क रखता है, उन सभी परियोजनाओं के लिए परिवर्तनों को वापस करने में सक्षम हूं जिनके साथ मैं काम कर रहा हूं।

+1

+1

MacOS सिएरा के लिए वर्कअराउंड की तरह।

डॉक सेटिंग्स में Prefer tabs when opening documents से Always सेट करके एक प्रोजेक्ट के अंदर एक टैब। लेकिन यह दूसरों के ऐप व्यवहार को भी प्रभावित करेगा।

+1

यह मेरे लिए हत्यारा बन रहा है। मुझे इस कार्यक्रम से प्यार है, लेकिन मैं एक खिड़की वाले व्यक्ति को पसंद नहीं करता ...

ईमानदारी से, मुझे कोड का उपयोग करना बंद करना पड़ा क्योंकि जितना मैं इसे पसंद करता हूं, यह बहुत ही बोझिल स्विचिंग विंडोज़ बन गया।

अगर यह भविष्य में तय हो जाता है तो मैं इसे फिर से आजमाऊंगा, तब तक यह मेरे लिए एक शो स्टॉपर है और हर उस व्यक्ति ने जो मैंने इसका परीक्षण किया था।

+1

+1

कृपया पसंद करें: +1: मूल मुद्दे की टिप्पणी पर प्रतिक्रियाएं जो हमें प्राथमिकता के साथ मदद करती हैं और अपडेट के लिए समस्या को सुनने वाले सभी को सूचनाएं नहीं भेजती हैं।

+1

मैं वर्तमान में Sublime का उपयोग कर रहा हूं, और कोड की कोशिश कर रहा हूं। यह अच्छा लग रहा है और अच्छा लगता है, लेकिन एकल परियोजना Git एकीकरण एक सौदा ब्रेकर है। मेरे पास एक Hadoop / Oozie प्रोजेक्ट है, और इसलिए कोड का एक रेपो है, और दूसरे काम करने वाले नोट हैं। उदात्त में, मैं उन दोनों को एक ही खिड़की में खोलता हूं, और प्रत्येक के लिए उपयुक्त गिट रेपो के लिए प्रतिबद्ध कर सकता हूं

इसलिए, इसे जोड़ना अच्छा होगा

+1 yep, microservice दुनिया में महत्वपूर्ण यह एक ही समय में 3..4 repos खुला होना आम तौर पर है

साप्ताहिक अनुस्मारक: +1 के साथ टिप्पणियां पोस्ट करना बंद करें। इसके बजाय, शुरुआती मुद्दे पर एक अंगूठे दें, जो वास्तव में गिना जाता है।

मुझे पता है आप सभी अच्छी तरह से मतलब है। इसलिए अपनी +1 टिप्पणी को हटाने के लिए स्वतंत्र महसूस करें ताकि यह इस महत्वपूर्ण ऐतिहासिक रिकॉर्ड में जगह न ले सके!

@jamietre मैंने कोशिश की है ... कठिन:

हो सकता है कि एक और विकल्प इस मुद्दे को बंद कर दिया जाए लेकिन हल होने तक खुला रखा जाए? इस तरह, हम मुद्दे के महत्व को जानते हैं (मैं कहूंगा कि हम पहले ही इसके लिए पर्याप्त + 1 प्राप्त कर चुके हैं), लेकिन अव्यवस्था / अतिरेक में जोड़ नहीं सकते हैं (उदाहरण के लिए और अधिक टिप्पणी की अनुमति नहीं है)।

हालाँकि मुझे लगता है कि यह एक शायद ही कभी इस्तेमाल की जाने वाली विशेषता है, मैं केवल एक सार्वजनिक परियोजना / गितुब पर रेपो में लॉकडाउन में आया था।

यदि आवश्यक हो, तो लॉकडाउन को अनलॉक किया जा सकता है।

@daluu यह है कि / aspnet / घोषणा रेपो कैसे काम करता है; हर मुद्दे को तुरंत बंद कर दिया जाता है। कहा जा रहा है कि, GitHub को यूआई में कुछ करना चाहिए ताकि कम से कम लोगों को "+1" से परे विकल्पों की ओर ड्राइव किया जा सके क्योंकि अब प्रतिक्रियाएं मौजूद हैं। 👍

दो से अधिक परियोजनाओं के दस्तावेजों को देखते हुए, बहु-खिड़की फ़ंक्शन को पूरी तरह से रखना बहुत सहायक है,

समस्या के लिए दिलचस्प दृष्टिकोण। मैं कई वर्षों से VB / .net प्रोग्रामर था, भाषाओं और औजारों से प्यार करता था, लेकिन Hadoop / Spark / Scala / Intellij / Sublime-Land में कुछ वर्षों के लिए दूर हो गया। मैं अभी भी DotNetRocks को सुनता हूं, जैसे कि क्या चल रहा है, इस तिथि को रखना और इस कोड ऐप के बारे में सुनने में दिलचस्पी थी। सकारात्मक पक्ष पर, यह एक बहुत अच्छा संपादक है, जिसमें कुछ अच्छी दिखने वाली गिट विशेषताएं हैं, लेकिन यह दुर्भाग्य से पूरी तरह अप्रासंगिक है। क्योंकि यह एक ही कार्यक्षेत्र में कई परियोजनाओं के लिए Git को हैंडल नहीं करता है, जैसा कि उदात्त बहुत ही सुरुचिपूर्ण ढंग से करता है, तो मैं अभी इसका उपयोग नहीं कर सकता

ऐसा होता है। मैं जिस चीज से सबसे ज्यादा आश्चर्यचकित हूं, वह यहां की प्रतिक्रिया है, पहले यह दावा करना कि यह एक आवश्यक विशेषता नहीं है, और फिर सबसे अधिक चर्चा अब चारों ओर "हम कैसे लोगों को पोस्ट करने से रोक सकते हैं" प्रतीत होती है।

मैं आपको बताता हूँ कि आप ऐसा कैसे करते हैं - आप एक बुनियादी समस्या को ठीक कर लेते हैं जो पहली बार एक पूरे साल पहले उठाई गई थी! इसे "फीडबैक सुनना" कहा जाता है। सिर्फ इसलिए कि आप व्यक्तिगत रूप से किसी समस्या से प्रभावित नहीं हैं, इसका मतलब यह नहीं है कि यह मौजूद नहीं है। यदि आप उपयोगकर्ताओं के किसी विशेष समूह को ऐप का उपयोग नहीं करना चाहते हैं, तो ठीक है, लेकिन हमें कोई प्रतिक्रिया तंत्र न दें, फिर हमारी समस्या पर विवाद करें और फिर हमसे मांगते रहने के लिए हमसे नाराज हो जाएं।

मैं उदात्त का उपयोग करने के लिए वापस आ गया हूँ

"+ 1" समस्या को निम्न कोड के साथ ठीक किया जा सकता है: अगर (पोस्ट_समेस == "+1") {add_smiley_reaction (); delete_post_message (); }

प्रिय GitHub, मैं भाड़े के लिए उपलब्ध हूँ।

हाँ, यह कभी तय नहीं होने वाला है, क्या यह है। वास्तव में मुख्य समस्या को संबोधित करने के बजाय "+1" टिप्पणियों को मॉक करना और अनदेखा करना आसान है, सॉफ्टवेयर डेवलपर्स के एक विशेष खंड में विपणन किया जा रहा है जो ऐसा नहीं करता है जो उन्हें उत्पादक होने की आवश्यकता है ...

बस इसे पढ़ें "इस टिप्पणी का हर सीधा उत्तर (= अधिक मेटा) मुझे उपयोगकर्ता को अवरुद्ध करने में परिणाम देगा।" - अब, कि कैसे प्रतिक्रिया का प्रबंधन करने के लिए है! अपनी उंगलियों को अपने कानों में चिपकाएं और कहें "आप सुन नहीं सकते!"

प्रिय भगवान

@ kryps1 तब लोग "+ 1" या "++ 1" या "1+" या "टक्कर" या "हां, कृपया +1" जोड़ेंगे। आप जो भी करेंगे लोग उसके आसपास एक रास्ता पाएंगे। उतना आसान नहीं है जितना आप सोचते हैं।

+1 'की बेकार बहस के साथ रुकें ... कृपया ध्यान दें कि यहां क्या जरूरी है, जो कि एक्सप्लोरर में कई परियोजनाएं हैं।

git समस्या के लिए, इसे बस उसी तरह से विभाजित करना होगा जिस तरह एक्सप्लोरर (यानी cwd द्वारा) है।

आइए +1 सामान पर लौ युद्ध शुरू न करें। यह निश्चित रूप से अच्छा होगा यदि इस मुद्दे को प्राथमिकता दी गई।

लेकिन मैं समुदाय का उल्लेख करना चाहता हूं, मुझे लगता है कि पीआर और योगदान का स्वागत है; कोर किसी भी डेवलपर के पास न पहुंचने पर कोड को पैच / फिक्स कर सकता है। मेरे कुछ प्रोजेक्ट्स में सुधार हुआ (कांटे के साथ) क्योंकि उपयोगकर्ता / डेवलपर ने खुद मुझ पर इंतजार करने के बजाय सुधार किया है कि वे मुझे सुझाव देना चाहते हैं। तो कोई भी जो इस मुद्दे से परेशान है और सक्षम / कुशल पर्याप्त है, कृपया ठीक करें (फिर एक पीआर सबमिट करें)? जबरदस्त हंसी

और +1 विषय पर वापस जाना, समस्या को उछालना और अपनी राय को जोड़ना अच्छा है, लेकिन +1 यह करने का एक लंगड़ा तरीका है अगर अंगूठे की तरह अन्य सुविधाएं उपलब्ध हैं। फेसबुक पोस्ट, या मूल Google+ पोस्ट पर विचार करें, और उपयोगकर्ता / पाठक Google+ के लिए लाइक (या फेसबुक की नई प्रतिक्रियाओं में से एक), या +1 पर क्लिक करने के बजाय +1 टिप्पणी जोड़ें। समय के साथ-साथ यह लंगड़ा + 1 s का एक लंबा टिप्पणी धागा है, जहां मैं पाठक के रूप में मैं दिलचस्प टिप्पणियों को देखने के लिए स्क्रॉल कर सकता हूं, लेकिन मैं अंत में + 1s का गुच्छा देख रहा हूं। यह वही है जो यहां हो रहा है, मैं इन + 1s के माध्यम से देखना / पढ़ना नहीं चाहता, चाहे मैं एक परियोजना डेवलपर हूं या केवल एक उपयोगकर्ता (या संभावित उपयोग के लिए इस परियोजना पर शोध कर रहा हूं)।

संबंधित नोट पर, यहां GH मुद्दे का एक मूर्खतापूर्ण (लेकिन अच्छा इरादा) उपयोग है, भगवान का शुक्र है, लोगों ने इस पर +1 नहीं किया, हालांकि: https://github.com/sinatra/sinatra/issues/920

मुझे लगता है कि पीआर और योगदान का स्वागत है

ज़रुरी नहीं। इस टिप्पणी को अगस्त से देखें: https://github.com/Microsoft/vscode/issues/396#issuecomment -241806158

स्पष्ट रूप से यह मुद्दा कम से कम तब से रोडमैप में है, लेकिन इस पर कोई प्रगति नहीं हुई है। VSCode की टीम से स्टेटस अपडेट सुनना अच्छा होगा।

मेरे लिए, और यह विषय को ट्रैक पर वापस लाने की कोशिश कर रहा है, कई प्रोजेक्ट फ़ोल्डर की आवश्यकता है।

एटम में, यह जीआईटी का समर्थन करता है, और इसका उपयोग करने का एकमात्र तरीका यह नोट करना है कि किन फ़ाइलों में परिवर्तन हैं। मेरे पास एक Rackspace सर्वर है जो SSH को मैनुअल अपलोड करने की अनुमति नहीं देगा। हालाँकि, मैं साइडबार में कई प्रोजेक्ट फ़ोल्डर्स रखने में सक्षम हूं, और इससे मुझे पिछले प्रोजेक्ट में उपयोग किए गए संदर्भ कोड को इतना आसान बना देता है। अगर मुझे एक राहत की ज़रूरत है, तो गियर को किसी अन्य प्रोजेक्ट पर स्विच करें।

VSCode के साथ, समस्या जो मुझे swtiching से रोक रही है, और आदमी मैं स्विच करना चाहता हूं, साइड बार में कई प्रोजेक्ट फ़ोल्डर की कमी है।

मेरा मतलब है कि मुझे लगता है कि मैं बस रूट फ़ोल्डर को अस्थायी रूप से हल करने के लिए खोल सकता हूं, लेकिन अगर मुझे केवल 3/20 फ़ोल्डर्स की आवश्यकता है, और मैं ढीली फ़ाइलों को नहीं देखना चाहता हूं, तो यह एक आसान कार्यान्वयन होना चाहिए, है ना?

अपडेट: जल्द ही आने वाला बड़ा कार्यक्षेत्र अपडेट हॉट एग्जिट (# 101) है, हॉट एग्जिट पर काम करते समय हम इस मुद्दे पर सक्रिय रूप से चर्चा कर रहे हैं ताकि यह सुनिश्चित हो सके कि डिजाइन कई फ़ोल्डर्स को ध्यान में रखता है।

यह समस्या वर्तमान में नंबर 2 है: +1: सभी मुद्दों की प्रतिक्रियाएं (नंबर 1 एक लंबे तरीके से टैग किए गए कार्यक्षेत्र के रूप में), क्योंकि इस तरह से गर्म निकलने के बाद कार्यक्षेत्र के लिए काम का अगला बड़ा टुकड़ा होने की संभावना है।

पर: +1: टिप्पणियां; वे केवल इस मुद्दे पर सदस्यता लिए गए 80+ लोगों को नाराज़ करने का काम करते हैं। हालांकि इस परियोजना को प्रभावित करने के लिए आप सबसे शक्तिशाली चीजों में से एक हैं।

यह भी ध्यान रखें कि हम अपेक्षाकृत छोटी टीम हैं और कोडबेस की सफाई और vscode का प्रदर्शन बहुत महत्वपूर्ण है, इसलिए चीजों को सही करने में समय लगता है। विशेष रूप से इस तरह के कुछ के लिए, जो कि vscode को आज तक कैसे बनाया गया है, के लिए एक बुनियादी बदलाव है, इस मुद्दे में काफी काम है।

+1

वास्तव में यह एक आसान सुविधा होगी।

मैंने एटम से स्विच किया और वास्तव में इसे पसंद किया, लेकिन मैं दो यूआई अनुप्रयोगों और दूसरे 2 एसडीके पर काम करता हूं, लेकिन उन परियोजनाओं (या फ़ोल्डर्स) के बीच जल्दी से बदलने की अक्षमता एक महत्वपूर्ण कमी है, मुझे लगता है कि मुझे एटम तक वापस जाना चाहिए हल हो गया

मैं वास्तव में इस सुविधा के लिए तत्पर हूँ ~~~

मैं vsolode का उपयोग कर एक गोलगप्पा काढ़ा हूँ, आशा है कि यह एक कार्यान्वयन है, thx!

मैं उदात्त से VScode में स्विच करने की कोशिश कर रहा हूं। और जल्द ही मुझे पता चला कि वीएसकोड एक "प्रोजेक्ट" अवधारणा में कई फ़ोल्डरों का समर्थन नहीं कर रहा है, वास्तव में मुझे ऐसा करने से रोकने में एक समस्या है।

वास्तव में इस "हल्के वजन" संपादक की अन्य विशेषताओं से प्यार है। इस बीच मेरा मानना ​​है कि एक "प्रोजेक्ट" में कई फ़ोल्डर्स का समर्थन करने से वीएसकोड "अधिक वजन" या "आईडीई-जैसे" नहीं बन जाएगा। यह संक्रमण को कम दर्दनाक बनाने के लिए अन्य संपादकों का उपयोग करने वाले डेवलपर्स के लिए इसे और अधिक सुविधाजनक बना देगा।

यह सुधार होने की उम्मीद है। धन्यवाद!

इसके अलावा, अगर टीम प्रोजेक्ट आधारित सेटिंग्स को बचाने की क्षमता जोड़ सकती है जो डिफ़ॉल्ट सेटिंग्स को ओवरराइड करती है जो शानदार होगी। Usecase है अगर मैं विभिन्न परियोजनाओं के लिए अलग-अलग व्याख्याकार रख सकता हूं। इसी तरह विभिन्न टैब आकार आदि होने से भी मदद मिलेगी। कृपया मुझे बताएं कि क्या यह पहले से किसी तरह से हासिल किया जा सकता है।

एक डेवलपर के रूप में हम हमेशा कई परियोजनाओं पर काम कर रहे हैं और हमारे पास स्वयं की परियोजनाएं हैं। हर बार जब मैं स्विच करता हूँ तो प्रोजेक्ट सेटिंग्स (vscode के लिए कार्यक्षेत्र सेटिंग्स) को अनुकूलित करना एक बड़ा दर्द होता है।

@bajubullet आपको https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig की कोशिश करनी चाहिए अगर यह आपकी जरूरत की हर चीज को कवर न करे, लेकिन यह एक शुरुआत है।

प्रतिक्रिया के लिए @danechitoaie धन्यवाद। EditorConfig हालांकि मदद नहीं करता है, मैं प्रति फ़ाइल गुण को निर्दिष्ट कर सकता हूं, लेकिन अगर मैं उन्हें प्रोजेक्ट सेटिंग्स के रूप में सहेज सकता हूं तो यह आसान होगा और मुझे हर प्रोजेक्ट के लिए .editorconfig पसंद नहीं है। अजगर एक्सटेंशन जैसे एक्सटेंशन के मामले में, जो हमें प्रदान करने के लिए दुभाषिया प्रदान करते हैं, यह मदद नहीं करेगा क्योंकि python.pythonPath Editorconfig के माध्यम से समर्थित नहीं है। कृपया मुझे बताएं कि क्या मुझे यहां कुछ याद आ रहा है। किसी भी सुझाव सबसे स्वागत है।

मैं सहमत हूं, मैं वास्तव में किसी प्रकार की परियोजना विशिष्ट सेटिंग्स के लिए आगे देख रहा हूं और कई "रूट" फ़ोल्डर खोलने में सक्षम हूं। यह केवल चीजें हैं जो मुझे उदात्त से याद आती हैं।

इसे जल्द ही लागू किया जा रहा है!

इसलिए इस पोस्ट से जुड़ने की जरूरत नहीं है। यदि आपके पास अन्य समस्याएँ हैं, तो एक नया थ्रेड बनाएँ। धन्यवाद!

यह काफी लंबा धागा है और मैं इसके बारे में शायद एक तिहाई के माध्यम से पढ़ता हूं, लेकिन बस अपना समर्थन देना चाहता हूं। मैंने अभी Atg / Juno के संभावित विकल्प के रूप में https://github.com/JuliaEditorSupport/julia-vscode के साथ VS कोड स्थापित किया है। यह खूबसूरत है! 😍

जूलिया कोड विकसित करते समय, हालांकि, मुझे लगता है कि विभिन्न फ़ोल्डरों में कई पैकेज खोलने में सक्षम होना बहुत महत्वपूर्ण है। सिद्धांत रूप में, मैं ऊपर दिए गए फ़ोल्डर को खोल सकता हूं, लेकिन मैंने जो जूलिया पैकेज स्थापित किए हैं उनमें से 100 को उजागर करेगा। मैं अपना LOAD_PATH भी बदल सकता था, लेकिन मैं एक VS कोड समाधान पसंद करूंगा।

मुझे पूरी उम्मीद है कि कई फ़ोल्डर्स खोलने में सक्षम होंगे। प्रयासों के लिए धन्यवाद 👍

हाय सब, जैसा कि आपने देखा होगा कि हम इस पुनरावृत्ति के दौरान इस मुद्दे के कार्यान्वयन की खोज कर रहे हैं।

Https://github.com/Microsoft/vscode/issues/17608 से

विभिन्न घटकों @team में मल्टी रूट वर्कस्पेस में जांच करें

जैसा कि हम कार्यान्वयन विवरण के माध्यम से सोचते हैं, मैं आपके उपयोग के मामलों के बारे में 3-5 से चैट करना चाह रहा हूं। यदि आप कर सकते हैं तो कृपया अगले मंगलवार को 15 मिनट के टाइम स्लॉट के लिए साइन अप करें। मुझे चैट करना अच्छा लगेगा।

मेरी आपी और उई के बीच अदला-बदली मुझे पागल बना रही है ... :-(

@ehartford विशेष रूप से किसी भी कारण से वे आपसी माता-पिता को साझा नहीं करते हैं?

हाँ। यदि मैं सिर्फ मूल निर्देशिका को खोलता हूं तो Git एकीकरण काम नहीं करता है।

@ इशार्टफोर्ड अच्छा कारण: मुस्कान:

@ वडेरियन आप _end user_ के लिए देख रहे हैं केवल मामलों का उपयोग करें, या _extension Developers_ भी?

_End user_ के रूप में बहु फ़ोल्डर समर्थन _searching प्रयोजनों के लिए सबसे अधिक उपयोगी था। मैं अलग-अलग एपीआई से अलग फ़ोल्डर जोड़कर प्रोजेक्ट्स बनाता था, बस खोजों को आसान बनाने के लिए (एकीकृत)। मैं कहूंगा कि मैं आज बहुत याद नहीं करता, और आज मुझे कई VSCode विंडो रखने के लिए परेशान नहीं करता है, विशेष रूप से Switch Window कमांड जोड़े जाने के बाद: +1:

जैसा कि _extension developer_ मेरे पास कुछ एक्सटेंशन हैं जो _Project Context_ पर आधारित हैं, जैसे context.workspaceState , activationEvents/workspaceContains । और प्रोजेक्ट मैनेजर भी, जो कि पहले से ही मैंने मल्टी फ़ोल्डर को सपोर्ट करने के लिए पहले से ही इंटर्नल रिफ्लैक्ट करना शुरू कर दिया था। मुझे यह जानकर अच्छा लगेगा कि यह एक्सटेंशन को कैसे प्रभावित करेगा

धन्यवाद

जो मैंने ऊपर कहा है उसे जोड़ने के लिए (https://github.com/Microsoft/vscode/issues/396#issuecomment-270326917), मैं वास्तव में गिट सबमॉडल्स का उपयोग करता हूं, इसलिए जब मैं अपने (निजी) पैकेजों पर काम कर रहा हूं, तो यह उन्हें बंडल करने के लिए सही समझ में आता है, लेकिन चूंकि जूलिया अभी भी काफी युवा (अपेक्षाकृत बोलने वाले) हैं, इसलिए मुझे अक्सर अपने साथ अन्य पैकेजों पर काम करने की आवश्यकता होती है। मुझे इन दूसरे पैकेजों को सबमॉड्यूल्स के रूप में जोड़ने के लिए एक आकर्षक कारण नहीं लगता (हालांकि मैं कर सकता था)।

आम तौर पर, जूलिया पैकेज के विकास के लिए, मैं लगातार पैकेज भर में hopping हूँ, ताकि कई परियोजना फ़ोल्डर्स महान होंगे: +1:

पुनश्च: एमएस, कृपया जूलिया पर अधिक ध्यान दें;)

सरलतम उपयोग का मामला: माइक्रोसर्विसेस

Haha। हां @saada 👍 यह वास्तव में microservices थी जिसने हमें VS कोड में लाया। हम एज़्योर सर्विस फैब्रिक का उपयोग कर रहे हैं और मेरे पार्टनर ने .NET और रस्ट में पहला माइक्रोसेर्विस बनाया है। मैं जूलिया microservices पर काम कर रहा हूँ। मेरा साथी एक VS लड़का है और Rust के लिए VS कोड पसंद करता है। उन्होंने सुझाव दिया कि मैं जूलिया के लिए वीएस कोड की कोशिश कर रहा हूं। धन्यवाद!

@ दादा निश्चित रूप से रडार पर हैं। क्या आप आवश्यकताओं पर क्रिस्प होने में मेरी मदद करने के लिए इन सवालों के जवाब दे सकते हैं?

1. क्या आपकी माइक्रो सर्विसेज एक पैरेंट फोल्डर शेयर करती हैं? क्यों या क्यों नहीं?
2. क्या प्रत्येक सूक्ष्मदर्शी अपने स्वयं के गिट रिपॉजिटरी में अलग हो गया है? क्यों या क्यों नहीं?

1. क्या प्रत्येक सूक्ष्मदर्शी अपने स्वयं के गिट रिपॉजिटरी में अलग हो गया है? क्यों या क्यों नहीं?

@ ग्वालियरन एक संभावित कारण यह है कि पाएएस प्लेटफार्मों को प्रत्येक एप्लिकेशन (माइक्रोसर्विस) को एक अलग गिट रेपो में होना चाहिए। डिप्लॉय-थ्रू-गिट-पुश एक लोकप्रिय रणनीति बन गई है।

@ ग्वालियरन मैंने कल एक स्लॉट के लिए साइन अप किया है और इसके लिए इंतजार कर रहा है - लेकिन इस तरह के उपयोग के मामलों की तरह, हमारा भी समान है।

हम एक बड़े संगठन हैं, हमारे पास एक निजी एनपीएम रजिस्ट्री है, और अपने स्वयं के मॉड्यूल प्रकाशित करते हैं जो संगठन के भीतर साझा किए जाते हैं। हमारे पास एक क्लाइंट कोडबेस के साथ एक रिएक्शन ऐप है जो एक बड़ा ऐप है जो कुछ सामान्य मॉड्यूल (जैसे यूटिलिटी लिबास, शेयर्ड कंपोनेंट्स) का उपभोग करता है, और एक सर्वर कोडबेस जिसमें कई मॉड्यूल भी शामिल होते हैं (एक्सप्रेस सर्वर ऐप, द्वारा उपभोग किए गए डेटा सर्विस घटकों का बैकएंड करता है। सेवा परत, और ग्राहक के सामने वास्तविक सेवाएं)। सक्रिय विकास में न्यूनतम दो (क्लाइंट और सेवाओं की परत) शामिल हैं, लेकिन समस्या निवारण में आसानी से आधा दर्जन मॉड्यूल शामिल हो सकते हैं।

सार्वजनिक npm मॉड्यूल का उपयोग करते समय भी, यह कभी-कभी उपयोगी होता है ताकि इसका स्रोत कोड सीधे जुड़ा हो और एक अलग VS कोड उदाहरण में एक कठिन समस्या का निवारण करने के लिए, या यहां तक ​​कि 3rd पार्टी मॉड्यूल में बग के लिए खुला हो, लेकिन ज्यादातर यह हमारा अपना कोड होता है।

प्रत्येक अलग गिट रिपोज हैं। एक रूट फ़ोल्डर (मैं वैसे भी) के तहत उन्हें मेरे फाइल सिस्टम में रखने में कोई समस्या नहीं है। लेकिन मुझे हर एक के लिए वीएस कोड का एक अलग उदाहरण खोलने की आवश्यकता है, और आगे और पीछे स्विच करना दर्दनाक है क्योंकि आप केवल फ़ाइल नाम देख सकते हैं - एप्लिकेशन का नाम ही नहीं। आसानी से पता लगाने का कोई तरीका नहीं है कि कौन सा एप्लिकेशन / मॉड्यूल / प्रोजेक्ट किस विंडो में खुला है। फ़ाइल का नाम ही मल्टीएसएल वीएस कोड उदाहरणों के बीच भेदभाव करने में बहुत कम उपयोगी जानकारी प्रदान करता है।

शीर्षक बार की जानकारी को कॉन्फ़िगर करने की अनुमति देने से संबंधित एक और खुला मुद्दा है, जिस पर मैंने बहुत टिप्पणी की है - और अनसुलझा भी है। यदि टाइटल बार में रूट फोल्डर नाम फ्लश-लेफ्ट होना संभव था, तो कई प्रोजेक्ट ओपन होने की समस्या एक इश्यू से काफी कम होगी, क्योंकि मैं कम से कम यह देख सकता था कि कौन सा ओपन एक्सैस विंडोज के भीतर था जो टास्क को स्विच करते समय होता था। ऐसा लगता है कि यह वास्तव में तुच्छ बनाने के लिए तुच्छ होना चाहिए और कम से कम एक बार में कई git repos खोलने में सक्षम नहीं होने के दर्द को कम कर सकता है एक महान उदाहरण में यह पता चला है, जबकि ...

@waderyan

1. मेरी वेब परियोजनाएं एक एकल पैरेंट फ़ोल्डर द्वारा प्रबंधित की जाती हैं। यह संगठन के लिए इस तरह से स्थापित है, और मेरे रिपॉजिटरी फ़ोल्डर के लिए त्वरित लिंक। मैं भी ऐसा करता हूं, क्योंकि जब कोड का पुन: उपयोग होने जा रहा है तो कोड नमूने खींचने के लिए मेरे लिए एक पिछली / वर्तमान परियोजना में स्वैप करना आसान है। जैसा कि एक और खिड़की खोलने का विरोध किया गया है, एक और टैब खोलना आसान है, और मेरे मामले में अधिक समय कुशल है।

2. प्रत्येक वेब परियोजना का अपना स्वयं का एकीकरण है, हालांकि मेरे लिए व्यक्तिगत रूप से, मुझे अपने कोड संपादक में एकीकृत होने के लिए .it की आवश्यकता नहीं है। यह मेरे लिए एक अच्छा विकल्प है, लेकिन आवश्यकता नहीं है। मेरे रेपो होस्ट में प्रत्येक वेब प्रोजेक्ट को अलग रखने की इच्छा के कारण उनका अपना एकीकरण है।

@nickmak @jamietre @pesho अपने विचार साझा करने के लिए धन्यवाद। यह मददगार है और मैं कल आप में से कई लोगों के साथ बातचीत करना चाह रहा हूं।

@alefragnani मैं अंतिम उपयोगकर्ता परिदृश्य पर केंद्रित हूं। एक्सटेंशन पर प्रभाव के कारण हमने सावधानी से इस मुद्दे पर संपर्क किया है। हम सावधानी से चलना और किसी भी एपीआई परिवर्तनों को संवाद करेंगे। यदि आप चाहें तो मुझे ट्विटर पर पिंग करें और हम अधिक चर्चा के लिए कॉल पर कूद सकते हैं।

यहां तक ​​कि नोटपैड ++ मल्टी फोल्डर को सपोर्ट करता है। यह कारण नोटपैड ++ नहीं छोड़ा जा सकता है।
इस दिन जावास्क्रिप्ट के साथ काम करने के लिए मल्टी प्रोजेक्ट खोलने की जरूरत है।

मैं एम्बेडेड सॉफ़्टवेयर का काम करता हूं और आमतौर पर कुछ फ़ोल्डर्स हैं जो मैं पूरे सिस्टम में काम कर रहा हूं। उदाहरण के लिए एप्लीकेशन कोड, वेंडर लाइब्रेरी और ऑपरेटिंग सिस्टम कोड।

मैं एक ही विंडो में कई फ़ोल्डरों के लिए अपने उपयोग के मामले को यहां जोड़ना चाहूंगा।

मैं एक गेम डेवलपर हूं और हमारे मौजूदा गेम के लिए हमने मॉड सपोर्ट लागू किया है। हमारे गेम में क्लाइंट, सर्वर और मास्टर सर्वर प्रोजेक्ट हैं। आवधिक फाइलों का संपादन करते हुए यह केवल खेल के आधुनिक स्तर में काम करने के लिए सामान्य है (इसके बजाय हम वास्तविक गेम कोड के मुख्य या देशी स्तर को कहते हैं। उदाहरण के लिए सर्वर और C # फ़ाइलों के बजाय केवल Lua फ़ाइलों में कार्य करना और ग्राहक क्रमशः)। फ़ोल्डर्स अक्सर एक आम अभिभावक फ़ोल्डर के भीतर स्थित नहीं हो सकते हैं।

इस उपयोग के मामले में, जब केवल मॉड फ़ाइलों के भीतर काम करते हैं, तो अतीत में हमने क्लाइंट और सर्वर से केवल शीर्ष स्तर के मॉड फ़ोल्डरों के प्रोजेक्ट दृश्य बनाने के लिए Sublime की मल्टीफ़ोल्डर कार्यक्षमता का उपयोग किया है। यह हमें मूल फ़ाइलों (C # और C ++) से बचने की अनुमति देता है और उन दो परियोजनाओं में Lua फ़ाइलों को जल्दी से संपादित करता है जो एक दूसरे से बहुत संबंधित हैं।

VSCode में मल्टीफ़ोल्डर सपोर्ट होने से हम ऐसा ही कर पाएंगे और VSCode को अपनाने में बहुत आसानी होगी (जो हमें बहुत पसंद है)।

पिछले सप्ताह हुई कॉल का क्या हुआ? मैं मैक पर हूँ और VSCode के कई उदाहरण नहीं खोल सकता, जो मुझे लगा कि यह वर्कअराउंड होगा।

धन्यवाद!

मेरे पास पिछले हफ्ते वेड के साथ एक कॉल आया, यह स्पष्ट और निष्पक्ष है कि यह नहीं था
प्रारंभिक प्राथमिकता, उन्होंने एक बहुत अच्छा संपादक बनाया है, और अब उम्मीद है
वे इसे अलग-अलग डेवलपर की जरूरतों को पूरा करने के लिए बढ़ा रहे हैं। देव टीम हैं
सुनकर, मैं यह देखने के लिए उत्सुक हूं कि वे इसके बारे में कैसे जाते हैं

सूर्य पर, 15 जनवरी 2017 21:20 nowherenearithaca, सूचनाएं @github.com
लिखा था:

पिछले सप्ताह हुई कॉल का क्या हुआ? मैं पर हूँ MAC और प्रतीत नहीं कर सकते
VSCode के कई उदाहरणों को खोलने के लिए, जो मैंने सोचा था कि एक समाधान होगा।

धन्यवाद!

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/396#issuecomment-272724576 ,
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/AA16yEIdTFJAnqXHLs_WUvrGBIR9G7f-ks5rSo2DgaJpZM4Gm3nX
।

बहुत अनुरोध में
निशान

@nowherenearithaca मेरे पास कई उपयोगकर्ताओं के साथ शानदार कॉल थे और मैंने बाकी टीम के साथ जो भी सीखा उसे साझा किया। हम अभी भी अगले चरणों का पता लगा रहे हैं, लेकिन मुझे उम्मीद है कि हम बहुत जल्द इस क्षेत्र में कुछ करेंगे।

@ ग्वालियरन , देर से प्रतिक्रिया के लिए खेद है:

क्या आपकी माइक्रो सर्विसेज एक पैरेंट फोल्डर शेयर करती हैं? क्यों या क्यों नहीं?

हाँ, सुविधा के लिए। जब वे एक ही निर्देशिका के तहत संबंधित सेवाओं को खोजना आसान बनाते हैं।

क्या प्रत्येक सूक्ष्मदर्शी अपने स्वयं के गिट रिपॉजिटरी में अलग हो गया है? क्यों या क्यों नहीं?

हाँ। उनके पास न केवल अलग-अलग रिपोज हैं, उनके पास अलग-अलग लाइनिंग और डिबगिंग कॉन्फ़िगरेशन भी हैं। इसके अलावा, परियोजनाओं के बीच फ़ाइलों को स्विच करने के लिए Cmd + P का उपयोग करना सुपर उपयोगी है। संबंधित परियोजनाओं में वैश्विक खोज, ...

कार्रवाई में यह देखने के लिए उत्सुक!

एक समाधान उस फ़ोल्डर के लिए एक लिंक बनाना होगा जहां आप जिन फ़ाइलों तक पहुंचना चाहते हैं, वे स्थित हैं।
यह आदर्श नहीं है लेकिन यह मदद कर सकता है।

_उदाहरण:_

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

मेरे पास 3 मॉनिटर हैं और मैं सभी तीनों में VSCode का उपयोग करना चाहता हूं। अगर मैं एक से अधिक उदाहरण नहीं खोल सकता तो कम से कम टैब को अनडॉक करने और उन्हें अन्य विंडो में खींचने का समर्थन कर सकता हूं (विजुअल स्टूडियो 2015 के समान)।

इस बात से सहमत।

अन्य सभी टेक्स्ट एडिटर इसे करते हैं। Microsoft इतनी सरल और आवश्यक किसी चीज़ में क्यों नहीं सोचता था?

@calloncampbell यह सुविधा इस समस्या में है: https://github.com/Microsoft/vscode/issues/2686

@calloncampbell @rsyring मुझे पता नहीं है कि मैं क्या गलत कर रहा हूं, लेकिन code -n का उपयोग करके मैं जितने चाहे उतने संपादक उदाहरण खोल सकता हूं।

अगर मैं सही तरीके से समझूं, तो इसकी जांच फरवरी के इरीटेशन प्लान के भीतर की जाएगी, '' मल्टी रूट वर्कस्पेस ',' मल्टी फोल्डर 'वर्कस्पेस' 'को लागू करने की प्रारंभिक जांच :)

+1 ...
क्या यह VSCode के पुराने संस्करण के साथ संभव नहीं है या मैं सिर्फ उदात्त का उपयोग कर रहा था? भूल गया...
लेकिन बहुत काम है।
अब मेरा मैक पूरी जगह 6 खिड़कियों से अटा पड़ा है ...

और नहीं, मैं उन सभी 6 फ़ोल्डरों का रूट फ़ोल्डर नहीं खोलूंगा जो मैंने खोले हैं, coz एक्सप्लोरर एक ऊर्ध्वाधर स्क्रॉल है और यह मुझे फ़ाइलों के माध्यम से ब्राउज़ करने के लिए हमेशा के लिए ले जाएगा ...

@edmundtfy यह उदात्त में संभव है। विजुअल स्टूडियो कोड का इस कार्यक्षमता के लिए समर्थन कभी नहीं था।

@ min20 समाधान एकदम सही है !!! मल्टी फ़ोल्डर प्रोजेक्ट, इसके बजाय बटन के माध्यम से प्रबंधित मल्टी-विंडो होगी

@DeeJaVu इस बात पर विचार कर रहा है ... VSCode में ये माउसओवर-टूलटिप और नियंत्रण + परिभाषा पर जाने के लिए क्लिक करें। मैंने उदात्त के लिए कुछ एक्सटेंशन डाउनलोड किए लेकिन माउसओवर और कंट्रोल + क्लिक सामान भी काम नहीं करते हैं .. कोई सिफारिशें?

मैं वास्तव में साल के लिए उदात्त का उपयोग करने के बाद यह याद आती है। अभी मैं इंटर्शोप (फ्रंट-एंड के रूप में) के साथ काम कर रहा हूं, प्रति कार्ड सैकड़ों-हजारों फाइलें। अगर मुझे एक पूर्ण webshop लोड करना है तो यह वास्तव में धीमा है जब आप एक फ़ाइल पर स्विच करने के लिए CTRL + P को खोलना चाहते हैं या जब आपको खोजना होगा।

इसके अलावा, मैं बस अपने संपादक में एक परियोजना के हर फ़ोल्डर नहीं चाहता। मुझे फ्रंट-एंड डेवलपर के रूप में सब कुछ की आवश्यकता नहीं है। बस मुझे जिन फ़ोल्डरों की आवश्यकता है, वे पर्याप्त हैं।

एक और उदाहरण: एक ही समय में इसके लिए एक Wordpress साइट और प्लगइन्स बनाना। मुझे एक पूर्ण वर्डप्रेस साइट शामिल करने की आवश्यकता क्यों होगी? यह सिर्फ आपकी दक्षता को धीमा करता है।

हमारे पास एक और समस्या है: हमारा फ्रंट-एंड फ्रेमवर्क अलग-अलग गिट रिपोज में विभाजित है। ' अधिक होने के बाद 4 खिड़कियां खुली होना एक वास्तविक दर्द है। और एससीएसएस इंटैलिजेंस तब काम नहीं कर रहा है (आईई। कोर> पैकेज से चर)

TLDR; वीएसकोड बड़ी / विशाल परियोजनाओं के लिए अनुपयोगी है

+1, आपको कई कस्टम मॉड्यूल के साथ एक वर्डप्रेस या ड्रुपल विकसित करने की कल्पना करने देता है।

आपकी परियोजना की जड़ आपकी वेबसाइट की जड़ है, लेकिन आप नहीं चाहते कि पूरी वेबसाइट रेपो हो, आप बस अपने कई मॉड्यूल या थीम को स्वतंत्र रेपो के रूप में चाहते हैं।

वेब विकास में बहुत आम उपयोग का मामला है जिसे कवर किया जाना चाहिए, यहां तक ​​कि सबसे छोटे / सबसे हल्के आईडीई द्वारा भी।

+1

+1, मुझे एक परियोजना को संपादित करने और उस पर काम करने में सक्षम बनाने में सक्षम है

+1

इसका एकमात्र मुद्दा हमें अपनी संपूर्ण 32 व्यक्ति देव टीम को वि.स.

सूक्ष्म-सेवा विकास केवल संभव नहीं है, इसका दर्दनाक।

+1

+1, निश्चित रूप से उपयोगी है, मैं उदात्त से vscode पर जाने का निर्णय ले रहा हूं, लेकिन, इस विशेषता के गायब होने के कारण, मुझे लगता है कि मैं अभी भी एक दिन तक उदासी का उपयोग करूंगा।

इसकी एक बहुत ही आवश्यक और बुनियादी विशेषता है। मैं विश्वास नहीं कर सकता कि कैसे इस महान संपादक के डेवलपर्स ने इसे अनदेखा कर दिया। इस सुविधा के बिना यह बेकार है। यह मुझे एटम से VSCode पर स्विच करने से रोक रहा है।

कृपया इस सुविधा को जोड़ें। उदात्त और फिर एटम का उपयोग करने के बाद यह मेरे लिए एक संपादक की एक आवश्यक विशेषता है। बेशक यह एकीकरण के कारण इतना आसान नहीं है, लेकिन यह कुछ ऐसा है जिसकी मुझे अपने पसंदीदा संपादक के भीतर ज़रूरत है।

+1

+1 तत्काल आवश्यकता

+1 जैसा कि पहले कहा गया था, एटम से VSCode तक जाने के लिए हमें वास्तव में इस सुविधा की आवश्यकता है।

ध्यान से पहले टिप्पणी
* कृपया !!!! "+1" के साथ टिप्पणी करना बंद करें

आपकी प्रत्येक बेकार टिप्पणी केवल इस धागे के साथ सौ से अधिक लोगों को विचलित करती है !!!
यदि आप इस सुविधा का समर्थन करना चाहते हैं - तो पहले संदेश में यह भावना है!
यदि आप अपडेट की सदस्यता लेना चाहते हैं - इसके लिए विषयों के दाईं ओर "सदस्यता लें" बटन है
अन्य सदस्यों का सम्मान करें, जिन्हें आपके "+1", "वास्तव में आवश्यक", आदि को पढ़ने के लिए मजबूर किया जाता है

संदर्भ के लिए, जिस तरह से उदात्त पाठ (उदाहरण के रूप में) यह प्रोजेक्ट करता है वह "फ़ोल्डर ट्री सहित" है, आपके प्रोजेक्ट में शामिल "फ़ोल्डर" प्रति अद्वितीय विकल्प के साथ।

यह कल्पना करने के लिए, एक उदात्त पाठ परियोजना फ़ाइल का JSON इस तरह दिखता है:

{
    "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 ऐप्स की बात कर रहा हूं, जिन्हें सिर्फ एक रनिंग सर्वर की तैनाती या कुछ भी करने की आवश्यकता नहीं है।
मुझे दूसरी फ़ाइल संरचना में क्यों परेशान होना चाहिए, जब मैं सिर्फ टॉमकैट से सीधे ऐप फ़ोल्डर खोल सकता हूं और मेरे बदलाव वास्तविक समय में प्रभावी होंगे।

और नहीं, कोई भी पैरेंट फोल्डर नहीं है, जब तक कि आप टॉमकैट सर्वर फोल्डर को एक प्रोजेक्ट के रूप में खोलने का सुझाव नहीं देते हैं (जो यह सुझाव देने जैसा है कि मैं अपने पूरे HDD को एक प्रोजेक्ट के रूप में खोलता हूं, क्योंकि मैं तब सभी फाइलें खोलने में सक्षम हूं)।

वाह, मैंने VS को आज़माने के लिए परमाणु की स्थापना रद्द कर दी, और यह सुविधा 2015 से नहीं जोड़ी गई है।

stoffeastrom ने 21 नवंबर 2015 को इस मुद्दे को खोला

वह निराशाजनक है। : निराश:

पुनश्च: मास्टर फ़ोल्डर को खोलना, वास्तव में एक समाधान नहीं है क्योंकि यह सभी अवांछित फ़ाइलों को खोलता है, साथ ही इस टिकट के पूरे उद्देश्य को भी पूरा करता है।

वह वास्तव में निराशाजनक है। लेकिन फिर से उतना निराशाजनक नहीं है जितना कि लोग अभी भी एक अद्भुत, मुफ्त, ओपनसोर्स संपादक के बारे में शिकायत कर रहे हैं (जो लगातार नई सुविधाओं के एक मुट्ठी भर जोड़ता है _every month_)। न ही किसी के अवसाद के बारे में टिप्पणियों के साथ इस धागे को देखने वाले सभी को स्पैमिंग के रूप में निराशाजनक।

_{(अब मैं spammers में से एक हूँ, मुझे लगता है: मुस्कराहट :)}

अपडेट: वर्तमान योजना मार्च / अप्रैल पुनरावृत्तियों में इस पर ध्यान देने की है।

मार्च यात्रा योजना के लिए https://github.com/Microsoft/vscode/issues/21923 देखें:

मल्टी-रूट, मल्टी-फोल्डर वर्कस्पेस # 396 @bpasero @Tyriar में जांच करें

+1

एक वास्तविक दुनिया उदाहरण साझा करने के लिए जो सुविधा विवरण को परिष्कृत करता है: उदाहरण, वर्डप्रेस थीम / प्लगइन देव।

अन्य संपादकों में, मैंने कई फ़ोल्डर सेट किए "बुकमार्क" के रूप में, एक बड़े और जटिल फ़ाइल ट्री को प्रबंधित करने के लिए थोड़ा आसान करने के लिए। एक वेबरोट के लिए है, जो रूट है जिसे मैं किसी भी डिबग और कोड पूरा करने वाले फ़ंक्शन को (पर्यावरण पर) शुरू करना पसंद करूंगा। दूसरा वास्तविक परियोजना के लिए है, एक थीम फ़ोल्डर या एक प्लगइन फ़ोल्डर है, जो मेरे वर्कफ़्लो में, संस्करण नियंत्रण रूट है। कभी-कभी, मैं संदर्भ के रूप में अतिरिक्त फ़ोल्डर सेट करता हूं, जैसे कि मूल विषय, या टेम्पलेट थीम, या एक प्लगइन जिसे मैं एकीकृत कर रहा हूं और मुझे अक्सर संदर्भ / पढ़ने की आवश्यकता होती है।

तो यहाँ सेट की सुविधा है, 1. विभिन्न स्थानों पर गिट रूट और सर्च रूट को सेट करने की क्षमता। 2. एक फ़ोल्डर बुकमार्किंग सिस्टम जो फ़ाइल ट्री पैनल को डिक्लेयर करने के लिए विशुद्ध रूप से दृश्य है।

थ्रेड पर कुछ के लिए, जहां git रूट, और प्रोजेक्ट रूट एक समान है, ऐसा लगता है कि सबमॉड्यूल्स सीखना और उपयोग करना पर्याप्त होगा, और फिर यह केवल 2. लगभग एक नेस्टेड फ़ोल्डर का एक अच्छा कम बरबाद दृश्य प्राप्त करना है।

मुझे यकीन है कि थ्रेड पर कुछ वास्तव में शाब्दिक मल्टी-प्रोजेक्ट समर्थन के लिए पूछ रहे हैं, लेकिन मुझे लगता है कि ज्यादातर मुख्य रूप से सरल फ़ोल्डर बुकमार्किंग विचार के लिए पूछ रहे हैं।

मैं इसके अतिरिक्त एक परियोजना रूट (खोज / डिबग) के रूप में परिभाषित करने के लिए एक रास्ता पूछ रहा हूं, और दूसरा एक रूट रूट के रूप में। (बेझिझक मेरे घटिया नामकरण की बातों को नजरअंदाज करें।)

इसके लिए मेरा वर्कअराउंड केवल पैरेंट फोल्डर बनाना है और मेरे द्वारा वांछित सभी प्रोजेक्ट्स के साथ प्रतीक लिंक बनाना है।
_e.g._

मेरे पास ये प्रोजेक्ट हैं

1. my-app-api
2. माय-ऐप-क्लाइंट

मैं _my-app-all_ (नाम यहाँ अप्रासंगिक है) नामक एक फ़ोल्डर बनाता हूं और भीतर, मैं अपने ऐप-एपी और मेरे-ऐप-क्लाइंट की ओर इशारा करते हुए दो प्रतीकात्मक लिंक बनाता हूं, फिर VSCode में मुझे बस अपना ऐप खोलने की आवश्यकता

कदम

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

टिप्पणियाँ:
गिट एकीकरण काम नहीं करेगा

@DannyFeliz को इस मुद्दे के उत्तर के रूप में चिह्नित किया जाना चाहिए और सभी को देखने के लिए शीर्ष पर पोस्ट किया जाना चाहिए ... मैंने MKLINK कमांड का उपयोग करके विंडोज पर भी इसका परीक्षण किया है।
उपयोग का उदाहरण:

1. प्रशासक विशेषाधिकारों के साथ ओपन कमांड प्रॉम्प्ट
2. अपने प्रोजेक्ट फ़ोल्डर में जाएं
   3. [वैकल्पिक] एक लिंक फ़ोल्डर बनाएँ
3. MKLINK / D "link_name" "उस पथ का उपयोग करें जिसे आप संदर्भित करना चाहते हैं"

जब आप वीएस कोड में प्रोजेक्ट खोलते हैं तो आपको संदर्भित फ़ोल्डर और इसमें सभी फाइलें / फ़ोल्डर दिखाई देंगे।

हैप्पी कोडिंग लोग!

यह Git एकीकरण को काम करने में सक्षम नहीं करता है।

सोम, मार्च 20, 2017 को 2:42 बजे, poparazvandragos सूचनाएं @github.com
लिखा था:

@DannyFeliz https://github.com/DannyFeliz इसे ए के रूप में चिह्नित किया जाना चाहिए
इस मुद्दे का जवाब और देखने के लिए सभी के लिए शीर्ष पोस्ट किया है ... मैंने परीक्षण किया है
Windows पर भी, MKLINK कमांड का उपयोग करते हुए।
उपयोग का उदाहरण:

1. प्रशासक विशेषाधिकारों के साथ ओपन कमांड प्रॉम्प्ट
2. अपने प्रोजेक्ट फ़ोल्डर में जाएं
   3. [वैकल्पिक] एक लिंक फ़ोल्डर बनाएँ
3. MKLINK / D "link_name" "उस पथ का उपयोग करें जिसे आप संदर्भित करना चाहते हैं"

जब आप वीएस कोड में प्रोजेक्ट खोलते हैं तो आपको संदर्भित फ़ोल्डर दिखाई देगा
और इसमें सभी फाइलें / फ़ोल्डर।

हैप्पी कोडिंग लोग!

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/396#issuecomment-287907310 ,
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/ABEOBVKz2bqFsRdfvyOpcFW2e_26HV5bks5rnvLWgaJpZM4Gm3nX
।

@ehartford मैंने एक जवाब कहा, जवाब नहीं, क्योंकि हम में से ज्यादातर इस सटीक चीज़ की तलाश में थे, एक ही VSCode विंडो में कई निर्देशिकाओं को प्रदर्शित करते हुए, जो विभिन्न स्थानों में रहते हैं।
प्रतीकात्मक लिंक बस यही करते हैं, लेकिन विंडोज पर काम करते समय यह समाधान नहीं है जो दिमाग में आता है।
हमें आने के लिए और सबसे सरल वर्कअराउंड दिखाने के लिए 2 साल गुजरने थे और एक लिनक्स / ओएसएक्स डेवलपर के लिए।
मुझे खुशी है कि मैंने आखिरकार इस मुद्दे पर अपनी टिप्पणी छोड़ने का फैसला किया क्योंकि मुझे जो चाहिए था उसके लिए मुझे एक वर्कअराउंड मिल गया है
सिर्फ 12 दिनों के बाद, जब मुझे इसकी सबसे ज्यादा जरूरत थी।

इस मुद्दे को नहीं छोड़ा जाना चाहिए, क्योंकि डेवलपर्स द्वारा मामले पर कदम उठाने के लिए बहुत कुछ किया जा सकता है।
लेकिन हम में से अधिकांश के लिए यह संतोषजनक है। मैं बस किसी तरह इसे ऊपर ले जाने का सुझाव दे रहा था, इसलिए लोग इस टिप्पणी तक पहुंचने तक, अन्य सभी टिप्पणियों को पढ़ने में समय बर्बाद न करें। धागे के आकार के कारण कुछ इसे अनदेखा कर सकते हैं।

मैं इसे संपादित करूंगा क्योंकि मैं देख रहा हूं कि लोग पहले से ही मेरी पीठ पर कूद रहे हैं क्योंकि मुझे पता चला है कि मैं जो चाहता था उसे कैसे हासिल करूं और दूसरों के लिए एक विकल्प देखने के लिए आसान बनाने की कोशिश की, भले ही वह सही न हो। बीटीडब्ल्यू: आप हमेशा व्यक्तिगत लिंक्ड फ़ोल्डर में फ़ाइलों को खींचने / कमिट करने / पुश करने के लिए VSCode में एकीकृत कमांड प्रॉम्प्ट का उपयोग कर सकते हैं लेकिन वर्कआउट के लिए व्यवस्थित क्यों होते हैं।

Git एकीकरण के बिना, यह कुल नॉन-स्टार्टर है। मैं इसे किसी भी तरह से स्वीकार्य समाधान नहीं मानता। एक वास्तविक समाधान के लिए आगे देख रहे हैं। सादर।

यदि यह मदद करता है - Google एपेंजाइन नोडज क्लाइंट इस तरह संरचित है:

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

मैं इस तरह के समाधान में / डिबग खोलने / काम करने में सक्षम होना पसंद करूंगा (भले ही यह एक बार में एक पैकेज हो)। मैं इस शैली में टाइपस्क्रिप्ट आधारित परियोजनाओं / कामों को लिखने में सक्षम होना पसंद करूंगा।

सभी महान काम के लिए धन्यवाद!

VSCode से प्यार है, लेकिन यह कई परियोजनाओं को संभालने में बकवास है। लेकिन मैं समझ सकता हूं कि फीचर को बंद क्यों किया गया है, क्योंकि यह कई चीजों को बनाता है जैसे स्रोत नियंत्रण घोंसले के कारण अधिक जटिल होते हैं आदि।

मैं एक 'प्रोजेक्ट क्विक स्विच' फ़ीचर या एक विंडो में कई vscode उदाहरणों को 'टैब' करने की क्षमता के लिए खुश हूँ।

पूरी तरह से सहमत हैं, कृपया एक ही विंडो में कई प्रोजेक्ट फ़ोल्डर खोलने का समर्थन करें। यह समारोह बहुत महत्वपूर्ण है।

@ पूरा करना आपकी समस्या का सही समाधान नहीं है। लेकिन प्रोजेक्ट मैनेजर को एक कोशिश दें, यह आंशिक रूप से अभी मेरी मदद कर रहा है।

@dariusrosendahl Yep, आज सुबह बहुत

साइडबार में केवल 5 आइकन हैं, इसमें 'प्रोजेक्ट' साइडबार जोड़ने के लिए बहुत कुछ नहीं होगा। लेकिन ऐसा लगता है कि vscode उत्पाद मालिकों के बारे में सुपर उधम मचाते हैं कि यह कितना कम है। बहुत कम IMO क्योंकि अब यह एक IDE बन रहा है।

@ जानकर खुशी हुई कि यह मददगार है know

वास्तव में, एक _experimental API_ में तथाकथित _Tree एक्सप्लोरर कंट्रीब्यूशन बनाने के लिए_ (सिंबल पैनल की तरह - https://github.com/Microsoft/vscode/issues/15485)। इसके साथ, एक्सटेंशन गतिविधि बार में एक आइकन जोड़ सकता है।

मैं आपके सुझाव के साथ अपने विस्तार के लिए एक मुद्दा जोड़ूंगा, धन्यवाद to

+1

@dmccaffery

मैं, व्यक्तिगत रूप से, परवाह नहीं करता हूं कि क्या यह विशेषता उत्पाद में समाप्त होती है या नहीं - मुझे समझ में आता है कि कुछ लोग इसे क्यों चाहते हैं, लेकिन मैं यह कहना चाहूंगा कि यह सब कुछ थोड़ा और जटिल बनाता है।

तब हो सकता है कि फीचर के खिलाफ नकारात्मक टिप्पणियों के साथ बातचीत पर हावी न हों और वीएससी एक आईडीई कैसे नहीं है? मुझे लगता है कि एक प्रतिक्रिया / नकारात्मक मतदान पर्याप्त है, या सबसे खराब दो पर, अगर किसी को आगे एक स्थिति स्पष्ट करने की आवश्यकता है।

इसके अलावा, "नहीं एक आईडीई" तर्क लूट है। अन्य गैर-आईडीई भी इसके लिए अनुमति देते हैं।

उदाहरण के लिए: जब रेगेक्स एक्सप्रेशन का उपयोग करके खोज करते हैं - मैं कौन सा कार्यक्षेत्र खोज रहा हूं? एक? सब?

उतना बड़ा मुद्दा नहीं। या तो सभी खोज करें, या खोजकर्ता को खुले कार्यक्षेत्रों में से किसी एक में गुंजाइश रखने के लिए है। फिर से, अन्य "गैर आईडीई" (साथ ही आईडीई) पहले से ही इस (और अन्य) मामलों को संभालते हैं।

मैंने प्रत्येक "कार्यक्षेत्र" के लिए एक डायर बनाकर और अपने स्वयं के सेटअप में उन परियोजनाओं के लिए सहानुभूति रखते हुए इस मुद्दे को निर्धारित किया जो मैं उस कार्यक्षेत्र में देखना चाहता हूं।

मैंने देखा

मल्टी-रूट, मल्टी-फोल्डर वर्कस्पेस में प्रारंभिक जांच # 396 @bpasero @Tyriar

के अनुसार किया जाता है https://github.com/Microsoft/vscode/issues/21923 इस पर कोई अपडेट? :)

हमने (टीम का सबसेट) काम की मात्रा में एक प्रारंभिक जांच की और जो चुनौतियां हम देख रहे हैं और अगले चरण में टीम के साथ उसके परिणाम पर चर्चा करना और उसके लिए योजना बनाना है। हम इस सप्ताह के दौरान अप्रैल की रिहाई के लिए अपनी योजना बना रहे हैं, इसलिए मुझे उम्मीद है कि इस काम के परिणामस्वरूप अधिक महीन अनाज की योजना बनाई जाएगी।

अगर मैं पार्टी के लिए देर नहीं करता तो यहाँ अच्छा तरीका है जिसे लागू किया जा सकता है।
जब आप "एक्सप्लोरर" पर जाते हैं तो हमारे पास पहले से ही दो खंड होते हैं। एक खोला फ़ाइलों के लिए और एक चालू खुले फ़ोल्डर के एक्सप्लोरर ट्री के लिए।

आदर्श रूप में हम केवल एक ही विंडो में और अधिक फ़ोल्डर खोल सकते हैं और उन्हें यहां अपने स्वयं के अनुभाग में जोड़ा जाएगा जिसे एक्सप्लोरर ट्री को देखने के लिए विस्तारित किया जा सकता है।

स्रोत नियंत्रण अनुभाग के लिए एक ही बात की जा सकती है। प्रत्येक फ़ोल्डर के लिए एक उपधारा जो "एक्सप्लोरर" में खोला गया है। तो 1to1 संबंध।

इस तरह शायद हम सभी को खुश कर सकते हैं। यदि हम चाहते हैं कि एक ही विंडो में कई फ़ोल्डर खोलने के लिए हमारे पास समर्थन है, और जीआईटी एकीकरण अभी भी काम करता है और प्रत्येक "प्रोजेक्ट रूट" को अलग से संभालने में सक्षम है।

एक ही विंडो पर एक से अधिक प्रोजेक्ट खोलें यह मेरे लिए भी एक महत्वपूर्ण विशेषता है। आमतौर पर, मैं कुछ आधार एप्लिकेशन को कॉपी करने के लिए बहुत अधिक प्रोजेक्ट खोलता हूं। मैं सिर्फ विजुअल स्टूडियो कोड स्थापित करता हूं और मैं इसी कारण एटम पर लौटूंगा

+1 मैं अन्य देवों के VSCode के मूल्य को दिखाना चाहता हूं, लेकिन एक ही विंडो में दो फ़ोल्डरों को खोलने में सक्षम नहीं होना एक डीलब्रेकर है। मुझे उम्मीद है कि इसे उच्च प्राथमिकता मिलेगी।

केवल मेरे दो सेंट्स:

अब तक "मोनोरेपो" शब्द इस धागे में नहीं दिखता है

मेरा मोनोरपो कई जड़ों के बीच कॉन्फ़िगरेशन चिंताओं को केंद्रीकृत करता है, जहां प्रत्येक को फ़ोल्डर में ".root" फ़ाइल द्वारा चिह्नित किया जाता है।

प्रत्येक रूट बाहरी गेट रिपॉजिटरी नहीं है, लेकिन वे वैश्विक कॉन्फ़िगरेशन के आंशिक ओवरराइड की अनुमति देते हैं।

मेरा मुख्य दर्द बिंदु यह है कि फाइलों और / या प्रतीकों की खोज मेरी जड़ों की सामग्री को प्राथमिकता नहीं देती है

मुझे लगता है कि आवश्यकता को ~ 4 अलग-अलग लोगों में विभाजित किया जा सकता है, जो सीधे एक-दूसरे से संबंधित हो सकते हैं या नहीं भी हो सकते हैं (और शायद स्वतंत्र रूप से लागू किए जाते हैं):

• एक्सप्लोरर में कई फ़ोल्डरों का समर्थन करें
• खोज में कई फ़ोल्डरों का समर्थन करें
• स्रोत नियंत्रण में कई फ़ोल्डरों का समर्थन करते हैं
• डीबग में कई फ़ोल्डरों का समर्थन करें

इस धागे में मैंने जो कुछ देखा है, उससे ये अलग-अलग प्रकार के परिदृश्यों का समर्थन कर सकते हैं। बेशक, अभी भी कुछ "मुख्य" फ़ोल्डर होना चाहिए, यह प्रभावित करता है कि कॉन्फ़िगर / चयनित फ़ोल्डर कैसे बनाए जाते हैं।

मुझे समझ नहीं आता कि अधिकांश टिप्पणियां मल्टी-रूट या मल्टी-फ़ोल्डर एक्सप्लोरर समाधान के बारे में क्यों बात करती हैं। वास्तव में मुझे लगता है कि आईडीई तरीके से इसे लागू करने की कोशिश करना वास्तव में बुरा है। यह जटिलता जोड़ता है और निश्चित रूप से प्रदर्शन को प्रभावित करता है (लोड समय, गिट रिफ्रेश ....)।

मुझे लगता है कि यह सुविधा बहुत महत्वपूर्ण है, मूल रूप से सभी संबंधित परियोजनाओं के बारे में एक दृश्य है और परियोजनाओं की खिड़कियों के बीच जल्दी से स्विच करने की आवश्यकता है!

हमारे पास दो विकल्प हैं:

• एक ही खिड़की में कार्यान्वयन : मेरे अर्थ में यह कई अन्य चिंताओं का परिचय देता है, git के लिए कई प्रोजेक्ट्स रूट, खोज ..... इस UX के लिए बहुत बुरा है और संभवतः संपादक को बग और जटिलता का परिचय देगा।
• एक स्विच तंत्र को लागू करें जो दृश्य है और प्रति प्रोजेक्ट एक खिड़की रखें : यह बहुत कम लागत के लिए सबसे सुरक्षित और अधिक सुविधाजनक विकल्प है! @ min20 ने उन समूहों के बीच स्लैक के स्विच बटन के बारे में एक दृश्य पोस्ट किया है जो मुझे आवश्यकता के लिए एकदम सही

मुझे उम्मीद है कि यह सुविधा उतरेगी, लेकिन मल्टी-रूट समाधान के रूप में नहीं! एक छोटे संपादक के प्रमुख लाभों में से एक यह सादगी और गति है, muti-root != simplicity & speed

मुझे आपसे पूरी तरह असहमत होना है सब्बल का कार्यान्वयन देखा है? यह बहुत सरल है और अभी भी बहुत तेज है तो विजुअल स्टूडियो कोड। यहां तक ​​कि सभी जीआईटी प्लगइन्स सक्षम होने के साथ।

हम 1 संपादक में कई परियोजनाओं का उपयोग करने के बारे में बात नहीं कर रहे हैं। हम केवल आपके द्वारा आवश्यक प्रोजेक्ट के फ़ोल्डर्स का उपयोग करने के बारे में बात कर रहे हैं।

मैं उदाहरण के लिए इन्टरशॉप दुकानों पर काम कर रहा हूँ। बहुत कुछ है जिसकी मुझे आवश्यकता नहीं है, केवल उन कारतूसों को जिन्हें मुझे संपादित करना है। फ़ोल्डरों और फ़ाइलों का 80% मेरे लिए बेकार है और केवल संपादक को बहुत भारी बनाता है (मुझ पर विश्वास करें, यह बहुत धीमा हो जाता है)।

विज़ुअल स्टूडियो में "क्विक ओपन" का उपयोग करना भी अनुपयोगी है अगर बहुत सारी डुप्लिकेट फाइलें हैं। आपको अक्सर यकीन नहीं होता है कि आप सही एक बार फिर से खोलेंगे, यह बहुत सारी फ़ाइलों के साथ धीमा हो जाता है।

मैं समझता हूं, लेकिन, अतीत में उदात्तता और परमाणु का उपयोग करने के बाद, मैं अंत में इस निष्कर्ष पर पहुंचा कि उनमें से कोई भी "मटि-रूट" फीचर ने प्रोजेक्ट फ़ाइलों की खोज के अलावा और कुछ भी हल नहीं किया है, उदात्त बोलना, उदात्त फ़ोल्डर ट्री बहुत धीमा है बड़ी परियोजनाओं और खोज करते समय भी जमा देता है, उदात्त के पास "गिट" और "डीबग" की विशेषताएं बॉक्स के बाहर एकीकरण नहीं होती हैं .... मुटी-रूट को शुरू करने से गिट एकीकरण से संबंधित कई मुद्दों की बेंच का परिचय होगा, बिना प्रभावों की खोज प्रदर्शन ... यहां तक ​​कि UX प्रभावित है, जैसे बड़ी परियोजनाओं में srcoll मुद्दों की खोज।

अजीब है, मेरे लिए यह विपरीत है।

शायद ऐसा इसलिए है क्योंकि 99% समय मैं केवल वही शामिल करता हूं जो मुझे उदात्त या एटम :) में चाहिए होता है और यही हम चाहते हैं।

शायद यह सिर्फ आप संपादक का उपयोग करने का तरीका है। मुझे CMD / CTR + P का उपयोग करने और मुझे इच्छित फ़ाइल लिखने की आदत है। यह असंभव है अगर आपको बहुत सारे डुप्लिकेट फ़ाइलों के साथ एक परियोजना की जड़ को शामिल करना है। (कार्ट्रिज / फाइलें जो मूल थी उसकी तुलना करने के लिए वहां छोड़ दिया गया था) या वर्डप्रेस जैसी कोई चीज जहां एक ही नाम के साथ बहुत सारी फाइलें हों।

नमस्ते,
हां कई चीजों को तोड़े बिना मल्टीपल फोल्डर आइडिया ठीक है। प्रत्येक अतिरिक्त फ़ोल्डर यह उपसर्ग के साथ एक नया उप खंड हो सकता है यह इंगित करने के लिए कि यह प्राथमिक फ़ोल्डर के लिए विदेशी है। प्राथमिक का उपयोग डिबगिंग और गिट के लिए किया जाता है। एक उपयोगकर्ता किसी भी विदेशी फ़ोल्डर पर राइट क्लिक कर सकता है और इसे प्राथमिक बना सकता है। आपको क्या मिलेगा:
1) अपने सभी फ़ोल्डर्स और फ़ाइलों को देखने और उन्हें आवश्यकतानुसार खोलने में सक्षम होना।
2) जिस पर काम करना प्राथमिक है, उसका फिर से होम करना।

अब यदि कोई एक बार में कई परियोजनाएँ खोलना चाहता है, तो उसे एक नया मुद्दा अनुरोध खोलना चाहिए। यह कई लोगों द्वारा उल्लिखित महत्वपूर्ण जटिलता को जोड़ता है। प्लगइन्स बिलिंस के बराबर नहीं हैं। यदि एक संपादक है जिसमें एक मिलान अंतर्निहित सुविधा है, तो इसे इंगित किया जाना चाहिए ताकि अन्य डेवलपर्स यह जांच सकें कि उनके कार्यप्रवाह इस तरह की सुविधा के साथ कैसे फिट होते हैं। धन्यवाद। अच्छा दिन।

मुझे उन उपयोगकर्ताओं की सूची में जोड़ें जो इस एकमात्र डील ब्रेकर को मानते हैं जो मुझे VSC में जाने से रोकता है। मुझे लगता है कि परियोजनाओं के उदात्त कार्यान्वयन पर हाजिर होना चाहिए। यदि मुझे उदाहरण के लिए "स्वयंसेवक घंटे" ऐप पर काम करने की आवश्यकता है, तो मैं उस परियोजना को खोलता हूं जिसे मैंने अलग-अलग फ़ोल्डरों (मुख्य परियोजना फ़ोल्डर के साथ-साथ एक और फ़ोल्डर जिसमें चित्र शामिल हैं) के साथ पॉपुलेट किया है। उस प्रोजेक्ट के लिए यह मेरा काम कर रहा है। अगर मुझे "एक्सचेंज कैलकुलेटर" ऐप पर फ़्लिप करने की आवश्यकता है, तो मैं उस प्रोजेक्ट के लिए पूरे काम करने वाले सेट को स्वैप कर सकता हूं या उस प्रोजेक्ट के साथ एक नई विंडो खोल सकता हूं।
CMS का उपयोग करते समय एक और उपयोग मामला है। अगर मैं CMS के लिए एक प्लगइन पर काम कर रहा हूं, तो मेरे पास प्लगइन के लिए एक प्रोजेक्ट हो सकता है जो कि Git रिपॉजिटरी है और दूसरा पूरे CMS के लिए, जो Gitified नहीं है। मैं आवश्यकतानुसार दोनों के बीच फ़्लिप कर सकता हूं और अपनी Git चिंताओं को अलग रख सकता हूं।
वीएससी मेरे लिए भविष्य की तरह दिखता है, लेकिन फ़ोल्डर्स के अलग-अलग काम करने वाले सेट रखने की क्षमता के बिना नहीं।

नमस्ते,
मैंने केवल देखा है कि Sublime Text में प्रोजेक्ट फ़ाइल के साथ प्रोजेक्ट्स के लिए समर्थन है। यहाँ जो माँगा जा रहा है, उसके बराबर कैसे है? यह एक कार्यक्षेत्र के भीतर परियोजना फ़ाइलों का समर्थन करने के लिए vscode के लिए एक अनुरोध की तरह लगता है। एक एक्सटेंशन के पहले एक टिप्पणी थी जो एक परियोजना प्रबंधक के लिए उस संबंध में चीजों को संभाल सकती थी।

मैं ईमानदारी से एटम का उपयोग करता हूं और मैं मल्टी फ़ोल्डर फ़ंक्शन (बिल्ट-इन) का उपयोग करता हूं जो मुझे एक ही समय में दस्तावेज़ फ़ोल्डर और मेरे वर्तमान प्रोजेक्ट फ़ोल्डर को खोलने की अनुमति देता है। यह वास्तव में कम लटकने वाले फल की तरह लगता है, जो प्राथमिक और सेकेंडरी का एक गुच्छा सक्षम करता है। संभवतः एक साधारण तीर या प्राथमिक संकेत करना शुरू करें। धन्यवाद। अच्छा दिन।

इसके लायक क्या है, यहां मेरा उपयोग मामला है। मैं एक खेल पर काम करता हूं जिसे तीन रिपॉजिटरी में विभाजित किया गया है; इंजन के लिए एक गिट रेपो, गेम कोड + सामग्री के लिए एक एचजी रेपो और गेम कोड के लिए एक एचजी रेपो जो कई परियोजनाओं के लिए सामान्य है। कंपनी के उदात्त पाठ प्लगइन्स के लिए एक hg रेपो भी है। जेनेरिक रेपो गेम-रेपो के लिए एक सबरेपो है।

अपने अगले कार्य स्थल पर, मुझे कई रिपॉजिटरी के साथ फिर से काम करने की उम्मीद है।

यह एक ही संपादक उदाहरण में इन सभी के लिए सुपर सुविधाजनक है, और मुझे लगता है कि यह इन सभी के लिए वीएस कोड में उचित एससीएम प्राप्त करने के लिए समझ में आएगा।

मुझे उम्मीद है कि डिफ़ॉल्ट रूप से मैप किए गए सभी फ़ोल्डरों के माध्यम से खोज की जाएगी। एक अच्छा बोनस अस्थायी रूप से खोज करने के लिए किन फ़ोल्डरों को चालू / बंद करने में सक्षम होगा। (उदाहरण के लिए, जब मैं केवल गेम इंजन में चीजों को खोजने में दिलचस्पी रखता हूं)

बहुत सारे लोग कह रहे हैं कि वीएस कोड को इसके लिए समर्थन नहीं होना चाहिए क्योंकि ए) उन्हें इसकी आवश्यकता नहीं है और बी) वीएस कोड एक सरल पाठ संपादक है। पहला कारण कोई अच्छा नहीं है - कुछ विशेषताएं हैं जो सभी द्वारा उपयोग की जाती हैं। दूसरा कारण ... VS कोड सिर्फ एक साधारण टेक्स्ट एडिटर नहीं है, इसमें डीबगिंग, SCM, प्लगइन्स हैं। अन्य "सिंपल टेक्स्ट एडिटर्स" जैसे सब्लिम में कई फोल्डर सपोर्ट होते हैं। और जैसा कि कोई व्यक्ति जो प्रदर्शन के बारे में अडिग है, मैं यह नहीं देख सकता कि इस सुविधा को जोड़ने से किसी भी सार्थक तरीके से प्रदर्शन प्रभावित होगा, खासकर ऐसे लोगों के लिए जो केवल एक फ़ोल्डर का उपयोग करते हैं। क्या हम इस चर्चा पर ध्यान केंद्रित कर सकते हैं कि हम

@ ट्रेक क्या आप अपने वर्तमान संपादकों में इस तरह से काम करने का स्क्रीनशॉट शामिल कर सकते हैं? यह बिल्ट-इन और प्लगइन्स का उपयोग करके फ़ोल्डर्स और प्रोजेक्ट्स के मिश्रण जैसा लगता है। उम्मीद है कि ए कैंप के लोग इस तरह के फीचर को शामिल करने के लिए बदलावों पर ध्यान नहीं देंगे। बी शिविर के लोगों के लिए, वे सही हैं। आप बॉक्स से बाहर आवेदन के साथ जल्दी से चीजें कर सकते हैं यदि आपको नीचे फंसने की आवश्यकता नहीं है। पास पकड़ना संभवत: ऐसे त्वरित अपडेट चक्र और अनअटेंडेड इंटरफ़ेस तत्वों को रखने में मदद करता है।

यह कैसे पूरा करने के लिए के बारे में कुछ बातें शामिल हैं:

• गुंजाइश, संदर्भ, सत्र, विचारों और वर्तमान होने के संबंध को समझना।
• ऊपरी सीमा (अधिक से अधिक 256 फ़ोल्डर?)
• प्रमुख प्रभावित क्षेत्र (संपादक टैब, सेटिंग्स, scm, git, एक्सटेंशन)।
• कार्यक्षेत्र सेटिंग ओवरराइड या टकराव।

इन क्षेत्रों में VSCode द्वारा दी जाने वाली कुछ चीजों के लिए मुआवजे की जरूरत होती है। धन्यवाद। अच्छा दिन।

+1

+1। मेरे पास प्रत्येक 30 git रिपॉजिटरी के साथ मॉड्यूल हैं जिन्हें मैं एक एकल वातावरण में एक्सेस करना और काम करना चाहता हूं। मैंने सोचा कि ज्यादातर js / नोड डेवलपर्स क्या करते हैं। VSCode के साथ यह असंभव है, अफसोस के लिए मेरे लिए एक सौदा ब्रेकर है।

+1

यह 2015 से खुला है और अभी भी तय नहीं हुआ है। यह किसी भी संपादक में एक बस सबसे वांछित सुविधा है, लेकिन दुख की बात है कि यह नहीं है।

+1

कमांड टैबिंग करते समय मैं लगातार एक वीएस कोड विंडो को दूसरे के साथ भ्रमित कर रहा हूं।

मुझे पता है हर दूसरे संपादक के पास यह (एटम, उदात्त, कोष्ठक ...)

मेरी परियोजना के लिए एक सिमलिंक जोड़ना एक हैक है और मुझे अपने .gitignore को अपडेट करने की आवश्यकता होगी। मूल निर्देशिका को खोलना कष्टप्रद है क्योंकि तब मेरी फाइलें फलक अन्य परियोजनाओं से भर जाती हैं जिनकी मुझे परवाह नहीं है।

कार्य को दिखाते हुए अप्रैल पुनरावृत्ति योजना "मल्टी-रूट, मल्टी-फ़ोल्डर वर्कस्पेस में जांच करें"। जांच के परिणाम क्या हैं?
@bpasero @tyriar

+1

क्षमा करें अगर मैं बहुत उत्सुक हो रहा हूँ। आप लोग अब कोड जारी करने में व्यस्त हैं।

नमस्ते,
ओपन फोल्डर डायलॉग को ओपन फोल्डर्स माना जाना चाहिए। इसलिए यदि मैं किसी विशेष अभिभावक फ़ोल्डर के अंतर्गत हूं, तो मैं एक ही समय में खोलने के लिए संवाद में इसके दो या अधिक उप फ़ोल्डरों को उजागर कर सकता हूं। यह इस सुविधा को शामिल करने के साथ एक स्वागत योग्य अतिरिक्त होगा। धन्यवाद। अच्छा दिन।

+ एक और

गीथहब के थ्रेड में इतने कम प्रयास वाली टिप्पणियां पहले कभी नहीं देखी गईं, विशेषकर पोस्ट-एमोजिस। अच्छाई मुझे।

मैं वास्तव में इस सुविधा को पसंद करूंगा। जैसा कि किसी और ने पहले ही कहा होगा, कई आधुनिक परियोजनाएं मॉड्यूलर हैं जैसे एक रेपो / प्रोजेक्ट में फ्रंटेंड और दूसरे में बैकेंड / एपी। आप अक्सर उन पर एक साथ काम करना चाहेंगे।

यही एकमात्र कारण है कि मैंने एटम को नहीं छोड़ा।

लंबे समय से स्थायी "रिपोस सस्ते हैं" मंत्र के साथ संयुक्त रूप से माइक्रोसर्विसेज और सर्वर रहित प्लेटफॉर्म हैं, यही कारण है कि यह एक होना चाहिए। यह असामान्य नहीं है कि ~ 30 [छोटे] रिपोजिटरी खुले हों और समवर्ती कई परियोजनाओं की फाइलों पर काम कर रहे हों; लोगों को उस कई खिड़कियों के बीच स्विच करने की उम्मीद है, या डेस्कटॉप वातावरण विंडो प्रबंधक में फ़ाइल दृश्य व्यवस्था को बंद करने से काम नहीं चल रहा है।

नमस्ते,
अब आप अपने 30 रिपोज का प्रबंधन कैसे करें
क्या आप अपने वातावरण में अन्य सीमाओं के कारण ऐसा कर रहे हैं? हो सकता है कि प्रोग्रामिंग भाषा में अंतर्मुखता न हो? हो सकता है कि एक एक्सटेंशन जो आपको कार्यात्मक हस्ताक्षर देने के लिए एपीआई पढ़ सकता है?
F # जैसी भाषा में एक सुविधा होती है जिसे टाइप प्रोवाइडर कहा जाता है, जिसमें से एक बस ऐसा कर सकता है और वेब की प्रोग्रामिंग को आसान बना सकता है। यह कई फ़ोल्डरों के लिए आपकी जरूरत को कम करने के लिए नहीं है, बस इतना है कि आप शायद इतने बड़े सक्रिय कार्यक्षेत्र के साथ कम से कम कुछ अन्य मुद्दों पर होंगे। धन्यवाद। अच्छा दिन।

@ pr-yemibedu, मुझे लगता है कि @martinjco क्या कह रही है कि उसके पास फाइलें नहीं हैं, लेकिन उसके पास रेपो की त्वरित संरचना है, अगर हमारे पास बहु-मूल संरचना है। कल्पना कीजिए, बस सीएमडी + पी को आपकी ज़रूरत की किसी भी फ़ाइल में;)

वर्तमान स्थिति के साथ समस्या यह है कि हमारे पास 30 अलग-अलग खिड़कियों के बीच फाइलें खुली या कम से कम स्विच होनी चाहिए क्योंकि वीएसकोड इसका समर्थन नहीं करता है।

मैं वास्तव में लापता सुविधा के कारण हाल ही में एटम में वापस आ गया हूं। मैं इस समय 9 रेपो के साथ एक परियोजना पर काम कर रहा हूं। मैं एक ही समय में 9 वीएसकोड विधवाओं को खोलना नहीं चाहूंगा, लेकिन मैं सिर्फ उस फ़ाइल का उपयोग करने के लिए एक शॉर्टकट का उपयोग करना चाहता हूं जिसकी मुझे आवश्यकता है।

@Dariusrosendahl की टिप्पणी से सहमत हैं। मैं एक नौसिखिया कोडर हूं और मुझे नए लिखने के लिए पुराने प्रोजेक्ट का संदर्भ देना होगा। उम्मीद है, कि जल्द ही बदल जाएगा, लेकिन उदात्त में मैं आसानी से तीन से चार परियोजना फ़ोल्डर और तुलना कर सकते हैं उन्हें एक ही सत्र में खुला

अगर हम उस दृश्य स्टूडियो में प्राप्त कर सकते हैं जो बहुत अच्छा होगा

नमस्ते,
मैं बनाए गए बिंदुओं से सहमत हूं क्योंकि आप मेरी पिछली पोस्टों को इस सुविधा के पक्ष में देख सकते हैं। एक सटीक कथन था जो मैं मार्टिंजको द्वारा टिप्पणी कर रहा था:

यह असामान्य नहीं है कि ~ 30 [छोटे] रिपोजिटरी खुले हों और समवर्ती कई परियोजनाओं की फाइलों पर काम कर रहे हों;

क्या nuno1895 दिखाता है कि मैं आज एटम का उपयोग कैसे करता हूं जब मुझे कई फ़ोल्डरों पर काम करने की आवश्यकता होती है लेकिन एक सरल मुख्य फोकस प्रोजेक्ट। मैं वास्तव में सक्रिय विकास के लिए VS2015, gedit, vim, notepad और notepad ++ दोनों का उपयोग करता हूं। प्रत्येक में ऐसी ताकतें हैं जिनके समकक्षों में अभी तक कोई समान नहीं है।

मैं बस यह समझने की कोशिश कर रहा था कि क्या कोई कोर पॉइंट है जिसे स्पष्ट किया जा सकता है। हम सभी इस पर काम करना चाहते हैं और डेवलपर्स के पक्ष में हैं जो इस पर समय बिताएंगे। इसीलिए मैं पूछ रहा था कि आज यह कैसे संभाला जाता है। 9 बनाम 30 ने शायद मेरी रुचि को उतनी प्रतिक्रिया नहीं दी है, लेकिन मुझे यह जानना पसंद है कि लोग vscode की तुलना कर रहे हैं और अगर यह मेरे लायक है तो मैं एक और टूल भी देख सकता हूं।

मैंने केवल Atom और SublimeText को तुलना के आधार के रूप में और उपयोगी स्क्रीनशॉट के साथ बात करते देखा है। इसे स्वीकार और कार्यान्वित करने के लिए अधिक चर्चा, अंगूठे और प्रतिक्रिया का स्वागत किया जाता है। धन्यवाद। अच्छा दिन।

एक बिंदु जिस पर पर्याप्त जोर नहीं दिया गया है वह फ़ोल्डर सेट (प्रोजेक्ट) के बीच जल्दी से "फ्लिप" करने की क्षमता है। इसे उदात्त में "क्विक स्विच प्रोजेक्ट" कहा जाता है। जब आप उस मेनू आइटम पर क्लिक करते हैं, तो आपको अपनी सभी परियोजनाओं की सूची के साथ एक पॉप-अप मिलता है, जब आप किसी एक परियोजना का चयन करते हैं, तो संपादक फ़ोल्डर (ओं) को प्रदर्शित करता है और आपकी सभी खुली हुई फाइलें जैसे ही आपने उन्हें छोड़ा था।
उदाहरण के लिए, यदि मैं प्रोजेक्ट A में काम कर रहा था और उसके पास app.js और index.html फाइलें खुली थीं और फिर प्रोजेक्ट B पर स्विच किया गया, तो यह प्रोजेक्ट A को बंद कर देगा और Project B को प्रदर्शित कर देगा। यदि मैं फिर प्रोजेक्ट A में वापस आ गया तो यह बंद हो जाएगा। मुझे फ़ोल्डर (ओं) और app.js और index.html दिखाएँ क्योंकि मैंने उन्हें छोड़ दिया था (यहां तक ​​कि बिना सहेजे गए संपादन भी हैं)।
अगर मुझे एक ही समय में दोनों परियोजनाएं खोलने की आवश्यकता है, तो मैं संपादक के दो उदाहरण खोल सकता हूं।
कुंजी यह है कि मैं अपना सारा सामान अलग बाल्टियों में रखने में सक्षम हूं और मैं उनके बीच तेजी से स्विच कर सकता हूं।

+1

नमस्ते,
मैंने उस फीचर के बारे में पढ़ा। उदात्त पाठ में ब्राउज़िंग के बिना परियोजनाओं को स्विच करना कुछ अच्छे और बुरे को इंगित करता है। कार्यक्षेत्र सेटिंग फ़ाइल में खुले कई फ़ोल्डरों को एनकोड करना शायद अच्छा होगा। यदि वह फ़ाइल गलत जगह लगती है, तो फ़ोल्डर्स और जेसन जैसी कोई चीज़ वर्तमान स्थिति को बनाए रखने के लिए बनाई जा सकती है, जो फ़ोल्डर और फ़ाइलें उपलब्ध हैं और वर्तमान कार्य सेट के लिए खुली हैं। धन्यवाद। अच्छा दिन।

मैंने कुछ महीने पहले VSCode का उपयोग करना शुरू किया था और आम तौर पर, मैं बहुत संतुष्ट हूं। मैं गाना बजानेवालों के लिए अपनी आवाज जोड़ूंगा और कहूंगा कि यह लापता विशेषता मेरे लिए बड़ा सिर-खरोंच है। क्या _any_ अन्य सभ्य संपादक हैं जिनके पास यह सीमा है? किसी भी मामले में, इसे ठीक किया जाना चाहिए। :)

यहाँ मेरी नई नौकरी में सेटअप है:
कोर टेक के लिए एक रेपो। कहो रास्ता C है: / mygamengine /
खेल कोड के लिए एक रेपो। यह C: / mygamengine / mygame के लिए सिंक किया गया है
खेल की सामग्री (बनावट आदि) के लिए एक रेपो: C: / mygamengine / mygame_data

तीनों गिट हैं। वे उप रेपो के रूप में स्थापित नहीं हैं, वे केवल उन फ़ोल्डरों के लिए सिंक किए गए हैं।

अधिमानतः मैं वीएस कोड में रूट फ़ोल्डर खोलना चाहता हूं और यह स्वचालित रूप से पता लगाएगा कि यह अनिवार्य रूप से तीन अलग-अलग परियोजनाएं हैं, और मायगेम के तहत फाइलें उस गिट रिपॉजिटरी की हैं न कि मायगेमेंगिन में।

मैं इस कार्यक्षेत्र के लिए सेटिंग्स सेट करने में सक्षम होना चाहता हूं जो प्रत्येक रिपॉजिटरी के लिए अलग हैं (उदाहरण के लिए, मैं इंजन प्रोजेक्ट पर लिंटर चलाना चाह सकता हूं लेकिन गेम कोड पर नहीं)। यह भी अच्छा होगा यदि डिफ़ॉल्ट रूप से कार्यक्षेत्र सेटिंग्स सभी तीन परियोजनाओं पर निर्धारित की गई थीं।

वाह, यह अभी भी हल नहीं किया गया है? मैं एटम को वीएस कोड से बदलने की उम्मीद कर रहा था, समीक्षाओं के अनुसार, यह बहुत तेज है और एटम के रूप में पिछड़ता नहीं है।
मेरा मुख्य प्रोजेक्ट दो गिट रेपो है, एक बैक एंड और दूसरा फ्रंट एंड। स्थानीय रूप से दोनों एक ही फ़ोल्डर में हैं, लेकिन यदि एटम या वीएस कोड उस मूल फ़ोल्डर को खोलता है, तो कोई भी जीआईटी स्थिति पहचानी नहीं जाती है।
एटम में मैं सिर्फ अपने कार्यक्षेत्र में दोनों फ़ोल्डर्स जोड़ता हूं और बस काम करता हूं।

: चमक: अद्यतन: चमक:

हमारे अंतिम अपडेट के बाद से कुछ समय हो गया है तो मैंने सोचा कि मैं सभी को गति प्रदान करूंगा। खुद, @bpasero और टीम के बाकी

इसमें इतना समय क्यों लग रहा है?

यह इतना लंबा समय ले रहा है क्योंकि यह सुविधा हमारी एकमात्र ज़िम्मेदारी नहीं है और मल्टी-रूट होने में शामिल कार्य काफी विशाल है। शुरुआत के लिए VS कोड के भीतर सभी घटकों को इस धारणा के तहत डिज़ाइन किया गया था कि किसी भी समय केवल एक फ़ोल्डर या कोई फ़ोल्डर नहीं खोला गया है। जब आपके पास इस तरह की धारणा के साथ हमारे जितना बड़ा कोडबस होता है, तो इसे और अधिक लचीला बनाने के लिए बहुत सारे काम लगते हैं।

कुछ उदाहरण देने के लिए, यहां हमने अब तक पहचाने गए कुछ बड़े दर्द बिंदु दिए हैं:

• एक्सटेंशन API एक एकल workspace.rootPath उजागर करता है, यह अपर्याप्त है जब हम मल्टी-रूट फ़ोल्डर्स के लिए समर्थन जोड़ते हैं। हम इन एक्सटेंशनों को तोड़ने से बचना चाहते हैं और यदि आवश्यक हो तो माइग्रेशन पथ प्रदान करें।
• मल्टी-रूट दुनिया में जिस तरह से वर्कस्पेस सेटिंग्स इंटरैक्ट करती हैं वह थोड़ा अलग है। workbench.statusBar.visible उदाहरण के लिए लें जो वर्तमान में कार्यक्षेत्र सेटिंग्स में अनुमत है। अब हम इसका समर्थन नहीं कर पाएंगे क्योंकि यह 2 फ़ोल्डरों में परिभाषित होने पर अजीब / छोटी गाड़ी का व्यवहार करेगा। हम इस तरह के मामलों से निपटने का तरीका जानने की प्रक्रिया में हैं।
• SCM प्रदाता (git) को कई फ़ोल्डरों का समर्थन करने के लिए संभवतः UX कार्य की सबसे बड़ी राशि की आवश्यकता है: क्या हमें "सक्रिय प्रोजेक्ट" की अवधारणा को पेश करने की आवश्यकता है? स्पष्ट रूप से सेट किया जाना चाहिए (फ़ोल्डर पर राइट क्लिक करें और इसे सेट करें) या इसे अंतर्निहित होना चाहिए (सक्रिय फ़ाइल के फ़ोल्डर को देखकर)? क्या यह एक वैश्विक अवधारणा होनी चाहिए या उस विशिष्ट विशेषता तक सीमित होनी चाहिए? आदि।

हम एक खराब सोच वाले समाधान के साथ बाहर नहीं निकलना चाहते हैं इसलिए हम अपना समय ले रहे हैं और वास्तव में संभावित समस्याओं और निहितार्थों के माध्यम से सोच रहे हैं कि यह प्रत्येक घटक को कैसे प्रभावित करेगा। यह तैयार होने पर आएगा।

टिप्पणियों का सारांश आज तक

मैंने अभी तक फीडबैक को टालने के लिए कुछ घंटों का समय दिया। इस सामान में से कुछ को वर्गीकृत करना थोड़ा कठिन था, लेकिन यहाँ उन लोगों के बारे में बताया गया था जो सामान्य रूप से हैं (मैं पैराफ़्रास्टिंग कर रहा हूँ)।

• मैं कई फ़ोल्डर्स में गिट एकीकरण चाहते हैं
• वर्तमान फ़ोल्डर स्विचिंग और / या OS विंडो प्रबंधन UX बोझिल है
• मैं कई फ़ोल्डरों में खोज करना चाहता हूं
• मैं कई फ़ोल्डरों में डिबग करना चाहता हूं

चिंताओं

• क्या रिफैक्टरिंग परियोजनाओं पर या किसी एक परियोजना पर काम करते हैं?
• मैं किस प्रोजेक्ट पर Git कर रहा हूं?
• मेरी खोज किस फ़ोल्डर में चल रही है?
• कार्यक्षेत्र सेटिंग्स को न तोड़ें
• एक्सटेंशन न तोड़ें - नए API के बारे में एक्सटेंशन डेवलपर्स को चेतावनी दें
• एक स्लैक-स्टाइल टैब्ड यूएक्स मेरे लिए पर्याप्त नहीं है, जो अनिवार्य रूप से ओएस से वीएस कोड तक सिर्फ खिड़की प्रबंधन को स्थानांतरित कर रहा है - मैं एक सिंगल विंडो (यानी संपादक समूहों के सेट) में परियोजनाओं से सभी फाइलों तक पहुंचने में सक्षम होना चाहता हूं।
• "मेरे अर्थ में यह कई अन्य चिंताओं का परिचय देता है, git के लिए कई प्रोजेक्ट्स रूट, खोज ..... इस UX के लिए बहुत बुरा है और संभवतः संपादक को बग और जटिलता का परिचय देगा।"

अन्य टिप्पणी

• मैं केवल अपने "git फ़ोल्डर" में रेपो का एक सबसेट खोलना चाहता हूं
• मैं एक एकल फ़ोल्डर में खोज करने या परियोजना द्वारा खोज परिणामों को व्यवस्थित करने का एक अच्छा तरीका चाहता हूं
• मैं जल्दी से पढ़ने के लिए निर्भरता कोड पर नेविगेट करने में सक्षम होना चाहता हूं
• मैं विभिन्न फ़ोल्डरों के लिए टाइपस्क्रिप्ट के विभिन्न संस्करणों को चलाना चाहता हूं
• वीएस कोड विशालकाय भंडार के साथ बहुत धीमा है
• मैं कुछ परियोजनाओं को हमेशा संदर्भ के लिए उपयोग करने के लिए खुला रखना चाहता हूं (जैसे। एक विषय / टेम्पलेट)
• मैं वी.एस. कोड को पहचानना चाहता हूं। किसी भी निर्देशिका में .vcode / settings.json फाइलें (इससे वर्कअराउंड में मदद मिलेगी)
• मुझे एक प्रोजेक्ट रूट (खोज / डिबग) और एक रूट रूट परिभाषित करने दें
• उदात्त बहु-फ़ोल्डर गिट एकीकरण को सुरुचिपूर्ण ढंग से संभालता है
• स्लैक UI के समान टैब्ड फ़ोल्डर्स (जैसे। कुछ सक्रिय प्रोजेक्ट प्रतिमान)
• प्रत्येक फ़ोल्डर के लिए एक्सप्लोरर में एक अलग अनुभाग
• एक फ़ोल्डर को प्राथमिक के रूप में और बाकी को लिंक / उप-फ़ोल्डर के रूप में उपयोग करें
• मैं उदात्त में त्वरित स्विच परियोजना चाहता हूं (फास्ट स्विच + कार्यक्षेत्र लेआउट को बनाए रखना)
• कार्यक्षेत्र प्रबंधन की यह शैली निम्नलिखित के लिए विशेष रूप से उपयोगी है: npm मॉड्यूल, जूलिया, हरको पा, वर्डप्रेस, ड्रिबल

वर्तमान वर्कअराउंड

यहाँ वर्तमान में मुख्य वर्कअराउंड हैं:

• परस्पर माता-पिता को खोलना
• Git प्रोजेक्ट मैनेजर
• प्रोजेक्ट मैनेजर
• "मास्टर फ़ोल्डर" की उप-निर्देशिकाओं के रूप में फ़ोल्डर को सिंबल करें

कब टिप्पणी करें?

कृपया टालें: +1: या "मुझे यह चाहिए" टिप्पणी। जब इस मुद्दे पर एक टिप्पणी की जाती है, तो 153 और गिनती करने वाले लोगों को सदस्यता बटन हिट करने वाले कई और लोगों के अलावा अधिसूचित किया जाता है। टिप्पणी करना भी टीम अपडेट को दफन कर देगा इसलिए उस पर ध्यान देने की कोशिश करें। हर तरह से टिप्पणी करें, हालांकि यह बातचीत में जोड़ता है।

एक विशेषता जिसमें कई जड़ें होने की तुलना में अधिक उपयोग होता है, वह है कॉन्फ़िगर करने योग्य कार्य करने की क्षमता को जोड़ना। यह आपको एक पारस्परिक माता-पिता को खोलने में सक्षम करेगा, लेकिन इस परियोजना के भीतर फ़ोल्डर्स के कई संयोजन हैं।

आम तौर पर यह किसी भी परियोजना के लिए उपयोगी होगा कि वह कुछ फ़ाइलों / फ़ोल्डरों पर एक बार में पूरे कोड के लिए कॉन्फिगरेशन को बदले बिना पूरे रूट पर "फोकस" कर सके।

इस सुविधा के बारे में कोई योजना नहीं?

आप इस सुविधा के लिए योजना @Tyriar की टिप्पणी और संबंधित लिंक में देख सकते हैं:
https://github.com/alefragnani/vscode-project-manager/issues/46
https://github.com/Microsoft/vscode/issues/26068

हम इसके लिए हमारे डिजाइन साझा करना चाहते हैं और आपकी प्रतिक्रिया प्राप्त करना चाहते हैं। ऐसा करने के लिए हम कई कॉन्फ्रेंस कॉल सेट करने जा रहे हैं जहां हम अपने डिजाइनों के माध्यम से चलेंगे और डिजाइनों के बारे में आपकी प्रतिक्रियाओं पर चर्चा करेंगे।

यदि आप इन चर्चाओं में भाग लेना चाहते हैं और हमें डिज़ाइन को सही बनाने में मदद करना चाहते हैं, तो कृपया मुझसे संपर्क करें (मुझे ईमेल भेजें - microsoft dot com पर स्टीवनक्ल) और मैं इन्हें स्थापित करूंगा।

हम गुरुवार 1 जून और शुक्रवार 2 जून को इन चर्चाओं को निर्धारित करने की उम्मीद कर रहे हैं।

@Tyriar @stevencl धन्यवाद दोस्तों! :ताली:

आज सत्र में शामिल होने के लिए सभी को धन्यवाद। सत्रों की रिकॉर्डिंग यहां पोस्ट की गई है

• समूह 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> ओपन वर्कस्पेस_ जैसे वर्तमान-फ़ाइल> ओपन फोल्डर_ की तरह एक शीर्ष-स्तरीय कमांड की उम्मीद है।
  
  
  • कुल मिलाकर, मैं इस बारे में निश्चित नहीं हूं। क्षमा करें, मेरे पास अधिक ठोस सुझाव नहीं हैं।
  
  

फिर से धन्यवाद, इस के साथ, VSCode नई महाशक्तियों का लाभ उठाएगा,

वीडियो शेयर करने के लिए धन्यवाद। मैं "एक रूट प्रति रूट फ़ोल्डर" डिज़ाइन का समर्थन करना चाहूंगा:

पहले, मैं अन्य (उदात्त-पाठ-जैसी) डिज़ाइन की उम्मीद कर रहा था, लेकिन "एक रूट प्रति रूट फ़ोल्डर" विकल्प को देखने के बाद, यह मेरे लिए स्पष्ट हो गया कि इस दृष्टिकोण के निम्नलिखित फायदे थे:

• फ़ोल्डरों के बीच स्पष्ट, अस्पष्ट अंतर और अलगाव (खासकर अगर मेरे पास उनमें से 2 या 3 से अधिक है, जो अक्सर ऐसा होता है जब मैं अन्य संपादकों और आईडीई का उपयोग करता हूं)
• इस धारणा को लागू करता है कि एक रूट फ़ोल्डर एक अलग (उप) परियोजना है
• उप-प्रोजेक्ट कमांड (जैसे "नई फ़ाइल", "रिफ्रेश" ... और संभवत: भविष्य में, उस विशिष्ट उप-परियोजना पर एक कार्य (जैसे "पुनर्निर्माण") शुरू करने के लिए राइट-क्लिक पर त्वरित पहुंच;)
• जैसा कि 2 वें समूह द्वारा उल्लेख किया गया है, इस डिजाइन के साथ, फ़ोल्डर-नाम-ट्रंकेशन समस्या होने की संभावना कम है

"एक रूट प्रति रूट फ़ोल्डर" अवधारणा के बारे में ... मुझे यकीन नहीं है कि यह मेरे और मेरे अधिकांश उपयोग मामलों के लिए अच्छा काम करेगा। जब भी मेरे पास कई-जड़ स्थिति होती है, तो यह सामान्य है कि मेरे पास कई हैं ; सिर्फ 2 या 3 नहीं।
मुझे यकीन नहीं है कि यह दृष्टिकोण कैसे पैमाना होगा?

वर्तमान फ़ोल्डर-जैसे लेआउट के लिए कुछ तर्क यह भी है कि यह इस बात के अनुरूप है कि मोनोरपो कैसे प्रदर्शित किया जाएगा। उदाहरण के लिए, तुलना करें:

monorepo/      <- contains .git
  project1
  project2

बनाम

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

उन दोनों को वास्तव में VSCode द्वारा काफी समान माना जाना चाहिए: मोनोरेपो पहले से ही है (कमिटिंग: प्राकृतिक, खोज: "शामिल करने के लिए फाइलें", कई READMEs: उनका फ़ोल्डर संपादक टैब में प्रदर्शित होता है; आदि)। मल्टी-रूट को इसका यथासंभव बारीकी से पालन करना चाहिए, आईएमओ, जिसे वर्तमान डिज़ाइन बहुत अच्छी तरह से करता है।

@stevencl एक बात जो मुझे पूरी तरह से समझ में नहीं आई: क्या समाधान .vscode सेटिंग का स्कोप (या यहां तक ​​कि पदानुक्रमित) उपचार लाएगा? जैसे, अगर मेरे पास .vscode प्रति-स्तरीय फ़ोल्डर था, तो क्या वे सेटिंग्स व्यक्तिगत रूप से लागू की जाएंगी? क्या वे किसी तरह प्रोजेक्ट रूट पर एकत्र होंगे? या केवल "प्राथमिक" .vscode गिनती होगी?

मैं "रूट फोल्डर प्रति रूट फ़ोल्डर" डिजाइन को पसंद करता हूं, जो कि @maddouri द्वारा सूचीबद्ध समान कारणों के लिए है। इसके अलावा, अन्य विकल्प (एटम में) का उपयोग करने के बाद, यह खोजना बहुत कठिन है कि एक नया रूट-फ़ोल्डर कहाँ से शुरू होता है जब कई उच्च-पदानुक्रमित फ़ोल्डर खुले और विस्तारित होते हैं।

डिजाइन अपडेट के लिए धन्यवाद, यह वास्तव में अच्छा लग रहा है!

क्या यूआई में एक साथ कई कार्यस्थान उपलब्ध होने की संभावना है? ताकि आप आसानी से उनके बीच स्विच कर सकें। उदाहरण के लिए, आपके पास कुछ ऐसा है:

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

और फिर CONNECT, CONNECT-PLUGIN डिवाइडर पर डबल-क्लिक करने से वह सक्रिय कार्यक्षेत्र के रूप में बदल जाएगा। यह उन लोगों के लिए कार्यक्षेत्र के बीच आसान स्विचिंग की अनुमति देगा, जिन्हें कई परियोजनाओं के सेट से निपटना पड़ता है। मैं सुझाव नहीं दे रहा हूं कि वे सभी खोज और एससीएम और व्हाट्सएप के लिए उपलब्ध रहें, यह वर्तमान कार्यक्षेत्र के साथ रहेगा जो वर्तमान में विस्तारित है।

फिर पहले समूह में सुझाए गए रूट फ़ोल्डर्स को हाइलाइट करने के साथ काम कर सकता है, और संभवत: उन फ़ोल्डरों पर मँडराते समय नई फ़ाइल / फ़ोल्डर आइकन उपलब्ध होंगे।

सेटिंग्स JSON पर कुछ प्रतिक्रिया, यह कार्यक्षेत्र सेटिंग्स के लिए उपयोगी हो सकता है जैसे कुछ:

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

तो फिर root पथ के बजाय फ़ोल्डर्स को खोलने का स्रोत बन जाता है, लेकिन रूट स्वयं नहीं खोला जाता है, केवल प्रत्येक फ़ोल्डर। फिर आपके पास "प्राथमिक फ़ोल्डर" नहीं है, लेकिन फिर भी सापेक्ष फ़ाइल पथ रखें। यह मान रहा है कि आप यूआई के माध्यम से एक पूर्व-निर्धारित कार्यक्षेत्र खोल सकते हैं, जैसा कि रूट फ़ोल्डर और इसके साथ सभी अतिरिक्त फ़ोल्डरों को खोलने के लिए। फिर नाम का उपयोग विभक्त के रूप में किया जा सकता है बड़ी संख्या में फ़ोल्डर के नाम को रोककर इसे बहुत लंबा, या अनपेक्षित रूप से छोटा कर दिया जाता है।

यदि "एक रूट प्रति रूट फ़ोल्डर" समाधान चुना जाता है, तो मैं सुझाव देना चाहूंगा कि वर्तमान में दिखाई देने वाला रूट फ़ोल्डर साइडबार के शीर्ष पर "चिपक जाता है", बजाय स्क्रॉल आउट के। एक बार बाद के रूट फ़ोल्डर के साइडबार के शीर्ष पर पहुंचने के बाद यह केवल ऊपर स्क्रॉल करेगा।

4 जून, 2017 को सुबह 6:47 बजे, पीटर पेट्रोव नोटिफिकेशन @github.com ने लिखा:

मैं "रूट फोल्डर प्रति रूट फ़ोल्डर" डिजाइन को पसंद करता हूं, जो कि @maddouri द्वारा सूचीबद्ध समान कारणों के लिए है। इसके अलावा, अन्य विकल्प (एटम में) का उपयोग करने के बाद, यह खोजना बहुत कठिन है कि एक नया रूट-फ़ोल्डर कहाँ से शुरू होता है जब कई उच्च-पदानुक्रमित फ़ोल्डर खुले और विस्तारित होते हैं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपको इस धागे की सदस्यता दी गई है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

या हम उदात्त, परमाणु दृष्टिकोण का अनुसरण कर सकते हैं, लेकिन रंग बदल सकते हैं या किसी तरह दिखा सकते हैं कि कौन सा फ़ोल्डर रूट है और / या इसे शीर्ष पर चिपका दें। बेशक दोनों दृष्टिकोण अच्छे हैं, लेकिन बहुत सारे खुले फ़ोल्डर होने से स्थान कम हो जाता है, क्योंकि ताज़ा करने के साथ बार, एक नई फ़ाइल बनाएं आदि दिखाई देंगे, यही कारण है कि बार को लोड नहीं करना बेहतर है, लेकिन किसी भी तरह दिखाओ कि कौन सा फ़ोल्डर है जड़। लेकिन फिर से, यह बार वास्तव में अच्छा है, क्योंकि खुले रूट फ़ोल्डर को देखना बहुत आसान है और आप उन्हें ताज़ा कर सकते हैं और अन्य चीजें कर सकते हैं जो बार में शामिल हैं। हमें यह देखने की आवश्यकता है कि यह कैसा लगता है जैसे कि 10 फ़ोल्डर बिना बार के साथ खोले गए।

@stevencl उन रिकॉर्डिंग को पोस्ट करने के लिए धन्यवाद! कुल मिलाकर, मैं उस दिशा के बारे में उत्साहित हूं जिसमें यह सुविधा बढ़ रही है! अब तक इसमें लगाए गए हर समय और प्रयास के लिए धन्यवाद। यहाँ मेरी प्रतिक्रिया / विचार है:

• मैं "EXPLORER" के तहत एकल फ़ोल्डर नाम बार डिज़ाइन के साथ पहला डिज़ाइन पसंद करता हूं, हालांकि, मुझे चिंता है कि अगर सभी फ़ोल्डर नामों को वहां सूचीबद्ध किया गया है, तो "फ़ाइल जोड़ें" दिखाने के लिए यह बहुत जल्दी समाप्त हो जाएगा। " फ़ोल्डर जोड़ें ", आदि, बटन। मुझे लगता है कि मैं स्ट्रिंग "मल्टीपल" या ऐसा ही कुछ डालूंगा जब एक से अधिक फ़ोल्डर खुले हों; अन्यथा, वहाँ सिर्फ एक फ़ोल्डर है इसलिए फ़ोल्डर का नाम वहां रखें जैसा कि आज किया गया है (और पेड़ में फ़ोल्डर जड़ को छिपाएं)।
• संपादक, IMO में टैब शीर्षक में फ़ोल्डर का नाम जोड़कर फ़ाइल नामों की अस्वीकृति आवश्यक नहीं है, जब तक कि एक ही फ़ाइल नाम के साथ कई संपादक खुले न हों। ध्यान दें कि यह परिदृश्य एक फ़ोल्डर के खुले होने पर भी असामान्य नहीं है। एक ही रूट के भीतर सबफ़ोल्डर्स के बीच एक ही नाम के साथ कई फाइलें (जैसे .gitignore ) प्राप्त करना काफी आसान है। तो यह डिजाइन (मूल फ़ोल्डर नाम को जोड़ते हुए) एक अलग सुविधा, आईएमओ होना चाहिए, और इसे लागू किया जाना चाहिए। इसके साथ ही, मुझे https://github.com/Microsoft/vscode/issues/15048 का एक अच्छा समाधान देखना अच्छा लगेगा क्योंकि इससे कुछ टैब शीर्षक और भी लंबे हो जाएंगे। :)
• खोज परिणामों के लिए, मुझे लगता है कि यह आवश्यक है कि सभी रूट फ़ोल्डरों में खोज कार्य हो। खोज को चुनी गई जड़ों तक सीमित करने के लिए एक और फिल्टर जोड़ा जा सकता है। परिणाम प्रदर्शित करते समय, प्रति रूट परिणाम देखने के लिए उपयोगी हो सकता है, इसलिए हो सकता है कि रूट फ़ोल्डर नामों के साथ एक लंबी सूची देखने के लिए एक विकल्प जोड़ा गया हो, या वर्गों में अलग-अलग सूची देखने के लिए, प्रत्येक रूट फ़ोल्डर के लिए एक।
• मुझे यह अजीब लगता है कि आप 'वर्कस्पेस' को __user settings__ में जोड़ने का प्रस्ताव कर रहे हैं। मुझे वास्तव में यह __वर्कस्पेस सेटिंग__ में अंत-अप होने की उम्मीद थी। I _think_ आप वास्तव में कह रहे हैं कि कार्यक्षेत्र सेटिंग में नई 'कार्यस्थान' संपत्ति भी हो सकती है, जो अच्छी है। यह वास्तव में अच्छा है कि कार्यक्षेत्र पथ सापेक्ष हो सकते हैं। यह सिर्फ उपयोगकर्ता सेटिंग्स में से कुछ के होने के लिए प्रतीत नहीं होता है। यह एक ऐसी सुविधा है जो कार्यक्षेत्रों के लिए बहुत विशिष्ट महसूस करती है। आह, लेकिन अब मैं देख रहा हूं कि यह उपयोगकर्ता सेटिंग्स में मान्य क्यों है, क्योंकि यह मुझे इन कार्यक्षेत्रों को संग्रहीत करने का एक तरीका देता है जब मैं अपने एचडीडी पर "यादृच्छिक" फ़ोल्डर चाहता हूं एक कार्यक्षेत्र में जहां कोई आम जड़ नहीं है।
• जब वे उपयोगकर्ता सेटिंग्स में संग्रहीत होते हैं, तो एक चीज़ जो कार्यस्थानों में खो जाती है, वह एक प्रोजेक्ट स्पेस या किसी अन्य के लिए जिम्मेदार अन्य प्रोजेक्ट-विशिष्ट सेटिंग्स को रखने की क्षमता है। उदाहरण के लिए, यदि मेरे पास एक कार्यक्षेत्र है जहां मुझे टैब का आकार 2 स्थान की आवश्यकता है और एक और जहां यह 3 होना चाहिए था, मैं उपयोगकर्ता सेटिंग्स में कार्यक्षेत्रों के साथ ऐसा करने में सक्षम नहीं होगा। मुझे कहीं एक फ़ोल्डर बनाना होगा, और फिर उसके अंदर .vscode फ़ोल्डर डालना होगा, और फिर अंत में उपयुक्त टैब आकार ओवरराइड के साथ मेरे कार्यक्षेत्र को परिभाषित करने के लिए .vscode/settings.json को परिभाषित करना होगा। इस बिंदु पर, मैं सोच रहा हूं कि एक नया VSCode प्रोजेक्ट फ़ाइल प्रकार बनाना जो इन सभी सेटिंग्स को संग्रहीत करता है और एक विशेष फ़ाइल के रूप में खोला जा सकता है कार्यक्षेत्र settings.json को संग्रहीत करने के लिए फ़ोल्डरों के इस पदानुक्रम को बनाने की तुलना में बहुत कम बोझिल हो जाता है।

पहले डिज़ाइन में, अतिरिक्त फ़ोल्डरों के लिए, कोष्ठक में पथ (सापेक्ष या निरपेक्ष) को विभेदन के नाम पर जोड़ा जा सकता है। मुझे लगता है कि एक सरल समाधान होगा।

@stevencl सत्र रिकॉर्ड करने के लिए धन्यवाद। मैं वास्तव में भाग लेना चाहता था, लेकिन उस समय उपलब्ध नहीं था

मुझे प्रस्तावित SCM इंटरफ़ेस पसंद आया। सारांश अनुभाग और फ़ोल्डर के प्रति एक खंड होने से मुझे, IMHO, परिवर्तनों के साथ पता लगाने और काम करने के लिए बहुत आसान इंटरफ़ेस मिलता है। और मुझे यह विचार पसंद है कि पूरे यूआई में एक सुसंगत व्यवहार हो, इसलिए प्रत्येक परिणाम में फ़ोल्डर नाम को संक्षिप्त करने के बजाय प्रति अनुभाग एक फ़ोल्डर विचार का उपयोग खोज टैब में भी किया जाना चाहिए। एक्सप्लोरर टैब के लिए भी ऐसा ही है।

_Multi-Folder_ को संग्रहीत करने के लिए उपयोगकर्ता सेटिंग्स का उपयोग करना मेरे लिए थोड़ा अजीब है, क्योंकि यह _doesn't को उपयोगकर्ता सेटिंग_: मुस्कान: लगता है additionalFolder एंट्री _always_ Workspace Settings का हिस्सा बनाते हैं Workspace Settings जोड़ा जाएगा। फिर, जब कोई फोल्डर खोलते हैं, तो आप .vscode\settings.json फ़ाइल और additionalFolders प्रविष्टि की तलाश करते हैं, _if की जाँच करने के लिए यह एक मल्टी-फ़ोल्डर_ वर्कस्पेस है। _ यह दूसरे उदाहरण के समान है जो आपने उपयोग किया था, दो गुम git repos_ के बारे में।

SomeFolder.vscodesettings.json

{
    "editor.wordWrap": "off",
    "editor.codeLens": false,
    "editor.renderWhitespace": "all",
    "workbench.colorTheme": "Abyss",

    "additionalFolders": [
        "./express",
        "./express-plugin",
        "~/commons/other-stuff",
        "file:///C://Temp//oldlib"
    ]
}

इसके अलावा, _user-data_ स्थानों को ~ और $home , जिससे विभिन्न कंप्यूटरों / प्लेटफार्मों के बीच परियोजनाओं को साझा करना आसान हो जाए।

मुझे केवल एक ही बिंदु याद आया: एपीआई । एक्सटेंशन उसके साथ कैसे एकीकृत होंगे?

प्रयासों के लिए धन्यवाद। पहले अंदरूनी सूत्रों के लिए आगे देख रहे हैं ins

प्रतिक्रिया के लिए धन्यवाद! मैं "मल्टी रूट" को लागू करने के लिए एक नई सेटिंग्स संपत्ति additionalFolders का लाभ उठाने की दिशा पर चलना चाहता था क्योंकि मैं ऊपर की टिप्पणियों से इस पर कुछ प्रतिक्रिया सुनता हूं।

पहली जगह में एक सेटिंग शुरू करने के लिए मुख्य प्रेरणा वास्तव में चीजों को सरल रखना है और कई नई अवधारणाओं को पेश नहीं करना है जबकि अभी भी एक समाधान है जो शक्तिशाली है और कुछ दिलचस्प परिदृश्यों को सक्षम करता है। यहाँ कुछ डिज़ाइन निर्णय और परिणाम दिए गए हैं:

इसे सरल रखें
हमें लगता है कि फाइलें और फोल्डर खोलना वीएस कोड के मूल में है। इस प्रकार हम "प्रोजेक्ट्स" की एक नई शीर्ष स्तरीय अवधारणा को पेश नहीं करना चाहेंगे। उदाहरण के लिए, हम यह नहीं सोचेंगे कि "ओपन प्रोजेक्ट" एक्शन की आवश्यकता थी, बल्कि यह सोचें कि एक प्रोजेक्ट हमेशा एक फ़ोल्डर होता है और इसमें वैकल्पिक रूप से अतिरिक्त फ़ोल्डर जुड़े हो सकते हैं। इस धारणा के साथ, एक सेटिंग उस के लिए अनुमति देने के प्राकृतिक तरीके की तरह लगता है। जब भी आप इस फ़ोल्डर को खोलते हैं, तो आप इसके साथ अतिरिक्त फ़ोल्डर खोलते हैं। फ़ोल्डर्स जोड़ना और हटाना एक सरल इशारा है और यह सीधे सेटिंग्स को अपडेट करेगा।

सेटिंग्स शक्तिशाली हैं
एक सेटिंग के रूप में बहु रूट होने से कई दिलचस्प परिदृश्य सक्षम होते हैं। उदाहरण के लिए, आप additionalFolders सेटिंग को अपने कार्यक्षेत्र में डालने के लिए स्वतंत्र हैं और इस तरह इसे अन्य लोगों के साथ साझा करते हैं (रिश्तेदार रास्तों का उपयोग करके - यह वीडियो में दिखाया गया है)।
उसके शीर्ष पर, आप यह भी आज़ाद हैं कि आप पहली बार परियोजनाओं को कैसे सेट करते हैं: उदाहरण के लिए, कुछ मामलों में अतिरिक्त फ़ोल्डरों के लिए एक मास्टर फ़ोल्डर का कोई स्पष्ट संबंध नहीं है (उदाहरण के लिए यह हो सकता है कि उनमें से कुछ भी संबंधित नहीं हैं एक दूसरे)। उस स्थिति में आप बस एक "प्रोजेक्ट" फ़ोल्डर बना सकते हैं, जिसमें सिर्फ एक settings.json उस फ़ोल्डर के साथ शामिल होता है जो इससे लिंक करता है:

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

अब जब आप allMyRandomProjects खोलेंगे तो यह आपको सेटिंग्स के आधार पर फ़ोल्डर्स की सूची दिखाएगा। आप settings.json में कुछ सेटिंग्स भी शामिल कर सकते हैं जो दिखाए गए सभी फ़ोल्डरों पर लागू होनी चाहिए।

कार्यक्षेत्र स्विचिंग और मल्टी विंडो
एक शक के बिना, हमें वीएस कोड में बेहतर कार्यक्षेत्र स्विचिंग और मल्टी विंडोज समर्थन पर काम करने की आवश्यकता है। चूंकि हम एक मल्टी-रूट वर्कस्पेस को एक फ़ोल्डर के साथ किसी अन्य कार्यक्षेत्र के समान मानते हैं, कार्यक्षेत्र स्विचिंग और मल्टी विंडोज समर्थन में सुधार से किसी भी उपयोगकर्ता को लाभ होगा, यहां तक ​​कि मल्टी-रूट वर्कस्पेस का लाभ नहीं उठा रहे हैं।
हमें फ़ोल्डरों के बीच स्विच करने के बेहतर और आसान तरीकों पर गौर करना होगा और मल्टी-रूट से स्वतंत्र विंडो खोली होंगी।

अपनी अगली टिप्पणी में मैं व्यक्तिगत टिप्पणियों पर कुछ प्रतिक्रिया दूंगा।

@borekb खोज में एक विशिष्ट रूट फ़ोल्डर (या एकाधिक) तक सीमित करने के विकल्प शामिल होंगे उसी तरह से आप आज पहले से ही एक विशिष्ट पथ को शामिल करने के लिए खोज को कॉन्फ़िगर कर सकते हैं।

@madduri @TurkeyMan @pesho , @dgileadi @stefcameron यह स्पष्ट प्रतीत होता है कि कुछ लोग एक पेड़ को पसंद करते हैं और दूसरे को एक्सप्लोरर में कई वर्गों को पसंद करते हैं। तो हम इसके लिए एक सेटिंग के साथ समाप्त हो सकते हैं, दोनों समाधानों के लिए पेशेवरों और विपक्ष हैं और यह उपयोगकर्ता के लिए होना चाहिए जो परिदृश्य के लिए बेहतर है।

@borekb सेटिंग कैसे लागू होती है, यह थोड़ा बदल जाएगा, क्योंकि आप जिस मल्टी-रूट सेटअप में हैं, उस पर निर्भर करता है: उपयोगकर्ता सेटिंग्स हमेशा पहले की तरह खोले गए सभी फ़ोल्डरों पर लागू होती हैं। कार्यक्षेत्र सेटिंग्स को मुख्य ("मास्टर") फ़ोल्डर से उठाया जाएगा और उन सभी फ़ाइलों और फ़ोल्डरों पर लागू किया जाएगा जो इससे जुड़े हैं। अब, आप अभी भी कार्यक्षेत्र सेटिंग्स के माध्यम से किसी भी अतिरिक्त फ़ोल्डर पर सेटिंग्स को परिभाषित कर सकते हैं, हालांकि हम उन सभी का समर्थन नहीं कर सकते हैं। उदाहरण के लिए, update.channel: none फ़ोल्डर के आधार पर files.exclude , सभी संपादक सेटिंग्स) पर समर्थन कर सकते हैं और उन्हें सक्षम करने के लिए आवश्यक परिवर्तन करते हैं। यह हमारे द्वारा निवेश किए जाने वाले कार्य के प्रमुख क्षेत्रों में से एक है, खासकर जब से एक्सटेंशन उन सेटिंग्स को भी परिभाषित कर सकते हैं जिन्हें हम प्रति-फ़ोल्डर गुंजाइश पर समर्थन करना चाहते हैं।

@BTMorton मुझे लगता है कि आप कार्यस्थानों को स्विच करने के आसान तरीके चाहते हैं। यह वह चीज है जिसे हमें किसी भी फ़ोल्डर संक्रमण के लिए मल्टी-रूट से स्वतंत्र रूप से देखना चाहिए जो एक उपयोगकर्ता कर सकता है।

@stefcameron हम additionalFolders सेटिंग को पर्याप्त रूप से खुला रखेंगे ताकि अंततः इसमें अतिरिक्त मेटा डेटा जोड़ा जा सके। उदाहरण के लिए, मैं इस तरह के एक विन्यास के लिए एक नाम प्रदान करने में सक्षम होने के बारे में सोच सकता था ताकि परियोजनाओं के बीच स्विच करना नाम से हो और मुख्य फ़ोल्डर से न हो।

एक चीज़ जो हमने अभी तक वीडियो में नहीं देखी है वह यह है कि एक्सटेंशन मल्टी-रूट फ़ोल्डर का समर्थन कैसे कर सकते हैं। मल्टी-रूट समर्थन के साथ एक और प्राथमिक लक्ष्य ("इसे सरल रखें") है: एक्सटेंशन को न तोड़ें

आज, एक्सटेंशन में वर्तमान में खोले गए कार्यक्षेत्र ( workspace.rootPath: string ) तक पहुंचने के लिए सरल एपीआई है। यह संपत्ति null हो सकती है जब कोई फ़ोल्डर नहीं खोला जाता है।

अब, additionalFolders सेटिंग की शुरुआत के साथ, एक एक्सटेंशन अभी भी workspace.rootPath संपत्ति सेट किया जा सकता है (यदि कोई फ़ोल्डर खोला जाता है), या नहीं (जब कोई फ़ोल्डर नहीं खोला गया है) पर भरोसा कर सकता है। चूँकि additionalFolders वास्तव में एक सेटिंग है, एक एक्सटेंशन पढ़ने के लिए स्वतंत्र है और यहां तक ​​कि एपीआई के साथ इस सेटिंग को लिखने के लिए हमारे पास आज पहले से ही सेटिंग्स हैं। जब यह सेटिंग बदलती है तब भी कोई ईवेंट उत्सर्जित होता है, जिससे उपयोगकर्ता इस सेटिंग को बदलने के लिए गतिशील प्रतिक्रिया देता है।

इस सेटिंग को पढ़ने से कार्यक्षेत्र में अतिरिक्त फ़ोल्डरों के बारे में विस्तार करने की अनुमति मिलती है। उदाहरण के लिए ट्रैविस CI एक्सटेंशन सभी फ़ोल्डरों में एक एकत्रित स्थिति दिखाने के लिए चुना जा सकता है।

इस सेटिंग को लिखना एक्सटेंशन के लिए कुछ दिलचस्प परिदृश्यों को सक्षम करता है: जैसे आपके पास प्रोजेक्ट-मैनेजर एक्सटेंशन हो सकता है जो आपके कार्यक्षेत्र में गतिशील रूप से फ़ोल्डर जोड़ता है और हटाता है और जैसे विंडो के भीतर प्रोजेक्ट ट्रांज़िशन के लिए अनुमति देता है, जैसे कि पिकर यूआई के माध्यम से परियोजनाओं की सूची दिखा कर ।

एक बिंदु पर हम बहु-रूट फ़ोल्डर से निपटने के लिए कुछ वास्तविक नए एक्सटेंशन एपीआई पेश करेंगे। एक्सटेंशन को पढ़ने / लिखने के लिए सेटिंग के अंदर दफन करना थोड़ा अजीब है। लेकिन शुरू करने के लिए, एक्सटेंशन पहले से ही संभव हो तो इसका लाभ उठाने के लिए additionalFolders सेटिंग का पता लगा सकते हैं। हम विस्तार लेखकों के साथ मिलकर उनके परिदृश्यों को समझेंगे और उनका बेहतर समर्थन कैसे करेंगे।

@bpasero क्या एलएसपी में अतिरिक्त फ़ोल्डरों की अवधारणा को भी जोड़ा जाएगा, या वीएस कोड केवल अतिरिक्त फ़ोल्डर में एक भाषा सर्वर शुरू करेगा?

@felixfbecker यह एक ऐसी चीज है जिसे हमें अभी भी निवेश करना है और भाषा के विस्तार के लिए एक अच्छा समाधान ढूंढना है। एक बार जब हम एक्सटेंशन के लिए अतिरिक्त एपीआई के बारे में सोचते हैं, तो हमें यह भी सोचने की जरूरत है कि एलएसपी के लिए इसका क्या मतलब है।

यह ध्यान देने योग्य है कि आज आप पहले से ही ऐसी स्थितियां बना सकते हैं जहां उपयोगकर्ता एक फ़ोल्डर से एक फ़ाइल खोलते हैं जो कार्यक्षेत्र के रूप में नहीं खुलती है (जैसे फ़ाइल> ओपन> somefile.xyz)। आदर्श रूप से एक भाषा एक्सटेंशन ऐसी फ़ाइल के लिए समान स्तर की भाषा सुविधाएँ दिखा सकता है, भले ही उस फ़ाइल का फ़ोल्डर न खोला गया हो।

शुरुआत में, additionalFolders किसी एक फ़ाइल को खोलना एक ऐसी फ़ाइल को खोलने के समान होगा जो आपके द्वारा शुरू में खोले गए फ़ोल्डर में नहीं है। उदाहरण के लिए टाइपस्क्रिप्ट इस मामले से अच्छी तरह से निपट सकते हैं: वे अभी तक वर्तमान में खोली गई फ़ाइल से चलते हैं जब तक tsconfig.json फ़ाइल नहीं मिलती है और फिर इसे एक परियोजना के रूप में मानते हैं। संदर्भ के बिना काम खोजने जैसी विशेषताएं:

यह अच्छा होगा यदि कोई भी भाषा एक्सटेंशन केवल एक स्पष्ट परियोजना संदर्भ के लिए मजबूर करने के बजाय वर्तमान में सक्रिय फ़ाइल से जाकर काम कर सकता है।

@bpasero टिप्पणी के लिए धन्यवाद। तो ऐसा लगता है कि मौजूदा मॉडल में, हमेशा एक "मास्टर" फ़ोल्डर होगा : यहां तक ​​कि allMyRandomProjects उदाहरण में, यह मूल रूप से मास्टर फ़ोल्डर है, हालांकि ज्यादातर खाली है। इसके कुछ सूक्ष्म प्रभाव हैं, लेकिन मुझे उपयोगी प्रतिक्रिया प्रदान करने के लिए इसके बारे में कुछ और सोचने की आवश्यकता है।

कुल मिलाकर, मुझे लगता है कि उपरोक्त टिप्पणी के अनुसार, VSCode को काफी समान तरीके से monorepo बनाम एकाधिक रिपॉजिटरी का समर्थन करना चाहिए: https://github.com/Microsoft/vscode/issues/396#issuecomment -30x4048585।

BTW, आप "रूट" को कैसे परिभाषित करते हैं, बिल्कुल? यदि मैं एक फ़ोल्डर खोलता हूं जिसमें सबफ़ोल्डर B और C शामिल हैं, तो यह A को path और B और C के रूप में additionalFolders रूप में परिभाषित करने से कितना भिन्न है? क्या VSCode के लिए इरादा उन दो स्थितियों को काफी अलग या मूल रूप से एक समान मानने का है? (मुझे लगता है कि यह बहुत ही समान अनुभव होना चाहिए।)

@bpasero

शुरुआत में, किसी भी अतिरिक्त फ़ोल्डर में से एक फ़ाइल खोलने से उस फ़ाइल को खोलना बहुत समान होगा जो आपके द्वारा शुरू में खोले गए फ़ोल्डर में नहीं है। उदाहरण के लिए टाइपस्क्रिप्ट इस मामले से अच्छी तरह से निपट सकते हैं: वे बस वर्तमान में खोली गई फ़ाइल से तब तक चलते हैं जब तक कि tsconfig.json फ़ाइल नहीं मिल जाती है और फिर इसे प्रोजेक्ट के रूप में मानते हैं। संदर्भ के बिना काम खोजने जैसी विशेषताएं:

टाइपस्क्रिप्ट हालांकि एलएसपी का उपयोग नहीं करता है। LSP में, भाषा सर्वरों में rootUri , और उदाहरण के लिए PHP इस rootUri का उपयोग उन फ़ाइलों के लिए स्कैन करने के लिए करेगी, जिन्हें अनुक्रमित करने की आवश्यकता है। इसमें tsconfig.json जैसी फाइल नहीं है जो एक "प्रोजेक्ट" को दर्शाएगा। इसलिए अगर ऐसी फाइलें हैं जो didOpen माध्यम से नहीं खोली जाती हैं, लेकिन rootUri तहत भी नहीं हैं, तो इन पर कोड इंटेलिजेंस के लिए विचार नहीं किया जाएगा, इसलिए मेरा सवाल है कि क्या एलएसपी को इसके लिए बढ़ाया जाएगा।

बस स्पष्ट करने के लिए, क्या कई जड़ें खोलने से एक फ़ाइल ./.vscode/settings.json यदि यह पहले से मौजूद नहीं थी?
जैसा कि मैंने यहाँ पढ़ा है, ऐसा लगता है कि हम कह रहे हैं कि यह होगा।

मैं समझता हूं कि परियोजनाओं की अवधारणा को जोड़ने से बचने के लिए इसका उपयोगी क्यों है, लेकिन शायद कार्यक्षेत्र की बचत को वैकल्पिक बनाना अच्छा होगा - भले ही इस मामले में, 'बचत' का अर्थ है रूट फ़ोल्डर में सेटिंग्स फ़ाइल बनाना।

मुझे लगता है कि यह एक उपयोगकर्ता को आश्चर्यचकित कर सकता है जो इस धागे का पालन नहीं कर रहे हैं अगर उन्होंने एक दूसरा फ़ोल्डर खोला और उसने एक सेटिंग फ़ाइल बनाई। फ़ोल्डर खोलना इस तरह की बात है, मेरा मानना ​​है कि अधिकांश उपयोगकर्ता केवल-पढ़ने के लिए उम्मीद करते हैं।

सभी की प्रतिक्रिया के लिए धन्यवाद, यह बहुत उपयोगी है।

@ साबर्री - एक फ़ोल्डर को जोड़ने पर सेटिंग के निर्माण से लोग किस हद तक आश्चर्यचकित होंगे, इसके बारे में अच्छा सवाल। हमें यह जांचने की आवश्यकता होगी कि क्या यह देखने के लिए कि यह मामला है (जाहिर है उन लोगों के साथ जो इस धागे का पालन नहीं कर रहे हैं :-))।

@borekb - हमने आपके द्वारा बताए गए परिदृश्य के बारे में बात की है (एक फ़ोल्डर खोलना जिसमें एक या अधिक सबफ़ोल्डर शामिल हैं) और हम इसे मल्टी रूट वर्कस्पेस खोलने के समान

मुझे इसमें दिलचस्पी होगी कि दूसरे इस बारे में क्या सोचते हैं।

@borekb आप एक अच्छा बिंदु लाते हैं, मैं यह भी कहूंगा कि यदि आप एक ऐसा फ़ोल्डर खोलते हैं जिसमें कई गिट रिपॉजिटरी हैं, तो हमारा SCM दृश्य आपको वही दृश्य दिखाने में सक्षम होना चाहिए, जैसा कि आप इसे स्पष्ट रूप से सेट करने के बाद प्राप्त करेंगे। additionalFolders संपत्ति। मुझे लगता है कि हम इस UI के विकास को उन फ़ोल्डरों के साथ शुरू कर सकते हैं जिनके पास additionalFolders सेटिंग सेट है और बाद में इसे अधिक उपयोग के मामलों में विस्तारित किया गया है। एक और दिलचस्प और संबंधित परिदृश्य यह है कि हमने एक रिपॉजिटरी में सबमोडुल्स को कैसे चुना।

मैं यह भी सोचता हूं कि आखिरकार हम किसी भी फ़ोल्डर पदानुक्रम स्तर पर .vscode सेटिंग्स का समर्थन करना चाहते हैं क्योंकि हमने इसके साथ आने वाली चुनौतियों को हल कर लिया है।

मैं मल्टी-रूट के बारे में बात करते समय मास्टर-डिटेल्स रिलेशनशिप के बारे में कम बोलूंगा क्योंकि अधिकांश यूएक्स अतिरिक्त फोल्डर के बराबर मुख्य फ़ोल्डर का इलाज करेगा। मास्टर फ़ोल्डर वास्तव में अतिरिक्त फ़ोल्डरों के लिए सेटिंग्स का कंटेनर है और वैश्विक कार्यक्षेत्र सेटिंग्स के लिए मुख्य ड्राइवर होगा। पीछे की संगतता के लिए यह वह भी होगा जिसे हम rootPath रूप में एक्सटेंशन पर भेजते हैं।

@felixfbecker का मतलब यह है कि मैं अपने प्रोजेक्ट की सिर्फ एक PHP फाइल खोलते समय "फाइंड रिफरेंस" या इसी तरह की भाषा के फीचर्स नहीं कर सकता, मुझे इन फीचर्स को पाने के लिए उस फोल्डर को खोलने की जरूरत है? मैं PHP में गहरी नहीं हूं, लेकिन यदि क्रॉस-फ़ाइल निर्भरता की अवधारणा है, तो मैं केवल एक फ़ाइल से दूसरी PHP फ़ाइल पर नेविगेट नहीं कर पाऊंगा, मुझे पहले फ़ोल्डर खोलने की आवश्यकता है?

जब आप फ़ोल्डर जोड़ते हैं तो @saborrie हम डिफ़ॉल्ट रूप से कार्यक्षेत्र सेटिंग नहीं जोड़ेंगे। उपयोगकर्ता सेटिंग्स में इसे डालने का एक कारण यह है कि मल्टी-रूट सेटअप के साथ एक कार्यक्षेत्र "गंदा" नहीं हो रहा है। इस सेटिंग को कार्यक्षेत्र में लाना संभव है, लेकिन आपको मैन्युअल रूप से ऐसा करने की आवश्यकता होगी। यह डिफ़ॉल्ट रूप से नहीं होगा।

@bpasero ठीक है हाँ, कार्यक्षेत्र सेटिंग्स के बजाय उपयोगकर्ता सेटिंग्स में बचत के साथ चिपके रहने से कार्यक्षेत्र फ़ोल्डरों की गंदगी को रोका जा सकेगा - मैं अनुमान लगा रहा हूं कि उपयोगकर्ता को स्पष्ट रूप से बचाने के लिए हां कार्रवाई करने की आवश्यकता होने से पहले यह अभी भी बचाएगा?

यह मुझे दो अनुवर्ती प्रश्नों के साथ छोड़ देता है:

1) क्या होगा जब कोई उपयोगकर्ता अपने कार्यक्षेत्र-सेटिंग्स में additionalFolders साथ एक कार्यक्षेत्र खोलता है? क्या यह उनकी उपयोगकर्ता-सेटिंग में सिंक हो जाएगा? और यदि यह उपयोगकर्ता-सेटिंग कार्यस्थान सूची में मौजूद है तो क्या यह उस कार्यक्षेत्र-रूट के लिए प्रविष्टि को ओवरराइड करेगा? या ठीक इसके विपरीत?

2) क्या यह कार्यस्थानों की सूची को उपयोगकर्ता-सेटिंग्स में रखना बेहतर विकल्प है जो शुरू में इन दोनों में से किसी भी कार्यस्थान को स्टोर करने से बचता है? वर्तमान एकल-फ़ोल्डर प्रणाली में, जब एक फ़ोल्डर को File > Open Recent मेनू आइटम से फिर से खोला जाता है, तो जो टैब पहले खुले थे, उन्हें याद किया जाता है - जहां तक ​​मैं बता सकता हूं कि यह किसी भी उपयोगकर्ता में संग्रहीत नहीं किया जा रहा है -सक्रिय सेटिंग्स फ़ाइल, क्या अतिरिक्त पथ उसी तरह से संग्रहीत नहीं किए जा सकते हैं, जब तक कि उपयोगकर्ता उन्हें स्पष्ट रूप से नहीं बचाता है?

- अंग्रेजी के लिए क्षमा करें, मैंने Google अनुवादक का उपयोग किया है -

खैर, मैं लेआउट पर गया, (हाँ - अंग्रेजी समझने में थोड़ी कठिनाई)। माफ करो फिर...

मुझे @madduri द्वारा प्रस्तुत लेआउट पसंद नहीं आया, मुख्य रूप से इस मुद्दे (# 25352, # 25352) में पाई गई समस्याओं के कारण। मुझे लगता है कि यह और भी जटिल होगा, भले ही आपको प्रदर्शित मॉडल में फ़ोल्डर्स तक पहुंचने के लिए कीबोर्ड का उपयोग करना पड़े।

मैं इस मॉडल को पसंद करता हूं, जो इस विचार से कि मैं तीर कुंजी का उपयोग करके विभिन्न प्रोजेक्ट फ़ोल्डर्स के बीच नेविगेट कर सकता हूं और अगर मुझे मुख्य फ़ोल्डर में एक फ़ोल्डर / फ़ाइल बनाने की आवश्यकता है, तो मैं कीबोर्ड पर मेनू कुंजी का उपयोग कर सकता हूं, मुख्य में सही फ़ोल्डर।

और / या नई फ़ाइल के विकल्प के साथ, नया फ़ोल्डर अपडेट और सभी को संक्षिप्त करें।

शीर्ष पर दिखाई देने वाले शीर्षक के लिए, मैं पसंद करता हूं कि यह उस फ़ोल्डर के साथ वर्तमान फ़ाइल पर केंद्रित है या इस छवि के समान सभी खुले मुख्य फ़ोल्डर्स और वर्तमान फ़ाइल को दिखाने के बजाय।

और एक सवाल: क्या अभी भी एडिटर्स खुले रहेंगे?

@bpasero

क्या इसका मतलब यह है कि मैं अपने प्रोजेक्ट की सिर्फ एक PHP फाइल खोलते समय "फाइंड रिफरेंस" या इसी तरह की भाषा सुविधाएँ नहीं कर सकता, मुझे इन सुविधाओं को प्राप्त करने के लिए उस फ़ोल्डर को खोलने की आवश्यकता है? मैं PHP में गहरी नहीं हूं, लेकिन यदि क्रॉस-फ़ाइल निर्भरता की अवधारणा है, तो मैं केवल एक फ़ाइल से दूसरी PHP फ़ाइल पर नेविगेट नहीं कर पाऊंगा, मुझे पहले फ़ोल्डर खोलने की आवश्यकता है?

यह सही है, यदि आप किसी एकल फ़ाइल को खोलते हैं, तो आप किसी भिन्न फ़ाइल में फ़ाइल के लिए परिभाषा नहीं कर सकते हैं जो खुली नहीं है, लेकिन केवल rootUri नीचे के लोगों के लिए। ऐसा इसलिए है क्योंकि PHP में हर फ़ाइल वैश्विक नामस्थान में प्रतीकों को डंप कर सकती है, और नाम स्थान वास्तव में कक्षाओं के लिए केवल नाम उपसर्ग हैं। इस बात पर कोई प्रतिबंध नहीं है कि कैसे नेमस्पेस और क्लास के नाम को डायरेक्टरी और फाइल नेम (केवल कुछ कन्वेंशन) के अनुरूप करने की आवश्यकता है, और टीएस की तरह कोई इम्पोर्टेन्ट स्टेटमेंट नहीं हैं, केवल नेमस्पेस अलायसेस हैं। लोडिंग कक्षाएं पंजीकृत "ऑटोलॉजिस्ट" के माध्यम से रनटाइम पर होती हैं। गो-टू-डेफिनिशन पर भाषा सर्वर के लिए इसका मतलब है, किसी भी फाइल में एक प्रतीक को परिभाषित किया जा सकता है। तो भाषा सर्वर स्टार्टअप पर rootUri में सभी फ़ाइलों को अनुक्रमित करेगा और फिर अनुरोधों का जवाब देने के लिए सूचकांक के साथ काम करेगा। क्या काम करता है यदि आपके पास एक परियोजना खुली है, और आप एक नई बिना सहेजे फ़ाइल बनाते हैं - तो आपको इसके लिए खुफिया जानकारी मिलेगी, क्योंकि आपको rootUri और textDocument/didOpen माध्यम से नई फ़ाइल मिली rootUri तहत नहीं खुली फाइलों में परिभाषित किसी भी प्रतीकों पर विचार नहीं किया जाएगा।

@ कार्यक्षेत्र सेटिंग्स उपयोगकर्ता सेटिंग्स को ओवरराइड करती हैं, पहले की तरह। कार्यक्षेत्र के अंदर एक additionalFolders सेटिंग हमेशा पूर्वता लेता है। इस सेटिंग की प्रकृति को देखते हुए, आप केवल वर्तमान में खोले गए फ़ोल्डर के लिए अतिरिक्त फ़ोल्डर को ओवरराइड कर सकते हैं जब यह सेटिंग कार्यक्षेत्र के अंदर निर्दिष्ट होती है (यह "मास्टर" के लिए path: "." होने पर वीडियो में दिखाया गया है)।

यह यूआई स्थिति के समान होने के कारण कितने टैब खोले गए हैं यह एक विकल्प था, जिस पर हमने चर्चा की लेकिन हमें यह नहीं मिला कि इसकी सेटिंग के बहुत सारे फायदे हैं। कुछ कारणों से:

• यह साझा करने योग्य नहीं है (न तो कार्यक्षेत्र सेटिंग के माध्यम से, न ही सेटिंग्स सिंक एक्सटेंशन के माध्यम से)
• यह कुछ एक्सटेंशन आज तक आसानी से नहीं पहुंच सकता है (सेटिंग्स एपीआई मौजूद है, यूआई राज्य एपीआई नहीं है)

क्या कोई विशेष कारण है कि आप इसे अंदर की सेटिंग्स नहीं चाहेंगे?

@Tekbr हाँ, "ओपन एडिटर्स" पहले की तरह काम करेगा

@felixfbecker क्या PHP एक्सटेंशन rootUri: string[] आसानी से कुछ अपनाने में सक्षम होगा? या क्या आप चाहते हैं कि PHP भाषा सर्वर खुलने वाले प्रत्येक फ़ोल्डर के लिए कई बार शुरू हो (जैसे वीएस कोड एन-फोल्डर्स के लिए खोले गए फ़ोल्डर के स्तर पर मल्टी-प्लेक्स होगा?)

@bpasero PHP rootUris: string[] काफी आसानी से काम कर सकता है। अन्य भाषा सर्वर हालांकि नहीं हो सकते हैं। कई भाषा सर्वरों को अलग करने का मतलब होगा कि प्रत्येक फ़ोल्डर अलग-थलग काम करता है (कोई जंप-टू-डेफिनिशन, उनके बीच में सभी संदर्भों को ढूंढें)। शायद एक दृष्टिकोण एक नया ServerCapability जो यह तय करता है कि क्या वीएस कोड एक या कई भाषा सर्वरों को स्पॉन करेगा।

मुझे अतिरिक्त फ़ोल्डर सेटिंग की अवधारणा पसंद है। मेरे लिए एक रूट फ़ोल्डर होना पर्याप्त है। यदि मैं एक संबद्ध परियोजना पर पूर्ण विकास की कार्यक्षमता चाहता हूं तो मैं एक नई vscode विंडो खोल सकता हूं।

अतिरिक्त फ़ोल्डर्स से मुझे जो चाहिए वह सिर्फ सीमित कार्यक्षमता है। उदाहरण के लिए, मैं रूट प्रोजेक्ट में उपयोग के लिए एक संबद्ध परियोजना से एक प्रतीक परिभाषा चाहता हूं, लेकिन आवश्यकता नहीं है या इसे नाम बदलने या अतिरिक्त फ़ोल्डर में इसके लिए सभी संदर्भ खोजने की क्षमता चाहिए।

@bpasero मैं सिर्फ सेटिंग्स (और ऑप्ट-इन) वैकल्पिक में एक कार्यक्षेत्र के निर्माण पर विचार करने के लिए वकालत कर रहा हूं। उपयोगकर्ता द्वारा किसी फ़ोल्डर को जोड़ने पर स्वचालित रूप से सेटिंग्स बदलने के बजाय अनिवार्य रूप से, इसके साथ ही यूआई स्थिति में शुरू होता है, और फिर उपयोगकर्ताओं को किसी तरह से सेटिंग में इसे सहेजने की अनुमति देता है। शायद यह भी विकल्प की अनुमति देता है कि यह कार्यक्षेत्र सेटिंग्स में जाता है या उपयोगकर्ता सेटिंग्स में।

मैं पूरी तरह से सेटिंग्स में संग्रहीत करने के खिलाफ नहीं हूं, मैं यूआई स्टेट का उपयोग न करने के निर्णय पर सवाल करने के लिए बस थोड़ा सा कर रहा हूं, बस उस स्थिति में जब इसे अनदेखा किया गया था।

@bpasero @saborrie यदि हम उस मार्ग पर जाते हैं, तो मैं यह जोड़ना चाहूंगा कि जब सेटिंग्स को सहेजने के लिए कहा जाए, तो "मेरी पसंद को याद रखने" (सेटिंग्स को कार्यक्षेत्रों को बचाने के लिए, या तो उपयोगकर्ता सेटिंग्स या प्रोजेक्ट सेटिंग्स) का विकल्प होना चाहिए। मुझे VSCode विंडो खोलने में थोड़ी निराशा होगी, कुछ फ़ोल्डर्स लोड करने होंगे, यह सब काम करने के तरीके से मिलेगा जो मैं चाहता हूं और फिर रिबूट या क्रैश होता है और मैंने फ़ोल्डर्स के उस संयोजन के लिए अपना पूरा कॉन्फ़िगरेशन खो दिया है क्योंकि कार्यक्षेत्र कभी भी सहेजा नहीं गया था डिस्क के लिए।

# 396 (टिप्पणी)

@Tekbr हाँ, "ओपन एडिटर्स" पहले की तरह काम करेगा

उत्तर के लिए धन्यवाद, @bpasero।

टीएल; डीआर: एक पेड़ के दृश्य का उपयोग करें जब भी यह समझ में आता है कि जड़ों के नाम को प्रत्येक आइटम पर लागू करने के विपरीत है।

कुछ चीजें, मैं वास्तव में जिस तरह से आप फ़ोल्डर को अंत तक नापसंद करते हैं, मैं वास्तव में इसे एक विकल्प के रूप में पसंद करूंगा क्योंकि मैं इसे express\.editorconfig और express-plugin\.editorconfig पसंद करना चाहूंगा। शायद आप निम्न विकल्प दे सकते हैं: editor.tabName: "${root}\${filename}"

एक और बात जो मुझे पसंद है और आप इसका उल्लेख करते हैं कि वीडियो में इस पर टैब के साथ मिलान करने के लिए जड़ों पर रंगाई है।

खोज:

Search दृश्य में मैं वास्तव में सोचूंगा कि आप एक गलती कर रहे हैं जहां तक ​​अनुभव होता है, मेरे दिमाग में इसे इस तरह से एक पेड़ के रूप में प्रदर्शित किया जाना चाहिए:

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

इसके कारण हैं:

1. आप आसानी से देख सकते हैं कि उनके नाम की लंबाई की परवाह किए बिना फाइलें कहां हैं।

2. आप उन जड़ों को ढहा सकते हैं जिन्हें आप देखना नहीं चाहते हैं।

मुझे लगता है कि यह Explorer लिए लागू डिज़ाइन के प्रकार पर भी अधिक फिट बैठता है।

कार्य:

Tasks मैं इस तरह का दृश्य रखना पसंद करूंगा:

express
    Compile
    Run Tests
express-plugin
    Compile
    Run Tests

कुछ बिंदु:

1. मेरी राय में आपको फ़ोल्डर के नामों को स्पर्श / परिवर्तित नहीं करना चाहिए, जिसका अर्थ "एक्सप्रेस-प्लगइन" है, जैसा कि Explorer में प्रदर्शित किया गया है और "एक्सप्रेस प्लगइन" के रूप में प्रदर्शित नहीं किया जाना चाहिए।

2. कीबोर्ड के साथ कार्यों के बीच चलना इस तरह से भी बनाया जा सकता है कि यह जड़ों के चयन को नजरअंदाज कर देता है, इसलिए यदि आप express\"Run Tests" से नीचे जाते हैं, उदाहरण में अगला आइटम जो चयनित होगा वह express-plugin\Compile है। express-plugin विरोध किया

ps अभी तक पूरे वीडियो को नहीं देखा है, लेकिन इन बातों को ध्यान में आया।

क्या होगा यदि आपके कार्यक्षेत्र में शामिल सभी रूट फ़ोल्डर्स का एक ही नाम हो?
जैसे

• / Dev / परियोजना / सार्वजनिक / src
• / Dev / रूपरेखा / src
• / Dev / कुछ घटक / src

फिर आपके पास एक कार्यक्षेत्र होगा:

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

वर्कस्पेस में फ़ोल्डर्स को शामिल करने के तरीके के अनुसार _sublime_ का तरीका, प्रत्येक वर्चुअल फ़ोल्डर रूट में है:

• पथ
• नाम (वैकल्पिक) - यह फ़ोल्डर का नाम है यदि बाहर रखा गया है, लेकिन कुछ भी प्रदर्शित किया जा सकता है
• फ़ाइलें / फ़ोल्डर के लिए बहिष्करण फ़िल्टर

ध्यान दें कि https://github.com/Microsoft/vscode/issues/396#issuecomment -283541760 (ऊपर) मेटाडेटा के उदाहरण के लिए चीजों को करने के इस तरीके से जुड़ा हुआ है।

मैं जानना चाहूंगा कि यह सुविधा अभी भी विकास के चरण में है?

@ifzm यह है और यदि आप नवीनतम (मई 2017 (संस्करण 1.13)) रिलीज़ नोट पढ़ते हैं, तो आपको पता होगा कि वे इस पर सक्रिय रूप से काम कर रहे हैं।

@eyalsk क्षमा करें, मैंने ध्यान से नहीं देखा, यह एक रोमांचक विशेषता है: डी

मैं additionalFolders अवधारणा के बारे में पागल नहीं हूं, हालांकि मैं चीजों को सरल रखने की इच्छा को समझता हूं।

यह मुझे अजीब लगता है कि एक फ़ोल्डर का एक सेट "कार्यक्षेत्र" के कॉन्फ़िगरेशन को संग्रहीत करेगा।

निम्नलिखित रूट फ़ोल्डरों की कल्पना करें:

• वेबसाइट
• एपीआई
• मोबाइल

... किस फ़ोल्डर में additionalFolders सेटिंग होनी चाहिए? क्यों?

मैं एक कार्यक्षेत्र / परियोजना प्रबंधक के विचार को पसंद करता हूं, जहां सेटिंग्स को साझा / सामान्य स्थान पर संग्रहीत किया जाता है। मैं वास्तव में यह नहीं सोचता कि यह एक UX परिप्रेक्ष्य से जटिल है, और मौजूदा workspace शब्दावली का पुन: उपयोग / विस्तार किया जा सकता है।

असंबंधित: मैं नेस्टेड सूचियों (और टैब नामकरण) के संबंध में @eyalsk की टिप्पणियों से पूरी तरह सहमत हूं।

@ ग्लेन -84 उस मामले में आप "माय-मोबाइल-वेबसाइट-प्रोजेक्ट" नामक डिस्क पर एक चौथा फ़ोल्डर रखने के लिए स्वतंत्र हैं, जिसमें यह सेटिंग है और अन्य सभी फ़ोल्डरों के लिए लिंक है।

@bpasero मैं समझता हूँ कि, लेकिन यह वास्तव में सिर्फ एक हैक है।

समझाने के लिए:

मैं website पर काम करने में व्यस्त हूं, और यह निर्णय लेता हूं कि मैं api कुछ बदलाव करना चाहता हूं। अगर मैं क्लिक Add Folder , यह संबद्ध करने के लिए जा रहा है api के साथ website , ऐसी है कि खोलने website भविष्य में खुलती api भी। मुझे यह समझने की आवश्यकता है कि यह कैसे काम करता है, और जब मैं करता हूं, तो मुझे वीएससी का एक अलग उदाहरण खोलना होगा, एक उचित रूप से नामित खाली फ़ोल्डर बनाना होगा, इसमें दोनों "प्रोजेक्ट" फ़ोल्डर जोड़ें, और फिर प्रारंभिक आवृत्ति को बंद कर दें।

इसके विपरीत, मैं बस 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
            }
        }
    }
}

मुझे बस अधिक लचीला और कम अजीब लगता है।

@ ग्लेन -84 समझ गया। आपके प्रस्तावित समाधान के साथ जाने से वीएस कोड का उपयोग अधिक जटिल हो जाता है, यही कारण है कि हमने इस तरह की अवधारणा के खिलाफ चुना। मुख्य कारण यह है कि अचानक "ओपन फाइल" और "ओपन फोल्डर" ही नहीं, बल्कि "ओपन प्रोजेक्ट" भी है। नई अवधारणाओं को पेश किए बिना हमारे पास प्राथमिकताओं के साथ रहना अधिक सरल दृष्टिकोण है।

यह कहा, अब हम कई फ़ोल्डर्स का समर्थन करने के लिए सभी काम करते हैं, जो आपके प्रस्ताव के रूप में परिदृश्यों के लिए भी अच्छा काम है। यदि हम कभी भी आपके परिदृश्य का समर्थन करना चाहते हैं, तो वहां पहुंचने के चरण बहुत कम हैं क्योंकि UI इसके लिए पहले से ही फिट है। मैं यह भी कल्पना कर सकता हूं कि शायद एक एक्सटेंशन कार्यक्षेत्रों की ऐसी धारणा को पेश कर सकता है और हम इसे समर्थन देने के लिए आवश्यक एपीआई जोड़ते हैं।

आइए पहले हम नई अवधारणाओं को पेश किए बिना UX को सही करें और फिर मल्टी-फ़ोल्डर्स के आसपास अन्य परिदृश्यों के बारे में सोचें। पहले देखने के लिए बहुत सी चीजें हैं (एक्सटेंशन, सेटिंग्स, एससीएम यूआई, आदि)।

आपका प्रस्तावित समाधान VS कोड का उपयोग करके अधिक जटिल हो गया है

मुझे इससे सहमत नहीं होना है। यदि कोई उपयोगकर्ता वैकल्पिक "ओपन प्रोजेक्ट" (या कार्यक्षेत्र) सुविधा से भ्रमित है, तो वे VSCode में कई मौजूदा सुविधाओं द्वारा भ्रमित होने की संभावना है। यह उपयोगकर्ता के दृष्टिकोण से जटिल नहीं है (यदि कोई भी इस असहमत को पढ़ता है, तो कृपया ऐसा कहें)।

मैं यह भी कल्पना कर सकता हूं कि शायद एक एक्सटेंशन कार्यक्षेत्रों की ऐसी धारणा को पेश कर सकता है और हम इसे समर्थन देने के लिए आवश्यक एपीआई जोड़ते हैं।

विस्तार पहले से मौजूद है, और कुछ समय पहले ही इसका उल्लेख किया गया है। लेखक के पास एक ओपन टिकट ट्रैकिंग मल्टी-फोल्डर समर्थन भी है। इस एक्सटेंशन में 370k + इंस्टॉल है, और 4.7 की रेटिंग है। कमांड पैलेट का उपयोग करने वाले एक साधारण यूआई के साथ भी, टिप्पणियों द्वारा भ्रम की स्थिति का थोड़ा संकेत है।

आइए हम पहले नई अवधारणाओं को पेश किए बिना UX को सही करें और फिर मल्टी-फ़ोल्डर्स के आसपास अन्य परिदृश्यों के बारे में सोचें

यह काफी उचित है। किसी भी तरह से, यह एक ही विंडो के भीतर कई रूट फ़ोल्डरों का समर्थन करने के बारे में है - इन फ़ोल्डर समूहों के प्रबंधन की वास्तविक विधि से बाद के चरण में सामना किया जा सकता है।

क्या आप इस विषय पर उपयोगकर्ता की राय एकत्र करने के लिए एक सार्वजनिक सर्वेक्षण बनाने पर विचार करेंगे (मुझे YouTube वीडियो के बारे में पता है, लेकिन मैं इस पहलू का स्वयं उल्लेख कर रहा हूं), या additionalFolders साथ जाने का निर्णय पहले ही कर लिया गया है

मैं @ ग्लेन -84 से सहमत हूं। मैं जटिलता के मुद्दे को नहीं समझता। हां, यह इसे और अधिक जटिल बना सकता है, लेकिन यह एक कोड संपादक है। मुझे लगता है कि यह 95% प्रोग्रामर हैं जो इसका उपयोग कर रहे हैं, जो आसानी से परियोजनाओं के विचार को समझ सकते हैं। हर दिन लोगों को भ्रमित करने के बारे में थोड़ी चिंता होनी चाहिए क्योंकि हर दिन लोग इसका उपयोग नहीं कर रहे हैं।

जबकि एक एक्सटेंशन कुछ हद तक एक समाधान है, मूल रूप से लागू संवर्द्धन होने की तुलना में एक्सटेंशन दूसरी दर भी हैं (यानी मेनू में विकल्प नहीं जोड़ सकते हैं, केवल कमांड पैलेट, आदि)।

@ glen-84 का निर्णय विकास टीम में उपयोक्ता के आधार पर additionalFolders सेटिंग के साथ किया गया है, उपयोगकर्ता अध्ययन जो हमने किया (उन 2 वीडियो) और इस मुद्दे में हमें मिली प्रतिक्रिया।

@pltrant यह बहु रूट का उपयोग करके अधिक जटिल बनाता है क्योंकि आपको लगातार एक फ़ोल्डर खोलने या एक परियोजना खोलने के बारे में सोचना पड़ता है। "हाल ही में खोलें" जैसी चीजों पर अचानक अधिक ध्यान देने की आवश्यकता होती है यदि प्रविष्टि उठाया गया एक फ़ोल्डर या एक परियोजना है, या इससे भी बदतर आप 2 बीनने वाले भी होंगे और यह तय करना होगा कि किसका उपयोग करना है।

मुझे यकीन नहीं है कि कैसे एक सेटिंग अधिक जटिल है। आपको मूल रूप से सेटिंग के बारे में परवाह करने की ज़रूरत नहीं है, आप बस अपने सेटअप में फ़ोल्डर्स जोड़ते हैं और हटाते हैं और सेटिंग को पृष्ठभूमि में अपडेट किया जा रहा है। मेरा तर्क है कि आप ज्यादातर मामलों में उस सेटिंग के मूल्य को कभी नहीं देखते हैं।

@ glen-84 एक ही महत्व के 3 फ़ोल्डरों के साथ एक परियोजना के अपने उदाहरण के बारे में, मुझे लगता है कि जो additionalFolders होना चाहिए एपीआई फ़ोल्डर दूसरे प्रोजेक्ट पर निर्भर नहीं है, जब इसे खोला जाता है, तो इसे एकल फ़ोल्डर के रूप में खोला जाना चाहिए और इसमें कोई भी अतिरिक्त फ़ोल्डर सेटिंग्स नहीं होनी चाहिए। लेकिन जब आप मोबाइल फ़ोल्डर खोलते हैं, तो मुझे लगता है कि इसमें एपीआई फ़ोल्डर पर निर्भरता है। इसलिए, आप vscode में एक अतिरिक्त फ़ोल्डर के रूप में एपीआई खोलने के लिए मोबाइल फ़ोल्डर में सेटिंग्स जोड़ते हैं। उसी वेबसाइट के लिए चला जाता है। यदि यह एपीआई पर निर्भर है, तो वहां सेटिंग्स जोड़ें। यदि नहीं, कोई सेटिंग्स की जरूरत है।

मुझे नहीं लगता कि अतिरिक्त फ़ोल्डर खोलने के लिए पुनरावर्ती या कैस्केडिंग होगा। मुझे एक्सटेंशन के विचार भी पसंद हैं अन्य प्रोजेक्ट फॉर्मेट जैसे विजुअल स्टूडियो सॉल्यूशंस पढ़ें और अतिरिक्त फ़ोल्डर सेटिंग्स को जगह में रखने / सुझाव दें। और आप हमेशा सभी के सामान्य मूल फ़ोल्डर खोल सकते हैं।

@stevencl ने दोनों वीडियो देखे।

1. विस्मयादिबोधक के साथ वैकल्पिक 2 सबसे स्पष्ट लगता है। ऐसा लगता है कि यह बंधनेवाला हो सकता है (यानी पेड़ की जड़ों में से एक) जो कई परियोजनाओं को एक बार में देखने की अनुमति देगा। अगर आपको मॉकअप चाहिए, तो मुझे बताएं।

2. वैकल्पिक 2 एक स्क्रीन रियल एस्टेट परिप्रेक्ष्य से अधिक कुशल है। आपके पास एक ही जानकारी (परियोजना का नाम) शीर्ष पर दोहराई जाएगी - जैसा कि विकल्प 1 में है और फिर प्रत्येक परियोजना की जड़ में दिखाया गया है।

3. खोज परिणाम और Git उसी तरह का व्यवहार कर सकते हैं ... जैसे कि एक बंधनेवाला पेड़। परिणाम उनके उपयुक्त शीर्षक के तहत समूहीकृत (w / स्थिति के साथ) किया जाएगा। मुझे लगता है कि यदि आप एक नौगम्य सारांश चाहते हैं (जैसा कि आपने जीआईटी के लिए दिखाया है, तो यह एक विकल्प होगा जो खोज में मौजूद हो सकता है (आपको कितनी फाइलें मिली हैं) और परियोजना क्षेत्र (यह कार्रवाई बटन को घर कर सकता है)।

इसलिए सारांश में, मैं अलग-अलग बंधनेवाला जड़ों w / नौगम्य सारांश के संभावित जोड़ का प्रशंसक हूं। वैकल्पिक 2 और इस उदाहरण के संयोजन को क्रमबद्ध करें

मुझे आशा है कि आप लोग जो कुछ भी चुनते हैं, कि आप अनुभव को विभिन्न तंत्रों के समान बनाते हैं। आप कहते हैं कि दो विकल्प थे, लेकिन वास्तव में 4 हैं क्योंकि जीआईटी और खोज दोनों अलग-अलग थे। मैं इस बात से सहमत हूँ कि जिसने भी यह टिप्पणी की है

बहु-परियोजना की जानकारी साझा करना। मुझे लगता है कि यह उपयोगी होगा - आपके पास यह कैसे एक शुरुआत के रूप में उचित होगा - मैं इसे सिर्फ gulp कार्यों का उपयोग करूँगा - या ऐसे कार्य जो VS कोड समझ सकते हैं।

इस पर आपके सभी प्रयास के लिए धन्यवाद।

बहु-रूट कार्यक्षेत्र के कार्यान्वयन को # 28344 पर और इस जून मील के पत्थर में ट्रैक किया जा रहा है।

@ गुलशन ,

ऐसे मामले हो सकते हैं जहां कोई निर्भरता नहीं है। उदाहरण के लिए यदि मैं website पर काम कर रहा हूं और उसी समय काम करने के लिए mobile जोड़ने का निर्णय लेता हूं। दोनों के बीच कोई निर्भरता नहीं है, लेकिन अब website "माता-पिता" बन गए हैं। अगर मैं mobile पहले काम कर रहा था, तो यह माता-पिता बन जाएगा। यह बस थोड़ी मनमानी है। फ़ोल्डर्स पूरी तरह से असंबंधित परियोजनाओं के लिए भी हो सकते हैं।

बावजूद, मैं VSC डेवलपर्स द्वारा निर्णय का सम्मान करता हूं, भले ही मैं जरूरी इसके साथ सहमत नहीं हूं।

सभी निरंतर टिप्पणियों के लिए धन्यवाद। जैसा कि ऊपर उल्लेख किया गया है, हम # 28344 अंक में काम को ट्रैक कर रहे हैं। हम इन टिप्पणियों को ध्यान में रखेंगे, जबकि हम इस पर काम करना जारी रखेंगे, खासकर एससीएम अनुभव को डिजाइन करते समय। जैसा कि वीडियो में चर्चा की गई थी और जैसा कि कई बार ऊपर उल्लेख किया गया है, हम पूरे अनुभव में निरंतरता हासिल करना चाहते हैं।

जटिलता के मुद्दे के बारे में कि @ glen-84, @pltrant और अन्य लोग लाए हैं, विस्तृत सुझाव और प्रतिक्रियाओं के लिए धन्यवाद। हम फीडबैक को समझते हैं और इस पर निगरानी रखना जारी रखेंगे क्योंकि हम फीचर पर काम करते हैं।

इसके आस-पास की चर्चा वास्तव में सहायक रही है और इसने हमें अपने वर्तमान डिजाइन के बारे में सोचने के लिए कुछ चीजें दी हैं। उदाहरण के लिए, शायद हमें उपयोगकर्ताओं को कार्यक्षेत्र में दूसरा फ़ोल्डर जोड़ने पर 'प्राथमिक' फ़ोल्डर चुनने की अनुमति देने पर विचार करना चाहिए। कार्यक्षेत्र बंद होने पर शायद हम इसके लिए संकेत देते हैं, शायद यह एक सेटिंग है। अनुभव को सुव्यवस्थित करने के लिए हमारे बारे में बहुत सारी बातें।

हालांकि @bpasero का उल्लेख है, हम हमेशा वीएस कोड में नई अवधारणाओं (जैसे परियोजनाओं) को जोड़ने के लिए बहुत अनिच्छुक हैं। ऐसा इसलिए नहीं है क्योंकि हमें लगता है कि यह वीएस कोड को बेकार कर देगा, यह अधिक है कि अतिरिक्त अवधारणाएं वीएस कोड के वजन या चोरी को जोड़ती हैं, जिससे यह अधिक जटिल लगता है। इस तरह की अवधारणाएं कुछ और होंगी जो डेवलपर्स को मानसिक संसाधनों को समर्पित करना होगा।

इसके अलावा, एक बार जब कुछ वीएस कोड में होता है, तो इसे बाहर निकालना बहुत मुश्किल होता है (समय के साथ लोगों को इसकी आदत हो जाती है और यह निर्भर करता है)। इसलिए हम बहुत समय ध्यान से विचार करते हैं कि हम वीएस कोड में क्या जोड़ते हैं और केवल कुछ जोड़ते हैं जब हम आश्वस्त होते हैं कि नई अवधारणाओं को जोड़ने की लागत सार्थक होगी। तो अभी हम यह निर्धारित करना चाहते हैं कि नई अवधारणाओं को जोड़ने वाली बहु जड़ के लिए एक डिज़ाइन कितना सफल नहीं हो सकता है।

एक बार फिर, अविश्वसनीय रूप से मूल्यवान प्रतिक्रिया के लिए धन्यवाद। इस तरह एक संवाद के बिना यह अनुभव को डिजाइन करने की कोशिश में बहुत कठिन होगा।

टीम पर आप सभी कितने विचारशील और उत्तरदायी हैं; यह वाकई काबिले तारीफ है!

जटिलता के संबंध में अभी तक जो कुछ भी नहीं कहा गया है वह यह है कि आप कुछ भी जोड़ रहे हैं। मुझे लगता है कि वर्तमान में इन दो विकल्पों पर चर्चा की गई है:

1. स्पष्ट परियोजनाओं।
2. ऐसा कुछ जो सादे एकाधिक फ़ोल्डरों की तरह दिखता है, लेकिन वास्तव में ऐसा नहीं है - एक प्राथमिक फ़ोल्डर की एक महत्वपूर्ण अवधारणा है जो एक्सटेंशन के लिए rootUrl और संभवतः अन्य चीजों (उदाहरण के लिए कार्यक्षेत्र सेटिंग्स विरासत) जैसी चीजों की चिंता करता है। मुझे लगता है कि आमतौर पर, VSCode उपयोगकर्ता को इस अवधारणा को समझने की आवश्यकता होगी और हो सकता है कि इसे दूर करने की कोशिश करने के बजाय इसके बारे में स्पष्ट और अग्रिम होना आसान हो।

मैं वास्तव में तीसरा तरीका पसंद करूंगा, वास्तव में कुछ भी नया नहीं शुरू करना, बस कई .git repos जैसी चीजों को संभालना और खोज और कार्यों और चीजों को इस तरह से पारदर्शी तरीके से करना - पहले दो तिहाई वीडियो की तरह सुझाव दिया (मुझे वायरफ्रेम बहुत पसंद आया)। हालांकि, तब मुझे लगा कि rootUrl को एक्सटेंशन के लिए विचार करने की आवश्यकता है जो शायद मुख्य कारण है क्योंकि यह जटिल है।

यदि यह rootUrl लिए नहीं थे, तो मैं अभी UI अपडेट के साथ शुरू करूंगा जैसा कि वायरफ्रेम में प्रस्तावित है और मल्टी-रूट वर्कस्पेस की स्थानीय दृढ़ता है, उसी तरह जैसे अन्य सभी फ़ोल्डर्स "ओपन हाल" में बने रहते हैं।

मैं अपने दृष्टिकोण से यह दोहराना चाहता हूं कि आदर्श राज्य वह है जहां VSCode कई फ़ोल्डरों के साथ काम करता है, भले ही वे SCM रूट्स हों या नहीं (monorepo बनाम मल्टीपल रिपोज, ऊपर देखें)। मेरा मानना ​​है कि प्रस्तावित वायरफ्रेम प्लस कुछ अतिरिक्त कोर काम जैसे .vscode सेटिंग्स को बहु-मूल समर्थन के "v1" के लिए पर्याप्त होगा। "प्रोजेक्ट्स" या "प्राथमिक + अतिरिक्त फ़ोल्डर" बाद में आ सकते हैं, आईएमओ। हालांकि, जो मैं कह रहा हूं वह rootUrl साथ गिर सकता है, मुझे इस बारे में निश्चित नहीं है, मैं सिर्फ इस बारे में अपनी सामान्य भावना व्यक्त करना चाहता हूं।

यह बहुत अच्छा है कि आप इस कठिन समस्या को हल करने की कोशिश कर रहे हैं और यथासंभव सरलता बनाए रखें!

मेरे पास बैकएंड और फ्रंटएंड नोड प्रोजेक्ट है, और इसमें 2 विजुअलकोड संपादक खुले हैं, जो एक महत्वपूर्ण संसाधन तनाव है।

मैंने दोनों वीडियो देखे और एक टिप्पणी के साथ सहमति व्यक्त की कि इन कई परियोजनाओं के लिए कुछ भी करने की आवश्यकता नहीं है। शायद एक नोडज प्रोजेक्ट हो सकता है जबकि दूसरा सी ++ है।

अतिरिक्त परियोजनाओं को जोड़ने के साथ मुझे "मास्टर" प्रोजेक्ट में से एक प्रोजेक्ट का विचार पसंद नहीं आया। प्रत्येक परियोजना समान और असंबंधित होनी चाहिए।

मुझे एक फ़ोल्डर खोलने में सक्षम होने की उम्मीद होगी, और फिर एक और फ़ोल्डर (एडीडी नहीं) खोलें। फ़ोल्डर को केवल वीडियो 1 के रूप में जोड़ा जाएगा, जड़ों को दिखाने के साथ (लेकिन रूट फ़ोल्डर को मँडराते समय टूलटिप में पूर्ण पथ दिखाएं)। ये परियोजनाएं पूरी तरह से असंबंधित होंगी। एक या दूसरे को चुनने से एक संदर्भ स्विच होगा। यह ऐसा होगा जैसे मैं दृश्य कोड के 2 उदाहरणों के बीच स्विच कर रहा था, दोनों सेटिंग्स, रंग योजनाएं, और क्या नहीं।

इन कई परियोजनाओं को जारी रखने का तरीका यह होगा कि इसे एक नई परियोजना फ़ाइल के रूप में सहेजा जाए, जो अन्य दो परियोजनाओं को संदर्भित करता है, लेकिन 2 परियोजनाओं में से किसी को भी संशोधित किए बिना। दूसरे शब्दों में, 2 परियोजनाएं स्वतंत्र, आत्मनिर्भर और तीसरी परियोजना (सेटिंग फ़ाइल) से अनजान हैं जो उनका संदर्भ देती हैं।

एक बार यह 3 डी फ़ाइल सहेजे / बनाए जाने के बाद, ऐसी सेटिंग्स बनाना संभव हो सकता है जो प्रोजेक्ट ए और बी सेटिंग्स से सेटिंग को ओवरराइड करती हैं जो फिर से नहीं बनाई गई हैं फिर से सक्रिय प्रोजेक्ट पर निर्भर करेंगी।

प्रोजेक्ट को साझा करते समय, कोई प्रोजेक्ट फ़ाइल साझा कर सकता है जो अन्य दो का संदर्भ देता है। जब वे फ़ाइल सिस्टम से गायब होते हैं, लेकिन उनके गिथब उरल्स का संदर्भ होता है, तो यह उपयोगकर्ता से पूछना चाहिए कि क्या वह उन्हें लाना चाहता है (डिफ़ॉल्ट रूप से उस मास्टर प्रोजेक्ट फ़ाइल की जड़ में सबफ़ोल्डर के रूप में, लेकिन उपयोगकर्ता वांछित के लिए ब्राउज़ कर सकता है प्रत्येक के लिए स्थान)।

कई परियोजनाओं में खोज करने की क्षमता वैकल्पिक होनी चाहिए, और कई परियोजनाओं को एक साथ चलाने और डिबग करने की क्षमता बहुत उपयोगी होगी, लेकिन लगता है कि वास्तव में पहली रिलीज के लिए बहुत जटिल है, और शायद इस तरह के usecase को वैसे भी 2 उदाहरण चलाने की आवश्यकता होनी चाहिए। कम से कम अभी के लिए।

यह यूआई में कैसे दिखना चाहिए, यह चरण दो है, लेकिन कार्यात्मक रूप से यह है कि मैं इसे कैसे काम करने की उम्मीद करूंगा। मुझे B या इसके विपरीत प्रोजेक्ट A को संशोधित करने का विचार पसंद नहीं है, और जैसा मैंने समझा था, उस तरह का है। फुर्तीली विकास के लिए, मुझे खुशी होगी अगर मैं 1 विंडो में 2 परियोजनाओं पर काम कर सकता हूं, तो 2 इंस्टेंसेस चलाने के लिए नहीं, लेकिन अब के लिए इससे अधिक नहीं। शायद 3rd ओवरराइडिंग प्रोजेक्ट फ़ाइल के साथ भी नहीं, लेकिन केवल संदर्भ स्विचिंग के साथ।

निरंतर प्रतिक्रिया के लिए धन्यवाद। उपयोगकर्ता से कुछ स्पष्ट कार्रवाई (जैसे कि बचाओ) होने तक एक बहु फ़ोल्डर कार्यक्षेत्र की दृढ़ता में देरी के बारे में एक निश्चित विषय है। हमें इस बारे में अधिक सोचने और आगे की जांच करने की आवश्यकता होगी।

मैं यह भी सुझाव दूंगा कि डेवलपर्स ग्रहण आईडीई पर एक नज़र डालें कि यह कैसा है
इस कार्यक्षमता को संभालता है, वे इसे बहुत पहले समझ गए और यह काम करता है
महान।

Tue, Jun 13, 2017 को सुबह 9:11 बजे, स्टीवन क्लार्क नोटिफिकेशन @github.com
लिखा था:

निरंतर प्रतिक्रिया के लिए धन्यवाद। के बारे में एक निश्चित विषय है
कुछ स्पष्ट होने तक एक बहु फ़ोल्डर कार्यक्षेत्र की दृढ़ता में देरी
उपयोगकर्ता से कार्रवाई (जैसे सहेजें)। हमें इस बारे में अधिक सोचने की आवश्यकता होगी
और आगे की जांच करें।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें, इसे 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 / सेटिंग
प्रोजेक्ट विशिष्ट लाइनिंग को संबंधित निर्देशिकाओं में फ़ाइलों के लिए नामांकित किया जाना चाहिए। उदाहरण के लिए, प्रोजेक्ट A मानक का उपयोग करता है जबकि प्रोजेक्ट B मानक का उपयोग करता है। दोनों संदर्भों के बीच स्विचिंग एक दूसरे के साथ परस्पर विरोधी नियमों के बिना निर्बाध होनी चाहिए।

खोज
इसके लिए कुछ वायरफ्रेम पसंद किए गए जहां खोज परिणाम सभी परियोजनाओं में थे और परियोजना द्वारा क्रमबद्ध किए गए थे।

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

_Project B_
file3: matched substring
file4: matched substring

एससीएम
इस मामले में, मैं प्रत्येक स्कैम परिवर्तन के साथ प्रोजेक्ट द्वारा एक ब्रेकडाउन दिखाने की दिशा में अधिक झुक रहा हूं।

_Project A_
file1: added
file2: removed
...

_Project B_
file3: moved
file4: added
file5: added

मुझे लगता है कि ये दृष्टिकोण अधिक पारदर्शी और सहज हैं।

सर्वसम्मति (हाल की टिप्पणियों और अन्य मुद्दों पर आधारित) additionalFolders के विचार के खिलाफ लगती है, कम से कम प्रारंभिक रिलीज में।

जबकि मैं समझता हूं कि निर्णय पहले ही किया जा चुका है, तो क्या आप इस सुविधा को एपीआई के एक सेट के रूप में लागू करने के प्रयास पर विचार करेंगे, जबकि बाद के पुनरावृत्ति के लिए हठ छोड़कर? इसलिए, फ़ोल्डरों को जोड़ने / खोलने के लिए एपीआई, और इसका समर्थन करने के लिए एक्सप्लोरर, खोज, कार्यों और SCM विचारों को अपडेट करता है।

आपने इस बारे में बात की है कि उत्पाद से कुछ निकालना कितना मुश्किल है (यदि कोई प्रोजेक्ट / कार्यक्षेत्र अवधारणा किसी तरह विफल रही है), लेकिन वास्तविकता यह है कि यह समान रूप से (यदि अधिक नहीं तो) additionalFolders अवधारणा पर लागू होता है।

एक्सटेंशन के रूप में additionalFolders और "प्रोजेक्ट्स / वर्कस्पेस" दोनों को लागू करने से आप एकल मॉडल के लिए बिना उपयोग डेटा इकट्ठा कर सकेंगे। इनमें से एक एक्सटेंशन (या एक हाइब्रिड समाधान) को बाद में उत्पाद में एकीकृत किया जा सकता है।

क्या मैक ओएस पर पर्यावरण के साथ मुद्दों को तय किया गया है? मैं अभी भी Homebrew npm का उपयोग नहीं कर पा रहा हूं और ऐसे में बिना code लाइन के VSCode को

हाँ, यह मेरे लिए भी जरूरी है। मैं इसके साथ लोगों की समस्याओं को नहीं समझता। यह एक व्यक्ति के काम करने का तरीका नहीं हो सकता है, लेकिन इसका मतलब यह नहीं है कि किसी अन्य व्यक्ति का पसंदीदा कार्यक्षेत्र प्रबंधन कम मान्य है। मैं सिर्फ "तुम ऐसा क्यों करना चाहते हो?" इसके बजाय "आइए जानें कि दुनिया के हर दूसरे कोड संपादक में एक फीचर कैसे जोड़ा जाए।"

एटम पर मेरा अनुमान है।

@saborrie https://github.com/Microsoft/vscode/issues/24961 (मुझे अंदरूनी और नियमित संस्करण दोनों पर एक ही मुद्दा मिलता है)। अगर मैं इसे डीबग करने में मदद कर सकता हूं, तो मैं खेल हूं।

@akutz इन लोगों ने एक सभ्य मल्टी-रूट सिस्टम को डिजाइन करने में काफी प्रयास किया है, उन्होंने अपने डिजाइन सत्रों के वीडियो भी डाल दिए हैं (यह नवीनतम रिलीज नोट्स में था)। यह आ रहा है, लेकिन वे यह सुनिश्चित कर रहे हैं कि उन्हें यह सही लगे :-) (https://code.visualstudio.com/updates/v1_13)

हाय @cliffrowley ,

सुन कर खुशी हुई। मैंने केवल हाल ही में VSCode पर एक और नज़र डाली क्योंकि मैं एटम का हमेशा से उपयोग कर रहा हूं (और इससे पहले उदात्त)। हाल ही में एटम समस्याग्रस्त रहा है और एक Reddit थ्रेड में मैंने देखा कि VSCode इन दिनों वास्तव में एक बढ़िया विकल्प था। इसलिए मुझे आश्चर्य हुआ कि इसने एक मूल सुविधा का समर्थन नहीं किया।

बस यहाँ पर जमा करना - यह वास्तव में मुझे IntelliJ / WebStorm से VSCode को पूरा करने के लिए स्विच करने पर विचार करने से एकमात्र विशेषता है ... मुख्यतः क्योंकि, पिछले पोस्टर के रूप में, मैं पूरे दिन वितरित आर्किटेक्चर के साथ काम करता हूं और कई गीतात्मक एकीकृत की आवश्यकता है मेरे संपादक को (क्योंकि मैं बहुत आलसी हूं)

मैं _love_ कि y'all इस पर काम कर रहे हैं, और मैं इसे कार्रवाई में देखने के लिए इंतजार नहीं कर सकता।

मुझे vscode पसंद है लेकिन यह "मिसिंग फीचर" मुझे परमाणु से vscode में पूरी तरह से स्विच करने से दूर रख रहा है

एक प्रारंभिक संस्करण पहले से ही अंदरूनी सूत्रों के निर्माण में है। जाइए, इसे ले लीजिए :)

+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 बनाया, धन्यवाद ub

@Tyriar मैं वास्तव में खोज की कार्यक्षमता को कम से कम कहने के लिए भ्रमित करता हूं और सोचता हूं कि इसे उसी तरह के परिणाम प्रदर्शित करने चाहिए जैसे यह Explorer में प्रदर्शित होता है जैसा मैंने पहले कहा है ।

मुझे नहीं पता कि आप लोगों ने मुझ पर क्या देखा और कुछ लोगों ने ऊपर कहा या क्या और अधिक बदलाव आ रहे हैं, लेकिन व्यक्तिगत रूप से मुझे पसंद नहीं है कि आप हर बार रूट का नाम एक पेड़ में चीजों को छांटने का विरोध करें। -जब संभव हो तो देखें।

@eyalsk यह कार्य प्रगति पर है, मैं जुलाई में खोज परिणामों को अधिक देखूंगा: # 29977

Vscode परियोजना एक फ़ोल्डर पर आधारित है।
इसलिए, आप प्रत्येक प्रोजेक्ट के कॉन्फ़िगरेशन को अलग से कॉन्फ़िगर कर सकते हैं, और आप सीधे एकीकृत Git का उपयोग कर सकते हैं, या नहीं।

पयच्छर: ह्रदय:: ह्रदय: ह्रदय:

+1

मुझे आपकी सराहना करनी है, प्रिय VSCode टीम।
अंत में मैं एटम खाई करने में सक्षम हूँ क्योंकि मल्टी-रूट वर्कस्पेस अंदरूनी बिल्डरों में उतरा!
चूंकि दो-साल .ignignore आदि का एटम में सम्मान नहीं किया जाता है, जब मल्टी-रूट वर्कस्पेस में खोज की जाती है और आप इसे शुरू से ही सही पाते हैं!

क्या कार्यक्षेत्र की दृढ़ता दूसरे मुद्दे पर नज़र रखी जाती है?

कल वीएस कोड टीम ने मल्टी रूट वर्कस्पेस फ़ीचर

इस कार्य के परिणाम को हम कई रूट फ़ोल्डर वर्कस्पेस पर परीक्षण को सक्षम करने के लिए "न्यूनतम व्यवहार्य उत्पाद" (एमवीपी) कहते हैं।

वास्तव में, केवल इनसाइडर बिल्ड से ही उपलब्ध है इसलिए आप इसे यहाँ डाउनलोड कर सकते हैं

फाइल ढूँढने वाला

खोज

मान लीजिए कि कार्यक्षेत्र में प्रत्येक जोड़ा फ़ोल्डर एक अलग गिट रिपॉजिटरी है - क्या मल्टी रूट वर्कस्पेस का वर्तमान संस्करण उन रिपॉजिटरी के स्रोत नियंत्रण को अलग करने का काम करता है?

@Eyzu हम बहु मील के इस परिदृश्य के लिए SCM को अपनाने पर काम कर रहे हैं। हमारी प्रारंभिक सोच यह है कि SCM व्यू को मल्टी-रिपॉजिटरी अवेयर होने की आवश्यकता है, जो कि आवश्यक नहीं है कि मल्टी-फ़ोल्डर के बारे में एक्‍सप्‍लोरर और सर्च में समान हो: पहले से ही जब आप वीएस कोड में एक भी फोल्‍डर खोलते हैं तो आप कई रिपॉजिटरी कर सकते हैं । हमें लगता है कि एससीएम दृश्य को इन रिपॉजिटरी को अच्छे तरीके से दिखाना चाहिए ताकि आप प्रत्येक रिपॉजिटरी के लिए आउटगोइंग / इनकमिंग बदलाव के साथ-साथ प्रत्येक रिपॉजिटरी से फाइल करने में सक्षम हो सकें।

परिणाम दोनों बहु-रूट परिदृश्यों के साथ-साथ एकल रूट परिदृश्यों के लिए एक बेहतर अनुभव प्रदान करना चाहिए, जहां कई रिपॉजिटरी एक रूट में निहित हैं।

परिणाम दोनों बहु-रूट परिदृश्यों के साथ-साथ एकल रूट परिदृश्यों के लिए एक बेहतर अनुभव प्रदान करना चाहिए, जहां कई रिपॉजिटरी एक रूट में निहित हैं।

उत्कृष्ट दृष्टिकोण, तुम लोग रॉक!

@bpasero कमाल! मैं निश्चित रूप से अपने लोगों को इस पर ले जाने के लिए दिलचस्पी होगी। IntelliJ / WebStorm में कुछ ऐसा ही होता है जहां यह ऑटो Git जड़ों का पता लगाता है और उन्हें नीचे दाईं ओर उचित रूप से आपके लिए लाइन्स करता है, और मैंने व्यक्तिगत रूप से इसका उपयोग करना पसंद किया है।

क्या तुम लोग उन पंक्तियों के साथ कुछ सोच रहे थे या कुछ और अधिक विस्तृत थे?

हम अभी भी इसके लिए UX छांट रहे हैं और आपको परिणामों के बारे में पोस्ट करते रहेंगे।

यहां वर्चुअल फ़ाइल सिस्टम रूट काम नहीं कर सका? यह प्रभावी रूप से कार्य करेगा जैसे कि VFS रूट कई, असमान रास्तों के लिए मूल dir थे।

मैं अपने मल्टी-रूट काम पर एक अपडेट देना चाहता था क्योंकि आज पहला दिन है, जहां हमारे संशोधित मल्टी-रूट यूएक्स ने इनसाइडर रिलीज को हिट कर दिया है और आप में से कई जो "पुराने" व्यवहार के अभ्यस्त हो गए हैं, वे भ्रमित हो सकते हैं कि क्या चल रहा है।

पुराने समाधान के पंजे
मल्टी रूट के लिए पुराना समाधान एक नई सेटिंग workspace (वैश्विक settings.json ) पेश करेगा जो एकल रूट फ़ोल्डर में अतिरिक्त फ़ोल्डर्स जोड़ने की अनुमति देता है। यदि आपने देखा नहीं है तो सेटिंग इस तरह दिखती है:

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

हम इस समाधान को "मास्टर" फ़ोल्डर कहते हैं जिसमें अतिरिक्त फ़ोल्डर्स ("विस्तार") हैं।

यह कई नई अवधारणाओं को पेश किए बिना सबसे सीधा समाधान था, लेकिन इसमें खामियां भी हैं:

• आप मास्टर फोल्डर को कभी भी सिंगल फोल्डर के रूप में नहीं खोल सकते क्योंकि सेटिंग बनी रहती है
• आप एक्सप्लोरर से मास्टर फ़ोल्डर नहीं निकाल सकते
• मास्टर फ़ोल्डर से कुछ सेटिंग्स अन्य सभी फ़ोल्डरों पर लागू होती हैं
• आपकी सेटिंग्स बहु-रूट कॉन्फ़िगरेशन सामान के साथ प्रदूषित हो जाती हैं
• एक ही समय में कुछ फ़ोल्डर खोलने की अनुमति देना कठिन है (उदाहरण के लिए जब आप 3 खोलते हैं, तो हमें कौन सा मास्टर फ़ोल्डर लेना चाहिए?)

हमारा समाधान
हमें लगता है कि मल्टी रूट परिदृश्यों के लिए एक अधिक स्पष्ट कार्यक्षेत्र अवधारणा की आवश्यकता है और जैसे कि आज के अंदरूनी सूत्र में आपको कुछ नए यूआई रैपिंग दिखाई देंगे:

यह विचार है कि मल्टी-रूट वर्कस्पेस को बनाने के लिए एक स्पष्ट कार्रवाई की आवश्यकता होती है। उसी तरह जब आप एक खाली कार्यक्षेत्र में हो सकते हैं (कोई फ़ोल्डर नहीं खोला गया, बैंगनी स्टेटस बार) या एकल-फ़ोल्डर कार्यक्षेत्र (लाइट-ब्लू स्टेटस बार) में आप मल्टी-रूट वर्कस्पेस (डार्क-ब्लू स्टेटस) में भी हो सकते हैं बार)। VS कोड में एक कार्यक्षेत्र खोलने का यह तीसरा तरीका है कि आप जितने चाहें उतने फोल्डर बना सकें। इन कार्यस्थानों को एक फ़ाइल (जैसे myWorkspace.code ) में सहेजा जा सकता है और इसमें कार्यक्षेत्र सेटिंग भी शामिल हैं। आप उन्हें बचाने के लिए मजबूर नहीं हैं, हालांकि, जब तक आप उन्हें सहेजना नहीं चाहते हैं, तब तक वे "अनटाइटल्ड वर्कस्पेस" के रूप में दिखाई देंगे।

कार्यक्षेत्र खोलने के लिए आप या तो सहेजी गई कार्यक्षेत्र फ़ाइल खोल सकते हैं या हाल ही में खोली गई सूची से चुन सकते हैं:

यह सब बहुत युवा कोड और बहुत युवा UX है, इसलिए अगले हफ्तों में कुछ बदलावों की उम्मीद करें। हम जानते हैं कि अभी भी कुछ चीजों को सुलझाया जा सकता है (जैसे कि हम सिंगल-फोल्डर से मल्टी-फोल्डर स्मूथ तक कैसे संक्रमण कर सकते हैं)।

कुछ बदलाव जो पहले से ही आज किए गए थे, जो कल फीडबैक के आधार पर इनसाइडर रिलीज को प्रभावित करेंगे:

• कार्यस्थानों के विस्तार के रूप में .code से .code-workspace नाम बदलें
• फ़ोल्डरों और कार्यस्थानों की एक एकीकृत सूची (जैसे फ़ाइल> ओपन हाल में) फ़ोल्डरों और कार्यस्थानों के बीच अंतर करने के बजाय

और आने के लिए बने रहें to

इसके शीर्ष पर, अब हमारे पास एक .vscode फ़ोल्डर प्रति प्रोजेक्ट फ़ोल्डर है जिसमें फ़ाइल settings.json । इस फ़ाइल में निम्नलिखित शामिल हो सकते हैं:

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

यहां समस्या यह है, कि जब हम एक ही प्रोजेक्ट फ़ोल्डर पर सर्वर पर कई उपयोगकर्ताओं (विभिन्न आरडीपी सत्र) के साथ काम करना चाहते हैं, तो हम समान सेटिंग्स साझा करते हैं। यह इच्छित व्यवहार नहीं हो सकता है। मुझे अपने सहयोगी की तुलना में मेरे फॉन्ट का आकार बड़ा लग सकता है।

तो मेरी राय में, आपको यह भी ध्यान में रखना चाहिए कि विभिन्न उपयोगकर्ता एक ही फ़ोल्डर पर काम कर रहे हैं, लेकिन settings.json में अलग-अलग सेटिंग्स के साथ।

@ DarkLite1 आप एक अच्छा बिंदु लाते हैं। मल्टी-रूट के लिए हमारी सेटिंग्स डिजाइन में हम उन सेटिंग्स की पहचान करने की कोशिश करते हैं जिन्हें हम प्रति-फ़ोल्डर और सेटिंग्स का समर्थन कर सकते हैं, जिनका हम समर्थन नहीं कर सकते। हम आम तौर पर कहते हैं कि सेटिंग्स जो संपादक या एक विशिष्ट संसाधन को लक्षित करती हैं, प्रति फ़ोल्डर का समर्थन किया जा सकता है क्योंकि यह स्पष्ट है कि संपादक किस फ़ोल्डर से खोला गया था। अन्य सेटिंग्स जो समर्थित नहीं होंगी वे कार्यक्षेत्र अनुकूलन के आसपास अधिक हैं (उदाहरण के लिए स्टेटसबार या नहीं दिखाना)।

आपका उदाहरण editor.fontSize सेटिंग के बारे में है जिसे हम वास्तव में एक बहु रूट कार्यक्षेत्र में भी प्रति फ़ोल्डर समर्थन करते हैं। मुझे लगता है कि यह एक वैध परिदृश्य हो सकता है कि एक उपयोगकर्ता एक फ़ोल्डर के लिए एक बड़ा फ़ॉन्ट आकार चाहता है जिसमें बहुत सारे मार्कडाउन प्रलेखन होते हैं (यहां तक ​​कि एक अलग फ़ॉन्ट भी?)। इसलिए मुझे लगता है कि हमें इस सेटिंग को प्रति फ़ोल्डर बहु ​​रूट वातावरण में भी सम्मान करने से नहीं रोकना चाहिए।

यदि आप व्यक्तिगत कार्यक्षेत्र सेटिंग के रूप में editor.fontSize रखना चाहते हैं, तो मुझे लगता है कि इसे भंडार में जांच नहीं करनी चाहिए।

नए कार्यस्थान अवधारणा के साथ आप निम्नलिखित कार्य कर सकते हैं:

• फ़ाइल> कार्यस्थान> नया कार्यक्षेत्र
• अपना फोल्डर चुनें
• कार्यक्षेत्र सेटिंग्स खोलें
• editor.fontSize: 15 बदलें

तब से आपका कार्यक्षेत्र इस सेटिंग को ले जाएगा, लेकिन आप इसे किसी और के लिए मजबूर नहीं कर रहे हैं।

UX के नजरिए से, यह सुविधाजनक होगा अगर मैं वीएस कोड विंडो में फ़ोल्डर्स को ड्रैग एंड ड्रॉप कर सकता हूं, बिना स्पष्ट रूप से पहले कार्यक्षेत्र बनाने के लिए (यह ऐसा कुछ है जो मैं सब टाइम में करता हूं)। मैं हमेशा एक ही समय में कई परियोजनाओं पर काम करता हूं, और जो मैं इस पर काम कर रहा हूं उसके आधार पर हर दिन परियोजनाओं का एक अलग (ओवरलैपिंग) सेट होगा।

कार्यस्थान एक अवधारणा पेश करेगा जो मेरे काम करने के तरीके के मूल निवासी नहीं है, और मुझे अलग-अलग कार्यक्षेत्र कॉन्फ़िगरेशन का ट्रैक रखना होगा (जैसा कि मैं इसे समझता हूं) जो लगता है कि यह मेरे प्रोजेक्ट फ़ोल्डर्स में कुछ कॉन्फ़िगरेशन अव्यवस्था पैदा करेगा।

इसके अतिरिक्त, मुझे लगता है कि मैं कई उपयोगकर्ताओं के लिए बोलता हूं यदि मैं तर्क देता हूं कि खोज, कॉन्फ़िगरेशन जैसी चीजें डिफ़ॉल्ट रूप से वैश्विक हैं (सभी खुले फ़ोल्डरों पर लागू होती हैं) - हालांकि यह अच्छा होगा यदि मेरे पास एक फ़ोल्डर में स्थानीय रूप से खोज करने का विकल्प होगा ( मैं हमेशा इस उदात्त में पाया गया था)।

@SanderMertens आपने इसे याद किया होगा लेकिन @bpasero ने लिखा;

इन कार्यक्षेत्रों को एक फ़ाइल (जैसे myWorkspace.code) में सहेजा जा सकता है और इसमें कार्यक्षेत्र सेटिंग्स भी शामिल हैं। आप उन्हें बचाने के लिए मजबूर नहीं हैं, हालांकि, जब तक आप उन्हें सहेजना नहीं चाहते हैं, तब तक वे "अनटाइटल्ड वर्कस्पेस" के रूप में दिखाई देंगे।

अब, मुझे यकीन नहीं है कि आपके पास फ़ोल्डरों को खींचने और छोड़ने की क्षमता होगी, लेकिन जो मुझे मिल रहा है उससे लोगों को कार्यक्षेत्र बनाने के बिना मनमाने फ़ोल्डर खोलने की क्षमता होगी।

मैं इस सुविधा के स्थिर निर्माण में शामिल होने की प्रतीक्षा नहीं कर सकता।

वाह! 😄

वर्तमान में आप इसे जोड़ने के लिए किसी फ़ोल्डर को एक्सप्लोरर में नहीं खींच सकते, लेकिन यह हमारे बैकलॉग पर है। इस इंटरैक्शन के साथ जटिलता यह है कि हम उपयोगकर्ता के इरादे को नहीं जानते हैं: विंडो में फ़ोल्डर खोलने या इसे कार्यक्षेत्र में जोड़ने के लिए?

1 फ़ोल्डर से कई फ़ोल्डरों में संक्रमण वर्तमान में अन्य संपादकों की तुलना में अधिक स्पष्ट कदम है (आपको फ़ाइल> कार्यक्षेत्र> कार्यक्षेत्र सहेजें और अपने इच्छित फ़ोल्डर को चुनने की आवश्यकता है)। कई कारणों से है कि हम वर्तमान व्यवहार के साथ तब तक चलना चाहते हैं जब तक कि मल्टी रूट स्थिर न हो जाए। मुख्य कारण यह है कि मल्टी-रूट हमारे सभी एक्सटेंशन के लिए एक बड़ा बदलाव है। जबकि एक्सप्लोरर काम करता है और आप सभी फ़ोल्डरों के माध्यम से खोज कर सकते हैं, तब तक अधिकांश एक्सटेंशन सही तरीके से काम नहीं करेंगे जब तक कि नया मल्टी रूट एपीआई नहीं अपनाया जाता है। जैसे, हम शुरुआत में बहु-रूट को दुर्घटना से दर्ज करना आसान नहीं बनाना चाहते हैं। यह बहु रूट वर्कस्पेस में प्रवेश करने के लिए एक स्पष्ट उपयोगकर्ता इशारा है और उस मोड में हम इस तथ्य पर ध्यान आकर्षित करना चाहते हैं कि कुछ एक्सटेंशन अभी तक काम नहीं कर रहे हैं।

एक और कारण कार्यक्षेत्र सेटिंग्स है: इस प्रवाह की कल्पना करें:

• आप 1 फ़ोल्डर से शुरू करते हैं जिसमें कार्यक्षेत्र सेटिंग्स हैं
• आप एक दूसरा फ़ोल्डर जोड़ते हैं (संदर्भ स्विच और विंडो पुनः लोड के बिना यह काम करता है)
• आप कार्यक्षेत्र सेटिंग्स खोलें
  => मल्टी रूट में कार्यक्षेत्र सेटिंग्स अब फ़ोल्डर्स के बाहर कुछ स्थान पर संग्रहीत की जाती हैं क्योंकि आपके पास कई हो सकते हैं
  => शायद हमें उपयोगकर्ता से पूछना होगा कि क्या उपयोगकर्ता उस नए स्थान पर कार्यक्षेत्र सेटिंग्स को स्थानांतरित करना चाहता है

इसलिए, कोई फर्क नहीं पड़ता कि, मल्टी-रूट में प्रवेश करना वर्तमान में एक हल्का ऑपरेशन नहीं है। जब धूल जम जाती है और बहु-रूट को व्यापक रूप से अपनाया जाता है, तो हम इसे फिर से देख सकते हैं, लेकिन अभी के लिए हमें लगता है कि यह मॉडल बेहतर है और निराशा से बचा जा सकता है।

@bpasero मुझे लगता है कि डिफ़ॉल्ट रूप से एक बार जब आप किसी फ़ोल्डर को एक्सप्लोरर में खींचते हैं, तो उसे कार्यक्षेत्र में स्वचालित रूप से सहेजना नहीं चाहिए , भले ही वह मौजूद हो और यह एक स्पष्ट कार्रवाई होनी चाहिए जहां उपयोगकर्ता फ़ोल्डर पर क्लिक करता है। घसीटा और फिर इसे स्पष्ट रूप से कार्यक्षेत्र में जोड़ें और यदि आपके पास कुछ असंबंधित फ़ोल्डर हैं, तो एक बार में उन सभी को बचाने के लिए एक और कार्रवाई प्रदान करने के लिए समझदार हो सकता है।

यह सब उन उपयोग मामलों पर निर्भर करता है जिन्हें कोई कवर करना चाहता है। मैं अनुभव से पाया है कि KISS करना हमेशा अच्छा तरीका है। परिचय Workspaces ध्वनियों के रूप में महान एक feature लेकिन असली लाभ क्या है और नुकसान क्या हैं?

Workspaces का परिचय और उपयोग करते समय ध्यान में रखने वाला एक नुकसान यह है कि इसे कहीं डेटा (सेटिंग्स) को संग्रहीत करने की आवश्यकता है और इसके लिए उपयोगकर्ता के रखरखाव / जागरूकता की आवश्यकता है।

मान लीजिए कि एकमात्र लक्ष्य उपयोगकर्ताओं को एक वीएस कोड सत्र में कई फ़ोल्डरों के साथ काम करने की क्षमता देना है। कुछ कम नहीं, कुछ ज्यादा नहीं।

सबसे आम उपयोग मामला:
कोई Workspaces अवधारणा नहीं है। उपयोगकर्ता केवल एक अतिरिक्त फ़ोल्डर खोलता है, या जितने चाहें, और वे बाईं ओर दृश्य में खुलते हैं जैसे कि एक एकल फ़ोल्डर करता है। वह अपेक्षा करता है कि उसकी सेटिंग हर जगह एक जैसी हो। इसकी परवाह किए बिना कि उसकी फाइलें कहां स्थित हैं। और वह नहीं चाहता है कि वीएस कोड की कोई अतिरिक्त अव्यवस्था उसकी प्रोजेक्ट फाइलों के बीच में @SanderMertens , मुझे और शायद अन्य लोगों द्वारा भी बताई गई फाइलों के बीच में हो।

चुनौतियां / समस्याएं / प्रश्न:

• अलग-अलग सेटिंग फ़ाइलें क्यों हो सकती हैं? उपयोगकर्ता सेटिंग्स, कार्यस्थान सेटिंग्स? यह IMHO होना चाहिए सभी को एक ही स्थान पर संग्रहीत किया जाना चाहिए। उपयोगकर्ता द्वारा अपने व्यक्तिगत फ़ोल्डर / प्रोफ़ाइल में वरीयता के आधार पर, सिस्टम पर प्रत्येक उपयोगकर्ता की अपनी सेटिंग्स हो सकती हैं। अतिरिक्त बोनस। वे परियोजना फ़ाइलों को अव्यवस्थित नहीं करते हैं और कई उपयोगकर्ता अपनी बात कर सकते हैं। प्रोफ़ाइल साफ़ करें? महान! वीएस कोड के लिए क्लीन स्लेट भी।

मुझे लगता है कि यदि आप चाहते हैं तो Workspaces थोड़ी अधिक इंजीनियरिंग चीजें हैं:
गति, सादगी और एक संपादक जो बस काम करता है।, कोई अधिक जटिल चीजें या अतिरिक्त अवधारणाओं को समझना नहीं है। यदि उदात्त या अन्य संपादकों के उपयोगकर्ता अपने वर्कफ़्लो में इस अवधारणा का उपयोग नहीं करते हैं, तो यह चीजों को उखाड़ फेंकने का संकेत होना चाहिए। या इसका मतलब यह हो सकता है कि वास्तव में भयानक का आविष्कार किया गया है कि अन्य संपादक भी लागू करेंगे, लेकिन मुझे अपने संदेह हैं।

मुझे खेद है अगर यह शेख़ी के रूप में लगता है, तो यह बिल्कुल मेरा इरादा नहीं है। लेकिन मेरा मानना ​​है कि हम मल्टी रूट / फोल्डर एक्सेस के संबंध में बेहतर कर सकते हैं।

@ DarkLite1 कार्यस्थानों के लिए हमारी नई रणनीति पर प्रतिक्रिया प्रदान करने के लिए समय निकालने के लिए धन्यवाद।

मैं आपकी सभी बातों से सहमत हूं और एक सरल समाधान भी चाहता हूं। एक अवधारणा के रूप में कार्यस्थान एक बहु-रूट समाधान की ओर हमारा पहला कदम है जो हमारे मौजूदा पैटर्न (कार्यक्षेत्र सेटिंग्स, एक्सटेंशन आदि) के साथ काम करता है। चूंकि यह पहला कदम है, इसलिए कुछ मोटे किनारों (जैसे 1 से एन फ़ोल्डरों में संक्रमण करना उतना हल्का नहीं है जितना कि हो सकता है) की अपेक्षा करें। हमारा लक्ष्य इस संक्रमण को सुचारू बनाना है और भविष्य में इसके होने की आवश्यकता से अधिक जटिल नहीं बनाना है। और हम एक उपयोगकर्ता को इन कार्यस्थानों को प्रबंधित करने के लिए बाध्य नहीं करना चाहते हैं (यही कारण है कि हमारे पास "शीर्षक रहित कार्यस्थान" हैं जो तब तक जीवित रहते हैं जब तक कि खिड़की खुली रहती है और एक बार जब आप उस विंडो को बंद कर देंगे)।

मल्टी-रूट वर्कस्पेस के आसपास कुछ चीजें हैं जो ध्यान में रखने के लिए हैं कि शायद इतनी स्पष्ट नहीं हैं। मुझे उम्मीद है कि निम्नलिखित विस्तृत व्याख्या हमारी डिजाइन प्रक्रिया को समझने में मदद करती है:

कार्यक्षेत्र सेटिंग्स
हम एक कार्यक्षेत्र फ़ोल्डर ( .vscode फ़ोल्डर) के अंदर सेटिंग का समर्थन करते हैं। जितना कुछ उपयोगकर्ता इस तरह की सेटिंग्स को पसंद नहीं कर सकते हैं जो .gitignore फ़ाइलों या रिपॉजिटरी में समाप्त होते हैं, ऐसे कई हैं जो इस कार्यक्षमता पर भरोसा करते हैं। हम केवल उन सेटिंग्स का समर्थन करना बंद नहीं कर सकते हैं जो फ़ोल्डरों के भीतर रहते हैं क्योंकि उपयोगकर्ता उन पर भरोसा करते हैं। अब, बहु-रूट परिदृश्यों के लिए यह स्पष्ट है कि हमें कार्यक्षेत्र सेटिंग्स के लिए एक नया स्थान ढूंढना होगा। हम एक कार्यक्षेत्र फ़ाइल की अवधारणा के साथ आए हैं जिसमें ये सेटिंग्स हैं। जब तक कार्यक्षेत्र कहीं भी सहेजा नहीं जाता है, तब तक यह उस फ़ोल्डर में रहता है जिसमें अन्य VS कोड विशिष्ट डेटा सम्‍मिलित है और जब आप फ़ाइल सहेजते हैं, तो सेटिंग उस फ़ाइल के भीतर होगी।

अब कल्पना करें कि आप वीएस कोड में 1 फ़ोल्डर से शुरू करते हैं जिसमें कार्यक्षेत्र सेटिंग्स परिभाषित हैं और आप एक दूसरा फ़ोल्डर जोड़ना चाहते हैं। अब हमें क्या करना चाहिए? पहले फ़ोल्डर के कार्यक्षेत्र सेटिंग्स पर ध्यान न दें? उपयोगकर्ता को सेटिंग्स माइग्रेट करने के लिए कहें? हमने यह स्पष्ट करने के लिए एक स्पष्ट संदर्भ स्विच बनाने का निर्णय लिया कि यह स्पष्ट है कि एक कार्यक्षेत्र खोलने के लिए एक अलग स्थान में अपनी कार्यक्षेत्र सेटिंग्स होती हैं।

और अब कल्पना करें कि आप 1 फ़ोल्डर से 2 फ़ोल्डर में गए और हम कार्यक्षेत्र सेटिंग्स को किसी अन्य स्थान पर ले गए। कल्पना कीजिए कि आप इन कार्यक्षेत्र सेटिंग्स में बदलाव करते हैं। अब आप 2 फ़ोल्डरों से 1 पर वापस जाना चाहते हैं, क्या आप कार्यस्थान सेटिंग्स को फ़ोल्डर में वापस माइग्रेट करने की अपेक्षा करेंगे?

एक और उदाहरण: आप 1 से 2 फ़ोल्डरों से संक्रमण करते हैं और कार्यक्षेत्र सेटिंग्स कॉन्फ़िगर करते हैं। अब आप विंडो को बंद करें। मुझे लगता है कि अगर आप इस कार्यक्षेत्र में किसी तरह से वापस नहीं आ पाए, तो आप हम पर पागल हो जाएंगे क्योंकि आपने इस कार्यक्षेत्र के लिए सेटिंग्स को ध्यान से कॉन्फ़िगर किया है। इसलिए भले ही आप कार्यक्षेत्र की अवधारणा को पसंद नहीं करते हैं, एक बार जब आप इसके लिए सेटिंग्स कॉन्फ़िगर करते हैं, तो मुझे लगता है कि आप चाहते हैं कि कार्यक्षेत्र पर रहना चाहिए।

मुझे आशा है कि इन उदाहरणों यह थोड़ा आसान सा समझने के लिए क्यों KISS के रूप में आसान हमारे लिए के रूप में एक सोच सकते हैं नहीं है।

एक्सटेंशन
हमारे सभी एक्सटेंशन हमेशा एक एपीआई के खिलाफ काम करते थे जो एकल कार्यक्षेत्र पथ प्रदान करता है क्योंकि अब तक हमने मल्टी-रूट वर्कस्पेस का समर्थन नहीं किया था। एक उपयोगकर्ता के रूप में आप सोच सकते हैं कि 1 फ़ोल्डर से 2 फ़ोल्डर में स्विच करना बहुत ही सरल और हल्का संचालन है, लेकिन एक्सटेंशन के लिए यह बहुत सारी चीजों का मतलब हो सकता है: भाषा एक्सटेंशन जो अब तक माना जाता है कि अचानक एक फ़ोल्डर को कई के बारे में पता होना चाहिए फ़ोल्डरों। और उसके शीर्ष पर, ये फ़ोल्डर किसी भी समय बहुत गतिशील रूप से आ और जा सकते हैं।

एक वास्तविक कार्यक्षेत्र अवधारणा पेश करने से हमें इस अवधारणा को अपनाने के लिए कुछ और कमरे और समय मिल जाते हैं और एक्सटेंशन को मदद मिलती है। हम उदाहरण के लिए विकलांगों को अक्षम कर सकते हैं जिन्होंने अभी तक बहु-रूट कार्यस्थानों को नहीं अपनाया है ताकि अजीब चीजों को होने से रोका जा सके (जैसे एक भाषा एक्सटेंशन केवल एक फ़ोल्डर पर काम करता है और दूसरे पर गलत त्रुटियों की रिपोर्ट करता है)।

आइए पहले इन नए कार्यक्षेत्रों के साथ बहु-रूट समर्थन को स्थिर करने की कोशिश करें और फिर यह संशोधित करें कि हम बदलाव को कितना हल्का बना सकते हैं। एक बार जब हमारे पास एक्सटेंशन होते हैं और हमारी सेटिंग की कहानी पता चलती है, तो मुझे लगता है कि हम फ्लिप को अधिक हल्के अनुभव के लिए बना सकते हैं।

पुनश्च: चूंकि आप अन्य संपादकों के साथ उनके बहु-रूट समर्थन के संदर्भ में चर्चा करते हैं, मैं सिर्फ यह बताना चाहता था कि ये संपादक एक कार्यक्षेत्र या परियोजना की अवधारणा के साथ आते हैं जिसे आप किसी फ़ाइल में सहेज सकते हैं और दूसरों के साथ साझा कर सकते हैं। आमतौर पर आप इन अवधारणाओं को नहीं देख रहे हैं क्योंकि 1 से एन फ़ोल्डर्स तक जाना एक बहुत ही हल्का ऑपरेशन है। हालांकि मैं तर्क दूंगा कि इस सुविधा पर भरोसा करने वाले लोग काम को प्रबंधित करने के तरीके के रूप में सहेजे गए कार्यक्षेत्र / परियोजनाओं में स्थानांतरित होने लगते हैं। उदाहरण के लिए, जब तक आप कार्यक्षेत्र / परियोजना को नहीं बचाते और खिड़की बंद नहीं करते, तब तक यह सब जानकारी खो जाती है।

@bpasero मुझे वापस पाने के लिए धन्यवाद और विस्तृत विवरण के लिए, मैं वास्तव में इसकी सराहना करता हूं।

जैसा कि मैं पूरी तरह से उदात्त से परिचित नहीं हूं, मैंने यह जांचने की स्वतंत्रता ली कि वे इसे कैसे संभालते हैं। और आप सही हैं, वे Workspaces हैं और यहां तक ​​कि Project फ़ाइलों का भी। केवल एक चीज जो मुझे परेशान करती है वह यह है कि यह मेरे प्रोजेक्ट के बीच में वीएस कोड फाइलें डालता है। लेकिन जैसा कि आपने उल्लेख किया है, यदि अन्य लोग इस पर भरोसा करते हैं, तो यह ध्यान रखना होगा कि यह वही हो सकता है जो सबसे अच्छा है। मैं केवल सोच रहा हूं कि ये सेटिंग फाइलें उपयोगकर्ता के लिए विशिष्ट क्यों नहीं हैं? मैं एक सहकर्मी को उसी फ़ोल्डर संरचना पर वीएस कोड खोलने की कल्पना कर सकता हूं, लेकिन अपनी खुद की सेटिंग्स चाहता हूं।

यदि Workspaces आगे बढ़ने का रास्ता है, और ऐसा लगता है कि वे हैं, तो यह ऐप खोलने पर तर्कसंगत होगा कि यह अंतिम उपयोग की गई सेटिंग्स को फिर से लोड करेगा। भले ही यह एक Workspace सहेजा न गया हो। मुझे लगता है कि यह जीवन को थोड़ा सरल बनाता है।

मैंने वीएस कोड के लिए क्यों चुना? क्योंकि यह क्रॉस प्लेटफॉर्म है, जैसा कि मैं घर पर लिनक्स और काम में विंडोज का उपयोग करता हूं, यह वास्तव में मेरा डिफ़ॉल्ट संपादक बन सकता है! अतिरिक्त बोनस के रूप में, मैं एक पॉवरशेल डेवलपर हूं और इसके लिए एक एक्सटेंशन भी है। तो वहां दो बड़ी जीत! उस शीर्ष पर, जावा पाठ्यक्रम के लिए मैं पीछा कर रहा हूं, Red Hat VS कोड के लिए एक एक्सटेंशन भी बना रहा है। एक बार जब आप वीएस कोड को बेहतर तरीके से जान लेते हैं, तो उसके शॉर्टकट और सभी के साथ, आपको बोर्ड भर में फायदा होगा।

एप्लिकेशन और इसके एक्सटेंशन अभी भी कुछ बिंदुओं पर बीटा या यहां तक ​​कि अल्फा स्थिति में थोड़े हैं, लेकिन फिर भी, महान काम करने वाले लोग! वास्तव में प्रयासों की सराहना करते हैं और हर दिन इनसाइडर में प्रगति को देखते हैं। बढ़िया काम करते रहें और अच्छा सप्ताहांत रहे।

उस व्याख्या @bpasero के लिए धन्यवाद, मुझे लगता है कि मैं बेहतर समझता हूं कि अब जटिलता क्या है।

एक दृष्टिकोण कार्यक्षेत्र के रूप में एक ही कॉन्फ़िगरेशन के साथ परियोजनाओं के किसी भी सेट को वैचारिक रूप से व्यवहार करने के लिए हो सकता है। उसके अलावा, आप .vscode फ़ोल्डर को तब तक जोड़ने से बच सकते हैं जब तक कि प्रोजेक्ट डिफ़ॉल्ट कॉन्फिगर से डायवर्ट न हो जाए। वैसा होना ही चाहिए:
1) परियोजनाओं में अधिकांश अव्यवस्था से छुटकारा
2) परियोजनाओं को जोड़ते समय अधिकांश कॉन्फ़िगरेशन क्लैस को रोकें (सरल मामले में, कोई कॉन्फ़िगरेशन नहीं होगा)

मुझे लगता है कि स्पष्ट कार्यक्षेत्र अवधारणा के रूप में चर्चा की गई समस्या का एक अच्छा समाधान है। इन दो सरल नियमों के साथ मैं उन यूसेकस को कम कर देता हूं जहां लोग इस समस्या में भाग लेते हैं।

मेरे लिए, थ्रेड में टिप्पणियों और मेरे उपयोग-मामलों को देखते हुए, मैं _Multi-folder_ और _Workspaces_ को दो अलग-अलग अवधारणाओं के रूप में देखता हूं, और शायद इसे अलग से भी माना जाना चाहिए।

यह किसी कार्यक्षेत्र_ को वर्तमान विंडो में एक और फ़ोल्डर जोड़ने के लिए मजबूर नहीं करना चाहिए। इसे बस नए फ़ोल्डर को पेड़ में जोड़ना चाहिए, और नव निर्मित कार्यक्षेत्र को _internal info_ के रूप में छोड़ना चाहिए। यदि उपयोगकर्ता कार्यक्षेत्र को बचाने का निर्णय लेता है, तो वास्तव में कार्यक्षेत्र बनाया जाता है। और यहां तक ​​कि अगर मैं शीर्ष-फ़ोल्डर को फिर से खोलते हुए कार्यक्षेत्र को नहीं बचाता हूं, तो यह _remember_ मेरा अस्थायी कार्यक्षेत्र_ होगा और अन्य फ़ोल्डरों को भी खोल देगा, ठीक वैसे ही जब आप एक फ़ोल्डर खोलते हैं तो यह खोली गई फ़ाइलों को याद करता है। BTW, मुझे आश्चर्य है कि मैं कमांड-लाइन में मल्टी-फ़ोल्डर कैसे खोल सकता हूं।

मेरे उपयोग के मामलों के लिए, मल्टी-फ़ोल्डर एक ही विंडो में एक समय में एक से अधिक फ़ोल्डर देखने का एक तरीका है, न कि _Project Group / Solution_ दृष्टिकोण। तो, एक सरल समाधान फिट होगा। लेकिन मैं समझता हूं कि दूसरों को _Workspace_ की आवश्यकता कैसे होती है, इसकी अपनी सेटिंग्स और इसी तरह: थम्सअप:।

वह चीज जो मुझे इस नए कार्यस्थान अवधारणा के बारे में सबसे अधिक परेशान करती है ( User Settings का उपयोग करके पहली पुनरावृत्ति की तुलना में) वही चीज है जो मुझे तब परेशान करती थी जब मैं उदात्त पाठ का उपयोग कर रहा था। तथ्य यह है कि आप _can_ .code-workspace फ़ाइलें _anywhere_ बचाते हैं, और अब मुझे उन्हें संग्रहीत करने के लिए एक सामान्य स्थान का प्रबंधन करना होगा। यह बहुत सरल होगा, IMHO कि यह दो स्थानों में से एक में अपने आप फिट हो जाएगा:

• user-data-dir फ़ोल्डर के अंदर, जैसे User Settings और Keybindings
• _Top Folder_ के अंदर

बस स्पष्ट होने के लिए, मैं अधिक जटिल कार्यक्षेत्र अवधारणा को समझता हूं जो अन्य उपयोगकर्ताओं को चाहिए। मैं बस एक सरल मल्टी-फ़ोल्डर अवधारणा के लिए एक सरल दृष्टिकोण चाहता था।

मुझे यह विकल्प पसंद है, इस विकल्प को जोड़ें।

क्योंकि अंदर का फोल्डर बहुत प्रभावशाली नहीं है।

या इस विकल्प को बदलने की क्षमता जोड़ें।

मुझे कार्यक्षेत्र का विचार पसंद है! इस पर कोई विचार कब तैयार होने वाला है?

क्या इस बिंदु पर यह अपेक्षित है कि निचले बाएँ कोने में गिट जानकारी, वर्तमान में फ़ोकस की गई फ़ाइल में जो भी रेपो है, उसकी गिट शाखा को ठीक से प्रतिबिंबित नहीं करती है? मुझे v1_15 रिलीज़ नोटों में "कई गिट जड़ों" के बारे में कुछ भी नहीं दिखाई दिया।

मैं अभी कुछ दिनों के लिए इनसाइडर बिल्ड के साथ इस सुविधा का उपयोग कर रहा हूं और मुझे कहना होगा कि यह सब कुछ है जो मैं चाहता था। बहुत साफ उपयोगकर्ता अनुभव और मैं तब तक इंतजार नहीं कर सकता जब तक यह मुख्य निर्माण में नहीं है इसलिए मैं अपनी पूरी टीम को इसमें परिवर्तित कर सकता हूं।

जब NodeJS के साथ काम करना और कई एनपीएम मॉड्यूल एक समय में खुले रहते हैं, तो यह एक खिड़की में सब कुछ एक साथ रखता है एक बहुत बड़ा समय बचाने वाला होता है।

विशाल टीम के लिए सहारा!

यह फीचर मेरे रिलीज़ नोट्स में gif और स्पष्टीकरण के साथ क्यों दिखाई देता है, लेकिन वास्तविक संपादक में उपलब्ध नहीं है ?!

@ शशांकनतराज जो अंदरूनी निर्माण पर है, मूल निर्माण पर नहीं। यदि आप डॉक्टर को ध्यान से देखते हैं तो इसका उल्लेख केवल अंदरूनी सूत्र के लिए किया जाएगा

चल रहे बहु रूट कार्य के लिए हमारा रोडमैप https://github.com/Microsoft/vscode/issues/28344 में कैप्चर किया गया है और अगस्त, सितंबर और शायद अक्टूबर तक भी जारी रहेगा।

हम इस सुविधा को केवल अंदरूनी सूत्रों में उपलब्ध रखेंगे:

• हम एक उचित बहु-रूट सक्षम SCM, डिबग और कार्य अनुभव प्रदान कर सकते हैं
• हमने उन एक्सटेंशनों के लिए बहु-रूट API और कार्यक्षमता को अपनाया, जिन्हें हम साथ भेजते हैं और जिन्हें हम सक्रिय रूप से योगदान देते हैं (उदा। Go)
• विस्तार लेखकों के पास नए मल्टी रूट एपीआई को अपनाने के लिए पर्याप्त समय (जैसे 1 मील का पत्थर) था

कृपया यह समझें कि हम इस सुविधा को स्थिर और टूटे हुए एक्सटेंशन अनुभव होने के कारण शिपिंग से बचना चाहते हैं, क्योंकि हमने इस सुविधा को जल्द ही शुरू कर दिया है।

पेशेवर लोगों, महान नौकरी होने के लिए धन्यवाद!

@bpasero मैं विस्तार लेखकों के बारे में थोड़ा चिंतित हूं कि वे समय पर प्लगइन्स को अपडेट करेंगे। क्या उन्हें कुछ विशेष आगामी ब्रेकिंग परिवर्तन ईमेल प्राप्त होते हैं?

धन्यवाद

@ फेलिकज कृपया हमारे रोडमैप (https://github.com/Microsoft/vscode/issues/28344) को देखें। सितंबर की रिलीज के लिए हम वीएस कोड में उन एक्सटेंशन को अपनाने की योजना बनाते हैं जिन्हें हम शिप करते हैं और जब हम उस पर काम कर रहे होते हैं तो हम ऐसा करने के लिए आवश्यक एपीआई और उपयोगिताओं को जोड़ते हैं।

सितंबर के दौरान यह योजना है:

आज का इनसाइडर अपडेट .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"
    ]
}

और नया प्रारूप ist:

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

कार्यक्षेत्र आईडी
कार्यस्थान ID का उपयोग कार्यस्थान के साथ कुछ चीजों को संबद्ध करने के लिए किया जाता है:

• सभी UI स्थिति (उदाहरण के लिए फ़ाइलें)
• सभी गंदे फ़ाइल स्थिति (उर्फ हॉट-एग्जिट)
• एक्सटेंशन स्टेट (यदि कोई हो)

हमने कार्यक्षेत्र फ़ाइल से id संपत्ति निकालने का निर्णय लिया और इसके बजाय डिस्क पर कार्यक्षेत्र फ़ाइल के निरपेक्ष फ़ाइल पथ के आधार पर id गणना की। इसके कुछ फायदे और नुकसान हैं लेकिन अंत में हमें लगता है कि फायदे इसे एक बेहतर समाधान बनाते हैं:

• यह अजीब था कि आप फ़ाइल में id को केवल एक और मान लिखकर संपादित कर सकते थे
• यह बहुत स्पष्ट नहीं था कि कार्यक्षेत्र फ़ाइल को दूसरों के साथ साझा करते समय id का इलाज कैसे किया जाना चाहिए (क्या id बदला जाना चाहिए? id एक यूआईडी होना चाहिए?)
• कार्यक्षेत्र फ़ाइल की प्रतिलिपि बनाना और उसे अलग विंडो में खोलना संभव नहीं था, आपको कॉपी किए गए फ़ाइल में id पहले बदलना होगा
• परिणामस्वरूप, "कार्यक्षेत्र को सहेजें" कार्रवाई के लिए उपयोगकर्ता से पूछना होगा कि क्या कॉपी में अलग id होना चाहिए या नहीं।

इस दृष्टिकोण का एक नुकसान यह है कि एक बार जब आप कार्यक्षेत्र फ़ाइल को स्थानांतरित या नाम देते हैं, तो संबंधित राज्य खो जाएगा। गंदी फाइलें ("हॉट-एग्जिट") फिर से शुरू होने के बाद भी फिर से खुल जाएंगी, लेकिन वे एक खाली विंडो में खुलेंगी और अब कार्यक्षेत्र की खिड़की से जुड़ी नहीं होंगी। हम अभी भी सोचते हैं कि हम इस व्यवहार में सुधार कर सकते हैं, हालांकि यह आज के साथ संगत व्यवहार कर रहा है जब आप संबंधित UI स्थिति और गंदी फ़ाइलों के साथ एक फ़ोल्डर का नाम बदलते हैं।

फ़ोल्डर
हमने folders प्रॉपर्टी के प्रारूप पर फिर से विचार करने का फैसला किया।

• हमें अब आपको संसाधन URI का उपयोग करने की आवश्यकता नहीं है, लेकिन संपादन आसान बनाने के लिए केवल फ़ाइल पथ
• हमने वस्तुओं के होने के लिए folders संपत्ति की प्रविष्टियों को बदल दिया ताकि हम मेटाडेटा को प्रविष्टियों में आवश्यकतानुसार जोड़ सकें (उदाहरण के लिए प्रत्येक फ़ोल्डर में अतिरिक्त name संपत्ति हो सकती है)

अंत में, रिश्तेदार रास्तों के लिए समर्थन भी उतरा है। आप एक रिश्तेदार फ़ाइल पथ दर्ज कर सकते हैं और इसे कार्यक्षेत्र फ़ाइल के मूल फ़ोल्डर के विरुद्ध हल किया जाएगा। ध्यान दें कि बग के कारण https://github.com/Microsoft/vscode/issues/33188 वर्तमान में हम कार्यक्षेत्र फ़ाइल में परिवर्तन करते समय निरपेक्ष पथों के सापेक्ष पथ लिख रहे हैं।

@bpasero यह कमाल है। जब अतिरिक्त name संपत्ति काम करेगी? इस समय मेरे कार्यक्षेत्र में एक ही नाम के दो फ़ोल्डर हैं और यह भयानक है।

@DaniloPolani https://github.com/Microsoft/vscode/issues/29871 देखें

सापेक्ष रास्तों की हैंडलिंग के लिए एक अद्यतन: आज के अंदरूनी सूत्र के निर्माण से शुरू होकर हम कार्यक्षेत्र फ़ाइल के लिए पथ के रूप में लिखेंगे यदि कार्यक्षेत्र फ़ाइल का स्थान लक्ष्य का माता-पिता है। दूसरे शब्दों में, पथ हमेशा सापेक्ष होंगे जब तक कि हमें पथ को व्यक्त करने के लिए " ../ " का उपयोग नहीं करना होगा।

चूंकि अनटाइटल्ड वर्कस्पेस हमेशा वीएस कोड के डेटा डायरेक्टरी में रहते हैं, इसलिए वहां के रास्ते हमेशा निरपेक्ष रहेंगे। लेकिन एक बार जब आप किसी अनटाइटल्ड कार्यक्षेत्र को किसी स्थान पर सहेज लेते हैं, तो हम यदि संभव हो तो रास्तों को फिर से लिखेंगे।

यदि आप इस स्प्रिंट के दौरान गए मल्टी रूट वर्कस्पेस के आसपास के बदलावों के बारे में उत्सुक हैं, तो अपडेट किए गए नोट्स को देखें ।

+1

+1

@bpasero IMHO, जिस तरह से यूआई राज्यों को संभाला जाता है (मौसम यह .code-workspace फ़ाइल में एक आईडी स्ट्रिंग का उपयोग कर रहा है, या इसके बजाय फ़ाइल पथ का उपयोग करके आईडी के रूप में) पर्याप्त नहीं है।
.code-workspace फ़ाइल, या उसके किसी भी मूल फ़ोल्डर का नाम बदलना, या उसे इधर-उधर ले जाना, और UI स्थिति को खोना मेरी राय में पूरी तरह से अनपेक्षित है। मुझे लगता है कि लोग इस बात से अनभिज्ञ हैं कि हुड के तहत काम करने वाले लोगों के पास इस बात का कोई सुराग नहीं होगा कि उन्होंने अपनी पिछली UI स्थिति को कैसे खो दिया और उन्हें कैसे वापस लाया जाए।
जो कि फाइल सिस्टम में फाइलों के निरपेक्ष पथ से बिल्कुल भी जुड़ा हुआ नहीं होना चाहिए!

यह यूआई स्थिति उस तरह से लागू होता है जो वर्तमान में स्थिर रिलीज में भी फ़ोल्डर पथ से संबंधित है। मैं उस बारे में पहले बहुत उलझन में था, जब तक मैंने कुछ गोलगप्पे नहीं किए।

IMO के मामले में हम सिर्फ एक फ़ोल्डर के साथ काम कर रहे हैं, यूआई राज्य को .vscode फ़ोल्डर के अंदर बचाया जाना चाहिए। यदि हम एक बहु-रूट कार्यक्षेत्र के साथ काम कर रहे हैं, तो यूआई राज्य को उचित नामकरण सम्मेलनों का उपयोग करके .code-workspace फ़ाइल के रूप में एक ही फ़ोल्डर में एक अलग फ़ाइल के रूप में सहेजा जाना चाहिए (या शायद उस फ़ाइल के अंदर, हालांकि सेटिंग्स को मिलाते हुए और राज्य एक अच्छा विचार नहीं हो सकता है)।

यदि इसे सही ढंग से लागू किया जाता है, तो यह उपयोगकर्ताओं को यूआई राज्यों तक पूरी पहुंच प्रदान करने की अनुमति देता है, नए यूआई राज्यों को किसी दिए गए कार्यक्षेत्र में संलग्न करें (मल्टी-रूट या रूट), आदि।
मुझे विभिन्न कंप्यूटरों के बीच UI स्थिति को सिंक करने में सक्षम होना पसंद है, कार्यालय में काम करना, फिर घर जाना, लैपटॉप को पकड़ना या जो कुछ भी हो और जहां मैंने छोड़ा था, जारी रखना।
कार्यक्षेत्र से जुड़े कई UI स्टेट्स होने पर और आसानी से उन दोनों के बीच स्विच (मेनू / कीबाइंडिंग / कमांड / आदि) जब अलग-अलग फीचर्स पर काम करना बहुत अच्छा होगा। शायद .vscode अंदर अलग-अलग .code-uistate स्वचालित रूप से सूचीबद्ध हैं, या कई .code-uistate फाइलें मुख्य .code-workspace अनुसार उपसर्ग करती हैं, या एक सरणी में सूचीबद्ध हैं।

मैं इस बारे में विस्तार से सोच रहा हूं कि प्रोजेक्ट और वर्कस्पेस सब्लिम टेक्स्ट पर कैसे काम करते हैं। एक ही कार्यक्षमता, विभिन्न डिजाइन। इस मामले में एक वीएस कोड कार्यक्षेत्र एक सब्लिम परियोजना के समान होगा, और अलग वीएस कोड यूआई राज्यों के अधीन कार्यक्षेत्रों के समान होगा।

इस मुद्दे के बारे में:

यह अजीब था कि आप किसी अन्य मान को टाइप करके फ़ाइल में आईडी को संपादित कर सकते थे

हाँ, पूरी तरह से। आईडी को वहां से हटाना सही विकल्प था।

यह बहुत स्पष्ट नहीं था कि कार्यक्षेत्र फ़ाइल को दूसरों के साथ साझा करते समय आईडी का इलाज कैसे किया जाना चाहिए (क्या आईडी को बदल दिया जाना चाहिए? क्या आईडी को यूआईडी होना चाहिए?)

ठीक है, अगर हमें myproject.code-workspace और myproject.code-uistate मिलते हैं, तो यह उपयोगकर्ता पर निर्भर है कि वह अपना UI राज्य साझा करे या नहीं। कोई और सोच नहीं है कि उस आईडी का क्या मतलब है, यह कैसे उत्पन्न होता है, अगर इसे साझा करते समय टकराव से बचने के लिए UUID होने की आवश्यकता है, आदि।
फ़ोल्डर सेटअप और सेटिंग्स साझा करना चाहते हैं? myproject.code-workspace भेजें, चिंता करने की कोई आवश्यकता नहीं है।
सब कुछ साझा करना चाहते हैं? दोनों फाइलें भेजें।

कार्यक्षेत्र फ़ाइल की प्रतिलिपि बनाना और उसे अलग विंडो में खोलना संभव नहीं था, आपको पहले कॉपी की गई फ़ाइल में आईडी बदलनी होगी

यदि आप उसी फ़ोल्डर सेटअप के साथ एक ताज़ा UI स्थिति के साथ शुरू करना चाहते हैं और सेटिंग्स आपके .code-workspace फ़ाइल की नकल करती हैं।

परिणामस्वरूप, "कार्यक्षेत्र को सहेजें" कार्रवाई के लिए उपयोगकर्ता से पूछना होगा कि क्या कॉपी में एक अलग आईडी होना चाहिए या नहीं

यह मुश्किल था क्योंकि उपयोगकर्ता को पता नहीं था कि वह आईडी क्या था। शायद दो विकल्प "वर्तमान राज्य के साथ क्लोन कार्यक्षेत्र" और "नया खाली कार्यक्षेत्र" होना अधिक सरल होगा। लेकिन यह UX है और आपको इसके बारे में एक विश्लेषण करना होगा।

फ्रैंक से सहमत, सभी प्रोजेक्ट कॉन्फ़िगरेशन फ़ाइलों को सेटिंग्स के अंदर रखें
परियोजनाओं में फ़ोल्डर, ग्रहण आईडीई पर एक नज़र डालें जिसका अधिकार है
दृष्टिकोण। इसमें प्रोजेक्ट और वर्कस्पेस सेटिंग्स की अवधारणा है
कार्यक्षेत्र में प्रोजेक्ट ओवर राइटिंग की चूक। कार्यक्षेत्र केवल एक फ़ोल्डर है
फ़ोल्डर परियोजनाओं का प्रतिनिधित्व करते हैं। तो कार्यक्षेत्र में .vscode फ़ोल्डर है
फ़ोल्डर, और प्रत्येक परियोजना का अपना .vscode फ़ोल्डर है। और कृपया नहीं
नीचे केवल ग्रहण आईडीई का उल्लेख करने के लिए इसे वोट करें।

सोम, 18 सितंबर, 2017 को रात 8:52 बजे, फ्रेंको गैलार्डो ग्रैजियो <
सूचनाएं@github.com> ने लिखा:

@bpasero https://github.com/bpasero IMHO, जिस तरह से यूआई राज्यों को संभाला जाता है
(मौसम यह .code- कार्यक्षेत्र फ़ाइल में एक आईडी स्ट्रिंग का उपयोग कर रहा है, या उपयोग कर रहा है
फ़ाइल पथ आईडी के बजाय) पर्याप्त नहीं है।
एक .code-कार्यक्षेत्र फ़ाइल, या उसके किसी भी मूल फ़ोल्डर का नाम बदलना, या बढ़ना
यह चारों ओर है, और UI स्थिति को खोना मेरी राय में पूरी तरह से अनपेक्षित है। मैं
लगता है कि लोग इस बात से अनभिज्ञ हैं कि हूड के तहत कैसे काम होता है
इस कारण के बारे में कोई सुराग नहीं कि उन्होंने अपनी पिछली UI स्थिति खो दी और कैसे प्राप्त करें
वापस।
यह फ़ाइल में फ़ाइलों के पूर्ण पथ से बंधा नहीं होना चाहिए
प्रणाली बिल्कुल!

यह उस स्थिति में लागू होता है जिस तरह से UI स्थिति वर्तमान में फ़ोल्डर पथ से संबंधित है
स्थिर रिलीज के रूप में अच्छी तरह से। मैं उस बारे में बहुत उलझन में था, जब तक कि मैं
कुछ गुगली की।

IMO हम केवल एक फ़ोल्डर के साथ काम कर रहे हैं, तो UI स्थिति बचाई जानी चाहिए
.vscode फ़ोल्डर के अंदर। यदि हम एक बहु-रूट कार्यक्षेत्र के साथ काम कर रहे हैं,
यूआई स्थिति को उसी फ़ोल्डर में एक अलग फ़ाइल के रूप में सहेजा जाना चाहिए
उपयुक्त नामकरण सम्मेलनों (या हो सकता है) का उपयोग करके .code-कार्यक्षेत्र फ़ाइल
उस फ़ाइल के अंदर, हालाँकि मिक्स सेटिंग और स्टेट्स a नहीं हो सकते हैं
अच्छा विचार)।

यदि इसे सही ढंग से लागू किया जाता है, तो यह उपयोगकर्ताओं को पूर्ण पहुंच प्रदान करने की अनुमति देगा
यूआई राज्यों को, दिए गए कार्यक्षेत्र (मल्टी-रूट या) में नए यूआई राज्यों को संलग्न करता है
नहीं), आदि।
मैं विभिन्न कंप्यूटरों के बीच UI स्थिति को सिंक करने में सक्षम होना पसंद करूंगा, कहते हैं
दफ्तर में काम करना, फिर घर जाना, लैपटॉप पकड़ना या जो भी हो
जारी रखने के बिल्कुल जहां मैं छोड़ दिया है।
कार्यक्षेत्र से जुड़े कई यूआई राज्य होने और आसानी से बीच में स्विच करना
विभिन्न विशेषताओं पर काम करते समय उन्हें (मेनू / कीबाइंडिंग / कमांड / आदि)
साथ ही भयानक हो। शायद अलग .code-uistate फाइलें .vscode के अंदर
स्वचालित रूप से सूचीबद्ध, या कई .code-uistate फ़ाइलों के अनुसार उपसर्ग
मुख्य .code- कार्यक्षेत्र, या एक सरणी में सूचीबद्ध।

मैं इस बारे में सोच रहा हूं कि कैसे परियोजनाओं और कार्यक्षेत्रों के विस्तार के रूप में
उदात्त पाठ पर काम करते हैं। एक ही कार्यक्षमता, विभिन्न डिजाइन। इस मामले में
वीएस कोड कार्यक्षेत्र एक उदात्त परियोजना के समान होगा, और अलग
वीएस कोड यूआई राज्य सब्लिम वर्कस्पेस के समान होंगे।

इस मुद्दे के बारे में:

यह अजीब था कि आप फ़ाइल को केवल टाइप करके आईडी को संपादित कर सकते थे
एक और मूल्य

हाँ, पूरी तरह से। आईडी को वहां से हटाना सही विकल्प था।

यह बहुत स्पष्ट नहीं था कि कार्यक्षेत्र फ़ाइल साझा करते समय आईडी का इलाज कैसे किया जाए
दूसरों के साथ (क्या आईडी बदल दी जानी चाहिए? क्या आईडी को यूआईडी होना चाहिए?)

ठीक है, अगर हमें myproject.code-workspace और myproject.code-uistate मिल गया है
फिर यह तय करना है कि उपयोगकर्ता को अपना UI राज्य साझा करना है या नहीं।
कोई और सोच नहीं है कि उस आईडी का क्या मतलब है, यह कैसे उत्पन्न होता है, अगर यह होना चाहिए
साझा करते समय टकराव से बचने के लिए एक UUID
फ़ोल्डर सेटअप और सेटिंग्स साझा करना चाहते हैं? Myproject.code- कार्यक्षेत्र भेजें,
चिंता करने की कोई जरूरत नहीं।
सब कुछ साझा करना चाहते हैं? दोनों फाइलें भेजें।

कार्यक्षेत्र फ़ाइल की प्रतिलिपि बनाना और उसे अलग से खोलना संभव नहीं था
विंडो, आपको पहले कॉपी की गई फ़ाइल में आईडी को बदलना होगा

यदि आप एक ही फ़ोल्डर सेटअप के साथ एक नए UI स्थिति के साथ शुरू करना चाहते हैं और
सेटिंग्स बस अपने .code-कार्यक्षेत्र फ़ाइल की नकल।

परिणामस्वरूप, "कार्यक्षेत्र को सहेजें" कार्रवाई को पूछना होगा
उपयोगकर्ता यदि कॉपी में एक अलग आईडी होना चाहिए या नहीं

यह मुश्किल था क्योंकि उपयोगकर्ता को पता नहीं था कि वह आईडी क्या था। शायद यह
वर्तमान के साथ दो कार्यक्षेत्र "क्लोन कार्यक्षेत्र" के लिए अधिक सरल हो
राज्य "और" नया खाली कार्यक्षेत्र "। लेकिन वह 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 एक प्रोजेक्ट कॉन्फ़िगरेशन में एक ही फ़ाइल में सेटिंग्स के साथ

@ यिम्मी , हां, इसलिए एलिप्से मुझे विभिन्न कार्यक्षेत्रों को खोलने की अनुमति देता है जो हैं
बस फ़ोल्डर जिसमें प्रोजेक्ट्स का प्रतिनिधित्व करने के लिए विभिन्न उप-फ़ोल्डर हैं। मैं
व्यक्तिगत रूप से दो कार्यस्थानों का उपयोग करें, एक ग्रहण आईडीई के विकास के लिए और एक इसके लिए
मेरे सभी काम संबंधित परियोजनाएं। मुख्य लेना यह है कि सेटिंग्स बस हैं
मानव पठनीय फ़ाइलें अपनी संबंधित सेटिंग्स फ़ोल्डर में संग्रहीत - http://wiki.eclipse.org/IRC_FAQ#Where_are_Eclipse_preferences_stored.3F -
यह मेरे लिए बहुत तार्किक है।

किसी भी IDE के लिए एक टिप्पणी / टिप ध्यान देने योग्य है, ऐसी स्थितियों में जहां आपके पास है
स्टैंडअलोन प्रोजेक्ट, workspace/your-awesome-library कहते हैं जो आप चाहते हैं
दूसरे प्रोजेक्ट के हिस्से के रूप में शामिल करें
workspace/my-wiget/libraries/your-awesome-library एक जंक्शनों का उपयोग कर सकते हैं
या OS के आधार पर हार्डलिंकिंग - मुझे यह क्लीनर git / hg सबरेपोज़ से मिलता है
अवधारणाओं।

Tue पर, 19 सितंबर, 2017 को सुबह 10:33 बजे, Yemi Bedu @ P & R सूचनाएं @github.com
लिखा था:

@danielsokolowski https://github.com/danielsokolowski मैं समझता हूँ
सेटिंग्स के लिए एक कार्यक्षेत्र को अधिलेखित करने वाली परियोजना की धारणा। Vscode में आप
सामान्य सेटिंग्स, उपयोगकर्ता सेटिंग्स (सामान्य लेखन से अधिक), और कार्यक्षेत्र है
सेटिंग्स (उपयोगकर्ता या सामान्य लेखन पर)। प्रत्येक परियोजना पहले से ही है
अपने स्वयं के .vscode फ़ोल्डर (कार्यक्षेत्र सेटिंग्स इसमें रहते हैं) का अवसर।
क्या आप एक अतिरिक्त फ़ोल्डर का सुझाव दे रहे हैं, जो परियोजनाओं को केवल घोंसला बना देगा
सेटिंग्स की जानकारी साझा करें? यह एक " समाधान " के समान प्रतीत होगा
दृश्य स्टूडियो शब्दों में फ़ाइल / फ़ोल्डर।

@fgallardograzio https://github.com/fgallardograzio के पास एक प्रोजेक्ट है
एक ही फ़ाइल में सेटिंग्स के साथ परस्पर क्रिया करने वाला कॉन्फ़िगरेशन बल देगा
युग्मन। Ui सामान एक और सुविधा से अलग एक बहुत अच्छा लगता है
यह मुद्दा टिकट। अब जब कि अंदरूनी सूत्रों का कुछ अच्छा लेआउट है
फ़ाइल में अतिरिक्त जड़ें, शायद एक एक्सटेंशन ui के लिए अंतर भर सकता है
अंश। धन्यवाद। अच्छा दिन।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे 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 अलग-अलग रिपॉजिटरी से बना है: वेब फ्रंटेंड, और एपीआई। यह अच्छा होगा यदि मैं इन दोनों फ़ोल्डरों को एक "प्रोजेक्ट" में खोल सकता हूं।

ज़रूर, मैं एक फ़ोल्डर में 2 repos क्लोन करके और उस फ़ोल्डर को खोलकर इसे हल कर सकता हूं लेकिन यह हर मामले के लिए काम नहीं करता है। खासकर यदि आपके पास कई परियोजनाएं हैं जो एक एकल भंडार (यानी एक ही एपीआई को साझा करना) पर निर्भर करती हैं।

यह सुविधा उन लोगों के लिए भी उपयोगी होगी जो प्रलेखन के रूप में कोड का उपयोग करते हैं।

थोड़ी देर के उपयोग vscode-अंदरूनी सूत्रों जो एक ही समय में कई परियोजनाओं का समर्थन के लिए @JamesTheHacker। और आप इसे बेहतर बनाने के लिए अंदरूनी सूत्र संस्करण के साथ जो महसूस करते हैं उसके आधार पर सुविधाओं का सुझाव दे सकते हैं

जब यह जहाज, VSCode संस्करण संभवतः 2.0 से टकरा जाना चाहिए। बस केह रहा हू :)

इस सुविधा से संबंधित त्वरित प्रश्न:

यह सुविधा मौजूदा कार्यस्थान में रिपॉजिटरी के साथ कई फ़ोल्डर्स जोड़ने का समर्थन करती है। क्या यह मोनो-रेपो कॉन्फ़िगरेशन का भी समर्थन करेगा, जिससे मैं एक मोनो-रेपो में कई परियोजनाएँ खोलना चाहता हूँ, लेकिन चूंकि वे एक रेपो में हैं, इसलिए उनके पास अपना कोई रेपो नहीं है। तो एक परियोजना के दृष्टिकोण से, उनके पास .git फ़ोल्डर नहीं है - पूर्वजों में से एक फ़ोल्डर उनके पास है।

आप पूछ सकते हैं कि मोनो-रेपो फ़ोल्डर को एक बड़े फ़ोल्डर के रूप में क्यों नहीं खोला जाए और वहां काम करें? दो उत्तर हैं:

1. (मेरे लिए कम दिलचस्प) मोनो-रेपो में बहुत अधिक परियोजनाएं हैं, और मुझे केवल उनमें से कुछ में दिलचस्पी है।
2. कई प्लगइन्स मान लेते हैं कि किसी प्रोजेक्ट में केवल एक ... प्रोजेक्ट है। उदाहरण के लिए, केवल एक एनपीएम पैकेज। इसलिए वे परियोजना के _root_ में चीजों की तलाश करते हैं। उदाहरण: VSCode के लिए npm प्लगइन, vscode के लिए मोचा प्लगइन, और VSCode में बहुत सारी कार्यक्षमता - उदाहरण के लिए, मैं launch.json में एक पथ निर्दिष्ट नहीं कर सकता जो कि सापेक्ष है वर्तमान फ़ाइल, अर्थात "नोड_मॉडल फ़ोल्डर जो वर्तमान फ़ाइल का निकटतम पूर्वज है"।

इस प्रासंगिक स्पष्टीकरण के बाद, मेरा सवाल सरल है - क्या यह सुविधा उन परियोजनाओं का समर्थन करेगी जो .git फ़ोल्डर उनकी जड़ का पूर्वज है? यदि ऐसा है, तो मोनो-रेपो में इस सुविधा का उपयोग करना संभव होगा।

@borekb हाँ। मुझे नहीं पता कि Microsoft के लोग अपने संस्करणों को कैसे प्रबंधित करते हैं, लेकिन मुझे लगता है कि यह एक प्रमुख के लिए एक विशाल पर्याप्त विशेषता है

इस प्रासंगिक विवरण के बाद, मेरा सवाल सरल है - क्या यह सुविधा उन परियोजनाओं का समर्थन करेगी जो .it फ़ोल्डर उनकी जड़ का पूर्वज है? यदि ऐसा है, तो मोनो-रेपो में इस सुविधा का उपयोग करना संभव होगा।

यह पहले से ही काफी लंबे समय से समर्थित है, अगर आप बस गिट रेपो का एक सबफ़ोल्डर खोलते हैं।

+1

उदात्त और एटम आप इसे करना चाहिए। कोई बेहतर कारण नहीं। यह नया एमएस है, इसे लोगों तक पहुंचाएं, मुझे आप पर पूरा भरोसा है। :)

नमस्ते,
@inestyne यदि आप पहले पोस्ट पढ़ कृपया तरह @Jeyanthinath से आप का उपयोग कर के बारे में पता किया जाएगा VSCode अंदरूनी पहले से ही इस सुविधा का मूल्यांकन करने के लिए। यहां तक ​​कि जांच के लिए एक रोडमैप भी है। तो कृपया उत्पाद का उपयोग करें और प्रतिक्रिया दें इससे पहले कि वह स्थिर हो जाए इसलिए हम सभी को सर्वोत्तम उत्पाद प्राप्त हो सके। धन्यवाद। अच्छा दिन।

बस थ्रेड पढ़ें और अंदरूनी सूत्र OMG का उपयोग करें। मैं अनसब्सक्राइब कर रहा हूं ... आप ट्रोल करते हैं जो नहीं पढ़ता है वह असंभव है। धन्यवाद @ पीआर-यमिबेदु

संवेदनशील

चूँकि यह धागा 2 साल लंबा है, और यह विशेषता अब अंदरूनी सूत्र के निर्माण में लगती है, तो क्या इस धागे को चिह्नित करने का कोई तरीका है ताकि शीर्ष से पूरे धागे को पढ़ने की तुलना में अधिक स्पष्ट हो?

एक चीज जो गायब है वह सीएलआई से एक नए कार्यक्षेत्र के साथ एक नई विंडो खोलने की क्षमता है।

@jearle code-insiders <folder> साथ पहले की तरह एक नई विंडो / कार्यक्षेत्र बनाया जाना चाहिए, नहीं?
फ़ोल्डर को वर्तमान विंडो में जोड़ने के लिए code-insiders -a <folder> की आवश्यकता होती है।

@ जयनाथनाथ धन्यवाद! @JamesTheHacker के रूप में एक ही काम कर रहा है और यह मेरी मदद करेगा!

@Tyriar मैं चाहता था कि मुझे निम्नलिखित कमांड निष्पादित करनी है

code .; code -a .

code . एक गैर कार्यक्षेत्र के रूप में फ़ोल्डर को खोलता है, और फिर code -a . संलग्न होता है यह एक कार्यक्षेत्र के रूप में पहले खुली खिड़की के लिए स्व है जो मुझे एक ही फ़ोल्डर को एक से अधिक बार खोलने की अनुमति देता है।

मुझे व्यक्तिगत रूप से लगता है कि इसे भी बदलने की जरूरत है। मैं आयनिक और एक कस्टम सर्वर के साथ दो अलग-अलग गिट रिपॉज में काम कर रहा हूं और यह बहुत आसान नहीं है। कम से कम दो अलग-अलग "प्रोजेक्ट टैब" खोलने की क्षमता या कुछ महान होगा।

मैंने एटम से स्विच किया क्योंकि बगिया कितनी धीमी और धीमी थी।

@ डार्क-स्वोर्ड्समैन आप मैक पर nativeTabs सक्षम कर सकते हैं

क्या Windows पर यह संभव है

संपादित करें: मैंने पूरी तरह से सेटिंग फ़ाइल के माध्यम से खोज की और उसके लिए कोई विकल्प नहीं है। इसलिए मैं पूछ रहा हूं।

Edit2: इसके अलावा, vs insiders को सक्षम करने के बारे में कोई स्पष्ट संसाधन नहीं है

नमस्ते,
@ डार्क-स्वोर्ड्समैन आप वीएस अंदरूनी सूत्रों को सक्षम नहीं करते हैं। यह VSCode की एक बिल्ड है जिसमें कुछ अतिरिक्त विशेषताएं हैं जो स्थिर करने के लिए अंतिम रूप से तय नहीं की गई हैं और एक तरह से आपको काम करने के लिए अतिरिक्त संपादक नाम स्थान देता है (आप सेटिंग्स या एक्सटेंशन के टकराव के बिना उन्हें कंधे से कंधा मिलाकर स्थापित कर सकते हैं)। धन्यवाद। अच्छा दिन।

मल्टी-रूट वर्कस्पेस के लिए समर्थन अब स्थिर रिलीज में डिफ़ॉल्ट रूप से सक्षम है।

कृपया इसके साथ आने वाली सभी विशेषताओं की पूरी व्याख्या के लिए हमारे दस्तावेज़ देखें। एक्सटेंशन लेखकों को हमारे विकी को संदर्भित करना चाहिए जो मल्टी-रूट वर्कस्पेस के लिए आपके एक्सटेंशन को तैयार करने के लिए नए एक्सटेंशन एपीआई की व्याख्या करता है। हमें खुशी है कि काफी कुछ एक्सटेंशन पहले ही नए मल्टी-रूट एपीआई को अपनाना शुरू कर चुके हैं, इसके लिए धन्यवाद!

कृपया मल्टी-रूट के लिए मुद्दों को दर्ज करने में संकोच न करें क्योंकि आप उनका सामना कर रहे हैं, हम अभी भी भविष्य में मल्टी-रूट वर्कस्पेस के साथ काम करने के लिए ट्विक्स बनाने और एक्सटेंशन के लिए अतिरिक्त एपीआई प्रदान करने की योजना बना रहे हैं।

यह बहुत अच्छा है, लेकिन यह कब उपलब्ध होगा? आप कहते हैं कि यह स्थिर बिल्ड में है, लेकिन मेरे पास नवीनतम स्टेबल बिल्ड (1.17.2) है और इसे अपडेट नहीं किया जा सकता है। इसके अलावा, प्रलेखन में जिसे आपने अभी संदर्भित किया है, यह कहा कि यह अभी भी इनसाइडर के निर्माण में है और जल्द ही स्थिर रिलीज में होगा।

मैं समझता हूं कि अगली बिल्ड जारी होने से पहले यह एक छोटा हो सकता है, लेकिन मैंने इस अधिसूचना को उपलब्ध होने की उम्मीद करते हुए देखा।

संपादित करें: मैं अपनी अधीरता के लिए माफी माँगता हूँ। मैं बस एक नया विंडो खोलने का प्रयास कर रहा था मैनुअल तरीके से (.exe फिर से कॉल करें) और यह काम नहीं कर रहा था, लेकिन फ़ाइल> ओपन विंडो में नहीं दिख रहा था। यह अभी के लिए काम करेगा। अगले बिल्ड की रिलीज़ की प्रतीक्षा कर रहा है। 👍

@bpasero कृपया इस # 35849 खुले मुद्दे को बंद करें क्योंकि अपेक्षित कार्यक्षमता ने इस # 396 सुविधा के रूप में किया है।

बस एक त्वरित प्रश्न। क्या यह संभव है, जब मैंने अधिक फ़ोल्डर खोले हैं, जो फ़ोल्डर मैं संकलित करना चाहता हूं? फिलहाल यह हमेशा स्थिर संस्करण में पहला है।

EDIT: यह PlatformIO एक्सटेंशन के निर्माता के लिए हो सकता है, लेकिन मैं दोनों पक्षों से पूछ रहा हूं। शायद ज़रुरत पड़े...

@DJManas ऐसा लगता है कि यह उस विस्तार पर निर्भर है जिसे आप तय करने के लिए उपयोग कर रहे हैं, इसलिए आपको एक्सटेंशन के लेखक से पूछना चाहिए।

@bpasero ठीक है, मैंने समानांतर में किया, उत्तर के लिए धन्यवाद।