Mitchell Hashimoto इंटरव्यू: Ghostty, Zig, open source मेंटेनेंस

 (alexalejandre.com)
10 पॉइंट द्वारा GN⁺ 5 시간 전 | 4 टिप्पणियां | WhatsApp पर शेयर करें
  • Mitchell Hashimoto ने Vagrant, Terraform और Vault के बाद Ghostty और Vouch बनाए, और terminal, Zig, open source मेंटेनेंस व product quality को लेकर अपने मानक स्पष्ट किए
  • Ghostty की शुरुआत GPU programming, desktop/single-node system programming और Zig सीखने के लिए एक personal project के रूप में हुई थी, और यह तेज़, feature-rich, native cross-platform terminal बनने के लक्ष्य की ओर विकसित हुआ
  • Terminal को browser की तरह हर feature समेटने के बजाय text-based apps की composability, automation और साफ़ security model को मजबूत करना चाहिए; PTY की असंरचित byte stream अब भी एक सीमा है
  • Open source maintainers पर users के प्रति कोई बाध्यता नहीं होती, लेकिन अच्छे software के लिए अलग-अलग requests को ज्यों का त्यों लेने के बजाय कई समस्याओं को एक consistent feature में हल करना चाहिए
  • Zig में बड़े बदलाव downstream पर बोझ डालते हैं, लेकिन वे API और compile tools की quality बढ़ा रहे हैं; AI बड़े बदलावों में repetitive काम घटाकर backward compatibility का बोझ कम कर सकता है

Ghostty क्यों शुरू हुआ

  • Mitchell Hashimoto Vagrant, Packer, Consul, Terraform, Vault, Nomad, Waypoint बनाने के बाद अब Ghostty और Vouch बना रहे हैं
  • Ghostty की शुरुआत इस एहसास से हुई कि उन्होंने लगभग 15 साल तक CLI applications बनाए, लेकिन terminal emulator कैसे काम करता है, इसे ठीक से नहीं समझते थे
  • Hashicorp छोड़ने के बाद वे तीन क्षेत्रों में फिर से काम करना चाहते थे
    • AI से पहले के संदर्भ में GPU programming
    • distributed systems से अलग desktop/single-node system programming
    • Zig का इस्तेमाल
  • शुरुआती लक्ष्य था vim और compiler चलाना, Ghostty को खुद को build करने लायक बनाना और फिर उसे छोड़ देना
  • Terminal ecosystem को और देखने पर उन्हें लगा कि तेज़, feature-rich और native cross-platform tools की कमी है
  • Discord पर दोस्तों के साथ share करने के बाद इसे रोज़ इस्तेमाल करने वाले users बन गए, और Ghostty Discord असल में दोस्तों के group chat को dedicated space में बदलने से बना
  • उन्हें लगा कि public visibility जरूरत से ज्यादा attention ला सकती है, इसलिए इसे लंबे समय तक private beta के रूप में चलाया

Terminal को कितना expand होना चाहिए

  • Hashimoto terminal को बिना सोचे-समझे एक बहुत बड़े application platform की दिशा में धकेलने के खिलाफ हैं
  • Terminal browser या पुराने Java runtime की तरह video, microphone access और responsive layout तक समेट सकता है, लेकिन उनके अनुसार browser, desktop और text-based fixed-width grid apps की अपनी-अपनी ताकतें हैं
  • Text-based applications जल्दी implement होते हैं, interaction आसान होता है, और उनका security model स्पष्ट होना चाहिए
  • Terminal-based apps की ताकत composability में है
    • TUI में यह गुण थोड़ा कम होता है, लेकिन अधिकतर CLI tools में stdin/stdout से आगे बढ़कर functions की तरह इस्तेमाल होने वाले mechanisms होते हैं
    • UNIX का “एक काम करो और अच्छे से करो” वाला दर्शन इसका चरम रूप है
    • Neovim और AI tools लगातार ज्यादा command-line flags दे रहे हैं
  • बेहतर terminal applications बेहतर automation और scriptability की ओर ले जाते हैं
  • PTY के in-band signals, यानी escape sequences समेत असंरचित byte stream, एक बड़ी समस्या बने हुए हैं
  • Nushell ecosystem इसे अलग layer में ठीक करने की कोशिश करता है, लेकिन Hashimoto के अनुसार अधिक बुनियादी सुधार की जरूरत है
  • Microsoft ecosystem को नापसंद करने वाले लोग भी बहुत हैं, लेकिन उनके मुताबिक PowerShell ने structured data के मामले में बहुत कुछ सही किया है

Non-legacy terminal API की परिकल्पना

  • नए terminal API पर सोचते समय Hashimoto browser, Emacs, Apple, Microsoft, Android और game consoles जैसे बड़े application platforms के frameworks को संदर्भ के रूप में देखते हैं
  • उनके अनुसार web के DOM और JS API, Apple के AppKit·Cocoa·SwiftUI, Windows के Win32·WinUI, और Linux के GTK·Qt जैसे पहले से जमा examples को पहले देखना चाहिए
  • Clipboard access ही लें, तो ऐतिहासिक terminal protocols text-centric हैं, लेकिन desktop लंबे समय से images और कई MIME types संभालता आया है, इसलिए हर platform की clipboard documentation देखनी चाहिए
  • अभी तक Ghostty में custom protocol introduce नहीं किया गया है

  • n-screen API

    • मौजूदा terminals में आम तौर पर दो screens होते हैं: main screen और alt screen
    • main screen shell और scrollback के करीब है, और alternate screen Neovim और अधिकतर TUI के करीब है
    • यह structure इन दो modes में से किसी एक को on या off करने जैसा है, और आमतौर पर पूरी screen घेरता है व scrollback खो देता है
    • Hashimoto एक n-screen API की कल्पना करते हैं, जिसमें unlimited screens background में बनाए और भरे जा सकें
    • हर screen का grid size अलग रखा जा सकता है और उन्हें overlay किया जा सकता है, जबकि terminal emulator line wrapping, selection और mouse event routing संभाल सकता है
    • किसी खास screen को independent window घोषित करने पर terminal emulator उसे grid के बाहर भी render कर सकता है
    • उदाहरण के तौर पर उन्होंने Neovim tabs को native window tabs की तरह एक साथ खोलने का रूप बताया

  • Button protocol

    • मौजूदा mouse protocol में event तभी मिल सकता है जब user current screen के grid cell पर click करे
    • Scrollback में चले गए history items पर click events नहीं मिल सकते
    • Terminal अभी hyperlink protocol OSC 8 support करता है
    • Hashimoto OSC 8 जैसा button protocol सोचते हैं, जो click पर program द्वारा तय message भेजे
    • उदाहरण के लिए open_profile ID वाला button user के history में scroll करने के बाद भी registered रह सकता है
    • यह feature scrollback वाले main screen applications को प्रभावित करता है, और Claude Code जैसे main screen apps में file opening या in-app links history में चले जाने पर काम न करने की समस्या से जुड़ता है

Standards की कमी और open source मेंटेनेंस

  • Hashimoto ने पूरे PTY protocol को Wayland से बदलने का experiment किया था, लेकिन उसे छोड़ दिया
  • Terminal को windows और window widgets manage करने वाले windowing server की तरह देखा जा सकता है, और उनके अनुसार Wayland local desktop और window rendering समस्याओं को हल करने वाला अच्छा protocol है
  • Terminal की समस्याओं में से एक यह है कि अब कोई standardization body नहीं बची है
  • पुराने specifications मौजूद हैं, लेकिन पिछले 20 वर्षों की standardization इस आधार पर हुई कि सबसे popular terminal क्या करता है
  • नतीजतन कई features आपस में मिल गए, और उनके अनुसार कोई भी taste-driven vision को आगे नहीं बढ़ा रहा
  • आगे का रास्ता तय नहीं है; terminal के बजाय नया text-based application space बनाकर legacy apps के लिए terminal translation layer जोड़ने की दिशा भी संभव है

  • User demands और बड़ी vision के बीच संतुलन

    • Hashimoto सार्वजनिक रूप से कहते रहे हैं कि open source maintainers की users के प्रति बाध्यता 0 है
    • Open source license की पहली line “as is, no warranty” होती है, और उनका रुख है कि users को free software मिलता है, इसलिए उन्हें मांग करने का अधिकार नहीं मिलता
    • साथ ही वे अच्छा software बनाना चाहते हैं, इसलिए समस्याएँ ठीक करने और software को बेहतर बनाने की जिम्मेदारी महसूस करते हैं
    • कुछ दिनों वे issues देखकर दूसरों की समस्याएँ ठीक करते हैं, और कुछ दिनों issues, discussions और PRs देखे बिना अपनी पसंद की चीज़ों पर focus करते हैं
    • अगर हर दिन सिर्फ user issues ही संभाले जाएँ, तो software stable लेकिन ठहरा हुआ बन जाता है; और अगर हर PR accept कर लिया जाए, तो software बदलता तो है, पर vision खो देता है
    • उनका कहना है कि अधिकतर contributions किसी व्यक्ति की खास समस्या को scratch करने तक सीमित होते हैं, और उन सबको लेने से code का पहाड़ लग जाता है
    • उलटे, अगर समस्या को गहराई से समझा जाए, तो कई feature requests को एक elegant system से साथ-साथ हल किया जा सकता है
    • Feature design video में उन्होंने 3–4 अलग-अलग feature requests बंद करने और उन्हें एक अलग feature से एक साथ हल करने का उदाहरण दिया

  • Feature-richness और bloat में फर्क

    • Ghostty में सबसे ज्यादा मांगे गए features में से एक search था, जिसे implement करके ship किया गया
    • कुछ users ने कहा कि search Ghostty के minimalism को तोड़ता है और उसे bloated बनाता है, लेकिन Hashimoto ने जवाब दिया कि वे Ghostty को feature-rich terminal के रूप में promote करते हैं
    • वे feature-richness और bloat में फर्क करते हैं
    • Search feature disk space और RAM loading लेता है, लेकिन उसे इस तरह design किया गया है कि इस्तेमाल न करने पर कोई code execute न हो
    • इसलिए उनके अनुसार यह उन users के लिए runtime cost न रखने वाला feature है जो इसे इस्तेमाल नहीं करते
    • Ghostty ऐसा terminal बनना चाहता है जिसे user अपनी जरूरत के मुताबिक customize कर सके, जो default state में भी काम करे, और features को तब तक छिपाए रखे जब तक उनकी जरूरत न हो या उन्हें search न किया जाए
    • Feature removal flag maintain करने की मांग पर उनका मानना है कि maintainer द्वारा वह flag manage करना और user द्वारा feature हटाए हुए fork को maintain करना एक ही तरह की मांग है

Open source के अधिकार, Zig के बदलाव और API quality

  • Hashimoto मानते हैं कि personal forks और maintained forks बहुत ज्यादा होने चाहिए
  • उनके अनुसार venture-backed open source ने ऐसी पीढ़ी बनाई है जो website, paid support staff और Slack/Discord support वाले polished projects की उम्मीद करती है
  • लेकिन open source का मूल product guarantee नहीं, बल्कि freedom और rights हैं
    • अपनी मर्जी से इस्तेमाल करना
    • modify करना
    • fork करना
  • Stability या maintenance obligation उन अधिकारों में शामिल नहीं हैं
  • वे कहते हैं कि security vulnerability लाने वाले commit के लिए सिर्फ maintainer को दोष नहीं दिया जा सकता; user की भी जिम्मेदारी है कि उसने उस commit की review नहीं की
  • अगर stronger guarantees और किसी को दोष देने का अधिकार चाहिए, तो software के लिए भुगतान करके vendor-customer relationship बनाना चाहिए
  • Personal projects में वे ऐसे bugs ठीक करने वाले PR भी merge नहीं कर सकते जिनका सामना वे खुद नहीं करते
    • क्योंकि merge करना उस code को हमेशा maintain करने का वादा है

  • Zig पर रुख

    • Hashimoto को Zig चुनते समय पता था कि वे क्या जोखिम ले रहे हैं, और compiler patches करते हुए उन्होंने community, culture और philosophy को समझा
    • अभी शुरू न हुए I/O changes Zig में सबसे कठिन कामों में से एक होंगे, ऐसा वे मानते हैं
    • Zig की popularity बढ़ रही है, लेकिन Andrew उन changes से पीछे नहीं हटते जिन्हें वे जरूरी मानते हैं, और downstream user के रूप में Hashimoto इसे अच्छा मानते हैं
    • Zig 0.15 ने writer interface बदलकर output करने वाले लगभग हर code को प्रभावित किया, लेकिन उनके अनुसार API खुद काफी बेहतर हुआ
    • Zig compile tools पर focus कर रहा है, और compile speed बढ़ाने के लिए language features हटाए भी गए हैं
    • पूरा lib-ghostty terminal तुरंत build किया जा सकता है, लेकिन उनके अनुसार Andrew उस millisecond-level समय को भी बहुत धीमा मानते हैं
    • Zig 1.0 कभी न कभी आएगा, लेकिन वे मानते हैं कि इसमें अभी कुछ साल बाकी हैं
    • AI language changes से होने वाली downstream pain को कम कर सकता है
    • अलग-अलग contexts में बदलाव करने का तरीका दिखाने के बाद बाकी लागू करवाने पर बड़े diff का करीब 90% अपने आप handle हो गया, ऐसा वे बताते हैं
    • अगर A state से B state तक जाने का तरीका समझाया जा सकता है, तो यह ऐसे भविष्य की ओर इशारा करता है जहाँ backward compatibility का अर्थ कम हो जाता है
    • Zig की strong anti-AI policy के साथ यह ironic है, लेकिन उनके अनुसार AI downstream users को बदलावों से होने वाली तकलीफ को कम करता है

  • Library और API design

    • अच्छी library design के लिए सबसे concrete तरीका है कई communities की बहुत-सी libraries को खुद इस्तेमाल करना
    • जैसे कोई programming languages सीखता है जिन्हें actual काम में नहीं इस्तेमाल करेगा, वैसे ही अलग-अलग ecosystems की libraries इस्तेमाल करने से perspective फैलता है
    • University के दिनों में Prolog, Haskell, Clojure और Java से toy products बनाते हुए उन्होंने हर ecosystem के build systems, usability, libraries, web frameworks, web servers और app servers सीखे
    • उनके अनुसार हर ecosystem की culture libraries और frameworks के separation of concerns और API shape में उतरती है
    • Java में लंबे समय से इस्तेमाल होने वाले builder pattern को Ruby में आजमाकर अच्छा लगने के अनुभव को उन्होंने concept transplantation का उदाहरण बताया
    • Docker ने देखा कि deployment और runtime से जुड़े कई elements development flow में मिल जाते हैं, और Vagrant ने development पर सीधे focus करने वाले nouns, CLI और configuration जानबूझकर इस्तेमाल किए, ऐसा वे कहते हैं

  • Toolmaker’s dilemma और tech stack

    • Hashimoto कहते हैं कि वे जीवन भर toolmaker रहे हैं, और toolmaker’s dilemma में विश्वास करते हैं
    • कोई व्यक्ति किसी समस्या को गहराई से समझकर ideal tool बनाता है, लेकिन जब tool popular हो जाता है, तो वह वास्तविक user के बजाय ground connection खो चुका toolmaker बन जाता है—यह समस्या बार-बार हो सकती है
    • Terminal वे खुद रोज़ इस्तेमाल करते हैं, लेकिन TUI development पर्याप्त नहीं कर पा रहे; वे कई email/IRC clients maintain करने और specs लिखने वाले rockorager जैसे maintainers पर निर्भर हैं
    • मौजूदा tech stack के बारे में उनका रुख बस “ठीक है” जैसा है
    • Frontend, TypeScript और React type community में कई अच्छी बातें हैं, लेकिन बदलाव बहुत ज्यादा हैं, complexity ऊँची है और abstraction layers स्पष्ट नहीं हैं, ऐसा वे मानते हैं
    • वे कहते हैं कि HTTP/1 से HTTP/2 और HTTP/3 तक के बदलावों की तरह कई क्षेत्रों में complexity nonlinear तरीके से बढ़ी है
    • Industry बहुत तेजी से चल रही है और जो चीजें सरल हो सकती थीं उन्हें जटिल बना रही है; AI और उससे जुड़े tools इसे accelerate कर रहे हैं

Principles, culture, quality और learning

  • Hashicorp principles document और Ghostty development style, दोनों Hashimoto के अपने व्यक्तित्व का reflection थे, इसलिए उन्हें रोज़ practice करना आसान था
  • उनका मानना है कि अपने से अलग principles तय करने पर उन्हें New Year resolutions की तरह व्यवहार में लाना मुश्किल होता है
  • Ghostty cross-platform core और native GUI, दोनों को महत्व देता है
    • core cross-platform है
    • GUI में cross-platform पर अड़े रहने के बजाय platform-specific native तरीका पसंद है
  • उनके अनुसार open source projects और internet अलग-अलग tribes के संग्रह होने चाहिए
  • वे नहीं चाहते कि programming languages सबकी चाही हुई features वाली least-common-multiple जैसी चीज़ बन जाएँ; उनके अनुसार constraints creativity और culture बनाते हैं
  • उन्होंने कहा कि Rust की language और philosophy उन्हें पसंद है, लेकिन Rust culture पसंद नहीं है; साथ ही यह अलग किया कि इसका मतलब Rust community के लोग बुरे हैं, ऐसा नहीं है
  • Zig के technology, community management, funding, PR, blog posts और बोलने के तरीके तक स्पष्ट और polarizing positions हैं; Hashimoto कहते हैं कि वे इस अजीबपन का सम्मान करते हैं, इसलिए इसे financial support देते और इस्तेमाल करते रहते हैं
  • Quality के साथ तेजी से release करने के लिए किसी specific customer problem नहीं, बल्कि यह समझना जरूरी है कि user उस problem तक किस context से पहुँचा और upstream problems क्या हैं
  • Enterprise scale पर इसे हल करने का तरीका वे नहीं जानते, लेकिन वे कहते हैं कि वे अपने बनाए software के बड़े user के रूप में judgement करते हैं
  • AI को demos या direction-checking के लिए rough तरीके से इस्तेमाल किया जा सकता है, लेकिन release होने वाला code पढ़कर और समझकर quality के साथ ही निकालना चाहिए
  • C सीखने के सवाल में language से ज्यादा यह समझना जरूरी है कि computer कैसे काम करता है
    • CPU scheduling, memory, cache hierarchy, file system, disk और file access समझना चाहिए
    • C, Zig, Rust जैसी languages में syscall layer के ठीक ऊपर काम करने से समझना आसान होता है कि क्या हो रहा है
    • Python, JavaScript और Ruby की file opening APIs कई details abstract कर देती हैं
    • वे सलाह देते हैं कि standard library functions को भी taken for granted न लें; वे भी किसी ने लिखे code हैं, इसलिए उन्हें खुद पढ़ें और समझें कि वे कैसे काम करते हैं

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

4 टिप्पणियां

 
unsure4000 2 시간 전

लगभग उसी समय पोस्ट हुआ था, लेकिन माहौल इतना अलग है कि मज़ा आ रहा है haha
Bun के Rust rewrite पर मेरे विचार
 
ffdd270 1 시간 전

हाहाहाहाहाहाहाहाहाहाहाहाहाहा
 
GN⁺ 5 시간 전
Lobste.rs की राय

  • शानदार इंटरव्यू था, और सबसे अच्छी लाइन थी: “मैं हर बात से सहमत नहीं हूं, लेकिन खुलकर अजीब होने का मैं सच में सम्मान करता हूं”
    काश ऐसा रवैया और ज्यादा देखने को मिले

  • अगर पूर्व उदाहरणों और टर्मिनल के विकास की बात हो रही है, तो Arcan और cat9 का कम-से-कम जिक्र होना चाहिए
    https://arcan-fe.com/2022/04/…

  • “PowerShell structured data को अच्छी तरह संभालता है” वाले हिस्से से मुझे Jörg W Mittag का यह जवाब याद आया
    typed arguments इस्तेमाल करें तो parsing पूरी तरह PowerShell संभालता है
    Neovim tabs के native window tabs के रूप में साथ-साथ खुलने की कल्पना भी वाकई कमाल है
    C, Zig, Rust की तरह system call layer के ठीक ऊपर काम करने से यह समझने में बहुत मदद मिलती है कि असल में क्या हो रहा है
    मशीन और प्रोग्रामर के बीच की abstractions हटाकर आधारभूत परत तक पहुंचने की प्रक्रिया मजेदार है, और समस्या के मूल के ज्यादा करीब ले जाती है
    standard libraries आमतौर पर portability को लक्ष्य बनाती हैं, इसलिए उनमें operating system features का lowest common denominator शामिल होता है; लेकिन जब आप platform का पूरा फायदा उठा पाते हैं, तो programming कहीं ज्यादा आनंददायक हो जाती है
    standard library functions भी किसी के लिखे हुए code ही हैं, इसलिए उन्हें हल्के में न लें और पढ़कर देखें—इस रवैये के लिए बहुत सम्मान है
    Ghostty के sponsorship program के बारे में भी और जानना चाहूंगा। लगता है इसे non-profit के रूप में incorporate किया गया है, पर यह कितना सफल और self-sustaining है, यह जानने की उत्सुकता है

  • Windows का PowerShell इस परिभाषा के अनुसार पूरी तरह internal होने का फायदा रखता है, लेकिन .NET framework पर बना होने के कारण यह लगभग सभी Windows APIs तक पहुंच सकता है और interoperate कर सकता है, इसलिए व्यवहार में यह बहुत सीमित नहीं है
    UNIX design के हिसाब से external है, और मेरी समझ में Nushell का structured answer सख्ती से internal है, इसलिए उसकी extensibility कम है
    Oils external structured interop के लिए json या अपने extension json8 पर दांव लगाता है, लेकिन PowerShell की तुलना में दोनों काफी सीमित लगते हैं
    सोचता हूं, अगर सब stdout पर सिर्फ msgpack जैसी चीज भेजने पर सहमत हो जाएं और सभी terminals को msgpack viewer बना दें तो कैसा रहे। शायद libc में pipe serialization/deserialization जोड़ने के लिए कोई petition करनी पड़े
    सिर्फ terminal standardization bodies गायब नहीं हुईं; shell की दुनिया में भी production के हिसाब से लगभग कोई innovation नहीं हुआ
    Bash अभी भी वे features जोड़ रहा है जो Kornshell में पहले से थे, Unix shells में ऐसे बहुत से traps हैं जिन्हें हटाना किसी को नहीं आता, और POSIX लगभग हिलता ही नहीं
    मैं अब भी यह सपना पकड़े हुए हूं कि Oils या Nushell प्रमुख distributions में adopt हों और लोग समझें कि इस क्षेत्र में innovation अच्छी चीज है
    फिर भी kitty ने terminal क्षेत्र में साफ तौर पर रास्ता खोला है, और coordination भले कम हो, innovation होने के चरण तक बात पहुंच गई लगती है

  • Mitchell के शांत और संतुलित सकारात्मक-नकारात्मक फैसलों के लिए मेरे मन में बड़ा सम्मान पैदा हुआ
    वे बेहतरीन terminal बनाते हैं और terminal interfaces पसंद करते हैं, लेकिन terminal से सब कुछ करवाने या उसे चरम तक ले जाने से सहमत नहीं हैं
    वे programming languages और communities की गहरी परवाह करते हैं और चाहते हैं कि हर language की अपनी अलग पहचान हो, लेकिन यह भी जानते हैं कि language आखिरकार लक्ष्य पाने का साधन है और बुनियादी समझ ज्यादा महत्वपूर्ण है
    वे मानते हैं कि उन्हें Rust community निजी तौर पर पसंद नहीं है, फिर भी अलग महसूस करने वालों को नीचा नहीं दिखाते
    वे internet को कई tribes के समूह के रूप में देखते हैं, लेकिन tribalism या “एकमात्र सच्ची tribe” खोजने में नहीं फंसते—यह काफी Zen जैसा रवैया प्रभावशाली है

  • इस विचार से सहमत हूं कि और ज्यादा personal/maintenance forks होने चाहिए, लेकिन उन्हें कैसे बढ़ावा दिया जाए यह ठीक से नहीं पता
    entitlement spectrum के निचले छोर पर लोग paid support contracts जैसे enterprise पहलुओं में रुचि नहीं रख सकते; वे बस यह सुविधा चाहते होंगे कि अपने पसंदीदा package manager से वही install कर सकें
    brew install या apt install से cloned repositories और build tools संभालने वाले चरण तक जाने की शुरुआती friction को किसी तरह कम करना होगा
    तेज compiler मदद कर सकता है
    हालांकि security-sensitive software में users का बहुत ज्यादा बदलाव न करना ही उनके हित में हो सकता है, इसलिए कभी-कभी वही friction एक feature भी होती है

  • मैं इस बात से जोरदार सहमत हूं कि आधुनिक UI में n-screen और button specification के बीच की कोई चीज चाहिए
    शायद इसे semantic layer कहना ही काफी हो
    इस layer के होने से agent-type tools, main screen tools, accessibility, composable widgets और controls जैसी चीजें संभव होती हैं
    n-screen और button आखिरकार इस बात की बाईं-दाईं सीमाएं लगते हैं कि कितना content व्यक्त किया जा रहा है
    आदर्श रूप से यह semantic layer multi-cursor, character-level wrapping की जगह word-level wrapping, overlays (z-index, cell blending आदि) जैसी चीजें भी लानी चाहिए