Cela fait longtemps que je suis un grand utilisateur de Screen, mais j’utilise une version que j’ai modifiée en 2002. Principalement parce que je voulais pouvoir faire en sorte que la fenêtre "suivant / précédent" trie les commandes de navigation dans l’ordre dans lequel les nouvelles Des fenêtres ont été créées, semblables à un gestionnaire de fenêtres en mosaïque comme i3 ou Ion . Le comportement standard de l'écran est que 'next' et 'prev' passent par le numéro de la fenêtre. Ainsi, une 'nouvelle' fenêtre (capturant le plus petit numéro disponible) sera située ailleurs que dans la 'fenêtre suivante' - ce qui déroutera si vous ne le faites pas. Ne me souviens pas des chiffres. Mon comportement préféré a depuis été implémenté dans Tmux en tant qu'indicateur de la commande new-window en 2010 et de l' option renumber-windows en 2012.. Le correctif My Screen, que j’essayais de rendre aussi acceptable que possible, y compris les ajouts de documentation, etc., n’a généré aucune discussion sur la liste Screen en juillet 2002 (alors "screen@informatik.uni-erlangen.de", trouver des archives). En fait, cela n'a même pas été reconnu, même lorsque je l'ai renvoyé un an plus tard.
Depuis 2002, j'ai "rebasé" mon correctif à quelques reprises pour l'appliquer aux nouvelles versions de Screen. Cependant, quand je suis arrivé à la version 4.3 (2015), j'ai remarqué un changement non documenté qui a cassé l'une de mes utilisations d'écran - à savoir que le «matériel» interpole maintenant les variables d'environnement . Je n'avais pas besoin de cette fonctionnalité et je n'arrivais pas à comprendre comment échapper facilement à l'argument «trucs» (pour pouvoir envoyer du texte contenant des signes dollar). J'ai donc continué à utiliser la version 4.0 (à partir de 2004).
J'utilise le "matériel" de Screen ("send-keys" dans Tmux) dans une fonction Emacs qui envoie le contenu de la région Emacs actuelle à un numéro de fenêtre spécifique. Ainsi, lorsque j'écris du code dans un langage de script, j'ouvre un interpréteur, je donne un numéro spécial à la fenêtre interpréteur, puis je peux envoyer des lignes de code de ma fenêtre d'édition directement à la fenêtre interpréteur à l'aide de cette liaison Emacs. C'est hacky, mais je l'aime mieux que la solution pure-Emacs , car je peux aussi interagir avec l'interprète dans sa fenêtre Screen en utilisant des frappes au clavier standard. C'est un peu comme une interface graphique, mais je n'ai pas besoin d'utiliser la souris ni de regarder fixement un curseur clignotant.
Une autre fonctionnalité implémentée dans mon patch est la possibilité de "marquer" une fenêtre, puis de repositionner la fenêtre marquée pour qu'elle soit "suivante" après la fenêtre actuelle. Pour moi, il s'agit d'un moyen beaucoup plus naturel de réorganiser les fenêtres que de renuméroter; c'est comme le paradigme copier / coller, ou "glisser-déposer". (J'ai récemment compris comment faire cela dans i3 également.)
Il devrait être possible de faire la même chose dans Tmux. Par exemple, à partir de 2015, il est possible de "marquer" un volet. Ou peut-être qu'une solution plus élémentaire pourrait être élaborée avec des scripts shell à états. J'ai implémenté un court script et des raccourcis clavier pour essayer la méthode "volet marqué", et cela a fonctionné à quelques reprises, mais Tmux s'est écrasé avec "[serveur perdu]". Ensuite, j'ai trouvé Tmux en panne, même sans que j'essaye de faire quelque chose de compliqué. Apparemment , il a été plantait pour certains utilisateurs pour quelques années au moins . Parfois, le serveur tombe en panne, parfois, il commence à utiliser 100% de la CPU et ne répond plus. Je n'ai jamais vu Screen faire l'un ou l'autre.
En théorie, Tmux est supérieur à Screen à plusieurs égards. La scriptabilité est bien meilleure, ce qui signifie que vous pouvez faire des choses comme interroger la liste des fenêtres de la session en cours à partir de la ligne de commande, ce qui est impossible avec Screen. Par exemple, en 2015, Screen a ajouté une commande permettant de "trier les fenêtres par titre" . Je ne sais pas quand une commande aussi spécialisée serait utile, mais cette variante, plus pratique (par exemple, le tri des fenêtres en fonction de l'utilisation du processeur) pourrait être réalisée assez facilement à partir d'un script shell dans Tmux. Il me semble difficile de faire quelque chose d'aussi créatif dans Screen, du moins sans modifier le code C.
Comme d'autres affiches l'ont mentionné, Tmux a un modèle à serveur unique que je considère comme le principal inconvénient, en particulier lorsque le serveur tombe en panne. Il est possible de contourner ce problème en spécifiant un socket distinct pour chaque "session". Je préfère tout de même le paramètre par défaut d’un serveur par session de Screen, qui semble légèrement plus élégant.
Travailler avec le code Screen, en 2002, était pour moi une expérience éducative et agréable. Curieusement, pour toutes ses fonctionnalités supplémentaires, Tmux a environ 25% de lignes de code en moins que Screen (30k vs 40k). J'ai remarqué que Tmux utilise de nombreuses structures de données arborescentes et listées, difficiles à comprendre pour moi. L'écran semblait préférer les tableaux.
Si j'ai bien compris, l'interface de terminal Unix étant très stable, il est inutile que le code Screen ou Tmux s'adapte aux modifications du système d'exploitation sous-jacent. Ces programmes ne disposent pas vraiment de mises à jour de sécurité telles que les navigateurs Web, les serveurs Web ou même le shell. Je n'ai pas remarqué de problèmes pour exécuter ma version personnalisée de Screen, mise à jour pour la dernière fois en 2004 (excepté la nécessité d'ajouter des fichiers de configuration pour empêcher Systemd de supprimer le socket.); ces fichiers font généralement partie du paquet de distribution). Peut-être que je pourrais simplement contourner les problèmes que j'ai rencontrés dans Tmux en exécutant une version de Tmux antérieure à son crash. Bien sûr, si suffisamment d'utilisateurs le font, cela ne sera pas très utile pour les nouveaux utilisateurs, car cela signifie que moins d'experts rechercheront des bogues dans les dernières versions officielles de ces programmes. Cependant, il est difficile de me motiver pour passer à un produit qui est instable pour moi (dernier Tmux) ou qui manque de certaines fonctionnalités que je souhaite (écran standard).
Je sais que cela ne fournit pas une réponse facile à la question du PO, mais j'espère que mon point de vue a été utile.