เทอร์มินัลแห่งอนาคต

 (jyn.dev)
8 คะแนน โดย GN⁺ 2025-11-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ชี้ให้เห็นถึง ความซับซ้อนและข้อจำกัดของสถาปัตยกรรมเทอร์มินัลแบบเดิม พร้อมนำเสนอแนวคิดเทอร์มินัลยุคถัดไปที่รวมการป้อนข้อมูล การแสดงผล และการควบคุมโปรเซสเข้าไว้ด้วยกันในรูปแบบใหม่
  • ใช้ Jupyter Notebook เป็นต้นแบบ เพื่อสำรวจความเป็นไปได้ของ อินเทอร์เฟซแบบโต้ตอบ เช่น การเรนเดอร์ภาพ การรันคำสั่งซ้ำ การแก้ไขผลลัพธ์ได้ และเอดิเตอร์แบบฝังในตัว
  • อธิบายอย่างเป็นรูปธรรมผ่านกรณีของ Warp และ iTerm2 ถึง การผสานรวมเชิงลึกระหว่างเชลล์กับเทอร์มินัล (shell integration) การจัดการโปรเซสที่รันยาวนาน และความสามารถในการแยก/กู้คืนเซสชัน
  • วางภาพฟีเจอร์ต่อยอดบนพื้นฐานของ การติดตาม dataflow (dataflow tracking) และ ความคงอยู่ถาวร (persistence) เช่น undo/redo ของคำสั่ง การรันซ้ำอัตโนมัติ และเทอร์มินัลสำหรับการทำงานร่วมกัน
  • เสนอ กลยุทธ์การพัฒนาแบบค่อยเป็นค่อยไป จาก CLI เชิงทรานแซกชัน → เซสชันแบบคงอยู่ → RPC แบบมีโครงสร้าง → ฟรอนต์เอนด์สไตล์ Jupyter

โครงสร้างพื้นฐานของเทอร์มินัล

  • เทอร์มินัลประกอบด้วย 4 ส่วน: terminal emulator, virtual terminal (PTY), shell, และ process group
    • terminal emulator คือโปรแกรมที่ เรนเดอร์โครงสร้างแบบกริด บนหน้าจอ
    • PTY คือสถานะภายในเคอร์เนล ทำหน้าที่ส่งอินพุตไปยัง process group และแปลงสัญญาณ (signal)
    • shell ทำหน้าที่เป็น event loop ที่อ่านและพาร์สอินพุต รวมถึงสร้างโปรเซส
    • โปรเซสต่าง ๆ โต้ตอบกับองค์ประกอบเหล่านี้ผ่านอินพุตและเอาต์พุต
  • อินพุตไม่ได้เป็นเพียงข้อความธรรมดา แต่รวมถึง สัญญาณ (signal) ด้วย ส่วนเอาต์พุตประกอบด้วย ANSI escape sequence ที่ใช้แสดงการจัดรูปแบบ

ภาพของเทอร์มินัลที่ดีกว่า

  • เทอร์มินัลแบบเดิมมีข้อจำกัดด้านฟังก์ชันมาก ทำให้ขาดทั้ง ความสามารถในการขยาย และ ความโต้ตอบ
  • Jupyter Notebook มีฟีเจอร์ที่ terminal emulator แบบ VT100 ดั้งเดิมทำไม่ได้
    • การเรนเดอร์ภาพความละเอียดสูง
    • ปุ่ม “รันใหม่ตั้งแต่ต้น” ที่แทนที่ผลลัพธ์เก่าโดยไม่เติมต่อท้าย
    • “มุมมอง” ที่สามารถเขียนทับทั้งซอร์สโค้ดและผลลัพธ์ได้ในตำแหน่งเดิม (เช่น แสดง Markdown เป็นซอร์สหรือเป็น HTML ที่เรนเดอร์แล้ว)
    • เอดิเตอร์ในตัวที่มี syntax highlighting, tabs, panels และรองรับเมาส์
  • แต่แนวคิด Jupyter Notebook ที่ ใช้เชลล์เป็นเคอร์เนล ก็เจอหลายปัญหา
    • เชลล์รับคำสั่งทีเดียวทั้งก้อน ทำให้ tab completion, syntax highlighting และ autosuggestion ใช้งานไม่ได้
    • ปัญหาการจัดการโปรเซสที่รันนาน: Jupyter โดยพื้นฐานจะรันจนกว่าเซลล์จะเสร็จ สามารถยกเลิกได้ แต่ ไม่สามารถหยุดชั่วคราว ดำเนินต่อ โต้ตอบ หรือดูโปรเซสที่กำลังรันอยู่ได้
    • ปุ่ม “รันเซลล์ใหม่” อาจสร้างปัญหากับสถานะของเครื่อง (โดยเฉพาะเมื่อมีคำสั่งอย่าง rm -rf)
    • การ undo/redo ใช้งานไม่ได้

แล้วมันจะทำงานอย่างไร?

  • การผสานรวมเชลล์ (Shell Integration)

    • เทอร์มินัล Warp สร้าง การผสานรวมแบบเนทีฟ ระหว่างเทอร์มินัลกับเชลล์
      • เทอร์มินัลเข้าใจจุดเริ่มต้นและจุดสิ้นสุดของแต่ละคำสั่ง รวมถึงเอาต์พุตและอินพุตของผู้ใช้
      • ทำได้โดยใช้ฟังก์ชันมาตรฐาน (custom DCS)
    • iTerm2 ก็ใช้แนวทางคล้ายกัน โดยรองรับ OSC 133 escape code
      • ไปยังคำสั่งก่อนหน้า/ถัดไปได้ด้วยคีย์ลัดเดียว
      • แจ้งเตือนเมื่อคำสั่งทำงานเสร็จ
      • ถ้าเอาต์พุตเลื่อนหลุดจอ จะแสดงคำสั่งปัจจุบันเป็น “overlay”
      โฆษณา

  • การจัดการโปรเซสที่รันนาน

    • การโต้ตอบ (interacting) :
      • หากต้องการโต้ตอบกับโปรเซสที่ทำงานนาน จำเป็นต้องมี การสื่อสารสองทาง
        • ตัวอย่าง TUI: top, gdb, vim
        • Jupyter เด่นในด้านการออกแบบ เอาต์พุตแบบโต้ตอบ ที่เปลี่ยนแปลงและอัปเดตได้
      • ฟีเจอร์เทอร์มินัลที่คาดหวัง: มี “free input cell” ให้ใช้งานตลอดเวลา
        • โปรเซสแบบโต้ตอบรันอยู่ด้านบนของหน้าต่าง และมี input cell อยู่ด้านล่าง
    • การหยุดชั่วคราว (suspending) :
      • การ “พัก” โปรเซสเรียกว่า job control
      • เทอร์มินัลยุคใหม่ควรแสดง สถานะของโปรเซสที่ถูกพักและโปรเซสเบื้องหลังแบบต่อเนื่องทางสายตา
        • คล้ายกับที่ IntelliJ แสดง “กำลังทำดัชนี...” ที่แถบงานด้านล่าง
    • การตัดการเชื่อมต่อ (disconnecting) : มี 3 แนวทางสำหรับการแยกและกู้คืนเซสชัน
      • Tmux / Zellij / Screen: แทรก terminal emulator เพิ่มอีกชั้นระหว่าง terminal emulator กับโปรแกรม เซิร์ฟเวอร์เป็นเจ้าของ PTY และเรนเดอร์เอาต์พุต ขณะที่ไคลเอนต์นำเอาต์พุตไปแสดงใน terminal emulator จริง สามารถแยกไคลเอนต์ เชื่อมต่อใหม่ หรือเชื่อมหลายไคลเอนต์พร้อมกันได้ iTerm สามารถทำตัวเป็นไคลเอนต์ของตัวเองโดยข้าม tmux client และสื่อสารกับเซิร์ฟเวอร์โดยตรง
      • Mosh: ทางเลือกแทน SSH รองรับการเชื่อมต่อกลับเข้าสู่เซสชันเทอร์มินัลหลังเครือข่ายหลุด เซิร์ฟเวอร์รัน state machine แล้วเล่นซ้ำความต่างแบบ incremental ของ viewport ไปยังไคลเอนต์ โดยคาดหวังให้ terminal emulator จัดการ multiplexing และ scrollback เอง เนื่องจากไคลเอนต์รันอยู่ฝั่งเครือข่ายจริง การแก้ไขบรรทัดแบบโลคัลจึงตอบสนองได้ทันที
      • alden/shpool/dtach/abduco/diss: จัดการเฉพาะการแยก/กลับมาใช้เซสชันด้วยโมเดลไคลเอนต์/เซิร์ฟเวอร์ ไม่รวมเครือข่ายหรือ scrollback และไม่มี terminal emulator ของตัวเอง จึงมี ระดับการแยกที่สูงกว่า เมื่อเทียบกับ tmux และ mosh
    โฆษณา

  • การรันซ้ำและการย้อนกลับ

    • คำตอบคือ การติดตาม data flow
    • ปัจจุบัน pluto.jl ทำสิ่งนี้ได้โดยเชื่อมเข้ากับคอมไพเลอร์ Julia
      • อัปเดตเซลล์ที่พึ่งพาเซลล์ก่อนหน้าแบบเรียลไทม์
      • หาก dependency ไม่เปลี่ยน ก็จะไม่อัปเดตเซลล์
      • เป็น Jupyter ที่คล้ายสเปรดชีต ซึ่งจะรันโค้ดใหม่เฉพาะเมื่อจำเป็น
    • และสามารถทำให้เป็นทั่วไปมากขึ้นด้วย orthogonal persistence
      • แซนด์บ็อกซ์โปรเซสและติดตาม I/O ทั้งหมด เพื่อป้องกันสิ่งที่ “ประหลาดเกินไป” ตราบใดที่โปรเซสไม่สื่อสารกับโปรเซสอื่นนอกแซนด์บ็อกซ์
      • ทำให้มองโปรเซสได้ว่าเป็นฟังก์ชันบริสุทธิ์ของอินพุต โดยอินพุตคือ “ทั้งระบบไฟล์ ตัวแปรสภาพแวดล้อมทั้งหมด และคุณสมบัติของโปรเซสทั้งหมด”

ฟีเจอร์ที่ต่อยอดได้

  • ต้องมีฟรอนต์เอนด์แบบ Jupyter:
    • Runbooks (จริง ๆ แล้วสร้างได้ด้วยเพียง Jupyter และ PTY primitives)
    • การปรับแต่งเทอร์มินัลด้วย CSS ปกติ โดยไม่ต้องใช้ภาษาปรับแต่งเฉพาะหรือ ANSI color code แปลก ๆ
    • การค้นหาคำสั่งจากเอาต์พุต/เวลา: ตอนนี้ค้นหาได้ทั้งในเอาต์พุตทั้งหมดของเซสชันปัจจุบันหรือในประวัติอินพุตคำสั่งทั้งหมด แต่ยังไม่มี smart filter และเอาต์พุตก็ไม่คงอยู่ข้ามเซสชัน
  • ต้องมีการผสานรวมเชลล์:
    • timestamp และเวลาในการรันของแต่ละคำสั่ง
    • การแก้ไขบรรทัดแบบโลคัลแม้จะข้ามขอบเขตเครือข่าย
    • IntelliSense สำหรับคำสั่งเชลล์โดยไม่ต้องกด Tab พร้อมการเรนเดอร์ที่ผสานอยู่ในเทอร์มินัล
  • ต้องมีการติดตามแซนด์บ็อกซ์:
    • ทุกความสามารถของการติดตามแซนด์บ็อกซ์: เทอร์มินัลแบบทำงานร่วมกัน การค้นหาไฟล์ที่ถูกแก้ไขโดยคำสั่ง asciinema ที่แก้ไขได้ระหว่างรันไทม์ และการติดตาม build system
    • ขยาย smart search ให้ค้นหาได้ตามสถานะดิสก์ ณ เวลาที่คำสั่งถูกรัน
    • ขยาย undo/redo ให้เป็นโมเดลแบบแตกแขนงคล้าย git (emacs undo-tree รองรับแล้ว) พร้อมมุมมองหลายแบบของ process tree
    • ด้วยโมเดล undo-tree และการทำแซนด์บ็อกซ์ ทำให้ สามารถให้ LLM เข้าถึงโปรเจกต์และรันหลายตัวแบบขนานพร้อมกันได้ โดยไม่เขียนทับสถานะของกันและกัน พร้อมตรวจสอบ แก้ไข และบันทึกงานเป็น runbook ไว้ใช้ภายหลัง
    • เทอร์มินัลที่ตรวจสอบได้เฉพาะสถานะเดิม ในสภาพแวดล้อม production โดยไม่กระทบต่อสถานะของเครื่อง

กลยุทธ์การสร้างแบบเป็นขั้นตอน

  • ขั้นที่ 1: semantics แบบทรานแซกชัน (transactional semantics)

    • การเริ่มออกแบบเทอร์มินัลใหม่จาก terminal emulator เป็นแนวทางที่ผิด
      • ผู้ใช้ผูกพันกับ emulator ของตน ทั้งการตั้งค่า รูปลักษณ์ และคีย์ไบน์ดิง
      • ต้นทุนในการเปลี่ยน emulator สูงมาก
      โฆษณา
    • วิธีที่ถูกต้องคือเริ่มจากเลเยอร์ CLI
      • โปรแกรม CLI ติดตั้งและรันง่าย และมี ต้นทุนในการเปลี่ยนต่ำมาก
      • ใช้งานแบบครั้งคราวได้โดยไม่ต้องเปลี่ยนเวิร์กโฟลว์ทั้งหมด
    • เขียน CLI ที่นำ ความหมายเชิงทรานแซกชันสำหรับเทอร์มินัล มาใช้
      • อินเทอร์เฟซอย่าง transaction [start|rollback|commit]
      • ทุกอย่างที่รันหลัง start สามารถย้อนกลับได้
      • แค่นี้ก็อาจสร้างธุรกิจได้ทั้งก้อน

  • ขั้นที่ 2: เซสชันแบบคงอยู่ (Persistent Sessions)

    • หลังมี semantics แบบทรานแซกชันแล้ว ให้ แยกเรื่อง persistence ออกจาก tmux และ mosh
    • หากต้องการ persistence ของ PTY จำเป็นต้องใช้โมเดลไคลเอนต์/เซิร์ฟเวอร์
      • เคอร์เนลคาดว่า PTY ทั้งสองฝั่งจะเชื่อมต่ออยู่ตลอดเวลา
      • สามารถทำอย่างเรียบง่ายโดยใช้คำสั่งอย่าง alden หรือไลบรารีที่คล้ายกัน โดยไม่กระทบ terminal emulator หรือโปรแกรมที่กำลังรันอยู่ในเซสชัน PTY
    • เพื่อให้ได้ scrollback เซิร์ฟเวอร์ต้องเก็บ I/O ไว้ไม่จำกัดและ replay ตอนที่ไคลเอนต์เชื่อมต่อใหม่
      • terminal emulator จะมี native scrollback ที่ปฏิบัติต่อข้อมูลเหล่านี้เหมือนเอาต์พุตทั่วไป
      • สามารถ replay และ resume จากจุดเริ่มใดก็ได้
      • ต้องพาร์ส ANSI escape code แต่เป็นงานที่ทำได้หากลงแรงพอ
    • สำหรับการกลับมาทำงานต่อของเครือข่ายแบบ mosh ให้ใช้ Eternal TCP (และอาจสร้างบน QUIC เพื่อเพิ่มประสิทธิภาพ)
      • แยก persistence ของ PTY ออกจาก persistence ของการเชื่อมต่อเครือข่าย
      • Eternal TCP เป็นเพียงการปรับปรุงประสิทธิภาพ: มันสร้างต่อบน bash script ที่วน ssh host eternal-pty attach ก็ได้
    • ณ จุดนี้จะสามารถ มีหลายไคลเอนต์เชื่อมต่อกับเซสชันเทอร์มินัลเดียวกันได้ แบบ tmux ขณะที่การจัดการหน้าต่างยังคงเป็นหน้าที่ของ terminal emulator
      • หากต้องการการจัดการหน้าต่างแบบรวมศูนย์ terminal emulator อาจใช้โปรโตคอล tmux -CC แบบที่ iTerm ทำ
    • ทุกส่วนของขั้นนี้ทำคู่ขนานกับ semantics แบบทรานแซกชันได้อย่างอิสระ แต่เพียงอย่างเดียวก็ยังไม่พอสำหรับการสร้างธุรกิจ
    โฆษณา

  • ขั้นที่ 3: RPC แบบมีโครงสร้าง

    • อาศัยโมเดลไคลเอนต์/เซิร์ฟเวอร์
    • เมื่อเซิร์ฟเวอร์คั่นอยู่ระหว่าง terminal emulator กับไคลเอนต์ ก็สามารถทำฟีเจอร์อย่าง การติดแท็ก I/O ด้วยเมทาดาทา ได้
      • เพิ่ม timestamp ให้ข้อมูลทุกชิ้นได้
      • แยกอินพุตออกจากเอาต์พุตได้
      • xterm.js ก็ทำงานคล้ายกัน
    • เมื่อรวมกับการผสานรวมเชลล์ ก็สามารถ แยก shell prompt ออกจากเอาต์พุตของโปรแกรมในชั้นข้อมูล ได้
    • ทำให้ได้ structured log ของเซสชันเทอร์มินัล
      • เล่น log ซ้ำเป็น recording แบบ asciinema
      • แปลง shell prompt โดยไม่ต้องรันคำสั่งทั้งหมดใหม่
      • นำเข้าไปยัง Jupyter Notebook หรือ Atuin Desktop
      • บันทึกคำสั่งแล้วรันซ้ำเป็นสคริปต์ภายหลัง
      • เทอร์มินัลกลายเป็นข้อมูล

  • ขั้นที่ 4: ฟรอนต์เอนด์คล้าย Jupyter

    • นี่คือ ขั้นแรกที่แตะ terminal emulator โดยตรง และตั้งใจให้เป็นขั้นสุดท้าย
      • เพราะมีต้นทุนในการเปลี่ยนสูงที่สุด
    • ใช้ประโยชน์จากทุกอย่างที่สร้างมาเพื่อมอบ UI ที่ดี
    • CLI transaction ไม่จำเป็นอีกต่อไป เว้นแต่จะต้องการ nested transaction
      • เพราะทั้งเซสชันเทอร์มินัลเริ่มต้นเป็นทรานแซกชันโดยปริยาย
    • เนื่องจากทุกชิ้นส่วนถูกประกอบเข้าด้วยกันแล้ว จึงสามารถมอบฟีเจอร์ต่อยอดทั้งหมดที่กล่าวถึงข้างต้นได้

บทสรุป

  • สถาปัตยกรรมนี้ถูกมองว่า กล้าหาญ ทะเยอทะยาน และอาจใช้เวลาสร้างครบทั้งหมดนานถึงราว 10 ปี
  • ควรเดินหน้าอย่างอดทนและค่อยเป็นค่อยไปทีละขั้น
  • หวังว่าบทความนี้จะสร้างแรงบันดาลใจให้ใครสักคนเริ่มลงมือสร้างมันด้วยตัวเอง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-11-13
ความคิดเห็นจาก Hacker News

  • อ่านทั้งหมดแล้ว ตอนแรกดูเหมือนเป็นแค่ รายการความอยากแบบ NIH
    ทั้งที่มีทางเลือกหลายอย่างที่สามารถมาแทนเทอร์มินัลได้อยู่แล้ว แต่บทความกลับไม่พูดถึงเลย
    ตัวอย่างเช่น Emacs เป็น VM ที่ใช้ Lisp เป็นฐาน นิยามฟังก์ชันใหม่ได้ง่าย และคำสั่งก็คือฟังก์ชันที่มีคอมเมนต์กำกับอยู่ เอาต์พุตถูกจัดการเป็นบัฟเฟอร์ และสามารถจัดวางหลายหน้าต่างกับหลายเฟรมแบบไทล์ได้ ใช้ CLI เดิมตรงๆ ก็ได้ (vterm, eat เป็นต้น) หรือจะเปลี่ยนไปเป็นโฟลว์แบบ REPL ก็ได้ (shell-mode, eshell เป็นต้น) รองรับกราฟิกด้วย แต่ยังไม่ใช่คอนเท็กซ์ 2D เต็มรูปแบบ
    อีกตัวอย่างคือ Acme ซึ่งคล้าย Emacs แต่เป็น สภาพแวดล้อมข้อความแบบโต้ตอบ ที่ข้อความทุกส่วนสามารถกลายเป็นคำสั่งได้ ส่วน Smalltalk ก็มีแนวคิดคล้ายกัน แต่ใกล้เคียง IDE มากกว่า

    • ใน Emacs มี Org-mode และ org-babel ที่ทำงานได้คล้าย Jupyter notebook แถมยังสื่อสารกับ Jupyter kernel ได้ด้วย
      ฉันใช้ GPTel ใน Emacs เพื่อตัดหน้า PDF ตำราภาษาละตินเก่าๆ แบบอัตโนมัติ แล้วแปลงผ่าน OCR ให้อยู่ในรูปแบบ org-mode ผลคือ พอเลือกคำก็เปิดพจนานุกรมได้ทันที และพอเลือกประโยค LLM ก็ช่วยวิเคราะห์ไวยากรณ์ให้ เท่ากับว่า text editor จากยุค 1970 กลายเป็น แพลตฟอร์มการเรียนรู้แห่งอนาคต ไปแล้ว
    • อยากรู้เรื่อง Acme เพิ่มเติม ค้นหายากมาก
      แพลตฟอร์มอย่าง Emacs, Jupyter, VSCode ทรงพลังมาก แต่ก็เป็นแพลตฟอร์มที่เน้นการคัสตอมมากกว่าจะเป็น แอปพลิเคชัน ที่เสร็จสมบูรณ์
      ถ้าจะเป็นนวัตกรรมจริง ก็ควรแจกจ่ายให้อยู่ในรูปที่ทำซ้ำได้ง่าย เช่น คอนเทนเนอร์ Docker หรือไฟล์รันได้ แทนการตั้งค่าซับซ้อน
    • ฉันคิดว่าใจความสำคัญของบทความคือการ เปิด data model ของเทอร์มินัล และจุดสำคัญคือเราสามารถสร้างความสามารถหลากหลายทับบนมันได้
    • สิ่งที่ไม่เหมือนใครของ Emacs คือ ความเป็นอิสระจาก UI แอปที่เขียนด้วย Elisp ทำงานได้เหมือนกันทั้งในเทอร์มินัลและ GUI เมื่อ 20 ปีก่อนฉันก็เขียน Elisp ในเทอร์มินัลอยู่แล้ว แต่ผู้ใช้ GUI แทบไม่รู้สึกถึงความต่างเลย แพลตฟอร์มแบบนี้ไม่มีที่อื่น

  • ยังสงสัยว่าแนวคิดถัดไปของเทอร์มินัลจำเป็นต้อง อิงข้อความ หรือเปล่า
    เทอร์มินัลแห่งอนาคตอาจอยู่ในรูป API และอาจถูกเรียกจากระยะไกลผ่านการยืนยันตัวตนด้วย OAuth ก็ได้ อินพุตและเอาต์พุตอาจไม่ใช่ข้อความแบบ CLI อีกต่อไป
    เราอาจเปลี่ยนไปใช้ อินพุต/เอาต์พุตแบบอิงอ็อบเจ็กต์ ทำให้ทั้งคำสั่งและโครงสร้างข้อมูลสามารถสำรวจผ่าน API ได้
    เทอร์มินัลเป็นมรดกจากยุค 70 และทุกวันนี้ก็มีทางเลือกที่ดีกว่าเกิดขึ้นได้มากมาย

    • จริงๆ แล้วเทอร์มินัลไม่ได้มีศูนย์กลางอยู่ที่ข้อความ แต่เป็น สตรีมโทเค็นสองทิศทาง ความเรียบง่ายนี้เองที่ทำให้การประกอบแบบ Unix เป็นไปได้
      ถ้าเพิ่มเอาต์พุตแบบ JSON ก็สามารถประกอบ pipeline ด้วยเครื่องมืออย่าง jq ได้
      มันวิวัฒน์มาได้หลายทศวรรษเพราะข้อดีของปรัชญา “worse is better” ที่ยอมรับความเรียบง่าย
    • ฉันก็เห็นด้วยกับ ข้อจำกัดของ standard input/output ใน CLI ข้อมูลกับการแสดงผลเป็นสิ่งเดียวกัน ทำให้ความสามารถในการประกอบต่อถูกจำกัด
      ถ้าส่งผ่าน อ็อบเจ็กต์ที่อธิบายตัวเองได้ แบบ PowerShell ก็จะประกอบกันได้ทรงพลังขึ้นมาก
      มีตัวอย่างที่เกี่ยวข้องสรุปไว้ในบล็อกโพสต์ของฉัน
    • PowerShell น่าสนใจ แต่ก็มีข้อเสียตรงที่มันค่อยๆ เข้าใกล้ความเป็นภาษาโปรแกรม มากขึ้น
      โฟลว์ที่เข้าใจง่ายแบบอิงคำสั่งหายไป และต้องจำโครงสร้าง API
      ถ้ามีระบบเติมคำอัตโนมัติด้วย AI และฟีเจอร์สำรวจโครงสร้างอ็อบเจ็กต์ ก็น่าจะช่วยลดจุดอ่อนนี้ได้
    • ฉันก็ใช้ Nushell บ่อยและชอบมาก มันสะอาดกว่า PowerShell และไม่ผูกกับ Microsoft
      https://www.nushell.sh/
    • ทางเลือกแทนเทอร์มินัลแบบไม่อิงข้อความมีอยู่แล้ว
      แต่เทอร์มินัลแบบอิงข้อความที่พัฒนาต่อไปได้ก็ยังน่าสนใจ ถ้ามี ข้อเสนอที่เป็นรูปธรรมและจินตนาการตามได้

  • เหตุผลที่เทอร์มินัลยังอยู่รอดมาจนถึงตอนนี้คือ ความเข้ากันได้ย้อนหลังและความสามารถในการทำงานอัตโนมัติ
    มันเขียนสคริปต์ได้ง่ายกว่า GUI และทุกอย่างก็ ทำซ้ำได้ กับ ค้นหาได้
    เมื่อก่อนฉันเคยรำคาญการสลับ alt-screen ของ Neovim แต่รายละเอียด UX เล็กๆ แบบนี้ก็สำคัญ
    ตอนที่ฉันได้ใช้คอมพิวเตอร์ครั้งแรก และตอนที่ได้เรียนรู้เทอร์มินัล ฉันตกหลุมรักมันอยู่สองครั้ง

  • โปรเจ็กต์ที่เกี่ยวข้องมีเช่น

    • Arcan — เสนอโปรโตคอลแบบใหม่สำหรับแอปพลิเคชัน TUI
    • Shelter — เชลล์ไฟล์ซิสเต็มที่แตก branch ได้เหมือน Git
    • Shelter ต้องอาศัย snapshot ของไฟล์ซิสเต็ม แต่เป็นไอเดียที่เจ๋งมาก
    • ฉันคิดว่าบทความที่ไม่พูดถึง Arcan ถือว่ายังไม่ครบ เพราะมันใช้งานได้แล้ว
      • เพิ่งเคยได้ยินครั้งแรก แต่น่าสนใจมาก ขอบคุณสำหรับลิงก์

  • เมื่อ 18 เดือนก่อน ฉันเคยลองทำการทดลองคล้ายๆ กันใน Windows Terminal
    มีบันทึกไว้ในคอมเมนต์บน GitHub
    แต่หลังจากได้ลองใช้ Polyglot Notebooks แล้ว ก็ย้ายไปใช้สิ่งนั้นเพราะมันเป็นธรรมชาติกว่ามาก
    การเปลี่ยนแบ็กเอนด์เชิงคำสั่งให้เป็น Jupyter kernel แล้วใช้งานเป็น เอกสารแบบโต้ตอบสไตล์โน้ตบุ๊ก มีประสิทธิภาพกว่ามาก

    • ฉันก็กำลังมองหาระบบแบบนี้อยู่ คิดว่าน่าจะเหมาะกับ LLM หรือสภาพแวดล้อมการทำงานส่วนตัวมากกว่า
    • การใส่แนวคิดแบบโน้ตบุ๊กเข้าไปใน Windows Terminal เป็นไอเดียที่เจ๋งจริงๆ อยากให้มีความพยายามแบบนี้มากขึ้น

  • ก่อนหน้านี้ฉันเคยทำโปรเจ็กต์ชื่อ TopShell เป็นเชลล์+เทอร์มินัลที่อิงการเขียนโปรแกรมเชิงฟังก์ชัน
    https://github.com/topshell-language/topshell#readme
    มันมีศักยภาพ แต่ยังต้องทำอีกมากกว่าจะเป็นทางเลือกเต็มรูปแบบได้

  • ฉันเคยมองหาเทอร์มินัลที่แสดงภาพหรือวิดีโอได้
    ถ้ามีเทอร์มินัลที่ทำงานเหมือนเบราว์เซอร์ได้เลยก็คงดี
    เช่นสั่ง browser google.com/maps แล้วเปิดแบบโต้ตอบได้ทันที

    • แต่ความสามารถแบบนี้ควรเป็นหน้าที่ของ โปรแกรมแยกต่างหาก (fbi, omxplayer เป็นต้น) มากกว่าเทอร์มินัลเอง

  • นี่คือข้อเสนอให้ขยาย pseudo-terminal (PTY) โดยเพิ่ม ช่องทาง out-of-band ที่อิง JSON-RPC
    escape sequence แบบเดิมมีข้อจำกัดเยอะ
    ถ้าใช้วิธีนี้ก็จะค่อยๆ เปลี่ยนผ่านได้แบบ เข้ากันได้ย้อนหลัง
    มันสามารถต่อรองความสามารถกันได้เหมือน LSP หรือ MCP และเคอร์เนลก็แค่ต้องมีช่องทางนี้ให้

    • JSON ไม่เหมาะกับงานแบบนี้ ฟอร์แมตไบนารี อย่าง DER หรือ SDSER มีประสิทธิภาพกว่า
    • แนวทางสมัยใหม่คือส่งข้อความสำหรับผู้ใช้ไปที่ stderr และส่ง JSON ที่เป็นมิตรกับเครื่อง ไปที่ stdout
      แบบนี้ pipeline กับการ redirect ก็ยังทำงานเหมือนเดิม และยังคงเอาต์พุตสีไว้ได้