I've also seen (elsewhere) "inspired by emacs ... it has emacs keybindings".
One of the advantages of emacs is that an insane level of customisation is possible. Or, more practically, the high level of customisation allows for a lot of low-hanging fruit for people to create editor macros that suit their usage.
> "inspired by emacs ... it has emacs keybindings"
Lol, incidentally macOS native text fields / text views support a bunch of Emacs keybindings out of box (C-f, C-b, C-n, C-p, C-a, C-e, C-k, C-d off the top of my mind), so any native Mac application with any text input can claim “inspired by Emacs” for free.
I recently showed an OSX based colleague some bash key bindings. He was amazed that I knew these, even more when I replied emacs has the very same key bindings.
Exactly. You can even add some more on your own. Just add the file ~/Library/KeyBindings/DefaultKeyBinding.dict and fill in. I added M-f and M-b but you can add more to make the experience even more Emacs-like.
that's likely a side-effect of emacs bindings being the readline default in Bash more than anything. (set -o emacs)
What will be interesting to see is if this changes now that zsh (which does not use readline) has become the standard...but alas, if you don't have EDITOR or VISUAL set, emacs is the default there too...
As for those curious, emacs is the readline default because readline is part of the GNU project.
What are you talking about? I’m talking about Cocoa NSTextField, NSTextView etc., got nothing to with libreadline or bash, unless there’s a history lesson here you’d like to share.
Edit: Your comment was expanded as I was replying / after I replied. From which it’s quite clear you didn’t get my point.
Oh I get it, I think you're just underestimating how much effort Apple's developers put into system-wide consistent behaviors in macOS. And also how picky developers are about keyboard first and changing keybindings.
They decided to use emacs bindings because emacs bindings are the system default for macOS programmers.
Apple's developers were also macOS's first users and they started with a terminal long before they had a working UI.
Reread your comment. I misunderstood the first time round. You presented a theory that Apple implemented Emacs keybindings for Cocoa text input widgets not because of Emacs per se, but rather, mainly for consistency with bash. It's an interesting theory, but without a history lesson backed up by sources it's still a theory.
For the record I don't underestimate how much effort Apple puts into system-wide consistent behaviors in macOS. <s>Also, zsh's default keybinding mode is Emacs mode.</s> (Of course, you did mention that.)
Technically, that was systemwide inconsistent behavior.
Readline compatible keystrokes came from nextstep (sorry, I don’t dare to guess how to capitalize that). Traditional Mac OS used completely different key combinations (command left arrow instead of control-a, for example). Because of that, Carbon apps didn’t support readline-like key combinations (but system input fields did)
The two could happily coexist only because the Mac originally didn’t have control keys (it only got them for supporting terminal programs, as part of trying to make Macs sell better in business), so none of its navigation keystrokes used the control key.
One of the advantages of emacs is that an insane level of customisation is possible. Or, more practically, the high level of customisation allows for a lot of low-hanging fruit for people to create editor macros that suit their usage.