Open ljcucc opened 5 years ago
Hey, this is certainly not normal behaviour. Currently, there is no real-time clock afaik. What exactly are you referring to? Can you describe the steps to reproduce this?
Sorry, I mean the clock making a new line on prompt. Is seems abnormal display when I enter ZSH.
Whether the type of terminal I used (except cmd.exe which is made by default of windows). The Line of the end will creating a new line on prompt that cover my input area.
it doesn't work...
I also find a post who was have the same issue as me, but I not really understand what the answer meaning. https://stackoverflow.com/questions/51120454/use-zsh-in-hypertm-with-powerlevel9k-but-the-right-label-is-always-outside-the
I also find a post who was have the same issue as me, but I not really understand what the answer meaning. https://stackoverflow.com/questions/51120454/use-zsh-in-hypertm-with-powerlevel9k-but-the-right-label-is-always-outside-the
The answer suggests to unset ZLE_RPROMPT_INDENT
or set to something higher than 0. Could you provide some information about who you installed powerlevel9k and provide the settings you use in your .zshrc
? Does this only happen in ConEmu and not in WSL?
This typically happens, if ZSH does not calculate the window with correctly. This can happen, on various occasions:
ZLE_RPROMPT_INDENT
might be set.locale
might not be a UTF-8 one.Could you post the output of echo ${ZLE_RPROMPT_INDENT} && locale
here?
OK..... I got those result when type the command( echo ${ZLE_RPROMPT_INDENT} && locale
) that @dritter you suggest: (It seems most values were set to UTF-8) Is that normal?
% echo ${ZLE_RPROMPT_INDENT} && locale
LANGUAGE=
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_PAPER="C.UTF-8"
LC_NAME="C.UTF-8"
LC_ADDRESS="C.UTF-8"
LC_TELEPHONE="C.UTF-8"
LC_MEASUREMENT="C.UTF-8"
LC_IDENTIFICATION="C.UTF-8"
LC_ALL=
Sorry for the late response. AFAIK there is no such locale as C.UTF-8
. Could you try to install a proper UTF-8
locale (like en_US.UTF-8
) and see if that helps?
C.UTF-8 is my go-to locale on Ubuntu. It works great and doesn't require any extra installation.
I couldn't reproduce it with these locales either.
Correct me on this. Here is no new line or other fancy trick going on here, so this should work with vanilla zsh by just setting RPROMPT
and break as well, right? For example:
% zsh -df
% RPROMPT=$'\uF09C'' '$'\uF09C'' '$'\uF09C'' '$'\uF09C'' '$'\uF09C'
If this breaks down it would narrow it down to something wrong with the locales, wouldn't it? I might be totally off here...
Ha. Indeed, C.UTF-8
is valid. That wasn't the case in the past (at least a couple years ago).
The issue here could be, as @Syphdias said, that the Terminal Emulator is not capable of rendering double-width glyphs. If the Emulator renders a double-width glyph in more than one cell, it would move the prompt.
I would extend @Syphdias test by echoing $COLUMNS
before and after. That value probably won't change, but if the prompt extends to the next line in that case, it would proof that the calculating the prompt width in ZSH and Terminal Emulator mismatch.
I don't know how, but when I using WSL(Ubuntu) in windows 10 which running on ConEmu, I got this weird result:
this bug? or it's the problem of my computer, or this is just a normal status? Need help, Thanks.