When selectiong a large completion entry in the pager, it would clobber the
prompt. To reproduce, first run this command
complete -c : -xa '(
# completion entries that, when applied to the commandline
# need one, two, or three lines respectively
echo 1
echo 2(string repeat -n (math $COLUMNS - 5) x)
echo 3(string repeat -n $COLUMNS x)
printf %s\n n(seq $LINES)
)'
then type ": " and hit Tab repeatedly. When cycling through completion
entries, observe that fish always tries to render the pager with the same
size, even though the number of lines occupied by the command line buffer
changes due to soft wrapping.
Fix this by rendering the pager after the command line has been rendered, so
we know how many lines we have left.
Prior to this fix, s_reset would attempt to reset the screen, optionally
using the PROMPT_SP hack to go to the next line. This in turn required
passing in the screen width even if it wasn't needed (because we were
not going to abandon the line). Factor this into two functions:
- s_reset_line which does not apply the hack
- s_reset_abandoning_line which applies the PROMPT_SP hack
common_get_width will "lazily" decide the screen width, which means
changing the environment variable stack. This is a surprising thing
to do from the middle of screen rendering.
Switch to passing in widths explicitly to screen.
Prior to this change, if the user's prompt was wider than the terminal, we
would reduce it to just `> `. With this change, attempt to truncate the
prompt.
For each line of the prompt, calculate its width. If the width exceeds
COLUMNS, prepend ellipsis to that line, and start removing characters
until it fits. Escape sequences are skipped.
Fixes#904
If we output text and end up in the last column, the sticky right edge
will cause a clr_eos to erase the last character. Ensure this doesn't
happen by not issuing clr_eos in that case.
Fixes#6951
Use inline initializers rather than the constructor, and adopt some
maybe_t.
Also move post_buff_1 and post_buff_2 to local variables instead of
member variables.
This was, under some circumstances, apparently off by one.
If a suggestion was really long, like
```fish
infocmp | string split , | string trim | string match -re . | while read -d = -l key val; test -z "$val"; and continue; string match -q '*%*' -- $val; and continue; test (string replace -ra '\e([\[\]]|\(B).*[\comJKsu]' '' -- a(tput $key)b) = ab; or echo $key $val; end > xterm
```
(I'm assuming longer than $COLUMNS), it would staircase like with a wrong wcwidth.
This reverts commit 15a5c0ed5f.
This stops trying to see if the previous line is wider if it is a
prefix of the current one.
Which turns out to be true often enough that it's a net benefit.
This passes character width as an argument for a few functions.
In particular, it hardcodes a width of "1" for a space literal.
There's no reason to compute wcwidth for the length of the prompt.
This measured *all* the characters on the commandline, and saved all
of them in another wcstring_list_t, just to then do... nothing with
that info.
Also, it did wcslen for something that we already have as wcstring,
reserved a vector and did a bunch of work for autosuggestions that
isn't necessary if we have more than one line.
Instead, we do what we need, which is to figure out if we are
multiline and how wide the first line is.
Fixes#5866.
line_shared_prefix explains in its comment that
> If the prefix ends on a combining character, do not include the
previous character in the prefix.
But that's not what it does.
Instead, what it appears to do is to return idx for *every* combining
mark. This seems wrong to begin with, and it also requires checking
wcwidth for *every* character.
So instead we don't do that. If we find the mismatch, we check if it's
a combining mark, and then go back to the previous character (i.e. the
one before the one that the combining mark is for).
My tests found no issues with this, other than a 20% reduction in
pasting time.
