Microsoft Edit

 (github.com/microsoft)
3 คะแนน โดย GN⁺ 2025-06-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Microsoft Edit เป็นเอดิเตอร์สำหรับงานแก้ไขที่เรียบง่าย โดยคารวะต่อ classic MS-DOS Editor พร้อมให้ส่วนติดต่อสมัยใหม่และการควบคุมอินพุตคล้าย VS Code
  • เป้าหมายคือการมอบ เอดิเตอร์ที่เข้าถึงได้ง่าย ซึ่งผู้ใช้ที่ไม่คุ้นเคยกับเทอร์มินัลก็ใช้งานได้สะดวก
  • บน Windows ติดตั้งได้ด้วย WinGet, macOS ด้วย Homebrew, ส่วน Linux ติดตั้งได้ด้วยสคริปต์ติดตั้งในกรณีที่ดิสโทรไม่มีไบนารีให้หรือเมื่อต้องการบิลด์เอง
  • สร้างด้วย Rust และแนะนำให้ตั้งค่า nightly Rust ในลักษณะที่ช่วยลดขนาดไบนารีได้มากและปรับปรุงประสิทธิภาพได้เล็กน้อย
  • ผู้ดูแลแพ็กเกจได้รับคำแนะนำให้ใช้ชื่อ msedit แทน edit เนื่องจากอาจชนกับชื่อไฟล์ปฏิบัติการอื่น และการตั้งค่าไลบรารี ICU มีผลต่อฟีเจอร์ค้นหา/แทนที่

เป้าหมายและลักษณะของ Microsoft Edit

  • Edit เป็นเอดิเตอร์เรียบง่ายที่มุ่งเป็น “simple editor for simple needs”
  • คารวะต่อ classic MS-DOS Editor พร้อมทั้งให้ส่วนติดต่อสมัยใหม่และการควบคุมอินพุตคล้าย VS Code
  • มุ่งเป็น เอดิเตอร์ที่เข้าถึงได้ ซึ่งผู้ใช้ที่ไม่คุ้นเคยกับเทอร์มินัลก็ใช้งานได้ง่าย

วิธีติดตั้ง

  • ดาวน์โหลดไบนารีได้จาก Releases page

  • Windows

    • เวอร์ชันล่าสุดติดตั้งได้ด้วย WinGet
    winget install Microsoft.Edit

  • Linux

    • หากดิสโทรไม่มีไบนารีให้ หรือถ้าต้องการบิลด์เอง สามารถใช้สคริปต์ติดตั้งได้
    • ข้อกำหนดที่ต้องมีคือ Rust, C compiler, ICU, curl หรือ wget และ tar
    • การติดตั้งค่าเริ่มต้นจะติดตั้ง msedit ไว้ที่ ~/.local/bin
    curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/microsoft/edit/… | sh
    • แฟล็กเพิ่มเติม --dev จะบิลด์โดยตรงจากสาขา main และ --system จะติดตั้งไว้ที่ /usr/local/bin
    curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/microsoft/edit/… | sh -s -- --dev --system

  • macOS

    • เวอร์ชันล่าสุดติดตั้งได้ด้วย Homebrew
    brew install msedit

วิธีบิลด์

  • การบิลด์ต้องติดตั้ง Rust และ clone repository
  • หากใช้ nightly Rust ให้บิลด์ release ด้วยคำสั่งต่อไปนี้ 
    cargo build --release --config .cargo/release.toml
  • หากใช้ stable Rust แนะนำให้ตั้งค่าตัวแปรสภาพแวดล้อม RUSTC_BOOTSTRAP=1 แล้วทำตามคำแนะนำการบิลด์แบบ nightly
    • วิธีนี้ช่วยลดขนาดไบนารีได้มากและปรับปรุงประสิทธิภาพเล็กน้อย
  • หากต้องการบิลด์ด้วย stable Rust โดยไม่ตั้งค่าเพิ่มเติม ให้ใช้คำสั่งต่อไปนี้ 
    cargo build --release

ตัวเลือกการตั้งค่าการบิลด์

  • สามารถปรับการตั้งค่าระหว่างบิลด์ได้ด้วยตัวแปรสภาพแวดล้อม
  • EDIT_CFG_ICU* เกี่ยวข้องกับการตั้งค่า ชื่อไลบรารี ICU และแนะนำให้ผู้ดูแลแพ็กเกจ Linux ตรวจสอบตัวเลือกนี้
  • EDIT_CFG_LANGUAGES ระบุรายการภาษาที่จะรวมไว้ในการบิลด์ โดยคั่นด้วยคอมมา
    • ภาษาที่ใช้ได้อยู่ใน i18n/edit.toml

ข้อควรระวังสำหรับผู้ดูแลแพ็กเกจ

  • ชื่อไฟล์ปฏิบัติการมาตรฐานคือ edit และชื่อทางเลือกคือ msedit
  • เนื่องจากชื่อ edit อาจชนกับคำสั่งที่มีอยู่ จึงแนะนำให้ใช้ msedit เป็นชื่อแพ็กเกจและชื่อไฟล์ปฏิบัติการ
  • ควรหลีกเลี่ยงชื่ออย่าง ms-edit
  • หากเป็นไปได้ แนะนำให้กำหนด alias ชื่อ edit

การตั้งค่าที่เกี่ยวข้องกับ ICU

  • โปรเจกต์นี้พึ่งพา ไลบรารี ICU แบบเลือกได้สำหรับฟีเจอร์ค้นหาและแทนที่
  • โดยค่าเริ่มต้นจะค้นหาชื่อไลบรารี ICU ตามแพลตฟอร์ม
    • Windows: icuuc.dll, icuin.dll
    • macOS: libicucore.dylib
    • Linux และอื่น ๆ: libicuuc.so, libicui18n.so
  • หาก SONAME ของสภาพแวดล้อมติดตั้งแตกต่างออกไป ต้องตั้งค่าตัวแปรสภาพแวดล้อมตอนบิลด์
    • EDIT_CFG_ICUUC_SONAME: เช่น libicuuc.so.76
    • EDIT_CFG_ICUI18N_SONAME: เช่น libicui18n.so.76
  • โดยค่าเริ่มต้นจะถือว่า ICU symbols ถูก export ในรูปแบบอย่าง u_errorName โดยไม่มี prefix _ และไม่มี suffix เวอร์ชัน
  • ในสภาพแวดล้อมที่ใช้รูปแบบ symbol อื่น สามารถใช้ตัวแปรสภาพแวดล้อมเพิ่มเติมได้
    • EDIT_CFG_ICU_CPP_EXPORTS=true: ค้นหา C++ symbols อย่าง _u_errorName และเปิดใช้เป็นค่าเริ่มต้นบน macOS
    • EDIT_CFG_ICU_RENAMING_VERSION=76: ค้นหา symbols อย่าง u_errorName_76
  • เมื่อตั้งค่า EDIT_CFG_ICU_RENAMING_AUTO_DETECT=true ไฟล์ปฏิบัติการจะพยายามตรวจจับค่า renaming version ตอนรันไทม์
    • วิธีนี้ ICU ไม่ได้รองรับอย่างเป็นทางการ จึงไม่แนะนำให้พึ่งพา
    • บน UNIX ยกเว้น macOS จะเปิดใช้เป็นค่าเริ่มต้นเมื่อไม่มีตัวเลือกอื่น
  • การทดสอบการตั้งค่าบิลด์ให้รัน cargo test พร้อมแฟล็ก --ignored 
    cargo test -- --ignored

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

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

 
GN⁺ 2025-06-26
ความคิดเห็นบน Hacker News

  • ความสนใจมีมากถึงขั้นที่โพสต์นี้ถูกนำขึ้นมา สามครั้งในหนึ่งสัปดาห์

    1. ผู้เขียนเอง - https://news.ycombinator.com/item?id=44034961
    2. Ubuntu Publication - https://news.ycombinator.com/item?id=44306892
      และโพสต์ครั้งนี้

  • เมื่อก่อนผมเคยแนะนำ micro ให้กับกลุ่มผู้ใช้เป้าหมายของเอดิเตอร์ตัวนี้ ตอนนี้เลยสงสัยว่าควรเปลี่ยนไหม

    1: https://micro-editor.github.io/

    • ดูเหมือนไม่จำเป็นต้องเปลี่ยน
      อย่างน้อยตอนลองใช้ทันที edit ก็ยังไม่รองรับ syntax highlighting เป็นค่าเริ่มต้นด้วยซ้ำ
    • ครั้งล่าสุดที่ตรวจดู micro ถ้าดูแค่ขนาดไบนารีก็น่าจะเรียกว่า macro ได้เลย
    • ยังมี dte ด้วย เป็นเอดิเตอร์ที่เบามากซึ่งเล็งจุดเดียวกันพอดี แต่มีฟีเจอร์มากกว่า เช่น รองรับ Unicode, คีย์ไบน์ดิงแบบ CUA
      ผมใช้เป็นเทอร์มินัลเอดิเตอร์แทน nano
      [1]: https://craigbarnes.gitlab.io/dte/
    • Micro เป็นเอดิเตอร์ที่ยอดเยี่ยมสำหรับใช้แทนอะไรอย่าง nano แต่คงไม่เหมาะจะเป็นตัวแทนของ edit เพราะ edit นั้นพื้นฐานมาก ขณะที่ micro ค่อนข้าง ขยายได้ ด้วย Lua
      จัดการไฟล์ใหญ่ได้ค่อนข้างดีด้วย
    • บน Windows ก็ติดตั้งได้เพียงแค่ "winget install zyedidia.micro" ชวนให้นึกถึง เอดิเตอร์ยุค 8 บิต/16 บิต ในช่วงเวลาใกล้เคียงกัน

  • ผมสงสัยจริง ๆ ว่าโปรเจกต์แบบนี้ได้รับการอนุมัติในองค์กรขนาดอย่าง Microsoft ได้อย่างไร เป็นโปรเจกต์ข้างเคียงของนักพัฒนาบางคน หรือเป็นส่วนหนึ่งของโรดแมปผลิตภัณฑ์กันแน่
    เขาโน้มน้าวผู้บริหารให้ใช้เวลากับเรื่องนี้ได้อย่างไร?

    • ตามคำอธิบาย พวกเขาต้องการ เอดิเตอร์ข้อความแบบ command line ที่ทำงานได้ในการติดตั้ง Windows Core Server
      Windows มี SSH Server รวมมาด้วยมาพักใหญ่แล้ว จึงสามารถจัดการได้ทั้งหมดผ่าน SSH อย่างเดียว และต้องการ เอดิเตอร์แบบไม่มีโหมด ที่แอดมิน Windows ซึ่งไม่มีประสบการณ์กับ vi ก็ใช้ได้
    • เอดิเตอร์ข้อความเป็นเป้าหมายที่เป็นธรรมชาติมากสำหรับ การผสานรวม Copilot
    • แต่ละกลุ่มต้องทำอะไรสักอย่างและต้องคิดไอเดียออกมา บางครั้งก็มาจากทิศทางของผู้บริหารอย่าง “จงใช้ Copilot” บางครั้งก็ต่อยอดจากไอเดียในงานอย่าง hackerdayz
      บางกรณีคนสายเทคนิคในองค์กรวิจัยก็เริ่มทำแบบมีเวลาว่าง และบางกรณีก็ได้รับเงินทุนหลังผ่านการวิเคราะห์เชิงลึกและการโต้แย้งหลายรอบ
      ดูจากจำนวนผู้ร่วมพัฒนาที่นี่ โปรเจกต์นี้น่าจะเป็น การลงทุนเชิงกลยุทธ์ มากกว่า ไม่น่าใช่สิ่งที่เกิดขึ้นในชั่วข้ามคืน

  • edit.com ต้นฉบับใน DOS 6.22 และต่อมา 7.0 ช่วง Win95 เป็น IDE แรกของผม ผมเริ่มจาก qbasic จึงคุ้นกับอินเทอร์เฟซที่คล้ายกันหรือเหมือนกัน และยังใช้ edit.com ต่อเนื่องตอนเรียน C/C++ ด้วย djgpp
    “ไฟล์โปรเจกต์” ของผมคือ e.bat ที่มี edit file1.cpp file2.cpp file3.cpp อยู่ และผมใช้มันเพราะมี การรองรับหลายไฟล์ ที่ค่อนข้างดี สลับได้ง่ายด้วย Alt-1,2,3 ทุกวันนี้ผมก็ยังรีแมปคีย์ไบน์ดิงของเอดิเตอร์ให้สลับไฟล์ด้วย Alt/Cmd-1,2,3 และพยายามรักษา “ชุดที่ใช้งานอยู่” ให้เล็ก โดยมีไฟล์ไม่กี่ไฟล์อยู่ข้างหน้า
    มันไม่มี syntax highlighting และพฤติกรรมการเยื้องก็ไม่ค่อยดี จึงไม่ใช่โค้ดเอดิเตอร์ที่ยอดเยี่ยม ดังนั้นช่วงต้นอาชีพผมจึงใช้การเยื้องด้วยช่องว่างสองช่อง ซึ่งพิมพ์ด้วยมือง่ายและไม่ดูเหมือนแท็บ ถึงอย่างนั้นก็ยังให้ความรู้สึกว่าได้แตะโค้ดโดยตรงมาก
    ผมรู้ว่าคนอื่นใช้เอดิเตอร์อย่าง qedit กันเยอะ แต่แปลกที่มันไม่เข้ามือ และเอดิเตอร์แบบ Unix บน DOS ก็รู้สึกขัด ๆ
    ลองใช้สั้น ๆ แล้วดูเหมือนว่าจะรองรับหลายบัฟเฟอร์ แต่ดูเหมือนจะสลับบัฟเฟอร์ด้วยคีย์ไบน์ดิงแบบเดียวกันไม่ได้

    • เรื่องแบบนั้นควรเปิดเป็น issue ไว้ สิ่งเหล่านี้ถ้าเข้าไปตั้งแต่ช่วงแรกก็มีโอกาสถูกนำไปปรับใช้
      และมันไม่ได้แค่คล้ายกัน แต่เหมือนกันตามตัวอักษรเลย EDIT.COM แค่เรียก QBASIC ด้วยแฟล็กพิเศษ และก็สามารถเรียก QBASIC โดยตรงพร้อมแฟล็กนั้นได้ด้วย อย่างที่พูดไว้ใน https://news.ycombinator.com/item?id=44037509 ผมเคยลองทำแบบนั้นจริง ๆ เพื่อความสนุก
    • ไม่มี syntax highlighting แต่ถ้าจะให้พูดโดยไม่มีคำที่ดีกว่านี้ มันมี syntax capitalization
      ถ้าพิมพ์ทั้งบรรทัดเป็นตัวพิมพ์เล็กแล้วกด Enter มันจะเปลี่ยนคำสงวนให้เป็นตัวพิมพ์ใหญ่โดยอัตโนมัติ ไม่ได้ยิ่งใหญ่อะไร แต่ก็ช่วยได้
    • หลังยุค copy con แล้ว edit นี่เป็นผู้กอบกู้จริง ๆ

  • มีหลายจุดที่ชอบ อย่างแรกคือ รายการ dependency ว่างเปล่า แค่นั้นก็โน้มน้าวผมได้แล้ว
    ทำงานได้ดีมาก ไม่น่าเชื่อว่าพวกเขาสร้าง TUI ทั้งชุดสำหรับสิ่งนี้ขึ้นมาเอง ตั้งแต่ file browser ไปจนถึง dialog box อยากเอาไปใช้กับโปรเจกต์ของตัวเองเหมือนกัน แต่สงสัยว่าจะง่ายแค่ไหน ถ้ามีคนเกี่ยวข้องกับโปรเจกต์นี้อยู่ที่นี่ ก็อยากรู้ด้วยว่าทำไมไม่ใช้ Ratatui
    คุณภาพโค้ดก็อยู่ระดับยอดเยี่ยม และผมพูดได้แค่คำเดียว: Bravo!

    • ถ้าไม่นับ development dependencies บางตัวที่ช่วยให้ทดสอบง่ายขึ้น ก็เรียกได้ว่า ไม่มี dependency จริง ๆ
      สำหรับของที่จะถูกแจกเป็นเครื่องมือพื้นฐานให้แอดมินใช้บนระบบปฏิบัติการอย่าง Windows นี่เป็นตัวเลือกที่สมเหตุสมผล ดูภูมิหลังเกี่ยวกับการ “ทำเอง” เพิ่มเติมได้จากคำตอบของ lhecker
      [1]: https://news.ycombinator.com/threads?id=lhecker

  • เมื่อประมาณหนึ่งเดือนก่อน ได้ยินมาว่า Microsoft มี ดิสโทร Linux ของตัวเอง เพื่อให้ผู้ใช้ Windows รู้สึกคุ้นเคยมากขึ้น เท่าที่จำได้เป็นการตั้งค่า GNOME ที่ค่อนข้างเรียบง่าย เลยไม่มีอะไรพิเศษนัก
    แปลกใจที่ Microsoft ไม่ใช้โอกาสนี้สร้างดิสโทร Linux เฉพาะของ Microsoft โดยใส่ PowerShell แทน bash, ใส่ Edit alongside ตัวเลือกอย่าง vim·nano และในชุดติดตั้งสำหรับนักพัฒนาก็รวม .NET กับ Visual Studio Code ไว้ด้วย
    มันอาจถูกใช้เป็นการติดตั้ง WSL เริ่มต้นได้ด้วย คงไม่ชนะสงครามกับดิสโทรแบบคลาสสิกอย่าง Ubuntu หรือ Debian แต่เพราะผู้ใช้ Windows มีจำนวนมาก ก็น่าจะได้ส่วนแบ่งระดับหนึ่งและกลายเป็นตัวเลือกที่พบได้บ่อย
    Microsoft อาจควบคุมเคอร์เนล Linux ไม่ได้ แต่ควบคุม user space ได้ ลองจินตนาการดูว่าถ้าทำให้แอปพลิเคชันของตัวเองถูกติดตั้งมาเป็นค่าเริ่มต้นในดิสโทรยอดนิยมได้จะเป็นอย่างไร
    Microsoft Edit ก็ใช้บน Linux ได้เช่นเดียวกับ PowerShell และอื่น ๆ ถ้าเล่นไพ่ได้ดีเมื่อสัก 10 ปีก่อน ตอนนี้ดิสโทรของพวกเขาอาจติด 5 อันดับแรกไปแล้ว เพราะผู้ใช้ Windows จำนวนมากใช้ผ่าน WSL
    บริษัทใหญ่สามารถยัดร่องรอยของตัวเองเข้าไปในพื้นที่ส่วนตัวของผู้ใช้ได้ ตอนนี้ก็แค่ให้ Microsoft Edit เปิด Co-Pilot เป็นค่าเริ่มต้นก็พอ

    • เมื่อเวลาผ่านไป ผมคิดว่ามีความเป็นไปได้สูงที่ Microsoft จะย้ายไป Linux อย่างน้อยก็ฝั่ง Windows Server และ Windows แบบฝังตัว จากนั้น Windows เดสก์ท็อปก็อาจค่อย ๆ เปลี่ยนไป หรือแบ่งเป็นตัวเลือกอย่าง Windows Legacy กับ Windows “Linux Workstation”
      อาจเป็นรูปแบบที่วาง “ซูเปอร์” WINE บางอย่างไว้บนเคอร์เนล Linux และสำหรับบางโปรแกรมก็ให้ fallback เป็น Windows แบบคลาสสิกใน virtual machine ที่ผสานรวมอย่างแนบแน่น
      แต่ปัญหาคือเคอร์เนล NT มีหลายส่วนที่ดีกว่าเคอร์เนล Linux ในเชิงการออกแบบ เช่น เคอร์เนล NT สามารถกู้คืนได้แม้ไดรเวอร์ GPU จะล่มสนิท แต่ Linux น่าจะลำบากพอสมควรในสถานการณ์แบบนั้น ไดรเวอร์อื่น ๆ ก็คล้ายกัน
      อย่างไรก็ตาม Windows กำลังกลายเป็น หนี้สิน มากกว่าสินทรัพย์สำหรับ Microsoft มากขึ้นเรื่อย ๆ โดยเฉพาะในฝั่งเซิร์ฟเวอร์ แหล่งรายได้หลักคือ Azure กับ Office 365 และยังเติบโตเป็นเลขสองหลัก ขณะที่การเติบโตของไลเซนส์ Windows นั้นหยุดนิ่ง
      อย่างน้อยก็น่าจะมีเวอร์ชันอย่าง Windows Server บน Linux และ Windows Workstation บน Linux ออกมา
    • เหตุผลที่ WSL มีอยู่ก็เพราะนักพัฒนาในองค์กรต้องการ วิธีรัน Linux
      ฝ่าย IT support และ technical support โดยทั่วไปไม่ค่อยรู้จัก Linux และไม่อยากซัพพอร์ตด้วย WSL แก้ปัญหานี้ได้
      นักพัฒนาส่วนใหญ่ไม่ได้อยากใช้ Linux เอง หลายคนยังใช้เทอร์มินัลไม่ค่อยเป็นและพึ่งพาเครื่องมือ GUI
    • ถ้าแปลกใจที่ Microsoft ไม่ทำดิสโทร Linux ของตัวเอง ความพยายามครั้งสุดท้ายก็ไม่ได้ไปได้สวยนัก ชื่อของมันคือ Xenix
    • ผมคิดว่าการจดจำชื่อช่วยได้ นักพัฒนาไม่อยากติดตั้งดิสโทรที่ไม่เคยได้ยินชื่อ แต่ยอมติดตั้ง Ubuntu
      ถ้า WSL รองรับ Ubuntu ก็ใช้ประโยชน์จากการรับรู้นั้นได้
    • ดูเหมือนจะสับสนระหว่าง Azure Linux (เดิมคือ CBL-Mariner) ซึ่งเป็นดิสโทร Linux ตัวหลักของ Microsoft กับสกินสภาพแวดล้อมเดสก์ท็อป Linux ที่หน้าตาเหมือน Windows ซึ่งผู้คนทำกันมานานแล้ว
      Azure Linux เป็นระบบปฏิบัติการที่ Microsoft ซัพพอร์ตสำหรับใช้กับคอนเทนเนอร์, VM, เซิร์ฟเวอร์ ฯลฯ

  • นี่ดูเหมือนโปรเจกต์ที่ทำขึ้นเพราะ “อยากลองทำดู” เฉย ๆ ผมเข้าใจนะ เพราะผมเองก็เคยทำอะไรทำนองนี้บ่อย ๆ เพื่อทำความเข้าใจว่ามีอะไรเกิดขึ้น
    แต่การเขียน Turbo Vision ใหม่ด้วย FPC แล้วคอมไพล์ไปหลาย target มีมาตั้งแต่ 20 ปีก่อนแล้ว Turbo Vision อาจเป็นไลบรารี windowing ใน text mode ที่ดีที่สุดเท่าที่มีอยู่
    ส่วนที่น่าสนุกเริ่มขึ้นเมื่อสามารถแมปหน้าจอข้อความทั้งหน้าจอเข้ากับอาร์เรย์แบบนี้ได้:
    var
    Screen: Array[1..80,1..25] Of Byte Absolute $B800; // or something like that as i recall
    สิ่งที่ Turbo Vision นำเข้ามาคือหน้าต่าง modal/non-modal ที่ย้ายได้ โดยพื้นฐานแล้วเป็นโครงสร้างที่เขียนอาร์เรย์นั้นซ้ำไปเรื่อย ๆ ในลูป และมันค่อนข้างตอบสนองเร็ว ผมทำเงินจากไลบรารีนั้นได้เยอะมาก

    • สำหรับคนที่สนใจ มีพอร์ต Turbo Vision สมัยใหม่บน C++ ที่รองรับ Unicode ด้วย:
      https://github.com/magiblot/tvision
    • นี่ไม่ใช่โปรเจกต์ที่ทำขึ้นเพราะ “อยากลองทำดู” แต่เป็นเพราะต้องการ TUI editor ขนาดเล็กที่รวมอยู่ใน Windows และทำงานข้าม SSH ได้ด้วย
      https://news.ycombinator.com/item?id=44034961
    • ถ้าพูดให้ถูกคือ array[1..25, 1..80] of Word absolute $B800:0000
      อาร์เรย์ของ TP จัดวางแบบ row-major และตัวอักษรแต่ละตัวแทนด้วยสองไบต์ ไบต์หนึ่งคือตัวอักษรเอง อีกไบต์คือแอตทริบิวต์ (สี foreground/background และการกะพริบ)
      ดังนั้นถ้าเขียนให้ดีกว่านั้นคือ array[1..25, 1..80] of packed record ch: char; attr: byte end absolute $B800:0000
      บนจอแสดงผลข้อความขาวดำแบบ Hercules (โหมด 7) ก็แค่เปลี่ยน $B800 เป็น $B000
    • อยากรู้ว่าคุณทำเงินจาก Turbo Vision ได้อย่างไร ถ้าไม่ลำบากก็ช่วยเล่าให้ฟังหน่อย
    • ทุกครั้งที่เห็น TUI framework สมัยใหม่ใหม่ ๆ ความผิดหวังก็เหมือนเดิม “อ้อ นี่ไม่ดีเท่า Turbo Vision”

  • ตอนนี้กำลังรอ EDLIN ที่รองรับ Unicode อยู่
    จำได้ว่าใน batch file เราสามารถ pipe การกดปุ่มผ่าน standard input เข้าไปเพื่อสคริปต์งานแก้ไขบางอย่างได้ ให้ความรู้สึกเหมือนแทนที่ฟีเจอร์บางส่วนของ sed หรือ awk
    ยังไม่เคยลอง แต่คิดว่า vi ก็น่าจะทำได้เหมือนกัน แยกอีกเรื่องว่ามันเป็นวิธีที่ต้องสาปมากแค่ไหนหรือไม่

    • สิ่งที่คุณหาอยู่น่าจะเป็น ed บางกรณีใช้ร่วมกับ -s ก็ได้

  • น่าสนุกดี พูดตามตรงก็ไม่ค่อยรู้ว่าเขาทำมาให้ใครใช้ แต่ดูน่าสนุก

    • มันทำมาสำหรับคนที่อยากแก้ไขไฟล์ใน Windows Terminal คำสั่ง edit เดิมไม่ได้รับการรองรับบน Windows ตั้งแต่หลังปี 2006 ดังนั้นหลังจากนั้นก็ไม่มีเอดิเตอร์ที่ Microsoft จัดให้สำหรับใช้บน command line
      น่าประทับใจว่าเอดิเตอร์ตัวนี้เร็วแค่ไหน https://github.com/microsoft/edit/pull/408

      ถ้าเขียนรูทีน SIMD ที่ปรับมาเฉพาะสำหรับการค้นหาอักขระขึ้นบรรทัดใหม่ ก็สามารถดันขึ้นไปได้ [ถึง 125GB/s]

    • มีเขียนไว้ใน README ตรง ๆ ว่า:

      เป้าหมายคือการมอบ เอดิเตอร์ที่เข้าถึงได้ง่าย ซึ่งแม้แต่ผู้ใช้ที่แทบไม่คุ้นกับเทอร์มินัลก็ใช้ได้ง่าย

    • เป็นการปรับปรุงที่ดีกว่า Notepad มาก
    • ถ้ามีหรือกำลังจะมีการรองรับ LSP หรือการค้นหาที่อิงกับ ripgrep ก็ยินดีจะใช้แทน vim ได้เลย
      ตอนนี้ใช้ Helix อยู่ แต่ชอบ TUI ที่ดี
    • มันทำมาสำหรับคนอย่างผม/ฉันที่ไม่ชอบ vi และกำลังมองหาของที่เข้าท่ากว่าเพื่อใช้แทน nano ในเทอร์มินัล

  • ในปี 1993 เคยเปิด ไฟล์ไบนารี ด้วย edit แล้วเพลิดเพลินกับการเห็นรูปหัวใจ

    • ประสบการณ์นั้น ภาพ visualization ของ DOS defrag และการแก้ไขเซฟไฟล์แบบ hex เอง แทบจะเป็นเหตุผลที่ทำให้ผม/ฉันกลายมาเป็นนักพัฒนาในตอนนี้