Strictly speaking, due to the way information was passed via telnet, there was no such thing as "backspacing over a newline". A newline didn't add a newline character to the buffer, it simply moved the cursor position. This is also what causes so many issues with other things, you keep thinking in terms of a "document", when it comes to storing the actual data of what transpired. A telnet client, even when you where lucky enough to have a display with some mad number of characters possible, like 160x43, had the display work like:
160 characters + color coding
160 characters + color coding
...
160 characters + color coding
It wasn't:
30 characters + newline
12 characters + newline
...
So, no, a backspace not only shouldn't erase a newline, in telnet, it should land the cursor, for all following data, at the "last possible" character position of the display, on the prior line. Logically, the newline shouldn't even exist, at all, once the characters for a line are stored, except maybe in the back buffer, and then, its purely treated as a marker, designating where *that* line ends (in fact, it isn't even needed in the buffer, since, if the client wraps at X characters, like 80, then **every line** will have 80 characters, to finding which line you are on is purely a matter of counting how many groups of 80 characters you have. If someone changes it to be 100, or 60 characters, you "backfill/rewrap/truncate" the buffers lines, to make it 100 characters per line. In any case, you never treat the line content as an arbitrary number of characters, its always what ever the wrap point is in size, even if only two characters where ever placed there.
I hadn't thought about it, but I think this is one of the hangups with working out text positioning. You seem to assume that such positioning works over the entire buffer, the whole thing needs to be recorded, and that scrolling back should replay it. Nope.. The only extra character that should *ever* be in the buffer, technically, would be a page break, and only for convenience, since you do what to be able to "replay" back to individual pages, maybe. All other positioning, changes, become "fixed" once they get buffered, and, strictly speaking, that means everything more than 23 lines (43, assuming your telnet negotiation, or something, can tell you have that many to work with, but since like 1% of PCs could do that, and telnet didn't support it exactly...). So, while trying to move "down" 23 lines would add 23 blank lines, moving "up" 24 lines would only get you 22 lines from where you are now (since you can't scroll "past" the "top of the display", which has to be a set size.
Yes, clients can now disobey those things, and have as many lines on the display as can fit, but the "positioning" functions all assume a "known" number of lines, and columns, with "no" special characters stored (or, at least not backspaces, newlines, carriage returns, etc.) As far as those functions are concerned, your "display" is still a fixed size, 80x23 grid, and everything else that went on is completely irrelevant to what is "on" that display. As such, using backspace to position makes perfect sense, and was probably how some systems implemented positioning, using backspace, forward, up, and newline, instead of having a machine language method of directly controlling the cursor position (or, at least that would be my guess). |
![[Go to top]](/images/gototop.gif){kind=small}
top