Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: [PATCH] use clear-to-end to reduce trailing whitespace
- X-seq: zsh-workers 53357
- From: Daniel Colascione <dancol@xxxxxxxxxx>
- To: Oliver Kiddle <opk@xxxxxxx>
- Cc: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>, zsh-workers@xxxxxxx
- Subject: Re: [PATCH] use clear-to-end to reduce trailing whitespace
- Date: Sun, 09 Feb 2025 14:45:14 -0800
- Archived-at: <https://zsh.org/workers/53357>
- In-reply-to: <94683-1737931820.416910@86vm.X0gk.K6JY> (Oliver Kiddle's message of "Sun, 26 Jan 2025 23:50:20 +0100")
- List-id: <zsh-workers.zsh.org>
- References: <87ed121ui4.fsf@dancol.org> <CAH+w=7bXVUpVVZ-wauCQTchCJK60zaqCSZUV+KKQ93tNoe2VDQ@mail.gmail.com> <CAH+w=7aWgKLzQ6MZfsyEYabdGic0qX6tfsC4HX4g8vBAW-+Lpw@mail.gmail.com> <875xma9xad.fsf@dancol.org> <94683-1737931820.416910@86vm.X0gk.K6JY>
Oliver Kiddle <opk@xxxxxxx> writes:
> On 19 Jan, Daniel Colascione wrote:
>> The attached new version of the patch should handle right prompts too. I
>> tested it with both zero and non-zero right prompt margins.
>
> Aside from right prompts, the other thing that comes to my mind
> as needing to be tested is the ellipses that are printed when the
> command-line is too big for the terminal.
>
> After resizing the terminal to not be too large and then filling it with
> text, I see issues with your patch. With the first patch, backspace on
> a line that was longer that the terminal is wide caused issues. With
> the second patch, I notice issues if I fill the command-line with more
> lines than will fit. Then when I move the cursor up, at some point it
> loses the prompt and replaces it with some of the text from the line.
> I would speculate that this is caused by the terminal scrolling by one
> line when that's not wanted. I'm mostly either using urxvt or foot.
>
> I would also suggest applying a background colour to the entire text
> entry area as that can show up problems that would not otherwise be
> present or apparent.
>
> I don't as such have objections to removing code that's only there for
> terminals that have long ago ceased to be used.
Thanks for testing. Is there any way you can give me a more precise
recipe for reproducing the issue you're describing with the second,
improved patch? When I start up urxvt (v9.31) and fill the terminal
window with a command line with more lines than the terminal is high, I
can't reproduce the issue of pieces of the command line edit buffer
migrating into what should be the prompt. I'm not sure whether you
meant the situation of
1. the edit buffer being a single big line that wraps to more lines
that the terminal is tall, or
2. a multi-line edit buffer (with newlines inserted with C-v C-j) with
more lines than the terminal is tall
so I tried both scenarios and both work fine for me with zsh --norcs.
I can't see any difference in visible output between stock zsh and zsh
with my patch. I see cursor movement and ellipsis-drawing
work normally.
For convenience, I've attached another version of my patch.
I've rebased it onto latest zsh master and fix the unused variable
compiler warning. It shouldn't have any strange line endings either,
not unless mu4e is messing it up in some way.
Can you re-test, and if the problem still repros with my patch and not
with stock zsh master, give me a step-by-step recipe for reproducing the
problem myself?
Thanks!
diff --git a/Src/Zle/zle_refresh.c b/Src/Zle/zle_refresh.c
index f076bdd61..2605792b1 100644
--- a/Src/Zle/zle_refresh.c
+++ b/Src/Zle/zle_refresh.c
@@ -1738,12 +1738,11 @@ refreshline(int ln)
col_cleareol, /* clear to end-of-line from this column */
i, j, /* tmp */
ins_last, /* insert pushed last character off line */
- nllen, ollen, /* new and old line buffer lengths */
- rnllen; /* real new line buffer length */
+ nllen, ollen; /* new and old line buffer lengths */
/* 0: setup */
nl = nbuf[ln];
- rnllen = nllen = nl ? ZR_strlen(nl) : 0;
+ nllen = nl ? ZR_strlen(nl) : 0;
if (ln < olnct && obuf[ln]) {
ol = obuf[ln];
ollen = ZR_strlen(ol);
@@ -1797,19 +1796,15 @@ refreshline(int ln)
With automatic margins, we shouldn't do it if there is another line, in
case it messes up cut and paste. */
- if (hasam && ln < nlnct - 1 && rnllen == winw)
- col_cleareol = -2; /* clearing eol would be evil so don't */
- else {
- col_cleareol = -1;
- if (tccan(TCCLEAREOL) && (nllen == winw || put_rpmpt != oput_rpmpt)) {
- for (i = nllen; i && ZR_equal(zr_sp, nl[i - 1]); i--)
- ;
- for (j = ollen; j && ZR_equal(ol[j - 1], zr_sp); j--)
- ;
- if ((j > i + tclen[TCCLEAREOL]) /* new buf has enough spaces */
- || (nllen == winw && ZR_equal(zr_sp, nl[winw - 1])))
- col_cleareol = i;
- }
+/* 2: see if we can clear to end-of-line. Always use TCCLEAREOL when available
+ to avoid leaving trailing spaces when moving between lines of different lengths. */
+
+ col_cleareol = -1;
+ if (tccan(TCCLEAREOL) && rpromptw == 0) {
+ /* Find first trailing space in new line */
+ for (i = nllen; i && ZR_equal(zr_sp, nl[i - 1]); i--)
+ ;
+ col_cleareol = i;
}
/* 2b: first a new trick for automargin niceness - good for cut and paste */
Messages sorted by:
Reverse Date,
Date,
Thread,
Author