ข่าวร้าย, Emacs
(eshelyaron.com)- แม้เดิมจะเป็นบทความวิจารณ์การเปลี่ยนแปลงของ ฟีเจอร์ registers ใน Emacs 30 แต่ในเนื้อหาที่เผยแพร่ปัจจุบัน ต้นฉบับถูกนำลงแล้ว
- ต้นฉบับถูกลบเนื่องจากวิจารณ์การพัฒนา Emacs ในช่วงหลังอย่างรุนแรงเกินไป และ ไม่เป็นมิตรต่อบุคคลที่เกี่ยวข้อง
- เหลือไว้เพียงคำแนะนำว่าหากต้องการดูเนื้อหาที่ถูกลบ ให้ไปค้นหา Git log ของเว็บไซต์ผู้เขียน
- สาระสำคัญที่ยังเหลืออยู่คือ ผู้เขียนเริ่มใช้ branch ของ Emacs ที่แตกต่างออกไปเล็กน้อยสำหรับการใช้งานประจำวัน
- จากเนื้อหาที่เผยแพร่ปัจจุบันเพียงอย่างเดียว จึงยากที่จะตรวจสอบรายละเอียดการเปลี่ยนแปลงหรือประเด็นทางเทคนิคของฟีเจอร์ registers ใน Emacs 30
บทความวิจารณ์ Emacs 30 ที่ถูกนำลง
- ต้นฉบับเป็นบทความเกี่ยวกับการเปลี่ยนแปลงใน ฟีเจอร์ registers ของ Emacs 30 ที่ผู้เขียนมองว่าแย่ลง
- ในเนื้อหาที่เผยแพร่ยังคงระบุเหตุผลของการลบไว้ว่า บทความเดิมวิจารณ์การพัฒนา Emacs ในช่วงหลังมากเกินไป และไม่เป็นมิตรต่อผู้คนที่เกี่ยวข้อง
- ยังระบุด้วยว่า บทความนี้ได้รับความสนใจมากกว่าบล็อกโพสต์ก่อนหน้ามาก ซึ่งเป็นส่วนหนึ่งของเหตุผลเบื้องหลังการลบ
ข้อมูลที่ตรวจสอบได้ในปัจจุบัน
- หากต้องการอ่านบทความที่ถูกลบจริง ๆ สามารถตรวจสอบ Git log ของเว็บไซต์นี้ได้
- ผู้เขียนระบุว่าเริ่มใช้ branch ของ Emacs ที่แตกต่างออกไปเล็กน้อยสำหรับการใช้งานประจำวัน
- เนื้อหาที่เผยแพร่ปัจจุบันไม่มีรายละเอียดปัญหา ตัวอย่าง หรือเนื้อหาแพตช์ที่เฉพาะเจาะจงเกี่ยวกับการเปลี่ยนแปลงฟีเจอร์ registers ใน Emacs 30
1 ความคิดเห็น
ความเห็นจาก Hacker News
ใน branch พัฒนาของ Emacs ต่อให้มีการนำ การเปลี่ยนแปลงที่ทำลายความเข้ากันได้ เข้ามาไม่ว่าจะตั้งใจหรือไม่ และแม้ผู้ใช้บางส่วนจะแสดงความกังวล ก็ไม่ได้หมายความว่าจะต้องรีบย้อนกลับทันที
จำเป็นต้องมีขั้นตอนในการถกข้อดีข้อเสีย ทดลองและปรับปรุงวิธีแก้หลายแบบ แล้วค่อยหาจุดประนีประนอม ตอนนี้เพิ่งผ่านไปแค่ 3 วันนับจากที่ผู้ใช้เริ่มแสดงความกังวล จึงยากจะบอกว่ากระบวนการนี้ควรเสร็จสิ้นไปแล้ว
คำตอบล่าสุดของ Eli ก็มีใจความว่า “สองคนแรกที่เข้าร่วมการถกเถียงมองว่าพฤติกรรมใหม่สมเหตุสมผลกว่าพฤติกรรมเดิมมาก แต่ตอนนี้มีความเห็นคัดค้านเข้ามาแล้ว จึงควรถกเรื่องพฤติกรรมนี้กันต่อ แล้วค่อยคุยเรื่องค่าเริ่มต้นภายหลัง”
แม้จะมองว่าวิธีพัฒนาของ Emacs มีปัญหาร้ายแรง แต่การที่ผู้ใช้ปกติคอยตำหนิคนหัวแข็งใน emacs-devel แล้วพอมีการเปลี่ยนแปลงที่ตัวเองไม่ชอบกลับทำเหมือนโลกจะแตก ก็เป็นปัญหาเช่นกัน เพราะจะยิ่งทำให้ผู้ดูแลรักษาตั้งการ์ดป้องกันตัว
ถ้าอ่าน mail thread จะดูเหมือนเป็นความเห็นต่างอย่างรุนแรงมากกว่าจะเป็น “ความหยิ่งยโส” และการหาฉันทามติก็ย่อมต้องใช้เวลา การที่ใครสักคนไม่ยอมถอยทันทีตามมุมมองของตน ไม่ควรถูกเรียกต่อหน้าสาธารณะว่า “หยิ่งยโส” และการพยายามปลุกคนหมู่มากที่ไม่ได้อ่าน thread ให้เข้ามารุมตำหนิก็ดูใกล้เคียงกับการคุกคาม
อีกทั้งการบอกว่า patch ที่ทำให้การเปลี่ยนแปลงนี้เป็นทางเลือกถูกเพิกเฉยก็ไม่ซื่อตรงนัก เพราะ patch นั้นไม่ได้แค่เพิ่มตัวเลือก แต่ยังเอาการเปลี่ยนแปลงอื่นออกไปด้วย จึงถูกปฏิเสธ และการโยนความรับผิดไปที่คนคนเดียวแบบนั้นก็ยากจะยอมรับได้
หากผู้ใช้ไม่ออกมาแสดงปฏิกิริยา ตามขั้นตอนที่อธิบายไว้ การเปลี่ยนแปลงเดิมที่พวกเขาคัดค้านก็น่าจะถูกนำเข้าไปตามเดิม ในกรณีของ clojure-mode ก็เคยมีตอนที่ rms พยายามนำชื่อของผู้เขียนจากชุมชน Clojure ที่ดูแลมานานมาใช้แล้วเขียนใหม่ คนจำนวนมากต้องออกมาประท้วงใน mailing list จึงหยุดไว้ได้ แต่สุดท้ายคนเหล่านั้นกลับถูกบอกว่าทำเกินจริง ดังนั้นคำวิจารณ์ว่า “เกินจริง” จึงดูไม่มีความหมายมากนัก
ถ้านำฟีเจอร์ที่ทำให้ user flow พังเข้า main branch โดยไม่คุยกับชุมชนวงกว้างก่อน ก็เป็นเรื่องธรรมดาที่ผู้คนจะไม่พอใจ การ merge แบบนี้คือวิธีที่เครื่องมือเก่าแก่ค่อย ๆ สูญเสียแรงสนับสนุนจากชุมชน
หากไม่มีการพิจารณาอย่างจริงจังที่จะย้อนกลับการเปลี่ยนแปลงที่ทำลายความเข้ากันได้ในทันที นั่นก็เป็นสัญญาณว่านักพัฒนา Emacs ไม่ได้ให้ความสำคัญกับ backward compatibility เท่าเดิมอีกต่อไป และเท่ากับว่ากำลังทอดทิ้งผู้ใช้เดิมจำนวนมาก
https://www.murilopereira.com/the-values-of-emacs-the-neovim...
คุณค่าหลักเป็นสิ่งสำคัญ ผู้ดูแลรักษา Emacs ได้ละเมิดคุณค่าหลักนั้น และการที่ชุมชนรู้สึกไม่พอใจก็เป็นเรื่องสมเหตุสมผล
การทำลาย workflow ของผู้ใช้โดยไม่ทำให้เป็นตัวเลือก ไม่ใช่แค่ไม่ opt-in เท่านั้น แต่ถึงขั้นปิดไม่ได้เลย ดูเหมือนเป็นการเพิกเฉยต่อ ประสบการณ์ผู้ใช้ อย่างไม่ใส่ใจ
ถ้าสรุปจากที่เข้าใจ ล่าสุดมีการรับคอมมิตใน Emacs ที่เปลี่ยนพฤติกรรมของ register ซึ่งเป็นกลไกทั่วไปกว่าการคัดลอก
ตอนนี้ Emacs จะเปิด minibuffer เพื่อแสดงว่าเกิดอะไรขึ้น และต้องกด Enter หรืออินพุตที่เทียบเท่าเพื่อยืนยันการเปลี่ยนแปลง ผู้เขียนต้นฉบับมองว่านี่เป็นการทำลายความเข้ากันได้อย่างร้ายแรง เพราะเปลี่ยนพฤติกรรมพื้นฐาน อาจปิดด้วยการตั้งค่าได้ไม่ง่าย และยังไม่มีการถกเถียงกันมากพอ
ถ้าเปรียบกับ Vim ก็เหมือนตอนพิมพ์
\"dyyเพื่อคัดลอกบรรทัดปัจจุบันไปยัง registerdแล้วจู่ ๆ ก็เปิด scratch buffer ขึ้นมา แสดงข้อความกับบัฟเฟอร์ และบังคับให้กดปุ่มเพื่อปิด สำหรับผู้ใช้ Vim ทั่วไปที่เข้าใจ register อยู่แล้วคงรู้สึกแย่มาก แต่ก็อาจมีคนที่ชอบพฤติกรรมแบบ “แสดงให้ชัดว่ากำลังคัดลอกอะไร” เหมือนคนที่คัดลอกผ่าน visual modeส่วนที่เหลือของบทความเป็นเรื่องที่ผู้เขียนต้นฉบับพยายามจุดประเด็นอภิปราย แต่ Thierry กันไว้ และโดยนัยก็โทษชุมชนนักพัฒนา Emacs ที่เหลือด้วย
แม้จะใช้ Emacs มาหลายสิบปี แต่ก็ไม่เคยลงลึกกับ register มากนัก โดยส่วนตัวใช้ kill/yank สำหรับคัดลอก และใช้ multiple cursors หรือคีย์บอร์ดแมโครแบบครั้งเดียวสำหรับงานแก้ไขที่ซับซ้อนกว่า ถึงอย่างนั้น Emacs ก็มีฟีเจอร์แก้ไขขั้นสูงแบบเลือกใช้จำนวนมากสำหรับคนที่อยากพึ่งพา muscle memory
การเพิ่มการกดยืนยันเข้ามาตรงนี้จึงดูแปลก คล้ายเอา “แป้นเหยียบยืนยันคอร์ดแปลก ๆ” ไปติดกับเปียโนไฟฟ้า เท่ากับเพิ่มอีกหนึ่งขั้นให้กับการป้อนข้อมูลที่ต้องเร็วและซับซ้อน
Emacs มีระบบ undo ที่ยอดเยี่ยมอยู่แล้ว ดังนั้นแทนที่จะถามว่า “จะวางเนื้อหาจาก register d ไหม?” ก็น่าจะแค่วางไปเลย แล้วถ้าผู้ใช้เลือกผิดก็ค่อย undo
เพราะอย่างนั้นการทำลายความเข้ากันได้ตรงนี้จึงดูประหลาด และถ้าไม่มีทางปิดได้ ผู้ใช้จำนวนมากก็คงไม่พอใจ Emacs เป็นเครื่องมือที่เก่ากว่าธรรมเนียม GUI สมัยใหม่ จึงไม่มีทางทำให้ผู้ใช้ใหม่คุ้นเคยได้เท่า vscodium ดังนั้นแนวคิดที่จะเน้นตอบโจทย์ power user ให้ดีที่สุดก็ฟังขึ้นเหมือนกัน
kill-ring-saveหรือค่าเริ่มต้นM-wไม่ได้รับผลกระทบ สิ่งที่เปลี่ยนมีแค่ การบันทึกลง register ซึ่งเป็นฟีเจอร์ที่ล้ำขึ้นไปregister ไม่ใช่ซูเปอร์เซ็ตของ clipboard หรือ kill ring
อีกอย่าง คนที่บอกว่าการเปลี่ยนนี้จะตั้งค่าไม่ได้ ดูเหมือนจะไม่ค่อยเข้าใจความปรับแต่งได้ของ Emacs นัก “การตั้งค่า” มีไว้เพื่อความสะดวกเท่านั้น ถ้าต้องการจริง ๆ ก็แก้โค้ดทั้งก้อนได้ นี่คือส่วน Elisp ของ Emacs และถึงจะถูกรวมเข้าไปตามเดิม ก็น่าจะมีแพ็กเกจออกมาเปลี่ยนพฤติกรรมได้ภายในไม่กี่นาที ไม่ถึงขั้นต้อง fork และการพูดถึงการ fork ในกรณีนี้ก็แทบเป็นแค่ท่าทีเชิงสัญลักษณ์มากกว่า
ถ้าไม่ย้อนกลับ ก็หวังว่าจะหา ชิ้นส่วนแมโคร ที่ช่วยจัดการการกดปุ่มเพิ่มให้อัตโนมัติได้ Emacs ทุกวันนี้ก็ต้องกดปุ่มเยอะอยู่แล้วแม้กับงานง่าย ๆ และก็ไม่ได้เชี่ยวชาญพอจะทำแมโครสำหรับการเปลี่ยนนี้เอง
ดูเหมือนเรื่องนี้เริ่มจาก Thierry พบปัญหาบางอย่างในพฤติกรรมของ register แล้วพยายามแก้
ข้อบกพร่องที่สำคัญที่สุดคือ เมื่อกด
C-x r SPCเพื่อเรียกsave-to-registerหลังจากนั้นไม่ว่าจะกดปุ่มอะไรต่อ ข้อความก็จะถูกบันทึกลง register ที่ตรงกับปุ่มนั้น โดยเฉพาะC-gซึ่งปกติเป็นปุ่มยกเลิกสากลของ Emacs กลับใช้ไม่ได้ในที่นี้ และจะกลายเป็นการบันทึกข้อความหรือตำแหน่งลง register^gแทน แม้เผลอกดjump-to-registerหรือinsert-registerผิด ก็ยกเลิกด้วยC-gหรืออย่างอื่นไม่ได้ ต้องเลือก register ให้ได้ก่อนเสมอประการที่สอง register สามารถเก็บข้อความ ตำแหน่ง หรือค่าว่างได้อย่างใดอย่างหนึ่ง
jump-to-registerใช้งานได้เฉพาะกับ register ที่เก็บตำแหน่ง ส่วนinsert-registerคาดหวังข้อความ Emacs มีพรีวิวของ register ที่ไม่ว่างตอนรันคำสั่งอยู่แล้ว แต่ไม่ได้แยกประเภทให้ชัด เช่น เอา register ที่มีสตริงไปแสดงเป็นตัวเลือกของjump-to-registerด้วยThierry พยายามแก้ปัญหาเหล่านี้พร้อมกับ feedback จาก code review และผู้รีวิวก็มองว่านี่เป็นการเปลี่ยนที่สำคัญ แม้จะเพิ่มการโต้ตอบขึ้นมาก็ตาม พวกเขาเห็นว่าการทำลายความเข้ากันได้ เช่น ต้องกด
RETเพิ่มหลังเลือก register ปกติ หรือเมื่อต้องการบันทึกลง register แปลก ๆ อย่าง^gก็เป็นราคาที่ยอมรับได้เมื่อเทียบกับประโยชน์ที่ได้ผู้เขียนต้นฉบับขอให้มีสวิตช์สลับระหว่างพฤติกรรมใหม่กับเก่า และได้รับคำตอบให้ส่งแพตช์มา แต่แพตช์ที่ส่งกลับไปนั้นดันย้อนการปรับปรุงทั้งหมดที่กล่าวมา และไปทำฟีเจอร์คนละอย่างคือ “ยืนยันก่อนเขียนทับ register ที่ไม่ว่าง” แบบอิงแฟลก Thierry ลองนำไปใช้และให้ feedback สั้น ๆ แต่ผู้เขียนตอบกลับประมาณว่า “ของแบบนั้นไม่จำเป็น”
ต่อมาพอมีคนใช้งานฟีเจอร์นี้มากขึ้น ก็เห็นชัดว่าความเชื่อของ Thierry และผู้รีวิวช่วงแรกที่ว่าผลกระทบของการเปลี่ยนแบบทำลายเดิมจะน้อยนั้นไม่ถูกต้อง Thierry จึงเริ่มทำแฟลกที่คงงานใหม่ไว้ แต่ก็ยอมให้ใช้โฟลว์แบบเดิมได้ด้วย โดยเฉพาะการตัด
RETเพิ่มออกดูจะไม่ใช่แก่นหลัก แต่เป็นผลข้างเคียงมากกว่าโดยรวมแล้วกระบวนการดูเหมือนทำงานได้ค่อนข้างดี และคนที่พยายามผลักการถกเถียงไปในทางไม่สนบริบท พร้อมท่าทีต่อต้านแฮ็กเกอร์แบบ “ถ้ามันพอใช้งานได้แล้วก็ห้ามเปลี่ยนไม่ว่าทางไหน” ดูจะใกล้เคียงกับฝ่ายผู้เขียนต้นฉบับมากกว่า
dyyหมายถึงการลบบรรทัดปัจจุบันแต่อีกมุมหนึ่ง นั่นอาจเป็นหลักฐานว่าเป็นมือใหม่ก็ได้
จากเมลลิงลิสต์เธรดนี้ ดูเหมือนว่าจะมี ตัวเลือก สำหรับย้อนพฤติกรรมดังกล่าว: https://yhetil.org/emacs/87h6kr9817.fsf@posteo.net/#t
ดูเหมือนว่าตัวเลือกนี้ถูกพูดถึงแล้วตั้งแต่ก่อนโพสต์ต้นฉบับจะถูกเผยแพร่ แต่อาจเป็นไปได้ว่าผู้เขียนไม่เห็น เรื่องนี้น่าจะแก้ปัญหาได้ แต่อาจยังมีบางจุดที่พลาดไป
แก้ไข: จากคำตอบของ ginko ด้านล่าง ดูเหมือนว่ายังต้องกดปุ่ม RETURN อยู่ดี
RETเพิ่ม หากต้องยืนยันการเขียนทับ registerhttps://yhetil.org/emacs/87a5qi1vui.fsf@posteo.net/
register-use-previewsดูเหมือนจะเป็น ตัวสลับ ของพฤติกรรมนี้แต่ก็มีการพูดถึงบั๊กว่าต่อให้ตั้งเป็น
neverในบาง workflow ก็ยังมีหน้าต่างยืนยันเด้งขึ้นมา ถ้ามันเป็นตัวเลือกจริง ความกังวลส่วนใหญ่ก็น่าจะคลี่คลายได้สำหรับ Emacs ควรยกระดับ muscle memory ให้เป็นเรื่องสำคัญระดับต้น ๆ
เพราะ muscle memory ที่สั่งสมไว้พังหมด กว่าจะใจเย็นลงได้ก็มีความคิดร้าย ๆ แวบมาไม่น้อย เรื่องนี้อาจดูเล็กน้อย แต่ก็พอเข้าใจได้ว่าทำไมอาชญากรรมอย่าง “ทรยศต่อ muscle memory” ถึงทำให้ปฏิกิริยาบานปลายไปถึงระดับ “fork you”
ใช้ได้กับทั้ง Google Maps หรือ iOS ไม่ต่างจาก Emacs
muscle memory ช่วยให้เราควบคุมซอฟต์แวร์แบบกึ่งอะซิงก์ได้โดย “ไม่ต้องมอง” และไม่ต้องคอยยืนยันด้วยสายตาทุกปฏิสัมพันธ์เล็ก ๆ น่าเสียดายที่ซอฟต์แวร์เดสก์ท็อปกลับมีแนวโน้มทำให้การใช้คีย์บอร์ดยุ่งยากขึ้นเรื่อย ๆ หรือถึงขั้นใช้ไม่ได้เลย
เป็น rant ที่ดี แต่การไม่อธิบายเลยว่าจริง ๆ แล้วกำลังพูดถึงฟีเจอร์อะไร ไม่ได้ช่วยให้โน้มน้าวได้มากนัก
Emacs register เป็น abstraction ที่เก่าแก่มาก register ทำงานเหมือนคลิปบอร์ดแยกต่างหากสำหรับเก็บและดึงค่าออกมาได้ และมี 62 ตัวที่ผูกกับสัญลักษณ์ ASCII หลัก
[a-zA-Z0-9]จึงให้คีย์บอร์ดอินเทอร์เฟซที่ทั้งยืดหยุ่นและรวดเร็ว ยังมีเรื่องสนุกอย่างการรัน keyboard macro จาก register ได้ด้วย มีคนใช้เยอะเหมือนกัน แต่ส่วนตัวผมไม่ใช้เหตุผลที่ผู้เขียนโกรธคือ default binding ถูกเปลี่ยน ทำให้งานที่เดิมทำได้ด้วยคีย์บอร์ดล้วน ๆ และใช้แค่ home row ตอนนี้มี modal UI มาแทรกอยู่ข้างหน้า ฟังดูเป็นข้อบ่นที่สมเหตุสมผล และถ้าฟีเจอร์ที่ฝังอยู่ใน muscle memory ของผมถูกเปลี่ยนแบบนี้ ผมก็คงหงุดหงิดเหมือนกัน
ถ้ามี modal dialog ยืนยันโผล่มาคั่นทุกครั้งระหว่างการเลือกกับการวาง และไม่มี setting ให้ย้อนกลับไปใช้พฤติกรรมเดิม ก็คงน่าหงุดหงิดแน่ ๆ แค่ทำพฤติกรรมเดิมเป็นตัวเลือกก็พอแล้ว เอาจริง ๆ ใช้โค้ดไม่กี่บรรทัดก็ทำได้
C-aใช้ไม่ได้ตามเดิมผมรู้จักคนที่ใช้ตัวอักษรธรรมดากับตำแหน่ง และใช้
C-ตัวอักษรกับข้อความ สำหรับบางคนอาจเป็นเคสประหลาดมาก แต่คนพวกนั้นน่าจะโกรธมากจริง ๆใน https://yhetil.org/emacs/8334wawfvg.fsf@gnu.org/ Eli บอกว่า “มีเสียงคัดค้านเข้ามาแล้ว เลยยังคุยกันต่อว่าพฤติกรรมที่เหมาะสมควรเป็นแบบไหน และพอได้ข้อสรุปแล้วค่อยคุยเรื่องค่าเริ่มต้น”
การตีความของผู้เขียนต้นฉบับไม่ค่อยดีนัก ถ้าผู้ใช้ต้องการความเสถียร ก็ควรอยู่บน release branch หรือ pin commit ของ master ไว้
ควรคาดหวังว่า development branch มีไว้ใช้พัฒนาฟีเจอร์ที่กำลังทำอยู่ และฟีเจอร์แบบนี้อาจต้องใช้เวลาขัดเกลา ถ้าตาม master ก็ต้องเจอการเปลี่ยนแปลงที่ทำลายความเข้ากันได้บ่อย ๆ และถ้ามันทำให้ workflow พัง ก็ควรชินกับการย้อนกลับไป commit ก่อนหน้า ทางเลือกที่ดีกว่าคืออยู่กับ release
หัวใจของ Emacs คือมันเป็น แพลตฟอร์มที่ปรับแต่งได้อย่างสุดขีด ดังนั้นถ้าไม่ชอบพฤติกรรมของฟีเจอร์ใด ก็แก้เองได้ด้วย Lisp ไม่กี่บรรทัด
การจะ fork ทั้งโปรเจกต์เพราะการเปลี่ยนฟีเจอร์ obscure อันเดียวมันไม่สมเหตุสมผลเลย ผมใช้ Emacs มาตั้งแต่ราวปี 1981 ตอนที่ยังทำด้วย TECO macro และก็ไม่เคยใช้ register
ไม่อย่างนั้นทุกครั้งที่แพลตฟอร์มเปลี่ยน ทุกคนก็ต้องคอยเขียนหรือซ่อมการปรับแต่งของตัวเองใหม่ทุกครั้ง
ถ้า patch นี้อยู่ต่อไปและมีใครอยากใช้แบบเดิมเป๊ะ ๆ ก็เท่ากับต้องเอา revert patch ไปใช้กับ Emacs local repository ของตัวเอง แล้วค่อยวางการเปลี่ยนแปลงของตัวเองทับลงไป ถ้าจะดึงการเปลี่ยนแปลงใหม่จาก upstream Emacs ทุกครั้งที่มันเปลี่ยน ก็ต้อง rebase
นั่นแหละคือ private fork ต้อง fork ไปตลอดและ rebase ไปตลอดกาล
จะใช้ monkey patch แบบหยาบ ๆ โดยโหลดไฟล์ของตัวเองแทนหรือหลังไฟล์ที่ shipped มาเพื่อ override function ก็ได้ แต่นั่นก็ยังเป็น fork แบบหนึ่งอยู่ดี ต้องเก็บสิ่งนี้ไว้เป็นโปรเจกต์ที่ไหนสักแห่ง และต้องพร้อมปรับเวลา monkey patch พังเพราะการเปลี่ยนแปลง
เลิกใช้ Emacs มา 20 ปีแล้ว แต่ก็เข้าใจได้ว่าการเปลี่ยนนี้ค่อนข้างทำลายล้าง
สิ่งที่ไม่เข้าใจคือทำไม Emacs ที่ชอบอวดว่ามี “everything including the kitchen sink” ถึงไม่เพิ่มตัวเลือกให้ย้อนกลับไปใช้พฤติกรรมเดิม
patch นั้นเพิ่ม flag เข้ามา แต่ก็ลบการปรับปรุงอื่น ๆ ออกไปด้วยทั้งหมด
น้ำเสียงของบทความค่อนข้างให้ความรู้สึกแบบ “neckbeard” มาก มันเป็นฟีเจอร์ obscure มาก ๆ ที่มี nerd ใช้กันอยู่แค่สามคน ไม่ใช่บันไดที่ขยับไม่ได้ของสุสานบรรพบุรุษ
แค่ผู้ดูแลที่ไม่ได้รับค่าจ้างเปลี่ยนมันนิดหน่อยโดยไม่ได้มาถามคุณก่อน ก็ไม่ได้แปลว่า “ทำ master พัง” เสมอไป ที่พูดถึงอยู่นี่คือ master ไม่ใช่ stable หรือ tagged release
แน่นอนว่าทางแก้เดียวที่เป็นไปได้คือต้องลองทำ Emacs fork หรือ reimplementation ขึ้นมาอีกตัว
รอบนี้ต้องสำเร็จแน่ ๆ และจะไม่กลายเป็นอะไรที่ไม่เกี่ยวข้องไปเลยเหมือนตัวอื่น ๆ แน่นอน
แต่จะดึงโปรเจกต์หลักมานั่งโต๊ะเจรจาได้หรือไม่นั้นอาจไม่สำคัญนัก ผู้เขียนต้นฉบับมีทั้งความสามารถและความตั้งใจจะถือ patch นี้ไว้ใน local repository ของตัวเองไปจนสุดทาง สิ่งเดียวที่ยังขาดในการทำ fork ให้เสร็จคือการเผยแพร่ local repository นั้นออกสู่สาธารณะ
บางทีอาจมีไว้เพื่อพยายามโน้มน้าวผู้ดูแล mainline ก็ได้