- ใช้ tmux มานาน แต่ช่วงหลังเริ่มรู้สึกกังขากับความซับซ้อนและข้อจำกัดของ tmux (ความเข้ากันได้ของสี, scrollback, การคัดลอกด้วยเมาส์, การไม่รองรับโปรโตคอลบางอย่าง ฯลฯ)
- ฟีเจอร์หลักของ tmux อย่าง การคงอยู่ของเซสชัน (detach/attach) หรือ การแบ่ง/จัดการหน้าต่าง ไม่ได้จำเป็นต้องทำได้ด้วย tmux เท่านั้น
- หากใช้เครื่องมือขนาดเบาตามแนวคิด Unix อย่าง dtach, abduco, shpool ก็สามารถโฟกัสเฉพาะการจัดการเซสชัน พร้อมได้ทั้ง native scrollback และความเรียบง่าย
- โดยเฉพาะการจับคู่
shpool+ ssh ทำให้สามารถ จัดการหลายรีโมตเซสชันจากตัวจัดการหน้าต่างได้โดยตรง และยังใช้ฟีเจอร์เนทีฟต่าง ๆ (การแจ้งเตือน, การเลื่อนดู, ไตเติล ฯลฯ) ได้เหมือนเดิม - แม้จะไม่สมบูรณ์แบบ แต่สำหรับผู้เขียนแล้วสามารถแทน tmux ได้ทั้งหมด และให้ความพึงพอใจกับ เวิร์กโฟลว์ที่เรียบง่ายและดูแลง่าย
ข้อดีและข้อเสียของ tmux
- ฟีเจอร์อย่าง การคงเซสชัน (detach/attach), การจัดการหน้าต่าง (แท็บ, split) คือแกนหลักของเวิร์กโฟลว์เดิมที่ tmux มอบให้
- แต่ถ้าไม่ได้ตั้งค่า
TERMอย่างถูกต้อง ก็จะเกิดปัญหาการแสดงผลสี และต้องคำนึงถึงปฏิสัมพันธ์ระหว่างเทอร์มินัลกับ tmux เพิ่มความซับซ้อนเข้าไปอีก - การใช้บัฟเฟอร์เลื่อนดูก็ต้องเรียนรู้วิธีเฉพาะของ tmux และการคัดลอกพื้นที่ด้วยเมาส์ก็ใช้งานลำบากในสภาพแวดล้อมที่มีหลาย split
- ยังรองรับ ฟีเจอร์เทอร์มินัลสมัยใหม่ ได้ไม่ดี เช่น kitty graphics protocol รวมถึงมีปัญหาไม่รองรับโปรโตคอลเชิงทดลอง
- ยังมีคำวิจารณ์ด้วยว่า การตีความ escape code ซ้ำซ้อนและการเพิ่มแนวคิดเรื่องเซสชัน/หน้าต่าง ทำให้มัลติเพล็กเซอร์ ขัดขวางพัฒนาการของระบบนิเวศเทอร์มินัล
การสำรวจแนวทางแทนที่ tmux
- การคงอยู่ของเซสชัน:
- วิธีง่าย ๆ อย่าง
ctrl-z+fg,nohup,disownก็พอช่วยได้ แต่แทนที่ทั้งหมดได้ยาก - มีเครื่องมือหลายตัวที่ออกแบบมาโดยเน้น การคงเซสชันเท่านั้น (
dtach, abduco, shpool)- ใช้การผสานกันของ fork() และ UNIX socket เพื่อเชื่อมต่อระหว่าง daemon กับ client
- ต่างจาก tmux ตรงที่ไม่มี virtual split จึงรองรับ native scrollback และบางตัวมีความสามารถกู้คืนบัฟเฟอร์ด้วย
- จากประสบการณ์ใช้งาน เครื่องมือทดแทนส่วนใหญ่ยังมีบั๊ก และมีปัญหาเรื่องปุ่ม detach ใช้งานไม่ได้ใน
nvimเป็นต้น จึงยัง ไม่ค่อยสมบูรณ์ - มีเพียง shpool ที่ให้ความรู้สึกว่าสมบูรณ์ที่สุด ทั้งในแง่คำสั่ง detach/attach และการปรับแต่ง keymap
- วิธีง่าย ๆ อย่าง
- การจัดการหน้าต่าง:
- บนเครื่องโลคัล ใช้ตัวจัดการหน้าต่างในการแบ่งและจัดวาง
- ในสภาพแวดล้อมรีโมต (SSH) ก็สามารถใช้ ssh_config ร่วมกับ shpool เพื่อคงหลายเซสชันแยกกันในหน้าต่างคนละบานได้
- ใช้ร่วมกับ autossh เพื่อรักษาเซสชันแม้ในสภาพแวดล้อมที่มีการเชื่อมต่อเครือข่ายใหม่
เวิร์กโฟลว์ใหม่
- โดยส่วนตัวใช้ ghostty (โน้ตบุ๊ก), sway+foot (พีซีส่วนตัว) สำหรับจัดการหน้าต่าง ส่วนเซิร์ฟเวอร์เป็น VM แบบ headless บน Proxmox และคงสภาพแวดล้อมพัฒนาผ่าน SSH ไว้ตลอด
- เชื่อมต่อหลาย shpool session อัตโนมัติผ่านทางลัด ssh และควบคุมแยกกันจากตัวจัดการหน้าต่างบนเครื่องโลคัล
- ตั้งค่าให้
ssh_configแนบเข้า shpool session ของแต่ละโฮสต์โดยอัตโนมัติ - แต่ละเทอร์มินัลสามารถเข้าใช้งาน IRC, จัดการ dotfiles, หรือใช้สภาพแวดล้อม neovim แยกกันได้แบบ เข้าใช้งานหลายเซสชันแยกอิสระ
- ตั้งค่าให้
- ฟีเจอร์อย่างการเลื่อนดูแบบเนทีฟ, การแจ้งเตือน, ไตเติลของเทอร์มินัล ที่ tmux รองรับได้ไม่เสถียร กลับทำงานได้เป็นธรรมชาติกว่าเดิม
- ก็ยังมีข้อเสียอยู่: เมื่อเชื่อมต่อ vim ใหม่จะมีอาการหน่วงในการกู้คืนสถานะเทอร์มินัล และเมื่อใช้
nvimจะมีปัญหาเรื่องการ resize- ไม่รองรับการใช้งานหลายผู้ใช้พร้อมกัน (หากมี autossh จากหลายไคลเอนต์พร้อมกัน จะเกิดการชนกันของเซสชัน)
- แต่สำหรับผู้เขียนแล้ว ถือว่า แทน tmux ได้อย่างสมบูรณ์
บทสรุป
- แม้จะไม่เหมือนเดิมทุกอย่าง แต่ก็สามารถเปลี่ยนไปสู่ เวิร์กโฟลว์การจัดการเซสชันที่เรียบง่ายและยืดหยุ่นกว่า โดยหลุดพ้นจากความซับซ้อนและข้อจำกัดของ tmux ได้
- ขึ้นอยู่กับเวิร์กโฟลว์ของแต่ละคน เครื่องมือทางเลือกอย่าง shpool ก็น่าลองพิจารณา
7 ความคิดเห็น
เดี๋ยวนี้ก็ใช้ AI ปั่นอะไรแบบ tmux ออกมาใช้กันครับ ทำด้วย Xterm.js + react + electron ใช้เวลา 3-4 ชั่วโมงก็เข็นของแบบนั้นออกมาได้เป็น 100 ตัว ถ้าจำเป็นก็แก้สดแบบเรียลไทม์แล้วใช้เลย ความรู้สึกเหมือนไปกินชาบู? อยากกินอะไรก็ใส่ลงไป แล้วอัดให้แน่น ๆ ลงในซอร์ส
ผมใช้งานได้อย่างสะดวกด้วย wezterm
Screen เจ๋งสุด!
cargo install shpool...งั้นฉันใช้tmuxต่อก็แล้วกัน...ต้องมีแพ็กเกจแยกสำหรับแต่ละ OS!มีหน้าใหม่ฝีมือเยี่ยมชื่อว่า Zellij อยู่ครับ แนะนำมากๆ
Zellij - เทอร์มินัลสำหรับนักพัฒนา & Ops
อันนี้ก็เคยโพสต์ไปนานพอสมควรแล้วเหมือนกัน ฮ่าๆ
ความเห็นจาก Hacker News
บทความนี้เหมาะกับผู้ใช้ Linux-on-the-Desktop แต่ผมอยากเน้นว่า tmux จะฉายแสงได้อย่างแท้จริงเมื่อใช้ร่วมกับ iTerm2 บน MacBook
ด้วยฟีเจอร์การทำงานร่วมกับ tmux ของ iTerm2 ทำให้ tmux กลมกลืนเข้าไปในเวิร์กโฟลว์ของผมอย่างเป็นธรรมชาติโดยสมบูรณ์
ถ้าตั้งค่าไว้ใน
~/.ssh/configแบบด้านล่างนี้ ต่อให้เปิด MacBook ใหม่หรือเปลี่ยนเครือข่ายเมื่อไรก็ยังเข้าไปยังเซิร์ฟเวอร์พัฒนาระยะไกลผ่าน ssh tmux ได้อย่างง่ายดายเสมอด้วยการทำงานร่วมกันของ iTerm2 และ tmux แท็บ tmux ระยะไกลและ scroll buffer จะทำงานเหมือนแท็บโลคัล และจริง ๆ แล้วใช้งานได้โดยแทบไม่ต้องรู้คำสั่ง tmux เลย
ผมใช้ Linux กับอุปกรณ์ส่วนตัวทั้งหมด และใช้ MacBook เป็นหลักเวลาทำงาน ซึ่ง tmux มีประโยชน์มากเพราะช่วยให้ได้สภาพแวดล้อมเดียวกันแบบข้ามแพลตฟอร์ม
บน Linux ผมใช้ Alacritty แต่บน macOS มักมีบางอย่างที่ไม่ทำงานได้ทันทีเสมอ เพราะเรื่องการตั้งค่าที่ต้องปรับหรือความต่างด้านหน้าต่าง/การเลื่อน
ผมไม่อยากเสียเวลากับความต่างของ OS พวกนี้ ดังนั้นการใช้ tmux คู่กับ iTerm2 เพื่อให้ได้ประสบการณ์ที่เกือบเหมือน Linux จึงดีกว่า
การที่มี session scrollback แยกออกจากกันโดยสมบูรณ์ก็เป็นข้อดีสำหรับผมเช่นกัน
ผมคิดว่าคำวิจารณ์ต่อ tmux นั้นเป็นประเด็นที่ใกล้กับฝั่งนักพัฒนาเทอร์มินัลมากกว่า
ถ้าซัพพอร์ตไม่ดี ก็แค่ย้ายไปใช้เทอร์มินัลที่ซัพพอร์ตดีกว่า
ผมใช้ mosh คู่กับ screen อยู่
ต่อให้เซิร์ฟเวอร์รีบูตก็ยังกู้คืนเซสชันได้ และต่อให้เปลี่ยนเครือข่าย เซสชันก็ไม่หลุด
ดูเพิ่มเติม: Immortal SSH Sessions
ผมลองใช้ tmux มาหลายสิบครั้งแล้ว แต่ไม่ค่อยชอบเลยกลับไปใช้ screen ตลอด
แต่พอเห็นทิปนี้แล้วก็ทำให้อยากลองอีกสักครั้ง
ผมมักเจอปัญหาเรื่องสีและฟอนต์กับชุด vim, tmux, iTerm2 จนสุดท้ายเลิกใช้ tmux บนเครื่องโลคัล
มันรอดจากการอัปเดตก็จริง และช่วยคงเซสชันได้ แต่ประโยชน์ที่ได้ไม่ได้มากนัก
ถ้าแก้ปัญหาฟอนต์ได้ ผมก็ยินดีจะลองอีกครั้ง แต่ตอนนี้ไม่มีเวลา
ผมสงสัยว่าบน Linux มีเทอร์มินัลตัวไหนที่มีฟีเจอร์ทำงานร่วมกับ tmux แบบ iTerm2 บ้าง
ตอนนี้ยังใช้ GNU Screen อยู่ แต่ก็ยินดีจะลอง tmux อีกครั้ง
บล็อกโพสต์นี้ทำให้ผมตระหนักอีกครั้งว่าทำไมถึงใช้ tmux
พอเห็นคนต้องลงแรงมหาศาลเพื่อประกอบเวิร์กโฟลว์ที่คล้าย tmux ขึ้นมา ก็รู้สึกว่าใช้ tmux ไปเลยดีกว่ามาก
บางครั้งการคัดลอกแปะอาจไม่สะดวกนิดหน่อย แต่ผมไม่ค่อยใส่ใจ
คำวิจารณ์ว่า 'multiplexer ทำให้เกิด overhead ที่ไม่จำเป็น' เป็นเรื่องที่ไม่ต้องสนใจเลย ถ้าคุณไม่ใช่คนดูแลรักษา codebase
ปัญหาคัดลอกแปะไม่ใช่ปัญหาเฉพาะของ tmux
แอปทุกตัวที่วาดทั้งเทอร์มินัลเองแบบ vim ก็อาจเจอได้เหมือนกัน
ปัญหานี้แก้ได้ง่ายด้วย terminal escape sequence ชื่อ OSC52
ถ้าใช้สคริปต์ Python สั้น ๆ ด้านล่างนี้ คุณก็ส่งผลลัพธ์จาก grep เป็นต้น ไปยัง system clipboard ได้โดยตรง
tmux และ nvim รองรับ OSC52 อยู่แล้ว และยังเอาไปใช้ที่อื่นได้ง่ายด้วย
เพิ่มเติมนิดหนึ่ง ผมเคยส่ง PR ให้ tmux มาก่อน และชอบมากที่ Nick Marriott ผู้ดูแลโปรเจ็กต์สื่อสารได้ดีจริง ๆ
โค้ดก็จัดระเบียบไว้ดี และ tmux ก็ดีขึ้นเรื่อย ๆ
ผมเบื่อการถกเถียงที่เหมือนพยายามสร้างปัญหาจากเรื่องที่ไม่มีปัญหา
เหตุผลที่ผู้เขียนยกมาฟังไม่ค่อยขึ้น และยิ่งทำให้ผมสงสัยด้วยซ้ำกับคำว่า "ใช้ tmux มานานกว่า 7 ปี" ของเขา
ผมเพิ่งรู้จัก Tmux เมื่อไม่กี่สัปดาห์ก่อน และหลงใหลกับความเป็นไปได้ในการเขียนสคริปต์เพื่อส่งคีย์อินพุตไปยัง pane ที่กำหนดแบบโปรแกรมได้
หลังได้แรงบันดาลใจจากฟอรัมญี่ปุ่น ผมก็สงสัยว่า Claude Code (ต่อไปจะเรียก CC) จะโต้ตอบกับสคริปต์ CLI ที่ต้องมีการโต้ตอบโดยตรงได้ไหม และพบว่าสามารถทำได้ด้วย Tmux
เลยสร้างเครื่องมือเล็ก ๆ ชื่อ claude-code-tools ขึ้นมา เพื่อให้ CLI agent อย่าง CC สร้าง Tmux pane, รันสคริปต์ข้างใน และโต้ตอบแบบเรียลไทม์ได้ด้วย
มันเหมือน Playwright หรือ Puppeteer เวอร์ชันสำหรับเทอร์มินัล
ลิงก์ GitHub ของ claude-code-tools
ด้วยวิธีนี้ CC สามารถเอาไปใช้ทดสอบอัตโนมัติกับสคริปต์ CLI ที่ต้องโต้ตอบ, เปิด UI ใน pane อื่นแล้วทดสอบบนเบราว์เซอร์ด้วย Puppeteer MCP, เปิดดีบักเกอร์แล้วจับ breakpoint, เชื่อมต่อหลายเอเจนต์ ฯลฯ ได้
ผมสงสัยว่าเครื่องมือทางเลือกแทน tmux จะรองรับความขยายต่อแบบนี้ได้หรือไม่
เพิ่มเติมว่า screen ก็ส่งคีย์อินพุตเข้า pane แบบโปรแกรมได้ด้วยคำสั่ง "stuff"
ด้วยวิธีนี้ Claude Code สามารถควบคุม CC instance หลากหลายแบบ เช่น Gemini CLI, OpenCode ในโหมด interactive ได้
ทำให้เชื่อมต่อกันได้ในรูปแบบที่ต่างจาก subagent แบบดั้งเดิม
ผมสงสัยว่า tmux-cli wrapper ช่วยให้ผลลัพธ์ดีขึ้นจริงไหม
สำหรับผม แค่บอกให้ Claude ใช้คำสั่ง tmux ที่มีอยู่เดิมก็ทำงานได้ดีอยู่แล้ว เลยให้ทุกคำสั่งรันอยู่ใน tmux session ไปเลยโดยไม่ต้องใช้ Bash แยก
ถ้าอยากทำอะไรแบบนี้ให้ง่ายขึ้นในระดับเทอร์มินัล ฟีเจอร์ remote control ของ Kitty ก็ยอดเยี่ยมเหมือนกัน
แนะนำ Kitty Remote Control
โดยพื้นฐานแล้วเทอร์มินัลก็เป็นแค่ file descriptor ดังนั้นเครื่องมือคล้ายกันอย่าง script(1), expect(1), chat(8) ก็มีมาตั้งแต่ยุค 80 แล้ว
ไม่จำเป็นต้องใช้ tmux เสมอไป
ปัญหาที่สีและอย่างอื่นแสดงผลไม่ถูกต้องเมื่อไม่ได้ตั้งค่า TERM ใน tmux ให้เหมาะสม เป็นปัญหาเดียวกับที่เกิดได้ใน terminal emulator/โปรแกรมทุกตัว
บนระบบ Unix และ Linux แนวคิดเรื่อง TERM และ terminfo/termcap เป็นหัวใจสำคัญอยู่แล้ว จึงจำเป็นต้องตั้งค่าให้ถูกต้อง
นี่ไม่ใช่ปัญหาเฉพาะของ tmux
แต่น่าเสียดายที่ผู้เขียนกลับโทษ tmux
ส่วนปัญหาเรื่องการเลื่อนเอง ผมก็ไม่แน่ใจว่าเป็นปัญหาของ tmux จริงหรือไม่ และ tmux ใช้ alternate screen buffer ซึ่งถูกนำมาใช้เพื่อให้มี baseline ของ viewport ที่ชัดเจน จะได้จัดการการเคลื่อนที่ของเคอร์เซอร์ได้ง่าย
เทอร์มินัลสมัยใหม่ส่วนใหญ่อนุญาตให้เลื่อนแบบโลคัลได้แม้อยู่ใน alternate screen จึงทำให้คุณสมบัตินี้ไม่ถูกรักษาไว้อย่างเคร่งครัด
โปรแกรมส่วนใหญ่ถ้าไม่ตั้งค่าดีฟอลต์ให้เหมาะสมก็ย่อมไม่ทำงานตามที่ตั้งใจไว้เหมือนกัน
สำหรับ tmux ปัญหาคือมันไม่ได้บอกชัด ๆ ทันทีว่า 'ทำไม' ถึงผิดพลาด แต่จะแก้อย่างไรก็ยังไม่ชัดเจนนัก (เช่น ควรตั้งค่าดีฟอลต์เป็น 256colors หรือไม่)
ก็จริง แต่เวลาจะใช้ tmux คุณต้องใส่ใจเพิ่มอีกหนึ่งเลเยอร์
ข้างใน tmux ต้องใช้ TERM สำหรับ tmux โดยเฉพาะ ส่วนข้างนอกก็ต้องใช้ TERM ที่ตรงกับเทอร์มินัลของตัวเอง
แค่ดู tmux FAQ ก็เห็นได้ว่าปัญหาการแสดงผลส่วนใหญ่เกิดจากการไม่ได้ตั้งค่า TERM
ข้อสังเกตว่า "multiplexer ทำให้เกิด overhead ที่ไม่จำเป็น" กลับเป็นเหตุผลที่ทำให้ผมชอบ tmux
ในช่วงที่แอปจำนวนมากขึ้นเรื่อย ๆ เลิกสนับสนุน termcap การมี tmux ทำให้ผมยังรันแอปได้แม้บนเทอร์มินัลเก่าอย่าง VT520
ผมไม่ค่อยสนใจหรอกว่านักพัฒนาเทอร์มินัลคนไหนจะไม่ชอบ tmux
ท้ายที่สุดแล้ว สำหรับผู้ใช้ สิ่งสำคัญคือมันต้องใช้งานได้จริง มากกว่าความสง่างามเชิงสถาปัตยกรรม
ส่วนตัวผมคิดว่า alacritty ดีกว่า (แต่ส่วนใหญ่ใช้งาน Konsole)
แค่อยากบอกว่าผมอิจฉาที่คุณมี VT520
ผมหา VT525 มานานแล้ว แต่ทั้งแพงและผู้ขายส่วนใหญ่อยู่ต่างประเทศ
ผมสงสัยมาตลอดว่า nosh realizer ทำงานได้ดีไหมบน VT525 แท้
ต่อให้ tmux หายไป แอปที่มีปัญหา TERM ไม่เข้ากันเล็ก ๆ น้อย ๆ ก็ยังพอแปลงแก้ได้ด้วยวิธีอื่น
VT420 ของผมไม่รองรับ hardware flow control จึงต้องใช้ software flow control ซึ่งเข้ากับแอปเทอร์มินัลสมัยนี้ได้ไม่ค่อยดีนัก
GNU Screen เป็นทางออกที่ยอดเยี่ยมมาก และยังมีฟีเจอร์อื่นอีกหลากหลาย
ผมใช้ tmux บ่อยกับ emulator สมัยใหม่ แต่บน terminal รุ่นเก่าดูเหมือนมันยังขาดฟีเจอร์ flow control สำคัญนี้
ผมเห็นด้วยว่า tmux มีประโยชน์สำหรับจัดการแอปที่ไม่รองรับ termcap/terminfo
ผมสงสัยว่าทำไมถึงคิดว่า alacritty ดีกว่า
บนฮาร์ดแวร์เก่า มันเปิดช้า แถมยังขาดฟีเจอร์ใช้งานจริงอย่างแท็บ และแม้แต่ benchmark ก็ยังเป็นรอง kitty/ghostty/konsole/foot
ถึงอย่างนั้นก็ยังน่าสนใจที่มีคนใช้ alacritty ด้วยเหตุผลบางอย่าง
ผมยังคงจะใช้ tmux ต่อไป
ผมชอบที่มันจัดการเซสชันข้ามหลายโปรเจ็กต์ได้ง่าย และกู้คืนเซสชันหลังรีบูตได้สะดวก
mouse copy/paste ก็ไม่เคยมีปัญหาเลยเมื่อใช้ tmux-yank
ผมใช้สภาพแวดล้อมเดิมนี้มาหลายปีแล้ว
ด้วยฟีเจอร์ send-keys ของ tmux ผมทำ automation เวลารีแฟกเตอร์ dotfile โดยอัปเดต alias หรือไฟล์ config พร้อมกันในหลาย pane/หลาย session และรีสตาร์ต nvim ได้ง่าย
ผมสรุปประสบการณ์นี้ไว้ในบล็อกและวิดีโอ
ผมมองว่า "you might not need tmux" คล้ายกับการถกเรื่อง "you might not need browser tabs"
ถ้าคุณมี terminal session หรือหน้าเว็บแค่หนึ่งสองอันก็อาจไม่จำเป็น แต่ถ้าต้องจัดการมากกว่านั้น การจัดการหน้าต่างจะยุ่งยากเกินไป แล้วสุดท้ายคุณก็ต้องมาสร้างฟีเจอร์เดิมซ้ำเองอยู่ดี
ช่วงนี้ผมแค่พยายามใช้ความสามารถจัดการหน้าต่างของ window manager ที่ใช้อยู่ให้เต็มที่
แทนที่จะใช้ browser tab, terminal tab หรือ tmux ผมให้ window manager จัดการการวางหน้าต่าง, แท็บ, bookmark ต่าง ๆ ก็ไม่ได้รู้สึกลำบากอะไร
ผมเริ่มเชื่อเกือบจะเป็นหลักการแล้วว่า การจัดการแท็บควรเป็นหน้าที่ของ window manager ไม่ใช่ของแอปพลิเคชัน
window manager ของผมสามารถจัดวางหน้าต่างแบบ tile หรือจัดกลุ่มหน้าต่างซ้อนกันเป็นแท็บได้
แท็บเหล่านี้ใช้ได้ทั้งกับแอปเดียวกันหรือคนละแอปก็ได้
browser tab แยกออกเป็นคนละหน้าต่างหรือรวมกลับเข้าด้วยกันได้ง่าย แต่ tmux tab ไม่ยืดหยุ่นในจุดนี้เท่าไร
ถ้ามี window manager ที่ดี คุณจะจัดรวมและแยกแท็บกับหน้าต่างใหม่ได้อย่างอิสระ
ใน tmux config ของผมมีแท็บที่คลิกได้
การจัดการหลายหน้าต่างของ MS Windows (Alt Tab, Win Tab ฯลฯ) ทำได้ยอดเยี่ยมมาก
ผมแยกเทอร์มินัลแต่ละตัวด้วยไอคอน/สีพื้นหลังที่ต่างกัน และตัวระบบปฏิบัติการเองก็ช่วยจัดการหน้าต่างให้ไปได้มาก
ผมก็เคยใช้ Mac แต่เรื่องนี้ยังไม่ถูกใจเท่า Windows
สิ่งที่หลายคนบ่นเกี่ยวกับ tmux เช่น buffer scrollback กลับเป็นแรงจูงใจให้ผมใช้ tmux มากขึ้น
แล็ปท็อปเครื่องที่สองของผมเป็นเครื่องเก่าไว้ใช้กับ debian terminal อย่างเดียว และไม่มีเมาส์ จึงคัดลอก/วางได้ผ่าน tmux เท่านั้น
สำหรับผม tmux ไม่มีสิ่งใดทดแทนได้
tmux capture-pane - | vim -ก็สะดวกกว่าล้อสกอร์ลเมาส์เสียอีกฝั่ง suckless เลือกแนวทางตรงข้ามโดยสิ้นเชิง คือจงใจไม่ใส่ความสามารถแบบ tmux ลงไปในเทอร์มินัลตั้งแต่ขั้นออกแบบ
ดูเพิ่มเติม: st.suckless.org/goals
ผมหวังว่า Kitty จะประสบความสำเร็จ เพราะดูเหมือนมีศักยภาพจะนำอนาคตของ terminal emulator ได้
แต่ผมใช้ Kitty ทำงานจริงไม่ได้ และถ้าไม่มี tmux ทั้ง session, การจัดวางหน้าต่าง, state, copy buffer, scrollback ก็จะหายหมด ดังนั้นเลิกใช้ไม่ได้เด็ดขาด
จนกว่าจะมีตัวแทนที่เหมาะสมบน Windows ต่อให้ใช้ Kitty ควบคู่กันอยู่ ผมก็ยังตั้งใจจะใช้ tmux ต่อในการทำงาน
แต่สุดท้ายก็กลับมาใช้ tmux คู่กับเทอร์มินัลปกติ
เพราะมันทำงานได้ดีทุกที่ และวิธีประกอบเครื่องมือหลายชิ้นเข้าด้วยกันแบบนี้มีแนวโน้มอยู่รอดได้นานกว่า ทำให้ tmux ยังเป็นตัวเลือกที่ดีที่สุดอยู่ดี