Of course, that assumes it came from a place of corporate strategy rather than individual habit, which could have been learned from other older systems.

https://en.wikipedia.org/wiki/IBM_PC_keyboard

Firstly it was a breaking change from dos. Dos programs used Enter. And enter meant you could capture numeric data using 1 hand, since the numeric keypad has an enter key.

That means left hand can stay on the (paper) source. Right hand types. People got fast at this. (Really fast). And this pattern lives on in some programs kline Excel).

Lots of people (ie my customers) hated needing both hands on the keyboard. Lots of our programs allowed mapping of enter=tab.

I should be clear. It's not the "name" of the key that matters, it's the location.

The dual-use of the key is just an annoyance we live with. Sometimes the key behaves as a navigator, but in other cases it behaves as a spacer. Daft. (Enter would have the same problem. )

The best solution (by far) would gave been to add another key to the keyboard. Preferably in the numeric key pad. We got lots of new keys in that era. Hindsight says we should have added a "move on" key at that time.

The same issue arises (with much higher frequency) with Enter and even in the modern world I'm sure we all have a pretty complex ruleset we've committed of when ctrl+crlf triggers a newline, or a message send and what the corresponding behaviors of a bare crlf and shift+crlf are.

In HN's editor shift+crlf and a bare crlf cause a newline creation and ctrl+crlf does nothing - but often times ctrl+crlf will trigger a form/message/whatever submission, shift+crlf often causes a raw newline insertion (even when in a form context) and then a bare crlf might do one - might do the other or might even do neither! Those are the common bindings but I have seen exceptions and inversions of bindings with shift+crlf causing form submission while requiring ctrl+crlf for raw newline insertion.

All this stuff is just super annoying and causes a lot of user friction (and for a long time MSFT's style guide was considered a seminal reference for best practices as ironic as they may seem to folks these days).

RIP /.

In the 80's IBM had a whole class of high level technical people called "Systems Engineers" whose entire job description was to opine on the merits of any given system. Not write systems, not debug them, and certainly not to explain them, it was simply to opine "you're doing it wrong."

Lame.

The IBM 3270 was a device for filling up forms. The mainframe sent the terminal a form with blanks, and the terminal let the user fill in the blanks. The terminal hardware prevented the user from overwriting the static parts of the form, and could apply some other form constraints, such as numeric fields. That was all done by the terminal. When the form was filled in, the user pressed ENTER, and the completed form was sent to the mainframe as one transaction. This approach let one mainframe service huge numbers of terminals. The user never experienced delays while typing and could type at full speed, often without looking.

PCs didn't have that usage model. The PC crowd was thinking "typewriter". One of the first terminals for home computers was called the "TV Typewriter".

Web forms do have that model, but with less consistency.

[1] https://sharktastica.co.uk/resources/images/model_bs/themk_1...

And that was true for many DOS programs. Pressing Return would just go to the next field, not submit the form. That was one of the things that needed some getting used to on Windows.

so they spent seven layers of management escalating against their own standard: https://archive.org/details/ibmsj2703E/page/n13/mode/2up

I was once told that the tab key can be represented in different ways on different systems, and that's why spaces are safer because they're always represented the same.

Is that what Brendan was trying to say?

To explain: control-shift-u allows entering a Unicode character by its hexadecimal code. This presumably depends on the Input Method Editor (IME) in use, which is something I've never fully understood, but this seems to work widely across different desktop environments (Xfce, KDE) and display servers (Xorg, Wayland).

However, it might also be reasonable to have a key or key combination (some programs use ^V) to enter control characters as data rather than as commands.

It might also be a consideration when designing a new computer (which does not have to be the same as existing ones); I had thought about such things and may make such a consideration.

It had a purpose, and it got hijacked and made its actual purpose more difficult to use.

It's not dissimilar to Apples initial Touch Bar and then removing the Escape key.

Average user might never use that key; average developer doesn't got long without using that key for its purpose.

I somewhat get the argument, but if you're writing code in the HN textarea you're doing something wrong (for code where tab/space matters anyways). Like, any code editor will use the tab key properly.

Though, it sills maddens me there's no somewhat universal tab-entry in OSes like we have with enter (somewhat because there's a mix of shift+enter, alt+enter and cmd+enter). All of shift/alt/ctrl tab are usually also hijacked.

(It's intended to allow video games that use standard OS controls to be controlled sanely with a gamepad.)