141–150 of 179 posts
Really interesting to read. I have used a lot of strange systems in my time. In the military signals group I have worked a lot with teletypewriter systems and the like - also the civilian telex system and the Aeronautical Fixed Telecommunication Network: https://en.wikipedia.org/wiki/Aeronautical_Fixed_Telecommuni... One thing the article doesn't mention is that some of the old teletypewriters were so slow that you c…
Earlier quoted context omitted.
But we do NOT need to setup CRLF translation at all? Who in his sane mind uses CRLF even under windows? All my source codes are in UNIX format (aka LF only) and I use it consistent under Windows, Cygwin and UNIX.. Why make your life harder?
> Who in his sane mind uses CRLF even under windows? All my source codes are in UNIX format (aka LF only) and I use it consistent under Windows, Cygwin and UNIX.. Why make your life harder? Why would you use LF if the focus of the application that you develop is Windows? You make the life harder for these users. :-) Seriously: your argument typically comes from developers who consider GNU/Linux as a first-class citiz…
It's a damn shame that the control characters for "Field Separator" (FS ASCII 28 decimal) and "Record Separator" (RS ASCII 30 decimal) weren't used instead of TAB and CR/LF. Then the whole CRLF vs CR vs LF for line endings in files would have been totally avoided, with CR returning the print-head/cursor to the left-most position (right-most on R-L languages) and LF literally moving the print-head/cursor down. The dri…
Editing a file like that with a text editor is a right pain. Inserting these characters isn't all that straight-forward, and everything will be on a single line. In theory RS could be treated as a newline, which will only add to the line ending confusion. I think this is one of those things that sounds kind of nice in principle, but where the real-world practicalities just don't work out.
The article illustrates an old 1930's Teletype model 15 with it's separate Carriage Return and Line Feed keys, and claims that these were kept separate (vs a single key/code that performed/represented CR + LF) so that sending the separate LF gave the receiving device enough time to mechanically perform the CR function. I wonder if this is quite correct? This Teletype use Baudot code, not ASCII, as reflected by the ke…
I don't have additional historical context, but the reason that makes sense to me is that a LF can be repeated multiple times (e.g. for double-spaced lines, or for advancing to the next page) without needing to also issue a CR more than the initial time, since the carriage is already back to the beginning of the line.
Earlier quoted context omitted.
> Carriage return moved the paper (on typewriters before the IBM Ball) and moved the print head (the "ball" on an IBM typewriter, or the actual print head on TTYs and DECWriter equivalents) back to column 0. Carriage return always returned the carriage to the far right. Neither the print ball (if there was one), the printwheel, nor the typebars moved. Linefeed rotated the platen. It's true the carriage return lever o…
> Neither the print ball (if there was one), the printwheel, nor the typebars moved. Certainly the head moved on most if not all ball/cylinder/wheel devices. Look at the Selectrics, Teletype 33, the Diablo/Xerox/Qume terminals, as common examples.
Nice history recap, most of which I lived through, but it's missing the Bill Gates/PCDOS botch of using CR and LF as the text line separator, a result of not doing a logical translation of the characters sent by the terminal. UNIX sort of did it right by just using LF, but it would have been better to use NUL as the terminator--then there wouldn't have been the need to strip off LF on input and add it back on output…
Using NUL as the terminator would have been incredibly incompatible with Unix's choice of systems programming language. PC-DOS did not invent CRLF as the line terminator, it was already in common use in CP/M and VMS at the time.
Earlier quoted context omitted.
Using NUL as the terminator would have been incredibly incompatible with Unix's choice of systems programming language. PC-DOS did not invent CRLF as the line terminator, it was already in common use in CP/M and VMS at the time.
No, it would have been completely compatible with C ... that's the point.
> And the IBM PC – and later Microsoft Windows – went with Enter. (Actually, they first chose the ↵ arrow. I'd claim that the article draws its own wrong conclusions. The key was not renamed . On the IBM PC, the key got overloaded with two functions. The IBM PC keyboard was preceded by larger keyboards with the same mechanism, style and font for use with IBM's terminals. Those had two separate keys for ↵ and Enter. T…
Speaking of overloading and Tab, piling on the ‘next field’ function is an endless source of pain.
Where it goes off the rails is when we embed a user interface inside another user interface. That's not a problem specific to the tabulator, but also with all novigation functions, like home, forward, and back.
I rarely use web-based email interfaces, but when I do, I accidentally send half-written email messages, because I'm trying to use a block quote or something similarly indented. It's especially bad when the next field is the 'Send' button, and pressing the spacebar sends the message.
> And the IBM PC – and later Microsoft Windows – went with Enter. (Actually, they first chose the ↵ arrow. I'd claim that the article draws its own wrong conclusions. The key was not renamed . On the IBM PC, the key got overloaded with two functions. The IBM PC keyboard was preceded by larger keyboards with the same mechanism, style and font for use with IBM's terminals. Those had two separate keys for ↵ and Enter. T…
Apple keyboards don't use the ⇥ symbol anymore, it's just labeled "tab" now (and the labels are lowercase). At least on a US keyboard, possibly it's different for others. I still remember when the ⌘ key was "open apple".
And young people look at me like I’m crazy when I tell them to press “omppu Z”… But it’s a hard habit to break. I don’t even know what the official name of the key is in Finnish.
Earlier quoted context omitted.
No, it would have been completely compatible with C ... that's the point.
Completely compatible, other than making most programs incapable of expressing multiple lines in one string that is. Or a partial line in a single string, since "end of line" and "end of string" would be indistinguishable.
Anyway, it's moot since UNIX didn't take this approach. I won't respond further.