
The Wonderful World of Keyboards - okket
http://blog.atom.io/2016/10/17/the-wonderful-world-of-keyboards.html
======
gue5t
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](http://xkbcommon.org/doc/current/md_doc_quick-guide.html)

~~~
gedy
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.

~~~
kps
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.)

~~~
gedy
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.

~~~
zeveb
> 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.

------
breatheoften
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 ...

~~~
arm
“ _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.

~~~
breatheoften
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.

------
pjc50
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.

------
jheriko
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...

------
EJTH
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...

------
protomikron
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?

