2008-10-12 5 views
12

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

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

+0

मुझे प्रश्न नहीं मिला। मैं हर रोज विम का उपयोग करता हूं, लेकिन बफर के साथ इस व्यवसाय को नहीं देखता हूं। यह प्रत्येक संपादक की तरह है, जिसे आप संपादित कर रहे हैं, तब तक फ़ाइल में लिखा नहीं जाता है जब तक आप सहेज नहीं लेते। – freespace

+0

मुझे सवाल भी नहीं मिला है। "संपादकों ने यह कब करना बंद कर दिया और क्यों?" हाल ही में, और क्योंकि यह आसान है। क्या फर्क पड़ता है? आपके पास क्या समस्या है? तुम क्या नहीं कर सकते –

+0

मैंने बस कुछ लड़के के सूचनात्मक उत्तर को पढ़ा है, और मैं हर दिन विम का उपयोग करता हूं, और मुझे अभी भी सवाल नहीं मिलता है। वे "अंतर का पर्दाफाश कैसे करते हैं"? बफर संशोधित होने पर थोड़ा [+] डालकर? –

उत्तर

30

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

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

+1

इसमें जोड़ने के लिए - Emacs और vim दोनों ऐसी चीजों को संभाल सकते हैं जो फाइल नहीं हैं, लेकिन जिनके साथ आप बातचीत कर सकते हैं। विम में, आप डिस्क पर संस्करण के लिए एक बफर को अलग कर सकते हैं - लेकिन वह diff फ़ाइल नहीं है। अधिकांश "आधुनिक" संपादक इस तरह की चीजें नहीं कर सकते हैं, या मनमानी सीमाएं बना सकते हैं। – Zathrus

+0

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

+0

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

0

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

+0

मुझे लगता है कि आप" बफर "शब्द को गलत समझ रहे हैं। – Rich

+0

मुझे यह भी लगता है कि आप अन्य संपादकों के "असीमित" पूर्ववत कर रहे हैं और विम या Emacs के "सीमित" पूर्ववत को कम करके आंका है। –

0

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

दूसरी ओर, एकाधिक फ़ाइलों को पढ़ने के द्वारा फ़ाइल छवि बनाने की क्षमता (या तो एक ही फ़ाइल की कई प्रतियां, या कई अलग-अलग फ़ाइलों की प्रतियां) भी उपयोगी होती हैं। अन्य दस्तावेजों में बेहद समान सुविधाएं हैं।

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

+0

वे बिल्कुल भेद को दूर नहीं करते हैं। वे सिर्फ हर कुंजीस्ट्रोक को तुरंत डिस्क पर फ्लश नहीं करते हैं। हालांकि, वे अलग-अलग शर्तों का उपयोग नहीं करते हैं। वे कुछ भी "बफर" नहीं कहते हैं, केवल सहेजी गई फ़ाइलें और सहेजी गई फ़ाइलें हैं। – ironfroggy

6

क्योंकि कई बफर आपको एक ही फ़ाइल के अलग-अलग दृश्य दिखा सकते हैं। मैं अन्य संपादकों के बारे में नहीं जानता लेकिन यह Emacs के बारे में सच है। और ओल्ड के साथ आपका क्या मतलब है?

1

जब अनुप्रयोग गैर-गीक्स द्वारा भारी रूप से उपयोग करना शुरू कर दिया जो खुद को अप्रासंगिक विस्तार से परेशान नहीं करना चाहते थे।

-2

क्योंकि उन संपादकों के डेवलपर्स उपयोगकर्ताओं से कार्यान्वयन विवरण छिपाने की परवाह नहीं करते थे।

क्योंकि देर बाध्यकारी संपादक में बफर और वास्तविक ठोस बात आप पर काम कर रहे के बीच, संपादन वातावरण अधिक लचीलापन और शक्ति देता है:

10

ठीक है, यहाँ मेरी अजीब दार्शनिक जवाब है।

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

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

ए) आप एक ही बफर/टैब के भीतर कई फ़ाइलों के बीच हाइपरलिंक करने में सक्षम होंगे (और वहां 'एक बैक बटन आदि होंगे)

ख) सामान्य बफ़र्स किसी भी प्रकार डेटा की पकड़ में सक्षम हो जाएगा: स्रोत-कोड, कमांड लाइन, गतिशील रूप से उत्पन्न ग्राफिक उत्पादन, परियोजना रूपरेखा आदि

दूसरे शब्दों में, विम/एमाक्स मॉडल का अधिकांश हिस्सा, ब्राउजर बना रहे खोजों के साथ अधिक ऑनलाइन होने के अलावा tweaked को छोड़कर।

संबंधित मुद्दे