कोड-हाइलाइट किया गया संपादक। समस्याएं और समाधान

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

एक साल से भी अधिक समय पहले हब्रे पर क्यूसिंटिला घटक ( 1 , 2 , 3 ) के नाम स्थान से लेखों की एक श्रृंखला थी, और इसकी आलोचना के साथ मेरा लेख। नतीजा कुछ समझ में आया। यह स्पष्ट है कि सब कुछ खराब है, लेकिन यह स्पष्ट नहीं है कि क्या करना है।

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

तुरंत एक आरक्षण करें कि यह एक मौलिक वैज्ञानिक लेख नहीं है। यह मेरा अनुभव है। वैकल्पिक दृष्टिकोण और समाधान के बारे में टिप्पणियों में पढ़ना बहुत दिलचस्प होगा।

प्रेरणा

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

कोड पार्सिंग

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

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

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

अनुकूलन

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

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

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

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

नतीजतन, मैं पायथन का उपयोग करने की उपयुक्तता में निराश नहीं था। सी में एक पार्सर मेरे घटक के कोड आधार का लगभग 1/3 है। मुझे लगता है कि श्रम के संदर्भ में, इस तरह के एक संकर विकल्प सी ++ में एक समाधान की तुलना में आसान निकला।

अतुल्यकालिक बैकलाइट

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

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


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

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

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

वृद्धिशील बैकलाइट

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

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

प्रदर्शन की तुलना

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

मैंने कई संपादकों में एक बड़ी C ++ फ़ाइल (364121 लाइनें) खोली, जो मेरे लिए दिलचस्प हैं, और इस तालिका में मेरे अवलोकन एकत्र किए हैं।

घटक या संपादक	संपूर्ण फ़ाइल को हाइलाइट करने का समय	जीयूआई को ब्लॉक करता है	बैकलाइट समस्याएं
Qutepart	44 सेकंड	कभी नहीं	फ़ाइल 3 सेकंड खोलें
katepart	6 मिनट के बाद मार दिया गया था	जब तक यह प्रदर्शित होने की आवश्यकता है, तब तक हाइलाइट करता है
QScintilla	3 सेकंड	कभी नहीं	संपादन करते समय धीमा हो जाता है
झलक	3 सेकंड	कभी नहीं	संपादन करते समय धीमा हो जाता है
उदात्त पाठ	23 सेकंड	संपादन करते समय, जब तक कि यह सभी परिवर्तित बैकलाइट को अपडेट न कर दे
एडिट	8 सेकंड	कभी नहीं	संपादन करते समय धीमा हो जाता है
क्यूटी निर्माता	20 सेकंड	संपादन करते समय, तब तक लटका रहता है जब तक कि यह सभी परिवर्तित बैकलाइट को अपडेट न कर दे
निंजा आईडीई	14 सेकंड	खोलने पर	केवल पहली 51 लाइनों को हाइलाइट किया गया। संपादन करते समय बहुत धीमी गति से।
शक्ति	तुरंत	कभी नहीं	बीच से एक फ़ाइल को पार्स करता है, कुछ मामलों में गलत परिणाम दिखाता है।
Emacs	तुरंत	कभी नहीं	बीच से एक फ़ाइल को पार्स करता है, कुछ मामलों में गलत परिणाम दिखाता है। रिवाइंडिंग के दौरान लगभग एक मिनट तक लटका रहता है।

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

और क्या हुआ

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

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

मुझे हैबर समुदाय से समीक्षा करने में खुशी होगी!