การบูรณาการ Claude Code IDE สำหรับ Emacs

 (github.com/manzaltu)
1 คะแนน โดย GN⁺ 2025-08-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Claude Code IDE for Emacs ผสาน Claude Code CLI เข้ากับ Emacs แบบเนทีฟ เพื่อมอบสภาพแวดล้อมผู้ช่วยเขียนโค้ดด้วย AI ที่ทรงพลัง
  • ผ่านสะพานทางสองทางบนพื้นฐาน Model Context Protocol (MCP) ทำให้ Claude สามารถใช้งานความสามารถต่างๆ ของ Emacs ได้ เช่น LSP, การจัดการโปรเจกต์ และฟังก์ชัน Elisp
  • ให้ฟีเจอร์ที่ปรับให้เหมาะกับ Emacs เช่น การตรวจจับโปรเจกต์อัตโนมัติ การจัดการหลายเซสชัน การผสานการวินิจฉัย (ข้อผิดพลาด/คำเตือน) การแสดง diff ระดับสูง tab-bar และการติดตามการเลือก/บัฟเฟอร์
  • อาศัยคำสั่งและความสามารถในการขยายของ Emacs ทำให้สามารถเผยแพร่คำสั่งแบบตรงไปตรงมาผ่าน เซิร์ฟเวอร์ MCP และเชื่อมต่อกับเวิร์กโฟลว์แบบกำหนดเองได้
  • ผ่านการเชื่อมโยงอย่างลึกซึ้งระหว่าง Claude และระบบนิเวศ Emacs ทั้งหมด ในการสร้างสภาพแวดล้อมการพัฒนาที่รองรับ AI บนคลาวด์

ภาพรวม

Claude Code IDE for Emacs เป็นโปรเจกต์โอเพนซอร์สที่เชื่อมต่อกับ Claude Code CLI เพื่อเพิ่มศักยภาพของ Claude AI ภายในสภาพแวดล้อมของ Emacs สูงสุด โดยแตกต่างจาก wrapper เทอร์มินัลแบบธรรมดา แพ็กเกจนี้ออกแบบมาเพื่อให้ Claude สามารถใช้งานฟังก์ชันภายในของ Emacs ได้จริง โดยให้สะพานการสื่อสารแบบสองทางที่อิง MCP (Model Context Protocol) และเชื่อมกับระบบนิเวศของ Emacs เช่น LSP, การจัดการโปรเจกต์, ฟังก์ชัน Elisp เพื่อสร้าง สภาพแวดล้อมช่วยพัฒนาด้วย AI ที่เน้นประสิทธิภาพและชาญฉลาดสำหรับผู้ใช้ Emacs

คุณสมบัติหลัก

  • การตรวจจับโปรเจกต์อัตโนมัติและการจัดการเซสชัน

    • ใช้ project.el ที่ฝังใน Emacs เพื่อรับรู้โปรเจกต์โดยอัตโนมัติและแยกเซสชัน
    • ให้บัฟเฟอร์และอินสแตนซ์ Claude Code แยกตามแต่ละโปรเจกต์

  • การผสานเทอร์มินัลและรองรับสี

    • รองรับเทอร์มินัลสีผ่าน vterm หรือ eat
    • สนทนา/โต้ตอบกับ Claude ได้ภายใน Emacs

  • การรวมเข้ากับ IDE ผ่านโปรโตคอล MCP

    • เปิดเผยคำสั่ง Emacs หลากหลาย (การนำทางโค้ด การค้นหา symbol การวิเคราะห์ AST ฯลฯ) เป็น MCP server
    • Claude สามารถรันคำสั่ง Emacs และฟังก์ชันที่ผู้ใช้กำหนดเองได้

  • เซิร์ฟเวอร์ MCP Tools ที่ขยายได้สูง

    • สามารถเพิ่ม/กำหนด MCP tool แบบส่วนตัวได้ (เช่น ค้นหาในโปรเจกต์ทั้งหมด, refactoring ทั่วระบบ เป็นต้น)

  • การวินิจฉัยโค้ดและ Diff

    • ให้ข้อมูลการวินิจฉัยข้อผิดพลาด/คำเตือนผ่านการผสาน Flycheck และ Flymake
    • รองรับมุมมอง diff ระดับสูงด้วย ediff และการเข้าถึงข้อมูลการวินิจฉัย

  • การจัดการการสลับสถานะ/คำสั่ง

    • ด้วย tab-bar, การเลือก/ติดตามบัฟเฟอร์ ฯลฯ ช่วยให้ Claude เข้าใจบริบทปัจจุบันของผู้ใช้ได้

การรวมเครื่องมือของ Emacs

Claude Code IDE เปิดเผยคำสั่งและข้อมูลต่าง ๆ ของ Emacs ให้ Claude โดยตรงผ่านระบบ MCP tool

  • การผสาน LSP (xref)

    • รองรับการนำทางอัจฉริยะด้วย LSP เช่น Go-to-definition และการค้นหาสัญลักษณ์/การอ้างอิงทั่วทั้งโปรเจกต์

  • การรองรับ Tree-sitter

    • ให้ความเข้าใจโครงสร้างโค้ดผ่านการวิเคราะห์ syntax tree และ AST (Abstract Syntax Tree)

  • การรวม Imenu, Project

    • จัดหาบัญชีสัญลักษณ์ รายการไฟล์โปรเจกต์ และข้อมูลโครงสร้างโปรเจกต์โดยอัตโนมัติ

  • ฟังก์ชัน Elisp ที่กำหนดเอง

    • เปิดเผยผ่าน MCP tool โดยตรง เพื่อใช้ฟังก์ชันที่ปรับตาม workflow/โดเมนเฉพาะได้

การรวมแบบนี้ทำให้ Claude ใช้บริบทข้อมูลจากระบบนิเวศ Emacs เพื่อให้ การช่วยเหลือด้วย AI ระดับโค้ดที่แม่นยำ ได้

การใช้งาน

คำสั่งพื้นฐาน

  • M-x claude-code-ide-menu: เปิด transient menu ที่แสดงคำสั่งทั้งหมดแบบภาพรวม
  • เปิดใช้งาน Claude Code ภายในโปรเจกต์ ส่ง prompt รับต่อการสนทนาก่อนหน้า และจัดการสถานะ/เซสชันแบบหลากหลาย
  • สามารถจัดการหลายโปรเจกต์พร้อมกันและใช้งานเซสชัน Claude เฉพาะของแต่ละโปรเจกต์ได้

การจัดการหน้าต่างและเซสชัน

  • หากมีการเรียกใช้งานเซสชันใหม่อยู่แล้ว จะทำเพียงการสลับหรือแสดงหน้าต่าง
  • แม้ปิดหน้าต่างด้วยคำสั่งมาตรฐานของ Emacs (C-x 0) Claude เองก็ไม่ถูกปิด

การตั้งค่า

  • รองรับการปรับแต่งรายละเอียดต่าง ๆ ได้อย่างละเอียด เช่น Claude Code CLI, backend ของเทอร์มินัล, backend การวินิจฉัย, ตำแหน่ง/ขนาดหน้าต่าง, ตัวเลือกโหมดดีบัก
  • มีตัวเลือกขั้นสูง เช่น เพิ่ม flag, กำหนด system prompt, กำหนดฟังก์ชันตั้งชื่อตัวบัฟเฟอร์ เป็นต้น
  • เปิดใช้ MCP server และกำหนด tools/พอร์ตที่ใช้ได้

ตั้งค่า Terminal Backend

  • ค่าเริ่มต้นคือ vterm และสามารถสลับไปใช้ eat backend เมื่อจำเป็น
  • eat เป็นเทอร์มินัลที่ใช้ Elisp ล้วน เหมาะสำหรับกรณีที่มีปัญหาในการ build vterm
  • มี key binding เฉพาะ (M-RET: ขึ้นบรรทัดใหม่ใน prompt, C-<escape>: ออกจาก/ยกเลิก ฯลฯ)

ตัวเลือกการวินิจฉัย/ดีบัก

  • รองรับการตรวจจับและผสาน Flycheck, Flymake แบบอัตโนมัติ หรือกำหนดแบบบังคับ
  • มีตัวเลือกชั่วคราวเพื่อลดปัญหา reflow (จัดเรียงใหม่) ของ Claude terminal ตามบั๊ก #1422
  • รองรับบันทึกดีบักเชิงลึกในระดับ Emacs และ CLI (ตรวจสอบข้อความ WebSocket, JSON-RPC ฯลฯ ได้)

Advanced: หลาย Worktree และการควบคุมเซสชัน

  • ใช้ git worktree เพื่อรันเซสชันอิสระหลายตัวแยกสาขาในโปรเจกต์เดียวกันได้
  • รักษาบัฟเฟอร์และบริบทเฉพาะสำหรับแต่ละกลุ่มงาน รองรับเวิร์กโฟลว์การพัฒนาขนาน

รายละเอียด Emacs MCP Tools

ตัวอย่าง MCP Tools ที่มีอยู่

  • xref-find-references: ค้นหาการอ้างอิงของ symbol ที่เจาะจงในโปรเจกต์ทั้งหมด
  • xref-find-apropos: ค้นหาสัญลักษณ์/โค้ดทั้งหมดแบบ pattern-based
  • treesit-info: ให้ข้อมูลการวิเคราะห์ AST จาก tree-sitter
  • imenu-list-symbols: แสดงรายชื่อฟังก์ชันและตัวแปรทั้งหมดในไฟล์
  • project-info: ให้ข้อมูล metadata และไฟล์ของโปรเจกต์ปัจจุบัน

การเพิ่มเครื่องมือแบบกำหนดเอง

  • ผู้ใช้สามารถเพิ่มฟังก์ชัน Emacs ของตนเองเป็น MCP tool ได้ตามรูปแบบเดียวกัน
  • ตัวอย่างเช่น นิยามเครื่องมือค้นหาโค้ดด้วย ripgrep หรือคำสั่งเฉพาะโดเมน แล้วเรียกใช้งานโดยตรงจาก Claude

ลิขสิทธิ์และโปรเจกต์ที่เกี่ยวข้อง

  • ให้บริการภายใต้ GNU GPL v3.0 หรือสูงกว่า
  • แนะนำโปรเจกต์ที่เกี่ยวข้อง เช่น plugin รวมเข้ากับ VS Code และปลั๊กอิน Neovim (claudecode.nvim)

ความสำคัญและจุดเด่น

Claude Code IDE for Emacs เสนอสภาพแวดล้อม AI IDE ที่ทรงพลัง โดยสามารถใช้ บริบทการทำงานที่เป็นของ Emacs และข้อมูลระบบนิเวศโดยตรง ได้อย่างเข้มข้น แตกต่างจากเครื่องมือรวม LLM/AI แบบเดิม แม้ยังอยู่ในช่วงต้น แต่มีฟังก์ชันในตัวที่หลากหลาย ความสามารถในการปรับแต่งสูง และการรองรับหลายโปรเจกต์ ทำให้เป็นตัวเลือกที่ทรงพลังมากสำหรับผู้ใช้ Emacs และนักพัฒนาโอเพนซอร์ส

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

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

 
GN⁺ 2025-08-07
ความคิดเห็นจาก Hacker News
  • เห็นชัดว่าเครื่องมือ AI coding อย่าง Claude Code และ Aider แบบเดียวกับ LSP กับ tree-sitter เป็นสัญญาณดีมากสำหรับ Emacs หรือ Vim ในฐานะแกนเครื่องมือที่มักถูกมองว่าเป็นตลาดทางเลือก เพราะเราไม่ต้องสร้างฟีเจอร์ IDE ระดับสูงด้วยตัวเองเหมือนเดิม และยังเชื่อมต่อกับเครื่องมือเหล่านี้ได้ง่ายขึ้น เพื่อเน้นจุดเด่นเฉพาะด้านการแก้ไขโค้ดของตัวเองได้มากขึ้น ความยืดหยุ่นในการปรับแต่งและการผสานแบบนี้ยกระดับความสามารถในการแข่งขันของ editor เหล่านี้ได้จริง
    • อยากรู้ว่ามีมาตรฐานแบบไหนที่ทำให้นำเครื่องมือ agent coding มา integrate เข้ากับ editor ได้ง่ายเหมือน LSP บ้าง
    • ผมคิดว่านี่เป็นเรื่องที่เป็นมาอย่างต่อเนื่องแล้ว: Emacs และ Vim มีฟีเจอร์ IDE ชั้นสูงอยู่แล้ว และด้วย LSP กับ tree-sitter ตอนนี้การทำมาตรฐานที่รองรับหลาย editor และหลายภาษาเลยทำได้ง่ายขึ้นมาก
    • ผมไม่เห็นด้วยกับการเรียก Emacs กับ Vim ว่าเป็น “niche editor” เพราะพวกมันก็เป็น editor หลักมานานแล้ว
  • ผมเชื่อมาตลอดว่า Emacs เป็น editor ที่เหมาะกับ AI agent ที่สุด เพราะ agent มองเห็นสถานะทั้ง editor ได้ง่าย และสามารถปรับการทำงานผ่าน elisp ได้ทั้งหมด ผมคิดว่า editor ที่เปิดโอกาสให้ปรับแต่งระดับเดียวกับ Vim/Emacs จะยังคงได้เปรียบมาก
    • Vim และ Emacs มีจุดแข็งอยู่เสมอจริง ๆ แม้แต่ละคนจะมองไม่เหมือนกัน แต่ด้วยประสบการณ์ผม ความยืดหยุ่นที่ปิดกันใน VSCode หรือ IntelliJ ยังเป็นจุดอ่อนร้ายแรงมาก คือ API ปลั๊กอินจำกัด สภาพแวดล้อมรันแบบ sandbox โครงสร้างการอนุมัติภายในองค์กร และความไม่โปร่งใสของ logic ภายใน เดิมทีเมื่ออยากได้ feature ใหม่ มักต้องย้ายไปใช้ IDE ตัวอื่น แต่ตอนนี้ผมรู้สึกว่าเรียนรู้ Emacs เองเพียงพอก็เข้าถึงเป้าหมายงานได้ดีขึ้นมาก และวิธีแก้ปัญหาใน Emacs ให้ความพึงพอใจมากกว่าการใช้ IDE
    • แก่นของความแข็งแรง Emacs คือ lisp interpreter core เพราะ AI agent สามารถมองสถานะ editor ทั้งหมดและเปลี่ยนแปลงได้ใน runtime ด้วยกลไกประเมินเดียวกับผู้ใช้เอง ขณะที่ editor ส่วนใหญ่กลับล็อกตัวเองไว้ด้วย plugin API ที่ตายตัว
  • ตอนนี้ผมใช้ปลั๊กอิน claude-code.el แล้วค่อนข้างพอใจ แม้จะเป็น wrapper แบบเทอร์มินัลล้วน ๆ แต่กลับให้ Transient menu ที่ทรงพลังมาก ทำงานใน Emacs อย่างเดียวก็ทำให้ workflow ดีขึ้นมากแล้ว ทำให้สร้างลำดับการทำงานที่ปรับแต่งเองได้ง่ายกว่า iTerm เดิมมาก ผมวางแผนจะตามดูแพ็กเกจใหม่ ๆ ต่อไปและคาดหวังกับ eca-emacs เหมือนกัน โดยเครื่องมือที่เกี่ยวข้องกับ productivity ผมมักเริ่มต้นอย่างระมัดระวังเพราะประสบการณ์ทั่วไปคือโปรเจกต์ขนาดใหญ่มักต้องผ่านช่วง “big-bang” เพื่อปรับแก้เยอะ
    • ผมลองใช้ไปช่วงสั้น ๆ แล้วสุดท้ายกลับไปใช้ claude code ในเทอร์มินัลอย่างเดียว เพราะใน Emacs มันรู้สึกค่อย ๆ กระตุก และไม่จำเป็นต้องเปิดเทอร์มินัลแยกเพิ่ม เสียดายที่ยังไม่เชื่อมกับแพ็กเกจ mcp.el ได้ และตอนใช้ claude code ในงานจริงก็ยังไม่เห็นว่าคุณภาพโค้ดถึงเกณฑ์ใช้งานของผม mcp.el ก็เป็นของที่น่าดูเช่นกัน
  • ความเคลื่อนไหวที่ Emacs รับ LSP, tree-sitter และ Claude Code เข้ามันเป็นน่าสนุกดี แต่ขณะเดียวกันระดับความยากในการตั้งค่าก็เพิ่มขึ้นชัดเจนมาก ผมเป็น Emacs user มานาน 20 ปี แต่ตอนนี้เซ็ต environment ไม่ง่ายเหมือนเมื่อก่อนอีกแล้ว ก่อนหน้านี้ก่อนมีการผสานกับ IDE, Claude Code ดูเหมือนตัวที่ใช้งานง่ายที่สุด (รันแล้วใช้งานได้เลย มี buffer sync อัตโนมัติแทบไม่ต้องดูแล) บน MacOS เครื่องใหม่ ผมทำให้ typescript-ls รันได้แบบเกือบผ่าน แต่ gopls ก็ยังดาวน์โหลดไม่สำเร็จ แก้ได้สักชั่วโมงหรือสองชั่วโมง แต่หาได้ที่คอขวดยังยาก ผมแชร์ตรงนี้เพราะอยากรู้ว่า Emacs user ตอนนี้จัดการกันอย่างไร ตอนนี้ผมกำลังเขียนโค้ดบน Zed อย่างสนุก 20 ปีของความชิน Emacs ไม่ง่ายเลยที่จะถอย แต่ความสามารถตั้งค่าจากไฟล์เล็ก ๆ ไปจนถึงรองรับโปรเจกต์ใหญ่ และความยืดหยุ่นสูงสุดของมันยังน่าทึ่ง จึงสงสัยว่า neovim อาจไปได้ดีกว่าในด้านนี้ไหม ตอนนี้ผมก็กำลังคิดว่าควรเรียน elisp debugging ให้ดีขึ้นเพื่อเข้าใจว่าคำสั่งที่รันไปมีผลต่อ environment อย่างไร อีกอย่างยังกังวลเหมือนกันว่าความชำนาญกับ key binding ของ Emacs (แม้แต่ Dvorak!) จะทำให้ประสบการณ์ neovim เป็นเรื่องที่ต่างออกไปมาก
    • ผมขอแนะนำให้เรียน elisp debugging อย่างยิ่ง แม้ใช้ Emacs มาหลายสิบปี คนจำนวนมากยังไม่รู้จัก built-in profiler, edebug, apropos, macro expansion, advising system, indirect buffer เลย เปรียบ Emacs เหมือนรถยนต์ที่ขณะวิ่งก็สามารถถอดประกอบและเปลี่ยนเป็นยานใต้น้ำได้ได้ แปลว่าเราต้องพร้อมรับมือกับงานแก้ปัญหาพื้นฐานและสถานการณ์ไม่คาดคิดอยู่เสมอ จุดแข็งคือหาปัญหาได้ตรงจุด และในบัฟเฟอร์ gptel ก็สามารถเขียน elisp สำหรับ hook หรือฟังก์ชัน advise แล้วทดสอบได้ทันที ความรู้สึก “ได้อิสระ” นี้ต้องลองเองถึงรู้สึก ตอนนี้ผมไม่ต้องเครียดเรื่อง “config สะอาด” แล้ว แค่ทำโมดูลให้เป็นระบบและเติม elisp ตามต้องการได้เลย ส่วนใหญ่ถ้าพังเพราะแพ็กเกจภายนอกอัปเดตหรือปัญหาต่าง ๆ ผมจะหาจุดที่พังแล้วแก้หรือหาทางเลือกใหม่เสร็จภายในไม่กี่นาที และเกิดไม่บ่อย
    • เพื่อควบคุมปัญหา environment ผมรัน Emacs ใน Docker แนะนำให้ดู emacs-native-dockerfiles
    • ถ้าต้องผสานระบบภาษาใหม่เข้า Emacs การเลือกแพ็กเกจและเครื่องมือภายนอก (เช่น LSP server) ก็เป็นงานที่ค่อนข้างยุ่งยาก โดยเฉพาะเมื่อมีโปรเจกต์ระดับ dabbling จำนวนมากให้เลือก ต้องคิดทุกครั้ง ในทางปฏิบัติผมใช้ Nix (devenv.sh), direnv ให้ไม่ให้ Emacs ดาวน์โหลดเอง แต่ชี้ path ให้เองและเก็บ config ไว้ใน devenv เพื่อให้ทีมอื่นใช้ environment เดียวกันได้
    • แม้จะเป็น Emacs user 8 ปี แต่เมื่อสองเดือนก่อนผมย้ายไปใช้งาน nvim อย่างเต็มตัว และแทบไม่เปิด Emacs ตลอดหนึ่งเดือน ผมติดตั้ง lazy.vim และสลับใช้ AI plugin กันไปมา ตอนนี้ ecosystem และ community ของ nvim ช่วงหลังกลับดู active กว่าเดิม และ ThePrimeagen ก็น่าสนใจให้ตาม
    • ประสบการณ์กับ neovim ก็พัฒนาขึ้นมาก ตอนนี้ตั้งค่าได้ตั้งแต่ barebone ไปจนถึงครบฟีเจอร์ IDE แล้ว และมี pre-configured distribution เยอะมาก ผมแนะนำให้ดู LazyVim ในแนวทางนี้ และ AI plugin ก็ดูได้จาก awesome-neovim #ai
  • ผมยังต้องการการผสานระหว่าง org mode หรือ AI ที่ครอบคลุมงาน note-taking มากขึ้น เพราะ GitHub Copilot ลบข้อความแชตหลังผ่านไป 30 วัน ทำให้การสร้าง knowledge base ด้วย AI มีปัญหามากในทางปฏิบัติ แบบที่จัดการงานวิจัยและบันทึกแบบ local เองแบบ notebookllm ของ Google นี่ต้องการมากจริง ๆ
    • แนะนำลองใช้ gptel-mode ได้ แชตจะถูกเก็บใน org buffer และเซสชันบันทึก/คืนค่าได้ง่ายมาก รันร่วมกับ mcp.el ได้ดี
    • ลิงก์ ob-aider
  • ผมพอใจกับความสามารถที่เพิ่มเครื่องมือลงใน mcp server ได้อย่างเสรี ซึ่งเป็นสิ่งที่ Emacs ต้องการอย่างแท้จริง ใช้มานานหลายปี และตอนนี้เขียน elisp ด้วยตัวเองบ่อยขึ้น เพราะ Claude ช่วยร่างโค้ด elisp ค่อนข้างดี ทำให้ผมใช้มันมากขึ้น (ยกเว้นบางครั้งต้องจัดแต่งวงเล็บเอง แต่โดยรวมโอเค) อีกแพ็กเกจที่ผมตั้งใจลองคือ efrit ของ Steve Yegge ฟีเจอร์ให้ agent รัน elisp expression แบบอิสระเป็นการยกระดับขีดจำกัดของ Emacs อีกขั้น
    • ผมเป็นแฟน Yegge มายาวนานและติดตามงานเขาเสมอ และยังมองว่ายังอยู่ในช่วง honeymoon ของ vibe code แต่ความสามารถด้าน Emacs ของเขาถือว่าคนไหนก็ไม่ทัน หลังจาก 1-2 ปีที่ผ่านมาเริ่มรู้ว่า LLM ขนาดใหญ่กลับเก่งกับ elisp อย่างแปลกอย่างมาก และนี่เป็นจุดเริ่มต้นของโปรเจกต์ hypermodern ของผมเอง efrit ดูมีอนาคตดี แม้ยังไม่สามารถตั้งค่าให้สมบูรณ์ได้เองเต็มที่
  • ตอนนี้มีแพ็กเกจที่เชื่อม Emacs กับ Claude Code มากกว่าห้าตัว และมีอีกสองถึงสามตัวที่แทบจะแข่งกันแรงบน reddit และที่อื่น ซึ่งน่าสนใจ แต่ปลั๊กอินที่ดีจริง ๆ กลับเงียบ ๆ อยู่ และแทบไม่มีใครเอ่ยถึง yuya373/claude-code-emacs ดูเหมือนทำงานได้เกือบครบเทียบเท่าแพ็กเกจคู่แข่งทั้งหมด
    • ไม่แน่ใจว่าจะเป็นที่นิยมมากแค่ไหน แต่ดูแล้วตัวนี้น่าจะติดตั้งง่ายที่สุด ลองดู melpa claude-code
    • ตัวนี้น่าจะยังไม่รองรับการผสาน /ide ของ Claude-code-ide
  • แนะนำแน่นอนว่าอย่าพลาด eca เขามุ่งเน้นทำ Emacs ให้เป็นเครื่องมือ AI pair programming ที่ดีที่สุด
  • ผมรู้สึกถึงบรรยากาศค่อนข้างโต้แย้งเรื่อง AI integration ในชุมชน Emacs ช่วงนี้ แต่ที่มองแล้วผลเสียมากกว่าผลดีมาก ๆ แม้ AI จะพัฒนาต่างจากแนวทางเดิม แต่ Emacs มีรากจาก MIT AI Lab แน่นอน จึงรู้สึกแปลกที่มีท่าทีปฏิเสธเครื่องมือจาก AI working group
    • ความงามของ Emacs คือการควบคุมโดยผู้ใช้ เพราะระดับ elisp layer ให้เปลี่ยนสิ่งที่ต้องการได้หมด ทำให้ปลั๊กอินพวกนี้เกิดขึ้นต่อเนื่อง ต่างจาก VS Code ที่มีโครงสร้างผลักให้เกิดการแยกเป็นชิ้น ๆ เพราะ Microsoft ใช้ API เฉพาะของตัวเองกับเครื่องมือ proprietary และให้เฉพาะ extension API ที่จำกัดสำหรับภายนอก จึงเกิด vscode forks เยอะมาก ในขณะเดียวกัน Emacs มี Elisp developer คนเดียวที่มีไฟและทักษะเพียงพอจะปรับทุกอย่างได้ และโมดูล AI/LLM ใหม่ก็สามารถถูกสร้างขึ้นได้ไม่หยุด ชุมชน Emacs อาจวิจารณ์เกินจริงบางส่วน แต่ปลั๊กอิน AI/LLM ยังคงออกมาอย่างต่อเนื่องและได้การตอบรับดี เช่น gptel
    • ที่มาของแนวโน้มนี้บางส่วนก็มาจาก Richard Stallman เขาเชื่อว่าถ้าโครงการเสรียังไม่พร้อม ควรระวังการนำทางเลือก “non-free software” เข้ามา วิธีคิดแบบนี้ทำให้การตัดสินใจหลายอย่างล่าช้าลง เช่น GCC extension, LLVM debugger, tree-sitter, git/bzr, CI build farm ฯลฯ และช่วงเวลานั้นทำให้ตัวเลือกแทนที่สำหรับโครงการแกนอย่าง Emacs ก็ช้าลง สุดท้ายก็ต้องยอมรับช้าอยู่ดี บางครั้งดูเหมือนเป็นการปกป้องอิทธิพลของ FSF
    • ชุมชน Emacs นั้นหลากหลายมาก วางตัวได้กับการวิจารณ์ได้บ้างก็พอ แต่ไม่ต้องไปยึดติด ใครก็ตามเพิ่มฟีเจอร์จาก third-party module ได้ตามใจ และไม่สามารถให้ main maintainer ขวางได้ง่าย ๆ
    • ความน่าสนใจที่ได้รู้ใหม่คือ MIT AI Lab เชื่อมโยงกับกระแส AI สมัยใหม่นี้จริง และนั่นก็น่าสนุกมาก
  • เครื่องมือพวกนี้ทำให้ผมตื่นเต้นมาก และผมชอบแนวคิดเอา Emacs+AI มาอยู่ใน coding flow แต่สิ่งที่ต้องการอันดับแรกคือรัน local ได้เองบนฮาร์ดแวร์ไม่เกิน $2000 จึงอยากรู้ว่าปัจจุบันหรือตอนใกล้ ๆ นี้ทำได้จริงหรือยัง และมีใครรัน coding agent ด้วย local model อยู่ไหม
    • มีความก้าวหน้ามหาศาลด้านการ inference ที่ประหยัดหน่วยความจำและโมเดลเปิดที่เน้นโค้ด โดยตอนนี้ Qwen3-Coder ได้รับความสนใจสูงมาก (Qwen3-Coder) สำหรับรัน local มี Ollama และ LM Studio ให้ใช้ ขึ้นกับขนาดโมเดล/การ quantization แล้ว ด้วยงบ $2000 เรารันโมเดลได้เยอะมาก และ Mac ซีรีส์ M ก็น่าสนใจเรื่องต้นทุน ตัวเลือกอีกมากสำหรับ local LLM พบได้ในซับเรดดิท LocalLlamas แม้ยังต่างจากระดับของห้องแล็บ AI ขนาดใหญ่ แต่ถ้าคุณชอบ setup local เต็มรูปแบบ ก็เป็นโปรเจกต์ที่น่าลองและน่าสนใจมาก
    • gptel รองรับโมเดลได้หลายตัวรวมถึง local models ด้วย
    • ตัวเลือกอื่นคือ MacMini, frame.work desktop หรือ Nvidia DGX Spark (เริ่มต้น 3k)