Pure eats long output lines #376
Comments
|
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 My hunch is that it's a prezto module that's causing it. Perhaps one that is triggering a |
|
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 |
|
I tested it with zim and it behaves correctly. This is related to prezto: sorin-ionescu/prezto#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 We use it in the 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 |
|
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 |
|
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. |
It seems that adding the initial newline in `$PROMPT` allows ZLE to erase the entile line where the newline began. This is problematic when command output does not end with its own newline. A subsequent terminal resize or prompt update that triggers a prompt redraw will then erase the line. To fix this, we separate the newline from the prompt by calling print manually during precmd. Previously, Pure tried to keep any potential prefixes the user might have added to the PROMPT (before preprompt). This fix no longer allows such prefixes as doing so would be hackish, and likely a recipe for other unforseen behavior. NOTE: Because the newline is printed by the Pure precmd hook, it's possible that another precmd hook is run afterwards, and if that hook outputs any text, the newline will appear in the wrong place. A possible solution would be to delay adding the hook or at a later point sort the hooks so that Pure is last. Fixes sindresorhus#390, sindresorhus#376.
It seems that adding the initial newline in `$PROMPT` allows ZLE to erase the entile line where the newline began. This is problematic when command output does not end with its own newline. A subsequent terminal resize or prompt update that triggers a prompt redraw will then erase the line. To fix this, we separate the newline from the prompt by calling print manually during precmd. Previously, Pure tried to keep any potential prefixes the user might have added to the PROMPT (before preprompt). This fix no longer allows such prefixes as doing so would be hackish, and likely a recipe for other unforseen behavior. NOTE: Because the newline is printed by the Pure precmd hook, it's possible that another precmd hook is run afterwards, and if that hook outputs any text, the newline will appear in the wrong place. A possible solution would be to delay adding the hook or at a later point sort the hooks so that Pure is last. Fixes #390, #376.
…sorhus#391) It seems that adding the initial newline in `$PROMPT` allows ZLE to erase the entile line where the newline began. This is problematic when command output does not end with its own newline. A subsequent terminal resize or prompt update that triggers a prompt redraw will then erase the line. To fix this, we separate the newline from the prompt by calling print manually during precmd. Previously, Pure tried to keep any potential prefixes the user might have added to the PROMPT (before preprompt). This fix no longer allows such prefixes as doing so would be hackish, and likely a recipe for other unforseen behavior. NOTE: Because the newline is printed by the Pure precmd hook, it's possible that another precmd hook is run afterwards, and if that hook outputs any text, the newline will appear in the wrong place. A possible solution would be to delay adding the hook or at a later point sort the hooks so that Pure is last. Fixes sindresorhus#390, sindresorhus#376.
General information
I have:
Problem description
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
and here with a much larger terminal the output is not even displayed (actually it flashes and directly gets deleted)
The same goes without
trfor example withfor ((i=0;i<100;i++)); do echo -n "${i}," >> /tmp/test; doneand thencat /tmp/test.Reproduction steps
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/testMy
.zshrc:I started fresh so these are default configs, nothing changed except for the prezto theme.
.zshrc
my .zpreztorc
The text was updated successfully, but these errors were encountered: