प्लेन टेक्स्ट दशकों से मौजूद है और आगे भी बना रहेगा

• Monospace plain text आधारित डायग्राम·UI डिज़ाइन टूल फिर से इस्तेमाल में आ रहे हैं, और text editing interface की परिचितता व file format की portability इन्हें लंबे समय तक टिके रहने की ताकत देती है
• Mockdown, Wiretext, Monodraw जैसे टूल सीमित visual choices को बनाए रखते हुए low-intensity diagrams बनाने के लिए अच्छे हैं, और source code के अंदर डालने के उपयोग के लिए भी उपयुक्त हैं
• Mockdown को web और mobile पर तुरंत इस्तेमाल किया जा सकता है, Wiretext web पर चलता है लेकिन desktop-only है, और Monodraw Mac app के रूप में उपलब्ध है
• 1970~1980 के दशक में अपने शिखर पर रही यह शैली Turbo Vision जैसी TUI श्रेणी की याद दिलाने वाले रूप में लौट रही है, जिसमें modern feel, performance, web accessibility, और mouse·trackpad usability जुड़ गई है
• जैसे-जैसे computer performance बढ़ती है, वैसे-वैसे खुद पर constraints लगाने वाला workflow अधिक उपयोगी होता जाता है, और ऐसे plain text tools धीरे-धीरे gen AI entry point के रूप में भी इस्तेमाल हो रहे हैं

---

प्लेन टेक्स्ट टूल्स की स्थायित्व

• Plain text या “ASCII” आधारित डायग्राम·UI डिज़ाइन टूल के रूप में Mockdown, Wiretext, Monodraw का उल्लेख किया गया है
  • Mockdown सीधे web पर चलता है और mobile को भी support करता है
  • Wiretext web पर चलता है, लेकिन इसे केवल desktop पर ही इस्तेमाल किया जा सकता है
  • Monodraw, Mac app के रूप में उपलब्ध है
• ऐसे टूल तब पसंद किए जाते हैं जब जानबूझकर सीमित visual choices चाहिए हों, source code में डालने के लिए low-intensity diagrams बनाने हों, और increasingly gen AI entry point के रूप में भी उनका उपयोग हो
• 1970~1980 के दशक में चरम पर रही यह शैली आधुनिक रूप में फिर जीवित हो रही है
  • यह Turbo Vision जैसी TUI श्रेणी की याद दिलाती है
  • इसमें modern sensibility, performance, web accessibility, और mouse व trackpad operability जुड़ते हैं
• constraints के साथ काम करने का तरीका खुद में महत्वपूर्ण होता जा रहा है
  • computer performance बढ़ने के साथ, खुद पर सीमाएँ लगाकर काम को आसान बनाना पहले से ही उपयोगी है
  • AI के फैलाव के साथ, self-constraint उस दिशा में भी महत्वपूर्ण हो जाती है जहाँ काम को जानबूझकर अधिक कठिन बनाया जाता है
• Monospace plain text के लंबे समय तक टिके रहने की ताकत सिर्फ file format की portability में नहीं, बल्कि इस बात में भी है कि interface के रूप में text editing व्यापक रूप से जानी-पहचानी और शक्तिशाली है
  • potent
• Mockdown का ASCII spray खास तौर पर एक दिलचस्प तत्व माना गया है
• यहाँ “ASCII” शब्द सख्त technical term से ज़्यादा, उसी तरह का बोलचाल का प्रयोग है जैसे looping animation को सामूहिक रूप से “GIF” कहा जाता है

[GN⁺]

Hacker News की राय

• उदाहरण के तौर पर plain text accounting का आना अच्छा लगा
  मैंने QuickBooks से Beancount+Fava पर अपने one-person business की बहीखाता प्रणाली शिफ्ट की, और इससे मैं कहीं ज़्यादा संतुष्ट हूँ। मैंने text-based invoice system और vehicle mileage tracking भी जोड़ लिया है, और tax status वाले खर्चों के लिए supporting documents अनिवार्य रूप से जुड़े रहें, इसके लिए validator भी लगा रखा है
  यह QuickBooks से बहुत तेज़ है, इस्तेमाल में आसान है, ads देखने की ज़रूरत नहीं पड़ती, और git तथा RFC3161 commit proof जोड़कर यह साबित किया जा सकता है कि कौन-सी एंट्री कब जोड़ी गई। लापरवाही से text edit होने पर रिकॉर्ड गायब हो जाने की संभावना भी कम हो गई है, और हर item कब बना था, यह देखना भी आसान है
  मूल बात यह है कि सब कुछ plain text है, लेकिन चाहें तो browser में संभालने के लिए Fava extension भी जोड़ रखा है। अगर graph वाला TUI Fava होता तो और अच्छा होता, लेकिन web UI भी काफ़ी अच्छा है
  अब बस यही देखना बाकी है कि accountant इसे कैसे देखेगा

  • मुझे Beancount के बारे में पहली बार पता चला, और यह काफ़ी आकर्षक लग रहा है
    मैं अमेरिकी हूँ, लेकिन दूसरे देश में काम करता हूँ, इसलिए हमेशा 2 currencies संभालनी पड़ती हैं। Gnucash में multi-currency को संतोषजनक ढंग से संभालना संभव नहीं हुआ, इसलिए मैं और मेरी पत्नी अब तक text files में रिकॉर्ड रखते आए हैं
    हमने format काफ़ी consistently इस्तेमाल किया है, इसलिए Beancount में migrate करते समय conversion script या LLM की मदद से शायद 95% काम automate हो सकता है। जो entries parse न हों, उनके लिए warning दिखा दी जाए तो काफ़ी होगा
    मेरे भी Beancount + Fava की तरफ़ जाने की पूरी संभावना है
  • यह मेरे plain text accounting projects के लिए सच में बहुत अच्छी प्रेरणा है
    खास तौर पर मैं यह ज़्यादा विस्तार से जानना चाहता हूँ कि RFC3161 commit proof का इस्तेमाल कैसे किया जाता है
    commit author खुद वही व्यक्ति है, यह दिखाने के लिए GPG signing का अंदाज़ा तो है, लेकिन मैं जानना चाहता हूँ कि इसमें external timestamp service और external CA का उपयोग होता है या अपनी trust chain बनाई जाती है
    अगर accounting auditor ledger commits की authenticity माँगे, तो असल में कौन-सा material और कौन-सी प्रक्रिया से यह साबित किया जाता है, यह भी जानना चाहूँगा
  • यह तरीका सच में बहुत अच्छा है
    जब मैं खुद कोई simple file format बनाता हूँ, तब भी मैं हमेशा सोचकर रखता हूँ कि ज़रूरत पड़ने पर इसे ज़्यादा common format में कैसे convert किया जाएगा
    सिर्फ़ यह जानकर ही मन को सुकून मिलता है कि ज़रूरत पड़ने पर किसी और को देने के लिए एक exit path मौजूद है
    इस मामले में तो शायद accountant के लिए स्वीकार्य CSV में बदलना भी आसान होगा

• इसका स्वर्णकाल 1970~80 के दशक में रहा हो सकता है, लेकिन 1990 के शुरुआती DOS दौर में भी बहुत शानदार TUI मौजूद थे
  वह समय Windows के पूरी तरह हावी होने से पहले का था, और आम तौर पर VGA-compatible graphics cards और monitors होते थे, इसलिए high-resolution, crisp, और adjustable-font text mode इस्तेमाल किया जा सकता था। कई बार mouse भी होता था
  बड़े होते हुए मैं ऐसे ही माहौल में QBASIC और EDIT.COM का आदी हुआ
  उस समय के कुछ apps में तो proper mouse cursor तक implement किया गया था, और Bisqwit का यह वीडियो उसे अच्छे से दिखाता है: https://www.youtube.com/watch?v=7nlNQcKsj74

  • उस दौर का Borland code editor मुझे बहुत पसंद था
    वही editor जो Turbo-C, Turbo-Pascal वगैरह में आता था; उसे IDE कहना भी गलत नहीं होगा
    text-mode WordPerfect, WordStar, और Lotus 1-2-3 भी काफ़ी बेहतरीन थे
  • मेरे हिसाब से TUI की चोटी के सबसे क़रीब Norton Commander या Midnight Commander आते हैं
  • बल्कि मैं तो मानता हूँ कि TUI का स्वर्णकाल अभी है
    terminal और config files पर चलने वाला operating system Omarchy देखें तो वह लगभग स्वर्ग जैसा लगता है
    अगर भविष्य में मशीनों के साथ मुख्य interface text-based conversation बन जाता है, तो यह रुझान कितना आगे जाएगा, यह देखने के लिए मैं उत्साहित हूँ
    यहाँ AI की बात करना कुछ लोगों को पसंद न आए, लेकिन मैं उस भविष्य को लेकर सच में उत्साहित हूँ

• शीर्षक देखकर मैं लेख के मूल विषय से थोड़ा अलग दिशा में चला गया, लेकिन अगर आप मानते हैं कि plain text simple और robust computing की बुनियाद है, तो Dylan Beattie का There's no such thing as plain text प्रस्तुतीकरण देखने लायक है
  https://www.slideshare.net/slideshow/theres-no-such-thing-as-plain-text-dylan-beattie/249952971
  इसके कई conference videos भी आसानी से मिल जाएंगे

  • मैंने अभी तक वीडियो नहीं देखा, लेकिन slides देखकर लगता है कि मुख्य बिंदुओं में से एक encoding का मुद्दा है
    UTF-16LE और UTF-16BE जैसे उदाहरण भी हैं
    अच्छी बात यह है कि अब UTF-8 लगभग default बन चुका है, इसलिए किसी खास वजह के बिना ज़्यादातर documents को UTF-8 मान लेना ठीक है
    जब कोई text file मिले और उसकी encoding न पता हो, तब भी मेरे हिसाब से उसके UTF-8 होने की संभावना 99.7% के आसपास है। इसलिए अब फिर से यह कहना ठीक लगता है कि plain text जैसी कोई चीज़ है
  • सिर्फ़ slideshow देखकर तर्क ठीक से समझ नहीं आता
    अगर बात यह है कि code page या UTF-16 जैसी चीज़ें भी plain text हैं, लेकिन वास्तव में नहीं हैं, तो 2026 के हिसाब से यह दावा काफ़ी पुराना लगता है
    अब तो UTF-8 लगभग हर जगह है
  • मैं यह अभिव्यक्ति पहले से इस्तेमाल करता आया हूँ, लेकिन बस एक धुँधला-सा अंदाज़ा था कि इस पर कोई proper talk पहले से मौजूद होगी
    ऐसा material वास्तव में मौजूद है, यह देखकर अच्छा लगा
  • मैं उस दावे से मज़बूती से असहमत हूँ
    Unicode जैसा complex और अजीब system plain नहीं कहा जा सकता, और आज भी बहुत से apps में Unicode से जुड़ी समस्याएँ अक्सर आती रहती हैं
    मेरे हिसाब से सच में हर जगह ठीक से काम करने वाली text system अब भी सिर्फ़ ASCII है, और plain text कहलाने के लिए कम-से-कम उतना simple होना चाहिए
    इसका मतलब है कि वह English-centric होकर सीमित रह जाती है, लेकिन कई environments में वही अधिक natural है। मैं भी native English speaker नहीं हूँ, फिर भी इस स्थिति का समर्थन कर सकता हूँ

• Plain text सच में शानदार है
  मैं अपने 20 साल से ज़्यादा पुराने notes को https://github.com/nickjj/notes से manage कर रहा हूँ
  invoices भी लगभग 7 साल से https://github.com/nickjj/invoice के जरिए plain text तरीके से संभाल रहा हूँ
  income-expense tracking के लिए https://github.com/nickjj/plutus भी है, और मैं इससे बहुत संतुष्ट हूँ
  अब मैं बस bank CSV export करता हूँ, उसे Plutus में डालता हूँ, और कुछ मिनट categories मिलाने में लगते हैं, बस ledger तैयार हो जाता है
  इसी तरीके से मैं 2 साल से tax filing भी कर रहा हूँ

• text Lindy है
  उसने समय की कसौटी पर खुद को साबित किया है, और SQL या TCP/IP जितना ही व्यापक है
  Graydon Hoare का पुराना लेख Always bet on text भी याद आता है
  [1]: https://news.ycombinator.com/item?id=8451271
  [2]: https://graydon2.dreamwidth.org/193447.html

• मुझे जिज्ञासा है कि यहाँ HN को भी plaintext माना जाएगा या नहीं
  साइट स्पष्ट रूप से HTML और hyperlinks से बनी है, लेकिन वास्तविक उपयोग का अनुभव clickable text interface के क़रीब है
  cryptographic नज़रिए से देखें तो HTML भी ascii/utf-8 में encode होता है, इसलिए उसे plaintext कहा जा सकता है, लेकिन MIME type में text/plain और text/html document structure और style information में फर्क करते हैं
  terminal को भी अक्सर plaintext माना जाता है, जबकि वास्तव में वह ऐसे escape sequences के ज़रिए metadata रखता है जिन्हें इंसान सीधे पढ़ना मुश्किल पाता है
  दूसरी तरफ़ social media पर कुछ lines वाले images बहुत हैं, और हाल के mobile platforms image के भीतर text पहचानकर उसे select भी करने देते हैं
  तो फिर सवाल उठता है: क्या दूसरे तत्वों के बिना सिर्फ़ text वाली image plaintext है?
  अंततः मैं यही पूछना चाहता हूँ कि शुरुआती implementation के दशकों बाद आज plaintext की सीमा कहाँ खींची जानी चाहिए

  • HN तो बस सामान्य HTML है, इसलिए उसे plaintext कहना कोई बड़ी बात नहीं होगी

• यह मूल लेख से थोड़ा अलग विषय है, लेकिन text character-based statistical charts याद आ गए
  बहुत पहले मैंने DOS के लिए educational edition MINITAB इस्तेमाल किया था, जो text characters से scatter diagram, dotplot, और box-and-whisker plot बनाता था
  जहाँ तक याद है, pure text, ASCII, या DOS line-drawing characters को option के रूप में इस्तेमाल किया जा सकता था
  मकसद यह था कि proper statistical tests पर जाने से पहले data को explore कराया जाए
  जानना चाहूँगा कि क्या आज भी कोई program है जो terminal में इस तरह का proper dotplot बना सके

  • इस Stack Overflow thread में terminal plotting tools काफ़ी अच्छे से संकलित हैं
    https://stackoverflow.com/questions/123378/command-line-unix-ascii-based-charting-plotting-tool
    इसमें gnuplot, feedgnuplot, eplot, asciichart, bashplotlib, ervy, ttyplot, youplot, visidata का ज़िक्र है
    और AWK की किताब में एक शानदार ASCII plot उदाहरण भी है: https://dn790008.ca.archive.org/0/items/pdfy-MgN0H1joIoDVoIC7/The_AWK_Programming_Language.pdf#page=148
  • शायद gnuplot dumb terminal mode काम आ जाए

• ऊपर की सूची और भी लंबी हो सकती है
  https://asciiflow.com/
  https://asciidraw.github.io/
  जानना चाहूँगा कि और कौन-कौन से tools हैं

  • D2 ने पिछले साल ASCII & Unicode output के लिए beta support जोड़ा था
    https://d2lang.com/
  • https://github.com/TheoKVA/ascii-box-editor
    नाम के उलट यह ASCII नहीं, बल्कि UTF-8 BOX DRAWING characters इस्तेमाल करने वाला visual editor है
    इसमें server या installation की ज़रूरत नहीं, यह सिर्फ़ browser में चलने वाला Javascript तरीका है
  • https://xosh.org/text-to-diagram पर बहुत से tools सूचीबद्ध हैं
  • https://monosketch.io

• M-x artist-mode भी है, जिसे Emacs में सीधे इस्तेमाल किया जा सकता है

• plain text निश्चित रूप से अच्छा है, लेकिन जैसे ही structured data की ज़रूरत पड़ती है, हर file के साथ फिर से शून्य से शुरुआत करनी पड़ती है
  पुराने Unix tools को ad-hoc तरीके से जोड़कर plain text process करने के approach के प्रति लोगों में nostalgia ज़रूर है, लेकिन ऐसा तरीका अस्थायी हालात में तो ठीक है, well-specified formats का विकल्प नहीं बन सकता

  • XML, JSON, YAML, RDF, EDN, LaTeX, OrgMode, Markdown जैसे structured plaintext formats पहले से बहुत हैं
    इन्हें line-based plain text की तरह process भी किया जा सकता है, structured data transformation भी संभव है, और इन्हें WYSIWYG की तरह render करने वाले clients या readers भी पहले से उपलब्ध हैं