ใน Emacs ทุกอย่างดูเหมือนบริการ

• Emacs ไม่ได้เป็นตัวระบบปฏิบัติการเอง แต่ทำหน้าที่ ประสานแอปพลิเคชันและยูทิลิตีบนเคอร์เนล พร้อมใช้ระบบไฟล์ เครือข่าย และโปรแกรมภายนอกเพื่อเป็นไคลเอนต์ของบริการหลากหลายรูปแบบ
• สามารถประกอบ UI, ชั้นการสื่อสาร และที่เก็บข้อมูลภายในเครื่อง ที่ไคลเอนต์ต้องใช้ได้ด้วยไลบรารีที่มีมาในตัว เช่น minibuffer, buffer, URL, TCP/UDP, JSON และ SQLite
• Emacs Lisp (Elisp) ซึ่งเป็นภาษาที่มีความเป็นไดนามิก สามารถผสานฟังก์ชัน Elisp กับคำสั่งเชลล์ระหว่างรันไทม์ เพื่อประสานความสามารถต่าง ๆ ที่ Emacs เข้าถึงได้อย่างยืดหยุ่น
• ตัวอย่างคำสั่ง wttr จะรับตำแหน่งที่ตั้ง ส่งคำขอ HTTP ไปยัง wttr.in ดึงข้อมูลภูมิภาค อุณหภูมิ และสภาพอากาศจาก JSON มาแสดงใน minibuffer และบันทึกลง kill ring ด้วย
• wttr.el ทั้งไฟล์มีเพียง 67 บรรทัด ตามการวัดของ cloc และถ้ามอบหมายการเรียกเครือข่ายกับการจัดการ JSON ให้เครื่องมือบรรทัดคำสั่งอย่าง Python ก็ยังสร้างไคลเอนต์ Elisp ที่สั้นกว่านั้นได้ โดยถือให้คำสั่งเชลล์เป็นบริการตัวหนึ่ง

---

Emacs ที่ประสานบริการอยู่เหนือระบบปฏิบัติการ

• การเรียก Emacs ว่าเป็นระบบปฏิบัติการอาจไม่แม่นยำนัก แต่การเปรียบเทียบนี้เกิดขึ้นเพราะความสามารถในการ ประสานแอปพลิเคชันและยูทิลิตีบนเคอร์เนลของระบบปฏิบัติการ
• มันเข้าถึงบริการของระบบปฏิบัติการอย่างระบบไฟล์และเครือข่ายผ่านความสามารถที่มีมาในตัว และยังเรียกใช้โปรแกรมอื่นได้ จึงประกอบพฤติกรรมแบบไคลเอนต์ขึ้นมาใน Emacs ได้อย่างรวดเร็ว
• เพราะจัดการงานคอมพิวติ้งได้มากมายผ่านโหมดไคลเอนต์หลายแบบ แนวคิดที่ว่าผู้ใช้ “ใช้ชีวิตอยู่แค่ใน Emacs” จึงพอฟังขึ้น

โมเดลไคลเอนต์-เซิร์ฟเวอร์ในมุมของคำขอและคำตอบ

• โมเดลไคลเอนต์-เซิร์ฟเวอร์ คือรูปแบบปฏิสัมพันธ์ที่แบ่งงานระหว่าง บริการ ที่ให้ทรัพยากร กับ ไคลเอนต์ ที่ร้องขอทรัพยากรนั้น
  • ไคลเอนต์ส่งคำขอ
  • เซิร์ฟเวอร์ประมวลผลคำขอแล้วส่งคำตอบกลับ
• ธุรกรรมที่ประกอบด้วยคำขอและคำตอบนี้อาจเกิดผ่านเครือข่ายหรือทำแบบภายในเครื่องเดียวกันก็ได้
• โมเดลแบบเครือข่ายถูกพัฒนาต่ออย่างกว้างขวางใน สถาปัตยกรรมซอฟต์แวร์สไตล์ REST

สามส่วนที่ประกอบเป็นไคลเอนต์ใน Emacs

• โดยทั่วไปไคลเอนต์จะรับผิดชอบสามส่วนต่อไปนี้
  • UI: จัดการอินพุตและเอาต์พุตของผู้ใช้ตามความจำเป็น
  • ขอบเขตไคลเอนต์ (Client Edge): สื่อสารกับบริการ โดยในไคลเอนต์เครือข่าย ระบบย่อยด้านเครือข่ายจะทำหน้าที่นี้
  • ฐานข้อมูลภายในเครื่อง: ใช้แทนข้อมูลที่จะแลกเปลี่ยนหรือซิงก์กับเซิร์ฟเวอร์ ซึ่งวิธีจัดการขึ้นอยู่กับความต้องการของการใช้งาน

• การประกอบส่วนติดต่อผู้ใช้

  • Emacs มีความสามารถในตัวหลายอย่างสำหรับสร้าง UI ของไคลเอนต์
  • Minibuffers
  • Buffers
  • Completion
  • Tabulated List Mode
  • Variable Pitch Table(vtable)
  • Transient

• การสื่อสารกับบริการและการแปลงข้อมูล

  • สำหรับ ขอบเขตไคลเอนต์ ที่เชื่อมต่อกับบริการ สามารถใช้ความสามารถต่อไปนี้ได้
    • URL
    • Socket(TCP/UDP)
    • SMTP
  • การ serialize และ deserialize ข้อมูล ใช้ parser ที่มีมาในตัว
    • JSON
    • XML

• การจัดการข้อมูลภายในเครื่อง

  • สำหรับตัวแทนข้อมูลของเซิร์ฟเวอร์ในเครื่อง สามารถใช้ collection ของ Elisp ได้
    • Association Lists
    • Property Lists
    • Hash Tables
  • หากต้องการที่เก็บข้อมูลถาวรในเครื่อง สามารถใช้ SQLite
  • ความซับซ้อนของไคลเอนต์จริงขึ้นอยู่กับความต้องการ และถ้ามียูทิลิตีบรรทัดคำสั่งเดิมที่จัดการงานหนักได้อยู่แล้ว ก็สามารถจัดวางใหม่ให้เป็น บริการที่เข้าถึงผ่านการเรียกเชลล์ ได้

วิธีผสานความสามารถด้วย Elisp

• ไลบรารีทั้งหมดข้างต้นเข้าถึงได้จาก Emacs Lisp (Elisp)
• Elisp เป็น ภาษาโปรแกรมแบบไดนามิก ที่เปิดให้ประกอบสิ่งต่าง ๆ ระดับสูงได้อย่างยืดหยุ่นระหว่างการทำงาน
• สามารถผสานพฤติกรรมที่ Emacs ใช้งานได้ ตั้งแต่ฟังก์ชัน Elisp ไปจนถึงคำสั่งเชลล์ เพื่อประสานลำดับการทำงานที่ซับซ้อน

การสร้างไคลเอนต์สภาพอากาศ wttr.in

• wttr.in คือเว็บบริการพยากรณ์อากาศที่เน้นคอนโซล และรองรับ เอาต์พุตแบบ JSON
• คำสั่ง wttr สำหรับ Emacs ทำงานตามลำดับดังนี้
  1. รับตำแหน่งที่ตั้งจากผู้ใช้
  2. สร้าง URL สำหรับร้องขอไปยัง wttr.in
  3. ส่งคำขอ HTTP
  4. ประมวลผลคำตอบแบบ JSON
  5. แสดงผลใน minibuffer และบันทึกลง kill ring
  6. หากเกิดข้อผิดพลาดระหว่างประมวลผล จะแสดงข้อความผิดพลาดใน minibuffer

• การสร้าง URL สำหรับคำขอ

  • wttr--request-url ใช้ https://wttr.in เป็น URL พื้นฐาน
  • จะแทนช่องว่างในตำแหน่งที่ตั้งด้วย + และสร้าง query ในรูป /<location>?0&format=j1
  • URL ที่ได้จะถูกส่งต่อไปยัง ฟังก์ชันดึง JSON

• คำขอ HTTP และการ parse JSON

  • fetch-json-as-hash-table ดึง URL แบบ synchronous ด้วย url-retrieve-synchronously
  • หากไม่ได้รับข้อมูล จะโยนข้อผิดพลาด Failed to fetch data from <URL>
  • จากนั้นจะเลื่อนไปหลัง HTTP metadata header ใน response buffer แล้วใช้ json-parse-buffer แปลงเนื้อหาที่เหลือเป็น hash-table ของ Elisp
  • เมื่อประมวลผลเสร็จ จะลบ network buffer ที่ดาวน์โหลดมาออกเสมอเพื่อป้องกัน memory leak

• การประกอบข้อความรายงานสภาพอากาศ

  • wttr--report-message ดึงค่าต่อไปนี้ออกมาจากข้อมูล JSON
    • ชื่อพื้นที่ที่ใกล้ที่สุด
    • ภูมิภาค
    • ประเทศ
    • อุณหภูมิเซลเซียสปัจจุบัน temp_C
    • อุณหภูมิฟาเรนไฮต์ปัจจุบัน temp_F
    • คำอธิบายสภาพอากาศ weatherDesc
  • จากนั้นจะนำองค์ประกอบตำแหน่งที่ไม่ว่างมาเชื่อมด้วยจุลภาค และสร้างผลลัพธ์ในรูป ตำแหน่ง: เซลเซียส, ฟาเรนไฮต์ คำอธิบายสภาพอากาศ
  • ดูการติดตั้งใช้งานทั้งหมดได้ใน ซอร์ส wttr.el

ใช้เครื่องมือบรรทัดคำสั่งเป็นบริการได้เช่นกัน

• API ของ Emacs ให้ abstraction ในระดับสูง และ wttr.el ที่เขียนคำขอ HTTP กับการจัดการ JSON เองก็มีเพียง 67 บรรทัด ตามการวัดของ cloc
• ทางเลือกที่ง่ายกว่าคือย้ายงานร้องขอเครือข่ายและจัดการ JSON จริงไปให้สคริปต์ Python ชื่อ weather
  • คำสั่ง weather ฝั่ง Elisp รับตำแหน่งที่ตั้งจากผู้ใช้
  • ประกอบคำสั่งเชลล์ weather โดยใส่ตำแหน่งที่ตั้งเป็นอาร์กิวเมนต์
  • รันคำสั่งด้วย shell-command-to-string
  • บันทึกผลลัพธ์ที่ได้ลง kill ring และแสดงใน minibuffer
• ในโครงสร้างนี้ คำสั่งเชลล์คือบริการที่รับคำขอ และฟังก์ชัน Elisp ทำหน้าที่เป็นไคลเอนต์
• ด้วยธรรมชาติแบบไดนามิกของ Elisp จึงสามารถผสานไลบรารี Elisp และยูทิลิตีบรรทัดคำสั่งเข้าด้วยกันได้ตามต้องการ และความสามารถในการบูรณาการแบบนี้เองที่ทำให้ทุกอย่างใน Emacs ถูกมองเหมือนเป็นบริการได้

[GN⁺]

ความคิดเห็นจาก Hacker News

• ที่ Emacs ดูเหมือนระบบปฏิบัติการก็เพราะตระกูล Lisp Machine ไม่ได้กลายเป็นกระแสหลัก
  “Symbolics Lisp Machine demo”
  https://www.youtube.com/watch?v=o4-YnLpLgtk
  “Emacs and Lisp”
  https://funcall.blogspot.com/2025/04/emacs-and-lisp.html
  Lucid เคยฟอร์ก Emacs เป็น XEmacs เพื่อพยายามทำให้แนวคิด LSP ยุคแรก ๆ เป็นจริง และความสามารถส่วนใหญ่ในตอนนั้นก็ถูกรวมกลับเข้า Emacs แล้วในปัจจุบัน
  https://dreamsongs.com/Cadillac.html
  “Lucid Energize Demo”
  https://www.youtube.com/watch?v=pQQTScuApWk

  • ระบบปฏิบัติการคือ เครื่องเสมือน ที่สร้างขึ้นเพื่อให้หลายโปรแกรมใช้งานร่วมกัน โดยปกติจะเปิดเผยสถาปัตยกรรมชุดคำสั่ง (ISA) ส่วนใหญ่ที่มันรันอยู่ แม้จะมีข้อยกเว้นอย่าง Inferno, Taos และ AS/400
  • ต่อให้ LISP machine ประสบความสำเร็จ ตัวแก้ไขข้อความที่รันอยู่บนนั้นก็ไม่ได้กลายเป็นระบบปฏิบัติการ การสับสนระหว่างแพลตฟอร์มกับระบบปฏิบัติการทำให้สุดท้ายเราอาจเรียกเว็บเบราว์เซอร์หรือแม้แต่ Roblox ว่าเป็นระบบปฏิบัติการได้

• ถ้านิยาม client, server, request ให้กว้างพอ ก็จับอะไรก็ได้มายัดเป็น สถาปัตยกรรมไคลเอนต์/เซิร์ฟเวอร์ คล้ายกับที่เคยมีคนพยายามอธิบายว่า Emacs ทำตามปรัชญา Unix เพียงเพราะฟังก์ชัน LISP ทำงานอย่างหนึ่งได้ดี
  คนส่วนใหญ่น่าจะพอเห็นด้วยว่า Emacs รับแนวคิดมาจาก Lisp machine และบนมันแทบจะสร้างอะไรก็ได้ตามต้องการ มันเชื่อมกับเครื่องมือ CLI ได้ดีมาก แต่ก็ยังไม่ชัดว่าการนิยามสิ่งนี้ว่าเป็นไคลเอนต์/เซิร์ฟเวอร์ช่วยอะไร
  มันดูดซับฟีเจอร์ตามกระแสนิยมมาหลายสิบปี และข้างในยังมี CEDET semantic analysis engine ที่ตอนนี้แทบไม่มีใครใช้แล้ว ต่อมาก็มี LSP โผล่มา และตอนนี้เข้าสู่ยุคเอเจนต์ ซึ่ง Emacs ก็เป็นฟรอนต์เอนด์สำหรับเอเจนต์ได้ดีพอสมควร

  • Emacs คือ ผู้ลี้ภัยจาก LISP ที่หนีมาอยู่ในโลก Unix มันไม่ได้เดินตามปรัชญา Unix แต่ตามปรัชญา LISP และก็ผสานกับ Unix ได้ดี
  • สมัยก่อน IDE ส่วนใหญ่มี semantic analysis engine ของตัวเองเป็นเรื่องปกติ เท่าที่จำได้ language server ตัวแรกของ Java ก็ถูกแยกออกมาจาก semantic analysis engine ของ Java ใน Eclipse

• ใช้ Emacs มานานกว่า 25 ปี แต่บริษัทที่ย้ายไปเมื่อปีที่แล้วไม่ยอมให้ใช้ แม้แต่งานที่ Emacs เหมาะมาก โดยให้เหตุผลว่าทุกคนในทีมต้องใช้เครื่องมือเดียวกัน และก็ไม่สามารถเปลี่ยนคนอื่นให้มาใช้ Emacs ได้
  ตอนนี้เลยต้องใช้ เครื่องมือเฉพาะทางแบบงานเดียวจบ แยกกันไปในแต่ละงานอย่างไม่มีประสิทธิภาพ แถมยังต้องเรียนรู้ UI และการแมปปุ่มใหม่ ๆ อยู่เรื่อย ๆ

  • พอบริษัทใหญ่ขึ้นก็เริ่มควบคุมซอฟต์แวร์ที่ติดตั้ง และดูเหมือนจะใช้ Microsoft Intune จัดการว่าอะไรอนุญาตหรือห้ามติดตั้ง เลยชะลอการอัปเดตหรือเปลี่ยนโน้ตบุ๊ก เพราะกลัวว่าจะใช้ Emacs ต่อไม่ได้
    ผู้จัดการคงจะบอกว่าโปรเจ็กต์ใหม่ต้องใช้ Visual Studio Code ทั้งหมด แต่โมเดลการใช้งานที่เราใช้กันอยู่ VSCode ก็ยังไม่รองรับ จริง ๆ แล้วถ้าขั้นตอน Git กับการ deploy ตรงกัน แต่ละคนก็ควรเลือก editor ที่ตัวเองถนัดได้ ทว่าคำตอบที่น่าจะได้กลับมาคือ Microsoft ไม่รองรับ มันเป็นโอเพนซอร์สที่เสี่ยง และเป็นซอฟต์แวร์ที่บริษัทยังไม่ได้ตรวจสอบ
    Emacs เป็นเครื่องมือหลักที่ใช้ทุกวัน ถ้าถูกห้ามใช้ก็คงลาออก ผู้จัดการไม่ได้พยายามจะเข้าใจหรือใช้เหตุผล แค่ทำตามคำสั่งจากแผนก IT อื่นเท่านั้น
  • ถ้าบริษัทบังคับให้ทุกคนใช้ telnet และห้าม ssh จะถือว่าสมเหตุสมผลหรือ? สิ่งสำคัญคือ อย่าถามขออนุญาตใช้ Emacs แค่ใช้มันไปเลย
    ถ้าบริษัทระบุเพียง text editor ทั่วไป การเปิด Notepad จะมีปัญหาด้วยหรือไม่ หรือบริษัทกำหนดแม้แต่เครื่องมือจัดการงานส่วนตัวหรือเปล่า ลองหาหมวดงานที่ Emacs ทำได้แต่บริษัทยังไม่ได้กำหนดเครื่องมือ แล้วติดตั้งเพื่อใช้ในจุดนั้น
  • เหตุผลแบบนี้ก็ไม่ต่างจากการบอกว่า การจัดการคนที่มีนิสัยต่างกันต้องปฏิบัติต่อแต่ละคนไม่เหมือนกันซึ่งไม่มีประสิทธิภาพ เลยจัด ผ่าตัดสมองส่วนหน้า ให้ทุกคนในทีมแทน
  • ถ้าเครื่องมืออื่นมี อิสระและการดัดแปลงได้ เท่า Emacs ผู้ใช้ Emacs ก็คงไม่พยายามยัดทุกอย่างเข้าไปไว้ในนั้น Emacs ไม่ได้เหนือกว่าโดยอัตโนมัติ แต่เป็นเพราะเครื่องมืออื่นจำกัดมากกว่าและมีเอกสารในตัวน้อยกว่า
  • ยังสงสัยว่าทำไมแนวคิดที่ว่าทุกคนในทีมต้องใช้เครื่องมือเดียวกันถึงถือว่าสมเหตุสมผล

• Emacs คือ แพลตฟอร์ม และระบบปฏิบัติการเองก็เป็นเพียงหนึ่งในหลายแพลตฟอร์ม แพลตฟอร์มคือชั้นซอฟต์แวร์ที่ถูกออกแบบมาเพื่อให้สร้างสิ่งใหม่บนมันได้ ดังนั้นคำถามคือ แพลตฟอร์ม X เหมาะกับการสร้าง Y ที่ต้องการหรือไม่
  สำหรับผม X มักเป็น Emacs แต่บางครั้งก็อาจเป็น Racket หรือ Rust ถ้าเป็นเครื่องมือที่ทั้งเป็นแอปพลิเคชันและเป็นแพลตฟอร์มที่ดีด้วย ก็คุ้มค่าที่จะลงทุนเรียนรู้มากกว่าแอปธรรมดา

• การใช้ Emacs มากพอจนเข้าใจคำว่า “Emacs คือระบบปฏิบัติการ” แบบไม่ใช่มุก แต่เป็นแนวคิดที่เชื่อได้จริง กลายเป็นจุดเปลี่ยนสำคัญในอาชีพ

  • ก็มีระบบปฏิบัติการอยู่แล้วและเขียนโปรแกรมได้อยู่แล้ว จึงยังสงสัยว่า Emacs มอบความสามารถใหม่จริงหรือไม่ Emacs เป็น text editor ไม่ใช่ IDE หรือสภาพแวดล้อมรันงานอัตโนมัติอเนกประสงค์ และก็ยากจะเข้าใจตรรกะที่ว่าถ้าเพิ่ม Lisp ให้ MSPaint แล้วมันจะกลายเป็นเครื่องมือมหัศจรรย์ขึ้นมาทันที

• เริ่มใช้ Emacs เมื่อหลายปีก่อนเพราะอยากลอง org mode และก็ใช้ต่อมาเรื่อย ๆ เพราะมันยืดหยุ่นสูงแบบสุดโต่ง

  • เคยใช้ Spacemacs อยู่พักหนึ่ง แต่ตอนนี้ได้ Keychron G6 Pro ที่รีโปรแกรม Caps Lock ได้แล้ว เลยคิดว่าจะเริ่มจัด init.el ของตัวเองอย่างจริงจัง

• Emacs ใกล้เคียงกับ สภาพแวดล้อมการเขียนโปรแกรม ที่มี text editor ฝังมาด้วยมากกว่า ถ้ามองว่าคล้าย Smalltalk image บางแบบก็จะเป็นเครื่องมือที่น่าสนใจมาก

• Emacs ไม่ใช่ระบบปฏิบัติการ แต่ใกล้กับ เชลล์ มากกว่า เพียงแต่แนวคิดเรื่องเชลล์เองก็ไม่ได้เป็นที่เข้าใจกันอย่างแพร่หลาย

  • ถ้ามองเชลล์ว่าเป็นวิธีใช้เครื่องมืออื่น vi อาจใกล้กับเชลล์มากกว่า เพราะต้องพึ่ง :.! เพื่อโยนงานจำนวนมากให้โปรแกรม Unix มาตรฐานตัวอื่นทำ
    ในทางกลับกัน Emacs กลับรวมความสามารถสารพัดไว้เหมือนระบบปฏิบัติการในดิสทริบิวชันขนาดใหญ่เพียงชุดเดียว

• เพิ่งเจอ วิดีโอแนะนำสั้น ๆ ที่เหมาะจะเอาไปให้คนที่ไม่ใช้ Emacs ดู
  https://www.youtube.com/watch?v=mJZDmO5yOxE

  • ชักอยากรู้ init.el ของ Anon Emoose จริง ๆ

• ตัว Emacs เองก็รันแบบ ไคลเอนต์และเซิร์ฟเวอร์ ได้ โดยเริ่มเซิร์ฟเวอร์ด้วย emacs --daemon แล้วเชื่อมผ่าน emacsclient จากนั้นทุกอินสแตนซ์ทั้งแบบเทอร์มินัลและ GUI จะใช้เซิร์ฟเวอร์เดียวกันและแชร์ไฟล์กับบัฟเฟอร์ที่เปิดอยู่
  น่าเสียดายที่มันทำงานได้แค่ในเครื่องโลคัล และแม้จะพยายามส่งต่อ Emacs server socket ผ่าน ssh เพื่อให้ไคลเอนต์ระยะไกลมาเชื่อมต่อ ก็ไม่สำเร็จ

  • พอมาย้อนคิด ชื่อ emacsclient ก็ไม่ค่อยดีนัก คนที่เพิ่งมาเจอ Emacs ครั้งแรกในปี 2026 อาจคาดหวังว่ามันจะซิงก์สถานะการทำงานของไคลเอนต์กับเซิร์ฟเวอร์ผ่านเครือข่ายเหมือน REST client
    แต่ในที่นี้ไคลเอนต์กับเซิร์ฟเวอร์หมายถึงโครงสร้างบน Unix local domain หรือก็คือ file system socket ที่ไคลเอนต์ส่งคำสั่งควบคุมง่าย ๆ ไปให้ หลังจากนั้นแม้จะรองรับ network socket เพิ่มแล้ว สิ่งที่ไคลเอนต์ส่งก็ยังเป็นเพียงคำสั่งควบคุมพื้นฐานเท่านั้น
  • แม้จะส่งต่อ socket ไม่ได้ แต่ถ้าใช้ X11 ก็สามารถใช้ ssh -X เพื่อเปิดเฟรมของ Emacs ระยะไกลบน X server ในเครื่องโลคัลได้ แต่อย่าลืมว่าใน บิลด์ GTK ที่ไม่ใช่ PGTK การปิดเฟรมใหม่อาจทำให้ Emacs ฝั่งรีโมตล่มได้
  • สงสัยว่าได้ตรวจสอบหรือยังว่าทำไมการส่งต่อ socket ถึงล้มเหลว