* [PATCH 0/1] prompt: Fix an off-by-one in the overf check in countpromt.
@ 2018-01-15 10:35 warepire.ml
2018-01-15 10:35 ` [PATCH 1/1] " warepire.ml
2018-01-15 11:07 ` [PATCH 0/1] " dana
0 siblings, 2 replies; 7+ messages in thread
From: warepire.ml @ 2018-01-15 10:35 UTC (permalink / raw)
To: zsh-workers; +Cc: Warepire
From: Warepire <Warepire@users.noreply.github.com>
Additionally to the commit message: I have only managed to test this
for my own use-cases, which is a very narrow subset of tests.
There is a similar check at the bottom of the method that may need
the same change. Please have this in consideration during the review.
Warepire (1):
prompt: Fix an off-by-one in the overf check in countpromt.
Src/prompt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.15.1
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH 1/1] prompt: Fix an off-by-one in the overf check in countpromt.
2018-01-15 10:35 [PATCH 0/1] prompt: Fix an off-by-one in the overf check in countpromt warepire.ml
@ 2018-01-15 10:35 ` warepire.ml
2018-01-16 15:28 ` Bart Schaefer
2018-01-15 11:07 ` [PATCH 0/1] " dana
1 sibling, 1 reply; 7+ messages in thread
From: warepire.ml @ 2018-01-15 10:35 UTC (permalink / raw)
To: zsh-workers; +Cc: Warepire
From: Warepire <Warepire@users.noreply.github.com>
This triggers overf when the prompt is exactly as wide as the
term, causes countprompt to count a 2-line prompt as 3 lines.
Which transmits an errorneus TCUP to the PTY. In some terminals
this causes the last line of the previous command to be erased.
Hexdumping the PTY in benign and trouble cases, for my term
TCUP is represented by "\x1b[A". The NOK dumps are when the
prompt is exactly as wide as the term.
OK chunk dump:
0000 0d 1b 5b 30 6d 1b 5b 32 37 6d 1b 5b 32 34 6d 1b ..[0m.[27m.[24m.
0010 5b 4a 1b 5b 33 33 6d 7e 2f 76 74 65 2d 6e 67 2d [J.[33m~/vte-ng-
0020 30 2e 35 30 2e 32 2e 61 1b 5b 30 30 6d 20 0d 0a 0.50.2.a.[00m ..
0030 1b 5b 33 37 6d 77 61 72 65 70 69 72 65 20 25 1b .[37mwarepire %.
0040 5b 30 30 6d 20 1b 5b 4b 1b 5b 36 34 43 1b 5b 30 [00m .[K.[64C.[0
0050 31 3b 33 32 6d e2 9c 94 1b 5b 30 30 6d 20 49 4e 1;32m....[00m IN
0060 53 1b 5b 36 39 44 0d 0d 1b 5b 41 1b 5b 3f 32 30 S.[69D...[A.[?20 <-- Correct number of TCUP
0070 30 34 68 1b 5b 30 6d 1b 5b 32 37 6d 1b 5b 32 34 04h.[0m.[27m.[24
0080 6d 1b 5b 4a 1b 5b 33 33 6d 7e 2f 76 74 65 2d 6e m.[J.[33m~/vte-n
0090 67 2d 30 2e 35 30 2e 32 2e 61 1b 5b 30 30 6d 20 g-0.50.2.a.[00m
00a0 0d 0a 1b 5b 33 37 6d 77 61 72 65 70 69 72 65 20 ...[37mwarepire
00b0 25 1b 5b 30 30 6d 20 1b 5b 4b 1b 5b 36 34 43 1b %.[00m .[K.[64C.
00c0 5b 30 31 3b 33 32 6d e2 9c 94 1b 5b 30 30 6d 20 [01;32m....[00m
00d0 49 4e 53 1b 5b 36 39 44 INS.[69D
NOK chunk dump:
0000 0d 1b 5b 30 6d 1b 5b 32 37 6d 1b 5b 32 34 6d 1b ..[0m.[27m.[24m.
0010 5b 4a 1b 5b 33 33 6d 7e 2f 74 65 73 74 2d 64 69 [J.[33m~/test-di
0020 72 2f 61 61 61 61 61 61 61 61 61 61 61 61 61 61 r/aaaaaaaaaaaaaa
0030 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa
0040 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa
0050 61 61 61 61 61 2f 62 62 62 62 62 62 62 62 62 62 aaaaa/bbbbbbbbbb
0060 62 62 62 2f 63 63 63 1b 5b 30 30 6d 20 0d 0a 1b bbb/ccc.[00m ...
0070 5b 33 37 6d 77 61 72 65 70 69 72 65 20 25 1b 5b [37mwarepire %.[
0080 30 30 6d 20 1b 5b 4b 1b 5b 36 34 43 1b 5b 30 31 00m .[K.[64C.[01
0090 3b 33 32 6d e2 9c 94 1b 5b 30 30 6d 20 49 4e 53 ;32m....[00m INS
00a0 1b 5b 36 39 44 0d 0d 1b 5b 41 1b 5b 41 1b 5b 3f .[69D...[A.[A.[? <--- Incorrect number of TCUP
00b0 32 30 30 34 68 1b 5b 30 6d 1b 5b 32 37 6d 1b 5b 2004h.[0m.[27m.[
00c0 32 34 6d 1b 5b 4a 1b 5b 33 33 6d 7e 2f 74 65 73 24m.[J.[33m~/tes
00d0 74 2d 64 69 72 2f 61 61 61 61 61 61 61 61 61 61 t-dir/aaaaaaaaaa
00e0 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa
00f0 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa
0100 61 61 61 61 61 61 61 61 61 2f 62 62 62 62 62 62 aaaaaaaaa/bbbbbb
0110 62 62 62 62 62 62 62 2f 63 63 63 1b 5b 30 30 6d bbbbbbb/ccc.[00m
0120 20 0d 0a 1b 5b 33 37 6d 77 61 72 65 70 69 72 65 ...[37mwarepire
0130 20 25 1b 5b 30 30 6d 20 1b 5b 4b 1b 5b 36 34 43 %.[00m .[K.[64C
0140 1b 5b 30 31 3b 33 32 6d e2 9c 94 1b 5b 30 30 6d .[01;32m....[00m
0150 20 49 4e 53 1b 5b 36 39 44 INS.[69D
NOK chunks from I/O channel:
0 chars and 0 bytes in 1 chunks left to process.
read/bp:
0000 00 0d 1b 5b 30 6d 1b 5b 32 37 6d 1b 5b 32 34 6d ...[0m.[27m.[24m
0010 1b 5b 4a 1b 5b 33 33 6d 7e 2f 74 65 73 74 2d 64 .[J.[33m~/test-d
0020 69 72 2f 61 61 61 61 61 61 61 61 61 61 61 61 61 ir/aaaaaaaaaaaaa
0030 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa
0040 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa
0050 61 61 61 61 61 61 2f 62 62 62 62 62 62 62 62 62 aaaaaa/bbbbbbbbb
0060 62 62 62 62 2f 63 63 63 1b 5b 30 30 6d 20 0d 0a bbbb/ccc.[00m ..
0070 1b 5b 33 37 6d 77 61 72 65 70 69 72 65 20 25 1b .[37mwarepire %.
0080 5b 30 30 6d 20 [00m
read 132/5355 bytes, again? yes, active? yes
read/bp:
0000 00 1b 5b 4b 1b 5b 36 34 43 1b 5b 30 31 3b 33 32 ..[K.[64C.[01;32
0010 6d e2 9c 94 1b 5b 30 30 6d 20 49 4e 53 1b 5b 36 m....[00m INS.[6
0020 39 44 9D
read 165/5355 bytes, again? yes, active? yes
read/bp:
0000 00 0d 0d 1b 5b 41 1b 5b 41 1b 5b 3f 32 30 30 34 ....[A.[A.[?2004 <--- Incorrect number of TCUP
0010 68 1b 5b 30 6d 1b 5b 32 37 6d 1b 5b 32 34 6d 1b h.[0m.[27m.[24m.
0020 5b 4a 1b 5b 33 33 6d 7e 2f 74 65 73 74 2d 64 69 [J.[33m~/test-di
0030 72 2f 61 61 61 61 61 61 61 61 61 61 61 61 61 61 r/aaaaaaaaaaaaaa
0040 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa
0050 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa
0060 61 61 61 61 61 2f 62 62 62 62 62 62 62 62 62 62 aaaaa/bbbbbbbbbb
0070 62 62 62 2f 63 63 63 1b 5b 30 30 6d 20 0d 0a 1b bbb/ccc.[00m ...
0080 5b 33 37 6d 77 61 72 65 70 69 72 65 20 25 1b 5b [37mwarepire %.[
0090 30 30 6d 20 00m
read 312/5355 bytes, again? yes, active? yes
read/bp:
0000 00 1b 5b 4b 1b 5b 36 34 43 1b 5b 30 31 3b 33 32 ..[K.[64C.[01;32
0010 6d e2 9c 94 1b 5b 30 30 6d 20 49 4e 53 1b 5b 36 m....[00m INS.[6
0020 39 44 9D
Fixes: commit fa699be45debba815ea5e3ed5bfebde280d894a0
Signed-off-by: Warepire <Warepire@users.noreply.github.com>
---
Src/prompt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Src/prompt.c b/Src/prompt.c
index c478e69fb..9b9e33670 100644
--- a/Src/prompt.c
+++ b/Src/prompt.c
@@ -1087,7 +1087,7 @@ countprompt(char *str, int *wp, int *hp, int overf)
#endif
for (; *str; str++) {
- if (w >= zterm_columns && overf >= 0) {
+ if (w > zterm_columns && overf >= 0) {
w = 0;
h++;
}
--
2.15.1
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 0/1] prompt: Fix an off-by-one in the overf check in countpromt.
2018-01-15 10:35 [PATCH 0/1] prompt: Fix an off-by-one in the overf check in countpromt warepire.ml
2018-01-15 10:35 ` [PATCH 1/1] " warepire.ml
@ 2018-01-15 11:07 ` dana
1 sibling, 0 replies; 7+ messages in thread
From: dana @ 2018-01-15 11:07 UTC (permalink / raw)
To: warepire.ml; +Cc: zsh-workers, Warepire
On 15 Jan 2018, at 04:35, warepire.ml@gmail.com wrote:
>Additionally to the commit message: I have only managed to test this
>for my own use-cases, which is a very narrow subset of tests.
FYI, if it's any help, i tested this in the following, too:
* Terminal.app
* iTerm2
* Alacritty
I used a multi-line prompt where the top line had a length of COLUMNS, COLUMNS +
1, or COLUMNS - 1. I tried both with single-byte characters only and with mixed
single/multi-byte characters.
Replication:
% zle-line-init() zle reset-prompt
% zle -N zle-line-init
% PROMPT=${(l<$COLUMNS><abc>):-}$'\n%~ %# '
abcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabc
~ % echo foo
Current behaviour: The echo output is swallowed up by the next prompt.
Patched behaviour: The echo output remains unmolested.
PS: When i was testing it i had changed the comparison in both places; as
mentioned, the patch as submitted only changes the first one.
dana
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/1] prompt: Fix an off-by-one in the overf check in countpromt.
2018-01-15 10:35 ` [PATCH 1/1] " warepire.ml
@ 2018-01-16 15:28 ` Bart Schaefer
2018-01-16 17:04 ` Warepire -
0 siblings, 1 reply; 7+ messages in thread
From: Bart Schaefer @ 2018-01-16 15:28 UTC (permalink / raw)
To: zsh-workers; +Cc: warepire.ml
On Mon, Jan 15, 2018 at 2:35 AM, <warepire.ml@gmail.com> wrote:
> From: Warepire <Warepire@users.noreply.github.com>
>
> This triggers overf when the prompt is exactly as wide as the
> term, causes countprompt to count a 2-line prompt as 3 lines.
> Which transmits an errorneus TCUP to the PTY. In some terminals
> this causes the last line of the previous command to be erased.
I see this has already been pushed to the zsh git, but I'm not sure
it's entirely correct.
This may cause problems on some terminals where auto-margin causes an
additional linefeed when the rightmost (or in some cases only the
bottom rightmost) character position is written. I would be willing
to bet that the original code was intended to account for this, and
other code has changed around it.
The correct thing may be to make this conditional upon
ZLE_RPROMPT_INDENT, or introduce a similar setting to override the
terminfo assertions of auto-wrap/auto-margin so that the user can
assert whether the additional TCUP is needed.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/1] prompt: Fix an off-by-one in the overf check in countpromt.
2018-01-16 15:28 ` Bart Schaefer
@ 2018-01-16 17:04 ` Warepire -
2018-01-16 19:32 ` Bart Schaefer
0 siblings, 1 reply; 7+ messages in thread
From: Warepire - @ 2018-01-16 17:04 UTC (permalink / raw)
To: Bart Schaefer; +Cc: zsh-workers
[-- Attachment #1: Type: text/plain, Size: 2177 bytes --]
This is what I was worried about, hence why I included the cover letter.
I just tried setting ZLE_RPROMPT_INDENT=0 in my .zshrc and my terminal
freaked out, it had no idea what to do with the cursor after I reached the
bottom corner. Length or wraps of my LPROMPT didn't matter much since I
have a multi-line config. The LPROMPT will not touch that character
position, but the RPROMPT does. However, this would most likely indeed
freak out on single-line LPROMPTS, although I could not come up with a
config that'd do it.
I don't think doing this based on ZLE_RPROMT_INDENT is the way to go,
libvte based terminals require the number of TCUPs to match the number of
lines the final prompt will have when drawn. I am open for fixing this
patch, if we can reach an agreement on what the proper handling should be.
I am sadly not clever enough about shells to come up with something on my
own here. I am available in the IRC channel for discussion if that would
help the decision making, since I can test configs quite quickly that way.
On Tue, Jan 16, 2018 at 4:28 PM, Bart Schaefer <schaefer@brasslantern.com>
wrote:
> On Mon, Jan 15, 2018 at 2:35 AM, <warepire.ml@gmail.com> wrote:
> > From: Warepire <Warepire@users.noreply.github.com>
> >
> > This triggers overf when the prompt is exactly as wide as the
> > term, causes countprompt to count a 2-line prompt as 3 lines.
> > Which transmits an errorneus TCUP to the PTY. In some terminals
> > this causes the last line of the previous command to be erased.
>
> I see this has already been pushed to the zsh git, but I'm not sure
> it's entirely correct.
>
> This may cause problems on some terminals where auto-margin causes an
> additional linefeed when the rightmost (or in some cases only the
> bottom rightmost) character position is written. I would be willing
> to bet that the original code was intended to account for this, and
> other code has changed around it.
>
> The correct thing may be to make this conditional upon
> ZLE_RPROMPT_INDENT, or introduce a similar setting to override the
> terminfo assertions of auto-wrap/auto-margin so that the user can
> assert whether the additional TCUP is needed.
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/1] prompt: Fix an off-by-one in the overf check in countpromt.
2018-01-16 17:04 ` Warepire -
@ 2018-01-16 19:32 ` Bart Schaefer
2018-01-16 20:23 ` Warepire -
0 siblings, 1 reply; 7+ messages in thread
From: Bart Schaefer @ 2018-01-16 19:32 UTC (permalink / raw)
To: Warepire -; +Cc: zsh-workers
On Tue, Jan 16, 2018 at 9:04 AM, Warepire - <warepire.ml@gmail.com> wrote:
>
> I don't think doing this based on ZLE_RPROMT_INDENT is the way to go, libvte
> based terminals require the number of TCUPs to match the number of lines the
> final prompt will have when drawn. I am open for fixing this patch, if we
> can reach an agreement on what the proper handling should be.
The situation is and pretty much always has been intolerable. Some
terminals linefeed as soon as the rightmost column is filled, and most
but not all of those swallow a newline if it is the next character
sent. Some feed when anything, even a zero-width character or control
sequence, is sent when there is something in the rightmost column;
others do so only when the next character sent is printable. Others
behave in one of these ways only for the bottomost-rightmost position.
Some have a "bug compatibility mode" which means you don't know
whether they're going to do this lunacy or not. And the available
terminfo bits don't adequately describe all the combinations,
especially in the "bug compatibility" case.
One of the reasons zsh introduced the "prompt truncation" escapes is
so that the user can control whether his prompt ever reaches the
rightmost column, because there's no way for the C code to get this
right in all cases.
So whether we keep this change or one like it depends in part on which
behavior we think is now most common, because somebody is going to
have to do a workaround in their prompt settings no matter what we do.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/1] prompt: Fix an off-by-one in the overf check in countpromt.
2018-01-16 19:32 ` Bart Schaefer
@ 2018-01-16 20:23 ` Warepire -
0 siblings, 0 replies; 7+ messages in thread
From: Warepire - @ 2018-01-16 20:23 UTC (permalink / raw)
To: Bart Schaefer; +Cc: zsh-workers
[-- Attachment #1: Type: text/plain, Size: 2559 bytes --]
On Tue, Jan 16, 2018 at 8:32 PM, Bart Schaefer <schaefer@brasslantern.com>
wrote:
> On Tue, Jan 16, 2018 at 9:04 AM, Warepire - <warepire.ml@gmail.com> wrote:
> >
> > I don't think doing this based on ZLE_RPROMT_INDENT is the way to go,
> libvte
> > based terminals require the number of TCUPs to match the number of lines
> the
> > final prompt will have when drawn. I am open for fixing this patch, if we
> > can reach an agreement on what the proper handling should be.
>
> The situation is and pretty much always has been intolerable. Some
> terminals linefeed as soon as the rightmost column is filled, and most
> but not all of those swallow a newline if it is the next character
> sent. Some feed when anything, even a zero-width character or control
> sequence, is sent when there is something in the rightmost column;
> others do so only when the next character sent is printable. Others
> behave in one of these ways only for the bottomost-rightmost position.
> Some have a "bug compatibility mode" which means you don't know
> whether they're going to do this lunacy or not. And the available
> terminfo bits don't adequately describe all the combinations,
> especially in the "bug compatibility" case.
>
> One of the reasons zsh introduced the "prompt truncation" escapes is
> so that the user can control whether his prompt ever reaches the
> rightmost column, because there's no way for the C code to get this
> right in all cases.
>
> So whether we keep this change or one like it depends in part on which
> behavior we think is now most common, because somebody is going to
> have to do a workaround in their prompt settings no matter what we do.
>
I might have worded myself badly, if so, I apologize. What I meant with
proper handling was how to properly introduce a configuration setting for
this and determine it's default numerical value (or boolean?), since my
patch in it's current state may trigger the problems zsh wants to avoid (at
least in theory).
Checking through the terminfo and termcap manuals, with my poor
understanding there doesn't seem to be a (combination of) termcap(s) to
detect this safely enough to attempt it.
I have no idea what it should be called, but I am leaning on a default as
1, turning the check into "> zterm_columns - offset", and just like
ZLE_RPROMPT_INDENT users can set it to 0 if their terminal supports it (and
fixes the erased-output problem without freak-out). As the freak-outs are
much worse than the dropped line of output when comparing the possible
problems users may see by default.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-01-16 20:23 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-15 10:35 [PATCH 0/1] prompt: Fix an off-by-one in the overf check in countpromt warepire.ml
2018-01-15 10:35 ` [PATCH 1/1] " warepire.ml
2018-01-16 15:28 ` Bart Schaefer
2018-01-16 17:04 ` Warepire -
2018-01-16 19:32 ` Bart Schaefer
2018-01-16 20:23 ` Warepire -
2018-01-15 11:07 ` [PATCH 0/1] " dana
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).