Przez długi czas byłem intensywnym użytkownikiem Screen, ale korzystam z wersji, którą zmodyfikowałem w 2002 roku. Głównie dlatego, że chciałem, aby okno nawigacyjne „następne / poprzednie” odpowiadało kolejności, w jakiej nowe okna zostały utworzone, podobnie jak menedżer okien sąsiadujących, taki jak i3 lub Ion . Standardowe zachowanie ekranu polega na tym, że „następny” i „poprzedni” przechodzi według numeru okna, tak że zwykle „nowe” okno (chwytając najmniejszą dostępną liczbę) znajduje się gdzie indziej niż okno „następne” - mylące, jeśli nie ” pamiętam liczby. Moje preferowane zachowanie zostało zaimplementowane w Tmux jako flaga polecenia new-window w 2010 roku , a opcja renumber -windows w 2012 roku. Moja łatka do ekranu, którą starałem się uczynić możliwie akceptowalną, w tym uzupełnienia dokumentacji itp., Nie spowodowała żadnej dyskusji na liście ekranów w lipcu 2002 r. (Wtedy „screen@informatik.uni-erlangen.de”, nie może znajdź archiwa). W rzeczywistości nie został nawet potwierdzony, nawet gdy wysłałem go ponownie rok później.
Od 2002 roku kilkakrotnie „zmieniłem” swoją łatkę, aby zastosować ją w nowszych wersjach ekranu. Kiedy jednak dotarłem do wersji 4.3 (2015), zauważyłem nieudokumentowaną zmianę, która przerwała jedno z moich zastosowań screena - mianowicie, że „rzeczy” interpolują zmienne środowiskowe . Nie potrzebowałem tej funkcji i nie mogłem wymyślić, jak łatwo uciec przed argumentem „rzeczy” (aby móc wysyłać tekst zawierający znaki dolara), więc nadal używałem wersji 4.0 (od 2004 r.).
Używam „rzeczy” Screena („klucze wysyłania” w Tmuxie) w funkcji Emacsa, która wysyła zawartość bieżącego regionu Emacsa na określony numer okna. W ten sposób, gdy piszę kod w języku skryptowym, otwieram interpretera, nadaję okno interpretera specjalny numer, a następnie mogę wysyłać wiersze kodu z okna edytora bezpośrednio do okna interpretera za pomocą tego powiązania Emacsa. Jest hacky, ale podoba mi się to bardziej niż rozwiązanie z czystym Emacsem , ponieważ mogę również wchodzić w interakcję z tłumaczem w jego oknie ekranowym za pomocą standardowych naciśnięć klawiszy. To trochę jak IDE GUI, ale nie muszę używać myszy ani patrzeć na migający kursor.
Inną funkcją, którą zaimplementowałem w mojej łatce, jest możliwość „oznaczenia” okna, a następnie przesunięcia zaznaczonego okna, aby było „następne” po bieżącym. Dla mnie jest to o wiele bardziej naturalny sposób zmiany kolejności okien niż zmiana numeracji; przypomina paradygmat kopiuj / wklej lub „przeciągnij i upuść”. ( Ostatnio wymyśliłem, jak to zrobić w i3 ).
To samo powinno być możliwe w Tmux, na przykład od 2015 r. Istnieje możliwość „oznaczania” szyby. A może można opracować bardziej elementarne rozwiązanie za pomocą stanowych skryptów powłoki. Zaimplementowałem krótki skrypt i skróty klawiszowe, aby wypróbować metodę „zaznaczonego panelu” i zadziałało kilka razy, ale potem Tmux zawiesił się z „[utraconym serwerem]”. Potem odkryłem, że Tmux ulega awarii nawet bez mojej próby zrobienia czegoś skomplikowanego. Podobno został on upaść dla niektórych użytkowników za kilka lat co najmniej . Czasami serwer ulega awarii, czasem zaczyna używać 100% procesora i przestaje odpowiadać. Nigdy nie widziałem, żeby Screen robił jedno z tych.
Teoretycznie Tmux jest lepszy od Screena na kilka sposobów. Ma znacznie lepszą skryptowalność, co oznacza, że możesz wykonywać takie czynności, jak przeszukiwanie listy okien w bieżącej sesji z wiersza poleceń, co jest niemożliwe w przypadku Screen. Na przykład w 2015 r. Screen dodał polecenie „sortuj okna według tytułu” . Nie jestem pewien, kiedy takie wyspecjalizowane polecenie byłoby przydatne, ale ta i bardziej praktyczna odmiana (np. Sortowanie okien według użycia procesora) można stosunkowo łatwo wykonać ze skryptu powłoki w Tmux. Wydaje mi się, że trudno jest zrobić coś tak kreatywnego na ekranie, przynajmniej bez modyfikacji kodu C.
Jak wspomniano w innych plakatach, Tmux ma model z jednym serwerem, który uważam za podstawową wadę, szczególnie gdy serwer ulega awarii. Można obejść ten problem, określając osobne gniazdo dla każdej „sesji”. Nadal wolę domyślny ekran dla jednego serwera na sesję, który wydaje się nieco bardziej elegancki.
Praca z kodem ekranowym w 2002 roku była dla mnie edukacyjna i przyjemna. Co dziwne, mimo wszystkich dodatkowych funkcji Tmux ma około 25% mniej wierszy kodu niż Screen (30 tys. Vs 40 tys.). Zauważyłem, że Tmux używa wielu struktur danych drzewa i list, które były dla mnie nieco trudne do zrozumienia. Wyglądało na to, że ekran woli tablice.
Jak rozumiem, ponieważ interfejs terminala w systemie Unix jest tak stabilny, nie ma potrzeby dostosowywania kodu Screen lub Tmux do zmian w podstawowym systemie operacyjnym. Te programy tak naprawdę nie mają aktualizacji zabezpieczeń, takich jak przeglądarki internetowe, serwery sieciowe, a nawet powłoka. Nie zauważyłem żadnych problemów z uruchomieniem mojej niestandardowej wersji Screen, ostatnio zaktualizowanej w 2004 roku (z wyjątkiem konieczności dodania niektórych plików konfiguracyjnych, aby zapobiec usunięciu gniazda przez Systemd; te pliki i tak są zazwyczaj częścią pakietu dystrybucyjnego). Być może mógłbym po prostu obejść problemy, które napotkałem w Tmux, uruchamiając wersję Tmux sprzed jego awarii. Oczywiście, jeśli zrobi to wystarczająca liczba użytkowników, nie będzie to dobre dla nowych użytkowników, ponieważ oznacza to, że mniej ekspertów będzie szukało błędów w najnowszych oficjalnych wersjach tych programów. Trudno jednak zmotywować się do przejścia na produkt, który jest dla mnie niestabilny (najnowszy Tmux) lub który nie ma pewnych funkcji, których chcę (standardowy ekran).
Wiem, że nie zapewnia to łatwej odpowiedzi na pytanie PO, ale mam nadzieję, że moja perspektywa była przydatna.