Subject: lib/2792: Patch for conformance with psd/19.curses
To: None <firstname.lastname@example.org>
From: Peter Seebach <email@example.com>
Date: 09/29/1996 11:34:05
>Synopsis: werase() and friends don't move to 0, 0.
>Responsible: lib-bug-people (Library Bug People)
>Arrival-Date: Sun Sep 29 09:50:01 1996
>Originator: Peter Seebach
Usenet Fact Police
System: NetBSD taniemarie 1.2_BETA NetBSD 1.2_BETA (SEEBS) #0: Fri Aug 16 17:16:09 CDT 1996 seebs@taniemarie:/usr/src/sys/arch/amiga/compile/SEEBS amiga
werase(), erase(), wclear(), and clear() are all supposed to move
to 0, 0 in the window erased or cleared. They don't.
I believe I submitted this, and it got bounced for lack of
documentation that this is supposed to happen. So...
Resets the entire window to blanks. If win is a
screen, this sets the clear flag, which will cause a
clear-screen sequence to be sent on the next refresh()
call. This also moves the current (y, x) co-ordinates
to (0, 0).
Erases the window to blanks without setting the clear
flag. This is analagous to clear(), except that it
never causes a clear-screen sequence to be generated on
a refresh(). This has no associated "mv" command.
I read this as asserting that erase also moves to 0, 0, because
it is supposed to behave like clear.
This behavior has been observed on other systems, and comes up
because some programs assume the observed behavior, or the documented
UTSL, or write simple programs that clear a window and put a character
*** erase.c.org Sun Sep 29 11:29:48 1996
--- erase.c Sun Sep 29 11:29:58 1996
*** 68,72 ****
--- 68,73 ----
__touchline(win, y, minx, maxx - win->lines[y]->line,
+ wmove(win, 0, 0);