micro - nano का आधुनिक विकल्प

 (micro-editor.github.io)
2 पॉइंट द्वारा GN⁺ 2023-08-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • micro टर्मिनल में इस्तेमाल होने वाला एक टेक्स्ट एडिटर है, जो nano की तरह सरल शुरुआत देते हुए भी अधिक आधुनिक और सहज उपयोग अनुभव देने का लक्ष्य रखता है
  • इसे बिना किसी dependency वाले static binary के रूप में वितरित किया जाता है, इसलिए इंस्टॉल करना आसान है, और साथ में आधिकारिक रिलीज़ डाउनलोड व विस्तृत इंस्टॉलेशन गाइड भी दी गई है
  • options और key bindings को JSON format में बदला जा सकता है, और अधिक गहरे customization के लिए Lua configuration और plugins का उपयोग किया जा सकता है
  • यह 75 से अधिक भाषाओं के लिए syntax highlighting, 7 default color themes, 16/256/truecolor themes, Sublime-स्टाइल multi-cursor, और mouse support प्रदान करता है
  • बिल्ट-इन terminal emulator की मदद से एडिटर के भीतर interactive shell चलाया जा सकता है, और split screen में code और bash को साथ देखा जा सकता है

टर्मिनल एडिटर के रूप में micro

  • micro एक terminal-based text editor है, जो आधुनिक और सहज usability पर ज़ोर देता है
  • Download se latest release prapt ki ja sakti hai, aur विस्तृत इंस्टॉलेशन गाइड bhi dekhi ja sakti hai
  • curl https://getmic.ro | bash तरीके की एक third-party pipe to shell script मौजूद है, लेकिन यह micro के नियंत्रण में नहीं है
  • इंस्टॉलेशन को आसान बनाने के लिए इसे dependency-free static binary के रूप में वितरित किया जाता है

  • सेटिंग्स और विस्तार

    • option settings और key rebinding के लिए सरल JSON format का उपयोग किया जाता है
    • यदि अधिक शक्तिशाली configuration चाहिए, तो Lua का उपयोग किया जा सकता है
    • plugins, Lua में लिखे जाते हैं, और plugin manager स्वतः download और install संभालता है

  • एडिटिंग फीचर्स

    • 75 से अधिक भाषाओं के लिए syntax highlighting सपोर्ट करता है
    • 7 default color themes प्रदान करता है
    • 16-color, 256-color, और truecolor themes का उपयोग किया जा सकता है
    • Sublime-स्टाइल multi-cursor सपोर्ट करता है
    • bindings.json में key bindings बदली जा सकती हैं

  • माउस और बिल्ट-इन टर्मिनल

    • click और drag से टेक्स्ट चुना जा सकता है
    • double click शब्द-स्तर चयन के लिए, और triple click पंक्ति-स्तर चयन के लिए उपयोग होता है
    • micro के भीतर वास्तविक interactive shell चलाया जा सकता है
    • split screen में एक तरफ code और दूसरी तरफ bash खोला जा सकता है
    • पूरी फीचर सूची GitHub feature list और online help में देखी जा सकती है

प्रोजेक्ट और कम्युनिटी

  • bugs को GitHub issue tracker में report किया जा सकता है, और questions या नए feature suggestions भी दिए जा सकते हैं
  • Pull request स्वीकार किए जाते हैं
  • एडिटर पर अनौपचारिक चर्चा Gitter chat में की जा सकती है
  • संबंधित लिंक:
  • उपयोगकर्ताओं की प्रतिक्रियाओं में एक ऐसा एडिटर शामिल है जो सरलता से काम करता है, mouse support देता है, और nano या Vim के विकल्प के रूप में इस्तेमाल किया जा सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-08-19
Hacker News की रायें

  • ऐसी क्लास में जहाँ सभी शुरुआती हों, command-line programming सीखते समय मैं छात्रों को nano सुझाता हूँ
    इन users के लिए nano का सबसे बड़ा फायदा यह है कि सभी commands स्क्रीन के नीचे दिखते हैं, और यह देखकर हैरानी हुई कि micro में यह नहीं है

    • micro और nano में फर्क यह है कि nano के keyboard shortcuts काफी अपने-आप में अलग हैं, जबकि micro आजकल ज़्यादातर graphical apps में इस्तेमाल होने वाले Ctrl+S save, Ctrl+F find, Ctrl+Z undo, Ctrl+Q quit जैसे तरीकों को follow करता है
      स्क्रीन के नीचे यह hint भी है कि Alt+G दबाने पर shortcuts देख सकते हैं, और Ctrl+G से help देख सकते हैं
    • micro का इरादा शुरुआती लोगों के लिए friendly या हर जगह मौजूद editor बनने से ज़्यादा, आधुनिक और extensible editor जैसा लगता है
      उस लिहाज़ से छात्रों को अब भी nano recommend करना सही है, और micro उन लोगों के लिए ठीक लगता है जो nano सीखने के बाद ज़्यादा features या बेहतर UI चाहते हैं
    • Alt+G दबाने पर shortcuts वाली screen आती लगती है, और Ctrl+G help खोलता है
      लगता है किसी तरह का comment mode भी है

  • Emacs को 10 साल से ज़्यादा इस्तेमाल करने के बाद अब micro को मुख्य code editor के रूप में इस्तेमाल कर रहा हूँ। Coq लिखने के लिए सिर्फ vscode अपवाद है
    मैं micro को आधुनिक समझौता किया हुआ acme मानता हूँ, और इसमें acme के core ideas को support करने वाली लगभग सारी features हैं। इस दिशा का फायदा उठाने के लिए मैंने एक plugin भी लिखा: https://github.com/xxuejie/micro-acme
    अब तक यह बिल्कुल सही fit रहा है

    • आजकल Emacs की करीब 1% features ही इस्तेमाल करता हूँ, इसलिए Emacs के alternative के तौर पर हल्का terminal editor लगातार try करता हूँ, लेकिन C/C++ जैसी आम Emacs major modes और खासकर indentation style बहुत याद आती है
      काश दूसरे editors भी tab से सही indentation enforce करने की convention अपनाएँ
    • micro के बारे में ज़्यादा नहीं जानता, इसलिए पूछ रहा हूँ: पिछले 1–2 सालों में development speed धीमी होने की कोई वजह है क्या
      https://github.com/zyedidia/micro/tags
    • इसी तरह Emacs से Acme पर आया, और terminal में mg इस्तेमाल कर रहा हूँ
      अब Micro को customize करके उसमें Acme जैसा feel बना दिया है

  • मुझे नहीं पता था कि कोई nano को अपना मुख्य code editor के रूप में इस्तेमाल करता है। जिन *nix servers पर काम करता हूँ वहाँ हमेशा इस्तेमाल करता हूँ, और शायद दसियों हज़ार बार इस्तेमाल किया होगा
    लंबे समय तक Linux/BSD engineer के तौर पर काम किया है, और कुछ जगहों पर servers पर nano install करने से मना कर दिया जाता था। vi के अलावा कुछ भी इस्तेमाल न करने देने वाले पुराने Linux admins होते हैं, यह समझ नहीं आता। यह 20MB package है और attack surface भी बहुत बड़ा नहीं है

    • पुराने लोग आखिर पुराने लोगों जैसा ही व्यवहार करते हैं
      पुरानी पीढ़ी से पूछो कि उन्होंने कौन सा system चलाया था, तो कई बार वे शेखी बघारते हुए बताते हैं कि अपने local government का पूरा IT department संभालते थे, और इलाका काफी बड़ा था इसलिए कम से कम 500 users रहे होंगे—यह हमेशा मज़ेदार लगता है
      मुझे 105% यकीन है कि वह system पूरे county में सबसे सुरक्षित रहा होगा, लेकिन साथ ही वह इस्तेमाल के लायक नहीं रहा होगा। जब वह व्यक्ति retire हो या office में कोई निराश होकर उसे हटाए, तो उम्मीद है कि उसकी जगह कोई नया engineer आए जिसे vi आता हो या नहीं, पर users की थोड़ी तो परवाह हो। बेशक हम भी engineers हैं, तो बहुत ज़्यादा परवाह तो नहीं करेंगे
    • Unix admin को vi पूरी तरह जानना चाहिए, इसकी मुख्य वजह यह है कि Unix और Linux systems में यही lowest common denominator है
      *nix technologist के तौर पर काम करने पर QNX, HP-UX, SGI Altix supercomputer, Sun Ultra 2 जैसे systems संभालने पड़ सकते हैं। Linux आसान था क्योंकि इसमें free/open-source software package management था, और nano popular होने से पहले default configuration में Emacs होना भी आम था
      कभी-कभी terminal issues की वजह से ऐसी हालत में काम करना पड़ता था जहाँ केवल एक line दिखती थी, तब vi को बिना देखे चलाना या sed/awk इस्तेमाल करना पड़ता था। इसलिए शायद सबको vi सीखाने की KISS instinct बची हुई है। मैंने भी इसी तरह सीखा
      एक editor अकेले बड़ा attack surface नहीं बनाता, लेकिन attacker plugin feature को persistence हासिल करने के साधन के रूप में abuse कर सकता है, इसे नकारता नहीं। root के रूप में चलाने पर अलग behave करेगा, लेकिन service accounts में ऐसा न भी हो सकता है
    • 20MB कहना ठीक नहीं; nano executable 277KB है, और पूरा .deb package भी 860KB है
      https://packages.ubuntu.com/jammy/nano
    • मैं मूल रूप से nano user था, लेकिन पुराने लोगों के दबाव में vim इस्तेमाल करने लगा, और अब nano को केवल तब छूता हूँ जब vimrc file ठीक करनी होती है
      उस समय गुस्सा आया था, लेकिन अब बदलाव से संतुष्ट हूँ। Vim या vi हर जगह है, यहाँ तक कि जिन switches और routers पर मैं काम करता हूँ उनमें भी। nano हर जगह नहीं है, और हर जगह आसानी से डाला भी नहीं जा सकता
      अगर पुराने या resource-constrained hardware पर नियमित रूप से SSH न करता, तो शायद इसका फायदा कम महसूस होता
    • निजी तौर पर nano से मुझे बहुत चिढ़ है, इसलिए कभी भी vi चुनूँगा
      लेकिन text editor चुनना बहुत personal बात है। किसी को किसी और पर कोई खास editor इस्तेमाल करने या न करने के लिए मजबूर करना बिल्कुल बेतुका है। बस उन्हें जो पसंद है, वह इस्तेमाल करने दें

  • JOE काफ़ी अच्छा है: https://joe-editor.sourceforge.io/
    यह WordStar और Emacs का मिश्रण है, और jstar के रूप में चलाने पर यह काफ़ी असली जैसा WordStar अनुभव देता है, साथ ही शुरुआती Borland Turbo IDE जैसा एहसास भी रहता है

    • मुझे JOE सच में बहुत पसंद था। शायद इसलिए कि इसमें WordStar की झलक थी
      मैंने अभी भी Linux में WordStar Diamond keys इस्तेमाल करने के तरीके पर लिखा है: https://benhoyt.com/writings/wordstar-diamond/
    • मेरा पहला word processor CP/M का WordStar था, और पहला programming environment Borland Turbo Pascal था
      बाद में मैंने QEdit भी इस्तेमाल किया, जिसे WordStar keys इस्तेमाल करने के लिए configure किया जा सकता था
      90 के दशक की शुरुआत में DOS से Unix पर शिफ्ट होते समय JOE मिला तो बहुत खुशी हुई। नए Linux या *BSD machine, VM पर यह सबसे पहले install करने वाला program है
      आजकल JOE में syntax highlighting और कई अच्छे features हैं, इसलिए मुझे कभी vi या emacs में माहिर होने की ज़रूरत महसूस नहीं हुई
    • 90 के दशक में code edit करने के अलावा लगभग हर चीज़ के लिए joe इस्तेमाल करने की अच्छी यादें हैं
      code editing के लिए यह खास अच्छा नहीं था, क्योंकि यह automatic line wrapping और syntax highlighting की कमी आदि की वजह से word processor model के ज़्यादा करीब था
      लेकिन text documents लिखने के लिए यह प्यारा-सा छोटा editor था
    • क्या mode-wise अंतर और key bindings manual में documented नहीं हैं?
      शायद मैं ही नहीं ढूंढ पाया, लेकिन सच में दिख नहीं रहे
    • मैं अक्सर इसे jmacs के रूप में चलाकर Emacs keyboard shortcuts का set इस्तेमाल करता हूँ

  • मुझे micro पसंद है और मैं इसे रोज़ इस्तेमाल कर रहा हूँ
    हालांकि Helix आज़माने के बाद मुझे micro का ऐसा रूप चाहिए जिसमें treesitter, LSP, contextual help built-in हों। Helix ने उस feature bundle को वाकई बहुत अच्छी तरह किया है, लेकिन “single mode + commands” और Ctrl-C/Ctrl-V की muscle memory इतनी सुविधाजनक है कि switch करना मुश्किल है

    • मैं Helix को करीब 6 महीने से रोज़ इस्तेमाल कर रहा हूँ, और इसका सभी basic features से लैस editor होना सच में बहुत अच्छा लगता है। यह एक बेहतरीन editor है

  • समझ नहीं आता कि अब भी ऐसे software क्यों हैं जो internet से download की गई चीज़ पर sudo चलाने को कहते हैं
    जब ज़्यादा आसान, सुरक्षित, कम install size वाला और सभी distributions में built-in विकल्प मौजूद है, तो ऐसी scripts इस्तेमाल करवाने की ज़रूरत क्यों है, यह सवाल है
    तुलना के लिए, Alpine का micro package install होने के बाद 4MB का है, जबकि GitHub से download किया गया statically compiled binary 11MB का है। मुझे लगता है repository package इस्तेमाल करना ज़्यादा micro जैसा है

    • क्या यह सच में sudo चलवाता है?
      https://github.com/zyedidia/micro#quick-install-script देखें तो quick install script curl https://getmic.ro | bash है, और script micro binary को current directory में रखती है
      उसके बाद चाहें तो उसे path में मौजूद directory में move कर सकते हैं, और example के तौर पर sudo mv micro /usr/bin दिया गया है। /usr/bin में move करने के लिए sudo चाहिए, बस यही बताया जा रहा है—इसमें समस्या क्या है, ऐसा लगता है
    • internet के किसी भी random source को sudo या (ba)sh में pipe करने की सलाह देना पूरी तरह गैर-ज़िम्मेदाराना है
      “सब लोग ऐसा करते हैं” वाली हास्यास्पद सफाई भी अब थका चुकी है
    • व्यक्तिगत रूप से, मैं application developer और अपने बीच कोई middleman नहीं चाहता
      मैं application सीधे developer से लेना चाहता हूँ। इससे मैं confirm कर सकता हूँ कि official supported version इस्तेमाल कर रहा हूँ और code से किसी ने छेड़छाड़ नहीं की है
      अगर application developer पर भरोसा नहीं है, तो मैं उसे install ही नहीं करता

  • मुझे लगा था कि Nano, Pico का आधुनिक विकल्प है

  • समझ नहीं आता कि ऐसे छोटे editors में इतनी दिलचस्पी क्यों है
    vi/vim इस्तेमाल करने की एकमात्र वजह यह है कि वे हर जगह मौजूद होते हैं। अगर editor install ही करना हो, तो मैं Emacs install करूंगा
    remote system हो तो tramp के जरिए SSH के पार files खोलता हूं और local Emacs की पूरी power और speed वैसी ही बनी रहती है। sudoedit, git commit, C-x C-e जैसे terminal UI editing के लिए Emacs को daemon के रूप में चला कर रखता हूं, इसलिए नया frame और terminal frame भी तुरंत खुलता है, nerd font और colors तक के साथ Emacs GUI जैसा ही होता है, और सचमुच Emacs ही होता है
    अलग-अलग कामों के लिए कई editors रखने की जरूरत नहीं है

    • मैं 20 साल से ज्यादा समय से Linux इस्तेमाल कर रहा हूं, लेकिन vi को आखिर तक ठीक से समझ नहीं पाया और वह intuitively समझ में नहीं आता
      Emacs मुझे ज्यादा आकर्षक लगा, और जब OpenWRT चलाने वाले router जैसे low-power device में ssh करता हूं, तो Emacs नहीं होता, इसलिए उपलब्ध editors में जो intuitive दिखता है, Nano इस्तेमाल करता हूं
      मुझे पता है कि Emacs और TRAMP भी इस्तेमाल किए जा सकते हैं, लेकिन हर कोई अपना workflow बना लेता है। vi को नीचा दिखाने की कोशिश नहीं है; hackers में कुछ लोगों का vi के साथ सहज न हो पाना एक जाना-पहचाना phenomenon है
    • हर किसी को विशाल editor और steep learning curve में दिलचस्पी नहीं होती
      कुछ लोग बस जल्दी से file edit करना चाहते हैं
      इसे Windows Notepad या Mac SimpleText से पहले से सीखी हुई चीजों के आधार पर इस्तेमाल किया जा सकता है, और broken machine या server machine पर सिर्फ Unix console उपलब्ध होने की स्थिति में भी यह काम करता है
    • मुझे ऐसे छोटे editors में खुद कोई खास दिलचस्पी नहीं है
      लेकिन nano जैसे छोटे editors में काफी दिलचस्पी है। वजह इस root comment में है: https://news.ycombinator.com/item?id=37173126
      यहां का पहला paragraph भी देखने लायक है: https://linuxize.com/post/how-to-use-nano-text-editor/
      आज के उन system administrators के लिए, जो vi या vim के साथ बड़े नहीं हुए और जिन्होंने emacs camp भी नहीं चुना, mass deployment images में nano शामिल रखना एक शिष्ट विकल्प है
    • जिन भी operating systems से मेरा सामना होता है, उनमें Nano होता है
      मैं remote पर अक्सर कुछ edit भी नहीं करता, और आम तौर पर वे सिर्फ simple config files होती हैं
      micro भी इस्तेमाल किया है और पसंद आया, लेकिन Pi पर वह तुरंत नहीं खुला, और command-line editor में features की सचमुच जरूरत पड़े इतना बड़ा काम मैं नहीं करता
    • micro इस्तेमाल करने की वजह यह थी कि ज्यादा मेहनत के बिना custom plugins develop कर सका, और जिन systems में ठीक-ठाक terminal editor नहीं था, वहां सिर्फ copy करके आसानी से deploy कर सका
      आम तौर पर vim पसंद करता हूं, लेकिन target system पर अच्छी config deploy करने में बहुत ज्यादा मेहनत लगती है

  • micro में मुझे जो दिक्कत आई वह formatted paste थी
    code snippet paste करने पर micro हर line पर indentation लगाने की कोशिश करता था, लेकिन पूरे context का पता न होने के कारण pasted text की indentation धीरे-धीरे अनंत गहराई तक बढ़ती चली जाती थी
    हर line पर formatting infer करने की वजह से process लगभग रुक जाने जितना धीमा हो जाता था। paste करके Matrix जैसा scene देखते रहने के बजाय आप coffee लेने चले जाते
    उम्मीद है कि यह ठीक हो गया होगा, लेकिन उस समय मैं छोड़ चुका था। अगर ठीक हो गया है तो फिर से try कर सकता हूं

    • इसे disable किया जा सकता है: Ctrl+E के बाद set autoindent off
      https://github.com/zyedidia/micro/blob/master/runtime/help/o...
      फिर भी enabled होने पर भी पूरा block paste करते समय indentation सही होनी चाहिए
      अगर settings, environment, configuration share कर दें तो मैं patch बनाने की कोशिश कर सकता हूं
    • Windows पर Wezterm के साथ इस्तेमाल करते समय एक बार ऐसा हुआ था
      यह paste करने के तरीके पर निर्भर करता है। ठीक-ठीक कैसे काम करता है, इस बारे में 100% निश्चित नहीं हूं, लेकिन लगता है micro xclip से direct paste को फिर से implement करता है, और Windows पर क्या करता है पता नहीं
      Ctrl+V से paste करने पर clipboard content block के रूप में तुरंत insert हो जाता है और original indentation copy होती है। Ctrl+Shift+V इस्तेमाल करने पर terminal में clipboard कभी-कभी ऐसे process होता है मानो characters एक-एक करके stream हो रहे हों, और अगले character को जाने बिना return character दिखते ही extra indentation कर देता है, फिर भोलेपन से कुछ और tabs जोड़ देता है

  • अन्य 14 submissions में से 2020 वाले लेख पर 103 comments थे, और 2021 वाले पर 162 comments थे
    [0]: https://news.ycombinator.com/item?id=23334190
    [1]: https://news.ycombinator.com/item?id=29128702