- Navios
- 5 de setembro de 2026 às 05:57 UTC
- Autor
- Kamo
- Enviar
- c85be57
A barra moveu o próprio buffer do xterm, e sob o tmux esse buffer nunca cresce: tmux envia ao cliente apenas as linhas que acabam visíveis e mantém o histórico Ele próprio. Então 'baseY' foi sempre 0, a barra leu que como "nada para rolar", e ele Eu verifiquei originalmente contra um xterm nu. js escrevendo sua própria saída, que é O único acordo onde funciona. Ele agora conduz tmux quando o buffer está vazio, enviando os relatórios da roda tmux já se liga a `copy-mode -e` – o mesmo caminho que a roda física toma, então não existem dois mecanismos para manter em passo. Codificação SGR (botão 64 para cima, 65 baixo), que é o que tmux pede para uma vez que seu modo de mouse está ligado. O branch local fica, porque está correto para um terminal que NÃO está hospedado por um multiplexador e não custa nada — e porque uma barra que enviou relatórios roda em um emulador simples não rolaria nada e seria quebrado precisamente da maneira que este está a consertar. Dois comportamentos tiveram que diferir honestamente em vez de fingir: - O GRIP. Com o tampão aqui a posição do polegar é a posição, então Arrastar a roupa. Com o retorno em tmux nada pode dizer onde no história o painel está sentado, de modo que a aderência torna-se uma roda de jog — centrada, fixa altura, rolagem por quão longe é puxado. Desenhando um polegar em uma posição nós Não sei se seria uma mentira que os olhos acreditariam. - O Jumps. Um relatório de roda não pode dizer "vá para o topo", por isso é uma explosão de tamanho a partir do próprio histórico-limite padrão do tmux de 2000 linhas. A superação é gratuita: tmux pára no topo, e na parte inferior simplesmente deixa o modo de cópia. 13 guardas e 5398 testes. check-i18n-keys está vermelho no CalDAV de outra sessão work; isto não adiciona chaves.