[btschaegg]

  What do you hate about terminals?

Escape sequences. The current system is basically a giant bag of baggage we inherited from ye olden days. If implemented today I'd guess it would make much more sense to let a terminal application determine the actual key combination pressed (such as C-Tab, for example). I'm pretty sure that wouldn't be very easy to change, though (at least while keeping compatibility).

Edit: To clarify: I'm referring mainly to the fact that certain key combinations are not mapped at all, while other ones are synonyms for special keys, i.e.: ^[ is Escape,^I is Tab etc.

cf.: http://wiki.bash-hackers.org/scripting/terminalcodes

[terminal-survey]

Oh yes. We want to have an API where clients (i.e. programs running in the terminal) can receive actual key/pointer/touch events if they choose to. The terminal may retain control over a few crucial keysequences (similar to how Ctrl-Alt-Del is always handled by the OS on Windows), but it has to inform the client about that.

[btschaegg]

Very good to hear! That alone makes me root for you guys.

Edit: BTW: If you really get a project going, make sure to inform us how to chip in (at least in monetary way, if nothing else. I'd like to be able to pay anyone who tackles this a beverage of their choice ;-) ).

[terminal-survey]

As soon as the project is at a point where we feel comfortable showing it to a wider audience, we'll make a proper announcement and post it to HN (among other places).

[bitwize]

So basically, you hate ASCII and Unicode.

[btschaegg]

Not really, just the way that keyboard input is mapped to a charset (like ANSI or Unicode). A keyboard is not a device that is 100% compatible with any character set (mainly because it is an array of keys that have an arbitrary meaning in a charset).

The current terminal architecture enforces any application to adopt its mapping of key combination to code points, which doesn't really make sense, at least from an input perspective (think of binding C-Tab in Vim to something: You can't, because the terminal knows no representation for it).

What would make sense OTOH is for the translation to happen in the application itself -- and maybe having a common API that makes the default mapping easy to use.

If I read [1] correctly, that's basically the same idea -- introduce a new API with which an application can determine which buttons were actually pressed as opposed to just reacting to an ANSI control signal that could've been produced in multiple ways.

Peripherals have the same problem, by the way: The USB HID for example can't send code points to the computer, but can only produce key codes, which are then interpreted by the keyboard driver. Sadly, this means that I can't tell my Ergodox keyboard to send an `ä` to the computer directly, only the combination that would produce this character if the right language has been selected.

Edit: Also, to quote the Plain White T's: Hate is a strong word... ¯\_(ツ)_/¯

[1]: https://news.ycombinator.com/item?id=16015036

[bitwize]

What you say about keyboards is true for PC keyboards, but was not always, historically, the case. Terminals always sent the ASCII code of the pressed key(s), and especially in early terminals, all CTRL really did was to mask off the highest bits of the transmitted code leaving a value between 0-31 -- the ASCII control range. That's why ^I is TAB and ^[ is escape.

If we implemented what you proposed, terminal emulators wouldn't be terminal emulators anymore -- they'd be some sort of generic input and output framework. While we're at it, why don't we include another API to take advantage of the high-color framebuffer displays most modern computers enjoy rather than just displaying a grid of fixed-width text characters. Oh look, we've just reinvented X11. Again (see: Wayland).

Or how about no, because it's yet another library dependency in what should be a straightforward terminal program, and the whole solution breaks when the program is talking to a real live terminal (as Linux programs can still actually do) because there is no "underlying key event" from a terminal. And if you are assuming an environment like X11 or Wayland, just write an X11 or Wayland program and be done with it. (Both vim and Emacs have taken this approach, and AFAIK support keybindings of the type you describe while running in graphical mode.)

[btschaegg]

As far as I can see it, we basically agree on everything discussed so far, except for the idea that it might be worth to try and fix some historical shortcomings.

While that's a worthwhile discussion to have and I see the difficulties in maintaining compatibility (see my original post), I'd say that arguing either way goes somewhat against the premise of this thread.