जैसा कि ZyX ने #vim पर कहा, यह प्रश्न "वीम विशेषज्ञों को गर्म पर स्वादिष्ट क्यों पसंद है?" ।
"विशेषज्ञ विशेषज्ञ" टैब पर बफ़र्स पसंद नहीं करते हैं: वे बफ़र्स का उपयोग फ़ाइल प्रॉक्सी के रूप में करते हैं जो वे हैं और टैब पृष्ठ वे कार्यक्षेत्र के रूप में हैं। बफ़र्स और टैब पृष्ठों के अलग-अलग उद्देश्य होते हैं इसलिए एक से दूसरे को प्राथमिकता देना कोई मायने नहीं रखता है।
बफ़र्स और टैब के साथ समस्या एक भ्रम है , जो स्वतंत्र तथ्यों के संयोजन के कारण है।
अधिकांश "आधुनिक" पाठ संपादक और IDE लोड की गई फ़ाइलों का प्रतिनिधित्व करने के लिए एक टैब रूपक का उपयोग करते हैं। वह रूपक सूचना प्रणाली के रूप में कार्य करता है - यह उपयोगकर्ता को दिखाता है कि कौन सी फाइलें खोली गई हैं और उनकी स्थिति - और एक संवादात्मक उपकरण के रूप में - यह उपयोगकर्ता को उन खोली गई फ़ाइलों को फिर से व्यवस्थित करने (फिर से चुनने, बंद करने) की अनुमति देता है। उनकी कई सीमाओं के बावजूद, टैब हर जगह हैं और लोग उनके लिए उपयोग किए जाते हैं और हर जगह उनकी अपेक्षा करते हैं।
विम ने अपने उपयोगकर्ताओं के लिए तदर्थ "वर्कस्पेस" बनाने के लिए 7.0 के रूप में टैब पृष्ठ पेश किए । उनकी विशेषताओं, उनके विशिष्ट विकल्पों, उनके विशिष्ट आदेशों या उनके :helpअनुभागों में कुछ भी नहीं पता चलता है कि टैब पृष्ठ फ़ाइल प्रॉक्सी के रूप में उपयोग किए जा सकते हैं या उनका उपयोग किया जाना चाहिए।
नाम और "टैब पेज" की उपस्थिति के अलावा, कुछ भी नहीं , जो बहुत भ्रम की ओर जाता है।
बिना :set hidden, जो कि डिफ़ॉल्ट रूप से अक्षम है और खोजने में बहुत आसान नहीं है, विम वर्तमान को लिखे बिना या उसके परिवर्तनों को छोड़ते हुए दूसरे बफर में स्विच करना असंभव बनाता है। नए उपयोगकर्ता, उस विकल्प से अनजान हैं, उनके पास भारी खिड़कियों के उपयोग या निकटतम "टैब जैसी" सुविधा को चालू करने के अलावा कोई विकल्प नहीं है जो वे पा सकते हैं: टैब पृष्ठ।
"टैब पृष्ठ" उस विशेषता के लिए एक दुर्भाग्यपूर्ण नाम विकल्प है, विशेष रूप से इस विचार पर हावी है कि प्रलेखन पढ़ना समय की बर्बादी है।
विम में, टैब पृष्ठ खिड़कियों के शीर्ष पर निर्मित एक अमूर्तता है, जो स्वयं बफर के शीर्ष पर निर्मित एक अमूर्त है। प्रत्येक नया स्तर उपयोगी सुविधाएँ जोड़ता है लेकिन आपके वर्कफ़्लो को प्रतिबंधित करता है।
"बफर रास्ता"
बफर-आधारित वर्कफ़्लो के साथ, आप जिन फ़ाइलों के साथ काम कर रहे हैं, वे एकल आयाम के साथ वितरित किए जाते हैं। आप अपने बफ़र्स के माध्यम से साइकिल चला सकते हैं, आप एक विशिष्ट बफर को उसके नाम का हिस्सा (पूरा होने के साथ) या उसकी संख्या टाइप करके एक्सेस कर सकते हैं, आप बफ़र्स के बीच वैकल्पिक कर सकते हैं, आप उन्हें आसानी से लक्ष्य कर सकते हैं। मूल रूप से कोई घर्षण नहीं है।
आठ बफ़र्स खुले, केवल एक दिखाई:
संख्या द्वारा स्विच करना:
नाम से स्विच करना:
बफ़र्स विम की फ़ाइल-प्रॉक्सी हैं। यदि आप फ़ाइलों के संदर्भ में सोचते हैं, तो आप बफ़र्स के संदर्भ में सोचते हैं।
"खिड़की रास्ता"
एक खिड़की-आधारित वर्कफ़्लो के साथ, आपकी "फाइलें" दोनों को एक ही "वर्चुअल" आयाम के साथ वितरित किया जाता है, क्योंकि यदि आप केवल बफ़र्स और दो अन्य "भौतिक" आयामों का उपयोग करते हैं। लेकिन कार्टेशियन रिक्त स्थान, जिसमें वे आयाम पाए जाते हैं, लगभग पूरी तरह से अलग हो जाते हैं: दूसरे बफ़र में जाने का मतलब अभी भी "दूसरी फ़ाइल में जाना" है, लेकिन दूसरी विंडो में जाना नहीं है। इच्छित फ़ाइल से संबंधित बफर उस विंडो में प्रदर्शित हो सकता है, लेकिन यह दूसरे में भी प्रदर्शित हो सकता है, शायद किसी अन्य टैब पृष्ठ में, या बिल्कुल भी नहीं।
खिड़कियों के साथ, खुली फ़ाइलों के बीच नेविगेट करना या तो बहुत जटिल या बहुत सरल हो जाता है, यहां तक कि 'switchbuf'और :sb। ज्यादातर क्योंकि आप अनिवार्य रूप से एक ही चीज के लिए दो सेट का उपयोग करने के लिए मजबूर हैं: एक बफर तक पहुंचना।
विंडोज का उनका उपयोग है, जैसा कि नीचे वर्णित है, लेकिन उनके पास ऐसा नहीं है जो किसी के वर्कफ़्लो में बफ़र्स को बदलने के लिए लेता है।
यहाँ मैं एक विम कलर्सकेम पर काम कर रहा हूँ। दो विंडो एक ही बफर के अलग-अलग दृश्य हैं: शीर्ष एक संदर्भ के रूप में कार्य करता है, जो कलरकेम में उपयोग किए गए रंग कोड की एक तालिका के साथ है, और नीचे एक वह जगह है जहां मैं काम करता हूं:
Windows को फ़ाइल-प्रॉक्सी के रूप में डिज़ाइन नहीं किया गया है और इसे लोगों में नहीं बनाया जा सकता है: वे "कंटेनर" या "व्यूपोर्ट" हैं जो आपको एक बफर में दृश्य पेश करने के लिए डिज़ाइन किए गए हैं। न आधिक न कम।
"टैब रास्ता"
टैब-आधारित वर्कफ़्लो के साथ, आप अनिवार्य रूप से विम के टैब पृष्ठों की प्रकृति को पूरी तरह से अनदेखा करते हुए आपके पिछले संपादक से उपयोग किए जाने वाले उपयोगकर्ता अनुभव की नकल करने की कोशिश करते हैं। अगर हम एक पल के इस रणनीति आम तौर पर यह है कि के लिए भूल जाते हैं बहुत अनुत्पादक है, यह भी खोने के बिना है कि "एक फ़ाइल = एक टैब" प्रतिमान का पालन करने के लिए बाध्य करने के विम असंभव है, सिर्फ खिड़कियों के साथ की तरह, एक बहुत लचीलेपन की।
अभी भी ऊपर की तरह एक ही फाइल के साथ काम करते हुए, टैबलाइन को वस्तुतः कोई लाभ नहीं हुआ। मेरी सभी फाइलें और मेरे सभी टैब कहलाते हैं javascript*.vimइसलिए मैं ऐसा नहीं कर 3gtसकता और मुझे विश्वास है कि मैं सही जगह पर समाप्त हो जाऊंगा और नाम से विशिष्ट टैब तक पहुंचना असंभव है। इस तथ्य को जोड़ें कि इसका लेबल बहुत अच्छी तरह से बहुत ही अनपेक्षित लेकिन पूरी तरह से तार्किक हो सकता है [Quickfix List]... चूंकि टैब पेज पर फ़ाइल / बफर को टाई करने का कोई व्यावहारिक तरीका नहीं है, इसलिए आप मूल रूप से टैब पृष्ठों के बीच नेविगेट करने के लिए केवल एक व्यावहारिक तरीके से बचे हैं। / बफ़र्स / फ़ाइलें: साइकिल चलाना।
और हाँ, मेरी सारणी केवल 8 टैब से भरी हुई है, कल्पना कीजिए कि मेरे पास 20 थे!
आठ टैब पृष्ठ (गलत) में आठ बफ़र्स खुले
दो विशिष्ट कार्यों के लिए दो टैब (दाएं)
टैब पृष्ठ "कंटेनर" या "व्यूपोर्ट" होते हैं जिन्हें एक या अधिक खिड़कियों के लिए डिज़ाइन किया गया होता है, खुद बफ़र्स को शामिल करने के लिए डिज़ाइन किए गए "कंटेनर" भी होते हैं।
निष्कर्ष के तौर पर
"विम एक्सपर्ट्स" (मान लें कि मैं बोल सकता हूं जैसे कि मैं एक था) टैब पर बफ़र्स पसंद नहीं करते हैं: वे सिर्फ विम का उपयोग करते हैं क्योंकि यह डिज़ाइन किया गया था और उस डिज़ाइन के साथ पूरी तरह से आरामदायक हैं:
"विम विशेषज्ञों" में 2, 30 या 97 बफ़र भरे हुए हैं और बहुत खुश हैं कि उन्हें स्थानिक वितरण से निपटने की ज़रूरत नहीं है;
जब उन्हें एक संदर्भ के रूप में दूसरे को रखते हुए वर्तमान बफर के एक हिस्से में दो फ़ाइलों की तुलना करने या काम करने की आवश्यकता होती है, तो "विम विशेषज्ञ" विंडोज़ का उपयोग करते हैं, क्योंकि उनका उपयोग कैसे किया जाता है;
जब उन्हें अपने वर्तमान दृश्य के साथ खिलवाड़ किए बिना परियोजना के एक अलग हिस्से पर कुछ समय के लिए काम करने की आवश्यकता होती है, तो "विम एक्सपर्ट्स" एक नया टैब पृष्ठ लोड करते हैं।