वीआईएम, विंडोज, क्विकफिक्स - कंपाइलर एन्कोडिंग के खिलाफ लड़ाई

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

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

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



और कमांड: सामना पढ़ने में मदद नहीं करता है, हालांकि यह कोड की गलत लाइनों पर कूदने की अनुमति देता है:



नोट: उदाहरण के लिए, विकल्प मेकफ = error.err का उपयोग किया गया था (मेक कमांड के प्रदर्शित लाइन को छोटा करने के लिए), हालांकि आमतौर पर यह डिफ़ॉल्ट रूप से खाली होता है और मेक त्रुटि फाइल TEMP में बनाई जाती है।

यह प्रतीत होता है - क्या बकवास है! हम एन्कोडिंग विकल्प को ठीक करेंगे ... लेकिन नहीं - यह एक वैश्विक संक्रमण है। इसलिए, एन्कोडिंग हर जगह बदल जाएगी, सभी खुले बफ़र्स में, स्रोत विंडो सहित। रूसी खान में टिप्पणियाँ। VIM मैसेज भी खुद।



आप कोशिश कर सकते हैं: मैन्युअल रूप से एन्कोडिंग = cp866 सेट करें, आप इसे $ VIM / vimfile / ftplugin / qf.vim में चिपका सकते हैं ताकि यह कमांड द्वारा काम करे: सामना करें। आप भी कोशिश कर सकते हैं: सेटलोकल - मदद नहीं करेगा।

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

1. जब 'ऑटोव्राइट' विकल्प सक्षम होता है, तो सभी संशोधित बफ़र लिखे जाते हैं।
2. त्रुटि फ़ाइल नाम की गणना 'मेकफ' विकल्प के मूल्य के अनुसार की जाती है। यदि 'मेकफ' विकल्प के मूल्य में "##" शामिल नहीं है, तो उसी नाम से एक मौजूदा फ़ाइल हटा दी जाएगी।
3. कार्यक्रम 'मेकपर्ग' विकल्प के मान में निर्दिष्ट नाम से शुरू होता है (डिफ़ॉल्ट: "मेक") एक वैकल्पिक सेट के साथ [तर्कों], जिसके आउटपुट को त्रुटि फ़ाइल (यूनिक्स में, आउटपुट को स्क्रीन पर भी प्रदर्शित किया जाता है) पर रीडायरेक्ट किया जाता है।
4. एक त्रुटि फ़ाइल को 'errorformat' विकल्प के मान का उपयोग करके पढ़ा जा रहा है।
5. यदि संशोधक [!] सेट नहीं है, तो सिस्टम सूची से पहली त्रुटि पर जाता है।
6. त्रुटि फ़ाइल हटा दी गई है।
7. अब आप त्रुटि सूची को कमांड के साथ नेविगेट कर सकते हैं जैसे: स्नेक्स और: स्पष्ट।

यह पता चला है, जब आप कमांड के साथ qf बफर खोलते हैं: सामना करते हैं, त्रुटि फ़ाइल अब मौजूद नहीं है। आप इसे अस्पष्ट तरीके से लौटाने का प्रयास कर सकते हैं - $ VIM / vimfile / ftplugin / qf.vim में

setlocal encoding=cp866 setlocal fileencoding=cp1251 w! ./error.err setlocal encoding=cp1251 

यही है, जब आप कमांड के साथ qf बफर खोलते हैं: एन्कोडिंग को बदलें, फाइल के लिए एन्कोडिंग डालें, एक नई एरर फाइल लिखें, और एन्कोडिंग को वापस लौटा दें। वैसे, यहां स्थानीय को छोड़ा जा सकता है - यह अभी भी बेकार है। अब आप मैन्युअल रूप से नई त्रुटि फ़ाइल स्थापित कर सकते हैं: cf ./error.err।



बदसूरत, असहज और बहुत सारे अतिरिक्त हाथ आंदोलनों। यह पता चला है, प्रत्येक संकलन के बाद, आपको पहले: सामना करना होगा, फिर: ccl, फिर: cf। /Error.err और फिर से: सामना करना होगा। यदि आप यह सब qf.vim में सम्मिलित करने का प्रयास करते हैं, तो आपको एक उन्मत्त पुनरावृत्ति मिलेगी जो VIM अपने आप ही गला देगी। और: सामना किसी भी तरह से अजीब व्यवहार करता है: अतिरिक्त छड़ें लाइनों की शुरुआत में जोड़ दी जाती हैं, यहां तक ​​कि कारणों का पता लगाने के लिए अनिच्छा भी।



ठीक है, तो आइए उस क्षण को पकड़ने की कोशिश करें जो त्रुटि फ़ाइल के पढ़ने के पास नहीं है, लेकिन संकलक आउटपुट के करीब है। आइए फिर से मदद देखें:

": मेक" कमांड 'मेकप्रैग' विकल्प के मूल्य में निर्दिष्ट प्रोग्राम को निष्पादित करता है। यह 'शेल' विकल्प के मान में निर्दिष्ट शेल से कमांड को कॉल करके होता है। दूसरे शब्दों में, लगभग ऐसा ही होता है जब एक कमांड दर्ज करते हैं

":!{_makeprg} [] {_shellpipe} {_}".

यहाँ {makeprg_value} 'makeprg' विकल्प का स्ट्रिंग मान है। आप किसी भी प्रोग्राम का उपयोग कर सकते हैं, न कि केवल बनाने के लिए।

विस्मयादिबोधक बिंदु ":! {कमांड}" को शेल में निष्पादित किए जाने के लिए निर्दिष्ट {कमांड} की आवश्यकता होती है। इसका अर्थ है कि निष्पादन के दौरान फ़ाइल के साथ होने वाली घटना को पकड़ना: मेक फेल हो जाएगा। ऑटो टीम का उपयोग करने की उम्मीद टूट गई। लेकिन जल्दी छोड़ देना। आइए नजर डालें

 'शेलपाइप' 'स्प' स्ट्रिंग (डिफ़ॉल्ट: ">", "| टी", "| और टी" या
			         "2> और 1 | टी")
			 वैश्विक विकल्प
	 विकल्प का उपयोग शेल को निर्दिष्ट करने वाली रेखा को निर्दिष्ट करने के लिए किया जाता है
	 ": make" कमांड के आउटपुट को एरर फाइल में डालें। 

यह पता चला है कि मेरा वीआईएम शेलपाइप =>% s 2> $ 1 में डिफॉल्ट करता है। ऐसा लगता है कि एक बाहरी कमांड लाइन उपयोगिता लेने का अवसर है और किसी तरह इसे इस गोले के बीच में डाल दिया गया है।

Iconv ले लो, जो कामेच्छा पृष्ठ पर GnuWin32 परियोजना में है। यह फ़ाइल से या कंसोल स्ट्रीम से डेटा प्राप्त कर सकता है। मैंने इसे C: \ bin \ में रखा, जहाँ मेक, ctags, 7z, सहायक बैच फ़ाइलों के एक जोड़े और dll के एक जोड़े पहले से ही झूठ बोलते हैं। निर्भरता के बारे में मत भूलो (निर्भरता, अर्थात् libintl3.dll, उपयोगिता पृष्ठ पर है)।

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

 :set shellpipe=\|c:\\bin\\iconv\\iconv.exe\ -c\ -f\ CP866\ -t\ CP1251>%s\ 2>&1 

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

सामान्य तौर पर, यह काम किया। मैंने निर्दिष्ट लाइन को (शुरुआत में एक कॉलन के बिना) $ VIM / vimfile / ftplugin / a6403.vim में लिखा। अब "शेल पाइप" को केवल इस विशेष चालाक फ़ाइल प्रकार को खोलने पर ट्रांसकोडिंग में बदल दिया जाता है। यहाँ परिणाम है:



स्रोत में रूसी टिप्पणियां पढ़ने योग्य हैं, त्रुटि संदेश भी त्रुटियों से कूदते हैं। समाधान आदर्श नहीं है:

• मुझे अंतर्निहित रूपांतरण टूल के साथ एक तृतीय-पक्ष उपयोगिता का उपयोग करना था। बहाना: इस मामले में विशेष रूप से डरावना नहीं है - तीसरे पक्ष के संकलक का उपयोग करने के लिए, और तीसरे पक्ष के ctags, और वैसे भी एक तृतीय-पक्ष बनाते हैं। वैसे, मेरी c: \ bin \ ... में और भी फाइलें हैं
• शेलपाइप विकल्प वैश्विक है, यह सभी बफ़र्स पर लागू किया जाएगा। बहाना: यदि आप इस विशिष्ट कोडांतरक की फ़ाइलों को नहीं खोलते हैं - कोई भी महसूस नहीं करेगा। यदि आप खोलते हैं और एक साथ दूसरे अनुवादक के साथ एक साथ खुले बफ़र्स में काम करते हैं, तो अंग्रेजी बोलने वाले संकलन बैंगनी (चेक किए गए), रूसी बोलने वाले संकलनकर्ता (cp866 पर) केवल फायदेमंद होंगे।

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

 setlocal makeprg=c:\bin\make.exe\ $*\ \\\|c:\\bin\\iconv\\iconv.exe\ -c\ -f\ CP866\ -t\ CP1251 

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