Я довгий час був важким користувачем екрана, але використовую версію, яку я змінив ще в 2002 році. Переважно тому, що хотів мати змогу вікно "next / prev" навігаційного замовлення збігатися з тим, у якому новий були створені вікна, схожі на керуючий плиткою вікон, як i3 або Ion . Стандартна поведінка екрана полягає в тому, що "наступний" і "попередній" мають перейти за номером вікна, так що зазвичай "нове" вікно (захоплюючи найменше доступне число) буде розташоване в іншому місці, ніж "наступне" вікно - заплутане, якщо ви не будете " t запам’ятати числа. Моя бажана поведінка з тих пір була впроваджена в Tmux як прапор команди new window у 2010 році , а варіант переномери Windows - у 2012 році. Мій патч на екрані, який я намагався зробити максимально прийнятним, включаючи доповнення до документації тощо, в липні 2002 року не викликав жодної дискусії у списку екранів (тоді "screen@informatik.uni-erlangen.de", не може знайти архіви). Насправді його навіть не визнали, навіть коли я знову надіслав його через рік.
Починаючи з 2002 року, я кілька разів перезавантажував свій патч, щоб застосувати його до нових версій Screen. Однак, перейшовши до версії 4.3 (2015), я помітив незадокументовану зміну, яка порушила одне з моїх застосувань екрана - а саме те , що тепер "інтерполює" змінні середовища . Мені ця функція не була потрібна, і я не міг зрозуміти, як легко уникнути аргументу на «речі» (щоб я міг надсилати текст, що містить знаки долара), тому я просто продовжував використовувати версію 4.0 (з 2004 року).
Я використовую "речі" екрану ("клавіші відправки" в Tmux) у функції Emacs, яка надсилає вміст поточної області Emacs на певний номер вікна. Таким чином, коли я пишу код на мові скриптів, відкриваю інтерпретатора, надаю спеціальному номеру вікна інтепретера, а потім можу надсилати рядки коду з мого вікна редактора безпосередньо у вікно інтерпретатора, використовуючи цю прив'язку Emacs. Це хакі, але мені це подобається краще, ніж чисте рішення Emacs , оскільки я також можу взаємодіяти з інтерпретатором у його вікні Screen, використовуючи стандартні натискання клавіш. Це трохи схоже на ID графічного інтерфейсу, але мені не потрібно користуватися мишею або дивитися на миготливий курсор.
Ще одна особливість, яку я реалізував у своєму патчі, - це можливість "позначити" вікно, а потім переставити позначене вікно на "наступне" після поточного. Для мене це набагато природніший спосіб упорядкування вікон, ніж перенумерування; це як парадигма копіювання / вставки або "перетягування". ( Нещодавно я зрозумів, як це зробити в i3 .)
У Tmux має бути можливість зробити те саме, наприклад, станом на 2015 рік є програма для "маркування" панелі. Або, можливо, більш елементарне рішення могло б бути розроблено зі стаціонарними скриптами оболонки. Я реалізував короткий сценарій та прив'язки клавіш, щоб спробувати метод "позначеної панелі", і він працював кілька разів, але потім Tmux зазнав аварії з "[загубленим сервером]". Тоді я виявив, що Tmux розбився, навіть не намагаючись зробити щось складне. Мабуть , це був збій для деяких користувачів на кілька років , по крайней мере . Іноді сервер виходить з ладу, іноді він починає використовувати 100% процесора і стає безвідповідальним. Я ніколи не бачив, щоб Screen робив щось із цього.
Теоретично Tmux перевершує Екран кількома способами. Він має набагато кращу можливість написання, це означає, що ви можете робити такі запити, як запит на список вікон у поточному сеансі з командного рядка, що неможливо з Screen. Наприклад, у 2015 році Екран додав команду "сортувати вікна за назвою" . Я не впевнений, коли така спеціалізована команда була б корисною, але це та більш практичні варіанти (наприклад, сортування вікон за використанням процесора) можна було відносно легко зробити із скрипту оболонки в Tmux. Мені здається складно зробити щось так креативне в Screen, принаймні, не змінюючи код C.
Як згадували інші афіші, Tmux має односерверну модель, яку я бачу як основний недолік, особливо коли сервер виходить з ладу. Можна обійти це, вказавши окремий розетку для кожного "сеансу". Тим не менш, я віддаю перевагу екрану за замовчуванням на один сервер на сеанс, який здається трохи більш елегантним.
Робота з екранним кодом ще в 2002 році була для мене навчальною і приємною. Як не дивно, за всіма своїми додатковими функціями Tmux має приблизно на 25% менше рядків коду, ніж Екран (30 к проти 40 к). Я помітив, що Tmux використовує багато структур даних про дерева та списки, які мені було трохи важко зрозуміти. Екран, здавалося, віддав перевагу масивам.
Як я розумію, оскільки термінальний інтерфейс Unix є настільки стабільним, для екранного або Tmux-коду мало потреби адаптуватись до змін базової операційної системи. Ці програми насправді не мають оновлень безпеки, таких як веб-браузери чи веб-сервери чи навіть оболонка. Я не помічав жодних проблем із застосуванням власної користувальницької версії екрана, востаннє оновленої у 2004 році (за винятком того, що потрібно додати деякі файли конфігурації, щоб Systemd не видаляв сокет; ці файли, як правило, є частиною пакету розповсюдження). Можливо, я міг би просто подолати проблеми, з якими стикався в Tmux, запустивши версію Tmux, перш ніж вона почала виходити з ладу. Звичайно, якщо для цього достатньо користувачів, це не буде дуже добре для нових користувачів, оскільки це означає, що в останніх офіційних версіях цих програм менше експертів шукатиме помилки. Однак важко мотивувати себе перейти на нестабільний для мене продукт (останній Tmux) або який не має певних функцій, які я хочу (стандартний екран).
Я знаю, що це не дає простої відповіді на питання ОП, але я сподіваюся, що моя точка зору була корисною.