* 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).