Hacker News new | past | comments | ask | show | jobs | submit login
The Wonderful World of Keyboards (atom.io)
54 points by okket on Oct 17, 2016 | hide | past | web | favorite | 21 comments



If you want to see how this sort of stuff is handled by software not living inside the dystopian future of 199x Netscape, look at libxkbcommon: http://xkbcommon.org/doc/current/md_doc_quick-guide.html


If some of these native toolkits had a decent track record of producing not-hideous and usable cross-platform apps, maybe we would. That devs with real cross platform needs have been using solutions like Java Swing, Flash, Electron, etc since the 90s should be a pretty big hint.


I may be misunderstanding the top-level comment, but xkbcommon is not a cross-platform toolkit — it's an implementation of keyboard layout, derived from X11 XKB, so it's in contrast to other system-level layout systems like those of Windows and OS X. (Personally, I think XKB is an over-complicated product of the second-system effect applied to X11 keymaps, and the NeXT/Apple approach is the least bad of the common ones.)


Thanks, yeah even more applicable in this case - Electron is not perfect, but hand-crafting Atom for every native platform and toolkit is not feasible.


> hand-crafting Atom for every native platform and toolkit is not feasible.

Somehow both emacs and vim exist, and run on more platforms than Atom!

It's not a bad thing that Atom exists, although I think it's sad that folks who care about extensibility and flexibility don't just hack on emacs. But I think that if they wanted to, they could support as many platforms as emacs and vim do.


...what? The poster linked to a library implementing a way to interface keyboard events with the Linux kernel input subsystem, to show how one might solve the problem the posted blog post attempts to solve from within a web browser when one is writing native code.

You're talking about cross platform GUI development toolkits.

The two things are just 2 completely and utterly different topics.


No, in the real world you use Qt.


I --and I suspect many HNers-- appreciate the link to how this sort of stuff is handled in libxkb, and I'm upvoting you for it, but the troll was unnecessary.

Atom and Slack and VSCode and Wordpress.app and <insert electron app here> have virtues and flaws born from the platform and the tradeoffs it implies. Can we move on and discuss it without trolling?


I've worked in this area, and if I had to criticize gue5t's comment, it would be for understatement. The historic de facto ‘web standard’ defined by Netscape 4.0 is essentially raw Windows events, forcing every other platform/browser to provide a complicated and necessarily imperfect emulation of Windows keyboard handling.

UI Events <https://w3c.github.io/uievents/>, the new API mentioned in the article, is a huge improvement, but can't undo every past mistake.


I was not criticizing the bare facts exposed by gue5t (that web events are an imperfect API), I was criticizing the replacement of facts ("I think X is bad because Y, and working with it I learned it causes Z", like you do, thanks) in favor of dismissing the whole thing as "the dystopian future of 199x Netscape", which brings nothing apart being fertile ground for a flamewar.


Prefacing everything with 'I think', 'in my opinion', etc. is bad style. It weighs down the text. We already know that the writer's statements are what she thinks since she's the one making the statements.

I for one prefer concise flavorful texts over hemming-and-hawing.


Point taken; would remove the "I think" if I had to rewrite this.


Protip: suck it up instead of starting arguments when people make jokes at the expense of things you like. They weren't "dismissing the whole thing", they were making a joke. A pretty funny one at that.


However VS Code had somehow worked around it and had working keybindings for my german keyboard layout from the beginning (oder at least for the time I use it).

On Atom in contrast lots of stuff including basic things like line comment loggling did not work. I even recall situtations where typing the @ character did not work without and resulted in the execution of some random command.


I have frequently encountered the fallout from the problem the article mentions with the way that osx handles alt-character input.

Specifically with emacs style character manipulation modifiers -- alt-b and alt-f. In older versions of OS X -- I think pre snow leopard although I can't remember the exact version which first included the change -- the alt-b and alt-f characters were bound by default system wide (I think this mechanism is part of CoreText maybe?) to emacs style forward-word and backward-word. At some point OS X changed to turn all these alt-key combos into Unicode characters for the given keyboard language. This made the forward word and backward word behavior no longer available system wide at all text editing points.

OS X allows customizing the keyboard handling to invoke this operation (~/Library/KeyBindings/DefaultKeyBinding.dict). Meanwhile Applications (mainly those targeting programmers) layered on their own way to provide this familiar behavior within their own text editing context -- and Things break down in a variety of application specific ways. Workarounds to get back the closest thing to the old universal binding become irksome to find and maintain compatibility across applications ...

I'd really like to see apple add a new key to the keyboard specifically for system-wide implementation of operations that "invoke commands to manipulate text buffers/selection while editing text buffers" -- and perhaps include an extension point to allow new functionality to be defined for manipulating text buffers system wide. The mechanism for defining bindings from keyboard to action for this setup should be an abstract statement about the relative physical position of the modifier and target key -- so that the same muscle memory works (or approximates working in a way that preserves universal muscle memory) for all keyboard input languages.

A whole lot of text editor functionality is about muscle memory around character manipulation -- as a programmer I want a system-wide mechanism for allowing muscle memory to most efficiently enhance text manipulation in as many text editing contexts as possible ...

Solving the problem this way would create a single uniform-across-languages keybinding space for the most frequently used keyboard shortcuts. If this idea were implemented many of the most annoying problems with keybinding inconsistency across applications would eventually go away I think ...


Specifically with emacs style character manipulation modifiers -- alt-b and alt-f. In older versions of OS X -- I think pre snow leopard although I can't remember the exact version which first included the change -- the alt-b and alt-f characters were bound by default system wide (I think this mechanism is part of CoreText maybe?) to emacs style forward-word and backward-word. At some point OS X changed to turn all these alt-key combos into Unicode characters for the given keyboard language. This made the forward word and backward word behavior no longer available system wide at all text editing points.

I don’t believe that was ever the case. ⌥B and ⌥F were never bound to an Emacs-style forward-word and backward-word, even back in the pre-Leopard days (from what I remember). You may be confusing it with ⎈B and ⎈F (⌃B and ⌃F), which move backwards and forwards by one ‘character’, respectively, and still work even on the newest versions of macOS.

If you actually do want to move between words, then the keyboard shortcuts ⌥← and ⌥→ have always done that, and work across every app that uses Cocoa text fields.


It definitely was bound to that behavior in some version of OS X -- may have been even older, I think it changed around 2008 or 2009.

I used the binding all the time in mail and safari until the default binding changed. And it drove me so crazy to lose the capability that I had to figure out the (incomplete) workaround. The left and right arrow keystrokes also always worked however require moving hands from keyboard and are less efficient to intersperse with other key strokes.


I had no idea the situation was this bad. Many years ago I got used to apps (usually games, especially DOS) that assumed en-US layout regardless ('#' on shift-3 etc), but I thought this had gradually gone away.

I just gave Atom a quick test, and happened to choose a file with DOS line endings and a UCS-2 LE BOM. It duplicated the newlines and left the BOM in the document. Obviously not such a common case - everyone rightly hates UCS-2 - but Notepad++ gets this right.


What about Chinese, Japanese, Arabic and Hebrew?

Can definitely be handled /somehow/ with native code - but I'd bet it gets even more interesting then... you would need to decouple the map from assumptions about modifiers I think...


I was really surprised by the lack of support for internationalized keyboard layouts when I first tried to run atom under windows, it took quite some hassle to get going prior to this update...


Little anecdote time.

Once upon a time I was writing a little terminal-based text editor (fun experience), and wanted to handle some additional keys for editing capabilities:

  - Arrows Keyps (up, down, left, right)
  - Delete Key
  - Backspace Key
  - Page-Up/Down
I do not remember the other special keys, but the point is that events for these keys are provided to your terminal using escape sequences (just run $ infocmp). In particular I did not want to use curses, so I parsed the raw escape sequences to find out the keys pressed. This worked reasonably (if you are OK to only support a subset of terminals), but was incredible more complicated than I thought, as there are subtle differences between xterm, linux-console, urxvt, minix, etc.

Running a terminal under X, as I understand the path of key events (on Linux) is a little bit like that:

  0. User-Key-Press
  1. Some-Magic
  2. Keyboard-Interrupt
  3. Keyboard-Driver
  4. Linux-Input-System (see /usr/include/linux/input-event-codes.h)
  5. x11-event
  6. xterm-terminal-emulator
  7. escape-encoded event at e.g. /dev/pts/{n}.
The escape sequence events at the end are harder to parse than the intermediate Linux input events.

The funny thing is, that the Linux input system knows exactly what key you pressed and exposes a fantastic API (/usr/include/linux/input.h), but it is actually harder to find out reliable for user-space applications. E.g. I built some basic mouse support (for positioning) for the editor, and this use case is actually not supported; Although it is possible to activate mouse support in your terminal (this might be xterm specific), this does not work across terminals (and is limited AFAIK to 255 rows/cols).

So I built a prototype using /dev/input/{...} (it's part of the Linux input system) and it was a breeze and just worked. This is obviously system wide, requires root privileges and ignores your WM, but from a dev point of view it was absolutely the best system to work with (both for keys and for mouse). In the end I went back to parsing escape sequences (a text editor should be usable by non-root users obviously), but it was an interesting experience (the abstraction making the API worse).

/edit:

Although this was just for fun and more of a learning experience, I wondered what is the best way to handle mouse in a terminal, and sadly concluded that there just is no sane way across terminals (at least you want to support xterm, urxvt, st and linux), as far as I understand. If somebody knows how to solve this issue (mouse-support across the mentioned terminals), I would be glad to hear or know what has to be done. In a perfect world I would like to have /dev/input local to my window - that sounds like a sane ... plan?




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: