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

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

@stevencl @ bgashler1 कृपया टैब पर फिर से ध्यान रखें कि मुझे टर्मिनल के focusNext और focusPrevious कार्यों के लिए उचित डिफ़ॉल्ट कीबाइंडिंग नहीं मिलेंगी (मैं .trl + shift + j / k)।

हमें इस मुद्दे के संदर्भ में इस पर विचार करने की आवश्यकता है: https://github.com/Microsoft/vscode/issues/9659

मैं वास्तव में टैब डिजाइन के भीतर एक टैब से सावधान हूं। हम टैब दिखाने के लिए सभी उपलब्ध स्थान का उपयोग करके समाप्त करेंगे :-)

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

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

यदि हम विभाजित टर्मिनलों के लिए दरवाजा खोलते हैं, तो विभाजन के लिए इसका क्या अर्थ होगा जैसे एक टर्मिनल और एक डीबग उत्तर? क्या यह वही UX इंटरैक्शन है?

@bpasero को विभाजित करके मेरा मतलब है कि साइड में एक नया टर्मिनल बनाएं, इसलिए हां यह वही होगा।

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

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

* संभवतः हम उन्हें एक्स-अक्ष पर खींचकर और किसी क्षेत्र से बाहर खींचने की कोशिश करने पर अक्षम-कर्सर होने से सीमा के बारे में सूचित कर सकते हैं, लेकिन इस काम की उम्मीद कर रहे लोगों से बचना मुश्किल है।

जब हम संपादक समूहों के क्षैतिज विभाजन का परिचय देते हैं, तो हम जिन बाधाओं को लगा रहे हैं, उनमें से एक यह है कि संपादक समूह केवल क्षैतिज रूप से विभाजित या लंबवत रूप से विभाजित हो सकते हैं। तो यह उपयोगकर्ताओं के लिए एक पैनल है कि एक क्षैतिज संपादक समूह के समान हड़ताली लग रहा है के लिए अलौकिक हो सकता है (लेकिन यह बिल्कुल उसी तरह व्यवहार नहीं करता है) ऊर्ध्वाधर संपादक समूहों के नीचे बैठे।

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

संपादक टैब के साथ टर्मिनल को संरेखित करने के विकल्प के बारे में क्या, ताकि टर्मिनल स्वचालित रूप से संपादक फ़ाइल की भाषा को दर्शाता है?

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

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

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

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

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

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

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

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

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

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

Settings.json फ़ाइल की संभावना होगी कि उपयोगकर्ता प्रत्येक टर्मिनल.internal.shell के विरुद्ध विशिष्ट भाषा एक्सटेंशन (.js, .cs, .rb) में प्रवेश करे। प्रविष्टि ताकि फ़ाइल में तार्किक मेल हो। डिफ़ॉल्ट शेल किसी भी फ़ाइल प्रकार के लिए कॉन्फ़िगर किया जा सकता है जो सेटिंग में निर्दिष्ट नहीं है। जेसन।

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

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

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

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

@Tyriar
वे अच्छी चिंताएं हैं, लेकिन मुझे लगता है कि विचार के रूप में लेने पर उन्हें आसानी से हल किया जा सकता है।

भटकाव से बचें
अपनी डिफ़ॉल्ट स्थिति में, एक अपुष्ट नई स्थापना में, टर्मिनल एक परिचित तरीके से व्यवहार कर सकता है। यह एक अप्रत्याशित व्यवहार से भटकाव से बचाता है।

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

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

जटिलता के बोझ के बिना समाजीकरण
एक प्रासंगिक टर्मिनल के साथ आपके सभी संपादकों के कई गोले भारी या कर लगाने का अनुभव नहीं करेंगे। सही मॉडल को देखते हुए UI / UX लोग इसे सुरुचिपूर्ण ढंग से काम कर सकते हैं।

मुझे लगता है कि आपकी चिंताओं को पूरी तरह से संबोधित किया जा सकता है।

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

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

तो इस मामले में त्वरित अवलोकन होना व्यवहार्य है कि टर्मिनलों को क्या खोला जाता है और वे क्या चल रहे हैं (संभवतः रन की स्थिति के साथ)। मुझे यकीन नहीं है कि यह नामांकित / maked टैब के बिना कैसे किया जा सकता है।

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

एक और सवाल कार्य धावक के साथ सहकारी उपयोग है। जिसका उपयोग वर्तमान में एक समय में केवल एक कार्य को चलाने के लिए किया जाता है। लेकिन यह https://github.com/Microsoft/vscode/issues/981 मानती है कि यह कई बैकग्राउंड टास्क को सपोर्ट करने वाला है - इसलिए यह कई टर्मिनलों की तरह (मैं विवाद नहीं कहूंगा) उद्देश्य है।

Jetbrains Webstorm curenlty में ऐसी क्षमताएं हैं - यह कई कार्य (ग्रन्ट / गल्प / npm के माध्यम से) और कई टर्मिनल (नामित टैब के साथ) चला सकती हैं। और आप वहां एक विभाजन दृश्य का उपयोग भी कर सकते हैं, जहां एक तरफ आप रनिंग कार्य देखते हैं, और दूसरे पर - टर्मिनल। (स्क्रीन संलग्न करना)

@सफेद रंग

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

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

नामित गोले
एक साधारण हाइपरटेक्स्ट स्ट्रिंग के विचार से एक टर्मिनल फलक के भीतर एक शेल उदाहरण का नाम दिखाते हुए एक वैकल्पिक निर्माण और नामकरण की संभावना आती है। इसलिए, उपयोगकर्ता के पास सेटिंग्स में एक एकल शेल कॉन्फ़िगर किया गया है ।json, जो 'cmd' हो सकता है।

एक बार जब वे एक शेल में होते हैं, तो वे या तो एक अन्य शेल में कूद सकते हैं, जैसे 'पॉवरशेल' या 'बैश', और टर्मिनल हेडर में 'cmd' नाम का हाइपरटेक्स्ट स्ट्रिंग उस शेल को प्रतिबिंबित करने के लिए बदल सकता है जिसमें उपयोगकर्ता कूद गया था।

या, उपयोगकर्ता स्टार्टर 'cmd' शेल से एक अतिरिक्त शेल उदाहरण बना सकता है, जो शायद टर्मिनल कमांड का उपयोग करके "नया" बनाता है"।

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

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

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

सरल, एकल शेल उपयोगकर्ता
हालाँकि, यदि कोई उपयोगकर्ता सरलीकृत और एकल टर्मिनल / शेल चलाना चाहता है, तो उसे प्राप्त करने के तरीके में कुछ भी नहीं है, और महत्वपूर्ण बात यह है कि कॉन्फ़िगरेशन सरल है। यह विचार मैट्रिक्स में सिर्फ एक और उपयोग परिदृश्य है।

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

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

फ़ाइल टैब के समान टर्मिनल टैब दिखाने के बारे में कैसे?
यह UI को पॉलेट नहीं करेगा और कोई कार्यात्मक रूप से नहीं खो जाएगा।

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

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

मैंने एक एक्सटेंशन के साथ लिखा है कि आप npm / gulp कार्य का चयन कर सकते हैं, यह टर्मिनल (कार्य नाम के साथ) लॉन्च करेगा और इसे वहां चलाएगा, स्टेटस बार पर एक आइटम भी रखेगा जिसे आप किसी भी समय क्लिक कर सकते हैं, साथ ही साथ रनिंग प्रोसेस स्टेट की बेसिक ट्रैकिंग करता है।

बस संभव "टैब" स्थान दिखाने के लिए, वे मंदिर के तल पर हो सकते हैं।

@whitecolor : open_mouth: यह नए टर्मिनल API का उपयोग कर रहा है? वह तो कमाल है!

@Tyriar हाँ, आप जिस पर काम कर रहे हैं: पलक:

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

कुछ ऐसा जो वेबस्टॉर्म नहीं करता है, हालांकि यह है कि यह खुले टर्मिनल टैब की संख्या को नहीं बचाता है।
जब आप विकसित करते हैं तो आपको आमतौर पर समान टैब (सर्वर, वॉचर, बैकएंड ...) की आवश्यकता होती है। अगर टैब की संख्या को बचाया जा सकता है और साथ ही उनके नाम के साथ यह भयानक होगा।

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

• जब vscode पुनः आरंभ किया जाता है तो एक मानक टर्मिनल बनाया जाएगा, आप इसके लिए एक स्टेटस बार आइटम संलग्न नहीं कर सकते
• जब उपयोगकर्ता द्वारा एक टर्मिनल का निपटान किया जाता है, तो एक्सटेंशन अनजान होता है, इसलिए स्थिति बार आइटम कम से कम चारों ओर चिपक जाएगा जब तक कि # 10925 फिर से क्लिक नहीं किया जाता है
• (बग) किसी टर्मिनल को निपटाने पर पैनल # 11275 दिखाएगा
• V1.6.0 में आने से संभवतः टर्मिनल डिफ़ॉल्ट रूप से छिपाया जाएगा, इसलिए आपको इसे बनाने के बाद Terminal.show सही में कॉल करना होगा # 11384

साझा करने के लिए @Tyriar धन्यवाद, आप सूची का जवाब देंगे:

1) हां यह इतना महत्वपूर्ण नहीं है, मेरा विस्तार वास्तव में "नया टर्मिनल खोलें" एक कमांड जोड़ता है और नए नाम वाले टर्मिनल को खोलने की अनुमति देता है, मैं आमतौर पर केवल मानक बंद करता हूं, और निर्मित एक का उपयोग करता हूं, लेकिन यह अच्छा होगा यदि कोई एक्सेस हो। पैनल में सभी मौजूदा टर्मिनल।
2) हाँ एक्सटेंशन टर्मिनल राज्य के बारे में अनजान है, लेकिन मैं PID द्वारा terminal._id की बाल प्रक्रियाओं को ट्रैक करता हूं, इसलिए मुझे पता है कि जब टर्मिनल उपयोगकर्ता द्वारा निपटारा किया जाता है (बच्चे की प्रक्रिया 0 पर जाती है)। इसलिए मैं भविष्य में _remove_ इस प्रक्रिया आईडी से क्या पूछूंगा, निश्चित नहीं कि अगर यह सार्वजनिक होना चाहिए)। इसलिए मैं चल रही बाल प्रक्रियाओं की मात्रा को भी ट्रैक करता हूं और यदि गिनती कम हो जाती है तो इसका मतलब यह हो सकता है कि कुछ गलत या कार्य समाप्त हो गया है, तो मैं इस टर्मिनल को दिखाता हूं, जो काफी उपयोगी है।
3) इसलिए मैं वर्तमान में डिस्पोजल का उपयोग नहीं करता।

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

एक्सटेंशन वास्तव में तैयार है प्रकाशित होने के लिए, शायद दिनों पर ऐसा करेंगे।

@whitecolor वर्तमान में केवल एपीआई के माध्यम से बनाए गए टर्मिनलों तक पहुंच है, हालांकि यह बदलने के लिए काफी सम्मोहक मामला है।

डरपोक डरपोक terminal._id झाँकते हैं: पलक: यह शायद कभी भी जल्द ही बदल नहीं जाएगा, लेकिन जैसे ही आप सुन सकते हैं एक घटना जोड़ी गई है, आपको निश्चित रूप से इसका लाभ उठाना चाहिए कि यह आधिकारिक स्थिर एपीआई होगा। # 11422 में बाल प्रक्रिया पर नज़र रखने और आउटपुट का पता लगाया जाना है (आप इस विषय पर कुछ चर्चा के लिए इससे जुड़े मुद्दों का पालन कर सकते हैं)।

नामित टर्मिनल कमांड के साथ आप # 10023: स्माइली के लिए वर्कअराउंड प्रदान कर रहे हैं:

अच्छा काम है, इसे आज़माने के लिए तत्पर हैं!

@whitecolor FYI करें, इसलिए मैंने झूठ बोला और terminal._id शायद v1.6 में बदलकर कुछ रैंडम आईडी बन जाएगा, पीआईडी ​​नहीं। मैं टर्मिनल पैनल को प्रक्रियाओं से अलग करने के लिए एक विशाल रिफ्लेक्टर के बीच में हूं (ताकि वे मौजूदा # 11275 पैनल के बिना भी मौजूद रह सकें) और मुझे नहीं लगता कि मैं इसे दुर्भाग्य से वहां रख सकता हूं।

@whitecolor आप कल के अंदरूनी सूत्रों में window.onDidCloseTerminal (# 10925) आज़मा सकते हैं। पीआईडी ​​पर नज़र रखने की तुलना में यह आसान होना चाहिए।

मैं इसे इंटेलीज की तरह देखना चाहता था। इस तक, मैं इसे इस निजी कीबिंग में जोड़ता हूँ:

[
    {
        "key": "ctrl+pageup",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },{
        "key": "ctrl+pagedown",
        "command": "workbench.action.terminal.focusPrevious",
        "when": "terminalFocus"
    }
] 

टैब के बीच नेविगेट करने के लिए एक ही कीबोर्डबोर्ड शॉर्टकट, लेकिन अगर टर्मिनल टर्मिनल के बीच टर्मिनल टॉगल पर ध्यान केंद्रित करता है।

टर्मिनल टैब पर स्प्लिट दृश्य सुपर उपयोगी होगा;

मैं वर्तमान में एक सर्वर उदाहरण के साथ अवधारणा का प्रमाण देने और दूसरे कंसोल टर्मिनल के माध्यम से अनुरोधों को निष्पादित करने का प्रयास कर रहा हूं।

इस पर कोई प्रगति?

@MeirionHughes
tmux एक समाधान हो सकता है लेकिन यह VSCode इंटीग्रेटेड टर्मिनल के अंदर (विंडोज़ में आखिरी बार) काम करता है।

@MeirionHughes यहाँ उस सुविधा के लिए मुद्दा है https://github.com/Microsoft/vscode/issues/7504। अब तक कोई प्रगति नहीं हुई, पिछली बार जब मैंने इसके लिए धक्का दिया तो मुझे टीम से वापस धक्का मिला। अधिक: +1: हालांकि उस मुद्दे पर बेहतर है।

@Tyriar आप कह सकते हैं कि यह मुद्दा विभाजन के लिए भी कह रहा है, क्योंकि तीसरी छवि में यह स्पष्ट रूप से

@MeirionHughes पहली टिप्पणी (मेरा) कहते हैं:

आइए # 7504 में टर्मिनल को विभाजित करते हुए ट्रैक करें

इसका कारण यह है कि 2 अलग-अलग विशेषताओं के लिए चर्चा एक-दूसरे के लिए शोर पैदा नहीं कर रही है।

ओह दोस्तों, pls मदद के रूप में यह वास्तव में महत्वपूर्ण UI सुविधा है, कभी-कभी यह कंसोल को बदलने के लिए crz हैंडल ड्रॉपडाउन बनाता है, बहुत बहुत धन्यवाद;)

+1 cycle terminal कीबाइंडिंग के लिए।

@whitecolor _darn! _ मैंने सोचा था कि एकीकृत टर्मिनल के भीतर tmux का अपना चतुर काम था, लेकिन यू ने मुझे हरा दिया। मेरे लिए ठीक काम करता है (कोई mouse mode ) लेकिन ठीक काम करने वाले पैन:

माउस मोड मेरे लिए tmux के साथ ठीक काम कर रहा है।

किसी भी मामले में, मुझे लगता है कि यह एक महान जोड़ है

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

Im भी टर्मिनलों के माध्यम से चक्र करने के लिए एक कीबाइंडिंग पर सिर्फ +1 जा रहा है। मुझे उस छोटे ड्रॉपडाउन पर क्लिक करने के लिए माउस का उपयोग करने से नफरत है, खासकर ट्रैक पैड वाले लैपटॉप पर।

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

@ psimoneau22 यह कीबाइंडिंग है जिसका मैं उपयोग करता हूं:

{ "key": "ctrl+shift+j",    "command": "workbench.action.terminal.focusNext" },
{ "key": "ctrl+shift+k",    "command": "workbench.action.terminal.focusPrevious" },

हम जल्द ही विभाजित होने जा रहे हैं।

मैं विश्वास नहीं कर सकता कि यह संपादक कितना अच्छा और शक्तिशाली हो रहा है। यह केवल कोड को खोलने के लिए और कोडिंग सत्र के दौरान और कुछ नहीं के लिए एक सुपर शक्तिशाली जोड़ होगा।

टी एल; डॉ; Tmux को लेने के लिए कुछ घंटों का उपयोग करें।

मैं अपने टर्मिनल में tmux से खुश हूँ (माउस मोड एक आकर्षण की तरह काम करता है)। मुझे सीखने में एक दिन लगा। मैंने कुछ समय पहले इसके साथ खेला है, लेकिन मैंने कल इसे एक बॉस की तरह स्थापित करने में खर्च किया। मैं अभी iTerm में एक tmux -CC करता हूं - जो एक टर्मिनल विंडो लॉन्च करता है। फिर उस सत्र पर हुक करने के लिए vscode टर्मिनल में tmux a करें - यह मैं लगातार टर्मिनल सत्र प्राप्त कर रहा था, इसलिए मैं vscode (अपडेट Vscode, एक्सटेंशन इंस्टॉल करें) को पुनः आरंभ करते हुए सत्र से हमेशा वापस आ सकता हूं। टर्मिनल में टैब या विभाजन होने की तुलना में यह मेरे लिए एक बेहतर सुविधा है। कृपया Vscode प्रकाश रखें। एटम (मैं इससे आया था) से सीखने के लिए एक सबक है। TMUX FTW :)

इसी दृष्टिकोण ने मेरे लिए Mac / cygwin / windows में भी काम किया है और हर जगह Vscode रन के लिए बहुत अधिक काम करना चाहिए।

टी एल; डॉ;

ड्रॉपडाउन के बजाय इंटीग्रेटेड टर्मिनल के लिए टैब रखना अच्छा होगा। भविष्य में इस सुविधा को देखने का कोई मौका?

शॉर्टकट ctrl + shift + ` और ctrl + ` को देखते हुए मेरा मानना ​​है कि ये सेटिंग्स अधिक मायने रखती हैं।

  {
        "key": "ctrl+shift+right",
        "command": "workbench.action.terminal.focusNext"
    },
    {
        "key": "ctrl+shift+left",
        "command": "workbench.action.terminal.focusPrevious"
    }

@leocaseiro @Tyriar @ psimoneau22 जब तक आप एक मैक का उपयोग नहीं कर रहे हैं, यह 'जब' विकल्प को ctrl + shift left और ctrl रूप में जोड़ने लायक है। shift + right का उपयोग संपादक में पाठ का चयन करने के लिए किया जाता है।

    {
        "key": "ctrl+shift+j",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },
    {
        "key": "ctrl+shift+k",
        "command": "workbench.action.terminal.focusPrevious",
         "when": "terminalFocus"
    }

या

    {
        "key": "ctrl+shift+right",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },
    {
        "key": "ctrl+shift+left",
        "command": "workbench.action.terminal.focusPrevious",
         "when": "terminalFocus"
    }

यहाँ इस बेहद वांछित सुविधा के लिए मेरा 2ct (खेद है कि कुछ बिंदुओं का पहले ही उल्लेख किया गया है)

बक्सों का इस्तेमाल करें
कारण है कि मैं पहले मामले में कई टर्मिनलों का उपयोग आमतौर पर या तो कर रहे हैं:

• मुझे समानांतर में दो निर्देशिकाओं में काम करने की आवश्यकता है और हर समय cd आगे और पीछे नहीं करना चाहते हैं
• मुझे दो अलग-अलग टर्मिनलों के साथ काम करने की आवश्यकता है (जैसे bash बनाम पावरशेल बनाम cmd या स्थानीय बनाम रिमोट / ssh)
• मैं समानांतर में दो अलग-अलग कार्यक्रमों के आउटपुट की निगरानी करना चाहता हूं

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

यूआई
वर्तमान टैब का विस्तार क्यों नहीं किया जाता है (जैसे डिबगिंग, ऊपुत, टर्मिनल ...) और एक अतिरिक्त "टर्मिनल 1, टर्मिनल 2, टर्मिनल 2 ....) की अनुमति दें।

टैब्स बनाम ड्रॉप-डाउन

• आप सभी उपलब्ध टैब देखें
• यह याद रखना आसान है (मेरे लिए) कि कौन सा टर्मिनल किस उद्देश्य से कार्य करता है यदि वे अलग-अलग दृश्य स्थानों (जैसे 3 टैब) द्वारा दर्शाए जाते हैं

tl; डॉ

मैं @MikeGitb के साथ दृढ़ता से सहमत

एक पागल विचार: क्यों नहीं टर्मिनल को नियमित संपादक टैब के समान दर्जा दिया जाए? विशेष रूप से आसान होगा यदि कोई एक ही समय में एक से अधिक लाइनों को देखना चाहता है।

एक पागल आइडिया

यह पागल नहीं है, यह कैसे विम / नवविराम काम करता है।

यह पागल नहीं है, यह कैसे विम / नवविराम काम करता है।

जैसा कि कई अन्य IDE;) करते हैं।

क्षमा करें, यह परिचय वास्तव में विडंबनापूर्ण था।

@ टायर अपने कोड के साथ टर्मिनल के ऊर्ध्वाधर पैनिंग की अनुमति देने की सुविधा है या इसकी अनुमति नहीं होगी?

@ajrator जो https://github.com/Microsoft/vscode/issues/2806 में कवर किया गया है

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

मैं यह भी देखता रहूंगा कि कब यह ड्रॉपडाउन के बजाय एकीकृत टर्मिनल के टैब्ड व्यू को प्रकाशित करेगा।

ड्रॉपडाउन मेनू उपयोग करने के लिए थोड़ा असहज है। इसके अलावा एक से अधिक खुले टर्मिनल होना बहुत अच्छा होगा।

उन लोगों के लिए जो टैब समर्थन की प्रतीक्षा करते हुए tmux का प्रयास करना चाहते हैं, मैंने सेटअप को किकस्टार्ट करने के लिए एक जिस्ट बनाया। इसमें डिफ़ॉल्ट रूप से माउस सपोर्ट सक्षम है और टर्मिनल को विभाजित करने के लिए सरल बाइंडिंग का उपयोग करता है।
https://gist.github.com/cybertim/e8b42c8cd8a5bebaa3eb8cec17a2746f

धन्यवाद @ बर्बर , महान फ़ाइल! मैंने पहले से ही tmux का उपयोग किया है लेकिन यह फ़ाइल काम में है।

कारण मैं व्यक्तिगत रूप से खिड़की के भीतर अलग-अलग स्थिति में कई टर्मिनलों पर काफी उत्सुक होगा, उम्मीद है कि यह VSCode के भीतर पर्यावरण की तरह RStudio / Jupyter लैब को लागू करने का मार्ग प्रशस्त करेगा।

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

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

अगला, अभी भी टैब चाहते हैं? फलक? विभाजन?

मुझे लगता है कि यहां बहुत से लोग एक ऐसी सुविधा का अनुरोध कर रहे हैं जो VScode के लिए ओवरकिल है। अगर वे सिर्फ tmux को जाने देंगे, तो वे इसके लिए नहीं पूछेंगे। हमें टर्मिनल दिया गया है। Tmux का उपयोग करना, यह टैब का समर्थन करता है। Tmux सीखने के लिए आप कुछ घंटे अधिकतम लेंगे। टैब, विंडो, विभाजन, और भी बहुत कुछ है, यदि आपको VSCode को पुनः आरंभ करने की आवश्यकता है तो आप अपने tmux sesion में वापस जाने के लिए पुनः आरंभ करने के बाद tmux -a टाइप कर सकते हैं। माउस मोड पर स्विच करने के बाद (विन्यास में सिर्फ एक पंक्ति), आप यहां तक ​​कि पैन का आकार बदल सकते हैं, उस टैब पर जाने के लिए टैब पर क्लिक करें। मैं VSCode में इस सुविधा के खिलाफ हूं। यह केवल प्रदर्शन को धीमा करने वाला है। VSCode को जितना संभव हो उतना हल्का रखें - हमें दूसरा एटम नहीं चाहिए। Tmux भारी उठाने करते हैं! जैसा कि आप नीचे देख सकते हैं, मेरे पास विभाजन है और यदि आप नीचे की तरफ देखते हैं, तो मेरे पास दो टैब हैं - python & fish । और हाँ, नीचे बाईं ओर, मैं Google को कमांड लाइन में googler का उपयोग करता

@piggyslasher मैं यह नहीं देखता कि यह फीचर vscode को कैसे धीमा कर सकता है।
Vscode पहले से ही एक से अधिक टर्मिनल उदाहरण होने का समर्थन करता है। यह सुविधा सिर्फ टैब फ़ीचर का उपयोग करने के लिए ड्रॉपडाउन चॉसर को एक आशावादी अच्छे व्यक्ति में बदलने के बारे में है।

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

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

@piggyslasher का सुझाव दिलचस्प है, हालांकि यदि आप इसके बारे में सोचते हैं, जैसे 'इसे tmux करते हैं'।

यह एक ऐसी चीज है जिसके बारे में मैं लंबे समय से सोच रहा था। Tmux के पास tabs और प्रत्येक tab को कई panes रूप में विभाजित किया जा सकता है। इसके विपरीत संपादकों के पास panes और फिर प्रत्येक pane में tabs ।

मुझे नहीं बल्कि tmux तरीका पसंद है क्योंकि यह 'टर्मिनलों के इस लेआउट से संबंधित है, और फिर हम संबंधित टर्मिनलों के दूसरे टैब पर स्विच करते हैं'

प्रतिक्रिया / कोणीय विकास जैसी किसी चीज़ के लिए, यदि आप एक जेएस / एचटीएमएल / सीएसएस / टेस्ट 'फलक' प्रत्येक घटक के लिए खुला है, और आपके द्वारा काम कर रहे प्रत्येक घटक के लिए एक 'टैब' है, तो मैं इसे उपयोगी देख सकता हूं।

मुझे यह देखने में दिलचस्पी होगी कि क्या प्लगइन में ऐसा कुछ करना संभव है। Origami उदात्त के लिए करीब है, लेकिन यह अभी भी नहीं 'शीशे का पूरा टैब' 'टैब से भरी शीशे'।

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

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

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

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

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

अगर इससे कोई मतलब नहीं है, या अगर मैं स्पष्ट कह रहा हूं, तो मुझे बताएं।

@ निक-वॉल्ट जब आप कहते हैं:

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

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

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

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

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

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

एक साल से अधिक पुराना @ bgashler1 ने यह कहा:

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

तो शायद इस समय उन टैब पर विचार करना सबसे अच्छा है, जो संपादक टैब के लिए अलग-अलग हैं, यह दर्शाता है कि वे संपादक टैब के साथ _not_ विनिमेय हैं, किसी भी भ्रम से बचने के लिए?

मैं मानता हूं, टैब्स अलग-अलग कंसोल का चयन करने के लिए एक बहुत अच्छा समाधान है।

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

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

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

• निर्देशिका स्थान
• परियोजना
• फ़ाइल प्रकार (हो सकता है कि जब फाइलें उसी स्थान पर हों)
• संपादक समूहन (उपयोगकर्ता परिभाषित)
• कुछ अन्य अमूर्त

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

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

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

और प्रत्येक टैब स्वचालित रूप से लोड किए गए कंसोल के प्रकार को प्रदर्शित कर सकता है, जैसे कि Git, Node, CMD, Powershell ... टर्मिनल 1, टर्मिनल 2, आदि प्रदर्शित करने के बजाय ( @Perkovec द्वारा

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

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

यदि मैं आपको सही तरीके से समझता हूं, तो मैं संपादक खिड़कियों के साथ टर्मिनल को जोड़ने के सख्त खिलाफ हूं। ज्यादातर समय मैं संपादक टैब और टर्मिनलों के बीच एक निश्चित संबंध नहीं रखता हूं और जब मैं ऐसा करता हूं तो निश्चित रूप से 1: 1 मैपिंग नहीं होती है (आमतौर पर 1: एन भी नहीं)।

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

कुछ दोनों मिश्रण करना चाहते हैं, इस पर निर्भर करता है कि वे क्या कर रहे हैं और वे किस कंसोल का उपयोग कर रहे हैं। यह यूआई / यूएक्स समस्या का सिर्फ एक शोधन है जिसे रचनाकारों को काम करना होगा। किसी भी UI / UX चुनौती के लिए भी।

प्रासंगिक संपादक / कंसोल UX का उपयोग मामला होने जा रहा है:

• कोई संदर्भ नहीं (किसी विशेष संपादक से संबद्ध कोई कंसोल नहीं)
• मिश्रित संदर्भ (कुछ कंसोल जुड़े, कुछ नहीं)
• सभी संदर्भ (एक संपादक से जुड़े सभी कंसोल)

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

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

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

बस अपने उपयोग के मामले को समझने के लिए: क्या मैं पूछ सकता हूं कि आप टर्मिनल पर किस तरह के ऑपरेशन करते हैं, जो परियोजना / निर्देशिका के विपरीत एक विशिष्ट फ़ाइल से बंधे हैं?

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

बहुत यकीन है कि लगभग हर कोई संपादक टैब के स्वतंत्र रूप से टर्मिनल उदाहरणों का उपयोग करता है। एक्सटेंशन के रूप में ऐसी सुविधा बेहतर होगी।

हाँ, मैं एक्सटेंशन के साथ कंसोल अनुभव का विस्तार करने से सहमत हूं। संभवतः इस क्षेत्र को विकास के लिए खोलने का सबसे अच्छा तरीका है।

सबको बनाने के लिए VScode में कंसोल इंजन बनाना एक दिलचस्प प्रयोग होगा।

यहां बताया गया है कि Cloud9 IDE कैसे काम करता है:

ऐसा लगता है कि हम में से कई लोग क्या देख रहे हैं: कोई भी नया टैब एक संपादक या टर्मिनल हो सकता है, और किसी भी टैब को क्षैतिज या लंबवत रूप से स्थानांतरित और विभाजित किया जा सकता है।

@plmrry यह कमाल है! उस दिशा में कुछ करना अच्छा होगा।

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

यदि संपादक टैब में कई टर्मिनल हैं, कुछ अग्रभूमि में, कुछ पृष्ठभूमि में हैं, तो कुछ टर्मिनल कमांड जो करते हैं उसका प्रश्न उतना स्पष्ट नहीं है और उतना सहज नहीं होगा।

क्या टर्मिनल कमांड केवल उस लक्ष्य को लक्षित कर सकता है जो पिछली बार केंद्रित था? उसी तरह से जो cmd + Shift + t उस टैब को लक्षित करेगा जो अंतिम बंद था

@btoo शायद ऐसी दुनिया में क्या करेगी। यह बहुत ही आमूलचूल परिवर्तन है कि वीएस कोड हालांकि कैसे काम करता है।

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

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

+1
टर्मिनल में टैब चयन की तुलना में अधिक UX के अनुकूल हैं और बहुत अधिक स्थान नहीं लेते हैं

+1

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

अगर उस के साथ एक प्रदर्शन मुद्दा होने जा रहा था तो vscode भी जम जाएगा अगर मैं एक टैब में npm रन सर्वर और दूसरे में mongod चला गया (या जो भी कई कमांड को चलाने की आवश्यकता हो सकती है)।

इस पर छोटा अपडेट: मैं वर्तमान में टर्मिनल को सुलभ बनाने के साथ सेवन कर रहा हूं (https://github.com/Microsoft/vscode/issues/8339), उसके बाद मैं जिस प्रमुख कृति पर काम करूंगा वह संभवत: होने जा रही है टर्मिनल बंटवारा (https://github.com/Microsoft/vscode/issues/7504) जो इस मुद्दे से दूर हो गया था (और संभावना है कि बहुत से लोग इसे वास्तव में चाहते हैं)। यह रोडमैप https://github.com/Microsoft/vscode/wiki/Roadmap#terminal पर है

@AnthonyMichaelc कई प्रदर्शनों के साथ कोई प्रदर्शन चिंता का विषय नहीं है, हाल के सुधारों के बाद टर्मिनल सुपर फास्ट है।

(बंटवारा) होने की संभावना है जो लोग वास्तव में चाहते हैं

@ टायरियर मैंने टैब को मुझे संदेह है कि अधिकांश अन्य लोगों का यह भी मतलब था कि उन्होंने किसके लिए मतदान किया था - एक लंबवत या क्षैतिज रूप से संकीर्ण टर्मिनल मेरे लिए ऐसा नहीं करता है।

... मैं उन सभी के माध्यम से पढ़ता हूं, और मुझे विश्वास नहीं हो रहा है कि मैं इस विचार से चूक गया:

मौजूदा टैब बार में अतिरिक्त टैब क्यों नहीं जोड़े जाते हैं, जब नए टर्मिनल खोले जाते हैं?
Problems | Output | Debug Console | Terminal 1 | Terminal 2 | Terminal 3 ...
... इसके अलावा, डिबग कंसोल बहुत उपयोगी नहीं है यदि आप वास्तव में डिबगर का उपयोग नहीं कर रहे हैं .. बस एक तरफ।

(और संभावना है कि बहुत से लोग इसे वास्तव में चाहते हैं)

मैं केवल यही पेस्ट करूंगा .... (इस विषय में पहली पोस्ट)

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

@PixelT जिस पोस्ट को आप उद्धृत कर रहे हैं

@ मिमिकमेकाना कृपया मेरी पोस्ट को एक बार फिर से समझने के साथ पढ़ें, क्योंकि मैं देख रहा हूं कि आप इसे नहीं समझ रहे हैं + मैंने कुछ भी नहीं हटाया:]

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

@mikemaccana विभाजन: https://github.com/Microsoft/vscode/issues/7504

क्या हमारे पास टैब रखने का विकल्प हो सकता है लेकिन डिफ़ॉल्ट रूप से इसे बंद कर सकते हैं?

इनसाइडर में विभाजन का पूर्वावलोकन उतरा है, पूर्ण अद्यतन के लिए https://github.com/Microsoft/vscode/issues/7504#issuecomment -365683609

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

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

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

@AnthonyMichaelc

मुझे यकीन है कि कोई शिकायत करेगा कि मैं 15 टर्मिनल क्यों नहीं डाल सकता, लेकिन मेरे लिए यह बहुत अच्छा होगा।

योजना वास्तव में आप जितनी चाहें उतनी अनुमति देने के लिए है, मैंने केवल n = 2 के लिए समस्या को हल किया है हालांकि।

जाली का नक्शा

हम अब इस पर सक्रिय रूप से चर्चा कर रहे हैं, यहां तक ​​कि इसे फ़रवरी की योजना पर भी जगह मिली है https://github.com/Microsoft/vscode/issues/43361

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

मैंने इसे अभी तक नहीं देखा है, लेकिन मैं धीमेपन के लिए एक नज़र रखूंगा।

@AnthonyMichaelc

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

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

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

@ टायरियर जैसा कि मैं देख सकता हूं, यह टैब के बारे में है, कोई विभाजन नहीं ...?

@PixelT यह स्पष्ट रूप से संबंधित है। कई लोगों ने इस मुद्दे में एक ही समय में कई टर्मिनलों को देखने में सक्षम होने के बारे में कहा है जो विभाजन समय के लिए हल करेगा, इसलिए वे इसे उपयोगी पाएंगे।

मैं आपसे सहमत नहीं हो सकता - यह विषय मुख्य रूप से उन लोगों का अवलोकन और चर्चा करता है जो टर्मिनल में टैब चाहते हैं, टर्मिनल को विभाजित करने के लिए एक और विषय है: https://github.com/Microsoft/vscode/issues/7504 जो आपने बनाया :)

टर्मिनल टैब और विभाजन आज लगभग हर आधुनिक आईडीई में मानक हैं।

इस परीक्षण के लिए अंदरूनी सूत्रों का निर्माण, आश्चर्यजनक रूप से काम करता है, धन्यवाद @Tyriar !

अभी भी टर्मिनल में टैब के बारे में कुछ नहीं होता ... s

@PixelT क्या आपने दोहरे टर्मिनल वाले अंदरूनी सूत्र संस्करण को आज़माया है? उन्होंने जो कहा उससे वे इसे बनाने की योजना बनाते हैं ताकि आप उस लेआउट में जितने चाहें उतने टर्मिनल खोल सकें लेकिन मेरा मानना ​​है कि वर्तमान में इनसाइडर संस्करण 2 कमांड के साथ अनुमति देता है: cmd / ctrl + d मुझे विश्वास है

@Morkowski मैं देखता हूं कि आपने क्या किया।

अरे @ प्रतिक्रिया की बिट - जब Maximize Panel Size या Restore Panel Size बटन (या कीबोर्ड शॉर्टकट) का उपयोग करते हुए कंसोल का आकार बदलने पर, कंसोल पैन की चौड़ाई भूल जाती है, और प्रत्येक फलक की चौड़ाई एक बराबर राशि पर रीसेट करें।

माउस का उपयोग करके कंसोल को ऊपर / नीचे आकार देते समय चौड़ाई को याद किया जाता है।

इसी तरह, बाईं ओर पट्टी को छिपाते या दिखाते समय चौड़ाई को भुला दिया जाता है।

अंत में, फलक को जोड़ते या हटाते समय चौड़ाई को भुला दिया जाता है - हालाँकि यह सबसे अधिक समझने योग्य है।

उम्मीद है की यह मदद करेगा!

@jamesjryan वहाँ पहले 2 के लिए नवीनतम अंदरूनी सूत्र में एक मुद्दा तय किया गया था जिसका आप उल्लेख करते हैं https://github.com/Microsoft/vscode/issues/45074

इसी तरह, बाईं ओर पट्टी को छिपाते या दिखाते समय चौड़ाई को भुला दिया जाता है।

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

अंत में, फलक को जोड़ते या हटाते समय चौड़ाई को भुला दिया जाता है - हालाँकि यह सबसे अधिक समझने योग्य है।

हाँ, यह as के अनुसार बनाया गया है

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

7504

@Tyriar अपडेटेड - वर्णित के रूप में काम करता है, धन्यवाद!

@KillyMXI यह अंतिम लक्ष्य की ओर प्रगति कर रहा है, और अपने वर्तमान स्वरूप में भी बहुत उपयोगी कार्यान्वयन है।

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

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

मुझे लगता है कि अंतिम गेम उपयोगकर्ता को कभी भी टर्मिनलों को लगाने की सुविधा दे रहा है, लेकिन शायद यह एक अच्छा स्टॉपगैप समाधान है?

@jamesjryan मैं Tyriar के समाधान को टैब की दिशा में प्रगति के रूप में नहीं देख सकता। मुझे पूरी तरह से ऑर्थोगोनल चीज लगती है।

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

अंत में हम टैब पर वापस आते हैं।

इसी तरह की बात ऊपर प्रस्तावित थी, वास्तव में: https://github.com/Microsoft/vscode/issues/10546#issuecomment -359632932
टर्मिनलों की सूची के साथ ड्रॉपडाउन को प्रतिस्थापित करते समय यह सबसे स्पष्ट बात है।

मैंने कोशिश की होती

• टर्मिनल टैब को दाईं ओर संरेखित करें;
• या टर्मिनलों से पहले एक ऊर्ध्वाधर रेखा जोड़ें;
• या दाईं ओर संरेखित करें और बाईं ओर आइटम के करीब पहुंचने पर एक ऊर्ध्वाधर रेखा दिखाएं।

मैं हर टैब पर "टर्मिनल" शब्द डालने से बचना चाहता हूँ। यह पर्याप्त स्पष्ट होगा कि यह क्या है।
या हो सकता है कि शब्द "टर्मिनल:" का उपयोग एक दृश्य विभाजक के रूप में किया जाए।

Problems   Output   Debug Console                  Terminals:  Git   Bash, Bash   +   []   ^

तो यह अंतिम परिणाम की तरह है जो मैं यहाँ आशा करूँगा:

Https://atom.io/packages/terminal-tab से लिया गया

यह समझना सरल और आसान है और अंतिम उपयोगकर्ता को लचीलापन देता है कि वे अपनी आईडीई को कैसे विभाजित / संरचना करना चाहते हैं।

मैं उलझन में हूं। हमारे पास पहले से ही नीचे, दाएं, बाएं या पूर्ण स्क्रीन पर एक टर्मिनल हो सकता है।

हमारे पास पहले से ही नीचे, दाएं, बाएं या पूर्ण स्क्रीन पर एक टर्मिनल हो सकता है।

हम कर? मैं बाईं ओर एक टर्मिनल कैसे बनाऊं? अभी, मैं केवल नीचे या दाईं ओर देख सकता हूं।

आप छोड़ नहीं सकते, लेकिन फिर भी, मैं इस gif से भ्रमित हूं। जबरदस्त हंसी

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

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

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

मैं डिफ़ॉल्ट रूप से टैब बार छिपाऊंगा और 1 "टैब" दिखाई देगा। ड्रॉप डाउन चीज रखें।

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

क्या मैं कुछ भूल रहा हूँ?

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

यह वही है जो ऊपर "भ्रमित" gif प्रदर्शित करने की कोशिश करता है।

हाँ, क्षमा करें यदि जिफ़ ने इसे और अधिक भ्रमित कर दिया है लेकिन यह मूल रूप से वह आधार है जिसे मैं प्राप्त करने की कोशिश कर रहा था।

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

कुछ प्रकार के वर्कअराउंड के रूप में मैंने कीबोर्ड शॉर्टकट का पालन किया:

{
  "key": "cmd+right",
  "command": "workbench.action.terminal.focusNext"
}
{
  "key": "cmd+left",
  "command": "workbench.action.terminal.focusPrevious"
}

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

@ देवता आप को परिष्कृत कर सकते हैं कि केवल काम करने के लिए जब टर्मिनल ध्यान केंद्रित है अगर यह भी बेहतर है:

{
  "key": "cmd+right",
  "command": "workbench.action.terminal.focusNext",
  "when": "terminalFocus"
}
{
  "key": "cmd+left",
  "command": "workbench.action.terminal.focusPrevious",
  "when": "terminalFocus"
}

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

# 14909 अंक के साथ हुई प्रगति को देखते हुए। क्या हमारे पास टर्मिनल को एक सामान्य टैब में रखने का विकल्प हो सकता है जिसे किसी स्थान के दृष्टिकोण से किसी अन्य टैब के समान माना जाता है? यह उपयोगकर्ताओं को एक टन लचीलापन देता है कि वे अपने टर्मिनल को कैसे देखना चाहते हैं। सामान्य टैब को देखने और व्यवस्थित करने के तरीके के साथ अब (या बल्कि जल्द ही) इतना लचीलापन है कि टर्मिनल अब तुलना द्वारा बहुत सीमित है।

@Tyriar workbench.action.terminal.focusPrevious काम नहीं कर रहा है

मैंने workbench.action.terminal.focusPreviousPane की भी कोशिश की, क्योंकि डिफेबल्स केबंडिंग्स इसका उपयोग कैसे करते हैं, लेकिन यह काम नहीं करता है ( workbench.action.terminal.focuNextPane काम नहीं करता है)

तो संक्षेप में: केवल workbench.action.terminal.focusNext काम करता है

    {
        "key": "ctrl+pagedown",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },
    {
        "key": "cmd+pageup",
        "command": "workbench.action.terminal.focusPrevious",
        "when": "terminalFocus"
    }

VSCode संस्करण

Version 1.24.1
Commit 24f62626b222e9a8313213fb64b10d741a326288
Date 2018-06-13T17:47:35.732Z
Shell 1.7.12
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64

ओएस: लुबंटू 18.04

एक्सटेंशन के बिना परीक्षण किया गया

संपादित करें

धन्यवाद Tyriar, मैंने cmd बजाय ctrl ऊपर लिखा

@ यदि आपको मदद चाहिए तो आपको एक नया मुद्दा बनाना चाहिए (यह हमेशा Ubuntu 18 पर मेरे लिए ठीक काम किया है)।

हाल ही में टर्मिनल के साथ एक समस्या का एहसास हुआ कि यह कहाँ है: यह समस्याओं को एक ही समय में देखना असंभव बनाता है।

मुझे लगता है कि आप कई परियोजनाओं के साथ एक कार्यक्षेत्र हैं। आप क्या कर सकते हैं, प्रति प्रोजेक्ट में एक टर्मिनल है, और एक एक्सटेंशन है जो संपादक में केंद्रित फ़ाइल के आधार पर संबंधित टर्मिनल पर ध्यान केंद्रित करता है (और यह किस परियोजना से संबंधित है)

यह आपकी विशेष समस्या को हल नहीं करता है, लेकिन समस्याओं को स्विच और नोटिस करना आसान बनाता है

मैं मानता हूं कि टर्मिनल का चयन वास्तव में व्यावहारिक नहीं है, बस संख्याएँ हैं: 1: bash , 2: bash , .. यह फ़ोल्डर बेसन दिखाने के बजाय बहुत बेहतर होगा

@ ऑब देखें https://github.com/Microsoft/vscode/issues/29816

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

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

@ मर्मबेक सहमत। मुझे यकीन नहीं है कि वे टैब और विभाजन दोनों को कैसे संभाल सकते हैं, लेकिन यह उल्लेखनीय है। Tmux करता है।

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

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

क्या

मूल रूप से मैं जिस चीज की उम्मीद कर रहा हूं, वह यह है कि एक नया टर्मिनल _optically_ एक _editor tab_ के रूप में बनाया जा सकता है, मूल रूप से इस एटम एक्सटेंशन के व्यवहार की नकल करता है (जो मुझे एटम से VSCode पर स्विच करने के बाद से बहुत याद आया है)। जब एक नया टर्मिनल टैब बनाया जाता है, तो उसे उसी तरह से संपादक टैब के रूप में व्यवहार किया जाता है और एक संपादक समूह में रखा जाता है। टर्मिनल टैब को यूआई में संपादक टैब के लिए पहचाना जाता है।

टर्मिनल टैब को शुरू करने के लिए पैनल में टर्मिनलों के साथ विनिमेय होने की आवश्यकता नहीं है; वे प्रतिक्रिया एकत्र करने के लिए शुरू में पूरी तरह से अलग संस्थाओं के रूप में बनाए जा सकते हैं।

क्यों

मैं व्यावहारिक रूप से टर्मिनल में रहता हूं, और इस तरह से टर्मिनल टैब निम्नलिखित सभी समस्याओं का समाधान करता है और मामलों का उपयोग करता है:

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

यहां तक ​​कि टर्मिनल टैब्स की दुनिया में, मैं पैनल के अस्तित्व को संपादक समूहों से अलग होने के लिए उपयोगी मानूंगा और मैं पैनल के वितरण की वकालत नहीं करूंगा। पैनल समझ में आता है कि सहायक सामग्री से भिन्न जानकारी को स्थान देना है। कुंजी यह है कि, मेरे लिए, एक टर्मिनल आमतौर पर _first-class content_ मैं साथ काम कर रहा हूं, और केवल सहायक सामग्री नहीं। इस परिप्रेक्ष्य के साथ, टर्मिनलों के संपादकों के साथ रहना पूरी तरह से स्वाभाविक है।

@sagebind मुझे पैनल के भीतर टर्मिनल टैब को सक्षम करने के रूप में इस ओर पहला कदम दिखाई देता है, अनिवार्य रूप से बस कुछ कम भयानक के साथ ड्रॉपडाउन को स्वैप करना। यह तब निम्न तरीकों से बनाया जा सकता है:

1. पैनल को अधिक लचीले ढंग से https://github.com/Microsoft/vscode/issues/57029 , https://github.com/Microsoft/vscode/issues/50984 , https://github.com/Microsoft पर रखने की अनुमति दें https://github.com/Microsoft/vscode/issues/10121
2. व्यक्तिगत टर्मिनलों को पैनल से "अलग" करने की अनुमति दें और संपादक ग्रिड में रखे जाने की जांच करें क्योंकि आप इस बारे में बात कर रहे हैं (इस मुद्दे में ट्रैक किए गए प्रकार)। यह UX, कमांड्स, कीबाइंडिंग और एक्सटेंशन API पर प्रभावों का पता लगाने के लिए थोड़ा काम करने की आवश्यकता है।

इसके अलावा, @sagebind , निश्चित नहीं है कि क्या आपने कभी ConEmu के बारे में सुना है, लेकिन यह वही है जो आपने वर्णित किया है।

और यदि आप एक पुराने स्कूल गेमर हैं, तो इसमें एक भूकंप शैली नीचे है (Ctrl + ~)। इसलिए मेरे सभी कार्यकाल छिपे हुए हैं, जब तक कि यह समय नहीं है।

मुझे लगता है कि यह विस्तार दिखाता है कि स्वच्छ तरीके से टैब कैसे बनाते हैं।

https://marketplace.visualstudio.com/items?itemName=Tyriar.terminal-tabs

@PauloDanielCarneiro यह एक्सटेंशन वास्तव में VSCode के वरिष्ठ डेवलपर्स में से एक ने ही बनाया है (@Tyriar)

मुझे पता है कि यह मुद्दा पुराना है, लेकिन यह आश्चर्यजनक होगा

यह वास्तव में लापता विशेषता है जो सभी SysAdmins को ISE से VSCode तक पूरी तरह से कूदने से रोकता है।

SysAdmin के रूप में मैं अपना अधिकांश समय कई कंप्यूटरों पर एक साथ काम करने में बिताता हूं।

मैं CTRL + SHIFT + R के साथ एक दूरस्थ कंप्यूटर से कनेक्ट हूं।
यह एक नया टर्मिनल टैब खोलता है जिसका नाम संगणना है जिसके साथ मैं जुड़ा हुआ हूं।
और हर टर्मिनल टैब नीचे एक या कई स्क्रिप्ट टैब से जुड़ा हुआ है।
मैं स्क्रिप्ट टैब से टर्मिनल टैब और सीटीआरएल + आर के साथ इसके विपरीत स्विच करता हूं।

यह एक ही समय में इतना आसान, आसान और शक्तिशाली है ...

क्या इस विशेषता पर विचार किया जा रहा है?

एक प्रतिस्थापन नहीं है, लेकिन आप अपने टर्मिनल को विभाजित करने के लिए cmd-\ का उपयोग कर सकते हैं

धन्यवाद @ Hum4n01d भी बेहतर है, उस के बारे में पता नहीं था।

@ Hum4n01d मेरे मामले में, मैं टर्मिनल को Ctrl+] साथ विभाजित कर सकता हूं, या टर्मिनल विंडो के शीर्ष दाएं कोने में टर्मिनल को विभाजित करने के लिए आइकन पर क्लिक करके Kill Terminal विकल्प के आगे।

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

केवल उस मामले में जिसमें मुझे कई टर्मिनलों की आवश्यकता होती है, यह एक समाधान नहीं हो सकता है, हालांकि टैब भी नहीं हो सकते हैं (प्रति से), इसके बजाय इसे टैब + फ्लोटिंग विंडो (https://github.com/Microsoft/vscode) की तरह कुछ की आवश्यकता होगी / मुद्दों / 10121)।

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

टर्मिनल क्षेत्र में टैब्स शांत होंगे, लेकिन ऐसा करने में निवेश क्यों करें जब टर्मिनल उदाहरणों को लपेटने के लिए कोड टैब को अनुमति देने में समय व्यतीत किया जा सकता है?

नमस्ते। मैं एक मुद्दे के बारे में खोज कर रहा हूं जो मैं कर रहा हूं और मैं यहां समाप्त हुआ।

केवल एक चीज जो मैं करना चाहता हूं वह यह है कि एक नियमित संपादक टैब के रूप में एक टर्मिनल का उपयोग करें

मेरा 15 "लैपटॉप का डिस्प्ले न सिर्फ इतना बड़ा है कि वह एक छोटे से टर्मिनल के साथ गड़बड़ करने के लिए बिल्ड आउटपुट सेक्शन पैनल में उलझ गया है। यह बिल्ड के लिए ठीक काम करता है, लेकिन यह टर्मिनल उपयोग के लिए अनुपयुक्त हो सकता है।

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

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

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

@Zyrsha - उस स्थिति में, आप वीएस कोड का उपयोग क्यों कर रहे हैं? ऐसा लगता है कि आप अपने ऑपरेटिंग सिस्टम के साथ कई टैब के साथ आने वाले वास्तविक टर्मिनल का उपयोग करके सीधे अधिक मूल्य प्राप्त करेंगे। ईमानदार सवाल / बहुत भ्रमित पाठक।

BTW vscode पहला और एकमात्र IDE है जहां मैं इसमें टर्मिनल का उपयोग करता हूं। मेरे 13 "लैपटॉप पर यह मेरे लिए ठीक काम करता है। अन्य IDEs जैसे कि ग्रहण या वेबस्टॉर्म के लिए मैं बहुत ही तेज़ WM को फास्ट स्विच और विंडो ऑर्डरिंग के लिए उपयोग करके बहुत खुश हूं।

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

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

@ शेन-स्मिथ

वह वास्तविक टर्मिनल जो आपके ऑपरेटिंग सिस्टम के साथ कई टैब के साथ आता है।

वैसे विंडोज के साथ आने वाले कंसोल एप्लिकेशन में AFAIK टैब सपोर्ट नहीं है। तो वह बाहर है। और लिनक्स एक सेस (एक डिस्ट्रो हो सकता है) प्रति टर्मिनल एमुलेटर के साथ "नहीं आता है", आपको अपनी पसंद का एक चुनना होगा। इस मामले में ऐसा लगता है कि एक @Zyrsha पसंद वीएस कोड है, अगर इसे थोड़ा सुधार किया जा सकता है।

@sagebind

इस मामले में ऐसा लगता है कि एक @Zyrsha पसंद वीएस कोड है, अगर इसे थोड़ा सुधार किया जा सकता है।

ओह, मैं सहमत हूं - वीएस कोड में टर्मिनल बहुत बढ़िया है। और मैं इस मुद्दे पर टिप्पणी कर रहा हूं क्योंकि मैं मानता हूं कि इसमें सुधार के लिए कुछ जगह है।

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

नमस्ते।

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

नहीं, वे केवल संपादक टैब की तरह टर्मिनल टैब रखना चाहते हैं, वास्तव में हमारे पास Cloud9, Atom और कुछ अन्य संपादकों (यहां तक ​​कि विम और Emacs) पर भी है। मैक या लिनक्स का उपयोग करने वाले लोगों के लिए, खिड़की के ऊपर संपादक और नीचे कुछ टर्मिनल टैब होना स्वाभाविक है।

यहां तक ​​कि थिया-आईडीई में कई टर्मिनल टैब हो सकते हैं और यह VSCode के कुछ हिस्सों पर आधारित है।

इस स्क्रीनशॉट पर एक नज़र डालें और आप समझ जाएंगे:

https://discourse-cdn-sjc1.com/business5/uploads/trydiscourse4/optimized/2X/a/a6c21ba006e249a65bb0c4c2ecf94296d6daad20_1_666x500.png

https://lh3.googleusercontent.com/eI50dceQrsPJDhqQmM_QMjd4rkORHRRd_Y3rbnD1M6KYbKulXI72PFC-A0y-SDraVJAXhGTFcg=w640-h400-e365

ठीक है, चलो एक पल के लिए क्यों अनदेखा करते हैं और इस पर ध्यान केंद्रित करते हैं:

इसे कैसे लागू किया जाएगा? क्या कोई वास्तुशिल्प कारण है कि टर्मिनल अपने वर्तमान स्थान पर क्यों हैं?

क्या यह एक कुशल तरीके से संभव होगा कि एक प्लगइन टैब में टर्मिनल प्रदान करे?

      Ok, let's ignore the why for a moment and focus on the how:

इसे कैसे लागू किया जाएगा? क्या कोई वास्तुशिल्प कारण है कि टर्मिनल अपने वर्तमान स्थान पर क्यों हैं?
क्या यह एक कुशल तरीके से संभव होगा कि एक प्लगइन टैब में टर्मिनल प्रदान करे?

वास्तु पक्ष पर:

• VSCode में एक एकल कंसोल (PowerShell एकीकृत कंसोल) से जुड़े कई स्क्रिप्टिंग टैब हैं जो एक मशीन पर कई स्क्रिप्ट का परीक्षण करने के लिए बहुत अच्छा है। हालाँकि, जब आप अधिक टर्मिनलों को जोड़ते हैं, तब भी सभी स्क्रिप्टिंग टैब एक ही PowerShell एकीकृत कंसोल से जुड़े रहते हैं।
  शुरुआत में, VSCode को विकासकों द्वारा विकासकर्ताओं द्वारा लिखा गया है।

• ISE इसके विपरीत तरीके से बनाया गया है: आप कई कंसोल खोल सकते हैं और प्रत्येक कंसोल पर आप कई स्क्रिप्टिंग टैब लिंक कर सकते हैं (यह एक साथ कई कंप्यूटरों पर एक साथ काम करने के लिए बहुत अच्छा है)।
  हम विभिन्न कंप्यूटरों पर एक साथ कई स्क्रिप्ट लिखते और चलाते हैं ।
  शुरुआत में, ISE को SysAdmins के लिए डिज़ाइन किया गया है।

Fortunatelly, ISE तरीका (कंसोल टैब से जुड़ा स्क्रिप्टिंग टैब) डेवलपरों के लिए भी काम करता है।
लेकिन वर्तमान VSCode तरीका ("एक एकल" स्क्रिप्टिंग टैब से जुड़ा कंसोल टैब) SysAdmins के लिए फिट नहीं है।
यदि आप (स्क्रिप्ट से जुड़े कंसोल की ओर कंसोल से जुड़ी लिपियों से) कम-से-कम नहीं करना चाहते हैं, तो कम से कम हमें यह चुनने में सक्षम होना चाहिए कि हम प्रत्येक स्क्रिप्टिंग टैब को किस कंसोल टैब से जोड़ना चाहते हैं ...

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

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

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

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

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

इसे कैसे लागू किया जाएगा?

लिनक्स के लिए, हम इसे अधिक सामान्य दृष्टिकोण के विशेष मामले के रूप में लागू कर सकते हैं: उपयोगकर्ता परिभाषित कमांड चलाएं और उन्हें नए टैब के एक्स विंडो पहचानकर्ता के साथ प्रदान करें। हम तब टर्मिनल के लिए xterm … -into $VSCODE_TAB … चला सकते थे, लेकिन अन्य सामान को बहुत आसान तरीके से एकीकृत कर सकते थे। परियोजना निर्देशिका द्वारा VSCode उदाहरण के लिए खोज करने के लिए एक CLI कमांड (डिफाल्ट की कार्यशील निर्देशिका के लिए डिफ़ॉल्ट) जहां उस उदाहरण में एक टैब खोलें, और X जीत आईडी को stdout पर प्रिंट करें, तो भी अच्छा होगा।और VSCode के $DISPLAY अलग होने पर इसलिए कोई भी बाहरी बर्तन VSCode के GUI में शामिल हो सकता है।

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

नहीं !!! टैब बना उई बुरा लग रहा है ...।

@ donnisnoni95

नहीं !!! टैब बना उई बुरा लग रहा है ...।

मैं बहुत आशावादी हूं कि उन्हें निष्क्रिय करना और / या छिपाना आसान होगा।

बस ड्रॉप-डाउन को बटन में बदलें और उन्हें मुख्य संपादक के टैब के समान स्टाइल करें।

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

बस स्पष्ट होने के लिए, मैं या तो @andraz के या @floydnoel के समाधानों को ओपीएस अनुरोध 2016 के बाद से किसी का ध्यान नहीं गया है

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

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

इसके लिए प्रतीक्षा और पहले दिन से फ्लोटिंग विंडो मैंने VSCode का उपयोग करना शुरू कर दिया। वर्तमान में मैं ConEmu का उपयोग कर रहा हूं। यह वर्तमान में अटैच और ड्रॉपडाउन टर्मिनल के लिए आसान नहीं है।

यदि आप अभी भी ConEmu का उपयोग कर रहे हैं, तो बस एक नोट (जबकि टैब को निश्चित रूप से vscode में जोड़ा जाना चाहिए) आप Windows टर्मिनल को आज़माना चाहते हैं।

अभी भी इसके लिए इंतजार कर रहे हैं :)

मैं एक ही समय में "आउटपुट" और "डिबग कंसोल" देखना चाहूंगा।

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

हालाँकि मैं वास्तव में यह नहीं देख सकता कि कितने "आउटपुट" या "समस्या" टैब की आवश्यकता होगी क्योंकि डेटा समान होगा।

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

@Tyriar @jaxspades 1754: +1: और 187: दिल: पर्याप्त नहीं है? और 34: रॉकेट:? कितना होना चाहिए?

यह अभी भी खुला है ?!

क्या इससे क्राउडफंड को मदद मिलेगी? मैं अपना पैसा कहां रखूं?

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

संपादित करें: खोज संपादकों के मुद्दे के लिए एक कड़ी जोड़ना।

23931

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

• पैनल में खोजें
• संपादक में खोजें
• सभी पैनल और देखने के दृश्य विनिमेय हो रहे हैं

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

मैं उन्हें एक संपादक के रूप में चाहता हूं, हालांकि स्क्रीन के नीचे उस छोटी खिड़की में नहीं।

जबकि मैंने बहुत समय पहले अवधारणाओं को अलग-अलग मुद्दों में अलग करने की कोशिश की थी, अब यह मुद्दा कुछ चीजों को शामिल करता है; टर्मिनल पैनल के भीतर टैब, संपादक में टर्मिनल टैब और दोनों के बीच टर्मिनल टैब ड्रैग करने योग्य है।

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

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

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

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

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

@ fullenw1 दिलचस्प विचार मैंने अभी तक नहीं सुना था, धन्यवाद!

@ggedde हम सक्रिय रूप से चर्चा कर रहे हैं कि यह UX बैठकों में कैसे काम करेगा।

# 10121 के मुद्दे के साथ यह एक अच्छी सुविधा से अधिक नहीं होगी।

टर्मिनल पैनल को किसी प्रकार की हेडिंग की जरूरत होती है।

यह जानना असंभव है कि जब आपके पास कई सारे वॉचर्स हों तो कौन सा पैनल कौन सा रास्ता है

@IceSentry में मेरे पास एक मुद्दा था लेकिन @Tyriar ने कहा कि यह इस का डुप्लिकेट था। मैंने मान लिया कि यह संबंधित था क्योंकि @Tyriar ने इसके पक्ष में

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

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

इसमें अंतर्निहित वीएस कोड टर्मिनल के लिए एक्सटेंशन हैं, लेकिन यदि आप टर्मिनलों के लिए एक अमूर्त की तलाश कर रहे हैं, तो यह dtach या abduco में बंडल करने के लिए अच्छा

टर्मिनल टैब जो संपादक टैब के साथ यूआई में विनिमेय हैं

यह सिर्फ शानदार है।

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

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

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

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

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

हालांकि, इसे सिर्फ एक संपादक 'टैब' बनाने के लिए एक लाभ है, क्योंकि संपादक टैब में सीरियलाइज़ / डिस्क्रिअलाइज़ हैंडलर हो सकते हैं।
इस प्रकार टर्मिनल को बचत और व्यवहार को बहाल करना संभव है। (जैसे, tmux session id और रीटेट को रिस्टोर करने पर सेव करें)

POC: https://github.com/mmis1000/Vscode-terminal-tab

@ mmis1000 अब निश्चित रूप से वेबव्यू एपीआई के साथ निर्माण करना संभव है, लेकिन यह सभी एकीकरण, कमांड, लिंक हैंडलिंग, एक्सटेंशन एपीआई एक्सेस जैसी सुविधाओं और केवल एक अलग चीज की तरह काम करेगा।

सहेजें और पुनर्स्थापना सुविधा को https://github.com/microsoft/vscode/issues/20013 में ट्रैक किया गया है

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

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

POC: https://github.com/mmis1000/Vscode-terminal-tab

अरे @ mmis1000 शायद आप कुछ स्थापित निर्देश जोड़ सकते हैं, जो बहुत अच्छा होगा। वास्तव में यह करना चाहेंगे।

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

@Tyriar एक

यह एक टर्मिनल के रूप में किसी भी स्क्रीन क्षेत्र का उपयोग करने के लिए उपयोगी है और सत्र के साथ लगातार tmux द्वारा समर्थित है।

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

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

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

(यह भी क्योंकि Cloud9 ने इस साल पहले किया था, इसलिए मुझे नहीं लगता कि यह एक तकनीकी समस्या है)

टर्मिनल अनुभव vscode वास्तव में मुझे ईमानदार होने के लिए एक नवीनतम जीन उत्पाद नहीं दिखता है।

@ mmis1000 क्या आप कृपया कुछ

Https://github.com/mmis1000/Vscode-terminal-tab रेपो का अपना मुद्दा ट्रैकर है। जिस किसी को भी उस परियोजना के बारे में पूछने की आवश्यकता महसूस होती है, कृपया वहाँ पूछें।

रिमोट आइड / ब्राउजर आधारित विचारधारा पर मुझे क्या देखने की उम्मीद है, इसके बारे में प्रदर्शन के लिए।
मैं यह उम्मीद करूंगा कि मैं टैब स्थिति / टर्मिनल सत्र को बहाल कर दूं क्योंकि मैं इसे कल बंद कर दूंगा।
It will kill the all the important tasks I am running instantly because I accidentally close the the browser / the browser crashed / the computer BSOD बजाय।

यह एक और मुद्दा है https://github.com/microsoft/vscode-remote-release/issues/3096 ।

@xgdgsc की संभावना दिखती है, लेकिन ऐसा नहीं है।

मुझे उम्मीद है कि स्थानीय बनाम कोड उदाहरण पर भी टर्मिनल लगातार उपलब्ध है। (कम से कम बात करने के लिए iterm2 करता है)
ऐसे उपयोगी फ़ंक्शन को दूरस्थ कनेक्शन तक सीमित करने की आवश्यकता क्यों है?

और मैंने ssh कनेक्शन को जारी नहीं रखा या तो, मैं बस कुछ टर्मिनल मल्टीप्लेक्स को चालू करता हूं और चीजों को चलाता हूं।

@ mmis1000 फिर से https://github.com/microsoft/vscode/issues/20013 में ट्रैक किया गया है, नवीनतम के लिए वहां देखें। इस विषय पर टिप्पणी के रूप में विषय पर रखने की कोशिश करें क्योंकि लोगों के _a lot_ हैं जो आपको सूचित करते हैं।

क्या निम्न पुनरावृत्तियों में ऐसा करने का कोई मौका है?

एक सामान्य संपादक पृष्ठ टैब के रूप में खुला टर्मिनल मेरे लिए एक अद्भुत विचार है, और मुझे इसकी बहुत आवश्यकता है।