Há muito tempo que sou um pesado utilizador de Screen, mas utilizo uma versão que modifiquei em 2002. Principalmente porque queria poder ter a janela “next/prev” de ordenação de navegação igual à ordem em que as novas janelas foram criadas, semelhante a um gestor de janelas de azulejo como i3 ou Ion . O comportamento padrão do ecrã é para ‘next’ e ‘prev’ ir por número de janela, de modo que normalmente uma janela ‘new’ (agarrando o menor número disponível) será localizada noutro lugar que não a janela ‘next’ - confuso se não se lembrar dos números. O meu comportamento preferido foi desde então implementado no Tmux como uma bandeira para o comando new-window em 2010 , e a opção renumber-windows em 2012 . A minha correcção Screen, que tentei tornar o mais aceitável possível, incluindo adições de documentação, etc., não gerou qualquer discussão na lista Screen em Julho de 2002 (então “screen@informatik.uni-erlangen.de”, não consigo encontrar arquivos). Na realidade, nem sequer foi reconhecido, mesmo quando o enviei novamente um ano mais tarde.
Desde 2002, “rebaseei” a minha correcção um par de vezes para aplicar a versões mais recentes do Screen. Contudo, quando cheguei à versão 4.3 (2015) notei uma alteração não documentada que quebrou uma das minhas utilizações do ecrã - nomeadamente que ‘coisas’ agora interpolam variáveis de ambiente . Não precisava dessa funcionalidade, e não conseguia perceber como escapar facilmente ao argumento de ‘material’ (para que pudesse enviar texto contendo sinais de dólar), pelo que continuei a utilizar a versão 4.0 (a partir de 2004).
Utilizo as ‘coisas’ do Screen (‘teclas de envio’ no Tmux) numa função Emacs que envia o conteúdo da actual região Emacs para um número de janela específico. Assim, quando estou a escrever código numa linguagem de scripting, abro um intérprete, dou um número especial à janela de interpretação, e depois posso enviar linhas de código da janela do meu editor directamente para a janela do intérprete utilizando esta ligação Emacs. É hacky mas gosto mais do que a solução de Emacs puro , uma vez que também posso interagir com o intérprete na sua janela de ecrã utilizando toques de tecla padrão. É um pouco como uma IDE GUI, mas não tenho de usar o rato nem de olhar para um cursor a piscar.
Outra característica que implementei no meu patch é a capacidade de “marcar” uma janela, e depois reposicionar a janela marcada para ser “seguinte” após a actual. Para mim, esta é uma forma muito mais natural de reordenar janelas do que renumerar; é como o paradigma copiar/colar, ou “drag-and-drop”. (Eu recentemente descobri como fazer isto em i3 também.)
Deverá ser possível fazer o mesmo no Tmux, por exemplo a partir de 2015 existe uma facilidade para “marcar” um painel. Ou talvez uma solução mais elementar pudesse ser trabalhada com argumentos de concha estatais. Eu implementei um pequeno script e keybindings para tentar o método “painel marcado”, e funcionou algumas vezes, mas depois o Tmux falhou com “[servidor perdido]”. Depois encontrei o Tmux a falhar, mesmo sem tentar fazer nada de complicado. Aparentemente tem estado a falhar para alguns utilizadores durante alguns anos pelo menos . Por vezes o servidor trava, outras vezes começa a usar 100% do CPU e fica sem resposta. Nunca vi o Screen fazer nenhuma destas duas coisas.
Em teoria, o Tmux é superior ao Screen de várias maneiras. Tem muito melhor scriptability, o que significa que pode fazer coisas como consultar a lista de janelas na sessão actual a partir da linha de comando, o que é impossível com o Screen. Por exemplo, em 2015 Screen adicionou um comando para “ordenar janelas por título” . Não tenho a certeza quando um comando tão especializado seria útil, mas isto e variações mais práticas (por exemplo, ordenar janelas por uso de CPU) poderiam ser feitas com relativa facilidade a partir de um script de shell no Tmux. Parece-me difícil fazer algo tão criativo no Screen, pelo menos sem modificar o código C.
Como outros cartazes mencionados, o Tmux tem um modelo de servidor único que eu vejo como o principal inconveniente, particularmente quando o servidor está a falhar. É possível contornar isto especificando uma tomada separada para cada “sessão”. Ainda assim, prefiro o padrão de um servidor por sessão do Screen, que parece ligeiramente mais elegante.
Trabalhar com o código Screen, em 2002, foi educativo e agradável para mim. Curiosamente, para todas as suas características adicionais, o Tmux tem cerca de 25% menos linhas de código do que o Screen (30k vs 40k). Notei que o Tmux utiliza muitas estruturas de dados em árvore e lista, que foram ligeiramente difíceis para mim de compreender. O Screen parecia preferir as arrays.
Como entendo, porque a interface terminal Unix é tão estável, há pouca necessidade de que o Screen ou código Tmux se adapte às mudanças no sistema operativo subjacente. Estes programas não têm realmente actualizações de segurança como browsers ou servidores web ou mesmo a shell. Não notei quaisquer problemas na execução da minha versão personalizada de Screen, actualizada pela última vez em 2004 (excepto a necessidade de adicionar alguns ficheiros de configuração para evitar que Systemd apague o socket ; estes ficheiros são tipicamente parte do pacote de distribuição de qualquer forma). Talvez pudesse apenas contornar os problemas que encontrei no Tmux, executando uma versão do Tmux de antes de este começar a falhar. Claro que, se um número suficiente de utilizadores fizer isto, então não será muito bom para novos utilizadores, pois isso significa que menos peritos estarão à procura de bugs nas últimas versões oficiais destes programas. No entanto, é difícil motivar-me a mudar para um produto que é instável para mim (o último Tmux) ou que carece de certas características que eu quero (ecrã padrão).
Sei que isto não dá uma resposta fácil à pergunta do OP, mas espero que a minha perspectiva tenha sido útil.