Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> macos leans so heavily on readline input

The ubiquity of readline is a bit of a myth. What happened was that Bash (thus Readline) and NeXT (thus MacOS) independently copied Emacs keybindings, where Emacs predates both. But the Mac GUI doesn’t use the Readline library, and differ in some points (e.g. M-f works in Readline but not MacOS). Moreover, it seems a lot of people think Readline is used everywhere in the CLI, but many popular interpreters use other libraries. For instance, Bash uses Readline but Zsh and Fish uses their own things. Python has used Readline up until now, but is moving away in 3.13. IPython switched from Readline to prompt_toolkit many years ago. Readline was also not the first shell to adopt Emacs keybindings, it was preceded by Ksh IIRC.

I have nothing against Readline, and I understand where you’re coming from since this is often repeated online for some reason. I just want to point out that it’s actually emacs keybindings and not readline keybindings that is the correct term here :)



I called them readline bindings because more people are familiar with readline than emacs. Furthermore macos certainly doesn't take enough of emacs outside of readline bindings to make me comfortable referring to them as emacs bindings.

I hadn't even noticed that zsh and fish used something other than readline. To me, they effectively are using readline as that's the name for the functionality that's fulfilled.

I don't really give a damn what they're called or why they exist, so I'll happily call them emacs bindings if that makes more sense to you.


> Furthermore macos certainly doesn't take enough of emacs outside of readline bindings to make me comfortable referring to them as emacs bindings.

That’s fair. But on the other hand they also don’t implement any of the Readline keybindings that are not in Emacs, like for example C-w and C-u to delete the last word and line, respectively.

> I hadn't even noticed that zsh and fish used something other than readline. To me, they effectively are using readline as that's the name for the functionality that's fulfilled.

IMO, that’s like calling Vim and Emacs for “TextEdit” because that’s what they do. I see the argument, but it is confusing.

Readline is one particular library, and it is relevant to many users like me whether it’s used or not. Many alternatives (as used by Fish and IPython for example) have better support for modern features like multi-line editing and syntax highlighting. Conversely, if MacOS actually used libreadline, I should have been able to enable Vi mode in .inputrc and get Vi keybindings in every MacOS text field, which I think many Mac users would want. But alas, MacOS ignores .inputrc, although there is a somewhat equivalent DefaultKeyBinding.dict. If you customize your .inputrc it also quickly becomes apparent that Fish and Zsh for example ignore your Readline settings.


> I just want to point out that it’s actually emacs keybindings and not readline keybindings that is the correct term here :)

Not least, because Readline also supports Vi keybindings (`set editing-mode vi` in `.inputrc`), it just defaults to Emacs keybindings (equivalent to `set editing-mode emacs`).


Sure but nobody's going to refer to the non-default bindings as "readline" bindings. Meanwhile cli prompts are where most users are exposed to emacs bindings.




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

Search: