1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หลังเริ่มต้นกับ Linux ในปี 1997 ประสบการณ์ที่สลับไปมาระหว่าง Vim และ Emacs ได้ย้ายไปใช้ VSCode และ IntelliJ ในปี 2015 ก่อนจะกลับมาที่ Doom Emacs อีกครั้งในปี 2022 ภายใต้สภาพแวดล้อม Linux VM ระยะไกลของ Snowflake
  • VSCode ทำให้การเรียนรู้และพัฒนาง่ายขึ้นด้วย UI ที่ทันสมัย ขนาดไม่ใหญ่ การตั้งค่าบนพื้นฐาน JSON และ การรวม LSP สำหรับ Go และ Rust ขณะที่ในการพัฒนา Java นั้น IntelliJ เป็นตัวเลือกที่ใช้งานได้จริงมากกว่า
  • บน Linux VM รุ่นเก่าของ Snowflake งานส่วนใหญ่เน้นการเขียน shell script และ Bazel build file และเพราะ การทำงานผ่าน SSH เหมาะกว่าสภาพแวดล้อมกราฟิกระยะไกล จึงกลับมาจำเป็นต้องใช้ Emacs อีกครั้ง
  • Doom Emacs ทำให้ Emacs ให้ความรู้สึกเหมือน IDE ด้วยค่าเริ่มต้นที่สมเหตุสมผล การรวมภาษา การผูกคีย์แบบ Vim เมนูป๊อปอัปที่อิงปุ่ม space และโครงสร้างไฟล์ตั้งค่าที่เรียบง่าย
  • เหตุผลสำคัญที่ยังใช้ Emacs ต่อไปคือสามารถคง สภาพแวดล้อมการพัฒนาแบบเดียวกัน ได้ทุกที่ ไม่ว่าจะเป็น MacBook, Linux laptop, Linux cloud workstation หรือ FreeBSD server โดยใช้เพียง shell, tmux และ Emacs

จาก DOS/Windows IDE สู่ตัวแก้ไขบน Linux

  • เริ่มต้นใช้ Linux ราวปี 1997 ด้วย Caldera OpenLinux 1.1
  • ก่อนหน้านั้นใช้ Borland Turbo C++ และ Visual Basic เป็นหลัก จึงคุ้นเคยกับ IDE ที่สมบูรณ์มากในยุคนั้น
  • ได้รู้จัก Vim และ Emacs ผ่านหนังสือแนะนำ Linux สองเล่ม ซึ่งต่างก็แนะนำทั้งสองตัวแก้ไขในฐานะตัวเลือกขั้นสูง
  • แม้ IDE ที่เคยใช้มาก่อนจะดูครบเครื่องกว่า แต่ก็ได้เรียนรู้การใช้งานพื้นฐานและบทสอนของทั้ง Vim และ Emacs
  • ใช้สลับกันระหว่าง Vim และ Emacs จนถึงราวปี 2015
    • Emacs เหมาะกับช่วงการเขียนโค้ดยาว ๆ มากกว่า
    • Vim เด่นกว่าเมื่อต้องแก้หลายไฟล์อย่างรวดเร็ว เช่น งานกับ pkgsrc

เหตุผลที่ย้ายไปใช้ VSCode และ IntelliJ

  • แม้ Vim และ Emacs จะใช้งานได้ดีพอ แต่ การรวมภาษาต่าง ๆ ยังอ่อนกว่า จึงเริ่มสนใจตัวแก้ไขที่ทันสมัยกว่า
  • หลังย้ายไปใช้ macOS ก็ลอง Atom และ Brackets ด้วย แต่รู้สึกว่าทั้งฟีเจอร์และการตั้งค่ามีมากเกินไปจนเปราะบางและเป็นภาระ
  • VSCode ที่ปรากฏในปี 2015 ให้ความรู้สึกเหมือนเป็นเครื่องมือที่เข้ามาแล้วใช่ทันที
    • ดูทันสมัยและมีขนาดค่อนข้างเล็ก
    • ตอนนั้นตัวแก้ไขการตั้งค่าใช้ไฟล์ JSON โดยไม่มีแผงตั้งค่า จึงรู้สึกว่าควบคุมได้ง่าย
  • เมื่อเริ่มเรียนรู้ Go และ Rust การ รวม LSP ของแต่ละภาษาใน VSCode ช่วยได้มาก
    • เติมโค้ดอัตโนมัติ
    • ไฮไลต์ข้อผิดพลาดแบบเรียลไทม์
    • เพิ่มความเร็วในการเรียนรู้
  • เมื่อทำงานกับโปรเจกต์ Java ที่ใช้ Bazel ที่ Google, IntelliJ เป็นทางเลือกที่เป็นธรรมชาติ
    • เคยลองพัฒนา Java ด้วย Emacs เช่นกัน แต่ IntelliJ ดีมากจนในทางปฏิบัติตัวเลือกที่สมเหตุสมผลคือ IntelliJ
  • ตอนทำงานกับโค้ดเบส C++ และเครื่อง Windows ระยะไกลที่ Microsoft ก็ยังใช้ VSCode กับปลั๊กอิน Vim ต่อไป
    • หลายคนทำงานบนเครื่องระยะไกลโดยตรงผ่าน RDP
    • แต่ชอบวิธีรัน VSCode บนเดสก์ท็อปโลคัลแล้วเชื่อมต่อเครื่องระยะไกลด้วย SSH มากกว่า

อะไรทำให้กลับมาสู่ Doom Emacs ที่ Snowflake

  • หลังย้ายไป Snowflake ในปี 2022 การพัฒนาทั้งหมดเกิดขึ้นภายใน Linux VM รุ่นเก่า และงานประจำวันคือการเขียน shell script กับ Bazel build file
  • ในสภาพแวดล้อมนี้ VSCode หรือ IntelliJ ไม่ได้ช่วยแก้ปัญหา และยังไม่ชอบข้อจำกัดของสภาพแวดล้อมกราฟิกระยะไกล จึงกลับไปใช้วิธีเชื่อมต่อเข้าโลคัล VM ผ่าน SSH
  • จึงต้องการตัวแก้ไขสำหรับช่วงทำงานยาว ๆ อีกครั้ง และตัวเลือกนั้นคือ Emacs
  • init.el เดิมมีการตั้งค่าหลายร้อยบรรทัดที่สะสมมาหลายปี แต่เข้าใจเนื้อหาของมันไม่ดีพอ จึงอยากทิ้งทั้งหมดแล้วเริ่มใหม่
  • ในช่วงนั้นได้รู้จัก Doom Emacs
    • Doom Emacs คือ “ดิสทริบิวชัน” ที่จัด Emacs มาให้พร้อมตั้งแต่ต้น
    • มีค่าเริ่มต้นที่สมเหตุสมผล
    • มีการรวมภาษาที่กำหนดไว้ล่วงหน้า
    • มอบประสบการณ์ที่คุ้นเคยสำหรับผู้ใช้ Vim มาก่อน
    • แม้จะไม่ได้อ้างว่าเป็น IDE แต่ความรู้สึกตอนใช้งานจริงคล้าย IDE มาก

Doom Emacs เปลี่ยนประสบการณ์การใช้งานอย่างไร

  • หลังตั้งค่า Doom Emacs แล้ว Emacs ก็กลับมาให้ความรู้สึกว่าเป็น “เครื่องมือที่ใช่” อีกครั้ง เหมือนที่ VSCode เคยเป็นในปี 2015
  • ฟีเจอร์จำนวนมากของ Emacs ถูกเผยผ่านเมนูป๊อปอัปแบบโต้ตอบภายใต้ คีย์ลัดที่อิงปุ่ม space จึงค้นพบได้ง่ายขึ้น
  • มันอยู่ร่วมกับการผูกคีย์แบบ Vim ได้ และให้ลำดับคีย์ลัดที่ลดภาระต่อข้อมือมากกว่า
  • การตั้งค่าแบ่งออกเป็นไฟล์ง่าย ๆ สามไฟล์
    • config.el: กำหนดค่าทั่วไป เช่น theme, font
    • init.el: เลือกโมดูลเฉพาะของ Doom ที่จะเปิดใช้
    • packages.el: ติดตั้งแพ็กเกจที่ไม่ได้รวมมากับ Doom
  • ค่าเริ่มต้นนั้นสมเหตุสมผล และจุดรายละเอียดที่ควรปรับแต่งก็มีคอมเมนต์อธิบายไว้อย่างเพียงพอ
  • ด้วยพัฒนาการของ LSP และฟีเจอร์สมัยใหม่อย่าง tree-sitter ทำให้ตอนนี้ Emacs ให้ความรู้สึกเหมือน IDE
    • ได้การรวมภาษาที่เหมาะสมสำหรับภาษาส่วนใหญ่ที่ต้องใช้งาน

คุณค่าของการใช้สภาพแวดล้อมการพัฒนาแบบเดียวกันได้ทุกที่

  • ความสามารถที่ทรงพลังที่สุดคือไม่ว่าจะทำงานบนเครื่องไหนก็ได้ สภาพแวดล้อมการพัฒนาแบบเดียวกัน
  • เครื่องที่ใช้งานครอบคลุมตั้งแต่ MacBook, Linux laptop, Linux cloud workstation ไปจนถึง FreeBSD server ส่วนตัว
  • สิ่งที่ต้องมีมีเพียง shell, tmux และ Emacs
  • เมื่อต้องทำงานบนหลายเครื่อง สภาพแวดล้อมเดียวกันและ ความจำของกล้ามเนื้อ มีคุณค่าโดยตรงต่อประสิทธิภาพการทำงาน
  • เพราะความต้องการนี้ Emacs จึงกลายเป็นเครื่องมือที่สำคัญยิ่งกว่าเดิม

Doom Emacs ทำมากเกินไปหรือไม่

  • มีคำบ่นว่า Doom Emacs “ทำมากเกินไป” แต่ในความเป็นจริงมันมีประโยชน์ก็เพราะมันช่วยทำหลายอย่างให้
  • บางครั้งก็คิดว่าสักวันหนึ่งอาจลดการปรับแต่งลงเพื่อเรียนรู้ Emacs เองให้มากขึ้น
  • แนวโน้มที่โมดูลสมัยใหม่จากภายนอกหลายตัวค่อย ๆ เข้ามาเป็นแพ็กเกจพื้นฐานของ Emacs ยิ่งทำให้คิดเรื่องนี้มากขึ้น
  • ช่วงหลังมานี้ก็มีความอยากลองดิสทริบิวชันอย่าง Bedrock หรือ Emacs Solo
  • อย่างไรก็ตาม พลังงานในการเริ่มต้นลงมือ ที่ต้องใช้เพื่อเปลี่ยนมีสูงมาก และต่อให้เลือกเส้นทางนั้น สุดท้ายก็ต้องย้อนกลับมาถามอีกว่าทำไมถึงไม่ใช้ Emacs แบบ “raw” ไปเลย

ระยะห่างที่มีต่อ Elisp, Org mode และ Magit

  • แม้ Emacs จะอิงกับ Elisp แต่ก็ยังไม่เข้าใจอย่างถ่องแท้ว่ามันเปลี่ยนเวิร์กโฟลว์ของผู้คนได้มากเพียงใด
  • แม้จะสามารถสร้างตรรกะและเวิร์กโฟลว์เพิ่มเติมภายใน Emacs ได้ แต่ตอนนี้ก็จัดการแทบทุกอย่างได้ง่ายอยู่แล้วด้วย shell script
  • script ให้ความรู้สึกเป็น Unix มากกว่า ในมุมมองแบบ “Unix is my IDE”
  • ไม่ชอบที่ Org mode และ Magit ไม่ได้เป็นแอปพลิเคชันอิสระ แต่ถูกผูกไว้หลัง Emacs
  • ตราบใดที่ยังต้องทำงานต่อเนื่องบนเครื่องระยะไกลหลายเครื่อง Emacs ก็ยังคงเป็นเครื่องมือสำคัญต่อไป

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

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Lobste.rs
  • ผมเขียนโพสต์นี้เพราะหัวข้อมัน ขำมากจริง ๆ
    ไม่ใช่เพราะคำถามอะไรเป็นพิเศษ แต่เพราะกำลังเห็นคนตำแหน่งสูง ๆ ในบริษัท “ค้นพบ” เครื่องมือบรรทัดคำสั่ง ขณะใช้เอเจนต์เขียนโค้ดแบบอิง CLI แล้วพยายามโชว์ว่าสิ่งที่เพิ่งค้นพบนั้นมีประโยชน์แค่ไหน
    จนถึงตอนนี้ตัวอย่างเด่นคือ tmux และตอนนี้ก็กำลังรอให้พวกเขารู้ต่อว่า Vim กับ Emacs ก็มีอยู่เหมือนกัน
    เครื่องมือพวกนี้อยู่กับเรามานานมากแล้ว และถ้าไปถาม “นักพัฒนา 10x ระดับสูง” ในบริษัท ก็น่าจะพบว่าพวกเขาใช้อยู่
    ถึงอย่างนั้นมันก็มักถูกมองแบบ “ฮ่า ๆ นั่นมันของโบราณ ไปทางเว็บกันเถอะ!!11” บางทีอาจมีเหตุผลก็ได้ว่าทำไมนักพัฒนาเหล่านั้นยังใช้เครื่องมือพวกนี้อยู่ ;P

    • ข้อดีอย่างหนึ่งของ “ฟองสบู่ผลผลิตคุณภาพต่ำ” คือ ข้อความล้วน กำลังกลับมาเป็นสื่อที่ใช้ได้จริงและสำคัญอีกครั้ง
      รวมถึงการที่ CLI กลายเป็นเรื่องปกติมากขึ้น และความรู้ที่เคยถ่ายทอดกันปากต่อปากจำนวนมากถูกทำเป็นเอกสารด้วย แน่นอนว่าต้องอยู่บนเงื่อนไขว่าเป็นความรู้ที่มนุษย์สร้างขึ้น
      ต่อให้ผ่านช่วงเวลาน่าอึดอัดตอนนี้ไปแล้ว ก็น่าอยากให้ส่วนดี ๆ แบบนี้ยังคงอยู่
    • ผู้ใช้ Emacs ส่วนใหญ่น่าจะใช้แบบ GUI กัน ผมไม่มีตัวเลขนะ แต่คิดว่าน่าจะเป็นคนส่วนใหญ่แบบท่วมท้น
  • ผมเองก็อยู่ในกลุ่มที่เพิ่งเริ่มเรียนรู้เหมือนกัน
    เมื่อหลายปีก่อนเคยลอง Doom Emacs แต่ตอนนั้นมันช้าจนน่ารำคาญเพราะอาการหน่วงเลยเลิกไป ไม่แน่ใจว่าตอนนี้ด้วย native compilation แล้วมันกลายเป็นเรื่องในอดีตไปหรือยัง เพราะตอนนี้ผมยังใช้ Emacs เปล่า ๆ แบบไม่ตั้งค่าอะไร เลยจับความต่างได้ยาก กำลังใช้ 30.2 จาก Nixpkgs อยู่ และดูเหมือนว่า native compilation จะเปิดมาเป็นค่าเริ่มต้น
    ฟีเจอร์อย่างการเขียนอีเมลใน Emacs ผมไม่ได้สนใจมากนัก ผมแค่อยากได้เอดิเตอร์ที่ปั้นให้เป็นแบบที่ผมต้องการได้ และถ้าวันหลังอยากเรียน Lisp แล้วใช้มันต่อได้ก็คงดี ซึ่งน่าจะเป็น Janet ตอนนี้ Helix ยังไม่มีปลั๊กอิน เลยแทบไม่มีตัวเลือกฝั่ง Lisp ปรัชญาแบบ “ทุกอย่างคือข้อความ” ก็ถูกใจผมเหมือนกัน แต่จะเข้ากับตัวเองจริงไหมคงต้องดูกันต่อไป
    จะมาเรียนมันในปี 2026 ก็มีส่วนที่ชวนหนักใจเหมือนกัน เพราะมี ความรู้โดยนัย สะสมมาหลายสิบปี เวลาอ่านอะไรสักอย่างก็จะเจอชื่อแพ็กเกจ ชื่อคำสั่ง โผล่มารัว ๆ ทั้งที่จริง ๆ ผมแค่อยากทำ $THING เลยรู้สึกท่วมท้น สุดท้ายก็เลยหยิบ Mastering Emacs มาใช้เป็นเส้นทางเรียนที่มีคนแนะนำ
    คีย์ไบน์ดิงเริ่มต้นก็ค่อนข้างแปลกดี ถึงจะรู้ว่าสามารถรีแมปใหม่ทั้งหมดได้ แต่นั่นก็เพิ่มงานอีก แถมผมยังทำคีย์บอร์ดแยกชิ้นแบบยศาสตร์ใช้เอง และยังปรับเฟิร์มแวร์ให้เข้ากับวิธีทำงานแบบ Vim/Helix ที่ไม่ใช้ปุ่ม modifier เป็นแกนหลักของ workflow ไว้แล้วด้วย
    ผมสลับใช้ทั้ง MacBook Pro, PC และคีย์บอร์ดคัสตอม รวมเป็นสามแบบ เลยต้องหาคีย์ไบน์ดิงที่สม่ำเสมอพอจนสมองไม่ละลาย hjkl อยู่ตำแหน่งเดิมบนทุกคีย์บอร์ด แต่ปุ่มอย่าง Ctrl ไม่ได้เป็นแบบนั้น

    • ถ้าคีย์ไบน์ดิงยากเกินไปและคุณคุ้นกับฝั่ง Vim มากกว่า ลองดู evil ได้
      คุณอาจโดนเทศน์ว่า evil มีไว้สำหรับผู้ลี้ภัยจาก Vim ที่ไม่อยากเรียนรู้ “พระกิตติคุณอันแท้จริงของ Emacs” แต่จริง ๆ แล้ว พระกิตติคุณอันแท้จริงของ Emacs® คือการใช้งานมันในแบบที่เหมาะกับตัวคุณที่สุด
      ผมใช้ Emacs มาตั้งแต่ปี 1998 และไม่ได้เป็นแฟน Vim เลย ราวปี 2011 เริ่มมีปัญหาอาการบาดเจ็บจากการใช้งานซ้ำที่ข้อมืออยู่บ้าง ก็เลยลองแพ็กเกจที่ช่วยลดภาระตรงนั้น หลายปีผมใช้ god mode เยอะมาก แต่ก็ยังรู้สึกแปลก ๆ อยู่ดี
      แล้ววันหนึ่งผมก็ลอง evil ทั้งที่ไม่เคยใช้ Vim มาทั้งชีวิต แค่เพื่อ “พิสูจน์ว่ามันใช้ไม่ได้” แต่ภายในหนึ่งสัปดาห์ผมก็คล่องเท่ากับตอนใช้ god mode แล้ว และผ่านไปหนึ่งเดือนก็เร็วกว่าใช้คีย์ไบน์ดิงทางการของ Emacs เสียอีก
      ไม่ได้แปลว่าคีย์ไบน์ดิงเริ่มต้นผิดนะ แค่มือผมไม่ค่อยดี ประสบการณ์เลยอาจต่างกัน boon หรือ meow ก็อาจเหมาะกับคุณมากกว่า
      แต่ถ้า evil เข้ากับคุณได้ ก็ไม่ต้องรู้สึกผิดเลย Emacs อาจเปลี่ยนผู้ใช้ก็จริง แต่ในระดับที่มากกว่านั้นมาก Emacs ก็เปลี่ยนตัวเองเพื่อผู้ใช้ด้วย
    • Doom ต่างกันได้มากจริง ๆ แล้วแต่ว่าตั้งค่ายังไง และจุดนี้ก็ดีขึ้นเรื่อย ๆ ตามเวลา
      ทางที่ดีที่สุดคือประกอบมันขึ้นมาเอง แต่ก็งานเยอะ และโปรเจกต์อย่าง Doom ช่วยให้ ผู้ใช้ใหม่เริ่มต้นใช้งาน ได้ง่ายขึ้นอย่างชัดเจน
    • ความที่คีย์ไบน์ดิงเริ่มต้นมันแปลกนี่แหละ กลับเป็นสิ่งที่ผมชอบใน Doom Emacs
      เมื่อก่อนผมพอรู้คีย์ไบน์ดิงเริ่มต้นของ Emacs อยู่บ้าง แต่ไม่เคยรู้สึกว่ามันเป็นธรรมชาติ โดยเฉพาะในแง่การค้นหาให้เจอว่ามีอะไรทำได้บ้างที่ค่อนข้างยาก
      Doom Emacs ใช้ คีย์นำหน้า SPC กับงานแทบทุกอย่าง แล้วถ้าหยุดค้างไว้สักนิดก็จะมีเมนูชั่วคราวขึ้นมาอธิบายตัวเลือกที่ทำต่อได้ ซึ่งดีมาก คุณเลยค้นพบฟีเจอร์ที่ไม่เคยรู้มาก่อนได้ และมันก็ไม่ชนกับโหมดแบบ modal ของ Vim
      ดังนั้นผมจึงรู้สึกว่าการใช้ Vim mode สำหรับแก้ไขข้อความ และใช้คอมโบ SPC สำหรับงานฝั่ง Emacs เป็นสมดุลที่ดี
      คีย์ไบน์ดิงเริ่มต้นของ Emacs ก็มีข้อดีเหมือนกัน คีย์พื้นฐานสำหรับจัดการข้อความถูกใช้ร่วมกับ readline และแม้แต่ macOS ด้วย คีย์จัดการข้อความแบบ Emacs บน macOS ยังแพร่ไปถึง VSCode และไม่ชนกับคีย์ลัดคลิปบอร์ดมาตรฐาน ทำให้ VSCode บน macOS ใช้งานได้ดีทีเดียว
      แต่หลังจากย้ายไป Windows และ Linux ผมก็แทบทน VSCode ที่ไม่มีปลั๊กอิน Vim ไม่ไหวเลย
    • ถ้ามาจาก Helix ก็ลองดู meow ได้เหมือนกัน
      ได้ยินมาว่ามันมีฟีเจอร์คล้าย Kakoune และ Helix มาให้ตั้งแต่ต้น และพยายามไม่เข้าไปก้าวก่ายมากเกินไป ผมเองไม่ได้ใช้ทั้งคู่โดยตรงนะ จึงเป็นแค่สิ่งที่ได้ยินมา
      สำหรับแพ็กเกจ evil ที่มีคนแนะนำ ผมมองว่าปัญหาคือมันยึดคีย์ไบน์ดิงไว้มากเกินไป และเข้ากับแพ็กเกจภายนอกได้ไม่ค่อยดี เลยต้องมีแพ็กเกจ “adapter” จำนวนมาก
      ส่วน meow หลังตั้งค่าเสร็จครั้งหนึ่งแล้วก็ค่อนข้างไม่ต้องดูแลมาก
  • ใช้มันมา 33 ปี แล้ว และมันทำทุกอย่างที่ผมต้องการจากเอดิเตอร์หรือ IDE ได้หมด

  • เคยสลับไปมาระหว่าง Doom กับ (n)vim แต่ช่วงหลังมาปักหลักอยู่กับ Neovim เป็นส่วนใหญ่
    ปัญหาหลักที่เจอตอนใช้ Emacs คือ น่าขำตรงที่การดูแลรักษามันทรมานมาก พออัปเกรด Doom แล้วการ sync แพ็กเกจก็มักเพี้ยน จนบ่อยครั้งเหลือทางเลือกแบบระเบิดทุกอย่างแล้วติดตั้งใหม่หมดเท่านั้น
    แน่นอนว่าอาจจะแก้ให้มันดู “ไม่มือใหม่ขนาดนั้น” ได้ แต่พอถึงจุดหนึ่งก็แค่อยากให้เครื่องมือมันทำงานได้เฉยๆ มีงานต้องทำอยู่แล้วแต่คอนฟิกดันพัง และเราดันพึ่ง editor มากเกินไป แบบนั้นรับมือยากมาก
    ถึงอย่างนั้นก็ยังคิดถึง org-mode กับแนวทางการนำทางโดยรวมของ Emacs
    ทุกครั้งที่ลองทางแก้แบบ “สมัยใหม่” อย่าง VSCode หรือ CLion ก็กลับเจอปัญหาเดิมหนักกว่า ไม่มีฟีเจอร์ accessibility ที่ดีพอ เลยต้องคลิกแบบฝืนๆ แทนการนำทางด้วยคีย์บอร์ดล้วน และพฤติกรรมแบบ “Vim” ก็ยังไม่สมบูรณ์เท่าของจริง
    ทุกวันนี้ใช้ Neovim เพราะมันใช้งานได้ดีเฉยๆ จริงๆ ถ้าให้ coding agent ช่วยแก้คอนฟิกสัก 2 นาที ก็คงพูดแบบเดียวกันกับ Emacs ตอนนี้ได้เหมือนกัน (:

    • ลองใช้ฟังก์ชัน update ของ Doom อยู่หลายครั้ง แต่มีปัญหาทุกที
      เดี๋ยวนี้ถ้าอยากอัปเกรด หรือจำเป็นเพราะต้องอัปเกรด Emacs ก็จะลบทิ้งด้วย rm -rf ~/.emacs.d/ แล้วตั้งค่า Doom ใหม่ตั้งแต่ต้น โดยเอา ~/.doom.d/ ไว้ใน version control
      เวิร์กโฟลว์แบบนี้ไม่มีปัญหา
  • ฉันเป็นคนประหลาดที่ใช้ Emacs ทั้งพัฒนา เขียนงาน และอีเมล ทำแบบนี้มาราว 15 ปีแล้ว แต่สุดท้ายก็ไม่เคยหาเวลาหรือพื้นที่ให้ตัวเองไปเรียน elisp ได้เลย
    ตอนแก้ไฟล์คอนฟิกก็จริงๆ ไม่ค่อยรู้ด้วยซ้ำว่าตัวเองกำลังทำอะไรอยู่ แต่ถึงอย่างนั้นมันก็ยังเป็นสภาพแวดล้อมที่ทำงานได้มีประสิทธิภาพที่สุดอยู่ดี ซึ่งแสดงให้เห็นว่า editor ตัวนี้ยอดเยี่ยมแค่ไหน :-)
    การอ่าน Mastering Emacs แบบจริงจังยังค้างอยู่ใน to-do list มานานจนน่าอายที่จะยอมรับ

    • ฉันก็แทบไม่ต่างกัน แก้คอนฟิกกับแก้ไขไปเรื่อยๆ จนเหมือนซึมซับ elisp มาได้นิดหน่อย แต่จริงๆ รู้แค่น้อยมากจนแอบเขิน
    • M-x high-five
      ของฉันก็ใช้แพ็กเกจน้อยมาก และใช้คีย์ลัดดั้งเดิม จริงๆ ไม่มีฟังก์ชัน high-five หรอก แต่โอกาสนี้อาจจะได้ลองเจาะ elisp จริงจังสักที
  • ไม่ชอบการเรนเดอร์ของ Vim และก็เริ่มเบื่อสาย Electron/VSCode เลยย้ายมา Emacs เมื่อประมาณ 2 ปีก่อน
    ชอบ avy กับปลั๊กอินแนวกระโดดอีกไม่กี่ตัวมาก แต่สิ่งที่ทำให้ยังอยู่ต่อและตอนนี้กลายเป็นเครื่องมือหลักในการจัดการการเปลี่ยนแปลงโค้ดก็คือ magit

  • ลูกค้าที่ต้องทำงานด้วยในที่ทำงานมีธุรกิจทั้งระบบพึ่งพาการใช้ไฟล์ CSV ขนาดใหญ่มาก แต่ดูเหมือนไม่มีใครฝั่งนั้นรู้วิธีเปิดหรือดูข้อมูลใน ไฟล์ขนาด 1GB เลย
    เวลาขอ CSV header ก็ยังไม่รู้จักคำสั่ง head

  • ใช้แบบ X/GUI มาหลายปี แล้วเพิ่งเปลี่ยนมาใช้ -nw เมื่อกี้นี้เอง
    ใช้ เวอร์ชัน Pgtk เฉพาะเวลาพรีเซนต์เท่านั้น