Vscode: खुली फाइलों के लिए उचित टैब

+1

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

क्या कस्टम एक्सटेंशन के माध्यम से टैब जोड़ना संभव होगा?

नहीं, यह वर्तमान में विस्तार से संभव नहीं है (यह भी देखें

+1

: +1:

: +1:

+1

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

उन लोगों के लिए जो टैब गायब हैं, क्या आपने खुली हुई फाइलों के इतिहास में नेविगेट करने के लिए Ctrl+Tab का उपयोग करने की कोशिश की है?

हाँ। लेकिन फ़ाइल बंद होने के बाद भी फ़ाइल Ctrl+tab संदर्भ में बनी हुई है। अनुभव उदात्त / परमाणु के समान नहीं है।

@snehilmodani सही है, क्या यह मदद करेगा कि सूची केवल वही दिखा रही है जो आपके पास एक्सप्लोरर के काम करने वाले फाइल अनुभाग में है? क्या आप कम से कम काम करने वाली फाइलों की सूची के साथ काम कर सकते हैं?

वह महान होगा!

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

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

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

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

@bpasero मैं ctrl+tab एक शॉट दूंगा, मुझे बस यह महसूस हुआ कि इसका उपयोग पिछली फ़ाइल में जाने के लिए किया जा सकता है, जो कि मैं चाहता था और अब तक देखा नहीं था। तो यह अच्छा है।

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

हां, Ctrl+Tab सभी फाइलों पर काम करने के इतिहास में वापस नेविगेट करने के बारे में है। आप Ctrl कुंजी दबाकर रख सकते हैं और 1 फ़ाइल से परे वापस जाने के लिए Tab दोहराया जा सकता है।

Ctrl+tab होना एक अद्भुत बात है और मैं पूरी तरह से इसका प्रशंसक हूं। यह कुछ ऐसा है जिसे परमाणु भी याद करता है।

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

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

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

मैं एक सामाजिक प्रयोग का हिस्सा बनना पसंद करूंगा जहां आप हमारे संपादकों के साथ हमारे क्लॉट किए गए लेआउट आधारित बातचीत से छुटकारा पाने के लिए हमें समझाने की कोशिश कर रहे हैं।

हां मुझे लगता है कि हमें इस 2016 की तरह कुछ करने की आवश्यकता होगी। @stevencl fyi

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

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

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

कुछ लोग वास्तव में उन्हें प्रबंधित करते हैं और दूसरों के लिए दाईं ओर करीब टैब है।

प्रतिक्रिया के लिए बहुत बहुत धन्यवाद।

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

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

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

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

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

मुझे साइन अप!

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

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

यह ध्यान में रखने योग्य है कि हर कोई एक वेब डेवलपर नहीं है, मुझे लगता है कि पैटर्न और वर्कफ़्लो अलग-अलग भाषाओं और एप्लिकेशन की शैलियों के लिए थोड़ा भिन्न होते हैं। एक देशी डेवलपर के रूप में, संबंधित फ़ाइलों का एक सेट दिखाई देना आम है; cpp + h , शायद यह भी एक inl , और आप आमतौर पर अलगाव में केवल एक फ़ाइल पर काम नहीं करते हैं। मेरे पास अक्सर कोड के बगल में दिखाई देने वाला डिस्सैड व्यू होता है। मेरे संपादक वातावरण में 2 मॉनिटर हैं, किसी भी समय 4 फाइलें दिखाई देती हैं, और मैं उससे अधिक प्रतिबंधात्मक वातावरण में काम करने के लिए संघर्ष करूंगा।
मुझे एक टैब को पकड़ने और एक छोटी सी फ्लोटिंग विंडो में चीरने में भी याद आती है, जिसे मैं अक्सर 'हमेशा शीर्ष पर' सेट करता हूं, जिसे आम तौर पर एक संदर्भ बिंदु, या कुछ और जो मैं बहुत कॉपी कर रहा हूं / का उपयोग करता है। के लिए / से pasing।

अभी उदाहरण के लिए, मैं कुछ विरासत कोड को फिर से भरने और सरल बनाने की कोशिश कर रहा हूं; फ़ाइलों का मेरा वर्तमान काम कर रहा है ... घटक.कंप, घटक.एच, कंपोनेंट.लि, कंपोनिमप्ल.कंप, कंपोनिमप्ल.एच, इकोम्पोनेंट.एच। वह 6 फाइलें है! और मैं परिधि पर कुछ अन्य फ़ाइलों के सामयिक ट्विक से बच नहीं सकता। जब मैं प्रोजेक्ट की उस शैली (2 फ़ाइलों के बीच फ़्लिप) पर काम कर रहा हूँ, तो मैं उदारता से ctrl-tab का उपयोग करता हूँ, लेकिन इस संदर्भ में / कोडबेस पर, मैं बस टैब के बिना काम नहीं कर सकता।

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

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

मैं इन फ़ोकस अध्ययनों का हिस्सा बनने के अवसर की सराहना करता हूँ!

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

यह मेरे लिए मामला है। वास्तव में मैं टैब के बिना काम नहीं कर सकता। मैं वर्षों से टैब सिस्टम के साथ काम कर रहा हूं, और उनके बिना, मैं वास्तव में खो गया हूं। यह एक कारण है कि मैं वास्तव में कोड का उपयोग नहीं कर रहा हूं।

कई स्थापित डिजाइन स्थापित हैं क्योंकि वे अच्छे और कुशल हैं, इसलिए नहीं कि वे पुराने हैं और अधिक फैशनेबल होने के लिए अद्यतन करने की आवश्यकता है :)

: +1:

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

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

यहां तक ​​कि अगर यह डिफ़ॉल्ट रूप से नहीं है, तो उपयोगकर्ता को कुछ विकल्प के माध्यम से टैब सुविधा को सक्रिय करने का विकल्प देना मेरे लिए लगभग अच्छा होगा।

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

मेरे लिए यह टैब की उपस्थिति इतनी नहीं है जितना कि उनके व्यवहार से मुझे याद आता है। (उदाहरण के लिए, आप वीएस कोड की तरह दिखने के लिए उदात्त पाठ प्राप्त कर सकते हैं जिसमें आप टैब बार को छिपा सकते हैं और इसके बजाय साइडबार में खुली फ़ाइलों को दिखा सकते हैं ... लेकिन वे अभी भी टैब की तरह ही व्यवहार करते हैं।)

पहली बात जो मैं कभी वीएस कोड के साथ करता हूं, वह है अपनी क्लोज फाइल और क्लोज एक्टिव एडिटर कीबोर्ड शॉर्टकट्स की अदला-बदली, ताकि ctrl + W वास्तव में एक फाइल को बंद कर दे जब मैं इसे दबाऊं, बजाय इसके कि इसे काम करने वाली फाइलों में छोड़ दिया जाए और ctrl / tab को बंद कर दिया जाए।

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

इसके अतिरिक्त, कार्यशील फ़ाइलों के बीच ctrl + टैब सबसे हाल के क्रम में काम करता प्रतीत होता है, जैसा कि टैब के विपरीत होता है जो आमतौर पर उस क्रम में काम करते हैं जो वे दिखाई देते हैं या व्यवस्थित होते हैं। (मैंने कुछ संपादकों को दोनों का समर्थन करते देखा है।)

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

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

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

Btw वहाँ एक विस्तार है कि - एक बार जब आप एक संपादक को बंद कर देते हैं - काम करने वाली फ़ाइलों से अगले एक को खोलता है। यदि आप कीबाइंडिंग को @kfranqueiro के रूप में बदलने के साथ इमो मिलता है।

यहाँ लिंक है: https://marketplace.visualstudio.com/items/bigous.file-smart-reopener-sscode

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

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

क्या यह है कि लोग वास्तव में टैब में फाइलें खोलना चाहते हैं, उन्हें चारों ओर ले जाते हैं और अंततः उन्हें बंद कर देते हैं?

हाँ

क्या यह इसलिए है क्योंकि आप इसके लिए अभ्यस्त हैं या ऐसा करने में वास्तव में कोई मूल्य है?

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

क्या मूल्य एक सक्रिय कामकाजी फ़ाइल सेट करने में सक्षम है जिसे आप बाद में कुछ नया शुरू करने के लिए खारिज कर सकते हैं?

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

मुझे आश्चर्य है कि टैब रखने में इतना अच्छा क्या है कि आप प्रतिनिधित्व के दूसरे तरीके से हासिल नहीं कर सकते।

एक अलग दृष्टिकोण से; अंतरिक्ष उपयोग पर विचार करें। वहाँ _already is_ कोड विंडो के शीर्ष पर एक टैब है, यह वह जगह है जहाँ फ़ाइल नाम है, इसमें सिर्फ नाम के चारों ओर टैब आयत नहीं है (यह टैब की तरह भी व्यवहार करता है; यदि आप मध्य-क्लिक करते हैं, तो यह बंद हो जाता है!)। कोड विंडो के ऊपर फ़ाइल नाम के दाईं ओर वर्तमान में रिक्त स्थान है (जहाँ टैब होना चाहिए)।
कार्यक्षेत्र के शीर्ष पर बाईं ओर 'कार्यशील फ़ाइलें' सूची है; यह दोगुना बर्बादी वाला स्थान है क्योंकि इसे बस अस्तित्व की आवश्यकता नहीं है, यह स्थान उस खाई में ले जाया जा सकता है जहां टैब आमतौर पर होते हैं, उस व्यर्थ स्थान को भरना।

मुझे अंतरिक्ष उपयोग और अभ्यस्त प्रवृत्ति से भी अधिक व्यावहारिक अंतर लगता है; मुझे उस संपादक की खिड़की से जुड़े टैब को पसंद करना है जो वे करने के लिए बाध्य हैं। मेरे पास आमतौर पर कम से कम 2, 3, अक्सर 4 कोड की खिड़कियां खुली होती हैं (बनाम-उचित), और प्रत्येक में संबंधित टैब की एक जोड़ी होती है। शायद एक विंडो में मेरे पास widget.cpp/.h , और दूसरे में मेरे पास gizmo.cpp/.h/.inl । ये टैब तार्किक रूप से उस कोड विंडो से जुड़े होते हैं जिससे वे जुड़े होते हैं, और मुझे लगता है कि मनभावन है।

और मैं इस तर्क को स्वीकार नहीं कर रहा हूं कि हर किसी को टैब का उपयोग किया जाता है :)। फ़ाइलों को सहेजने के लिए बहुत से लोगों का उपयोग किया जाता है और अभी भी ऑटो सेव क्षमता वाले संपादक हैं और लोग इसे पसंद करते हैं।

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

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

यह सिर्फ नियमित टैब से बेहतर नहीं है, और इसलिए अनुकूलन के लिए कोई आकर्षक कारण नहीं है ... मेरी राय में :)

+1 @ तुर्की

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

हम फ़ाइल जानकारी और कार्यों को दिखाने के लिए संपादक के ऊपर स्थान आरक्षित करते हैं। कोई यह तर्क दे सकता है कि यह स्थान टैब के लिए आवश्यक स्थान है। लेकिन टैब के खिलाफ मेरा तर्क यह है कि आम तौर पर क्षैतिज स्थान काम करने वाली फ़ाइलों की सूची दिखाने के लिए पर्याप्त नहीं है क्योंकि आप जल्दी से इसे समाप्त करते हैं:

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

अब, स्पष्ट रूप से काम करने वाली फ़ाइलों में एक समान समस्या है, बस दूसरे आयाम में। यही कारण है कि हम टीम में आमतौर पर हर चीज के लिए Ctrl+Tab करते हैं और इस बात की परवाह नहीं करते हैं कि क्या खोला गया है या नहीं।

संक्षेप में: टैब को बदलने के लिए काम करने वाली फाइलें हमारा जवाब नहीं है, बल्कि यह काम करने वाली फाइलों और Ctrl+Tab का संयोजन है। और हमारी टीम Ctrl+Tab का उपयोग करते हुए कम से कम 100% है और कुछ नहीं।

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

जब यह लागू होता है तो मैं बहुत उदार Ctrl-Tab उपयोगकर्ता हूं, लेकिन जब तक आप सक्रिय रूप से 2 या 3 से अधिक फ़ाइलों का संपादन नहीं कर रहे हैं, तब तक आप Ctrl-Tab का उपयोग नहीं कर सकते।
मुझे संदेह है कि इस मामले पर आपकी राय आपके विशेष प्रोजेक्ट के प्रति काफी पक्षपाती हो सकती है, और इसमें एक भाषा पूर्वाग्रह भी शामिल हो सकता है। C / C ++ में कार्यशील फ़ाइलों की विशिष्ट संख्या दोगुनी या तिगुनी हो जाती है जब आप स्वीकार करते हैं कि .h , और मेरे मामले में, अक्सर .inl हर .cpp .inl पूरक होता है। इस परिदृश्य में Ctrl-Tab कम प्रभावी है, और आप टैब प्रबंधन के साथ संयोजन के रूप में, Ctrl- ~ का उपयोग करते हैं (cpp / लॉग को टॉगल करें; जिसे मैंने एक सुविधा अनुरोध भी पोस्ट किया है)।
या जावा पर विचार करें, जहां हर वर्ग - चाहे वह कितना भी छोटा हो - उसे अपनी फाइल में रहना आवश्यक है।

मेरे वर्तमान दिन-प्रतिदिन में मेरे पास अक्सर 10 फाइलों का एक सेट होता है, जब मैं इस तरह से काम कर रहा होता हूं तो Ctrl-Tab का कोई फायदा नहीं होता है। सबसे व्यावहारिक वर्कफ़्लो 2-4 संपादक विंडो है, और प्रति विंडो टैब की एक जोड़ी है। मैंने इस लेआउट को इसलिए नहीं चुना क्योंकि मैं इसे पसंद करता हूं; यह केवल उभरा, क्योंकि यह इस विशेष कार्य के लिए सबसे कुशल कार्यक्षेत्र लेआउट है।

+ 1
मैं आमतौर पर संपादक को विभाजित करता हूं और टैब को बंद करना 10+ कामकाजी फाइलों की तुलना में थोड़ा अधिक सहज है।

मैं भी आमतौर पर केवल फाइलों के एक सबसेट पर काम कर रहा हूं और उन कामों को रखना पसंद करता हूं। 5/5 व्यक्तिगत रूप से मेरे लिए 10 की सूची की तुलना में प्रबंधन करना आसान है। मैं उनके बीच लगातार सक्रिय रूप से आगे बढ़ रहा हूं। टैब्स भी इसमें मदद करते हैं कि एक दृश्य संकेत है कि आपके पास बहुत अधिक खुला है - @bpasero द्वारा दिखाया गया 'टैब नरक'।

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

एक सरल उदाहरण .cpp और '.h' टैब के साथ होगा, यह विंडो के शीर्ष पर केंद्रित दोनों क्लिक होंगे, जबकि कार्यशील फ़ाइलों के साथ यह कार्यशील फ़ाइलों के साथ 3-4 क्लिक होंगे, जिनके लिए आपको चयन करना होगा। प्रश्न में संपादक और फिर संपादित करने के लिए नई फ़ाइल का चयन करें।

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

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

मैं उत्सुक हूं कि टैब लागू करने पर इतना धक्का क्यों है। तकनीकी रूप से यह मुश्किल नहीं है और वहां पहले से ही लागू फाइलें काम कर रही हैं; क्यों नहीं दोनों और उपयोगकर्ताओं को निर्णय लेने दें?

यह लगभग स्पेस v। टैब की तरह लगता है, 2.0

मैं उत्सुक हूं कि टैब लागू करने पर इतना धक्का क्यों है। तकनीकी रूप से यह मुश्किल नहीं है और वहां पहले से ही लागू फाइलें काम कर रही हैं; क्यों नहीं दोनों और उपयोगकर्ताओं को निर्णय लेने दें?

यह लगभग स्पेस v। टैब की तरह लगता है, 2.0

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

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

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

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

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

यह एक वैचारिक बहस नहीं है - हम वास्तव में न्यूनतम सौंदर्यवादी बनाए रखने की कोशिश कर रहे हैं जो हमें विश्वास है कि एक हल्का, शक्तिशाली अनुभव प्रदान करता है। हम उत्पाद में नए यूआई और यूएक्स को पेश करने के बारे में बहुत सावधानी बरत रहे हैं।

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

मुझे उम्मीद है कि यह इस पर हमारे दृष्टिकोण को समझाने में मदद करता है। और मैं फिर से माफी मांगता हूं कि यह देखने के लिए कि हम नाभि टकटकी लगा रहे हैं और इस बारे में कुछ नहीं कर रहे हैं।

धन्यवाद @stevencl , यह अच्छा है कि यह कम से कम रडार पर है और कुछ मंथन चल रहा है।

टैब जोड़ने के साथ हमारी चिंता यह है कि यह उन समस्याओं का एक और सेट पेश करता है जो उपयोगकर्ता को कोड के बजाय UI पर ध्यान केंद्रित करने की आवश्यकता होती है।

मुझे लगता है कि मुझे अभी कोड के बजाय UI पर ध्यान केंद्रित करने की आवश्यकता है, इसलिए यह तर्क दोनों तरीकों को काट देता है। :)

कई उपयोगकर्ता अक्सर कई टैब खोलते हैं जिसमें वे फाइलें होती हैं जिनकी उन्हें अब आवश्यकता नहीं है

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

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

@stevencl , आपकी प्रतिक्रिया के लिए धन्यवाद। मैं आपके कुछ बिंदुओं पर टिप्पणी करना चाहूंगा:

[...] हम फ़ाइलों के प्रबंधन के लिए वर्तमान अनुभव के साथ मुद्दों से अवगत हैं और कई बदलाव हैं जो हम अनुभव को बेहतर बनाने के लिए करना चाहते हैं।

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

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

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

टैब जोड़ने के साथ हमारी चिंता यह है कि यह उन समस्याओं का एक और सेट पेश करता है जो उपयोगकर्ता को कोड के बजाय UI पर ध्यान केंद्रित करने की आवश्यकता होती है।

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

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

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

फिर भी, कार्यशील फ़ाइलों की सूची अभी भी समस्या का समाधान नहीं करती है। बहुत सारी कामकाजी फाइलें सूची को स्क्रॉल करने का कारण बनती हैं और सूची का विस्तार नहीं किया जा सकता है। तो अंततः स्क्रॉलिंग टैब के अनुसार, आप अधिक तेज़ी से काम करने वाली फ़ाइलों की सूची को नीचे स्क्रॉल करने जा रहे हैं।

[...] हम वास्तव में न्यूनतम सौंदर्य को बनाए रखने की कोशिश कर रहे हैं, जो हमें विश्वास है कि एक हल्के, शक्तिशाली अनुभव प्रदान करता है। हम उत्पाद में नए यूआई और यूएक्स को पेश करने के बारे में बहुत सावधानी बरत रहे हैं।

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

[...] मैं फिर से माफी माँगता हूँ कि यह देखने के लिए कि हम नाभि टकटकी लगा रहे हैं और इस बारे में कुछ नहीं कर रहे हैं।

यह निश्चित रूप से मेरी नहीं है, इसलिए वहां कोई चिंता नहीं है। जिन कारणों के लिए मैंने पहले ही कहा था, इस बारे में एक स्वस्थ बातचीत निश्चित रूप से केवल उस बड़े उद्देश्य को बढ़ा सकती है जो वीएस कोड का यूआई / एक्स है।

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

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

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

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

धन्यवाद, मैं इस बातचीत के अवसर की सराहना करता हूं।

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

विजुअल स्टूडियो के डिज़ाइन पर कई वर्षों तक काम करने के बावजूद मैंने यूएक्स समस्याओं को देखा है जो टैब का कारण बन सकता है। मैंने विजुअल स्टूडियो में पूर्वावलोकन टैब अनुभव पर काम करते हुए 18 महीने बिताए जो कि 'टैब नरक' समस्या को कम करने का प्रयास है जो @bpasat ऊपर वर्णित है।

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

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

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

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

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

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

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

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

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

टैब के लिए +1। सवाल- आप इसे विजुअल स्टूडियो बंडल से क्यों नहीं हटाते? देखिए फिर क्या होता है ...

टैब के लिए +1! कृपया इसे भविष्य के अपडेट में लागू करें।

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

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

हर कोई अलग है इसलिए एक विकल्प होना बहुत अच्छा होगा। भले ही मैं उनके बिना ठीक काम कर सकता हूं, लेकिन मुझे इसमें कोई दिक्कत नहीं होगी और संभवत: वे वीएस पूर्ण का उपयोग करने के कई वर्षों में कुछ का उपयोग करेंगे। लगता है जैसे वे पहले से ही बैकलॉग पर हैं - धन्यवाद!

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

Ctrl + tab एक महत्वपूर्ण क्रिया है, और टैब दृश्य क्रिया है, जो बहुत तेज़ है।

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

यह इस तथ्य के साथ संयुक्त है कि जब आप किसी फ़ाइल को बंद करते हैं / एक नया "वर्किंग" पर ध्यान केंद्रित करते हैं, तो फ़ाइल एक्सप्लोरर आपके अंतिम स्थान पर रहने के बजाय खुली हुई फ़ाइल के लिए MOVES बनाता है।

मैं समझता हूं कि "4 साल के लिए टैब के बिना आपने इसका उपयोग किया है" तब से वे आपके लिए चिंतित नहीं हैं, इसलिए कुछ भी जो Ctrl + Tab दायरे से बाहर जाता है उसे प्रोग्राम का उपयोग करने के एक अजीब तरीके के रूप में देखा जाता है।

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

: +1:

मैं टैब के साथ बहुत अधिक उत्पादक हूं! मैं एटम का उपयोग करता हूं क्योंकि मैं Google क्रोम का उपयोग करता हूं (Ctrl + 1 पहले टैब के लिए, Ctrl + 5 आदि Ctrl + Tab, Ctrl + Shift + टैब)।

काम करने वाली फाइलें मुझे कम उत्पादक बनाती हैं और मैं हमेशा इसका इस्तेमाल करने के बाद थोड़ा निराश महसूस करता हूं।

तो कृपया, टैब लागू करें।

टैब बहुत उपयोगी होंगे, +1

: +1:

@MadSpindel "वर्किंग फाइल्स मुझे कम प्रोडक्टिव बनाती हैं और मैं इसे इस्तेमाल करने के बाद हमेशा थोड़ा निराश महसूस करता हूं।" 1000% सहमत हूँ ... ऐसा लगता है कि हम किसी के लिए एक बिंदु या कुछ बनाने के लिए मजबूर नहीं हैं। हमें यह पसंद नहीं है, यदि आप ऐसा करते हैं, तो कृपया इसे हमारे लिए वैकल्पिक बनाएं।

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

: +1: और मैं @sitefinitysteve से सहमत हूं। यदि टीम टैब नहीं होने पर जोर देती है, तो कम से कम एक्सटेंशन एपीआई में सुधार करें ताकि इसे तीसरे पक्ष द्वारा जोड़ा जा सके।

यहां वह जगह है जहां टैब महत्वपूर्ण हैं- हमें एक और लापता सुविधा के लिए एक पल वापस करना होगा:

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

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

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

@riclf पर यह हाजिर है।

मेरे पास आमतौर पर 3 ऊर्ध्वाधर कॉलम खुले हैं, HTML, JS और CSS बाएं से दाएं।

उदात्त में मेरे पहले कॉलम के ऊपर मेरे सभी html टैब थे, दूसरे कॉलम के ऊपर टैब के रूप में सभी जेएस फाइलें आदि। टैब में एक संदर्भ है और मुझे पता है कि मैं गलत कॉलम में गलत फाइल खोलने वाला नहीं हूं।

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

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

Microsoft टीम के लिए एक प्रश्न। यदि आपके पास एक विभाजन दृश्य है, तो आपको यह कैसे पता चलेगा कि "वर्किंग फाइल्स" में एक फाइल किस कॉलम से संबंधित है? यह तब सरल होता है जब टैब अपने संबंधित कॉलम से ऊपर होते हैं।

बस मेरा 2 सी।

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

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

एक mvim उपयोगकर्ता के रूप में, मेरे पास TDD फ़ाइलों के कई सेट खुले हैं, और उनके बीच टैब है। उदाहरण के लिए, मैं कोणीय + परीक्षण, सर्वर + परीक्षण, ककड़ी या व्यवहार + लिपियाँ। मैं एक फ़ाइल तक पहुँचने के लिए टैब नहीं करना चाहता, लेकिन खुली फ़ाइलों का एक संयोजन। मैंने एक टाइपस्क्रिप्ट प्रोजेक्ट के लिए 3 महीने के लिए VSCode पर स्विच किया, क्योंकि इसमें वास्तव में सर्वश्रेष्ठ-इन-क्लास / अद्भुत टाइपस्क्रिप्ट समर्थन था। हालाँकि, जैसे ही मैं एक गैर-टाइपस्क्रिप्ट प्रोजेक्ट में गया, मैंने पाया कि मैंने इसकी सामान्य उद्देश्य खोज, नेविगेशन और प्रतिस्थापन क्षमताओं की तुलना सीधे mvim से की है और मुझे यह कहने के लिए खेद है कि मैं तेजी से (यानी, तुरंत) अपने पूर्व संपादक को वापस कर दिया। मेरे पास 27 "Apple सिनेमा डिस्प्ले है और यदि संभव हो तो एक बड़ा डिस्प्ले मिलेगा। मेरे पास बहुत सारे टैब और फ़ाइल-जोड़े के लिए बहुत जगह है, और मेरे संपादक द्वारा उस स्थान का उपयोग करने में सीमित होने के लिए एक सम्मोहक कारण नहीं है। मैं एक समय में सिर्फ एक फ़ाइल से निपटना नहीं चाहता - मैं कई खोलना चाहता हूं, और टैब से टैब तक प्रवाह को ट्रैक करना चाहता हूं।

मैंने दो सप्ताह पहले विजुअल स्टूडियो कोड एक और कोशिश की। मैं वास्तव में सुखद आश्चर्यचकित था जब बस कुछ ही फाइलों के साथ मिलाना। लेकिन जब मैंने एक मुट्ठी भर फाइलों के साथ एक वास्तविक (बड़ी) परियोजना पर काम करना शुरू किया, तो टैब की कमी बहुत कष्टप्रद हो गई। _Working Files_ ने मुझे सूट नहीं किया और इसने मुझे धीमा कर दिया। 3 दिनों के बाद मैं इससे इतना नाराज हो गया कि मैं उदात्त पाठ पर वापस चला गया। मेरे पास काम पर दो 24 "स्क्रीन (विंडोज), एक 27" मैक घर पर है और इसमें आसानी से 20 टैब खुल सकते हैं और फिर भी भेद कर सकते हैं कि कौन सी फाइल है। मेरे मामले में टैब के लिए स्क्रीन रियल एस्टेट की बहुत सारी। _You_ पहले से ही फ़ाइल का फ़ाइल नाम दिखा रहा है जो संपादक में खोला गया है। फ़ाइल नाम के दाईं ओर का सभी स्थान अप्रयुक्त है (विंडो के दाईं ओर के आइकन को छोड़कर) और टैब से भरा जा सकता है (जो कि Sublime Text भी करता है)। मैं कहता हूं कि उपयोगकर्ताओं को _Working Files_ और / या फ़ाइल टैब के साथ काम करने का विकल्प दें। अभी के लिए, मैं उदात्त पाठ और विज़ुअल स्टूडियो एंटरप्राइज के कॉम्बो पर वापस जा रहा हूं। जब टैब जोड़े जाएंगे तो मैं पुनर्विचार करूंगा।

Working Files विकल्प के लिए, मुझे फ़ाइल का चयन करने के लिए साइड बार को टॉगल करना होगा (जैसा कि मैं इसे कोड के विस्तारित दृश्य के लिए छिपाकर रखता हूं)। और Ctrl+P और Ctrl+tab विकल्प भी उपयोगकर्ता के अनुकूल नहीं हैं।

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

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

जब मैं वीएस कोड के लिए नया था तो मैं वास्तव में टैब से चूक गया। तब मैंने ctrl + टैब की खोज की और मुझे अब उनकी आवश्यकता नहीं है।

मैं कई महीनों से अपने प्राथमिक संपादक बनाम vscode (जो कि ज्यादातर हिस्सों में कमाल का है) को बनाने की कोशिश कर रहा हूं, लेकिन टैब की कमी मुझे परेशान करती है और मेरी उत्पादकता को नुकसान पहुंचा रही है (मैं उन लोगों में से एक हूं जो खुले टैब के सेट को सक्रिय रूप से प्रबंधित करते हैं। अन्य संपादकों में)। Ctrl + tab टैब के लिए एक प्रतिस्थापन नहीं है।

यह स्पष्ट है कि vscode टीम इसके खिलाफ पक्षपाती है, और वर्तमान में उपयोगकर्ताओं को "समझाने" का लक्ष्य है कि उन्हें वास्तव में टैब की आवश्यकता नहीं है। लेकिन यह उसी प्रकार की सोच है जो विंडोज 8 से स्टार्ट मेनू को हटाने की ओर ले जाती है (हम सभी जानते हैं कि यह कैसे समाप्त हुआ)।

@Pesho बिल्कुल!

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

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

@pleerock आप IDE आज़माने वाले नहीं हैं क्योंकि इसमें टैब नहीं है!] (ऊँ) वेव्यूव्यूव्यू। वे टैब जोड़ना नहीं चाहते हैं क्योंकि टैब व्यर्थ हैं, क्रिया वे आम तौर पर जोड़ते हैं, जबकि विंडो क्रोमेस स्थान पर शीर्ष wieght जोड़ते हैं। विकल्प अधिक मेटाडेटा, उपयोग में आसानी और तेज नेविगेशन प्रदान करते हैं।

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

मुझे पता है कि मेरे 3 संपादक हैं, लेकिन कभी-कभी मैं अपने लुक-अप कोड-ओनली फ़ाइल के साथ अन्य 2 को ओवरराइड नहीं करना चाहता।

अगर मैं कोई फ़ाइल खोलता हूँ तो वह भिन्न फ़ाइल इतिहास में रहती है, तो मैं टैब के बिना ठीक हूँ। हो सकता है कि यदि कोई फाइल 5s से अधिक खुली हो तो वह CTRL + Tab में एंट्री के लायक हो।

@ 4tron हाँ यह मेरे लिए है, क्योंकि मैं IDE का उपयोग करना चाहता हूं जो मेरे लिए सुविधाजनक है। किसी को खोने वाले टैब के लिए व्यर्थ है और अपने स्थान को सुरक्षित करते हैं (शायद वे नेटबुक का उपयोग कर रहे हैं और वास्तव में कुछ अतिरिक्त पिक्सेल =) के लिए पर्याप्त जगह नहीं है), दूसरों के लिए यह सुविधाजनक है और उनकी उत्पादकता बढ़ाता है। किसी भी अच्छे सॉफ्टवेयर को अनुकूलन योग्य होना चाहिए और उसमें पैनलों को छिपाने / दिखाने की क्षमता होनी चाहिए। "एक स्थान बचाओ" बहस नहीं है। टैब को पेश करें + उन्हें दिखाने / छिपाने की क्षमता जोड़ें (यदि किसी के लिए वास्तव में इसकी आवश्यकता है)) तो उन्हें जाने का सबसे अच्छा तरीका है। एक नया अमेरिका खोलने या गलत नवाचारों के साथ जाने की आवश्यकता नहीं है, यहां सबसे अच्छे आईडीई से सीखने की जरूरत है, जो वर्षों से यूएक्स को बेहतर और बेहतर बना रहे थे, जैसे कि इंटेलीज, विज़ुअल स्टूडियो और अन्य।

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

मुझे, मैं एक टैब आदमी हूं। मुझे वर्किंग फाइल्स बहुत सीमित और नॉन सहज ज्ञान युक्त लगती हैं, साथ ही प्रोजेक्ट ट्री पर वर्टिकल स्पेस लेते हैं। लेकिन यह शायद ही मायने रखता है अगर हमारे पास 1 से अधिक परियोजना नहीं हो सकती है। :(

मुझे लगता है कि एक वरीयता भी ठीक होनी चाहिए।

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

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

तथ्य यह है कि टैब बहुत ही व्यावहारिक हैं, भले ही टैब ब्लोटिंग एक समस्या हो। आपको टैब का उपयोग करने के तरीके के बारे में सोचना चाहिए लेकिन उनकी संख्या को सीमित करना चाहिए।

आमतौर पर मैं खुले टैब रखता हूं जिसे मैंने दिनों तक संपादित नहीं किया है। यह आम तौर पर है कि जो इसे फूला हुआ बनाते हैं।

+1

मेरे पास 4K स्क्रीन है और क्षैतिज रूप से कोई टैब नहीं है वास्तव में मुझे VsCode से बंद कर रहा है

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

अगर मैं एक IDE है कि मुझे फ्रेम में खोलने के लिए एक दूसरे के बगल में सिर्फ एक टैब स्विच कर देंगे, जैसे जब मैं खुले button.html यह button.js बगल में खोलने के लिए और में button.scss होगा द्वारा "जुड़े" फ़ाइलों की अनुमति होगी पाया तीसरा फ्रेम, मैं फिर कभी एक और आईडीई का उपयोग नहीं करूंगा।

मुझे पता है कि ऐसा कभी नहीं होगा, लेकिन सिर्फ कहने के लिए। '

ठीक है, तो, आप mvim का उपयोग करना चाहिए! http://www.vim.org/scripts/script.php?script_id=1567 कमांड: AV संबंधित फाइलें खोलता है (A संबद्ध)।

क्या @jtosey के बारे में बात करता है कि मैं क्या कहने के लिए यहाँ आया था। मैं संबंधित फाइलों के एक सेट को व्यवस्थित करने के लिए पैन का उपयोग करता हूं। अधिकांश टैब प्रबंधन में संदर्भों को स्विच करने पर उन संबंधित फ़ाइलों को एक दूसरे के बगल में प्राप्त करना शामिल है।

+1

यहाँ भी, टैब पसंद करेंगे।

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

वीएस टैब सही हैं, कृपया टैब लाएं, अलग विंडो में टैब को अनडॉक करना बहुत अच्छा होगा!
Vscode के लिए धन्यवाद :)

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

ऐसी दो स्थितियाँ हैं जहाँ एक टैब बार की बिल्कुल माँग है।

1. कई टैब के बीच जल्दी से स्विच करें।
   मेरे लिए एक सामान्य स्थिति यह है कि मुझे इसके आकार के अनुसार 2 या अधिक फ़ाइलों की तुलना करने की आवश्यकता है, जैसे कि सरलीकृत चीनी और इसके पारंपरिक समकक्ष के बीच तुलना करना। एक भिन्न समस्या का समाधान नहीं करेगा क्योंकि वे विभिन्न वर्ण हैं। एकमात्र तरीका यह है कि यह देखने के लिए टैब के बीच जल्दी से स्विच करें कि क्या आपके आईबॉल द्वारा कोई लापता शब्द है। ST और I का उपयोग करके Alt-NUM का उपयोग करके टैब को स्विच किया जा सकता है, लेकिन VSC में एकमात्र संभव तरीका कई Ctrl-Tab, या माउस का तेजी से चलना और क्लिक करना है।
2. लंबे और कठिन प्रकार के फ़ाइल नाम।
   फ़ाइलों के बीच स्विच करने के लिए Ctrl-P का उपयोग करना बुरा नहीं है। लेकिन कुछ फ़ाइल नामों के बारे में कैसे पता चलता है जो एक लंबे आम फिक्स को साझा करते हैं? ऐसे कुछ नामों के बारे में जो अंग्रेजी में नहीं हैं? विचार करें कि आप 青年急着买房的原因（上）.md और 青年急着买房的原因（下）.md बीच स्विच करने के लिए Ctrl-P पर कितना समय व्यतीत करेंगे?

मैं कहता हूँ, कोड लिखते समय आप दोनों में से कोई भी स्थिति हिट नहीं होगी, लेकिन एक सामान्य उद्देश्य संपादक के रूप में, यह एक गंभीर मुद्दा है।

@ msg7086 Im एक बिंदु के बारे में निश्चित नहीं है, लेकिन बिंदु दो के लिए आप ctrl + p नहीं कर सकते हैं और फिर .md दोनों विकल्पों के साथ छोड़ रहे हैं और फिर ctrl + tab एक को चुनने के लिए चाहते हैं? निश्चित नहीं कि मैं इस मुद्दे को सही ढंग से समझ रहा हूँ

@ 4tron उत्तर के लिए धन्यवाद। हालाँकि, आपकी विधि केवल तभी काम करती है जब मेरे पास उस प्रकार की केवल 2 फाइलें हों। वास्तव में लोग संभवतः एकल निर्देशिका में उन फाइलों के गुच्छा के साथ काम कर रहे होंगे। इमेजिंग मैं एक ब्लॉग लिख रहा हूं जिसमें मार्कडाउन फॉर्मेट में 50 पोस्ट हैं, चीनी या कोरियन या अरेबियन आदि में अलग-अलग अक्षरों के साथ फाइल के नाम। वास्तविक परिदृश्य जो मैं मार रहा था, वह वास्तव में सीजेके नामों के साथ कुछ उपशीर्षक फाइलें थीं, जहां वे सभी *.ass , इस प्रकार विस्तार से Ctrl + P बहुत अच्छी तरह से काम नहीं करता है।

वास्तव में सराहना अगर यह लागू किया जा सकता है

इसके साथ डेवलपर्स का उपयोग किया जाता है, कृपया इसे प्राथमिकता दें ।

टैब के लिए +1। कृपया टैब लागू करें।

टैब के लिए +1!

मैं टैब जोड़ने के लिए भी वोट देता हूं।

+1

+1

+1

हमें ASAP टैब की आवश्यकता है।

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

क्या बड़ी बात है?

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

कृपया हमें दस्तावेज़ प्रबंधन सारणी दें :)

+1, मुझे।

+1

+1

VSCode एक महान संपादक है और इसमें Git और Nodejs दोनों के साथ अच्छे एकीकरण अंक हैं। मुख्य कारण है कि मैं इसे अपने प्राथमिक विकास आईडीई के रूप में उपयोग नहीं करता हूं क्योंकि यह टैब का समर्थन नहीं करता है।

मुझे भी। यह एक चीज है जो मुझे इसका उपयोग करने में रखती है।
Op 10 mrt करें। 2016 om 15:18 schreef कोनराड पिस्किक < सूचनाएं @github.com

VSCode एक महान संपादक है और इसमें Git और दोनों के साथ अच्छे एकीकरण अंक हैं
NodeJS। मुख्य कारण यह है कि मैं इसे अपने प्राथमिक विकास आईडीई के रूप में उपयोग नहीं करता हूं
क्योंकि यह टैब का समर्थन नहीं करता है।

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/224#issuecomment -194867036

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

यदि यह जोड़ा जाता है, तो कृपया निम्नलिखित जोड़ें:

1. Google Chrome जैसी बंद कार्यक्षमता। (हमेशा VS के मानक संस्करण से नाराज थे, यह नहीं था।)
   - " अन्य टैब बंद करें "
   - " दाईं ओर टैब बंद करें "।
2. टैब को दाईं या बाईं ओर खोलने का विकल्प। (वीएस ने कुछ बिंदु पर डिफ़ॉल्ट बदल दिया, लेकिन फिर बदलने का विकल्प जोड़ा)

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

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

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

-1

मैं टैब के खिलाफ क्यों हूं, इसके लिए कुछ नोट:

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

ठीक है, एक समझौता है- वरीयताएँ / विकल्प में दृश्यमान टैब बनाएं या नहीं।

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

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

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

जैसा कि मैंने पहले इस धागे में सुझाव दिया है, यह _behavior_ है जो गायब है जो महत्वपूर्ण है, यदि दृश्य घटक की तुलना में मोरसो नहीं है। मैं ctrl + [Shift +] टैब या यहां तक ​​कि ctrl + P जैसे कीबोर्ड शॉर्टकट का उपयोग करके फ़ाइलों को खोलने के लिए (खुले वाले सहित) कर रहा हूं, लेकिन वर्किंग फाइल्स का व्यवहार और यह कैसे संपादक विंडो (और यह ctrl / tabs) का प्रबंधन करता है MRU के क्रम में) मुझे बहुत घबराहट होती है।

फोन पकड़ना! मुझे जवाब मिल गया! यह एकदम सही है! तैयार? हम _need_ टैब नहीं करते हैं। आइए, संपादक के शीर्ष पर क्षैतिज रूप से टैब में उन्हें प्रदर्शित करने के लिए एक सरल विकल्प के साथ काम करने वाली फ़ाइलों का विस्तार करें! वू हू! टैब बनाने के बिना हल की गई समस्या!

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

तो मैं इस पर -1 हूं। लेकिन मैं अभी भी खिड़कियों को खोलना देखना चाहूंगा।

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

यह। 100% सहमत हैं।

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

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

@ jayrosen1576 शायद समस्या यह है कि किसी ने वास्तव में एक गहन प्रस्ताव नहीं किया है कि यह कैसा दिखना चाहिए

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

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

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

1) एटम डाउनलोड करें
2) एटम खोलें
3) टैब देखें
4) VSCode में लागू

@ jayrosen1576 गंभीरता से? मैंने एटम के कार्यान्वयन के साथ कुछ वैध चिंताओं का नाम दिया है और यह भी समस्या है कि एटम के पास केवल इसलिए नहीं है क्योंकि इसमें काम करने वाली फ़ाइलों की अवधारणा नहीं है।

फिर, आपकी प्रोफ़ाइल तस्वीर सब कुछ कहती है।

• क्या टैब बार को सभी खिड़कियों के ऊपर बैठना चाहिए?
  A: हाँ। एटम में टैब आज़माएं
• जब आपके पास एक से अधिक फ़ाइलों को साइड-बाय-साइड खोलने या भविष्य के रिलीज़ में, यहां तक ​​कि क्षैतिज रूप से विभाजित होने पर एक टैब काम कैसे करेगा?
  एक: टैब प्रत्येक फलक के शीर्ष पर दिखाई देते हैं। एटम में टैब आज़माएं।
• क्या सक्रिय फ़ाइल का टैब हमेशा हाइलाइट किया जाएगा?
  A: हाँ। एटम में टैब आज़माएं।
• यदि डिबग कंसोल केंद्रित है तो क्या होगा?
  A: समान परिणाम जब डिबग कंसोल अभी दो फ़ोकस के साथ साइड-बाय-साइड खुलता है।
• यदि आप टैब सेटिंग सक्षम करते हैं, तो क्या यह कार्यशील फ़ाइलों का खंड हटा दिया जाएगा क्योंकि यह निरर्थक है?
  A: केवल तभी जब आप कार्यशील फ़ाइलों को अक्षम करते हैं (एक विकल्प के रूप में)
• विभिन्न फ़ोल्डर में डुप्लिकेट फ़ाइल नामों के बारे में क्या?
  A: टैब में आंशिक पथ शामिल है। एटम में टैब आज़माएं।
• टैब और पैनल के डुप्लिकेट क्लोज़ बटन के बारे में क्या?
  A: पैनल में क्लोज बटन नहीं है। एटम में टैब आज़माएं।
• क्या पैनल बंद करने से टैब बंद हो जाएगा?
  A: हाँ। एटम में टैब आज़माएं।
• क्या आप जैसे ही एटम (उरघ) में कोई फ़ाइल खोलते हैं या जब आप काम करने वाली फाइलों की तरह संपादित करते हैं, तो एक टैब दिखाई देगा?
  A: केवल तभी जब आप ऐसा करने के लिए विकल्प सक्षम करते हैं (Atom में झूठे झूठे का उपयोग करता है)। अन्यथा एक टैब में डबल-क्लिक उन्हें खोलता है। एटम में टैब आज़माएं।

@felixfbecker क्योंकि यह उत्पाद Visual Studio moniker को ले जाता है, वहाँ वैकल्पिक टैब होना चाहिए, और उन्हें किसी अन्य Visual Studio उत्पाद में जैसा व्यवहार करना चाहिए वैसा ही करना चाहिए।

यह आपके चरित्र के बारे में संस्करणों को कहता है जब आप अपनी चिंताओं के एक वैध जवाब के जवाब में एक प्रोफ़ाइल तस्वीर के रूप में कुछ हद तक लाते हैं।

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

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

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

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

@nvivo खुद इसे नहीं डाल सकता था। यह पूरी चर्चा सिर्फ गूंगी लगती है।

वीएस अपरकेस मेनू पसंद है।

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

https://marketplace.visualstudio.com/items?itemName=wmaurer.change-case

यदि आपको यह चर्चा लोगों को पसंद नहीं है, तो बस आगे बढ़ें। इस धागे को पढ़ना पूरी तरह से वैकल्पिक है!

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

यदि टैब जल्द ही नहीं जोड़े जाते हैं तो क्या आप वीएस कोड का उपयोग करना जारी रखेंगे? हाँ नही

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

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

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

ब्राउज़र एक्सटेंशन? सक्रिय ... एनवीएम।

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

पहले जो कहा गया था उसके संदर्भ में।

"मुझे नहीं लगता कि अन्य सुधारों से समय लगता है"

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

@ 4tron , निश्चित रूप से यहाँ Microsoft का परीक्षण करने के लिए दुष्ट समुदाय की साजिश है! वहाँ हमेशा एक नहीं है?

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

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

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

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

घीहे, प्रफुल्लित!

सेशन za 12 mrt। 2016 om 11:57 schreef Natan Vivo सूचनाएं @github.com

@ 4tron https://github.com/4tron , निश्चित रूप से की साजिश है
यहाँ Microsoft का परीक्षण करने के लिए बुराई समुदाय! वहाँ हमेशा एक नहीं है?

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

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

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

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

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/224#issuecomment -195715795।

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

@ 4tron मुझे ऐसा लग रहा था कि वह टेक्स्ट एडिटर की तुलना टेक्स्ट एडिटर से भी कर रहा था।
मुझे लगता है कि वे vscode को एक्स्टेंसिबल बनाने में बहुत अच्छा काम कर रहे हैं, लेकिन मैं उस कैंप में मजबूती से खड़ा हूं जो मानता है कि टैब एक आउट-ऑफ-द-बॉक्स सुविधा होनी चाहिए। यह धारणा "ओह, आप उपयोग किए जाने वाले अन्य सभी सॉफ़्टवेयरों की तरह टैब पसंद करते हैं; Google समस्या; उपयुक्त उपयोगकर्ता-योगदानित एक्सटेंशन को स्थापित करने के तरीके की व्याख्या करने वाली अनुशंसाएँ खोजें, और आप जाने के लिए अच्छे हैं!" उड़ता नहीं है। मुझे लगता है कि ज्यादातर उपयोगकर्ता सिर्फ टैब मौजूद होने की उम्मीद करते हैं, और मुझे बहुत संदेह है कि बहुत सारे लोग हैं जो सोचते हैं कि आप एक्सटेंशन स्थापित करके टैब बार पाएंगे। मुझे पूरा यकीन है कि यह सॉफ्टवेयर के किसी भी अन्य टुकड़े से अप्रत्यक्ष नहीं है। लोग ऐसा करने के लिए क्यों सोचेंगे?

@TurkeyMan
उनकी बयानबाजी ब्राउज़रों की तुलना के साथ शुरू हुई थी।

हम यहां डेवलपर्स के बारे में बात कर रहे हैं। मुझे लगता है कि अगर उन्हें टैब चाहिए होता तो उनकी पहल होती। मुझे खेद है कि मैं इस विचार के खिलाफ हूं, लेकिन मुझे कोई वैध कारण टैब दिखाई नहीं दे रहा है, मैं alt + q बनाम पूरे समय में हूं। बस किसी भी मूल्य को नहीं जोड़ा गया है। यह मेरा व्यक्तिगत विचार है, और शायद यह समझने के लिए कि कैसे टैब को उपयोगी माना जाता है, के लिए im crap dev। मुझे लगता है कि यह वार्तालाप मौखिक है और व्यक्तिगत रूप से मैं देखना चाहूंगा कि vscode को लगभग पूर्ण अनुकूलन और यहां तक ​​कि व्यापार मॉडल जैसे एक अलग शेल के रूप में खोला जा रहा है। जहां कोई कह सकता है कि ड्रुपल डेवलपमेंट या वर्डप्रेस डेवलपमेंट के लिए एक केंद्रित डिग्री के लिए अनुकूलन को बढ़ाया जा सकता है जहां संपादकों का निर्माण उपयोगकर्ताओं के कोडबस के पारिस्थितिकी तंत्र के आसपास आधारित है। वह भी मुझे हल करने के लिए एक बेहतर समस्या की तरह लगता है।

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

टैब जैसा कुछ बेसिक होना चाहिए। अब, जैसा कि अन्य लोगों ने इस धागे में अनुरोध किया है, टैब के बीच संबंध बनाने या बनाने के लिए जहां एक्सटेंशन चर्चा में आना चाहिए।

@ 4tron , यह मजाकिया था, लेकिन मैं इस बिंदु पर गंभीर हूं।

बाहरी कंपाइलर सेवाएँ एक ऐसी चीज़ है जिसे आप टेक्स्ट एडिटर में समर्थन के लिए तय कर सकते हैं या नहीं। एकीकृत कार्य धावक सुविधा के लिए एक अच्छा कर रहे हैं।

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

और यही कारण है कि टैब अच्छा है या नहीं, इस पर चर्चा की जा रही है। वीएस कोड एक यूएक्स प्रयोग नहीं है, यह सभी प्लेटफार्मों के लिए एक अच्छा .NET संपादक होने का प्रयास है। इस लानत बात को 90% लोगों के लिए उपयोगी बनाएं और आप सफल होंगे।

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

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

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

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

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

जैसा कि मैंने पहले कहा था, एक रिलीज के लिए विज़ुअल स्टूडियो, एज या किसी अन्य Microsoft उत्पाद से टैब लें और प्रतिक्रिया देखें। यह सुंदर नहीं होगा। हम _can_ सभी के पास दोनों तरीके हैं। हम टैब को _optional_ नहीं एक आवश्यक संपादक घटक होने के लिए कह रहे हैं। क्या अन्य संपादक विकास पर बेहतर समय बिताया जा सकता है? ज़रूर। महत्वपूर्ण बग फिक्स और सुधार जो संपादक के ब्लॉक उपयोग को हमेशा पहले आना चाहिए। हालाँकि, मुझे यकीन है कि इसमें बहुत सारे फीचर्स जोड़े गए हैं जो महत्वपूर्ण सुधार या फिक्स होने के स्तर तक नहीं बढ़ते हैं। इसलिए यदि उन पर समय व्यतीत किया जाता है, तो एक सुविधा के लिए अलग से समय निर्धारित किया जाना चाहिए, जो इस थ्रेड पर विशाल बहुमत के लिए पूछ रहे हैं।

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

मुझे नहीं लगता कि "टैब के लिए जुनून" का एक बहुत कुछ है। क्या होता है कि @bpasero के बाद कहा गया " मुझे नहीं लगता कि टैब खुली फ़ाइलों की सूची दिखाने का एक अच्छा तरीका है " और " अभी तक मैंने टैब के लिए एक अच्छा कारण नहीं सुना है ", लोगों को सही ठहराने की कोशिश में अधिक मुखर होगा मुख्य परियोजना के लिए अनुरोध।

मैं यह सब चर्चा देख कर बहुत निराश हो गया, और मैं थोड़ा आहत हुआ क्योंकि मैं अपने काम में प्रतिदिन VS कोड का उपयोग करता हूं और मैं एक अच्छा .NET संपादक चाहता हूं मैक और लिनक्स पर, और मुझे टैब बहुत याद आता है, और मुझे वह "_wow नहीं मिला! यह वास्तव में अधिक उपयोगी_" क्षण है, लेकिन यहाँ प्रतिक्रिया प्रतीत होती है कि "_you ने महसूस नहीं किया कि हमने कुछ अद्भुत बनाया है! इसे समय दें और इसकी आदत डालें!"।

यहाँ कुछ वास्तविक मुद्दे हैं जो मैं वी.एस. कोड का उपयोग करके कुछ महीनों के लिए देख रहा हूं:

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

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

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

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

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

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

मैं और अधिक सहमत नहीं हो सका।

चूंकि कोड तह कभी सुविधा के लिए सबसे अधिक मतदान था, इसलिए अब टैब है । Vscode टीम ने हमें तह दिया।

मैं आश्चर्यचकित और असंतुष्ट हो जाऊंगा अगर टैब को कभी भी ओपन सोर्स समुदाय में Microsoft की ताज़ा भागीदारी के मद्देनज़र vscode टीम के शीर्ष उपयोगकर्ता अनुरोधों को शामिल करने का महान ट्रैक रिकॉर्ड नहीं मिला।

@ianwesterfield बिल्कुल, यह हजारों वोटों के साथ शीर्ष अनुरोधित सुविधा है। यह होने जा रहा है। यह वार्तालाप व्यर्थ है और "कैसे वास्तव में टैब काम करना चाहिए?"

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

@ jon64digital शायद यह सिर्फ मैं ही हूं, लेकिन मुझे लगता है कि इस बातचीत को विकसित होने से रोकता है। यह अनुरोध अभी भी बैकलॉग में अप्रकाशित है, यहां तक ​​कि 6k + वोटों के साथ और 31 मार्च की यात्रा में एक अस्पष्ट शब्द का संदर्भ:

दस्तावेज़ प्रबंधन में सुधार, संपादकों के व्यवहार को ढेर करना

ऐसा लगता है कि हमें अभी भी बार-बार टैब के अस्तित्व को सही ठहराना है, अकेले उनके व्यवहार को आइए। बहुत कम से कम, मुझे लगता है, यह संदर्भ तीन में से एक है जो अपोजिशन रोडब्लॉकर्स को

इस बात को ध्यान में रखते हुए, मुझे लगता है कि अगर वे कम से कम किसी को यह काम सौंपते तो हम @ वादी में जो पहले कह सकते थे,

EDIT हो सकता है VS कोड टीम की प्रतिबद्धता की यह कमी एक गलतफहमी है - 7 मार्च के बाद से सभी मार्च पुनरावृत्ति योजना को अपडेट नहीं किया गया है।

@ jayrosen1576 मैं सहमत हूं - और मुझे लगता है कि 1% उपयोगकर्ता अनुरोधों को कवर नहीं किया जाएगा, फिर उन्हें एक्सटेंशन के माध्यम से संबोधित किया जा सकता है (जैसे टैब समूहों में संबंधों के साथ फाइलें खोलना, आदि)।

@ jayrosen1576 क्या आप फ़ाइलों को लिंक करने की अनुमति देते हैं ताकि आप एक विभाजन दृश्य देख सकें (उदाहरण के लिए) पहले फ्रेम में toolbar.html, दूसरे में toolbar.js और तीसरे में toolbar.css हैं?

यह सिर्फ एक उदाहरण है लेकिन यह बिल्कुल आदर्श होगा। ऊपर किसी ने कहा कि विम ऐसा कर सकता है, लेकिन मैंने विम की जाँच की और कई कारणों से इस पर उत्सुक नहीं था, लेकिन टैब की बात शानदार लगती है।

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

EDIT ऊपर (इस पोस्ट से लगभग 9 दिन पहले) @jtosey द्वारा टिप्पणी का संदर्भ देता है।

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

लेकिन फिर, यह एक विस्तार की सुंदरता है - अगर मुझे यह पसंद नहीं है तो मैं इसे बंद कर सकता हूं।

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

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

जबकि टैब की अवधारणा को अच्छी तरह से समझा जाता है, हम यह नहीं सोचते हैं कि हम अपने मौजूदा दस्तावेज़ प्रबंधन के शीर्ष पर टैब जोड़ सकते हैं, बिना हमारी अवधारणाओं को फिर से देखे।

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

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

@bpasero यह अच्छा था यदि आपने चर्चा की और अधिक विस्तार से बताया कि आपके द्वारा पोस्ट की गई समस्याओं के संभावित समाधानों के रूप में आपके द्वारा देखे जाने वाले कुछ दृष्टिकोण क्या हैं।

PS मुझे यकीन नहीं है कि यह VSCode के साथ संभव है, लेकिन कुछ टीम जैसे Roslyn, TypeScript और कुछ और अपने डिजाइन नोट्स साझा करते हैं, यह बहुत सारे संदर्भ देता है कि वे कैसे काम करते हैं और आगे क्या आ रहा है, यह समुदाय को नई चर्चाओं के लिए भी खोलता है। क्या यह संभव है?

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

मुझे लगता है कि आपकी टीम वाष्प ताला में है और इस पर्वत में मोलेहल बना रही है।

अर्थ: टैब्स दस्तावेज़ प्रबंधन की व्यापक अवधारणा के साथ, समानार्थक नहीं हैं। Vscode के दस्तावेज़ प्रबंधन के अन्य क्षेत्रों से निपटने के लिए पहले से ही अन्य मुद्दे हैं।

हम पहले से ही खुले में मुद्दों के माध्यम से हमारे UX विचारों पर चर्चा करते हैं (देखें https://github.com/Microsoft/vscode/issues?q=is%3Aopen+is%3Aissue+label%3Aux), मेरा मानना ​​है कि हम ऐसा ही करेंगे दस्तावेज़ प्रबंधन और टैब के लिए।

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

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

@bpasero आपको बहुत धन्यवाद, बस इतना ही मैं जानना चाहता था। :)

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

इस पूरे सूत्र को पढ़े बिना मैं इस पर एक बड़ा: +1: देता हूं।

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

+1

अत्यंत आवश्यक है।

+1

मैं विकास के दौरान कई अलग-अलग फ़ाइल प्रकारों पर काम करता हूं इसलिए मैं अक्सर एक प्रकार की फ़ाइल के लिए दाईं ओर एक टैब समूह बनाना चाहता हूं और अन्य प्रकार की फ़ाइलों के लिए बाईं ओर एक अन्य टैब समूह बनाता हूं। उदाहरण के लिए, जब प्रोटेक्टर / वेबड्राइवर कोड पर काम करते हैं, तो मैं "पेज ऑब्जेक्ट्स" को दाईं ओर रखना चाहता हूं और बाईं ओर "स्पेक्स" सभी को अलग-अलग और तार्किक रूप से समूहीकृत करता हूं। इसी तरह जब फ्रंट-एंड स्टफ पर काम करते हैं, तो मैं सभी / js / ts फ़ाइलों के लिए दाईं ओर एक html और css के लिए बाईं ओर एक टैब समूह रखूँगा।

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

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

कोड में टैब समूहों की कमी बेहद निराशाजनक है और मुझे नहीं लगता कि लोगों को एक निश्चित तरीके से काम करने के लिए मजबूर या आश्वस्त होना चाहिए क्योंकि "आपकी राय में यह बेहतर है" या "टैब के लिए कोई अच्छा कारण नहीं है"। हाँ वहाँ है। हो सकता है कि आप सिर्फ उनका सबसे अच्छे तरीके से उपयोग न करें या उन्हें ऐसा न लगे कि वे उपयोगी हैं, लेकिन हम में से कई ऐसे हैं जो टैब समूहों के रूप में बुनियादी तौर पर कुछ करना चाहते हैं।

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

कृपया टैब समूहों को वीएस कोड पर वापस लाएं।

हो सकता है कि अगर आप वर्किंग फाइल्स लिस्ट में फाइलनामों के इर्द-गिर्द बक्सा खींचते हैं, तो लोग देखेंगे कि यह कार्यात्मक रूप से लेफ्ट साइडेड के बराबर है ... :-)

@ क्रिसमिस : इसके अलावा यह नहीं है । (यदि ऐसा होता तो मैं संभवतः इसके साथ रहना चाहता / चाहती हूँ)

जबरदस्त हंसी

थू पर, 17 मार्च, 2016 को 4:59 बजे केनेथ जी फ्रैंकेरो <
सूचनाएं@github.com> ने लिखा:

@ChrisM मियामी https://github.com/ChrisM मियामी : इसके अलावा यह नहीं है
https://github.com/Microsoft/vscode/issues/224#issuecomment -166931316।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/224#issuecomment -197603728

@kfranqueiro एक उचित टैब सॉल्यूशन की प्रतीक्षा करते समय आपके द्वारा उपयोग की जाने वाली कीबाइंडिंग को अपनाने में रुचि हो सकती है जो कि ctrl + w और ctrl + shift + w को एक नियमित टैब्स कार्यान्वयन के करीब लाती हैं।

@ nub340 VSCode एटम पर आधारित नहीं है, लेकिन इलेक्ट्रॉन जो उसी समूह द्वारा बनाया गया था जो एटम पर काम कर रहा है।

+1 कृपया जोड़ें !!!

मुझे यह भी लगता है कि यह अन्यथा महान संपादक में गायब होने वाली एक विशेषता है।

कृपया विकल्प के रूप में टैब जोड़ें, या टैब कार्यक्षमता के लिए तीसरे पक्ष के प्लगइन की अनुमति दें।

पहली बात जिसने मुझे VSC के बारे में मारा (मूर्खतापूर्ण नाम के बाद) कैसे _great_ यह _not_ टैब था।

मेरे पास वर्तमान में 8 फाइलें खुली हैं - टैब मेरे लिए व्यर्थ हैं, क्योंकि फ़ाइल नाम टैब पर दिखाई नहीं देंगे।

I _adore_ CTRL + TAB, और 'कार्यशील फ़ाइलें' सूची।

यदि आपको टैब जोड़ना होगा, तो कृपया उन्हें वैकल्पिक करें।

@leegee वे "व्यर्थ" नहीं हैं, आपको उनके लिए कोई आवश्यकता नहीं है। क्या आप मानते हैं कि जो लोग विभिन्न प्रकार की परियोजनाओं पर काम कर रहे हैं, उनके लिए आपके पास एक अलग उपयोग का मामला हो सकता है?

उन हजारों लोगों को दे दो जिन्होंने टैब के लिए मतदान किया है, मुझे लगता है कि यहाँ केवल "व्यर्थ" बात है आपकी टिप्पणी :)

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

@ jon64digital @leegee ने कहा कि वे व्यर्थ थे _ उसके लिए, सामान्य रूप से नहीं। मैं पूरी तरह से टैब का समर्थन करता हूं, लेकिन मैं सहमत हूं कि उन्हें एक विकल्प होना चाहिए जो उन लोगों के लिए बंद हो सकता है जो उनका उपयोग नहीं करते हैं। आइए चर्चा नागरिक रखें और व्यक्तिगत हमलों का सहारा न लें। किसी की भी गलत राय नहीं है। वे बस यही हैं ... राय।

@ jayrosen1576 उन्होंने अपनी टिप्पणी संपादित की है। यदि यह मूल रूप से "मेरे लिए व्यर्थ" कहा जाता था, तो निश्चित रूप से मैंने यह नहीं कहा कि मैंने क्या किया। मैं यह भी मानता हूं कि जिन दो अन्य लोगों ने उनकी टिप्पणी को अस्वीकार किया, उन्होंने इसे संपादित करने से पहले ऐसा किया।

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

वैसे भी, अगर किसी ने इसे निजी हमले के रूप में देखा तो मैं माफी मांगता हूं। मैंने इसके बाद एक स्माइली लगाई।

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

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

@ nub340 बिल्कुल! हम में से कुछ लोग टैब पसंद करते हैं क्योंकि वे हमेशा डेवलपर्स / उपयोगकर्ताओं के रूप में हमारे अनुभव का हिस्सा थे, व्यक्तिगत रूप से मैं उन फ़ाइलों को देखना पसंद करता हूं जो मैं सबसे ऊपर काम कर रहा हूं, काम करने वाली फाइलों पर टैब करने का कोई अंतर्निहित लाभ नहीं है, लेकिन यह सिर्फ कुछ है हमें यह पसंद है।

सहमत, मैं इसे एक विकल्प के रूप में चाहूंगा, इसे बलपूर्वक नहीं।
Tue पर, 22 मार्च, 2016 को 6:22 AM Eyal Solnik सूचनाएं @github.com पर
लिखा था:

@ nub340 https://github.com/nub340 बिल्कुल! हममें से कुछ लोग टैब पसंद करते हैं क्योंकि
वे हमेशा डेवलपर्स / उपयोगकर्ताओं के रूप में हमारे अनुभव का हिस्सा थे, व्यक्तिगत रूप से मुझे पसंद हैं
उन फ़ाइलों को देखने के लिए जो मैं शीर्ष पर काम कर रहा हूं, कोई अंतर्निहित नहीं है
काम कर रही फाइलों पर टैब करने का लाभ लेकिन यह हम में से कुछ को पसंद है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/224#issuecomment -199565160

हमारे पास विक -20 पर टैब नहीं था ...।

इस चर्चा से एक बात सामने आती है कि जो कुछ भी है (बनाया)
उपलब्ध है, यह अनुकूलन योग्य होना चाहिए।

@glennblock , @leegee हाँ, यह निश्चित रूप से एक विकल्प होना चाहिए, लेकिन क्या कामकाजी फ़ाइल को इन उपचारों के लिए वही नहीं मिलना चाहिए जो इसे नहीं चाहते हैं? हालाँकि, संभवतः किसी अन्य सुविधा अनुरोध में इस पर चर्चा करना सबसे अच्छा है। :)

मैंने इस पाठ को यहां पोस्ट किया है: https://github.com/Microsoft/vscode/issues/101

यह इस चर्चा के लिए भी मान्य है। मुझे @bpasero की प्रतिक्रिया देखकर खुशी होगी।

मुझे यह सुविधा चाहिए। चर्चा का अंत। अपनी राय भाड़ में जाओ @bpasero मुझे परवाह नहीं है कि आपको क्या लगता है कि क्या सही है और क्या नहीं। यह टैब # 224 के बारे में है। आप हमें यह समझाने की कोशिश कर रहे हैं कि आपका समाधान बेहतर है। एक बार फिर अपना हल चोदो। हम सभी सामान अलग तरह से करते हैं और किसी को परवाह नहीं है कि आप क्या सोचते हैं। मैं vscode का उपयोग कर रहा हूँ टाइपस्क्रिप्ट और कोणीय 2 के महान समर्थन का। अन्यथा मुझे इससे नफरत है क्योंकि इसमें उन विशेषताओं का अभाव है जो सामान्य संपादकों के पास हैं, जैसे कि सबमिलीटेक्स्ट, एटम, ब्रैकेट्स

Haha @PeterMtj , यह कहने के लिए धन्यवाद कि हम सभी क्या सोच रहे हैं :)

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

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

@PeterMtj गंभीरता से? यह है कि आप चीजों को कैसे देखते हैं? लोगों को शाप? अगर आपके मन में उसके लिए सम्मान नहीं है तो अपने लिए कुछ सम्मान रखें!

@ jon64digital वह वोट कर सकता है या अपनी निजी राय कह सकता है और यह ठीक है! हमें अपनी राय के लिए व्यक्तिगत और निश्चित रूप से लोगों को शाप देने की आवश्यकता नहीं है!

मैं उनकी शुरुआती प्रतिक्रिया से भी असहमत हूं, यह कहते हुए कि "नहीं" मेरी राय में पेशेवर और काफी असभ्य नहीं है, लेकिन मुझे लगता है कि समुदाय लोगों की राय की परवाह किए बिना बेहतर और सभ्य रह सकता है।

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

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

चलो इसे एक लौ युद्ध में नहीं बदल दें और इसे रचनात्मक रखें, कृपया!

@eyalsk

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

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

आपको एक लंबा धागा मिल गया है जिसमें सैकड़ों लोग MS EXACTLY को बता रहे हैं कि वे एक कोड संपादक से क्या चाहते हैं। ऐसा नहीं है कि वे नहीं जानते कि हम क्या चाहते हैं। फिर हमारे पास एक एमएस कर्मचारी है जो यहां कहता है "नहीं, आप मूल रूप से सभी गलत हैं"। क्या उस कंपनी की तस्वीर अपने दर्शकों के साथ तालमेल में नहीं है?

बस मेरा 2 सी।

@ jon64digital

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

यह सिर्फ आपकी पूर्वाग्रह की धारणा है और मैं इसका सम्मान करता हूं, लेकिन हम दुनिया के किसी भी अन्य निगम के बारे में एक ही बात कह सकते हैं कि कुछ Apple, Oracle और Google का नाम ...

मैं ऐसे बहुत से लोगों को जानता हूं जिन्हें काम में एमएस ऑफिस का उपयोग करना पड़ता है,

लोग एमएस ऑफिस का उपयोग करने के लिए मजबूर नहीं होते हैं, यह नियोक्ता का निर्णय है, लिबर ऑफिस एक महान उत्पाद है और यह काफी अच्छा विकल्प है।

मुझे पहले Visual Studio का उपयोग करना पड़ा क्योंकि मेरे पास कोई अन्य विकल्प नहीं था

मुझे नहीं पता _why_ आपके पास कोई विकल्प नहीं था लेकिन आपके पास निश्चित रूप से आज विकल्प हैं! मेरे पास हमेशा एक विकल्प होता था जब लोग विजुअल स्टूडियो का उपयोग करते थे। .NET विकास के लिए मैंने शार्पडेवलप, विम और नोटपैड ++ का उपयोग किया था, मुझे कई संपादकों का उपयोग करने में कभी समस्या नहीं हुई, मैं वैसे भी डिजाइनरों का प्रशंसक नहीं हूं ...

C / ++ के लिए आपके पास संपादकों और IDE से और भी अधिक समर्थन है जब तक आप VC ++ का उपयोग नहीं करते हैं :)

इसके अलावा, मुझे कभी यह समझ में नहीं आया कि कुछ लोग अपने आप को एक्स द्वारा बनाई गई प्रौद्योगिकियों के एक विशिष्ट ढेर में बंद क्यों कर रहे हैं, माइक्रोसॉफ्ट से परे कई प्रौद्योगिकियां हैं।

मैं उन लोगों की संख्या की गणना कर सकता हूं जो एक हाथ की उंगलियों पर स्वेच्छा से इंटरनेट एक्सप्लोरर का उपयोग करेंगे।

आप सही हैं इंटरनेट एक्सप्लोरर संस्करण 9 तक बहुत खराब था, लेकिन तब से उनमें काफी सुधार हुआ है और भले ही मैं एक फ़ायरफ़ॉक्स उपयोगकर्ता हूं, मैं अपने अतीत के लिए Microsoft का न्याय नहीं करता, मैं उन्हें जज करता हूं कि वे किसके लिए हैं वर्तमान और यह अच्छा लग रहा है!

यहां तक ​​कि वे इन प्रथाओं के कारण एंटी-ट्रस्ट सूट का विषय भी रहे हैं, इसलिए यह कहना कि कोई भी एमएस सॉफ्टवेयर का उपयोग करने के लिए किसी को भी अनुभवहीन बना रहा है।

कोई किसी का कुछ भी उपयोग नहीं कर रहा है और मुझे ज्यादातर लोगों के बारे में पता नहीं है लेकिन मैं भोले से दूर हूं, मैं सिर्फ उचित हूं।

यदि आपका नियोक्ता MS प्रौद्योगिकियों का उपयोग करने का विकल्प बनाता है, तो आप निश्चित रूप से _ कार्यान्वित_ हैं, लेकिन फिर भी यह Microsoft की गलती नहीं है, यदि आपने MS प्रौद्योगिकियों का उपयोग करने का विकल्प बनाया है, तो आपने इसे चुना और इसके बारे में शिकायत करना थोड़ा मूर्खतापूर्ण है, समकक्ष तकनीकें हैं Microsoft के रूप में के रूप में अच्छे हैं तो लोगों को निश्चित रूप से विकल्प हैं।

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

बिल्कुल सही! हालांकि मुझे नहीं लगता है कि लोगों को जो वे चाहते हैं वह एक डिजाइन के दृष्टिकोण से अच्छा है। :)

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

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

आपको एक लंबा धागा मिल गया है जिसमें सैकड़ों लोग MS EXACTLY को बता रहे हैं कि वे एक कोड संपादक से क्या चाहते हैं। ऐसा नहीं है कि वे नहीं जानते कि हम क्या चाहते हैं। फिर हमारे पास एक एमएस कर्मचारी है जो यहां कहता है "नहीं, आप मूल रूप से सभी गलत हैं"। क्या उस कंपनी की तस्वीर अपने दर्शकों के साथ तालमेल में नहीं है?

यह एक उचित बिंदु और शिकायत है, मैं अन्यथा नहीं कह रहा हूँ! लेकिन @bpasero ने पहले ही कहा था कि एक बार जब वे UX पर काम करेंगे तो वे इस समस्या से भी निपटेंगे "_ जब तक हम टीम में UX चर्चा शुरू करते हैं हम उस समुदाय को भी शामिल करना चाहते हैं और फिर हम उन दोषों पर भी चर्चा करेंगे जो हम अपने वर्तमान डिजाइन में देखते हैं। और हम क्या सुधार करने की योजना बना रहे हैं ।_ "

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

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

यह महसूस करने की कोशिश करें कि Microsoft हमारी मदद नहीं कर रहा है। हम उनके उत्पादों का उपयोग करके और प्रतिक्रिया देकर Microsoft की मदद कर रहे हैं ताकि वे सभ्य उत्पाद बना सकें। यह बचाव टैब के बारे में चर्चा नहीं होनी चाहिए, लेकिन टैब कैसे काम करना चाहिए, यह प्रकृति में vscode के साथ है। Vscode समुदाय के लिए है, कि हमें और चरम मामले में अगर हम सभी स्क्रीन के बीच में लाल डायनासोर चाहते हैं, तो उन्हें बिना किसी कारण के ऐसा करना चाहिए। हम सभी के अपने-अपने कारण हैं। अन्यथा समुदाय के लिए vscode बेकार है। मैं इसे कैसे देखता हूं।

@PeterMtj मुझे लगता है कि हम असहमत होने के लिए सहमत होंगे। :)

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

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

सुलभता परिवर्धन के लिए टीआईए - हमारे लिए एक बड़ा बदलाव लाएगा
आधा अंधा

Sat, 26 Mar 2016, 01:38 Erich Gamma पर, सूचनाएं @github.com ने लिखा:

मैं इस मुद्दे के लिए कुछ अतिरिक्त पृष्ठभूमि प्रदान करना चाहता था।
हम कोड के प्रमुख मील के पत्थर के बारे में बता रहे हैं। हमारे लिए एक प्रमुख फोकस
पिछले 6 महीनों में पहुँच और स्थानीयकरण के लिए समर्थन था। यह
टैब की प्रतिक्रिया पर सक्रिय रूप से काम करने के लिए हमें यूआई क्षेत्र में कोई चक्र नहीं छोड़ा है।
अब है कि मार्च योजना (# 3555) पर अधिकांश चेक बॉक्स
https://github.com/Microsoft/vscode/issues/3555) की जाँच की जाती है, हम हैं
धीरे-धीरे फिर से दिखना शुरू। अप्रैल में हम इस विषय पर रैंप करेंगे।
@bpasero https://github.com/bpasero ने एक महत्वपूर्ण भूमिका निभाई
हमारे यूएक्स का विकास और यह अगला प्रमुख विकास होगा।

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/224#issuecomment -201618115

@egamma मैं वास्तव में आपको और आपकी टीम को हर चीज के लिए धन्यवाद देता हूं, मुझे लगता है कि आप बहुत अच्छा काम कर रहे हैं! लेकिन मुझे ऐसा लगता है कि @bpasero द्वारा की गई पहली प्रतिक्रिया से लोग चिढ़ गए और इससे बचा जा सकता था अगर उन्होंने अंतर्दृष्टि दी कि वह क्यों सोचते हैं कि टैब को केवल "नहीं" कहने के बजाय एक विकल्प नहीं होना चाहिए।

वैसे भी, वर्तमान पर ध्यान दें, क्या // बिल्ड / ईवेंट से पहले कोई नया बिल्ड है? : डी

@eyalsk मुझे विश्वास है कि "नहीं" टिप्पणी वास्तव में @inakianduaga से पहले उत्तर की बात कर रही

@Tyriar , gotcha धन्यवाद! :)

वैसे भी, वर्तमान पर ध्यान दें, क्या // बिल्ड / ईवेंट से पहले कोई नया बिल्ड है? : डी

नए बिल्ड के लिए बिट्स पहले से ही अंदरूनी चैनल ( रिलीज नोट्स ) पर आपका इंतजार कर रहे हैं कृपया इसका उपयोग करें और हमें प्रतिक्रिया दें।

@ तागम्मा धन्यवाद! ;)

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

पहला सत्र इस बुधवार को होगा। कृपया यहाँ साइन अप करें यदि आप रुचि रखते हैं: https://calendly.com/stevencl/visual-studio-code-tabs-design-discussion/04-06-2016

बहुत बढ़िया!
सोम, अप्रैल 4, 2016 को 3:54 AM स्टीवन क्लार्क नोटिफिकेशन @github.com पर
लिखा था:

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

पहला सत्र इस बुधवार को होगा। कृपया यहाँ साइन अप करें यदि
आप इसमे रुचि रखते हैं:
https://calendly.com/stevencl/visual-studio-code-tabs-design-discussion/04-06-2016

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।

इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/224#issuecomment -205239769

नए डिजाइनों पर आपकी प्रतिक्रिया सुनने के लिए उत्सुक हम इस मुद्दे से संबंधित खोज कर रहे हैं। यदि आप रुचि रखते हैं, तो कृपया ऊपर दिए गए लिंक पर @stevencl की टिप्पणी के माध्यम से साइन अप करें!

केवल 3 और 4 बजे? कोई और समय? मैं एक मैट पर 3/4 बजे पीएसटी नहीं बना सकता।

सोम, 4 अप्रैल, 2016 को सुबह 8:14 बजे ब्रैड गैशलर नोटिफिकेशन @github.com
लिखा था:

हम आपके द्वारा खोजे जा रहे नए डिज़ाइनों के लिए आपकी प्रतिक्रिया सुनने के लिए उत्सुक हैं
इस मुद्दे से संबंधित। यदि आप रुचि रखते हैं, तो कृपया लिंक के माध्यम से साइन अप करें
ऊपर स्टीवन की टिप्पणी!

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।

इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/224#issuecomment -205342923

यह अच्छा होगा यदि आपके पास पीएसटी के अनुसार समय है, तो कई (मेरे सहित) भाग ले सकते हैं

{मोबाइल}

सोम, 4 अप्रैल, 2016 को प्रातः 8:50 बजे, "ग्लेन ब्लॉक" सूचनाएं @ithub.com ने लिखा:

केवल 3 और 4 बजे? कोई और समय? मैं एक मैट पर 3/4 बजे पीएसटी नहीं बना सकता।

सोम, 4 अप्रैल, 2016 को सुबह 8:14 बजे ब्रैड गैशलर नोटिफिकेशन @github.com

लिखा था:

हम आपके द्वारा खोजे जा रहे नए डिज़ाइनों के लिए आपकी प्रतिक्रिया सुनने के लिए उत्सुक हैं

इस मुद्दे से संबंधित। यदि आप रुचि रखते हैं, तो कृपया लिंक के माध्यम से साइन अप करें

ऊपर स्टीवन की टिप्पणी!

-

आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।

इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें

https://github.com/Microsoft/vscode/issues/224#issuecomment -205342923

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

हाँ कृपया। मुझे लगता है कि मैं बातचीत का हिस्सा बनना चाहूंगा।

क्षमा करें, मुझे पता है कि ये समय सभी के लिए सुविधाजनक नहीं है। भविष्य में हम उन तरीकों पर गौर करेंगे, जिन्हें हम अलग-अलग समय क्षेत्रों में सत्र निर्धारित कर सकते हैं क्योंकि हम उन्हें नियमित आधार पर रखने की योजना बनाते हैं।

सिर्फ एक अतिरिक्त समय पर इस सप्ताह एक अतिरिक्त शेड्यूल क्यों नहीं? यह है एक
बहुत रुचि के साथ गर्म विषय।

सोम, 4 अप्रैल, 2016 को सुबह 9:44 बजे स्टीवन क्लार्क नोटिफिकेशन @github.com
लिखा था:

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।

इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/224#issuecomment -205386984

बस आप जानते हैं, आपके द्वारा देखे जाने वाले टाइम स्लॉट अभी भी उपलब्ध हैं। मेरे पास बाद में दिन में स्लॉट खुले थे, लेकिन वे बहुत जल्दी ले गए थे।

जैसा कि मैंने कहा, हम भविष्य में अलग-अलग समय क्षेत्रों में सत्र निर्धारित करने का प्रयास करेंगे।

सभी रुचि के लिए धन्यवाद।

मुझे लगता है, अच्छी तरह से मुझे लगता है कि वे तुरन्त भर गए (जो अच्छा है)
सोम, अप्रैल 4, 2016 को 11:30 AM स्टीवन क्लार्क नोटिफिकेशन @github.com पर
लिखा था:

बस आप जानते हैं, जो समय स्लॉट आप देखते हैं, वे केवल वही हैं जो हैं
अभी भी उपलब्ध। मेरे पास दिन में बाद में स्लॉट खुले थे, लेकिन उन्हें ले जाया गया
तुरन्त चुप।

जैसा कि मैंने कहा, हम अलग-अलग समय क्षेत्रों में सत्रों को निर्धारित करने का प्रयास करेंगे
भविष्य।

सभी रुचि के लिए धन्यवाद।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।

इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/224#issuecomment -205436942

क्या आप सत्रों को रिकॉर्ड कर सकते हैं?

सोम, 4 अप्रैल 2016 को सुबह 11:32 बजे ग्लेन ब्लॉक ग्लेन। [email protected] ने लिखा है:

मुझे लगता है, अच्छी तरह से मुझे लगता है कि वे तुरन्त भर गए (जो अच्छा है)
सोम, अप्रैल 4, 2016 को 11:30 AM स्टीवन क्लार्क नोटिफिकेशन @github.com पर
लिखा था:

बस आप जानते हैं, जो समय स्लॉट आप देखते हैं, वे केवल वही हैं जो हैं
अभी भी उपलब्ध। मेरे पास दिन में बाद में स्लॉट खुले थे, लेकिन उन्हें ले जाया गया
तुरन्त चुप।

जैसा कि मैंने कहा, हम अलग-अलग समय क्षेत्रों में सत्रों को निर्धारित करने का प्रयास करेंगे
भविष्य।

सभी रुचि के लिए धन्यवाद।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।

इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/224#issuecomment -205436942

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

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

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

Ditto @indiejames

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

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

मैं कई IDE और टेक्स्ट संपादकों में 30 से अधिक वर्षों से विकास कर रहा हूं। मैं टैब को बैसाखी के रूप में नहीं देखता, एक उपयोगी संगठनात्मक उपकरण हैं। हाँ, यदि आपके पास टैबिल के क्षेत्र हैं, तो वे नियंत्रण से बाहर हो सकते हैं, लेकिन मैं नहीं ...।

फ़ाइलों पर फ़ोकस की ओर झुकाव वाले टैब और, फ़ाइलों में कोड रहता है, और फ़ाइलों का उपयोग संगठन के लिए किया जाता है, और VS कोड फ़ोल्डर और कोड की फ़ाइलों के प्रबंधन के आसपास बनाया जाता है।

मुझे पूरी तरह से कुछ मिल रहा है जो टैब नहीं होना पसंद कर सकता है और मैं यह नहीं कह रहा हूँ कि जो है उससे छुटकारा पाएं लेकिन एक समर्थित टैब वर्कफ़्लो अच्छा होगा।
Tue, Apr 5, 2016 को 7:32 AM त्रुटि सूचनाओं पर ।@github.com ने लिखा:

यदि आप टैब लागू करते हैं, तो कृपया कई फ़ाइलों के लिए कई पंक्तियों का समर्थन करें। मैं घृणा करता हूँ
मेरे टैब बार पर स्क्रॉलबार होना। मेरा पसंदीदा टैब कार्यान्वयन टैब है
स्टूडियो https://tabsstudio.com/।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।

इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/224#issuecomment -205834354

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

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

@indiejames

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

दो अलग-अलग नेविगेशन वर्कफ़्लोज़ या दो से अधिक का समर्थन करना बहुत मुश्किल नहीं है, वास्तव में मुश्किल क्या है जो डिज़ाइन को सही बना रहा है!

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

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

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

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

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

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

जाहिर है यह एक लंबी अवधि नहीं हो सकती है, लेकिन अधिक प्रतिक्रिया उम्मीद के साथ कुछ अलग दृश्य बिंदुओं को चोट नहीं पहुंचा सकती है।

मुझे वास्तव में उम्मीद है कि कुछ पायथन देव और c / c ++ देव बैठक में होंगे क्योंकि उनके वर्कफ़्लो एक जावास्क्रिप्ट देव के वर्कफ़्लो के लिए अलग हैं

धन्यवाद स्टीवन मेरे साथ बात करने के लिए समय निकालने के लिए!
समुदाय के साथ यह जुड़ाव वास्तव में उत्साहजनक है, और मैं आनंद ले रहा हूं
vscode विकास के बाद!

6 अप्रैल 2016 को 19:41 पर, माइकल वालेस लौवरेंस < सूचनाएं @github.com

लिखा था:

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

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

मैं वास्तव में उम्मीद करता हूं कि कुछ अजगर देव और सी / सी ++ देव बैठक में होंगे
उनके वर्कफ़्लो एक जावास्क्रिप्ट देव वर्कफ़्लो के लिए अलग है

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/224#issuecomment -206261939

धन्यवाद @TurkeyMan , आज पहले आपके साथ शानदार चैटिंग।

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

इस सप्ताह हम जो वार्तालाप कर रहे हैं, वे सभी 1: 1 वार्तालाप हैं, जिसके दौरान हम उन समस्याओं के विवरण पर चर्चा करते हैं जो प्रत्येक व्यक्ति ने अनुभव की हैं। इससे हमें उन समस्याओं की गहरी समझ मिल सकती है जिन्हें हमें हल करने की आवश्यकता है।

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

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

+1
बुध पर, अप्रैल 6, 2016 को 7:36 पूर्वाह्न पीटर पेट्रोव सूचनाएं @github.com पर
लिखा था:

@stevencl https://github.com/stevencl सारांश पोस्ट करना संभव है
हममें से जो असमर्थ हैं, उन सत्रों (या इससे भी बेहतर, रिकॉर्डिंग) के लिए
भाग लेने के लिए, लेकिन अभी भी प्रतिक्रिया प्रदान करने में रुचि रखते हैं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।

इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/224#issuecomment -206405009

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

1. माउस-कम नेविगेशन
2. खुली फ़ाइलों के सेट के भीतर आगे और पीछे नेविगेट करने की क्षमता
3. आसानी से फ़ाइलें बंद करें

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

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

मैं खोली गई फ़ाइलों के बीच जल्दी से स्विच करने के लिए कीबोर्ड का उपयोग करने में असमर्थ हूं, कि _in my head_ एक लिंक की गई सूची बनाते हैं। जिस क्रम में मैं उन्हें खोलता हूं, वह उस क्रम के समान ही महत्वपूर्ण है, जिस क्रम में मैं उन्हें बंद करता हूं। मुझे Ctrl + Tab बेकार लगता है, क्योंकि मुझे उस सूची में एक-एक करके फ़ाइल नाम पढ़ने हैं और फिर पता लगाना है कि किससे टैब करना है। मैं बहुत तेजी से 5-8 खोली गई फ़ाइलों के माध्यम से फ्लिप करने के लिए दाईं ओर से केवल एक सामग्री को पहचान सकता हूं, जबकि यह फ़्लैश कर रहा है या बस यह जानकर कि "सूची" में मेरी वांछित फ़ाइल कहाँ है।

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

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

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

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

सिर्फ इसलिए कि किसी ने इसका उल्लेख नहीं किया है और मुझे संदेह है कि मैं इस पर अकेला नहीं हूं: मेरे लिए एक संपादक में सभी स्थानिक स्मृति के बारे में है - यानी मैं कहां हूं, और मेरे आसपास सामान कहां है?

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

मेरे लिए, एक समय-क्रमबद्ध फ़ाइल इतिहास मक्खियाँ अंतरिक्ष की इस सहज समझ के विरुद्ध जाती हैं। अगर मुझे पता है कि "main.java" या मेरे कीबोर्ड की T कुंजी एक निश्चित स्थिति में है, तो मैं नहीं चाहता कि जब तक मैं शारीरिक रूप से और जानबूझकर इसे स्थानांतरित नहीं कर दूं। यदि यह अपने आप चलता है, तो मुझे इसे रोकने और सोचने और खोजने की आवश्यकता है। उन पहियों के साथ एक टीवी रिमोट की कल्पना करें जो अपने आप ही अपने घर के चारों ओर चले गए, या एक कीबोर्ड जो कि हाल ही में आपके पत्र का उपयोग करने के आधार पर कुंजियों को फिर से व्यवस्थित करता है! यह अराजकता होगी! :-)

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

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

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

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

तो क्या यह संभव है _ अन्याय संभव है कि आपमें से कुछ "मैं टैब के बिना नहीं रह सकता" ने अन्य वर्कफ़्लोज़ का पता नहीं लगाया है? यदि हां, तो क्या यह कोशिश करने के लायक नहीं है कि क्या भुगतान आपकी उत्पादकता बढ़ा रहा है?

उन लोगों में से जिन्होंने टैब के बिना काम करने की कोशिश की है और टैब को अनुकूलित या ईमानदारी से महसूस नहीं कर सकते हैं, जिससे आप अधिक उत्पादक बन सकते हैं, मैं स्वीकार कर सकता हूं कि यह सिर्फ एक ईमानदार असहमति है। लेकिन उन लोगों के लिए जो शारीरिक रूपकों के लिए बहस करते हैं क्योंकि "उन्होंने 30 साल तक काम किया है!" मैं पूछूंगा कि क्या हमें वास्तव में _another_ TextMate / उदात्त / परमाणु की आवश्यकता है? क्या हमें लिफाफा स्थानांतरित करने की कोशिश नहीं करनी चाहिए?

मुझे इसमें कोई संदेह नहीं है कि मैं यहाँ अल्पमत में हूँ (लेकिन यह मुझे गलत नहीं बनाता है), इसलिए यह आखिरी टिप्पणी है जिसे मैं करने जा रहा हूँ। बेझिझक ढेर करें :)

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

@indiejames
टैब मेरे लिए उत्पादकता के बारे में नहीं हैं। इसके संज्ञान के बारे में।

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

@indiejames मैं बहुत सारे टैब के बीच नेविगेट करने के लिए ctrl + (Shift +) टैब का उपयोग पकड़ @ मैट 1 के रूप में ही है - तथ्य यह है कि ctrl + टैब सबसे हाल ही में उपयोग किए गए आदेश में संचालित होता है। मुझे यह याद नहीं है कि मैंने आखिरी और सेकंड-टू-लास्ट में कौन सी फ़ाइल देखी थी, लेकिन मेरे लिए यह देखना / याद रखना बहुत आसान है कि मैंने उन्हें किस क्रम में खोला / व्यवस्थित किया। सबलिम टेक्स्ट ने MRT टैब को ctrl + (Shift +) टैब को भी डिफॉल्ट किया। गण; मैं हमेशा इसे बदल देता हूं, क्योंकि इसमें एमआरयू और दृश्यमान आदेश दोनों के लिए आदेश हैं।

मुझे याद है कि दिन में कुछ वेब ब्राउज़र (क्या यह प्री-ब्लिंक ओपेरा हो सकता है?) ने डिफ़ॉल्ट रूप से भी ctrl + टैब के लिए MRU का इस्तेमाल किया था, संभवतः अनुमान लगा रहा है कि चूंकि OS इसे ऐप्स के लिए करते हैं, इसलिए ब्राउज़र भी ऐसा कर सकता है; मैंने पाया कि यह भयानक रूप से अनपेक्षित है, और मुझे जो वास्तव में वापस स्विच करना चाहता था, उसे खोजने के लिए अतिरिक्त ध्यान देना पड़ा ... जो, अनुमान लगाता है, इस प्रक्रिया को _slower_ बनाता है।

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

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

• हाल की फ़ाइलों को जल्दी खोलने के लिए Ctrl + E / ⌘ + E का उपयोग करना।
• हाल की फ़ाइलों को स्विच करने के लिए Ctrl + Tab का उपयोग करना

वैसे, जो लोग टैब पसंद करते

@ bgashler1
मुझे कीबोर्ड शॉर्टकट पसंद हैं। ऐसा नहीं है कि मैं सबसे तेज टाइपिस्ट हो सकता हूं, लेकिन क्योंकि मैं उन्हें कम ध्यान भटकाता हूं तो माउस / ट्रैकपैड को स्थानांतरित करना।

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

बायां फलक

मॉडल 1 फ़ाइल (टैब) | देखें 1 फाइल (टैब) | नियंत्रक 1 फ़ाइल (टैब)

राइट पेन

मॉडल 2 फ़ाइल (टैब) | 2 फ़ाइल देखें (टैब) | नियंत्रक 2 फ़ाइल (टैब)

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

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

बस मेरे 2 ¢ ...

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

1. कीबाइंडिंग को काम करने वाली फ़ाइलों को बंद करना चाहिए, उन्हें काम करने वाली फ़ाइलों की सूची और एमआरयू (सबसे हाल ही में प्रयुक्त) स्टैक से हटा देना चाहिए। मेरे पास इसे पूरा करने के लिए निम्नलिखित कीबाइंडिंग हैं:

json { "key": "ctrl+shift+w", "command": "workbench.files.action.closeAllFiles" }, { "key": "ctrl+w", "command": "workbench.files.action.closeFile" },

1. संपादक में फाइलें "स्टैक्ड" होनी चाहिए, ताकि जब आप एक फाइल बंद करें, तो एमआरयू स्टैक में आखिरी फाइल दिखाई जाए।
2. ctrl + Shift + t को हाल ही में बंद किए गए टैब को पुनर्स्थापित करना चाहिए। यह कीबाइंडिंग vscode में workbench.action.tasks.test साथ संघर्ष करता है लेकिन यह टैब्ड वातावरण में एक बहुत ही मानक हॉटकी है। मैंने यहां कमांड के लिए एक फीचर अनुरोध बनाया https://github.com/Microsoft/vscode/issues/3989
3. ctrl + tab और ctrl + shift + टैब को केवल "वर्किंग फाइल्स" लिस्ट में फाइलों के माध्यम से घुमाया जाना चाहिए, न कि उन फाइलों को जिन्हें "प्रिव्यू" किया गया (एक्सप्लोरर में क्लिक करें और फिर नेविगेट करें)।
4. मैं चाहता हूं कि संपादक के शीर्ष पर मेरी काम करने वाली फाइलें रखी जाएं। इसके कारण हैं:
   
   
   
   • मैं अपनी कामकाजी फ़ाइलों को नेत्रहीन रूप से देखने में सक्षम होना चाहता हूं, चाहे मैंने किस साइडबार को खोला हो। संबंधित: https://github.com/Microsoft/vscode/issues/3360
   
   
   • लगभग 2 दशकों से मैं अपनी कार्यशील फाइलों के लिए संपादक के ऊपर देख रहा हूं। इसे तोड़ना एक कठिन आदत है।
   
   

@bpasero

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

मैं VSCode में Ctrl + Tab का काफी उपयोग करता हूं, लेकिन मुझे लगता है कि Visual Studio में अनुभव इतना बेहतर है क्योंकि फ़ाइलों के अलावा मैं UI के अन्य भागों में भी नेविगेट कर सकता हूं, मैं इसका उपयोग पैकेज कंसोल प्रबंधक में नेविगेट करने के लिए करता हूं, समाधान एक्सप्लोरर आदि ...

@ तीयर महान अंक!

[दर्शन चेतावनी]

ctrl+tab 'वर्किंग फाइल्स' की अवधारणा की तुलना में इतना अधिक उपयोगी क्यों है, क्योंकि यह खड़ा है? यह क्रूर प्रश्न है। निजी तौर पर, मुझे लगता है कि खेल में दो मुद्दे हैं।

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

दूसरे, ctrl+tab आपको _all_ उन फ़ाइलों को दिखाता है जिन्हें आपने हाल ही में, रिवर्स कालानुक्रमिक क्रम में देखा है। 'वर्किंग फाइल्स' आपको केवल उन्हीं को दिखाती है जिन्हें आपने या तो डबल-क्लिक किया या उसमें बदलाव किया और इस क्रम में कि आपने उन्हें खोलने की जहमत उठाई। मानदंड और आदेश मनमाना है और प्रोग्रामर के सोचने के तरीके से कोई लेना-देना नहीं है - कॉलर और फ़ंक्शन, वर्ग और उपभोक्ता के बीच आगे और पीछे कूदना।

(राय। माइलेज भिन्न हो सकती है।)

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

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

मुझे पता चला कि इस मुद्दे के संदर्भ में मैं उदासीनता से गायब था।

[
  { "key": "cmd+w", "command": "workbench.files.action.closeFile" },
  { "key": "cmd+shift+]", "command": "workbench.files.action.openNextWorkingFile" },
  { "key": "cmd+shift+[", "command": "workbench.files.action.openPreviousWorkingFile" }
]

@stephenmartindale मुझे यकीन नहीं है कि अगर किसी ने अभी तक 'पूर्वावलोकन फ़ाइलों' को अक्षम करने के लिए एक सुविधा अनुरोध किया है।

@stephenmartindale हम खुले रहने के लिए "पूर्वावलोकन फ़ाइलों" को पिन करने का एक तरीका देख रहे हैं - जिसमें केवल-पढ़ने वाली फाइलें शामिल हैं।

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

मुझे वास्तव में यहाँ उदात्तता का प्रवाह बहुत पसंद है। सिंगल क्लिक आप फ़ाइल के लिए कूद,
डबल क्लिक यह खुला रहता है।
शनिवार, 9 अप्रैल, 2016 को 11:49 बजे ब्रैड गैशलर सूचनाएं @github.com
लिखा था:

@stephenmartindale https://github.com/stephenmartindale हम देख रहे हैं
खुले रहने के लिए "पूर्वावलोकन फ़ाइलों" को पिन करने का एक तरीका है।

हम "प्रीव्यू फाइल्स" रखना पसंद करेंगे, क्योंकि कई बार लोग नहीं जानते हैं
वे किस फ़ाइल की तलाश कर रहे हैं जब तक कि उन्होंने कई (जो कर सकते हैं) नहीं खोली हैं
खुली फ़ाइल अव्यवस्था की अवांछनीय मात्रा में परिणाम)।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/224#issuecomment -207830702

@Tyriar , @ bgashler1 , @stevencl मुझे लगता है कि फीडबैक प्राप्त करने के लिए टैब और काम करने वाली फाइलों के लिए दो नए पोस्ट रखना बेहतर है।

बस मेरी राय है, लेकिन मुझे लगता है कि यह दोनों विशेषताओं पर चर्चा करने से बेहतर होगा कि यह बहुत लंबा हो। :)

This कृपया ऐसा न करें, या कम से कम इसे वैकल्पिक बनाएं। स्वच्छ टैब-मुक्त यूआई वीएस कोड के बारे में मेरी सबसे पसंदीदा चीजों में से एक है।

@tobico यह सब या कुछ भी नहीं होना चाहिए ... आप जानते हैं, जहां तक ​​मुझे लगता है कि मैं काम करने वाली फ़ाइलों और टैब दोनों को वैकल्पिक और अभी तक उन लोगों के साथ अभिन्न होना चाहता हूं जो उस अनुभव को प्राप्त करना चाहते हैं।

मैं दूसरा कहना चाहूंगा कि Ctrl + W न केवल वर्तमान संपादक को बंद करना चाहिए, बल्कि इसी खुली कार्यशील फ़ाइल को भी। मेरे लिए यह वर्तमान कार्यान्वयन में सबसे बड़ी कमी है। वह तथ्य यह है कि Ctrl + Tab सभी हालिया फाइलों को सूचीबद्ध करता है, न कि केवल काम करने वाली फाइलों में। दूसरे विचार पर, तीसरा कैविएट यह होगा कि सिंगल क्लिक एक फ़ाइल को काम करने वाली फ़ाइल के रूप में नहीं खोलता है, लेकिन इसे संपादित करता है।

+1

@ csholmq आप अब ऐसा कर सकते हैं, https://github.com/Microsoft/vscode/issues/224#issuecomment -207507479 में कस्टम कीबाइंडिंग

@Tyriar यह मेरे लगभग सभी

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

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

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

साथ ही, टॉप टैब्स मानव आंखों के लिए बेहतर हैं। आप शीर्ष टैब शीर्षक और मुख्य क्षेत्र कोड एक ही समय में स्कैन कर सकते हैं। लेकिन आप मुख्य कोड के साथ working files नहीं पढ़ सकते हैं। इसे स्वयं आज़माएं। इसके अलावा, टैब व्यापक हैं, माउस आंदोलन के लिए बेहतर हैं। (यहां तक ​​कि आप इस पर ध्यान केंद्रित नहीं करेंगे, यह अधिक पूर्वानुमान है)

+1/0

+1

बस मेरी व्यक्तिगत राय है, लेकिन कृपया, -1, +1 पोस्ट करना बंद करें ... मेरा मतलब है कि यह सुझाव देने के अलावा कि आप इस सुविधा को पसंद या नापसंद करते हैं कि प्रतिक्रिया / इमोटिकॉन का उपयोग किया जा सकता है क्योंकि यह आपके अनुभव और इसके बारे में कुछ नहीं कहता है यदि आप पहले से ही एक पोस्ट लिख रहे हैं, तो सुनिश्चित करें कि यह उपयोगी है! मुझे यकीन है कि आपके पास चीजों पर अपना स्वयं का संरक्षक है और आप उन्हें कैसे काम करना चाहते हैं! अन्यथा, सिर्फ इमोटिकॉन्स का उपयोग करें।

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

@ csholmq मैं नहीं जानता कि अगर मैं आपको सही तरीके से

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

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

जब आप कुछ नया करना चाहते हैं तो एक सर्वेक्षण काम नहीं करता है। उदाहरण:

इनमे से कौन सा नगेटिंग स्टाइल आपके लिए सबसे अधिक उपयोगी होगा?

• कुछ कुछ। (कुछ नया आज़माएं जो बेहतर हो सकता है)
• टैब्स। (अच्छा पुराना वर्कस्टाइल जिसे आपने प्यार करना सीखा था)।

बेशक टैब जीत जाएगा। लेकिन संभवतः दूसरा विचार एक नए मानक नेविगेशन UI के लिए मार्ग प्रशस्त कर सकता है।

सच कहूं तो, मेरे लिए वीएस कोड की परिभाषित विशेषताओं में से एक टैब की अनुपस्थिति थी। मुझे एहसास भी नहीं था (पहले) कि वे गायब थे! यह बहुत ही दिलचस्प दृष्टिकोण था।

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

सब कुछ एक ही होने की दुनिया में, यह एक पहचान होने के लिए ताज़ा महसूस करता है।

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

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

@RussBaz मुझे नहीं लगता कि टैब की संख्या को सीमित करना एक अच्छा विचार है क्योंकि यह संख्या उपयोगकर्ता से उपयोगकर्ता में बदल सकती है लेकिन शायद यह एक विकल्प कुछ इस तरह हो सकता है:

tabs.autoClose = "नहीं-दृश्यमान", "बंद", "समय", x जहां x एक संख्या है

यह एक अजीब विचार है। अगर मुझे 16 टैब पसंद हैं और आपको 4 पसंद हैं, तो यह आसान है। आप 4 टैब का उपयोग करते हैं और मैं 16 का उपयोग करूंगा! क्यों कहते हैं कि मेरा रास्ता मेरे मुकाबले बेहतर है, या इसके विपरीत। वैसे भी यह क्या है? यहां तक ​​कि टैब के बारे में बातचीत भी बेकार की तरह है, जब तक कि टैब विकल्प / प्राथमिकता में सक्रिय / निष्क्रिय न हो जाएं। जो लोग टैब नहीं चाहते हैं, महान! जो लोग उन्हें चाहते हैं, छोटे चेकबॉक्स की जांच करें! वास्तव में, यह होना जरूरी नहीं है कि आपका रास्ता मेरी तुलना में बेहतर है, या यह कि मैं आपसे बेहतर जानता हूं।
+1
;)

उदाहरण का उपयोग करें: मैं वर्तमान में परमाणु में लगातार 6 टैब के बीच स्विच करता हूं।

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

@ मैं सहमत हूं और आपसे असहमत हूं। कुछ ऐसी चीजें हैं जिन्हें इनोवेट करने की जरूरत है, लेकिन पहले यह पूछना होगा कि टैब्स को हटाकर हम वर्कफ़्लो के बारे में क्या बेहतर कर सकते हैं। मेरे लिए, विकास के लिए मेरे द्वारा उपयोग किए जाने वाले प्रत्येक एकल संपादक में टैब इंटरफ़ेस है क्योंकि फ़ाइलों के सटीक नाम को याद किए बिना एक समय में 5-10 फ़ाइलों के बीच काम करना आम बात है और न ही उन्हें जिस क्रम में खोला जाता है। मुझे पूछना है, इस नए इंटरफ़ेस ने इसे कैसे बेहतर बनाया? यह अभिनव कैसे है? पहले पूछें, वे इसका उपयोग कैसे करते हैं, फिर पूछते हैं, मैं इसे कैसे बेहतर बना सकता हूं।

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

हम में से उन लोगों से पूछना जो टैब को स्विच करने के लिए टैब पसंद करते हैं, बस उतना ही अच्छा है
उन लोगों से पूछना जो टैब पर स्विच करने के लिए कोई टैब पसंद नहीं करते हैं। हम दोनों नहीं करना चाहते हैं
दूसरी विधि पर स्विच करें।

क्या अब हम 'Mac vs Windows', 'Android vs IPhone' प्रकार के साथ रुक सकते हैं
किस तरीके से बहस करना बेहतर है: 'टैब्स बनाम नो टैब्स'? वे दोनों अच्छे हैं
और विभिन्न लोगों की अपनी पसंद है।

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

क्या किसी के पास दोनों तरीकों के विकल्प के रूप में है जिसे आप चालू कर सकते हैं या कर सकते हैं
आपकी पसंद के आधार पर?

मुझे लगता है कि यह इन दो विकल्पों के लिए नीचे आता है:

1) एक प्राथमिकता के रूप में टैब जोड़ें। उन लोगों के लिए जो इसे पसंद करते हैं और जो लोग इसे पसंद करते हैं
नहीं है।

2) टैब को बिल्कुल भी न जोड़ें, भले ही मेरे पास उन्हें बंद करने का विकल्प हो।

आप विकल्प 2 के लिए भी मतदान क्यों करेंगे जब आपके पास उन्हें चालू करने का विकल्प होगा
बंद?
15 अप्रैल, 2016 को 7:32 बजे, "जेम्स मैकलॉघलिन" सूचनाएं @github.com
लिखा था:

@Measuring https://github.com/Measuring मैं आपसे सहमत हूं और आपसे असहमत हूं।
कुछ ऐसी चीज़े हैं जिन्हें इनोवेट करने की ज़रूरत है लेकिन पहले एक को पूछना होगा, क्या
वर्कफ़्लो के बारे में हम टैब निकालकर बेहतर बना सकते हैं। वैसे मेरे लिए, हर
विकास के लिए मेरे द्वारा उपयोग किए जाने वाले एकल संपादक का टैब इंटरफ़ेस है क्योंकि यह है
विकसित करने के लिए एक समय में 5-10 फ़ाइलों के बीच काम करने के लिए आम है
फाइलों का सही नाम याद रखना और न ही उन्हें खोलने के आदेश
, तो मुझे पूछना होगा कि इस नए इंटरफ़ेस ने इसे कैसे बेहतर बनाया? कैसे
यह अभिनव है? पहले पूछें, वे इसका उपयोग कैसे करते हैं, फिर पूछते हैं, मैं कैसे बना सकता हूं
यह बेहतर। तीन मिनट के मुद्दे के लिए, मैं मान रहा हूं कि कोड है
इतना अलग नहीं है तो उदात्त या परमाणु और यदि शुरू से ही सही
इसके साथ काम करने या किसी को कुशलता से दिखाने के लिए कि उन्हें क्या करने की आवश्यकता है
फ़ाइलों के बीच कुछ काम करने के लिए, तो मैं कुछ काम करता हूँ का उपयोग करेंगे
मेरी जरूरतों के लिए बेहतर है और कोड को सड़क के कुछ संस्करणों में देखें
जब यह तैयार है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/224#issuecomment -210705545

@ tones411 कुछ लोग विकल्प 2 को सिर्फ इसलिए

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

कुछ लोग विम बफ़र्स की तरह कुछ करना चाहते हैं और न तो टैब और न ही काम करने वाली फ़ाइलों को रखना चाहते हैं।

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

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

चलो बस असहमत होने के लिए सहमत हैं, यह ठीक है। जब तक टैब वैकल्पिक हैं
उन लोगों की तुलना में जो उन्हें नहीं चाहते उनका उपयोग नहीं करना है।

मेरा व्यक्तिगत रूप से मानना ​​है कि वे उपयोगी हैं, लेकिन मैं किसी को रोकने नहीं जा रहा हूं
काम करने वाली फ़ाइलों का उपयोग करने से यदि उनके लिए काम करता है। यह मेरे लिए काम नहीं करता है।
शुक्र पर, १५ अप्रैल २०१६ को सुबह १०:२० बजे tones411 सूचनाएं @github.com ने लिखा:

हम में से उन लोगों से पूछना जो टैब को स्विच करने के लिए टैब पसंद करते हैं, बस उतना ही अच्छा है
उन लोगों से पूछना जो टैब पर स्विच करने के लिए कोई टैब पसंद नहीं करते हैं। हम दोनों नहीं करना चाहते हैं
दूसरी विधि पर स्विच करें।

क्या अब हम 'Mac vs Windows', 'Android vs IPhone' प्रकार के साथ रुक सकते हैं
किस तरीके से बहस करना बेहतर है: 'टैब्स बनाम नो टैब्स'? वे दोनों अच्छे हैं
और विभिन्न लोगों की अपनी पसंद है।

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

क्या किसी के पास दोनों तरीकों के विकल्प के रूप में है जिसे आप चालू कर सकते हैं या कर सकते हैं
आपकी पसंद के आधार पर?

मुझे लगता है कि यह इन दो विकल्पों के लिए नीचे आता है:

1) एक प्राथमिकता के रूप में टैब जोड़ें। उन लोगों के लिए जो इसे पसंद करते हैं और जो लोग इसे पसंद करते हैं
नहीं है।

2) टैब को बिल्कुल भी न जोड़ें, भले ही मेरे पास उन्हें बंद करने का विकल्प हो।

आप विकल्प 2 के लिए भी मतदान क्यों करेंगे जब आपके पास उन्हें चालू करने का विकल्प होगा
बंद?
15 अप्रैल, 2016 को 7:32 बजे, "जेम्स मैकलॉघलिन" सूचनाएं @github.com
लिखा था:

@Measuring https://github.com/Measuring मैं आपसे सहमत हूं और आपसे असहमत हूं।
कुछ ऐसी चीज़े हैं जिन्हें इनोवेट करने की ज़रूरत है लेकिन पहले एक को पूछना होगा, क्या
वर्कफ़्लो के बारे में हम टैब निकालकर बेहतर बना सकते हैं। मेरे लिए अच्छा है,
हर एक
विकास के लिए मेरे द्वारा उपयोग किए जाने वाले एकल संपादक का टैब इंटरफ़ेस है क्योंकि यह है
विकसित करने के लिए एक समय में 5-10 फ़ाइलों के बीच काम करने के लिए आम है
फाइलों के सटीक नाम को याद रखना और न ही उन्हें खोले जाने का आदेश
उन्हें
, तो मुझे पूछना होगा कि इस नए इंटरफ़ेस ने इसे कैसे बेहतर बनाया? किस तरह
है
यह अभिनव है? पहले पूछें, वे इसका उपयोग कैसे करते हैं, फिर पूछते हैं, मैं कैसे कर सकता हूं
बनाना
यह बेहतर। तीन मिनट के मुद्दे के लिए, मैं उस कोड को मानने जा रहा हूं
है
इतना अलग नहीं है तो उदात्त या एटम और यदि शुरू से ही सही
मैं
इसके साथ काम करने या किसी को कुशलता से दिखाने के लिए कि उन्हें क्या करने की आवश्यकता है
फ़ाइलों के बीच कुछ काम करने के लिए, तो मैं कुछ का उपयोग करेंगे
काम करता है
मेरी जरूरतों के लिए बेहतर है और कोड को सड़क के कुछ संस्करणों में देखें
जब यह तैयार है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/224#issuecomment -210705545

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/224#issuecomment -210712143

+1

मैं पिछले ~ महीने से इस सूत्र का पालन कर रहा हूं और जब से मैंने कोड को अपने मुख्य संपादक के रूप में स्विच किया है और फ़ाइल नेविगेशन व्यवहार से लगातार परेशान हूं। मैंने वर्किंग सेक्शन सेक्शन में जाने के लिए समय _trying_ खर्च किया है, जिसे आप स्वीकार करते हैं कि आप अधिक-से-कम वैसे भी हैं, और Ctrl + Tab और Ctrl + P। मैं कोड के साथ सुपर खुश हूं और यह आसानी से मेरा पसंदीदा संपादक है, लेकिन ये फ़ाइल नेविगेशन विकल्प बहुत खराब कल्पना करते हैं यह समझना मुश्किल है कि उन्हें पहली जगह में कैसे सोचा गया था।

इनमें से अधिकांश का उल्लेख किया गया है, लेकिन यहां मेरी पकड़ है:

डब्ल्यूएफ सूची अनिवार्य रूप से बेकार है, क्योंकि संपादक विंडो बंद करना वास्तव में डब्ल्यूएफ से फाइल को बंद नहीं करता है। मुझे वास्तव में एक फ़ाइल _twice_ को बंद करने की आवश्यकता है, और ऐसा करने के लिए माउस का उपयोग करें (Ctrl + W _and_ फ़ाइल को DNS सर्वर से बंद करें)। अगर मैं फ़ाइल को खुला छोड़ना चाहता था, तो मैंने Ctrl + W नहीं दबाया होगा - Ctrl + W को दबाने का कोई मतलब कैसे बनता है और एक फ़ाइल "ओपन" (WF में दिखाई देने वाली) को छोड़ देता है। हाँ, यह आश्वस्त किया जा सकता है, लेकिन मैं WF के डिफ़ॉल्ट व्यवहार के बारे में बात कर रहा हूँ)।

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

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

मेरी राय में, फ़ाइल पर सिंगल या डबल क्लिक करने से मुझे _exact को समान व्यवहार देना चाहिए_, लेकिन यदि आप वास्तव में एक क्लिक "पूर्वावलोकन" चाहते हैं, जो WF / Ctrl + Tab में प्रदर्शित नहीं होता है, तो _obpret UI मार्कर_ होना चाहिए। सक्रिय संपादक विंडो एक पूर्वावलोकन है और जब आप इसे बदलेंगे तो यह चला जाएगा।

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

इन बिल्कुल हास्यास्पद संपादक पैनल, WF और फ़ोल्डर दृश्य व्यवहार मौजूद एकमात्र कारण _because वहाँ कोई tab_ हैं। यदि आप टैब जोड़ते हैं (संपादक पैनल के विभाजित होने पर एक विशेष पैनल पर डॉक किया गया), और सामान्य संपादक व्यवहार के लिए डिफ़ॉल्ट है जो _always को एक नया टैब_ में सब कुछ खोलना है, तो उस व्यवहार में से कोई भी आवश्यक नहीं है। बस मुझे यह तय करने दें कि मैं अपने पेड़ को कैसे नेविगेट करना चाहता हूं और मैं अपने टैब को कैसे स्टैक करना चाहता हूं, और मुझे "बेहतर तरीका" दिखाने की कोशिश करना बंद कर दें (जब तक कि आप वास्तव में _have_ बेहतर तरीके से नहीं - दैनिक कार्य के 6 महीने के बाद, मैं कर सकता हूं। पूर्ण निश्चितता के साथ कहते हैं कि वर्तमान तरीका _not_ मेरे लिए बेहतर है)।

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

आप लोगों ने इस संपादक के साथ एक शानदार काम किया है और मैं इसका उपयोग करना जारी रखूंगा। अगर हम देख सकते हैं:

1. टैब
2. WF को अक्षम करें
3. ऑटो-नेवीगेटिंग फोल्डर ट्री बंद करें
4. Ripoff अस्थायी संपादक पैनल में टैब करता है (जो मुख्य इंटरफ़ेस में अन्य संपादक पैनल के समान सभी व्यवहार साझा करता है)

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

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

धन्यवाद!

@ आपकी जानकारी के लिए धन्यवाद!

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

"explorer.autoReveal": false

मैं workbench.files.action.showActiveFileInExplorer को बाँधता हूं, ताकि मुझे ज़रूरत पड़ने पर एक्सप्लोरर में एक यादृच्छिक फ़ाइल मिल सके।

@Tyriar मुझे यकीन नहीं है कि आप किस संस्करण का उल्लेख कर रहे हैं, लेकिन मैं इनसाइडर पर अद्यतित हूं और यह विकल्प अभी तक कुछ नहीं करता है।

: +1:

: +1:

@bpasero मैंने टैब के फायदे / नुकसान के बारे में इस बोर्ड पर पहले कुछ संदेश पढ़े हैं। मैं इस पर MSFT टीम के रुख को भी समझता हूं: टीम एक ही कोडिंग शैली के तहत एकजुट है और ctrl+tab और / या काम करने वाली फ़ाइलों के अनुभाग के बारे में रिफ्लेक्स के समान सेट को विकसित किया है। यह एक अच्छी बात है। सभी टीम के सदस्य सामान्य रूप से, चीजों को करने का एक समान प्रवाह रखते हैं। हालाँकि, हम उस टीम का हिस्सा नहीं हैं, और न ही हम रिफ्लेक्स के समान सेट को विकसित करना चाहते हैं। हमारे मौजूदा रिफ्लेक्स को आदर्श रूप से पूरा किया जाना चाहिए, मजबूर नहीं और प्रतिस्थापित किया जाना चाहिए। संपादक को उपयोगकर्ता की मदद करनी चाहिए।

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

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

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

यह वही है जो मैंने अपनी प्राथमिकताओं में रखा है: "explorer.autoReveal": false,

@anyong आप रहे हों तो सही @stephenmartindale, मुझे नहीं पता था कि कैसे नए इस सेटिंग था। यह अगले इंसाइडर्स बिल्ड पर उपलब्ध होना चाहिए।

खैर @stephenmartindale ने कहा। टैब के बिना हमारे पास Alt-Tab के अपने स्वयं के संस्करण के साथ notepad.exe है (जो कि ऊपर कई बार नोट किया गया है, टूट गया है)। मैं "वर्किंग फाइल्स" का उपयोग करने की कोशिश कर रहा हूं, जैसे कि वे साइड टैब थे, लेकिन एक हफ्ते के बाद मैं बहुत उदासीन होकर वापस जाने के लिए तैयार हूं और यह समस्या है, विशेष रूप से उस साइडबार को बनाने का कोई तरीका नहीं है ऐप में और क्या चल रहा है। "विज़ुअल स्टूडियो ..." नाम के साथ मुझे कम से कम विज़ुअल स्टूडियो एडिटर (टैब, और उन टैब को अपनी खिड़कियों में खींचने की क्षमता) की बुनियादी विशेषताओं की उम्मीद थी। क्यों वे हटा दिया है कि कार्यक्षमता अस्पष्टीकृत है। हो सकता है कि मैं कुछ महीनों में वापस जाँच करूँ और यह देखूँ कि क्या उन्होंने एक बिल्ड पर प्री-अल्फा टैग लगाने के लिए काफी कुछ हासिल कर लिया है। अभी यह एक यूआई प्रयोग से अधिक कुछ नहीं है, एकमात्र सवाल यह है कि क्या यह पहले से ही विफल है या क्या यह विफलता की कगार पर है?

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

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

@SturmB सब्लिम एकमात्र ऐसा संपादक नहीं है जो मौजूद है और मुझे नहीं लगता है कि उन्होंने VSCode को अभी तक एक और उदात्त कॉपीकैट बनाया है, एटम की तरह नहीं है लेकिन सभी संपादक सुविधाओं को साझा कर रहे हैं जो कि एक अच्छी बात है, इस तरह से आपको विकल्प मिलते हैं !

VSCode सब्लिम की तरह काम नहीं कर रहा है क्योंकि वे बहुत अलग हैं, VSCode का उद्देश्य एक कोड एडिटर और एक IDE के बीच का मध्य मैदान होना है जबकि Sublime यह दावा नहीं करता है कि, VSCode के लोगों के बड़े दर्शक हैं, जिन्हें लेकर लोग विजुअल स्टूडियो के लिए विम का उपयोग करें।

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

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

मुझे काम करने वाली फाइलें अवधारणा पसंद हैं। जब बहुत सी फाइलें खुली हों तब टैब अच्छी तरह से स्केल नहीं करता है। जो भी हो, कृपया कार्यशील फाइलों को नियंत्रित रखें!

@helmbold मैं वास्तव में उत्सुक हूँ - _how_ क्या आप उन्हें कुशलता से इस्तेमाल करते हैं? मैंने _tried_ किया है और मैं सिर्फ यह पता लगाने का तरीका बता रहा हूं कि किस तरह से गंदगी का अंदाजा लगाया जा सकता है। (इसके अलावा, इस मुद्दे में कहीं न कहीं, टीम ने कहा कि काम करने वाली फाइलें वास्तव में सिर्फ एक सोच थी, एक नियोजित सुविधा नहीं थी।)

@ सालक :

असली समस्या डिजाइन सही हो रही है और सुनिश्चित करें कि अनुभव सभी के लिए बहुत अच्छा लगता है, ये जो टैब से प्यार करते हैं और जो इसे नफरत करते हैं।

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

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

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

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

सिर्फ इसलिए कि उदात्त / एटम या किसी अन्य कार्यक्रम में टैब होता है और यह अच्छी तरह से काम करता है इसका मतलब यह नहीं है कि आप वहां काम करने वाली सभी चीजों को ले सकते हैं और इसे अपने कार्यक्रम में सेंक सकते हैं, यह नहीं है कि चीजें कैसे काम करती हैं, वास्तव में यह कैसे चीजें _can_ विफल होती हैं! यह वहां सफल है क्योंकि पूरा पैकेज इसे सफल बनाता है।

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

: +1:

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

अब हम आपकी प्रतिक्रिया प्राप्त करने के लिए अपने शुरुआती डिजाइनों को आपके साथ साझा करना चाहेंगे। हम गुरुवार 21 अप्रैल को शाम 4 बजे बीएसटी पर एक Google हैंगआउट की मेजबानी करेंगे। यदि आप हमसे जुड़ना चाहते हैं, तो कृपया उस समय इस लिंक पर क्लिक करें: https://hangouts.google.com/call/u3wnrhjja5h47ovt7piatelkxme

यह हमारी पहली सार्वजनिक बैठक होगी और हम इसके लिए तत्पर हैं।

मैं विशेष रूप से (वेबस्टॉर्म से आया) VSCode का उपयोग कर रहा हूं और मुझे टैब याद नहीं है। शुरू में मैंने सोचा था कि मैं करूंगा, लेकिन मुझे काम की फाइलें ज्यादा पसंद आने लगीं क्योंकि मैं कम जगह में ज्यादा देख सकता था और बिना यह सोचे कि स्क्रीन पर चीजों को व्यवस्थित या व्यवस्थित कैसे किया जा सकता है। अब मैं मुख्य रूप से CTRL + TAB का उपयोग करता हूं।

मुझे लगता है कि अगर कुछ पारंपरिक टैब एक आधिकारिक _extension_ या एक ऑप्ट-इन _option_ होना चाहिए। व्यक्तिगत रूप से मैं वर्तमान अनुभव को बढ़ाने के लिए टैब के अलावा कुछ और की उम्मीद कर रहा हूं।

मुझे क्या लगता है कि CTRL + TAB की कमी सक्रिय संपादक फलक का संदर्भ है। अगर मेरे पास 2 एडिटर पैन खुले हैं, तो मैं CTRL + TAB देखना चाहता हूं, फ़ाइल इतिहास को उन फ़ाइलों को फ़िल्टर कर दें, जो पूरी तरह से एप्लिकेशन में खोली गई सभी फाइलों के बजाय

अच्छा काम करते रहें।

एक अन्य सुझाव .. साइडबार के छिपे होने पर वर्किंग फाइल्स की सूची देखने के लिए बेहतर डिफ़ॉल्ट कुंजी कॉम्बो रखना अच्छा होगा। मुझे अभी हाल ही में पता चला कि CTRL + K CTRL + P से पता चलता है कि मुझे क्या चाहिए लेकिन CTRL + TAB की तुलना में इसे खींचना अधिक कठिन है। जैसा कि मैंने CTRL + TAB के साथ सुझाव दिया है, कार्यशील फाइलें पॉपअप सक्रिय संपादक फलक के आधार पर कुछ संदर्भ से लाभ उठा सकती हैं। हो सकता है कि इसे क्रमबद्ध किया जा सके ताकि सक्रिय संपादक फलक में खुलने वाली कार्यशील फ़ाइलों की सूची बाकी हिस्सों से ऊपर हो।

@RyanEwen मुझे लगता है कि आप पहले एक शॉर्टकट उपयोगकर्ता नहीं हैं? क्योंकि इंटेलीज आइडिया प्लेटफॉर्म में एक ही शॉर्टकट है और टैब्स को कहीं भी रखने में सक्षम है (टॉप, बॉटम, लेफ्ट, राइट, कोई नहीं)। जब इसे लेफ्ट / राइट पर रखा जाता है, तो यह VSCode में वर्किंग फाइल्स के समान काम करता है। कुछ प्रयोग करना बहुत अच्छा होगा। शीर्ष टैब के साथ CTRL + TAB कॉम्बो का उपयोग करके वेबस्टॉर्म पर वापस जाना, यह देखने के लिए कि क्या आपको इसकी आवश्यकता नहीं है या इसे केवल वर्कअराउंड के रूप में स्वीकार करने के लिए मजबूर किया जा रहा है। वेबस्टॉर्म में CTRL + E फ़िल्टर करने के प्रकार (खोज करने के लिए) के साथ हाल ही की फ़ाइलें भी हैं।

यदि आपने अपने वर्कफ़्लो में MOUSE का उपयोग कर रहे थे तो किसी ने भी टैब्स को नहीं कहा।

: +1:

@KayLeung मैंने

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

मैंने बस Adobe Brackets की कोशिश की, और उनकी कार्य फ़ाइलों की सूची फलक द्वारा विभाजित है। यदि आपके पास एक वाम और एक दाएँ फलक है, तो VSCode में एक के बजाय साइडबार में कार्यशील फ़ाइलों ("वाम" और "दाएँ") की 2 सूचियाँ हैं। बुरा हल नहीं है। ऐसा कुछ भी बुरा नहीं लगेगा (सक्रिय संपादक फलक पर आधारित CTRL + TAB के संदर्भ जोड़ने के मेरे अन्य सुझाव के अलावा)।

@RainEwen आपने बहुत अच्छी बात की है। मैं हमेशा अपने आईडीई के किसी भी खुले उदाहरण के लिए 2 पैन के साथ काम करता हूं। मेरे पास 2 स्क्रीन पर 2 ओपन इंस्टेंस हो सकते हैं, 4 ओपन पैन के लिए। मैं उस पर अपनी उंगली नहीं डाल सकता था लेकिन आपने किया। एक ही सूची होने पर दो (या अधिक?) खुले पैन हैं, वर्तमान कार्य फाइलों के कार्यान्वयन के साथ समस्या है जिसने इसे मेरे लिए अनुपयोगी बना दिया है। यहाँ विशिष्ट होने के लिए धन्यवाद।

एक दोस्ताना याद दिलाता है कि हम (खुद, @bpasero और @ bgashler1) टैब और काम की फाइलों के लिए अपने नवीनतम डिजाइनों को आज शाम 4 बजे ब्रिटिश समर टाइम में साझा करेंगे।

इस लिंक पर शाम 4 बजे BST: https://hangouts.google.com/call/u3wnrhjja5h47ovt7piatelkxme पर हमसे जुड़ें

जो भी हैंगआउट में शामिल होने की योजना बना रहा था, उसके लिए अनुस्मारक - यह अभी है इसलिए ऊपर दिए गए लिंक पर क्लिक करें। अब तक केवल ~ 5 लोग।

मैं वास्तव में वहां रहना पसंद करूंगा लेकिन यह सुबह 11 बजे है और मैं इसमें शामिल होने में असमर्थ हूं। मुझे लगता है कि किसी के पास लिखित में साझा करने के लिए कुछ सामान होगा? : डी

संक्षिप्त अवलोकन:

1. टैब्स और काम करने वाली फाइलें ("ओपन एडिटर्स" नाम बदलकर) बिल्कुल उसी तरह का व्यवहार करती हैं, यह सिर्फ इस बात पर निर्भर करता है कि आप टॉप (टैब) पर विजुअल चाहते हैं या लेफ्ट (ओपन एडिटर्स)
2. टैब पैनल द्वारा नेत्रहीन शीर्ष पर समूहीकृत होते हैं, खुले संपादकों को हेडर्स "लेफ्ट", "राइट" के तहत एक साथ समूहीकृत किया जाता है।
3. एक पूर्वावलोकन टैब खोलने के लिए एक फ़ाइल पर क्लिक करें (या "खुले संपादक"); फ़ाइल को डबल-क्लिक करें, फ़ाइल को संपादित करें, या जारी रखने के लिए टैब को डबल-क्लिक करें
4. डीबगर सभी फ़ाइलों को पूर्वावलोकन फ़ाइलों के रूप में खोलता है, जब तक कि आप उपरोक्त विकल्पों में से एक को ले कर फ़ाइल को डीबग किए जाने के लिए जारी नहीं रखते
5. टैब / खुले संपादकों को पैनलों के बीच खींचा जा सकता है
6. टैब के पूरे समूह को स्थानांतरित करने के लिए पैनलों को खींचा जा सकता है

वास्तव में अच्छा लग रहा है, और व्यक्तिगत रूप से (बहुत समर्थक टैब समूह से यदि आप ऊपर मेरी पोस्ट पढ़ते हैं), मुझे लगता है कि मैं नए "ओपन एडिटर्स" को एक निष्पक्ष शॉट देकर खुश रहूंगा।

देवों के लिए अनुवर्ती विचार:

1. चूँकि टैब / खुले संपादकों का प्रवाह ठीक वैसा ही होता है, ऐसे में कुछ करना संभव होना चाहिए: खोजकर्ता के खुला रहने पर खुले संपादकों को दिखाएँ, और एक्सप्लोरर के बंद होने पर टैब दिखाएं। हम कोड के लिए क्षैतिज अचल संपत्ति बढ़ा सकते हैं और टैब एक्सेस बनाए रख सकते हैं। मान लें कि एक छुपा / शो टैब शॉर्टकट है, यह एक ही समय में उस और CTRL + B को दबाने के बराबर होगा - यदि यह काम करता है, तो यह सेटिंग्स में एक विकल्प होना चाहिए: autoShowTabsWhenExplorerClosed या कुछ और। यदि हमें अधिक टैब देखने की आवश्यकता है, तो हम या तो शेवरॉन पर क्लिक कर सकते हैं, या बस CTRL + B को बाएं पैनल में टैब देख सकते हैं। मुझे यकीन नहीं है कि अगर यह "भटकाव" होगा, लेकिन जब तक खुले संपादकों और टैब हमेशा एक समान और एक ही क्रम में होते हैं, मैं कल्पना कर सकता हूं कि यह बहुत अच्छा काम करेगा।
2. मुझे लगता है कि आपने उल्लेख किया है कि पहले बंद टैब CTRL + Tab + कुछ दृश्यों में से एक में उपलब्ध थे, लेकिन क्या आपने CTRL + SHIFT + T (पूर्ववत क्लोज़ टैब) शॉर्टकट के बारे में सोचा है जो पहले बंद टैब (क्रम में) को फिर से खोल देगा जो वे बंद थे)?

मैं केवल पिछले 15 मिनटों तक ही शामिल हो पाया था। दर्ज किया गया था?

मुझे निराशा हुई (लेकिन आश्चर्य नहीं) यह देखने के लिए कि टैब की संभावना है
डिफ़ॉल्ट बनें। एक आशा है कि आप लाइटवेट का संरक्षण करते रहेंगे
VS कोड का वातावरण और प्रगतिशील वर्कफ़्लो का पता लगाने के लिए।

धन्यवाद,

जेम्स

Thu, अप्रैल 21, 2016 को 11:07 पूर्वाह्न पर, किसी भी सूचनाएँ @github.com ने लिखा:

जो भी हैंगआउट में शामिल होने की योजना बना रहा था, उसके लिए अनुस्मारक - यह अभी पर है
ऊपर दिए गए लिंक पर क्लिक करें। अब तक केवल ~ 5 लोग।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/224#issuecomment -212963079

लगता है कि कुछ अच्छे विचार थे। मैं एक्शन में इसे देखने के लिए उत्सुक हूं।

FWIW (और यदि यह अभी भी प्रासंगिक है) तो मुझे अभी भी लगता है कि UI _by default_ में टैब न होना बेहतर है। अगर मैं साइडबार दिखाई नहीं दे रहा है, या CTRL + TAB, फ़ाइलों की एक सूची देखने के लिए क्लिक किया जा सकता है जो एक अच्छा साफ संपादक हैडर है, जो मैं वास्तव में उम्मीद कर रहा हूं :)

उन सभी के लिए धन्यवाद जो आज उपस्थित होने और हमें प्रतिक्रिया देने में सक्षम थे। हमने नोट्स ले लिए हैं और यहाँ GitHub मुद्दे का लगातार अनुसरण कर रहे हैं। हम सबकी बात सुन रहे हैं।

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

@ bgashler1 आप उल्लेख करते हैं कि आप एक समाधान में देख रहे हैं जो लोगों को यह चुनने की अनुमति देगा कि वे काम करने वाली फाइलें, टैब या दोनों चाहते हैं या नहीं? यह एक विकल्प है? प्रोजेक्ट और भाषा पर निर्भर करता है कि मैं जिस पर काम कर रहा हूं वह पॉवरशेल की तरह स्क्रिप्टिंग के लिए महान नहीं हो सकता है। :)

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

विज्वल डिज़ाइन

सबसे पहले, यह चित्र बताता है कि कैसे हम सोचते हैं कि टैब वीएस कोड में दिख सकते हैं:

हम एक हल्के, गैर-विचलित करने वाले लुक के लिए लक्ष्य कर रहे हैं, ऐसा कुछ जो वीएस कोड के बाकी हिस्सों के साथ अच्छी तरह से फिट बैठता है। हमने अभी तक ऐसा नहीं किया है कि यह एक हल्के विषय में कैसा दिखेगा।

जैसा कि आप ऊपर की छवि में देख सकते हैं, टैब में नाम के बाईं ओर एक करीब बटन होता है। जब फ़ाइल में सहेजे न गए परिवर्तन होते हैं तो हम एक गंदे संकेतक को दिखाते हैं जहाँ नज़दीकी बटन होता है।

टैब पर होवर करने से टैब में फ़ाइल के लिए पूर्ण पथ वाला टूलटिप दिखाई देगा।

टैब का पूर्वावलोकन करें

खुले टैब से पूर्वावलोकन टैब को स्पष्ट रूप से अलग करने के लिए हम टैब में शीर्षक को निम्न वायरफ्रेम के रूप में पुन: व्यवस्थित करते हैं।

हमने पूर्वावलोकन टैब को पूर्ण खुले टैब में बढ़ावा देने के लिए क्रियाओं पर चर्चा की:

• टैब के अंदर संपादन सामग्री
• एक्सप्लोरर में किसी फाइल पर डबल क्लिक करना
• टैब समूह में पूर्वावलोकन टैब पर डबल क्लिक करें

बाढ़

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

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

वर्तमान में अतिप्रवाह में एक टैब पर क्लिक करने से वह टैब दृश्य में आ जाएगा।

टैब नेविगेट करना

निम्न आदेश उपयोगकर्ताओं को टैब के बीच नेविगेट करने की अनुमति देते हैं:

• Ctrl-Tab सक्रिय टैब समूह के अंदर सभी टैब की एक सूची दिखाता है:
  
• Ctrl Alt Tab सभी टैब समूहों के अंदर सभी टैब की एक सूची दिखाता है
  
• त्वरित ओपन सभी टैब के रैखिक इतिहास को दर्शाता है
  

काम कर रही फाइलें

हमने संपादकों को खोलने के लिए काम करने वाली फाइलों का नाम बदलकर बेहतर तरीके से दर्शाया है कि यह वास्तव में क्या है।

खुले संपादकों की सूची टैब के लिए अनौपचारिक रूप से काम करती है। हम उन्हें केवल टैब के रूप में देखने के बजाय खोजकर्ता में सूचीबद्ध करते हैं।

यदि कोई फ़ाइल दो या अधिक संपादक समूहों में खुली है, तो हम इसे खुले संपादकों की सूची में दिखाते हैं:

कोई भी संपादक जो उपयोगकर्ता खोलता है, खुले संपादकों की सूची में दिखाई देता है। इसलिए, उदाहरण के लिए, संपादक अलग दिखाता है:

प्रत्येक समूह में केवल एक पूर्वावलोकन टैब होता है।

सक्रिय संपादक समूह के शीर्ष दाईं ओर स्थित शेवरॉन इंगित करता है कि संपादकों का ढेर है या नहीं।

इस मामले में, एक संपादक को बंद करने से संपादक को पूरी तरह से बंद करने के बजाय ढेर में उसके नीचे के संपादक का पता चल जाएगा।

संपादक को बंद करना (उदाहरण के लिए Ctrl-W के साथ) भी संपादक को खुले संपादकों की सूची से हटा देता है।

@stevencl

खुले टैब से पूर्वावलोकन टैब को स्पष्ट रूप से अलग करने के लिए हम टैब में शीर्षक को निम्न वायरफ्रेम के रूप में पुन: व्यवस्थित करते हैं।

इसे इटैलिकाइज़ करने के अलावा, यह बहुत अच्छा हो सकता है अगर टैब के रंगों को मंद करने का विकल्प था ताकि इसे _really_ स्पष्ट किया जा सके।

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

@eyalsk यह चर्चा में उल्लेख किया गया था कि टैब और खुले संपादकों को स्वतंत्र रूप से सक्षम होना चाहिए या दोनों / दोनों के लिए अक्षम होना चाहिए।

@ डियानगॉन्ग धन्यवाद! :)

Ctrl-Tab सक्रिय टैब समूह के अंदर सभी टैब की एक सूची दिखाता है:

आखिरकार! टैब या नहीं, यह वह व्यवहार है जिसकी मुझे प्रतीक्षा थी! मेरे फ़ाइल इतिहास में कोई और अधिक खो नहीं रहा है।

संपादक को बंद करना (उदाहरण के लिए Ctrl-W के साथ) भी संपादक को खुले संपादकों की सूची से हटा देता है।

महान! यह उम्मीद है कि अधिक सहज महसूस होगा और _Working files_ में अव्यवस्था को साफ करने में मदद करेगा।

अब मैं बस https://github.com/Microsoft/vscode/issues/5554 के बंद होने का इंतजार करूंगा।

हम्म मैं नहीं जानता कि क्या इस पर विचार किया गया था, लेकिन मैंने इसके बारे में अभी सोचा था, कई मॉनिटर सपोट! दृश्य स्टूडियो में मैं एक टैब को एक अलग मॉनिटर पर खींच सकता हूं और एक नया टैब विंडो / दृश्य बना सकता हूं, क्या ऐसा कुछ माना जा रहा है? मुझे लगता है कि एक नई VSCode प्रक्रिया बनाकर इसे हासिल करना संभव है और अंतर-प्रक्रिया संचार के माध्यम से प्रक्रियाओं के बीच टैब खींचें, वही खुले संपादकों के लिए जाता है, बस एक विचार :)

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

मैं आमतौर पर अपने आप को खुले टैब में दफनाता हूं जब तक कि मैंने काम की एक इकाई पूरी नहीं कर ली है और फिर उन सभी को उसी समय बंद कर देता हूं जब मैं प्रतिबद्ध होने के लिए जाता हूं।

धन्यवाद @eyalsk , हाँ हमने इस पर विचार किया। अंततः हम इसका समर्थन करने में सक्षम होना चाहते हैं, लेकिन कई प्रक्रियाओं के बीच संदर्भ साझा करने के लिए आवश्यक कार्य काफी महत्वपूर्ण है और इसलिए ऐसा होने की संभावना नहीं है जबकि हम बाकी दस्तावेज़ प्रबंधन UX पर काम करते हैं। यह निश्चित रूप से कुछ ऐसा है जो हम करना चाहते हैं।

@stevencl मुझे खुशी होगी अगर ड्रैगिंग ने नई vscode विंडो को उस फाइल के साथ खोला (शायद उसी फोल्डर के साथ भी खुला हो)।

धन्यवाद @Tyriar , हम इसे देखते रहेंगे। अगर कोई ऐसा तरीका है जिससे हम इसे अच्छी तरह से काम कर सकते हैं, तो हम इसे करने में सक्षम होना पसंद करेंगे।

@stevencl मुझे बस यह चिंता है कि भविष्य में इसे जोड़ने के लिए और भी अधिक काम की आवश्यकता होगी इसलिए _when_ आप बुनियादी ढांचे में सुधार करते हुए इसे अपने बैकलॉग में रखना सुनिश्चित करेंगे! ;)

कृपया टैब करें

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

इसे स्पिन देने के लिए तत्पर हैं। सुनने के लिए धन्यवाद।

@stevencl यह दोनों दुनिया के सर्वश्रेष्ठ की तरह लगता है। बहुत अच्छा लग रहा है! टैब दिखाई देते हैं जैसा कि मैंने उन्हें बाकी UI के साथ फिट होने के लिए उम्मीद की होगी, और ऐसा लगता है कि मुझे ठीक वैसा ही मिलेगा जैसा मैं वर्किंग फाइल्स में बदलाव के साथ चाहता हूं :)

क्या ओपन एडिटर 2 से अधिक संपादक समूहों का समर्थन करेंगे? बस यह सोचकर कि आप उनका नाम कैसे लेते हैं यदि यह वाम और अधिकार से अधिक जटिल है।

हाँ, यह अभी भी समर्थित होगा।

प्रेषक: Maxime Quandallemailto: सूचनाएं@github.com
प्रेषित: 22/04/2016 23:09
के लिए: Microsoft / vscodemailto: [email protected]
Cc: Steven Clarkemailto: [email protected]; Mentionmailto: [email protected]
विषय: Re: [Microsoft / vscode] खुली फाइलों के लिए उचित टैब (# 224)

क्या घसीटना और ड्रॉप द्वारा पुनरावृत्ति करना अभी भी

आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें:
https://github.com/Microsoft/vscode/issues/224#issuecomment -213605667

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

@ jayrosen1576 क्षैतिज विभाजन इस अंक में कैप्चर किया गया है https://github.com/Microsoft/vscode/issues/1749 , अपनी रुचि दिखाने के लिए: +1 करें।

अच्छा काम लोग वायर फ्रेम को देखते हैं जैसे वे वास्तव में अच्छी तरह से काम करेंगे।

अरे @stevencl
महान काम के लिए धन्यवाद और यहाँ बाईं ओर करीब बटन के बारे में मेरे 2 सेंट है।
जब कई फाइलें खुली होती हैं और टैब सिकुड़ती जा रही होती हैं, तो प्रत्येक टैब के लिए छोटी जगह केवल क्लोज बटन दिखाने के लिए पर्याप्त होगी, जिससे गलती से टैब को चुनने के बजाय बंद करना आसान हो जाएगा।

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

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

@ हमारी यह समझ थी कि टैब ओवरव्यू टैब शेवरॉन ओवरफ्लो बटन से उपलब्ध होंगे। बंद बटन एक मुद्दा नहीं होना चाहिए।

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

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

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

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

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

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

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

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

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

इसे साफ करने के लिए धन्यवाद @stevencl।

टैब में फ़ाइल नामों के साथ ध्यान में रखने के लिए एक किनारे का मामला कई फाइलें हैं जो अलग-अलग फ़ोल्डरों (index.js, README, LICENSE, package.json, आदि) से खोले गए एक ही नाम के साथ हैं।

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

थू पर, अप्रैल 28, 2016 को 12:16 बजे, स्टीवन क्लार्क सूचनाएं @github.com
लिखा था:

सबको धन्यवाद। हमने इसे मॉकअप में नहीं दिखाया लेकिन हमारा इरादा है
जब आवश्यक हो, हम टैब को सिकोड़ देंगे ताकि केवल का नाम हो
फ़ाइल और बंद बटन दिखाई दे रहे हैं। कारणों के लिए @anyong
https://github.com/anyong में उल्लेख किया गया है, हमें नहीं लगता कि हम हटना चाहते हैं
वह बिंदु जहाँ फ़ाइल नाम एक दूसरे से अलग नहीं होते हैं। हम सोचते हैं
कोड संपादक के कई टैब के लिए यह संभवतः अधिक सामान्य है
इसके समान नाम ब्राउज़र टैब के लिए समान नाम वाले हैं (जैसे,)
एक ही उपसर्ग के साथ कई फ़ाइल नाम हो सकते हैं)। इस प्रकार हम सोचते हैं कि
एक कोड संपादक में सिकुड़ते टैब की तुलना में अलग परिणाम हैं
ब्राउज़र।

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/224#issuecomment -215481474

धन्यवाद @alexgorbatchev हमारे पास कुछ विचार हैं कि इन मामलों में असंतुष्ट होने में सक्षम होने के लिए फ़ाइल को पथ कैसे दिखाया जाए। उदाहरण के लिए ऊपर दिखाए गए उच्च निष्ठा मॉकअप में हम फ़ाइल नाम के नीचे फ़ाइल को पथ दिखाते हैं। हालांकि यह केवल एक विचार है और जब रास्ता लंबा हो तो काम नहीं कर सकता है। एक और स्थिति पट्टी में रास्ता रखा जाएगा। बहुत सी बातें पता लगाने के लिए ...

@stevencl

क्या यह आशय है कि संख्या केवल यह बताती है कि अतिप्रवाह टैब हैं या क्या अतिप्रवाह टैब की वास्तविक संख्या महत्वपूर्ण है?

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

इसलिए वे सहजता से "मुझे बहुत सारे टैब खुले मिल गए हैं" का कुछ विचार है "बनाम" मुझे 2 या 3 टैब खुले हैं "

"20" दिखाने वाला बैज 20 छोटे / बेकार सिकुड़े हुए टैब दिखाने की तुलना में बहुत छोटा (कोई अतिरिक्त अचल संपत्ति नहीं है), लेकिन यह अभी भी मुझे तुरंत यह जानने की अनुमति देता है कि (ए) छिपे हुए टैब हैं और (बी) बिल्कुल कैसे बहुत से हैं।

मैं केवल इस धागे के लिए नया हूं लेकिन एक पूर्ण VS2015 उपयोगकर्ता के रूप में मेरा 2p:

Vscode में टैब होने की उम्मीद है, क्योंकि काम करने वाली फाइलें कभी भी मेरे साथ नहीं बैठती हैं (हालांकि अब मैं देख रहा हूं कि ctrl-f4 मारना उस सेट से नहीं हटता है, जैसा कि मैंने यह मान लिया था)।

प्रीव्यू टैब का बड़ा प्रशंसक, यह देख कर खुशी हुई।

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

मैं VS के अनुसार टैब के लिए राइट क्लिक मेनू देखने की उम्मीद कर रहा हूं ... 'सभी को बंद करें' (समूह के लिए) सबसे महत्वपूर्ण बात, 'इसके अलावा सभी को बंद करें' के बारे में उपद्रव नहीं किया गया। सभी संशोधित फ़ाइलों के लिए वीएस स्टाइल सेव बॉक्स यहां उपयोगी होगा।

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

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

शेवरॉन संख्या - क्या यह इस समूह में _hidden_ ​​टैब / फ़ाइलों / संपादकों की गिनती है, या दृश्य फ़ाइलों सहित _all_ की गिनती है? मैं केवल छिपी हुई वस्तुओं पर बहस करूंगा, खासकर यदि आप केवल शेवरॉन (और इस प्रकार गिनती) दिखाते हैं, जब टैब पंक्ति से कुछ ओवरफ्लो होता है।

थोड़ा संबंधित नोट पर, अगर मैं ctrl-f4 (या ctrl-w? यह ctrl-f4 का गैर-विंडोज संस्करण लगता है, जब तक कि मुझसे कोई गलती न हो), मुझे उम्मीद है कि अगर टैब दूर जा रहा है, तो यह बंद हो रहा है संपादक को ctrl-tab / ctrl-alt-tab / working files से इसे बचाने / हटाने और हटाने के लिए संकेत देना चाहिए ... मैं देख सकता हूं कि इस कार्यक्षमता को सक्षम करने के लिए मैं इस समय कुछ कीबाइंड परिवर्तन कर सकता हूं, लेकिन मैं संघर्ष करता हूं एक टैब आधारित इंटरफ़ेस में क्यों देखें टैब का अस्तित्व सीधे 'वर्तमान' से संबंधित नहीं है - फ़ाइल / संपादक का ओपन-नेस।

आप सबको vscode पर क्या हो रहा है, यह बहुत अच्छा लग रहा है

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

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

वैसे भी, मैं अब एक फ़ाइल इतिहास आस्तिक हूँ। :)

मुझे लगता है कि यह वास्तव में अच्छा होगा अगर हम shift+cmd+[ और shift+cmd+] का उपयोग करके इतिहास में आगे और पीछे जाने की क्षमता जोड़ सकें। ये अन्य अनुप्रयोगों में टैब के आसपास नेविगेट करने के लिए डिफ़ॉल्ट शॉर्टकट हैं और इतिहास को नेविगेट करने के लिए उनका उपयोग करने में सक्षम होने के बजाय मुझे लगता है कि मुझे विश्वास करने की दिशा में एक लंबा रास्ता तय करना होगा

संपादित करें: मूल रूप से इसे लागू करके प्राप्त किया गया

  { "key": "shift+cmd+[", "command": "workbench.action.openPreviousEditor" },
  { "key": "shift+cmd+]", "command": "workbench.action.openPreviousEditor" },
  { "key": "shift+cmd+[", "command": "workbench.action.quickOpenNavigateNext", "when": "inQuickOpen" },
  { "key": "shift+cmd+]", "command": "workbench.action.quickOpenNavigatePrevious", "when": "inQuickOpen" }

कस्टम कुंजी बाइंडिंग के रूप में

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

@Josh यह पूरी तरह से संभव है, लेकिन उनके पास संपादक के लिए अंतर-प्रक्रिया संचार के लिए बुनियादी ढांचे की कमी है, इसलिए दो उदाहरणों के लिए संवाद करने और कुछ भी करने के लिए उन्हें इस पहले के लिए एक प्रोटोकॉल की आवश्यकता है।

... टैब में नाम के बाईं ओर एक निकट बटन होता है

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

हमने पूर्वावलोकन टैब को पूर्ण खुले टैब में बढ़ावा देने के लिए क्रियाओं पर चर्चा की ...

मुझे लगता है कि पहले दो विकल्प शायद पर्याप्त होंगे। टैब पर डबल क्लिक करना भविष्य में अन्य चीजों के लिए उपयोगी हो सकता है।

हमारे पास कुछ विचार हैं कि इन मामलों में असंतुष्ट होने में सक्षम होने के लिए फ़ाइल को पथ कैसे दिखाया जाए।

टैब पर मँडरा करने पर क्या केवल टूलटिप (सापेक्ष पथ के साथ) दिखाने के बारे में? यह डिजाइन को कम अव्यवस्थित बनाता है, और टैब को लंबा नहीं होना चाहिए।

जब भी कोई अतिप्रवाह होता है तो हम एक शेवरॉन दिखाते हैं ...

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

यदि वास्तव में टैब क्लोज बटन प्लेटफ़ॉर्म सम्मेलनों से मेल खाते हैं तो बहुत अच्छा होगा: विंडोज़ पर दाईं ओर, ओएस एक्स पर बाईं ओर।

कुछ समय के लिए VSCode का उपयोग करने के बाद, मुझे लगता है कि _Working Files_ मोड ने मुझ पर बहुत काम किया है!

यहाँ कुछ कारण हैं:

1. हालाँकि यह काउंटर-सहज लगता है, एक फ़ाइल को बंद करना जो मैं उपयोग नहीं कर रहा हूं (ctrl-w) इसे वर्किंग फाइल्स से बाहर नहीं ले जाता। यह बहुत अच्छा है क्योंकि कई बार मैं अपने आप को हाल ही में बंद फाइलों (एक रिएक्ट प्रोजेक्ट में) से संबंधित फाइलों (या अन्य शहरों) के साथ काम करते हुए फिर से खोलने लगता हूं। इसलिए, जब मुझे _feel_ पसंद होता है, तो मुझे एक फ़ाइल को एक-एक करके उस समय मैप नहीं करना चाहिए जब मैंने _should_ को बंद कर दिया है।
2. मुझे स्पष्ट फोर्स-क्लोज पसंद है, जो workbench.files.action.closeFile द्वारा पेश किया जाता है।
3. मैंने Ctrl + k Ctrl + w के लिए workbench.files.action.closeFile का रीमैप किया है क्योंकि इसमें Ctrl + kw , की तुलना में (थोड़े) कम प्रयास की आवश्यकता होती है
4. मैं संपादक के शीर्ष बार में पूर्ण फ़ाइल नाम और पथ देख सकता हूं -> यह गहरी नेस्टेड परियोजनाओं (जैसे मेरे पास) में बहुत महत्वपूर्ण है जिसमें समान या समान नामों वाली फाइलें हैं ( index.js ?) और केवल? विभेद करने का मार्ग मार्ग है।
5. टैब का कम शोर = ज़ेन!

तो, एक तरह से मैं यह कहना चाह रहा हूँ कि कृपया टैब को हटाएं नहीं तो मौजूदा प्रवाह_ को हटाएं।

@kumarharsh वे क्यों

यदि गंदा संकेतक CLOSE आइकन को बदल देता है, तो यदि हम अपने परिवर्तनों को सहेजना नहीं चाहते हैं, तो हम फ़ाइल को कैसे बंद कर पाएंगे? क्या ctrl-w अभी भी उपलब्ध होगा?

गंदे संकेतक सिर्फ होवर पर बंद बटन में नहीं बदल सकते हैं?
यह एक बहुत ही सामान्य समाधान है ...

बुध पर, 4 मई, 2016 को 11:28 बजे, rojorojo सूचनाएँ @ithub.com ने लिखा:

यदि गंदा संकेतक CLOSE आइकन को बदल देता है, तो हम कैसे कर पाएंगे
यदि हम अपने परिवर्तनों को सहेजना नहीं चाहते हैं, तो फ़ाइल बंद करें? Ctrl-w अभी भी होगा
उपलब्ध?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/224#issuecomment -216901750

@rojorojo हम @anyong ने भी सुझाया है, इसलिए आपको कोई परेशानी नहीं होगी। और हाँ, Ctrl + W अभी भी उपलब्ध होगा।

पूरी प्रतिक्रिया के लिए धन्यवाद।

हम इस महीने के अंत में हमारे नवीनतम डिजाइनों पर एक यूएक्स अध्ययन चला रहे हैं। यदि आप 25 या 26 मई को एक घंटे का समय निकाल सकते हैं और अध्ययन में भाग लेना चाहते हैं, तो कृपया यहाँ साइन अप करें: https://calendly.com/stevencl/vs-code-docmgmt/

दुर्भाग्य से मैं केवल दिन के दौरान (ब्रिटिश समर टाइम) की पेशकश कर सकता हूं और शाम को सत्र नहीं चला सकता।

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

रुको, मुझे वर्तमान UI व्यवहार पसंद है, क्या कोई कॉन्फ़िगरेशन होगा?

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

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

जैसा कि कोई है जो वास्तव में ऊर्ध्वाधर टैब पसंद करता है (वे वाइडस्क्रीन डिस्प्ले पर बेहतर और बेहतर काम करते हैं), मैं सोच रहा हूं: आपको टैब और "ओपन एडिटर" दोनों की आवश्यकता क्यों है। यदि बाद वाला टैब व्यवहार के साथ मूल रूप से "काम करने वाली फाइलें" है, तो मुझे बस इतना ही चाहिए।

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

मेरे दो सेंट: मुझे कभी भी बंद बटन नहीं चाहिए; मेरे लिए, वे अचल संपत्ति की बर्बादी हैं जो कभी-कभी हताशा (गलती से क्लिक) का कारण बनते हैं। गलती से बीच-बीच में क्लिक करने की तुलना में गलती से 1px क्लिक करना बहुत अधिक कठिन है।

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

सीमा के बाईं ओर बहुत चौड़ा है

@ be5invis @MrTravisB @rauschma @marcusrugger @jpaaso

दोस्तों, मैं समझता हूं कि यह एक लंबा धागा है, इसलिए आपने शायद यह सब नहीं पढ़ा है, लेकिन कृपया आस-पास की पोस्ट यहाँ पढ़ें। टैब्स वैकल्पिक होंगे, देव पहले से ही बहुत हैं, उन बिंदुओं से बहुत अवगत हैं जिन्हें आप ला रहे हैं।

हो सकता है पोस्टर: कृपया देखने के लिए धागे के माध्यम से देखें कि क्या आपके मुद्दे पहले से ही संबोधित हैं - हर बार जब आप पोस्ट करते हैं तो सौ लोग आपके साथ ईमेल प्राप्त कर रहे हैं: +1: धन्यवाद

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

@ be5invis एकमात्र अंतर यह है कि एक दृश्य विभाजक है। आप अभी भी फ़ाइलों को इधर-उधर खींच सकते हैं और अपनी पसंद के किसी भी संपादक में खोल सकते हैं।

@ क्या मैं इसे छिपा सकता हूँ? और अगर मैं एक संपादक कॉलम में "विभाजक", और Ctrl-Tab को छिपाने के लिए चुनता हूं, तो क्या मैं दूसरे कॉलम में एक खुली फाइल पर स्विच कर सकता हूं? कोन-टैबर्स चाहते हैं कि मौजूदा व्यवहार को पूरी तरह से बनाए रखा जाए।

@ be5invis ऊपर दी गई टिप्पणी से जुड़ा:

Ctrl Alt Tab सभी टैब समूहों के अंदर सभी टैब की एक सूची दिखाता है

तो हां, यदि आप चाहें तो आप वर्तमान Ctrl + टैब व्यवहार को बनाए रखने के लिए कुंजी बाइंडिंग सेट कर सकते हैं।

@ संयोग अच्छा है।
लेकिन फिर भी, क्या मैं "बाएं / दाएं" संकेतक को छिपा सकता हूं और सूची को एक एकता जैसा बना सकता हूं?

यह @stevencl के लिए एक प्रश्न होगा

वाह! मुझे आशा है कि हम जल्द ही टैब प्राप्त करेंगे!

बड़ी खबर .. हम टैब प्राप्त कर रहे हैं..लेकिन हम 'वर्किंग फाइल्स' फोल्डर को ढीला नहीं करना चाहते हैं। टैब के साथ इसे रखें?

बहुत बढ़िया! टैब समूह

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

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

हमने जो कारण किया है वह यह है कि किसी फाइल को प्रबंधित करते समय भ्रम की संभावना है जो कि वर्तमान में काम कर रहे फाइल सेटअप में दो संपादकों में खुला है। उदाहरण के लिए, वर्तमान उत्पाद से नीचे स्क्रीनशॉट में, जब मैं काम करने वाली फाइलों की सूची में app.js को बंद करता हूं तो क्या होना चाहिए। क्या दोनों संपादकों को पास होना चाहिए या उनमें से सिर्फ एक को। और अगर उनमें से सिर्फ एक, कौन सा?

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

यही कारण है कि हमने संपादकों को खोलने के लिए काम करने वाली फ़ाइलों का नाम बदल दिया क्योंकि हमें लगता है कि बेहतर नए व्यवहार को दर्शाता है।

गो टू डेफिनिशन (F12) विकल्प को बढ़ाने की जरूरत है (यहां तक ​​कि परिभाषा एक परियोजना में किसी अन्य पेज में है)) लाइम टेक्स्ट की तरह? मैं इस मुद्दे का सामना लंबे समय से कर रहा हूं क्योंकि मैं वीएस कोड स्थापित करता हूं? इस पर कोई मदद?

@ विनोद-ए-एक्स्ट - गो टू डेफिनिशन के साथ आने वाली समस्या का वर्णन करते हुए कृपया एक नया मुद्दा खोलें।

@stevencl
VS कोड में डेफिनिशन प्रॉब्लम पर जाएं
https://github.com/Microsoft/vscode/issues/6238

@stevencl मेरी राय है कि आप "खुले संपादक" में लेबल छिपा सकते हैं, और बस विभिन्न पैनलों का प्रतिनिधित्व करने के लिए एक रेखा खींच सकते हैं। एक बार एक पैनल बंद हो जाता है, तो दो सूचियों को प्राकृतिक रूप से विलय किया जा सकता है।

सुझाव के लिए धन्यवाद, हम निश्चित रूप से इसके लिए विभिन्न दृश्य उपचारों का पता लगाएंगे।

दिनांक: मंगल, १० मई २०१६ ०४.०२:३४ -0700
प्रेषक: सूचनाएँ@github.com
को: [email protected]
CC: [email protected]; [email protected]
विषय: Re: [Microsoft / vscode] खुली फाइलों के लिए उचित टैब (# 224)

@stevencl मेरी राय है कि आप "खुले संपादक" में लेबल छिपा सकते हैं, और बस विभिन्न पैनलों का प्रतिनिधित्व करने के लिए एक रेखा खींच सकते हैं। एक बार एक पैनल बंद हो जाता है, तो दो सूचियों को प्राकृतिक रूप से विलय किया जा सकता है।

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

मैं उत्सुक हूं, आपने मॉक अप्स को जनरेट करने के लिए किस प्रोग्राम का उपयोग किया, जैसे यह

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

दिनांक: मंगल, १० मई २०१६ 05:03:55 -0700
प्रेषक: सूचनाएँ@github.com
को: [email protected]
CC: [email protected]; [email protected]
विषय: Re: [Microsoft / vscode] खुली फाइलों के लिए उचित टैब (# 224)

मैं उत्सुक हूं, आपने मॉक अप्स को जनरेट करने के लिए किस प्रोग्राम का उपयोग किया, जैसे यह

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

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

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

यह कोणीय 2 विकास में व्यवस्थित रखने के लिए वास्तव में उपयोगी होगा, जहां आपके पास आमतौर पर संबंधित फाइलें हैं:

• widget.component.css
• widget.component.html
• widget.component.ts
• widget.component.spec.ts

@Lucidtech से सहमत

मैं @coreh से सहमत

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

अनिवार्य रूप से, किसी भी टैब-आधारित संपादक में, मैं खुद को अपने संपादक फ़्रेम में परिणामों के साथ काम करने के लिए बाध्य पाता हूं जो टैब के साथ बुरी तरह से स्पैम किए जाते हैं, जिसके लिए फ़ोल्डर फ़ॉब्स बहुत छोटे होते हैं वे अपठनीय होते हैं। इसके अलावा, जब मैं इस तरह के संपादक को Ctrl / PI-PI के समतुल्य उपयोग करता हूं, तो किसी अन्य फ्रेम पर वार करने के लिए, जो भी मैं उस फ़ाइल को देख रहा था, जब मैं पहली बार फाइल पर नेविगेट करता था। उसी फ़ाइल को किसी अन्य फ़्रेम में देखने के लिए, आपको एक क्लूनी "स्प्लिट टैब" ऑपरेशन करना होगा, जो अक्सर इन संपादकों में से कई में विभाजित फ्रेम के साथ युग्मित किया जाता है। _Tabs डिस्प्ले पर दिए गए फ्रेम के साथ कसकर युगल फ़ाइल बफर स्थिति ।_

यदि आप भावुक अपील करते हैं, तो कृपया _please_ वी.एस. कोड को अभी तक किसी अन्य टैब्ड संपादक में न बदलें।

मुझे लगता है कि यूएक्स के नजरिए से, एटम या किसी अन्य संपादक के व्यवहार से मेल खाने के लिए नेत्रहीन रूप से टैब लागू करने के बजाय, यह _why_ लोग टैब (केवल आरामदायक परिचित के अलावा) चाहते हैं और देखें कि क्या अधिक अभिनव समाधान है उनकी जरूरतें संभव हैं। मैं निश्चित रूप से सहमत हूं कि वर्तमान कार्यक्षेत्र शासन विकसित करना जारी रख सकता है: जैसा कि किसी और ने एक ही में एक अलग विंडो खोलने का उल्लेख किया है (टैब-आधारित "रिपआउट" के बराबर) बेहतर उत्तोलन करने के लिए परियोजना के लिए मल्टी-हेड डिस्प्ले दिमाग में आते हैं!

संपादित करें: बहुत दुख की बात है कि मैं 19 दिन पहले कॉल करने से चूक गया। अगर मैं इसके बारे में जानता होता तो मैं इसमें शामिल होता। केवल 1.1.0 के रिलीज नोटों से पता चला। :(

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

@orospakr , आप एक मेनू विकल्प के माध्यम से Sublime में टैब बंद कर सकते हैं। सिर्फ आपकी जानकारी के लिए।

@orospakr

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

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

उन्होंने "काम करने वाली फाइलों" के साथ कुछ नया करने की कोशिश की और एक समूह को यह पसंद आया, दूसरे ने इसे नापसंद किया और यहाँ हम आज टैब से पूछ रहे हैं! मुझे नहीं लगता कि आप फिर से वही सिंड्रोम चाहते हैं ...

ऐसा करने का सही तरीका यह है कि अनुभव प्राप्त करने के लिए लोग पहले की तलाश में हैं और फिर अल्फा बिल्ड और / या एक विकल्प के रूप में अतिरिक्त सुविधाएँ, नवाचार या प्रयोग हैं।

टैब्स / "ओपन एडिटर्स" या कल कुछ और के मामले में उन्होंने इसे वैकल्पिक बना दिया है और यही होना चाहिए कि लोगों को अनुभव से ऑप्ट-इन करने या उसमें से ऑप्ट-आउट करने की क्षमता होनी चाहिए।

मुझे पता है कि मुझे यहाँ खेल में थोड़ी देर हो गई है, लेकिन इस खंड के संबंध में:

हमने पूर्वावलोकन टैब को पूर्ण खुले टैब में बढ़ावा देने के लिए क्रियाओं पर चर्चा की:

टैब के अंदर संपादन सामग्री
एक्सप्लोरर में किसी फाइल पर डबल क्लिक करना
टैब समूह में पूर्वावलोकन टैब पर डबल क्लिक करें

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

यह बहुत संभावना नहीं है कि मैंने एक फ़ाइल में एक बुकमार्क जोड़ा है जिसे मैं तुरंत बंद करने का इरादा रखता हूं।

मैंने जितनी भी टिप्पणियां देखीं, उतने कीवर्ड खोजे और यह उल्लेख नहीं किया।

जहाँ तक टैब जाते हैं, सबसे पहले, _thank you! _ उनकी अनुपस्थिति केवल उन चीजों में से एक है जो मुझे VS कोड के बारे में नापसंद हैं।

मैं टैब के बीच नेविगेशन को देखने के लिए अनुकूलन योग्य होगा; उदाहरण के लिए, मैं जिस तरह से cmd + left दबाकर टैब के बीच स्विच करता हूं, उसी तरह से प्यार करता हूं, और मेरे संपादक के साथ भी ऐसा करना बहुत पसंद करेगा।

एक महान संपादक <3 के लिए धन्यवाद

टैब मेरे लिए बहुत महत्वपूर्ण हैं ... तब तक आपके पास तब तक स्विच करना जब तक आपके पास टैब नहीं है। पीएस मैं आपके रवैये से बहुत निराश हूं; आपको लगता है कि UX का कोई मतलब नहीं है फिर भी यह दावा किया गया है कि यह UX को बेहतर बनाने के लिए किया गया है। आपके व्यक्ति क्या हैं? आपके उपयोगकर्ता साक्षात्कार कहां हैं? इसे साबित करो।

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

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

@asadighi यह सब आपके सिर में है और आपकी टिप्पणी में आपकी बकवास है, इसे रोकें।

@ म्यूलरकेले : +1: आपको आपके द्वारा उपयोग किए जाने वाले बुकमार्क एक्सटेंशन के विरुद्ध एक समस्या बनानी चाहिए।

मैं इस सुविधा का इंतजार कर रहा हूं

+1!

दैनिक, मैं ग्रहण, PhpStorm, नोटपैड ++ और VSCode के बीच स्विच करता हूं। क्या लगता है, CTRL+W मुझे पागल कर देता है।

मुझे इस पार्टी के लिए देर हो रही है, लेकिन क्या टैब वैकल्पिक होने जा रहे हैं? मुझे लगता है कि मैं उन्हें याद करने के लिए उपयोग करता हूं, लेकिन अब मैं नहीं करता हूं। बस जिज्ञासु अगर वहाँ एक तरह से उन्हें छुप जाएगा। टैब और उनके उपयोग के इच्छुक लोगों के प्रति कोई घृणा नहीं, बस मुझे लगता है कि मैं दिखाने / छिपाने के लिए टॉगल पसंद करूंगा। यही सब महान काम है। मुझे विस्कोस बहुत पसंद है।

@jamesmenera हाँ, यह वैकल्पिक होने जा रहा है, लेकिन काम करने वाली फ़ाइलें (खुले संपादक) करता है।

एक तरफ के रूप में, क्या आप उन मॉकअप चित्रों को बनाने के लिए किस कार्यक्रम का उपयोग करेंगे?

@ciel , @stevencl ने लिखा कि उन्होंने इसके लिए PowerPoint का इस्तेमाल किया।

व्यक्तिगत रूप से, मुझे यह करने के लिए वायरफ्रेमस्केचर बहुत पसंद है, लेकिन PowerPoint भी काम कर सकता है। :)

जैसा कि @jamesmenera ने उल्लेख किया है कि मैं वास्तव में टैब और साइडबार को याद करता हूं लेकिन मैं देख सकता हूं कि बहुत सारे लोग वर्किंग फाइल्स को पसंद करते हैं इसलिए यह वैकल्पिक होना चाहिए।

@ kadza93 टैब और काम करने वाली दोनों फाइलें वैकल्पिक होने जा रही हैं ... मुझे आश्चर्य है कि मैं इसे लिखने के लिए कितनी बार जा रहा हूं।

यह वास्तव में एक खोज करना आसान है और शब्द "वैकल्पिक" की तलाश में है, यह वास्तव में इसके बारे में एक पोस्ट लिखने की तुलना में आपको इसे खोजने में कम समय लगेगा!

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

यह आपकी पोस्ट से केवल 3 ऊपर था ...

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

@jtlowe यह GitHub पर टिप्पणी की तरह हालांकि यह स्पष्ट करने के लिए कोई आसान तरीका है। लोग नई टिप्पणियाँ करते हैं और यह महत्वपूर्ण सामान को दफन करता है। GitHub भी कई बार कमेंट करता है, जब पेज में बहुत सारे कमेंट होते हैं, जो पेज को कठिन बनाता है।

शायद प्रवेश पृष्ठ अंक के शीर्ष पर (ओपी के मुद्दे-निकाय के तहत) एक "मौजूदा स्थिति: IN-DEVELOPMENT" बैनर लगा सकते हैं?

यह github में एक उचित विशेषता होनी चाहिए --- यहाँ कुछ-जैसा पाठ बताता है: https://xkcd.com/979/

@ kadza93 मैंने आपको लौ नहीं

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

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

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

हाँ ... आप बहुत समझदारी बना रहे हैं, मेरा मतलब है कि किसी ऐसी चीज़ के बारे में राय व्यक्त करना जो पक्की थी! और आपको इसकी खोज करने की भी आवश्यकता नहीं थी क्योंकि मैंने उसी व्यक्ति को जवाब दिया था जिसे आपने अंगूठे दिए थे।

आम तौर पर, एक लंबे पोस्ट में संभावित सामान्य शब्दों की खोज करना सामान्य ज्ञान है।

वास्तव में देवों को अक्सर पूछे जाने वाले प्रश्नों और विवरणों के साथ एक नया मुद्दा खोलना चाहिए
इस धागे में सबसे आम बिंदु और इस मुद्दे को बंद करें। लोग
इस मुद्दे की सदस्यता के लिए हर दिन दर्जनों ईमेल मिल रहे हैं
वही "अंगूठे ऊपर" / "अंगूठे नीचे" टिप्पणी।
18 मई, 2016 को 1:51 AM, "कुमार हर्ष" सूचनाएं @github.com ने लिखा:

शायद व्यवस्थापक "CURRENT STATUS: IN-DEVELOPMENT" बैनर लगा सकते हैं
पृष्ठ के शीर्ष (ओपी के मुद्दे-निकाय के तहत)?

यह github में एक उचित विशेषता होनी चाहिए --- कुछ-जैसे ऑल्ट-टेक्स्ट
यहां बताया गया है: https://xkcd.com/979/

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/Microsoft/vscode/issues/224#issuecomment -219798727

@ मैं हाँ पूरी तरह से सहमत हूँ! चर्चा करने के लिए कुछ भी नहीं है और एक बार tabs और open editors रहते हैं, उन्हें इन सुविधाओं के बारे में प्रतिक्रिया के लिए दो अलग-अलग मुद्दे बनाने चाहिए।

@eyalsk हम अभी भी प्रयोग कर रहे हैं कि समुदाय द्वारा बनाए गए मुद्दों पर अपडेट कैसे संभालें। ऐसा करने के तरीकों का एक समूह है, लेकिन GitHub पर एक चुटकी टिप्पणी की सुविधा के बिना वे सभी तरह के बुरे हैं। एकीकृत टर्मिनल मुद्दा https://github.com/Microsoft/vscode/issues/143#issuecomment -213581854 थ्रेड के बीच में एक बड़े अपडेट के साथ अब तक ठीक रहा है, मुझे लगता है कि इसे चर्चा की कम आवश्यकता के लिए करना होगा इसलिए इसे दफन नहीं किया गया है।

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

हम इस मील के पत्थर में टैब और संपादक समूहों के लिए डिजाइनों को लागू करने पर काम कर रहे हैं और अगले मील के पत्थर में ऐसा करना जारी रखेंगे

उन सभी के लिए धन्यवाद, जिन्होंने यूएक्स अध्ययन में भाग लिया, इन अंतिम दिनों में। हमें आपकी ओर से कुछ बढ़िया प्रतिक्रिया मिली, जिसने हमें अनुभव में कुछ सुधार करने में मदद की:

• ओवरफ़्लो आइकन को फिर से डिज़ाइन करें
• यह चुनने के लिए एक सेटिंग प्रदान करें कि त्वरित खुले से फाइलें पिन की गई हैं या पूर्वावलोकन की गई हैं
• एक पूर्वावलोकन फ़ाइल को एक पिन की गई फ़ाइल में बदलने के लिए एक कमांड जोड़ें

क्षमा करें, अगर मैं चूक गया हूं, लेकिन हम टैब कैसे सक्षम करते हैं? क्या वे नवीनतम इनसाइडर बिल्ड में उपलब्ध हैं, जैसा कि मेरे पास है, लेकिन वहां टैब का कोई निशान नहीं है। मैं अब भी एक्सप्लोरर में 'वर्किंग फाइल्स' देखता हूं, जबकि ऐसा लगता है कि इसे 'ओपन एडिटर्स' से बदल दिया जाना चाहिए जैसा कि # 6536 में कहा गया है।

@lllopo वे अभी तक उपलब्ध नहीं हैं। स्टैक / खुले संपादकों को v1.3.0 में विलय कर दिया गया था और अगले सप्ताह अंदरूनी में उपलब्ध होगा जब दैनिक बिल्ड उपलब्ध हो जाएंगे।

+1

+1

👎

यहाँ क्या हो रहा है, आप हमें टैब का उपयोग करने का विकल्प देने का विरोध क्यों कर रहे हैं? 😕
मेरे जैसे बहुत से लोग टैब पसंद करते हैं, हमें लानत विकल्प PERIOD देते हैं!

@aminroosta गंभीरता से ... क्या आप पढ़ नहीं सकते? क्या आप अंधे हैं?

मजेदार बात यह है कि आप पूछ रहे हैं कि यहां क्या चल रहा है ... और फिर मान लें कि वे वास्तव में इसे अस्वीकार करते हैं या अपने स्वयं के शब्दों में "विरोध" करते हैं जब वास्तव में उन्होंने पुष्टि की कि टैब आ रहे हैं और इसे लागू करने पर काम कर रहे हैं!

इस दुनिया में कुछ लोग! अविश्वसनीय!

@eyalsk
मैंने पहले 20 से 30 टिप्पणियों को पढ़ते हुए 25 मिनट बिताए।
मैं थक गया और एक टिप्पणी छोड़ दी, जो अब लगता है कि गलती से मेरा हिस्सा टूट गया।

उसके लिए माफ़ करना।

हम Microsoft R & D को इनोवेट करने का प्रयास करने के लिए दोषी नहीं ठहरा सकते। टैब सिस्टम में विपक्ष है।

यूआई डिजाइन सभी प्रकार के डिजाइन की तरह है। 90% जो उपयोगकर्ता प्रतीक्षा कर रहे हैं, 10% नई चीजें बना रहे हैं, एक नई क्रांतिकारी और उपयोगकर्ता के अनुकूल प्रणाली बनाने की कोशिश कर रहे हैं।

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

@aminroosta मैं आपको एक टिप दूंगा, जब आप एक लंबी पोस्ट पढ़ रहे हैं, तो मूल पोस्ट पढ़ें और फिर नवीनतम अपडेट प्राप्त करने के लिए एक मिनट खर्च करें या फिर नीचे से ऊपर तक स्क्रॉल करें।

यह एक बहुत अच्छा सुझाव है क्योंकि यह बहुत लंबा फ़ीड है।

सूर्य पर, जून 5, 2016 को 10:42 पूर्वाह्न ईयाल सोलनिक नोटिफिकेशन @github.com पर
लिखा था:

@aminroosta https://github.com/aminroosta मैं आपको एक टिप दूंगा, जब
आप एक लंबी पोस्ट पढ़ रहे हैं, मूल पोस्ट पढ़ें और फिर प्राप्त करें
नवीनतम अपडेट एक मिनट खर्च करते हैं या नीचे से ऊपर तक स्क्रॉल करते हैं।

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

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

@adred दोनों Working files (अब Open editors कहा जाता है) और Tabs जहाँ तक मैं बता सकता हूँ वैकल्पिक होने जा रहे हैं।

@bpasero

क्या आप इस धागे को लॉक कर सकते हैं और इस में कॉपी किए गए महत्वपूर्ण बिट्स के साथ एक नया खोल सकते हैं? अभी भी दैनिक लोगों की टिप्पणियाँ आ रही हैं, जो इसे पढ़ नहीं सकते (आपको बता दें कि यह बहुत लंबा है), और एक ही सवाल को बार-बार पूछ रहे हैं, और एक बार टैब जारी होने के बाद सार्वजनिक बनाता है जो हम करने जा रहे हैं इस धागे में और भी अधिक स्पैम देखें।

मैं टैब से संबंधित घटनाओं पर अप-टू-डेट रहना चाहता हूं, और यह धागा वर्तमान में ऐसा करने के लिए जगह है, लेकिन यह एक ही टिप्पणियों के लिए दिन में कई बार स्पैमी ईमेल प्राप्त करने के लिए सुपर कष्टप्रद है।

स्वर और धन्यवाद के लिए क्षमा याचना।

बहुत सारे + 1s हैं कि यह थोड़ा ज्यादा है।

सोम, जून 6, 2016 को 2:16 AM -0700 पर, "anyong" नोटिफिकेशन @github.com ने लिखा:

@bpasero

क्या आप इस धागे को लॉक कर सकते हैं और इस में कॉपी किए गए महत्वपूर्ण बिट्स के साथ एक नया खोल सकते हैं? अभी भी दैनिक लोगों की टिप्पणियाँ आ रही हैं, जो इसे पढ़ नहीं सकते (आपको बता दें कि यह बहुत लंबा है), और एक ही सवाल को बार-बार पूछ रहे हैं, और एक बार टैब जारी होने के बाद सार्वजनिक बनाता है जो हम करने जा रहे हैं इस धागे में और भी अधिक स्पैम देखें।

मैं टैब से संबंधित घटनाओं पर अप-टू-डेट रहना चाहता हूं, और यह धागा वर्तमान में ऐसा करने के लिए जगह है, लेकिन यह एक ही टिप्पणियों के लिए दिन में कई बार स्पैमी ईमेल प्राप्त करने के लिए सुपर कष्टप्रद है।

स्वर और धन्यवाद के लिए क्षमा याचना।

आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें:
https://github.com/Microsoft/vscode/issues/224#issuecomment -223906131

अपडेट पाठ पर केवल एक टिप्पणी @ https://code.visualstudio.com/updates#_workbench

पाठ मेरे लिए अस्पष्ट था और मुझे वास्तव में लगा कि अपडेट किए गए ढेर पहले से ही यहां थे (और यह टैब बाद में आएगा)। अपडेट करने के बाद मैंने अपडेट किए गए स्टैक को नहीं देखा और पाठ को कुछ बार फिर से पढ़ना पड़ा।

मेरे लिए यह कहता है कि टैब अधिक पुनरावृत्तियों (इसलिए _this_ अपडेट में कोई टैब नहीं) लेगा, लेकिन मई में आपने संपादकों के ढेरों को प्रबंधित करने के बारे में बहुत प्रगति की है (इसलिए इस अद्यतन में कोई भी टैब नहीं होने के बावजूद, अपडेट किए गए ढेर ___?) और यह कि जून की रिलीज ब्रांच के लिए और अधिक काम किया जाना है (आगे भी स्टैक में सुधार करना है?)।

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

मैं @RyanEwen से सहमत हूं। मैं वास्तव में खुले विकास और संचार की मात्रा का मूल्यांकन करता हूं, लेकिन आधिकारिक "रिलीज नोट्स" का हिस्सा होने वाली ये घोषणाएं वास्तव में भ्रमित करने वाली हैं।

हो सकता है कि यह वास्तविक रिलीज़ नोटों में विभाजित हो जाए, और 'अभी हम जो काम कर रहे हैं' या कुछ और।

इस मुद्दे को रोडमैप में जोड़ना एक अच्छा विचार नहीं है क्योंकि यदि आप इसे पहली बार पढ़ते हैं तो आपको वर्तमान स्थिति (माइलस्टोन से अधिक) का स्पष्ट विचार नहीं मिलेगा। अभी भी काम करना है लेकिन वर्तमान स्थिति ठीक है: +1:

हाँ, उन्हें मुद्दों को संक्षेप में प्रस्तुत करना चाहिए और फिर इन सारांशों के लिंक होने चाहिए ताकि लोगों को वर्तमान योजना के बारे में पता चले।

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

जब मैंने 1.2 के लिए रिलीज़ नोट्स पढ़ना शुरू किया, तो पहली चीज़ जो मैंने देखी, वह थी _the Tab Feature_। मैं इस बात की सराहना करता हूं कि उन्होंने वर्तमान स्थिति को वहां रखा है। लेकिन मैं भी भ्रमित हो गया। पहले मैंने सोचा कि यह उतरा, मुझे एहसास हुआ कि यह नहीं था, लेकिन बहुत प्रगति हुई थी। उस स्थिति में यह वास्तव में ऐसा लगता है कि आइटम को जारी नोट्स के नीचे चर्चा या एक मील के पत्थर के लिंक के साथ होना चाहिए (वे दोनों सुविधा पर प्रगति साबित करते हैं) साथ ही एक छोटे नोट के साथ कुछ ऐसा कहते हैं जैसे _ "बाहर की जाँच करें टैब कार्यान्वयन की दिशा में प्रगति "_।

भले ही यह मामूली बात हो। रिलीज पर शानदार काम। वीएस कोड अद्भुत विकास चक्र के साथ एक महान उत्पाद है।

VSCode को केवल 1.3.0-इनसाइडर में अपडेट किया गया। हाल की फाइलें निकल गई लगती हैं। क्या अब ऐसा करने का कोई तरीका है?

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

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

@JoshClose कृपया इसके लिए एक नया मुद्दा खोलें क्योंकि मैं इस मुद्दे को इस एकल धागे के बजाय व्यक्तिगत मुद्दों के पक्ष में शीघ्र ही बंद कर दूंगा। धन्यवाद।

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

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

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

धन्यवाद फिर से, अब जाओ और अंदरूनी सूत्र रिलीज स्थापित करें!

https://github.com/Microsoft/vscode/issues/6605 सभी जोड़े गए या परिवर्तित आदेश पहचानकर्ताओं को कीबाइंडिंग के साथ उपयोग करने के लिए दस्तावेज़। क्योंकि स्टैक मॉडल वीएस कोड के यूआई के लिए इतना बड़ा बदलाव है, हमने संपादकों या समूहों से संबंधित सभी आदेशों को फिर से जारी करने का फैसला किया।

हमें यह घोषणा करते हुए खुशी हो रही है कि अब आप हमारे रात्रिकालीन इनसाइडर बिल्ड (http://code.visualstudio.com/Download#insiders) में टैब सक्षम कर सकते हैं। संबंधित सेटिंग workbench.editor.showTabs । कृपया संपादक स्टैक, पूर्वावलोकन संपादकों और टैब की अवधारणा के बारे में अधिक जानकारी के लिए हमारे रिलीज़ नोट्स देखें।

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

धन्यवाद!

जैसा कि @bpasero ने उल्लेख किया है कि अब आप हमारे रात के अंदरूनी अंदरूनी निर्माण में टैब सक्षम कर सकते हैं।

यदि आपने यह कोशिश की है और अपनी प्रतिक्रिया साझा करने के लिए 30 मिनट का समय दे सकते हैं, तो कृपया यहाँ चैट के लिए साइन अप करें: https://calendly.com/stevencl/vs-code-tabs/

दुर्भाग्य से, मैं अगले सप्ताह केवल दिन के समय (मैं एडिनबर्ग, स्कॉटलैंड में हूं) के दौरान समय स्लॉट की पेशकश कर सकता हूं।

tl; डॉ; VS कोड के अंदरूनी सूत्रों में टैब सक्षम करें workbench.editor.showTabs: true

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

इस कार्य आइटम के विवरण से, @TurkeyMan ने टैब और कार्यक्षेत्र से एक टैब को एक नई विंडो के अंदर खोलने का एक तरीका है। मैंने बाद को https://github.com/Microsoft/vscode/issues/8171 में निकाला है क्योंकि यह हमारे द्वारा किए गए टैब के काम से संबंधित नहीं है।

कृपया टैब पर समस्याएँ दर्ज करना जारी रखें क्योंकि आप उन्हें आज़माते हुए देखते हैं। अंदरूनी सूत्र निर्माण के परीक्षण में मदद करने के लिए धन्यवाद!