52

这很奇怪。我在中定义了以下提示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-terminalansi-termEmacs M-x ansi-term

提示示例 gnome-terminal/ansi-term

multi-term但是,它在 Emacs中不能很好地工作,如下所示:

提示示例多词

我认为multi-term能够解释终端喜欢 gnome-terminalansi-term所做的同一组转义字符。为什么它不能git-prompt_info正确解释和其他人返回的转义字符?

我也试过:

  • M-x set-terminal-coding-system并将其设置为utf-8-unix
  • TERM=eterm-color在多术语终端内,或在调用 Emacs 之前等。
  • TERM=在多术语终端内,或在调用 Emacs 之前等。
  • export TERM从我的删除任何.zshrc

更新(2014 年 1 月 29 日):

到目前为止,最好的解决方案似乎是执行以下操作:

TERM=xterm-256color

但会导致我在这里报告的另一个问题:Passing escape sequences to shells within ansi-term in Emacs

4

1 回答 1

1

为什么它不能正确解释 git-prompt_info 和其他人返回的转义字符?

答案很可能multi-term就是不准备以这种格式接受那些转义序列,无论出于何种原因。这可能是配置问题、错误或故意的。将模式设置为接受颜色,即TERM=xterm-256color,可以改善这种情况,因为它随后接受类似于终端仿真器中使用的标准格式的颜色转义序列,例如:

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

从这里借来的代码

突出的部分是颜色,它在您的另一个问题的“更新 2”中的链接线程中被引用,询问为什么打印出的行以该颜色转义序列的一部分[0;31m开头。4m

这是更多信息,并附有相关摘录:

因此,理解颜色的是您的终端仿真器。您的终端仿真器知道那\033[0;36m是青色,但另一个终端仿真器可能会使用一组完全不同的字符来表示青色(尽管没有一个理智的终端仿真器会标榜标准并这样做)。这就是原因tput。当您运行时tput setaf 6tput将查找终端的颜色 6(青色)的转义码,并输出该转义码。

我怀疑,在您的另一个问题中,alt+balt+f在您的另一个问题中不起作用的原因是由于对这些应该是非打印或零的转义序列的不正确解释而导致终端宽度计数关闭宽度。我没有搞砸multi-term很多,但解决方案可能涉及使用tput或类似的方法,以使其正确理解转义序列。

可能的相关故障排除信息

于 2017-10-16T15:18:44.067 回答