He sido un gran usuario de Screen durante mucho tiempo, pero utilizo una versión que modifiqué en 2002. Principalmente porque quería que el orden de navegación “siguiente/previo” de las ventanas coincidiera con el orden de creación de las nuevas ventanas, similar a un gestor de ventanas en mosaico como i3 o Ion . El comportamiento estándar de Screen es que “siguiente” y “prev” vayan por número de ventana, de modo que normalmente una ventana “nueva” (que toma el número más pequeño disponible) estará ubicada en otro lugar que la ventana “siguiente” - confuso si no recuerdas los números. Mi comportamiento preferido ha sido implementado desde entonces en Tmux como una bandera al comando new-window en 2010 , y la opción renumber-windows en 2012 . Mi parche de Screen, que traté de hacer lo más aceptable posible, incluyendo adiciones de documentación y demás, no generó ninguna discusión en la lista de Screen en julio de 2002 (entonces “screen@informatik.uni-erlangen.de”, no puedo encontrar los archivos). De hecho, ni siquiera se reconoció, incluso cuando lo envié de nuevo un año después.
Desde 2002, he “rebasado” mi parche un par de veces para aplicarlo a las nuevas versiones de Screen. Sin embargo, cuando llegué a la versión 4.3 (2015) me di cuenta de un cambio no documentado que rompió uno de mis usos de Screen - a saber, que ‘stuff’ ahora interpola las variables de entorno . No necesitaba esa característica, y no pude averiguar cómo escapar fácilmente el argumento de ‘stuff’ (para poder enviar texto que contenga signos de dólar), así que seguí usando la versión 4.0 (de 2004).
Utilizo ‘stuff’ de Screen (‘send-keys’ en Tmux) en una función de Emacs que envía el contenido de la región actual de Emacs a un número de ventana específico. De esta manera, cuando estoy escribiendo código en un lenguaje de scripting, abro un intérprete, le doy a la ventana del intérprete un número especial, y entonces puedo enviar líneas de código desde mi ventana del editor directamente a la ventana del intérprete usando este enlace de Emacs. Es un poco complicado, pero me gusta más que la solución pura de Emacs, ya que también puedo interactuar con el intérprete en su ventana de pantalla usando las teclas estándar. Es un poco como un GUI IDE, pero no tengo que usar el ratón o mirar un cursor parpadeante.
Otra característica que implementé en mi parche es la capacidad de “marcar” una ventana, y luego reposicionar la ventana marcada para que sea la “siguiente” después de la actual. Para mí esta es una forma mucho más natural de reordenar las ventanas que renumerarlas; es como el paradigma de copiar/pegar, o “arrastrar y soltar”. (Yo recientemente descubrí cómo hacer esto en i3 también.)
Debería ser posible hacer lo mismo en Tmux, por ejemplo desde 2015 hay una facilidad para “marcar” un panel. O tal vez una solución más elemental podría ser elaborada con scripts de shell con estado. Implementé un corto script y keybindings para probar el método de “panel marcado”, y funcionó algunas veces pero luego Tmux se estrelló con “[servidor perdido]”. Luego me encontré con que Tmux se estrellaba incluso sin que yo intentara hacer nada complicado. Aparentemente ha estado fallando para algunos usuarios durante algunos años al menos . A veces el servidor se bloquea, a veces empieza a usar el 100% de la CPU y deja de responder. Nunca he visto a Screen hacer ninguna de estas cosas.
En teoría, Tmux es superior a Screen en varios aspectos. Tiene una capacidad de scripting mucho mejor, lo que significa que puedes hacer cosas como consultar la lista de ventanas en la sesión actual desde la línea de comandos, lo que es imposible con Screen. Por ejemplo en 2015 Screen añadió un comando para “ordenar las ventanas por título” . No estoy seguro de cuándo sería útil un comando tan especializado, pero esto y otras variaciones más prácticas (por ejemplo, ordenar las ventanas por uso de la CPU) podrían hacerse con relativa facilidad desde un script de shell en Tmux. A mí me parece difícil hacer algo tan creativo en Screen, al menos sin modificar el código C.
Como ya han mencionado otros usuarios, Tmux tiene un modelo de un solo servidor, lo que considero el principal inconveniente, especialmente cuando el servidor se bloquea. Es posible solucionar esto especificando un socket separado para cada “sesión”. Aún así, prefiero el modelo de un servidor por sesión de Screen, que parece un poco más elegante.
Trabajar con el código de Screen, en 2002, fue educativo y agradable para mí. Curiosamente, para todas sus características adicionales, Tmux tiene alrededor de un 25% menos de líneas de código que Screen (30k vs 40k). Me di cuenta de que Tmux utiliza muchas estructuras de datos en forma de árbol y de lista, que me resultaron ligeramente difíciles de entender. Screen parecía preferir las matrices.
Según tengo entendido, debido a que la interfaz de terminal de Unix es tan estable, hay poca necesidad de que el código de Screen o Tmux se adapte a los cambios en el sistema operativo subyacente. Estos programas no tienen realmente actualizaciones de seguridad como los navegadores o servidores web o incluso el shell. No he notado ningún problema al ejecutar mi versión personalizada de Screen, actualizada por última vez en 2004 (excepto por la necesidad de añadir algunos archivos de configuración para evitar que Systemd borre el socket ; estos archivos suelen formar parte del paquete de distribución). Tal vez podría solucionar los problemas que encontré en Tmux ejecutando una versión de Tmux de antes de que empezara a fallar. Por supuesto, si un número suficiente de usuarios hace esto, no será muy bueno para los nuevos usuarios, ya que significa que menos expertos buscarán errores en las últimas versiones oficiales de estos programas. Sin embargo, es difícil motivarme para cambiar a un producto que es inestable para mí (el último Tmux) o que carece de ciertas características que quiero (Pantalla estándar).
Sé que esto no proporciona una respuesta fácil a la pregunta del OP, pero espero que mi perspectiva haya sido útil.