He sido un gran usuario de Screen durante mucho tiempo, pero uso una versión que modifiqué en 2002. Principalmente porque quería que la ventana "siguiente / anterior" ordenara la navegación en el orden en que Se crearon ventanas, similares a un administrador de ventanas de mosaico como i3 o Ion . El comportamiento estándar de la pantalla es que 'siguiente' y 'anterior' vayan por número de ventana, por lo que generalmente una ventana 'nueva' (agarrando el número más pequeño disponible) se ubicará en otro lugar que la ventana 'siguiente', lo que es confuso si no lo hace ' No recuerdo los números. Desde entonces, mi comportamiento preferido se implementó en Tmux como un indicador del comando de nueva ventana en 2010 y la opción de renumerar ventanas en 2012. Mi parche de Screen, que traté de hacer lo más aceptable posible, incluidas las adiciones de documentación, etc., no generó ningún debate sobre la lista de Screen en julio de 2002 (luego "screen@informatik.uni-erlangen.de", no puede encontrar archivos). De hecho, ni siquiera fue reconocido, incluso cuando lo envié nuevamente un año después.
Desde 2002, "modifiqué" mi parche un par de veces para aplicarlo a las versiones más nuevas de Screen. Sin embargo, cuando llegué a la versión 4.3 (2015) noté un cambio indocumentado que rompió uno de mis usos de la pantalla, es decir, ese 'material' ahora interpola las variables de entorno . No necesitaba esa función, y no podía encontrar la manera de escapar fácilmente del argumento de 'cosas' (para poder enviar texto que contenga signos de dólar), así que seguí usando la versión 4.0 (de 2004).
Utilizo las 'cosas' de Screen ('teclas de envío' 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 esa manera, cuando escribo código en un lenguaje de script, abro un intérprete, le doy a la ventana del intérprete un número especial y luego puedo enviar líneas de código desde la ventana de mi editor directamente a la ventana del intérprete usando este enlace de Emacs. Es hacky, 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 IDE GUI, pero no tengo que usar el mouse 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 "siguiente" después de la actual. Para mí, esta es una forma mucho más natural de reordenar ventanas que renumerarlas; es como el paradigma de copiar / pegar, o "arrastrar y soltar". ( Recientemente descubrí cómo hacer esto también en i3 ).
Debería ser posible hacer lo mismo en Tmux, por ejemplo, a partir de 2015 existe la posibilidad de "marcar" un panel. O tal vez una solución más elemental podría elaborarse con scripts de shell con estado. Implementé un script corto y combinaciones de teclas para probar el método de "panel marcado", y funcionó varias veces, pero luego Tmux se bloqueó con "[servidor perdido]". Luego encontré que Tmux se bloqueaba incluso sin intentar hacer algo complicado. Al parecer, se ha fallando para algunos usuarios para unos pocos años por lo menos . A veces el servidor se bloquea, a veces comienza a usar el 100% de la CPU y deja de responder. Nunca he visto a Screen hacer ninguno de estos.
En teoría, Tmux es superior a Screen de varias maneras. Tiene una capacidad de escritura mucho mejor, lo que significa que puede hacer cosas como consultar la lista de ventanas en la sesión actual desde la línea de comandos, lo cual es imposible con Screen. Por ejemplo, en 2015 Screen agregó un comando para "ordenar ventanas por título" . No estoy seguro de cuándo sería útil un comando tan especializado, pero esta y otras variaciones más prácticas (por ejemplo, ordenar ventanas según el uso de la CPU) podrían hacerse con relativa facilidad desde un script de shell en Tmux. Para mí, parecería difícil hacer algo tan creativo en Screen, al menos sin modificar el código C.
Como otros carteles mencionaron, Tmux tiene un modelo de servidor único que veo como el principal inconveniente, particularmente cuando el servidor falla. Es posible solucionar esto especificando un socket separado para cada "sesión". Aún así, prefiero el valor predeterminado de un servidor por sesión de Screen, que parece un poco más elegante.
Trabajar con el código Screen, en 2002, fue educativo y agradable para mí. Por extraño que parezca, para todas sus características adicionales, Tmux tiene aproximadamente un 25% menos de líneas de código que Screen (30k frente a 40k). Me di cuenta de que Tmux utiliza muchas estructuras de datos de árbol y lista, que me resultaron un poco difíciles de entender. La pantalla parecía preferir las matrices.
Según tengo entendido, debido a que la interfaz de terminal Unix es tan estable, hay poca necesidad de que el código Screen o Tmux se adapte a los cambios en el sistema operativo subyacente. Estos programas realmente no tienen actualizaciones de seguridad como navegadores web 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 agregar algunos archivos de configuración para evitar que Systemd elimine el socket; estos archivos son típicamente parte del paquete de distribución de todos modos). Quizás podría solucionar los problemas que encontré en Tmux ejecutando una versión de Tmux antes de que comenzara a fallar. Por supuesto, si suficientes usuarios hacen esto, entonces 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í (ú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.