Emacs многократно не отображает специальные символы правильно

Это нечетно. Я определил следующее приглашение в 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}"

Он отлично работает на gnome-terminal, а также в терминале ansi-term в Emacs (M-x ansi-term) - см. пример ниже:

prompt example gnome-terminal/ansi-term

Тем не менее, он не работает хорошо в multi-term в Emacs, как вы можете видеть ниже:

prompt example multi-term

Я думал, что multi-term будет способен интерпретировать один и тот же набор escape-символов, что делает терминал вроде gnome-terminal или ansi-term. Почему это неверно интерпретирует escape-символы, возвращаемые git-prompt_info и другими?

Я также пробовал:

  • M-x set-terminal-coding-system и установите его на utf-8-unix
  • TERM=eterm-color в многотерминальном терминале или перед вызовом Emacs и т.д.
  • TERM= в многотерминальном терминале или перед вызовом Emacs и т.д.
  • Удаление любого export TERM из моего .zshrc

Обновление (29 января 2014 года):

Лучшее решение, похоже, заключается в следующем:

TERM=xterm-256color

но вызывает еще одну проблему, о которой я сообщил здесь: Передача escape-последовательностей в оболочки в рамках ansi-term в Emacs.

Ответы

Ответ 1

Почему это не интерпретирует escape-символы, возвращаемые git -prompt_info и другие правильно?

Ответ скорее всего на то, что multi-term просто не готов принять эти escape-последовательности в этом формате по любой причине. Это может быть проблема конфигурации, ошибка или преднамеренное. Установка режима для приема цветов, т.е. TERM=xterm-256color, улучшает ситуацию, поскольку затем принимает цветовые escape-последовательности, аналогичные стандартным форматам, используемым среди эмуляторов терминала, например:

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

код, заимствованный здесь

значимая часть - это цвет [0;31m для цвета, на который ссылается связанный поток в "Обновлении 2" вашего другого вопроса, спрашивающий, почему строки печатаются, начиная с 4m, который является частью этого escape цвета последовательность.

Подробнее info с соответствующей выдержкой:

Таким образом, ваш эмулятор терминала понимает цвета. Ваш терминальный эмулятор понимает, что \033[0;36m является голубым, а другой терминальный эмулятор может использовать совершенно другой набор символов для голубого (хотя никакой здравомыслящий эмулятор терминала не будет выставлять напоказ стандарт и сделайте это). Это причина tput. Когда вы запустите tput setaf 6, tput будет искать коды выхода вашего терминала для цвет 6 (голубой) и выводить этот код выхода.

Я подозреваю, в вашем другом вопросе, что alt + b и alt + f не работают в вашем другом вопросе из-за того, что счетчик ширины терминала отключен из-за неправильной интерпретации из этих управляющих последовательностей, которые должны быть непечатаемыми или нулевыми. Я не много перепутал с multi-term, но решение может включать использование tput или подобное, чтобы позволить ему правильно понимать escape-последовательности.

Возможная информация по устранению неполадок