สคริปต์เชลล์ 3 ตัวสำหรับจับ weasel words, passive voice และคำซ้ำ

• จุดอ่อนที่เกิดซ้ำในงานเขียนเชิงเทคนิคสามารถถูกเปิดให้เห็นก่อนได้ด้วย การตรวจสอบอัตโนมัติ แทนที่จะให้คนคอยชี้ทุกครั้ง และบทความนี้แนะนำสคริปต์เชลล์ 3 ตัวที่นำไปผูกกับการ build บทความ LaTeX ได้
• เป้าหมายไม่ใช่การห้ามใช้ passive voice หรือสำนวนบางแบบ แต่คือการทำให้ผู้เขียนมองประโยคที่ถูกไฮไลต์แล้วเลือก ถ้อยคำที่ชัดเจนและแม่นยำกว่า
• weasel words อย่าง various, quite, surprisingly, very, extremely ทำให้ความแม่นยำพร่าเลือน จึงใช้ regular expression ตรวจจับเพื่อจำกัดจุดที่ต้องตรวจทาน
• การตรวจ passive voice จะมองหารูป -ed หรือ past participle ไม่ปกติหลัง be verb ส่วนการตรวจคำซ้ำจะจับคำเดียวกันที่อยู่ติดกันโดยไม่สนตัวพิมพ์เล็กใหญ่
• เมื่อรวมการตรวจทั้งสามไว้ใน make proof ก็สามารถรันซ้ำใน repository ของบทความได้ และช่วยลดกรณีที่ข้อผิดพลาดเล็ก ๆ สะสมจนอ่านแล้วรู้สึกว่า ขาดการพิสูจน์อักษร

---

ลดจุดอ่อนซ้ำ ๆ ในงานเขียนด้วยอัตโนมัติ

• ส่วนที่ยากเป็นพิเศษในการดูแลนักศึกษา Ph.D. คือ การสอนเขียน และปัญหาที่เกิดซ้ำสามารถใช้เครื่องมือกรองก่อนได้
• ปัญหา 3 อย่างที่สคริปต์เหล่านี้เล็งไว้คือ
  • การใช้ passive voice มากเกินไป
  • weasel words
  • lexical illusion หรือคำซ้ำที่สายตามักมองข้าม
• สคริปต์เหล่านี้ใช้โดยผสานเข้ากับระบบ build ของเอกสาร LaTeX
• กฎการเขียนย่อมมีข้อยกเว้น ดังนั้นเป้าหมายไม่ใช่การห้ามใช้โครงสร้างไวยากรณ์บางแบบ
• เมื่อประโยคถูกไฮไลต์ ผู้เขียนจะได้ตรวจสอบด้วยตนเองว่า “มีถ้อยคำที่ชัดเจนและแม่นยำกว่านี้หรือไม่”
• หากเป็นโปรแกรมเมอร์ คุณสามารถรู้จุดอ่อนซ้ำ ๆ ของตัวเอง และใช้ automation เพื่อลดจุดอ่อนนั้นได้

หนังสือที่น่าใช้อ้างอิงสำหรับงานเขียนเชิงเทคนิค

• The Elements of Style แม้จะไม่สมบูรณ์แบบ แต่ยังมีประโยชน์ในฐานะคู่มือสไตล์
  • ควรอ่านโดยคำนึงถึง คำวิจารณ์ จากผู้เชี่ยวชาญด้านภาษาศาสตร์
  • ในงานเขียนด้านวิทยาศาสตร์ วิศวกรรม และคณิตศาสตร์ การไม่มีสไตล์อาจแสดงออกมาอย่างรุนแรง
• Style: The Basics of Clarity and Grace ได้รับการแนะนำโดย Zachary Tatlock และภายหลังถูกมองว่าเป็นคู่มืออ้างอิงที่ดีกว่า Strunk and White
  • หากต้องเลือกเพียงเล่มเดียว หนังสือเล่มนี้ก็น่าเลือก
• The Chicago Manual of Style ใช้เป็นมาตรฐานในการยุติข้อถกเถียงเรื่องสไตล์
• A Manual for Writers of Research Papers, Theses, and Dissertations เทียบได้กับคู่มือ Chicago สำหรับงานเขียนเชิงเทคนิค

จุดที่ความแม่นยำและความชัดเจนรั่วไหล

• Olin Shivers สอนงานเขียนเชิงเทคนิคว่าเป็นการสร้างสมดุลระหว่าง ความแม่นยำ ความชัดเจน และการตลาด
• ระหว่างกระบวนการส่งบทความ จุดที่ความแม่นยำและความชัดเจนอ่อนลงในแบบที่ระบุได้เชิงกลไกจะปรากฏให้เห็น
  • weasel words
  • การใช้ passive voice มากเกินไป
• การสร้างสคริปต์เชลล์ที่จับการตลาดที่แย่ของแนวคิดทางวิทยาศาสตร์นั้นทำได้ยาก

การตรวจจับ weasel words

• Weasel words คือคำหรือวลีที่ดูดีแต่แทบไม่ส่งข้อมูล ทำให้ความแม่นยำของประโยคพร่าเลือน
• weasel words ที่พบบ่อยในงานเขียนของนักศึกษาแบ่งได้เป็น 3 ประเภท

• Salt and pepper words

  • นักศึกษาบัณฑิตใหม่ ๆ มักโปรย คำที่ดูเป็นเทคนิค ลงในประโยคเหมือนเครื่องปรุง แต่บางครั้งก็ไม่ได้ส่งข้อมูลจริง
  • ตัวอย่างหลักคือ various, a number of, fairly, quite
  • เมื่อตัดคำเหล่านี้ออก ประโยคจะแข็งแรงขึ้น
  • It is quite difficult to find untainted samples. → It is difficult to find untainted samples.
  • We used various methods to isolate four samples. → We isolated four samples.

• Beholder words

  • Beholder words คือคำที่ความหมายเปลี่ยนไปตามผู้อ่าน
  • ตัวอย่างคือ interestingly, surprisingly, remarkably, clearly
  • peer reviewer มักไม่ชอบถ้อยคำที่ตัดสินแทนผู้อ่าน
  • แทนที่จะเขียน False positives were surprisingly low. การเขียนแบบ To our surprise, false positives were low (3%). ซึ่งแสดงตัวเลขและผู้สังเกตจะดีกว่า

• Lazy words และ adverbs

  • Lazy words คือคำที่ใช้เพื่อหลีกเลี่ยงการระบุคุณลักษณะเชิงปริมาณ ทำให้งานวิทยาศาสตร์ดูไม่หนักแน่นและเหมือนยังไม่เสร็จ
  • ตัวอย่างที่แย่ที่สุดคือ very และ extremely ซึ่งยอมรับได้ยากในงานเขียนเชิงเทคนิค
  • ตัวอย่างอื่นคือ several, exceedingly, many, most, few, vast
  • ในงานเขียนเชิงเทคนิค adverbs มักดูเหมือน weasel words
  • ในงานเขียนเชิงเทคนิคของนักศึกษาบัณฑิตใหม่ ๆ การตัด adverbs ทั้งหมดออกมีแนวโน้มให้ผลสุทธิเป็นบวก
  • We offer a completely different formulation of CFA. สู้ We offer a different formulation of CFA. ไม่ได้

• สคริปต์ weasel words

  • สคริปต์ Bash กำหนดรายการ weasel words พื้นฐานเป็น regular expression และใช้ egrep -i -n --color ระบุตำแหน่งในไฟล์อินพุต
  • หากรายการพื้นฐานไม่เหมาะ สามารถใช้ไฟล์รายการทดแทนได้
    • $HOME/etc/words/weasels
    • $WORDSDIR/weasels
    • words/weasels
  • หากไม่มี argument จะพิมพ์วิธีใช้ในรูป usage: <script> <file> ...

ใช้ passive voice อย่างมีสติ

• ในงานเขียนเชิงเทคนิค passive voice ไม่ได้แย่เสมอไป
• อย่างไรก็ตาม งานเขียนเชิงเทคนิคที่เคยแก้ไขมากกว่าครึ่งสามารถดีขึ้นได้เพียงแค่ ตัด passive voice
  • นักศึกษามักใช้ passive voice มากเกินไปมากกว่าจะใช้ได้ดี
• passive voice ที่เป็นปัญหาคือกรณีที่มันซ่อนข้อมูลที่เกี่ยวข้องหรือเป็นคำอธิบาย
  • Termination is guaranteed on any input. ซ่อนข้อมูลที่เกี่ยวข้อง
  • Termination is guaranteed on any input by a finite state-space. ใส่ข้อมูลที่เกี่ยวข้องแล้ว แต่จุดเน้นผิดตำแหน่ง
  • A finite state-space guarantees termination on any input. มีข้อมูลที่เกี่ยวข้องและชัดกว่า
• เมื่อประธานไม่สำคัญจริง ๆ passive voice อาจดีกว่า
  • 4 mL HCl were added to the solution.
  • อย่างไรก็ตาม We added 4 mL HCl to the solution. ก็ไม่ได้ถือว่าเป็นปัญหาร้ายแรง

• คำถามเพื่อพิจารณา passive voice

  • เมื่อสคริปต์ไฮไลต์ passive voice ให้ตรวจสอบ 2 อย่าง
    • ผู้กระทำเกี่ยวข้องแต่ไม่ชัดเจนหรือไม่
    • หากเปลี่ยนเป็น active voice งานเขียนจะอ่านลื่นขึ้นหรือไม่
  • หากทั้งสองคำถามตอบว่า “ใช่” ให้เปลี่ยนเป็น active voice
  • หากมีเพียงคำถามแรกที่ตอบว่า “ใช่” ให้ระบุผู้กระทำให้ชัดเจน

• สคริปต์ passive voice

  • สคริปต์ Bash กำหนดรายการ irregular past participle ไว้ยาว ๆ
  • ค้นหา pattern ที่หลัง am|are|were|being|is|been|was|be มีช่องว่างและ \w+ed หรือ past participle ไม่ปกติตามมา
  • แสดงผลด้วย egrep -n -i --color พร้อมชื่อไฟล์และเลขบรรทัด

คำซ้ำและ lexical illusion

• เมื่อมีการขึ้นบรรทัดใหม่ คำซ้ำ อย่าง the the มักถูกสายตามองข้าม
• แค่เปลี่ยนการขึ้นบรรทัด คำซ้ำเดิมก็จะเห็นชัดขึ้น
• คำซ้ำเป็นปรากฏการณ์ที่เกิดขึ้นในกระบวนการเขียนเอกสารอิเล็กทรอนิกส์ และดูเหมือนเกิดจากอุบัติเหตุในการตัดและวาง
• เกิดบ่อยเป็นพิเศษกับ the
• คำซ้ำเพียงคำเดียวไม่ทำให้บทความถูกปฏิเสธ แต่เมื่อความผิดพลาดเล็ก ๆ อย่างสะกดผิดและคำซ้ำสะสมกัน ก็จะเผยให้เห็นว่า ขาดการพิสูจน์อักษร
• reviewer อาจตีความการพิสูจน์อักษรที่ไม่พอว่าเป็นการไม่เคารพเวลาและความใส่ใจของตน

• สคริปต์คำซ้ำ

  • สคริปต์ Perl ค้นหาคำซ้ำที่อยู่ติดกัน
  • อ่านไฟล์ทีละบรรทัด และแยกด้วยอักขระที่ไม่ใช่คำ
  • ข้ามช่องว่าง และเมื่อพบเครื่องหมายวรรคตอนจะรีเซ็ตสถานะของคำล่าสุด
  • เปรียบเทียบคำปัจจุบันกับคำก่อนหน้าในรูปตัวพิมพ์เล็ก หากเหมือนกันจะพิมพ์ในรูป ชื่อไฟล์:เลขบรรทัด คำ
  • exit code คือจำนวนคำซ้ำที่พบ

ผสานเข้ากับ Makefile

• วางสำเนา local ของสคริปต์แต่ละตัวไว้ในไดเรกทอรี bin/ ของ repository บทความแต่ละชิ้น
• เพิ่ม rule make proof ใน Makefile
• make proof จะรันการตรวจทั้งสามตามลำดับกับไฟล์ *.tex
  • sh bin/weasel *.tex
  • sh bin/passive *.tex
  • perl bin/dups *.tex

การตลาดของบทความและ peer review

• นักศึกษาบัณฑิตมักคิดในตอนแรกว่าเพียงเขียนความจริงทั้งหมดก็จะได้ตีพิมพ์
• แต่สิ่งที่เป็นจริงมีมากมาย และใน venue peer review ระดับสูงก็มีบทความที่ถูกต้องทางเทคนิคอยู่มากพอแล้ว
• peer review จึงใกล้เคียงกับบทบาทในการตัดสินว่าอะไรที่เป็นจริงและควรค่าแก่การรู้
• จากมุมมองนี้ reviewer คือผู้พิทักษ์ ความสนใจร่วมกัน ซึ่งเป็นทรัพยากรที่จำกัดที่สุดของชุมชนวิทยาศาสตร์
• หากจะทำการตลาดให้บทความ ต้องแสดงให้เห็นอย่างน่าเชื่อถือว่าแนวคิดนั้นมีคุณสมบัติพอที่จะเข้าถึงทรัพยากรดังกล่าว

เครื่องมือที่เกี่ยวข้องและแนวคิดต่อยอด

• Benjamin Beckwith ได้แรงบันดาลใจจากสคริปต์นี้และสร้างโหมด "writegood" สำหรับ Emacs
• John Regehr เสนอเครื่องมือง่าย ๆ สำหรับจับวลีไม่จำเป็นอย่าง Note that, Notice that
• คนอื่น ๆ เสนอให้ทำสคริปต์ที่จับการใช้ future tense ในงานเขียนเชิงเทคนิค

[GN⁺]

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

• สมัยที่ผมเขียน论文 แหล่งข้อมูลที่ช่วยปรับปรุงการเขียนได้คือ How to Write Mathematics ของ Paul R. Halmos และ Mathematical Writing ของ Donald E. Knuth และคณะ
  ถ้าอยากจับความรู้สึกของการสื่อสารที่ชัดเจนและแม่นยำ ผมมักเริ่มอ่านจาก Halmos ส่วนข้อเสนอแบบ “Bad/Better/OK” ทำให้นึกถึงการอภิปรายที่เคยเห็นในโน้ตประกอบการสอนของ Knuth และคณะ
  ในขั้นที่สาม ลินเตอร์แบบที่เสนอไว้อาจมีประโยชน์ในการจับส่วนที่หลุดรอดไป
  ผมมองว่าแหล่งข้อมูลเหล่านี้จำเป็นสำหรับคนที่เขียนในหัวข้อที่มีนิยามเข้ามาเกี่ยวข้องแม้เพียงเล็กน้อย

  • นอกจากคำแนะนำนั้น The Craft of Scientific Writing ของ M. Alley ก็ดีเช่นกัน

• ถ้าชอบบทความนี้และอยากรู้เพิ่มเติมเกี่ยวกับกระบวนการ เขียนวิทยานิพนธ์ปริญญาเอก อย่างมีประสิทธิภาพ ลองดู [1]
  จริง ๆ แล้วใครก็ตามที่อยากพัฒนาทักษะการสื่อสารก็ควรดู และถึงขั้นที่ผมคงไม่เสียดายเงินแม้ต้องจ่ายเพื่อเข้าถึงวิดีโอนี้
  [1] https://youtu.be/vtIzMaLkCaM

  • ถ้ามีรีโพซิทอรีที่รวบรวม “ทุกอย่างที่ควรรู้เมื่อเริ่มปริญญาเอก” ก็คงดี
    รวมถึงแหล่งข้อมูลดัง ๆ อย่าง phd grind ด้วย

• ผมเห็นด้วยกับตัวอย่างจำนวนมากได้ยาก
  เช่น ถ้าเปลี่ยน “It is quite difficult to find untainted samples” เป็น “It is difficult to find untainted samples” คำว่า quite difficult กับ difficult เฉย ๆ อ่านแล้วให้ความหมายต่างกันพอสมควร
  ไม่ใช่ว่าประโยคดีขึ้น แต่ความหมายเปลี่ยนไป
  อีกอย่าง การเขียนว่า “various methods” ให้ข้อมูลว่าไม่ได้ใช้วิธีเดียว แต่ในประโยคที่สองข้อมูลนั้นหายไป

  • ความหมายที่ “quite” สื่ออาจต่างกันมากขึ้นอยู่กับผู้อ่านหรือบริบท
    เวลาพูดจะเปลี่ยนไปมากตามน้ำเสียง และถ้าพูดอย่างเคร่งครัดมันใกล้กับ “ยากนิดหน่อย” แต่ในหลายที่ก็ใช้เหมือน “แทบเป็นไปไม่ได้”
    ผมไม่ได้คิดว่าการตัดคำออกเป็นสิ่งผิด แต่คิดว่าควรเปลี่ยนเป็น สำนวนเปรียบเทียบ ที่เฉพาะเจาะจงกว่านี้
  • เพราะอะไรทำนองนี้ สุดท้ายเราจึงต้องอ่าน เอกสารออกแบบยาว 30 หน้า ที่จริง ๆ แล้วพูดเนื้อหาเดียวกันได้ใน 3 หน้า
    โดยเฉพาะในเอกสารเทคนิค ลองพยายามทำความเข้าใจดูว่าทำไมผู้คนถึงเกลียดการเขียนแบบประดับประดาขนาดนั้น
    ถ้าอ่าน论文หรือเอกสารออกแบบมาก ๆ สำนวนแบบนั้นทำให้ชีวิตลำบาก
  • ถ้าอยากบอกว่าใช้วิธีอื่น ๆ ก็เขียนไปเลยว่าทำอะไรจริง ๆ
    เขียนแบบ “We isolated four samples using the following methods…” จะชัดเจนกว่า
  • ตัวอย่างส่วนใหญ่ดูแย่มาก
    นี่เป็นหนึ่งในเหตุผลที่论文อ่านยาก แม้จะพูดเรื่องง่าย ๆ ก็ตาม
    มันยึดติดกับ สำนวนเชิงทางการ ที่แข็งทื่อซึ่งไม่มีใครชอบ พร้อมกับตัดเบาะแสเชิงบริบทที่ละเอียดแต่สำคัญออกไป

• ถ้ากำลังหาเครื่องมือแบบนี้เพิ่มเติม ก็ควรลองดู vale.sh
  สามารถเพิ่มแนวทางด้านสำนวนได้หลายแบบ รวมถึงการหลีกเลี่ยงคำที่คลุมเครือ
  GitHub Action ที่ใช้รัน vale บนเว็บไซต์ตอนเปิด PR อยู่ที่นี่: https://github.com/FusionAuth/fusionauth-site/blob/main/.git...
  การตั้งค่าอยู่ที่นี่: https://github.com/FusionAuth/fusionauth-site/tree/main/conf...
  มันช่วยบังคับใช้สไตล์การเขียนได้ แต่คงยังไม่ได้ใช้ความสามารถของมันอย่างเต็มที่

  • Vale.sh ดูค่อนข้างดี
    ตอนนี้ผมกำลังแก้ไขหนังสือฉบับพิมพ์ครั้งที่ 3 และบทความบนเว็บไซต์หลายชิ้น น่าจะนำมาใช้ได้เป็นประโยชน์

• ผมให้ Claude ย้าย สคริปต์ Bash เหล่านั้นมาเป็นเว็บ UI เพื่อให้วางโค้ดแล้วดูผลลัพธ์ได้ทันที: https://tools.simonwillison.net/writing-style
  บันทึกการคุยกับ Claude อยู่ที่นี่: https://gist.github.com/simonw/e9902ed1cbda30f90db8d0d22caa0...

  • ดูเหมือนจะทำงานไม่ถูกต้อง
    น่าจะมีอะไรแปลก ๆ แถวการจับคู่แพตเทิร์นตัวที่สอง
    เช่น ถ้าใส่ “It is quite difficult to find untainted samples. We used various methods to isolate four samples.” มันจะเจอ “quite” ใน “is quite difficult to find untainted samples.” และเจอ “various” ในสตริงว่าง
    แต่ก็ยังชอบเครื่องมือ HTML/JS แบบทำเร็ว ๆ อย่างนี้อยู่ดี
  • ผมสงสัยว่าทำไมไม่ให้ Claude ตรวจงานเขียนเองไปเลย แทนที่จะให้ Claude เขียนสคริปต์ Bash ที่เปราะบางและจำกัดกว่า
    ยังให้ Claude เขียน พรอมป์ต์ ที่ทำงานแบบเดียวกันหรือทำได้ดีกว่าเองก็ได้
    Bash กับ Perl เป็นเครื่องมือที่แย่มากสำหรับงานแบบนี้ เหมือนใช้เทปกาวกับหมากฝรั่ง และนี่แหละคืองานที่ Claude ถนัดที่สุด
    แทนที่จะแค่ทำเครื่องหมายปัญหา มันสามารถชั่งน้ำหนักทางเลือกและเสนอคำแก้ไขได้ อีกทั้งไม่มีความไม่ตรงกันของ regex แปลก ๆ ที่ก่อให้เกิด false positive, false negative หรือข้อผิดพลาดในการพาร์ส

• ใน Unix ยุคแรกมีคำสั่ง diction และ style ที่ทำงานคล้ายกัน
  ดาวน์โหลดได้จาก GNU และมีใน Homebrew ด้วย
  https://www.gnu.org/software/diction/
  เท่าที่จำได้มันไม่ได้ยอดเยี่ยมมากนัก และชุดเครื่องมือนี้ก็คงทำได้ในระดับใกล้เคียงกัน

• ในสาขาของผม คุณภาพของงานเขียน อยู่ลำดับความสำคัญต่ำสุด แถมยังต่ำกว่าการประเมินการสอนด้วยซ้ำ
  ถึงจะให้ความสำคัญกับประโยคที่ชัดเจนและกระชับก็จริง แต่ถ้าเป็นนักศึกษาบัณฑิตศึกษา ผมคิดว่าการฝึกความสามารถในการนำเสนอ โดยเฉพาะต่อหน้าคำถามที่ไม่เป็นมิตร และน่าเศร้าที่รวมถึงความสามารถในการประจบสอพลอ น่าจะช่วยได้มากกว่า
  ใช่ครับ มีประสบการณ์ขมขื่นอยู่ :p

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

• คำกล่าวที่ว่า “ในการทำการตลาดให้บทความวิจัย ผู้เขียนต้องเสนอเหตุผลที่น่าเชื่อถือว่าไอเดียของตนสมควรได้เข้าถึงทรัพยากรนั้น” ก็หมายความว่าวารสารวิชาการจะเต็มไปด้วยบทความที่ขายได้ดีที่สุด ไม่ใช่ไอเดียที่สำคัญที่สุด
  อย่างที่ผู้เขียนบอก องค์ประกอบผิวเผินอย่างการพิมพ์ผิดที่หาเจอยากก็อาจกลายเป็นปัจจัยชี้ขาดได้ เพราะผู้ประเมินสามารถค้นพบได้
  ควรเลิกแสร้งว่ามีความเป็นกลาง แล้วยอมรับว่าวารสารสะท้อนรสนิยมและทัศนะของบรรณาธิการ
  หรือไม่ก็อัปโหลดทุกอย่างไว้ในที่มาตรฐานอย่าง arxiv ก็ได้
  การอัปโหลด PDF ไม่ได้มี ทรัพยากรที่ขาดแคลน อะไร

  • คนที่ตัดสินใจจริง ๆ น่าจะเป็น ผู้ประเมิน มากกว่าบรรณาธิการ
    ถ้าผู้ประเมินให้คะแนนดีหรือคะแนนกลาง ๆ บทความก็จะได้รับการตีพิมพ์ไปตามนั้น แต่ถ้าผู้ประเมินวิจารณ์บทความอย่างรุนแรง บรรณาธิการก็ต้องตั้งใจพิจารณาและตัดสินว่าผู้เขียนได้ตอบสนองต่อข้อไม่พอใจของผู้ประเมินอย่างเพียงพอหรือไม่
    ถึงอย่างนั้น คนที่เรียกร้องมาตรฐานก็ยังคงเป็นผู้ประเมิน ไม่ใช่บรรณาธิการ
  • ไหน ๆ แล้วก็อยากให้ปรับปรุง ระบบการอ้างอิง ด้วย ให้รายการอ้างอิงกลายเป็นไฮเปอร์ลิงก์ และเข้าถึงผลลัพธ์ที่เป็นโค้ดได้ด้วย

• มีประโยชน์สำหรับคนที่ไม่ใช้ emacs ด้วยเหตุผลที่ไม่อาจทราบได้
  เวิร์กโฟลว์แบบรันแล้วกลับมาแก้ไขอีกครั้งค่อนข้างยุ่งยาก จนอาจทำให้สร้างเวิร์กโฟลว์ที่ดีได้ยาก
  ผู้เขียนยกเครดิตให้ emacs “writegood” แต่ปลั๊กอินตรวจสไตล์การเขียนที่ผมชอบที่สุดเป็นการส่วนตัวคือ “artbollocks-mode”

• บทความที่เกี่ยวข้อง:
  Shell scripts to improve your writing - https://news.ycombinator.com/item?id=13295530 - มกราคม 2017, 55 ความคิดเห็น
  Shell scripts to improve your writing, or "My advisor rewrote himself in bash." - https://news.ycombinator.com/item?id=1529166 - กรกฎาคม 2010, 31 ความคิดเห็น