Emacs multi-term no muestra caracteres especiales correctamente

terminal zsh

Question

Esto es raro. He definido el siguiente mensaje en zsh :

local user_host=''%{$terminfo[bold]$fg[green]%}%n @ %m%{$reset_color%}''
local current_dir=''%{$terminfo[bold]$fg[blue]%} %~%{$reset_color%}''
local git_branch=''$(git_prompt_info)%{$reset_color%}''
local return_code="%(?..%{$fg[red]%}%? ↵%{$reset_color%})"
PROMPT="╭─${user_host} %D{[%a, %b %d %I:%M:%S]} ${current_dir} ${git_branch}
╰─%B$%b "
RPS1="${return_code}"

Funciona muy bien en gnome-terminal , así como en un terminal ansi-term en Emacs ( Mx ansi-term ) - vea el siguiente ejemplo:

Sin embargo, no funciona bien en multi-term en Emacs, como puede ver a continuación:

Pensé que multi-term sería capaz de interpretar el mismo conjunto de caracteres de escape que un terminal como gnome-terminal o ansi-term . ¿Por qué no está interpretando correctamente los caracteres de escape devueltos por git-prompt_info y otros?

También he intentado:

• Mx set-terminal-coding-system y configurarlo en utf-8-unix
• TERM=eterm-color dentro de la terminal de término múltiple, o antes de llamar a Emacs, etc.
• TERM= dentro de la terminal de término múltiple, o antes de llamar a Emacs, etc.
• Eliminando cualquier término de export TERM de mi .zshrc

Actualización (29 de enero de 2014):

La mejor solución hasta ahora parece ser hacer lo siguiente:

TERM=xterm-256color

pero causa otro problema que he reportado aquí: pasar secuencias de escape a shells dentro de ansi-term en Emacs .

Answer 1

¿Por qué no está interpretando correctamente los caracteres de escape devueltos por git-prompt_info y otros?

La respuesta es más probable que multi-term no esté preparado para aceptar esas secuencias de escape, en ese formato, por el motivo que sea. Esto puede ser un problema de configuración, error o intencional. Configurar el modo para aceptar colores, es decir, TERM=xterm-256color , mejora la situación porque luego acepta secuencias de escape de color similares al formato estándar usado entre los emuladores de terminal, por ejemplo:

RED=''/033[0;31m''
NC=''/033[0m'' # No Color
echo "I ${RED}love${NC} /n" # this output IS NOT interpreting the escapes
echo -e "I ${RED}love${NC} /n" # this output IS interpreting them

^{código prestado de aquí}

la parte saliente es el [0;31m para el color, al que se hace referencia en el hilo vinculado en "Actualización 2" de su otra pregunta, preguntando por qué se imprimen líneas que comienzan con 4m que es parte de esta secuencia de escape de color.

Aquí hay más info , con un extracto relevante:

Por lo tanto, es su emulador de terminal que entiende los colores. Su emulador de terminal entiende que /033[0;36m es cian, pero otro emulador de terminal podría usar un conjunto de caracteres completamente diferente para cian (aunque ningún emulador de terminal sensato alarde del estándar y haga esto). Esta es la razón de tput . Cuando ejecute tput setaf 6 , tput buscará los códigos de escape de su terminal para el color 6 (cian) y generará ese código de escape.

Sospecho, en su otra pregunta, que la razón por la que alt + b y alt + f no están funcionando en su otra pregunta se debe a que el ancho del terminal está desactivado debido a una interpretación incorrecta de estas secuencias de escape que se supone que no son Impresión o ancho cero. No me he metido mucho en el multi-term pero la solución puede implicar el uso de tput o similar para permitirle entender correctamente las secuencias de escape.

Posible información relevante para la solución de problemas