On Sun, Jun 12, 2005 at 12:24:43AM -0400, Daniel Jacobowitz wrote: > On Sun, Jun 12, 2005 at 01:27:05PM +0930, Ron wrote: > > I'll be happy to make and test a patch if there is agreement on > > a desirable remedy. Who (else) would I need to convince to make > > that a useful thing to pursue? > > Thomas Dickey. But, don't you think that any action which moves the > cursor off the screen must be an error? Remember, the cursor is > _visible_; we can't paint it if it's gone out of bounds.
Yes, I agree that is the case (and moreso if it would be directly addressing hardware to set its position). I think the SVr4 behaviour recognises this fully to one extreme. I would imagine on some terminals it may not even be possible to see the a character that was under a cursor left parked in the LR position. > I don't think that there's a valid solution to this without a function > which adds characters to the screen, and leaves the cursor at its > previous location. The other option might be to wrap it back to the top left in full screen mode (since it's next location is unspecified in anything I can find), though I'm inclined to agree simply leaving the cursor in the LR position after a write to it would offer the least surprises to existing code that does something blindly writing on the last line. (or alternately wrap to the beginning of the last line, but I think I prefer that the least of these choices) What you suggest would essentially be the result of simply returning OK instead of ERR when this is trapped, unless I've misread something, since we already reset the cursor back to that position now in the event of this occurring if you ignore the errors like most people seem to. That would indeed be a special case for writing a character, but we already appear to have a special case unique to ncurses(?) in this situation (succeed but return error, leaving the cursor one spot back) -- hmm ok, I can see how some might use that if they were writing char at a time... OTOH, it is still not clear how you portably can use that without masking other potentially real errors when you write to that spot. "Breaks a lot of existing code" is a good counter argument to any proposed change like this, and I'll accept that if its justified, (aka Thomas Dickey or yourself assert it to be the case :) but my feeling at present is still that if we (already) make a special case to permit this, and make a special case to (not) move the cursor when that position is written to), then the error is in fact averted internally by the lib (and if it must be reported at all, would perhaps be the thing better returned via an ncurses specific _NOTADVANCED flag or similar instead). I don't know how many apps might write until they simply run out of screen. I wouldn't expect many, but I'm surely not the best judge. This does suggest another alternative to me though. Given that: All routines return the integer ERR upon failure and OK on success (the SVr4 manuals specify only "an integer value other than ERR") upon successful completion, unless otherwise noted in the preceding routine descriptions. We could return something other than ERR _and_ other than OK. Since we are (il)legitimately somewhere between those two in this case. susv2 is a little more specific than that about the return codes, but not about what actually constitutes an error ;-) I'm not normally into 'colour coded' error status values, but it seems a bit safer than just switching to the opposite 'lie' about what happened with a write to that position in this particular case and is probably the most (easily) portable... Ron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
