gnome-terminal usa cores brilhantes para negrito

Question

gnome-terminal usado para exibir caracteres com uma cor e o atributo negrito em uma cor mais clara do que os caracteres com a mesma cor, mas sem atributo negrito, para um total de 16 cores possíveis. A página Preferências ainda tem 16 cores para selecionar, mas parece sempre usar a linha superior, mesmo quando os caracteres estão em negrito. Eu nunca pareço ver a última linha de cores usada.

(Esse é um problema ao jogar Nethack, já que estou acostumado a ver os monstros e objetos em 16 cores distintas.)

Existe uma maneira de recuperar o antigo comportamento com todas as 16 cores?

    

Answer 1

Versão curta: Por favor, tente TERM=xterm nethack , provavelmente será o truque.

Versão longa:

Por favor, tente e examine a saída do script da minha resposta em Imprima um padrão de teste de 256 cores no terminal .

O atributo do qual você está falando ( \e[1m ) tem uma confusão de legado, quer signifique negrito, claro ou ambos. Com a paleta estendida de 256 cores aparecendo em praticamente todos os emuladores de terminal, e subsequentemente o verdadeiro suporte de cores aparecendo em alguns (incluindo o gnome-terminal), a tendência é deslocada para esse atributo, que significa negrito. Obviamente, não se pretende adulterar as cores RGB diretas, e também seria problemático com a paleta de 256 cores (haveria um mapeamento entre esses índices ou resultaria em cores fora da paleta?).

Existem várias maneiras de acessar as primeiras 16 entradas da paleta. As seqüências de escape legadas com os números 30 a 37 (primeiro plano) e 40 a 47 (plano de fundo) representam as oito primeiras. As iniciais, se combinadas com o modo 1 (negrito / brilhante), ainda habilitam suas contrapartes brilhantes para compatibilidade herdada razões (por exemplo, para nethack ainda parecer como antes ... suspiro).

Os códigos 90-97 (fg) e 100–107 (bg) significam as próximas 8 entradas de paleta que são as mais brilhantes de qualquer maneira.

As novas seqüências de paleta de 256 cores (38; 5; 0 - 38; 5; 255 para fg, 48; 5; 0 - 48; 5; 255 para bg) se comportam de maneira diferente, embora (seguindo o comportamento de xterm): Aqui, o atributo 1 (negrito / brilhante) ativa apenas a negritude e não altera a cor.

Então, no seu caso, a diferença é que seu aplicativo costumava emitir as antigas seqüências de escape, mas agora emite as novas (paleta de 256 cores) que se referem às cores da mesma paleta, a A única diferença é que o modo 1 funciona de maneira diferente: significa negrito apenas aqui, em vez de negrito e brilhante.

Isso, por sua vez (andando para trás na cadeia de raciocínio), é provavelmente causado pela variável de ambiente TERM com o padrão xterm-256color, em vez de xterm como anteriormente. Tente reverter essa variável e veja como ela afeta seu aplicativo.

Algo que eu não entendo sem investigar (e não investigarei por falta de tempo e interesse): o nethack parece estar usando ncurses. ncurses não permite que o aplicativo decida que tipo de seqüências de escape usar, ele só oferece acesso a 256 cores, e é o negócio privado de ncurses que usa a seqüência de escape para os primeiros 16. De fato, como visto da saída de tput setaf e tput setab , em alguma sintaxe estranha ele codifica uma ramificação if-else para os intervalos 0–7, 8–15 e 16–255, isto é, até onde eu sei, é esperado que ele emita as seqüências de escape herdadas para as primeiras 16 cores, o que no seu caso deve significar que, mesmo com TERM = xterm-256color, o comportamento não deve mudar em comparação com TERM = xterm. Eu deixaria você investigar mais a partir daqui, dada a entrada que você recebeu até agora, por exemplo use script para gravar a saída de nethack e examine com um visualizador de texto para ver quais tipos de seqüências de escape ele emite.