Re: New line in a JTextArea (student learning here)

Wojtek Bok wrote:

The action of moving the cursor to the beginning of a new line is in fact two operations:

Two? How many buttons on your keyboard do you normally press to accomplish this?

I do not have a CRLF button on my keyboard

You have a button that, in a single keypress operation, moves the cursor to the start of the next line though.

any more than I have a CR or an LF button.

I do, when I press Enter my terminal emulator sends CR (Not CR LF).

If I happen to be leaning on my Ctrl key then my J keys acts as an LF key and I have a dedicated down-arrow key whose effects are often hard to distinguish from LF.

I do have an Enter button though. And the pretty graphic shows:
|
<----|

Which looks like two operations to me.


Nah, then the pretty graphic would be

|
v, <--

Two operations should be two arrows shouldn't it?

- move the cursor down one line
- move the cursor to the beginning of the line

Only for electromechanical teletypewriter machines that supported overprinting and underlining that way. (and their successors that try to be backwards compatible with carriage-control from the days when a carriage was a large lump of metal driven by separate motors for rotation/feed and for horizontal positioning).

Yes, but it seemed to be a natural thing, as you do have two things happen.


Not in a text file!

The ASCII standards didn't define a character or sequence for "line separator" or "line terminator" in stored files.

True, though for a text file dumped to a screen you do want new lines to start at the beginning of screen, one line down. This is two operations.

Is "move to start of next line" intrinsically two operations? More so than "move to column 1 row 11"? I wouldn't be surprised if the latter is what many curses applications end up sending to the terminal when the user presses the Enter key.

If I have my text editor in autoindent mode and press Enter the cursor rarely ends up in column 1 so a gotoXY is possibly selected by curses in preference to CR LF Cursor-right Cursor-right ...


Which is why ASCII does have two specifications CR and LF.

But screens don't have *carriages* so they don't need carriage-return. They don't have paper to *feed* through a print position a line at a time. Files especially don't have carriages or paper feeders so the need for CR and LF together as line separators seems tenuous at best.

Now as for separating information within a file (such as lines), you could use anything, as long as the file reader interprets it correctly.

Which is why LF is no less correct than CR or CR LF.


Never mind, I must be in an argumentative mood today :-)
.