Hacker News Reader

Comment by speerer | Hacker News Reader

> Nobody ever wants to be in the middle of a line, then move down to the next line and continue writing in the next column from where you left off. No real-world program ever wants to do that.

I routinely do this while drafting text and tables, and isn't this akin to what multi-cursor input achieves in many text editors?

View on HN

You are missing a subtle issue: let's say you want to type the numbers 1-3 above each other. If you send 1NL2NL3 the result will be a set of stairs

  1
   2
    3

Since after typing the digit the writing head is behind that character. You have to add a backspace to go back one column. 1NLBS2NLBS3 which then pushes the Cursor back to the right column.

Once you add more than one character per row its all over anyways.

You are absolutely right that I didn't consider that. Thank you!

The reason is because I have just been typing into a table in a WYSIWYG editor which undoes the problem for me, returning to the beginning of each cell.So I tricked myself, because that is of course not what's being discussed in the article.

> Once you add more than one character per row its all over anyways.

Ah, but that can be solved by returning the carriage to the start of the line :)

Thus giving you the perfectly valid control sequence: LFCR!

Which can be easily replaced with a single control sequences since parts never make sense on their own

Wouldn't the backspace go back up to the previous line, since the only character between each of those numbers is the newline?

In there definition control signals position the cursor (typing head) on the screen (paper in typewriter), they don't operate on the command stream.

Typing in tables, etc. Is a reasonable use case. Especially on a line feed printer or typewriter from which these movements descended.

True, if you assume a table here has 1 column. If you are printing multiple columns you print a full row at a time.

Reply on news.ycombinator.com