Emacs multi-termine non visualizza correttamente caratteri speciali

Question

Questo è dispari. Ho definito il seguente messaggio in 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}" 

E funziona molto sulle gnome-terminal così come in un terminale ansi-term in Emacs (Mxansi-term) - vedere l'esempio seguente:

Tuttavia, non funziona bene sotto multi-term in Emacs come potete vedere qui sotto:

ho pensato multi-term sarebbe in grado di interpretare lo stesso insieme di caratteri escape che un terminale come gnome-terminal o ansi-term fa. Perché non interpreta correttamente i caratteri di escape restituiti da git-prompt_info e altri?

Ho anche provato:

• Mxset-terminal-coding-system e impostandola utf-8-unix
• TERM=eterm-color all'interno del terminale multifunzione termine, o prima della chiamata Emacs, ecc
• TERM= nel multi terminale di termine, o prima di chiamare Emacs, ecc.
• Rimozione di qualsiasi export TERM dal mio .zshrc

Aggiornamento (29 gennaio 2014):

La soluzione migliore finora sembra essere quello di effettuare le seguenti operazioni:

TERM=xterm-256color

ma provoca un altro problema che ho qui riportato: Passing escape sequences to shells within ansi-term in Emacs.

Answer 1

Perché non interpretare correttamente i caratteri di escape restituiti da git-prompt_info e altri?

La risposta è molto probabile che multi-term non sia pronto ad accettare quelle sequenze di escape, in quel formato, per qualsiasi motivo. Questo potrebbe essere un problema di configurazione, bug o intenzionale. L'impostazione della modalità di accettare i colori, cioè TERM=xterm-256color, migliora la situazione perché accetta poi il colore delle sequenze di escape simile al formato standard utilizzato tra emulatori di terminale, ad esempio:

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

^{code borrowed from here}

la parte sporgente è il [0;31m per il colore, a cui viene fatto riferimento nella discussione collegata in "Aggiornamento 2" dell'altra domanda, chiedendo il motivo per cui le righe vengono stampate che iniziano con 4m che fa parte di questa sequenza di escape colore.

qui è più info, con un estratto rilevante:

Così è il vostro emulatore di terminale che capisce i colori. L'emulatore di terminale riconosce che \033[0;36m è ciano, ma un altro emulatore di terminale potrebbe utilizzare un set di caratteri completamente diverso per cyan (sebbene nessun emulatore di terminale sensato possa sfoggiare lo standard e farlo). Questo è il motivo per tput. Quando esegui tput setaf 6, tput cerca i codici di escape del terminale per il colore 6 (ciano) e genera il codice di escape.

Ho il sospetto che, nella vostra altra domanda, la ragione che alt + b e alt + f non funzionano nella vostra altra domanda è dovuto al conteggio larghezza del terminale di essere fuori perché di interpretazione impropria di queste sequenze di escape che dovrebbero essere non stampabili o a larghezza zero. Non ho incasinato molto con lo multi-term ma la soluzione potrebbe comportare l'uso di tput o simili per consentirgli di capire correttamente le sequenze di escape.

Possible relevant troubleshooting info