* Bug in echotc ? @ 2005-03-02 9:10 Bart Schaefer 2005-03-02 15:08 ` Clint Adams 0 siblings, 1 reply; 5+ messages in thread From: Bart Schaefer @ 2005-03-02 9:10 UTC (permalink / raw) To: zsh-workers I was fooling with something related to the discussion of nopromptcr workarounds. I tried this: schaefer[505] echotc cm $LINES $COLUMNS ; sleep 5; echo here here That doesn't look like column 80 to me, but I checked "man termcap" which says (and "man terminfo" confirms): cm Cursor move to row %1 and column %2 (on screen) Nevertheless, I tried "echotc cm $COLUMNS $LINES" instead, and got what I expected the first to have done. Is echotc broken, or is the manual page confused? (Using "echoti cup $LINES $COLUMNS" works correctly.) ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bug in echotc ? 2005-03-02 9:10 Bug in echotc ? Bart Schaefer @ 2005-03-02 15:08 ` Clint Adams 2005-03-02 16:10 ` Clint Adams 0 siblings, 1 reply; 5+ messages in thread From: Clint Adams @ 2005-03-02 15:08 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers > Is echotc broken, or is the manual page confused? echotc is broken. I think it's still broken after this patch. Index: Src/Modules/termcap.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Modules/termcap.c,v retrieving revision 1.18 diff -u -r1.18 termcap.c --- Src/Modules/termcap.c 7 Dec 2004 16:55:11 -0000 1.18 +++ Src/Modules/termcap.c 2 Mar 2005 15:04:42 -0000 @@ -155,7 +155,7 @@ tputs(t, 1, putraw); else { num = (argv[1]) ? atoi(argv[1]) : atoi(*argv); - tputs(tgoto(t, atoi(*argv), num), num, putraw); + tputs(tgoto(t, num, atoi(*argv)), num, putraw); } return 0; } ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bug in echotc ? 2005-03-02 15:08 ` Clint Adams @ 2005-03-02 16:10 ` Clint Adams 2005-03-02 18:20 ` Bart Schaefer 0 siblings, 1 reply; 5+ messages in thread From: Clint Adams @ 2005-03-02 16:10 UTC (permalink / raw) To: Bart Schaefer, zsh-workers > echotc is broken. I think it's still broken after this patch. This is probably a bit more appropriate. Index: Src/Modules/termcap.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Modules/termcap.c,v retrieving revision 1.19 diff -u -r1.19 termcap.c --- Src/Modules/termcap.c 2 Mar 2005 15:12:30 -0000 1.19 +++ Src/Modules/termcap.c 2 Mar 2005 16:10:10 -0000 @@ -154,8 +154,9 @@ if (!argct) tputs(t, 1, putraw); else { + /* This assumes arguments of <lines> <columns> for cap 'cm' */ num = (argv[1]) ? atoi(argv[1]) : atoi(*argv); - tputs(tgoto(t, num, atoi(*argv)), num, putraw); + tputs(tgoto(t, num, atoi(*argv)), 1, putraw); } return 0; } ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bug in echotc ? 2005-03-02 16:10 ` Clint Adams @ 2005-03-02 18:20 ` Bart Schaefer 2005-03-02 18:25 ` Clint Adams 0 siblings, 1 reply; 5+ messages in thread From: Bart Schaefer @ 2005-03-02 18:20 UTC (permalink / raw) To: zsh-workers On Mar 2, 11:10am, Clint Adams wrote: } Subject: Re: Bug in echotc ? } } > echotc is broken. I think it's still broken after this patch. } } This is probably a bit more appropriate. } } else { } + /* This assumes arguments of <lines> <columns> for cap 'cm' */ } num = (argv[1]) ? atoi(argv[1]) : atoi(*argv); } - tputs(tgoto(t, num, atoi(*argv)), num, putraw); } + tputs(tgoto(t, num, atoi(*argv)), 1, putraw); } } Hmm. The tputs routine applies padding information to the string str and outputs it. The str must be a terminfo string variable or the return value from tparm, tgetstr, or tgoto. affcnt is the number of lines affected, or 1 if not applicable. putc is a putchar-like routine to which the characters are passed, one at a time. So it seems like what we really want is more like num = atoi(*argv); t = tgoto(t, (argv[1] ? atoi(argv[1]) : num), num); tputs(t, num, putraw); Because atoi(*argv) is "the number of lines affected". Except it isn't, quite, because really the number of lines affected is the difference between the current line and the target line. So maybe 1 is the right value to use for the second argument of tputs() after all. Except if this isn't a "cm" but rather a relative line-motion such as "DO" or "UP" then ... maybe what we want is num = atoi(*argv); if (argct == 1) tputs(tgoto(t, num, num), num, putraw); else tputs(tgoto(t, atoi(argv[1]), num), 1, putraw); Except it's not clear *that* does the right thing with "LE" or "RI". Gag. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bug in echotc ? 2005-03-02 18:20 ` Bart Schaefer @ 2005-03-02 18:25 ` Clint Adams 0 siblings, 0 replies; 5+ messages in thread From: Clint Adams @ 2005-03-02 18:25 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers > Because atoi(*argv) is "the number of lines affected". Except it isn't, > quite, because really the number of lines affected is the difference > between the current line and the target line. So maybe 1 is the right > value to use for the second argument of tputs() after all. Except if My thought was based on the assumption that affcnt is used only for delay padding. > this isn't a "cm" but rather a relative line-motion such as "DO" or "UP" > then ... maybe what we want is > > num = atoi(*argv); > if (argct == 1) > tputs(tgoto(t, num, num), num, putraw); > else > tputs(tgoto(t, atoi(argv[1]), num), 1, putraw); > > Except it's not clear *that* does the right thing with "LE" or "RI". > Gag. I think that there's probably a reason everyone says to use terminfo instead. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2005-03-02 18:25 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-03-02 9:10 Bug in echotc ? Bart Schaefer 2005-03-02 15:08 ` Clint Adams 2005-03-02 16:10 ` Clint Adams 2005-03-02 18:20 ` Bart Schaefer 2005-03-02 18:25 ` Clint Adams
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).