टेक्स्ट एडिटिंग से भी आपको नफरत है

एलेक्सिस बिंगनर का लेख, "टेक्स्ट रेंडरिंग हेट्स यू," एक महीने पहले प्रकाशित हुआ था , जो मेरे बहुत करीब है।

2017 में वापस, मैं एक ब्राउज़र में एक इंटरैक्टिव पाठ संपादक विकसित कर रहा था। मौजूदा ContentEditable पुस्तकालयों से असंतुष्ट, मैंने सोचा: “अरे, पाठ के चयन को फिर से साकार करना! क्या यह कठिन है? ” मैं जवान था। अनुभवहीन। मुझे लगा कि मैं इसे दो सप्ताह में संभाल सकता हूं। वास्तव में, इस समस्या को हल करने के प्रयास में मेरे जीवन के कई साल लग गए, जिसमें नए ओएस के लिए एक पाठ संपादक विकसित करने के लिए सुबह से शाम तक का एक साल का भुगतान काम भी शामिल है।

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



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

टंकण कठिन है।

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

ऊर्ध्वाधर कर्सर आंदोलन

मैंने पहले ही एक पिछले लेख में इसे कवर किया था , लेकिन हम जल्दी से यहां दोहरा सकते हैं।



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

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

निकटता

ठीक है, अब हम जानते हैं कि जब हम पाठ का चयन करते हैं, तो हमारे पास दो टुकड़े होते हैं: बाइट ऑफसेट लाइन के अंदर और x पिक्सेल में समन्वयित होता है, जो ऊपर उल्लेखित है। क्या समस्या का समाधान हो गया है? खैर, नहीं।

बहुत लंबी लाइन पर दो कर्सर स्थिति पर विचार करें:



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

इमोजी संशोधक

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



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

• खराब # 1 सही लग सकता है । लेकिन यह कैसे एक पाठ संपादक विरासत इमोजी प्रतिपादन के लिए समर्थन के साथ काम करता है, उदाहरण के लिए, उदात्त पाठ। यह बुरा है क्योंकि हल्की उंगली इमोजी एक पीले रंग की उंगली के रूप में एन्कोडेड है, इसके तुरंत बाद एक त्वचा टोन संशोधक है। वे एक प्रतीक में संयुक्त नहीं हैं, जैसा कि अपेक्षित था। यहां तक ​​कि अगर मैं किसी अन्य एप्लिकेशन से हल्की उंगली की नकल करता हूं, तो यह अभी भी यहां पर सही ढंग से प्रदर्शित नहीं होगा।
  
• पता बार में Chrome # 2 बुरा है । वेब पेजों पर नहीं, केवल एड्रेस बार में। यह एक रेंडरिंग समस्या नहीं है, क्योंकि स्किन टोन के साथ कॉपी-पेस्ट इमोजी काम करता है। इसके बजाय, Chrome ने पत्र को हटा दिया है, और पत्र के बाद संशोधक को देखा है, इसे हटा भी देता है। उफ़।
  
• बुरा # 3 इमोजी के विनिर्देश से मेल खाता है कि इमोजी का विलय कैसे किया जाना चाहिए। लेकिन यह उपयोगकर्ताओं के लिए काफी समझ से बाहर है, और वैसे, आपको कर्सर को स्थानांतरित करने की आवश्यकता है ताकि यह इमोजी के अंदर आधा अटक न जाए।

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



अब संशोधक न्यूलाइन वर्ण को बदलता है। TextEdit आपको दूसरी पंक्ति की शुरुआत में कर्सर रखने की अनुमति नहीं देगा! मैं व्यक्तिगत रूप से इस निर्णय को "बुरा भी मानता हूं।"

आपने यह भी देखा होगा कि अंगूठा ऊपर नीचे हो गया है। मैंने पूरी स्थिति के बारे में मेरी भावनाओं को दर्शाने के लिए ऐसा किया।

वैसे, TextEdit विशेष रूप से पहली पंक्ति में कर्सर को बहुत छोटी गाड़ी बनाता है। उदाहरण के लिए, अनुमान लगाएं कि अगर मैं यहां 4 दबाऊं तो क्या होगा?



उह हुह। आप यह भी सोच सकते हैं कि संख्याओं के बीच रिक्त स्थान हैं। वे वहां नहीं हैं।

अप्रत्यक्ष पाठ

एलेक्सिस मिश्रित बोली पाठ में चयनों को विभाजित करता है, जैसा कि TextEdit से इस उदाहरण में है:



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

इसलिए, यह थोड़ा आश्चर्यजनक है कि हम यह चयन प्राप्त कर सकते हैं:



हां, यह दृष्टिगत रूप से निरंतर है, लेकिन बाइट-अलग है। हाँ, यह बुरा है। कुछ संपादक ऐसा करते हैं यदि आप माउस के बजाय तीर कुंजियों के साथ पाठ का चयन करते हैं। पाठ के अंदर बाईं / दाईं कुंजियों को स्वैप करने का विकल्प दाईं ओर से बाईं ओर है, जो खराब भी है। यहां अच्छे विकल्प नहीं हैं।

एक बोनस के रूप में, यह समझने की कोशिश करें कि यहाँ क्या हो रहा है:



भगवान ... मैं इस पर टिप्पणी नहीं करना चाहता।

इनपुट विधियों के बारे में बात

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



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


(स्क्रीनशॉट के लिए Shae को धन्यवाद!)

क्या ये सभी चयन और रचना क्षेत्र द्विदिश पाठ के साथ परस्पर क्रिया करते हैं? आइए इसके बारे में न सोचें।

इनपुट विधियों को टर्मिनल के अंदर भी , हर जगह काम करना चाहिए:



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

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

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

सब कुछ इतना जटिल क्यों है ??

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

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

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