I have:
It seems that when the output line is longer than the size of the terminal, the output gets trimmed. When it is larger it seems it gets deleted (flashes).
Here's an example with a terminal width of 100
~
❯ tput cols
100
~
❯ touch /tmp/test; for ((i=0;i<100;i++)); do echo $i >> /tmp/test; done
~
❯ cat /tmp/test | tr '\n' ','
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,
~
❯
and here with a much larger terminal the output is not even displayed (actually it flashes and directly gets deleted)
❯ tput cols
318
~
❯ cat /tmp/test | tr '\n' ','
~
❯
The same goes without tr for example with for ((i=0;i<100;i++)); do echo -n "${i}," >> /tmp/test; done and then cat /tmp/test.
touch /tmp/test; for ((i=0;i<100;i++)); do echo $i >> /tmp/test; donecat /tmp/test | tr '\n' ','or with
touch /tmp/test; for ((i=0;i<100;i++)); do echo -n "${i}," >> /tmp/test; donecat /tmp/test.zshrc:I started fresh so these are default configs, nothing changed except for the prezto theme.
.zshrc
autoload -Uz promptinit
promptinit
prompt adam1
setopt histignorealldups sharehistory
bindkey -e
HISTSIZE=1000
SAVEHIST=1000
HISTFILE=~/.zsh_history
autoload -Uz compinit
compinit
zstyle ':completion:*' auto-description 'specify: %d'
zstyle ':completion:*' completer _expand _complete _correct _approximate
zstyle ':completion:*' format 'Completing %d'
zstyle ':completion:*' group-name ''
zstyle ':completion:*' menu select=2
eval "$(dircolors -b)"
zstyle ':completion:*:default' list-colors ${(s.:.)LS_COLORS}
zstyle ':completion:*' list-colors ''
zstyle ':completion:*' list-prompt %SAt %p: Hit TAB for more, or the character to insert%s
zstyle ':completion:*' matcher-list '' 'm:{a-z}={A-Z}' 'm:{a-zA-Z}={A-Za-z}' 'r:|[._-]=* r:|=* l:|=*'
zstyle ':completion:*' menu select=long
zstyle ':completion:*' select-prompt %SScrolling active: current selection at %p%s
zstyle ':completion:*' use-compctl false
zstyle ':completion:*' verbose true
zstyle ':completion:*:*:kill:*:processes' list-colors '=(#b) #([0-9]#)*=0=01;31'
zstyle ':completion:*:kill:*' command 'ps -u $USER -o pid,%cpu,tty,cputime,cmd'
source "${ZDOTDIR:-$HOME}/.zprezto/init.zsh"
my .zpreztorc
zstyle ':prezto:*:*' color 'yes'
zstyle ':prezto:load' pmodule \
'environment' \
'terminal' \
'editor' \
'history' \
'directory' \
'spectrum' \
'utility' \
'completion' \
'prompt'
zstyle ':prezto:module:editor' key-bindings 'emacs'
zstyle ':prezto:module:prompt' theme 'pure'
I can't reproduce this. Can you reproduce without prezto? It would also be helpful if you can test with another version of zsh, e.g. 5.3.1 or HEAD.
can't reproduce without prezto, should I report this on prezto directly ?
I would recommend it. I can't think of anything Pure does that would cause this. Since you are triggering this in $HOME, Pure isn't even performing any prompt updates and/or async tasks. It's only setting the prompt variable and letting zsh take care of the initial prompt rendering (as with any prompt/theme).
My hunch is that it's a prezto module that's causing it. Perhaps one that is triggering a zle reset-prompt or zle redisplay.
Can you reproduce with the editor module disabled? I believe that's the only one that performs reset/redisplay.
Good guess, that was it, without the editor module, this doesn't happen anymore.
Thanks for your help, I'll report that on prezto
I tested it with zim and it behaves correctly.
This is related to prezto: https://github.com/sorin-ionescu/prezto/issues/1524.
closing, thanks.
I've spent quite a while debugging this and I'm not 100% sure where the issue lies. Deep in the prezto code there's a call to zle reset-prompt which I'm pretty sure should be fine to call, as it's just meant to redisplay the current prompt.
We use it in the editor module to handle updating the prompt when something changes due to a zle bind (such as the vi mode the user is in). However, it looks like this may interact strangely with multiline prompts, such as pure.
Specifically, pure's initial newline seems to have a strange effect on how this works.
I'll try to investigate this more later, but for now, it's been nailed down to the call to zle reset-prompt in the editor module, which shouldn't be causing issues like this.
I appreciate the effort @belak, and thanks for checking in! I'm wondering if #375 might be related. If so, you shouldn't be able to reproduce this in prezto with zsh 5.3.1 nor HEAD. (This would indicate a regression in ZLE for 5.4.x).
I did some testing, and there seems to be no effect when switching to 5.3.1 or HEAD.
There's something we can do on the Pure side to work around this though. Not sure I like it but it's not a big deal.
diff --git a/pure.zsh b/pure.zsh
index c3454a8..09722ac 100644
--- a/pure.zsh
+++ b/pure.zsh
@@ -132,13 +132,13 @@ prompt_pure_preprompt_render() {
# and after the last newline, leaving us with everything except the
# preprompt. This is needed because some software prefixes the prompt
# (e.g. virtualenv).
- cleaned_ps1=${PROMPT%%${prompt_newline}*}${PROMPT##*${prompt_newline}}
+ cleaned_ps1=${PROMPT%%'$begin_preprompt'*}${PROMPT##*${prompt_newline}}
fi
# Construct the new prompt with a clean preprompt.
local -ah ps1
ps1=(
- $prompt_newline # Initial newline, for spaciousness.
+ '$begin_preprompt' # Empty var placeholder, used for prompt cleanup.
${(j. .)preprompt_parts} # Join parts, space separated.
$prompt_newline # Separate preprompt and prompt.
$cleaned_ps1
@@ -150,7 +150,10 @@ prompt_pure_preprompt_render() {
local expanded_prompt
expanded_prompt="${(S%%)PROMPT}"
- if [[ $1 != precmd ]] && [[ $prompt_pure_last_prompt != $expanded_prompt ]]; then
+ if [[ $1 == precmd ]]; then
+ # Force an initial newline, for spaciousness.
+ print
+ elif [[ $1 != precmd ]] && [[ $prompt_pure_last_prompt != $expanded_prompt ]]; then
# Redraw the prompt.
zle && zle .reset-prompt
fi
I had editor module turned off and autosuggestion module turned on. And autosuggestion module was the cause for me.
I was having a similar issue until I applied @mafredri 's patch in the above comment
I experienced the issue in a sightly different scenario however. The issue only arose when I was in a tmux session, and the first occurrence of standard output of a command exceeding the terminal height would trigger this issue. clearing would fix until the next command or set of commands filled the terminal height which would trigger the issue.
I tried both zplug and zim versions of pure to no success, until finally getting it fixed with the patch.
We recently pushed a fix to prezto. If you're still seeing problems with the latest prezto commit, please let me know and we can continue to investigate.
Most helpful comment
I did some testing, and there seems to be no effect when switching to 5.3.1 or HEAD.
There's something we can do on the Pure side to work around this though. Not sure I like it but it's not a big deal.