Microsoft Edit

 (github.com/microsoft)
3 पॉइंट द्वारा GN⁺ 2025-06-26 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Microsoft Edit क्लासिक MS-DOS Editor को श्रद्धांजलि देने वाला एक सरल text editor है
  • यह VS Code जैसा आधुनिक interface और input controls प्रदान करता है
  • इसका विकास लक्ष्य ऐसा editing environment देना है जिसे terminal से कम परिचित उपयोगकर्ता भी आसानी से अपना सकें
  • Search and Replace फीचर के लिए इसमें ICU library पर वैकल्पिक dependency है
  • इसमें package managers के लिए स्पष्ट executable naming और environment variable options संबंधी मार्गदर्शन शामिल है

Open source project overview

  • Microsoft Edit सरल कामों के लिए क्लासिक editor style वाला text editor है
  • इसकी खासियत MS-DOS Editor की आधुनिक पुनर्व्याख्या है, जिसमें VS Code शैली का परिचित UI और input तरीका अपनाया गया है
  • इसे खास तौर पर ऐसी सादगी पर ध्यान देकर डिज़ाइन किया गया है जिससे terminal का कम अनुभव रखने वाले users भी इसे आसानी से इस्तेमाल कर सकें

विशेषताएँ और फीचर्स

  • यह न्यूनतम जटिलता के साथ बुनियादी text editing कार्यों को आसानी से पूरा करने देता है
  • इसका interface परिचित अनुभव देता है और accessibility तथा ease of use को महत्व देता है
  • यह ICU (International Components for Unicode) library पर वैकल्पिक रूप से निर्भर होकर Search and Replace फीचर को सपोर्ट करता है

Package managers और packaging maintainers के लिए ध्यान देने योग्य बातें

Package naming

  • डिफ़ॉल्ट executable नाम "edit" है, और वैकल्पिक नाम "msedit" है
  • मौजूदा system command "edit" के साथ टकराव की संभावना के कारण "msedit" जैसे वैकल्पिक naming की सिफारिश की जाती है
  • "ms-edit" जैसे नामों से बचने की सलाह दी जाती है

ICU library naming (SONAME)

  • Search and Replace फीचर के लिए ICU library का उपयोग किया जा सकता है
  • अलग-अलग OS पर डिफ़ॉल्ट रूप से खोजी जाने वाली libraries इस प्रकार हैं
    • Windows: icuuc.dll
    • macOS: libicuuc.dylib
    • UNIX और अन्य: libicuuc.so
  • यदि system environment के अनुसार library नाम (SONAME) अलग हो, तो उसे environment variables (EDIT_CFG_ICUUC_SONAME, EDIT_CFG_ICUI18N_SONAME आदि) से सेट किया जा सकता है
  • ICU export symbol naming convention अलग होने की स्थिति के लिए अतिरिक्त environment variables भी दिए गए हैं

अन्य

  • ICU renaming auto-detection, C++ symbol support जैसी अतिरिक्त options भी उपलब्ध हैं
  • इन settings की जाँच के लिए cargo test -- --ignored कमांड से test चलाया जा सकता है

निष्कर्ष

  • सादगी और accessibility पर ज़ोर देने वाला, साथ ही लचीले environment configuration का समर्थन करने वाला open source editor
  • यह developers, open source contributors, और package managers को स्पष्ट guidelines और उच्च compatibility प्रदान करता है

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

1 टिप्पणियां

 
GN⁺ 2025-06-26
Hacker News राय

  • यह बस एक ऐसा प्रोजेक्ट है जो किसी ने “मैं यह करना चाहता था” वाली भावना से बनाया, और मुझे भी याद है कि मैंने भी इसी तरह कुछ बनाकर अंदरूनी कामकाज के सिद्धांत समझे थे। लेकिन Turbo Vision को FPC में फिर से लिखकर कई targets के लिए compile होने वाला version तो लगभग 20 साल से मौजूद है। मुझे Turbo Vision अब तक की सबसे बेहतरीन text mode window library लगती है। असली मज़ा पूरे text screen को एक array से map करने वाले हिस्से से शुरू होता है। var Screen: Array[1..80,1..25] Of Byte Absolute $B800 कुछ ऐसा ही था, अगर ठीक याद हो। Turbo Vision वाकई इस मायने में क्रांतिकारी था कि इसमें movable (non)modal windows थीं। यानी आखिरकार वही array loop में घुमाकर लगातार फिर से लिखा जाता था। काफ़ी तेज़ था। मुझे याद है कि मैंने भी उस library से काफ़ी अच्छी कमाई की थी

    • जिन लोगों की दिलचस्पी हो, उनके लिए इसका आधुनिक C++ Turbo Vision version भी है, और Unicode support वाला port भी मौजूद है https://github.com/magiblot/tvision

    • TP के arrays row-major थे। एक character 2 bytes का होता था (glyph + attribute)। इसलिए even array[1..25, 1..80] of packed record ch: char; attr: byte end absolute $B800:0000 जैसी सुविधा भी थी। monochrome text display पर $B800 को $B000 कर देना होता था। जैसे Hercules वाले माहौल में

    • अगर VSCode में ऐसा interface terminal में, वह भी remote पर, चल सके तो वाकई बहुत अच्छा होगा

    • यह जानने की जिज्ञासा है कि उस library से पैसे कैसे कमाए। काश इसका राज़ थोड़ा बताया जाता

    • आजकल जब भी कोई नया TUI framework देखता हूँ, हमेशा यही लगता है: “Turbo Vision जितना अच्छा नहीं”

  • दूसरी तरफ AI Copilot जैसी अनावश्यक भारी चीज़ों को Notepad में ठूँसने की कोशिश हो रही है। मुझे तो हमेशा लगा कि Notepad की असली खूबी यही थी कि वह बिना फालतू features के सिर्फ़ एक काम ठीक से करता था

    • नया Edit भी इस तरह के फ़ैसलों से पूरी तरह मुक्त नहीं है। Satya के दौर में MS ने FOSS-फ्रेंडली होने का अभिनय किया, लेकिन Gates/Balmer के ज़माने में वह Windows developers के लिए कहीं ज़्यादा बेहतर था। अब web/desktop frameworks आपस में घुलमिल गए हैं, और हालत यह है कि अंदर भी उन्हें ठीक से इस्तेमाल नहीं किया जाता। पहले के VS wizards या plugins की जगह अब CLI tools से Excel files dump करने जैसी चीज़ें दिखती हैं। इससे पीढ़ियों के बीच Windows development culture का टूटना और management में know-how की कमी साफ़ दिखती है

    • Raymond Chen ने एक बार कहा था कि Notepad उम्मीद से कहीं ज़्यादा testing में इस्तेमाल होता है। फीचर साधारण है, लेकिन प्रयोगों के लिए उसे बहुत चलाया जाता है https://devblogs.microsoft.com/oldnewthing/20180521-00/?p=98795

    • मैंने Windows 11 की नई Paint में screenshot paste करके देखा, और minimized होने पर भी वह लगातार 5% CPU खा रही थी और लगभग 250MB memory ले रही थी। RAM की बात तो किसी हद तक समझी जा सकती है, लेकिन CPU की ऐसी बर्बादी ठीक नहीं लगती। पहले कभी quality और craftsmanship पर गर्व हुआ करता था

    • जब ISP में intermittent outage था (IPv4/MTU issue), तब Notepad में save तक नहीं हो पा रहा था। ज़बरदस्ती बंद करना पड़ा। उस समय मैं Wireguard से temporary workaround सेट कर रहा था

    • अगर modern notepad हटा दो, तो Start Menu में पुराना notepad search करने पर भी नहीं मिलता

  • मुझे याद है, करीब एक महीने पहले मैंने सुना था कि MS ने Windows users के लिए ज़्यादा परिचित Linux distribution जारी किया है। जहाँ तक याद है, वह बस एक साधारण GNOME environment था और उसमें कोई खास बात नहीं थी। उल्टा MS अपनी खुद की Linux distro बनाकर उसमें bash की जगह powershell, Edit की जगह vim/nano आदि के विकल्प, और .NET या Visual Studio Code जैसे tools default development tools के रूप में दे सकता था... अगर MS ने इसे WSL की default distro बनाया होता, तो शायद वह युद्ध तो नहीं जीतता, लेकिन user share ज़रूर बढ़ा सकता था। भले MS kernel तक कब्ज़ा न कर पाए, userland पर प्रभुत्व तो बना सकता था। बहुत से Windows users default installed apps के तौर पर MS के tools स्वाभाविक रूप से इस्तेमाल करने लगते। अब Microsoft Edit Linux पर भी उपलब्ध है। Powershell जैसी दूसरी apps भी वैसी ही हैं। अगर 10 साल पहले यह रणनीति अपनाई जाती, तो कल्पना की जा सकती है कि आज WSL में MS की distro top 5 में होती। यह बात थोड़ा असहज करती है कि बड़ी कंपनियाँ (M$) मेरे निजी PC तक अपना प्रभाव बढ़ा सकती हैं। आखिर में तो मैं बस उस दिन की कल्पना कर रहा हूँ जब Microsoft Edit में Co-Pilot bundled मिलेगा

    • मुझे लगता है कि किसी दिन MS कम-से-कम कुछ क्षेत्रों, जैसे Windows Server या embedded Windows, से शुरू करके धीरे-धीरे Linux की तरफ बढ़ेगा। लंबी अवधि में Windows desktop भी धीरे-धीरे बदलकर ‘Windows Legacy’ बनाम ‘Windows Linux Workstation’ जैसे विकल्पों तक पहुँच सकता है। शायद Linux kernel + tuned WINE + कुछ legacy support के लिए integrated VM जैसी दिशा में। समस्या यह है कि NT kernel डिज़ाइन के स्तर पर Linux से कई मामलों में आगे है (जैसे पूरे GPU driver crash के बाद recovery संभव होना)। लेकिन Windows खुद धीरे-धीरे asset से ज़्यादा liability बनता जा रहा है। असल में MS की growth Azure & Office 365 से आ रही है, जबकि Windows license लगभग ठहरा हुआ है। कम-से-कम Linux-based Windows server और workstation की उम्मीद की जा सकती है

    • Azure Linux (पूर्व CBL-Mariner) MS की आधिकारिक Linux distribution है, जो containers, VM और servers के लिए बनाई गई है। इसे सामान्य Windows users के लिए किसी skinned desktop environment से अलग समझना चाहिए

    • मुझे याद है कि MS की पुरानी Linux-like distribution का नाम “Xenix” था, लेकिन उसका प्रदर्शन अच्छा नहीं रहा था

    • WSL बनने की बड़ी वजह यह थी कि बड़ी कंपनियों के अंदर developers को Linux environment की ज़रूरत बढ़ रही थी। IT support वाले Linux को अच्छी तरह नहीं जानते, और न ही उसे support करना चाहते हैं। WSL ने इस समस्या को हल किया। असल में बहुत से developers Linux इस्तेमाल करना भी नहीं चाहते, और terminal में भी सहज नहीं होते। वे GUI tools पर निर्भर रहते हैं

    • यह मानना थोड़ा अवास्तविक है कि MS सिर्फ़ Windows users की भावनात्मक पसंद पूरी करने के लिए अपनी कोई secret distro बनाए रखेगा

  • यह खबर इतनी चर्चा में है कि एक हफ़्ते के अंदर 3 बार पोस्ट हो चुकी है

    1. लेखक की पोस्ट - https://news.ycombinator.com/item?id=44034961
    2. Ubuntu की आधिकारिक पोस्ट - https://news.ycombinator.com/item?id=44306892
    3. और अब यह पोस्ट

  • मूल edit.com (DOS 6.22 से, बाद में 7.0/Windows 95) मेरा पहला IDE था। शुरुआत qbasic से हुई थी, और वह लगभग edit.com जैसा ही program था। C/C++ मैंने djgpp से सीखा, तब भी edit.com ही इस्तेमाल करता रहा। मेरी “project file” e.bat होती थी, और edit file1.cpp file2.cpp... की तरह कई files एक साथ खोल सकता था। दूसरे editors में multi-file switching असुविधाजनक थी, लेकिन alt-1,2,3... से तुरंत switch होना मुझे बहुत पसंद था। आज भी जब मैं editor shortcuts बदलता हूँ, तो इस style को ज़रूर बनाए रखता हूँ। हालाँकि code editor के तौर पर वह कमज़ोर था। syntax highlighting नहीं थी, और indentation support भी ख़ास नहीं था (इसीलिए शुरुआत में मैं दो spaces indentation करता था, जिसे manually करना भी आसान था)। फिर भी लिखे गए code पर तुरंत feedback और उसकी familiarity शानदार थी। qedit जैसा editor भी था, लेकिन वह मेरी पसंद नहीं था; Unix-style editors DOS में मुझे उतने अच्छे नहीं लगे। यह नया editor multi-buffer support तो देता है, लेकिन मेरे परिचित key binding style जैसी चीज़ इसमें नहीं दिखती

    • इसे issue के रूप में उठाना अच्छा रहेगा। इस तरह का feedback अगर शुरुआती चरण में दिया जाए, तो अक्सर वह सच में शामिल कर लिया जाता है। और सच तो यह है कि सिर्फ़ मिलता-जुलता नहीं, edit.com तो qbasic को एक flag के साथ boot किया गया वही program था। मैं खुद भी qbasic को वह flag देकर चलाता था https://news.ycombinator.com/item?id=44037509

    • syntax highlighting नहीं थी, लेकिन syntax uppercasing था (जैसे reserved words अपने-आप uppercase हो जाते थे)। उदाहरण के लिए, अगर आप पूरी line lowercase में लिखें और Enter दबाएँ, तो reserved words अपने-आप uppercase बन जाते थे। छोटी चीज़ थी, पर काफ़ी सुविधाजनक

    • copy con के ज़माने की तुलना में edit सचमुच एक उद्धारक था

  • कई वजहों से यह चीज़ बहुत पसंद आई। सबसे पहले, dependency-free साफ़-सुथरी list! मैं तो पूरी तरह प्रभावित हो गया। यक़ीन ही नहीं होता कि पूरी TUI सिर्फ़ इस एक editor के लिए खुद बनाई गई है। dialogs हैं, file browser भी है। मैं इसे अपने project में भी अपनाना चाहूँगा। अगर यहाँ कोई संबंधित व्यक्ति हो, तो यह जानने की जिज्ञासा है कि Ratatui क्यों नहीं इस्तेमाल किया गया। code quality असाधारण रूप से अच्छी है। एक शब्द में: Bravo!

  • पहले मैं ऐसे text editor की तलाश करने वालों को micro[1] recommend करता था। अब समझ नहीं आ रहा कि क्या recommend करूँ

    • https://micro-editor.github.io/

    • मेरे हिसाब से recommendation बदलने की ज़रूरत नहीं है। edit में (कम-से-कम जहाँ तक मैंने देखा) syntax highlighting भी नहीं है

    • आख़िरी बार जब मैंने देखा, तो उसका binary file size इतना बड़ा था कि उसे micro नहीं बल्कि macro कहना चाहिए था

    • dte[1] भी एक विकल्प है। Unicode support, CUA key bindings वगैरह के साथ बहुत सरल लेकिन ताकतवर है। मैं इसे nano के विकल्प वाले terminal editor के रूप में संतोष से इस्तेमाल कर रहा हूँ https://craigbarnes.gitlab.io/dte/

    • Windows पर इसे सिर्फ़ winget install zyedidia.micro से install किया जा सकता है। इसमें पुराने 8-bit/16-bit दौर के editors जैसा एहसास है

  • मैं सच में जानना चाहता हूँ कि MS जैसी बड़ी संस्था में ऐसे projects को मंज़ूरी कैसे मिलती है। क्या यह सिर्फ़ किसी developer का side project था, product roadmap का हिस्सा था, या leadership को मनाने की कोई प्रक्रिया हुई थी?

    • text editor, copilot integration के लिए, एकदम उपयुक्त target है

    • जैसा कि वजहों से पता चलता है, command line पर चलने वाला editor चाहिए था (Windows Core Server install के लिए), SSH से connect होकर भी इस्तेमाल करना था (कुछ सालों से Windows में SSH server default built-in है), और जिन Windows administrators को vi का अनुभव नहीं है उनके लिए non-modal editor की ज़रूरत थी। इन्हीं ज़रूरतों ने इस project को जन्म दिया

    • कभी-कभी हर team को कुछ quota पूरा करना होता है, तो ideas आते हैं; कभी leader के निर्देश पर (जैसे copilot usage), या hackathon जैसी events से शुरू होकर चीज़ें बढ़ती हैं। research organization में technical लोग अगर कुछ समय खाली हों तो ऐसी चीज़ें निकल आती हैं, और कई बार लंबी analysis के बाद ही budget मिलता है। सिर्फ़ committers की संख्या देखकर भी लगता है कि यह काफ़ी strategic investment था। यह कोई overnight तैयार हो गया project नहीं है

  • उम्मीद है कि किसी दिन पुराना EDLIN Unicode support के साथ वापस आए। EDLIN में batch file से scripted key input pipe करके कुछ काम automate किए जा सकते थे। कुछ-कुछ sed या awk के आंशिक विकल्प जैसा था। मुझे लगता है vi भी कुछ हद तक ऐसी architecture रखता है, हालांकि वह कितना असामान्य है यह अलग सवाल है

    • शायद आप ed ढूँढ़ रहे हैं। -s option के साथ वह scripting के लिए एकदम सही है

  • संबंधित चर्चा (271 points, 185 comments) https://news.ycombinator.com/item?id=44031529