Everything becomes better with fzf. I use it to parse git logs, checkout branches, select and download files from s3... Fzf is the single tool that vastly improved my command line productivity.
As an alternative, the fish shell has been a huge boon to my productivity. The drawbacks are that some shell syntax you’ve become familiar with from bash, won’t work.
fish has the best command line input experience from any program I've used, by far. I wish there were something like rlwrap that could give a powerful fish-like prompt to any interactive program out there.
tread carefully in combination with other software. Trying to install opam for Ocaml completely broke my fish shell config, the bug seems to remain unfixed for two years now.
I put "set editing-mode vi" in my ~/.inputrc to enable basic vi keyboard shortcuts in readline-based programs like bash.
If I'm using bash on a machine I don't control, I can type "set -o vi" at the bash prompt to get the same thing temporarily, and that's usually the first thing I type.
I also like to use rlwrap[1] to get readline editing and command history on terminal apps that aren't readline aware and don't have history of their own.
Most of the time, though I spend in zsh, which is not readline-based but has its own readline-like capabilities. There I have ^R bound to reverse history search, and ^E to edit the current line in my $EDITOR.
In addition to this, I use fzy[2] (which I prefer over fzf[3]) to do fuzzy searches over my shell history with something like:
Heh, I tend to go all in and run shells in Emacs :)
There are (at least) 3 ways to do this:
- `term` and `ansi-term` act as terminal emulators; they run a normal shell, like bash, and act much like e.g. `xterm`. You can even use curses-based programs. I don't use this as I find it quite clunky, since normal Emacs navigation and editing doesn't work (since the key combos would conflict with those used by the shell and applications).
- `eshell` is the opposite extreme: it's a shell which you use instead of bash and friends. It has nice features like piping to a buffer, running Elisp (if that's what you're into) and (my favourite) using TRAMP to invoke SSH and sudo. I tend not to use it much other than for TRAMP. The most obvious problem is the limited support for piping.
- `shell` is half way between. It runs a normal shell like bash, but Emacs keeps control over the buffer. This means we can't use things like curses, but we can navigate and edit the buffer contents just like any other.
Emacs `shell` is my "default" terminal; I currently have 24 shell buffers open. For things like curses, I use a separate `st` window running DVTM.
As a bonus, we can actually use `shell` and TRAMP together: we first use TRAMP to connect somewhere, e.g. `/ssh:me@remote:/home/me` (we can do this using `cd` in `eshell`, or using `dired` mode, or whatever), then from there we invoke `shell`. We'll be dropped into a remote shell, just as if we'd run `ssh`, but Emacs will be able to do things like tab-completion for the remote system.
Also when you just want to run a single command, `M-&` (`async-shell-command`) is always handy. Or in Dired mode `&` for operating on files. At least for me those two work for majority of shell usage.
I mostly use `M-x shell`. One of the best features (other than the standard features of Emacs buffers) is `C-c C-p` and `C-c C-n` to jump to the previous/next prompt.
On that last bit, it's possible to have org links point to tramp URLs, so in my start.org file (my initial buffer, an entrance to my world :)) I keep some links to remotes I frequent, and with ssh agent running, it's one clock to connect. Also it's useful to be able to just link a related remote directory in my notes.
GNU Readline definitely makes it faster to work on the command line. I find it a real frustration I log into a system that is only running Busybox, which lacks all the Readline goodness, and I can’t use Alt-F to move forward word by word.
for those that don't know it, rlwrap[0] is a neat tool that allows you to use a lot of the readline goodness with tools that don't support it natively (e.g. a repl for your newly written language).
>”The direct result of this is that we now have an Objective C front
end. They had wanted to distribute the Objective C parser as a
separate proprietary package to link with the GCC back end, but since
I didn't agree this was allowed, they made it free.”
The direct result of this is half-a-trillion dollar company that wrote its own toolchain from scratch and released it to the public for free, giving birth to thousands of modern language projects, while GNU Objective-C is still a dead crap with no demand.
My favorite unsung readline default is ctrl-o, for "operate-and-get-next”. If you’ve gone back and found a command from your history, ctrl-o will run it and then tee up the next command. And, if you hit the end of your history, it will cycle back to the point you initially searched to. So if you have a set of a few commands (e.g., foreground your editor, run make, test the results) that you tend to keep repeating, it will replace “up up up enter” with just “ctrl-o”.
Once a year or so I read one of these articles and figure out how much time I can save (like this Ctrl-O). But I rarely do, I think I need to print out the cheatlist and put it on the wall behind my monitor so I can use them enough to get them into my patterns.
I will start writing a command, decide I’m not ready for it, CTRL-u to kill it and store it in the clipboard, run another command, and CTRL-a to put back the command I just deleted.
That should read CTRL-y to put back the command I just deleted.
CTRL-k: kill the line after the cursor, add to clipboard
CTRL-u: kill the line before the cursor, add to clipboard
The more emacsian way of saying that you removed a line segment from a buffer and put it on the clip-board is to say that you yank the line rather than you kill the line.
Now I'm just confused. I thought that C-k stood for kill, and C-y stood for yank. So you kill the text, which... puts it into the dead buffer? And then yank it from the dead buffer? I've never really understood this.
Most of those emacs shortcuts work in Cocoa text fields, including TextEdit, your location bar, file dialogs, etc... Some, like ^W, are missing though, but, likewise to .inputrc, they can be added back via:
~/Library/KeyBindings/DefaultKeyBinding.dict
Some people went overboard[0] with it, but hey, whatever floats your boat. At least it makes for some kind of example/demo/documentation for the thing.
As an aside, personal opinion: the separation of Control and Command on macOS is the one thing I love as it makes for a very consistent interface whether I'm in a terminal or in an application.
> the separation of Control and Command on macOS is the one thing I love
I became a reluctant Mac user (work gave me a Mac laptop).
Being able to use ^D, ^N and so on in this text edit box is very useful, especially on a laptop keyboard, and it's something I miss back in KDE. Does anyone know a way to bring the same feature to KDE, Firefox etc?
Last time I tried it was in the KDE 3 days and there were mappings that you could set up but it required so much tedious work, often per app.
the end result was terrible and inconsistent.
I’ve also explored the Ctrl/Cmd separation in GNOME/GTK3 but it’s deep into the code, guess what there’s actually a constant or two dedicated for that and it could magically work but they’re entirely unavailabe to configuration, probably pertain to some build time thing for macOS, gated by auto #define’d per platform values. Turns out nobody cares and it requires quite an involvement to get into the thing, build a proper patch, submit it, have it reviewed and accepted.
In the end I stuck for a while in tiled WM land (awesome, i3) with deft configuration, and minimal desktop apps that wouldn’t require such shortcuts, but you always end up needing a browser or something and things become leaky and inconsistent again. So I moved back to macOS.
Already discussed on HN: GNU readline, BSD editline, rlwrap and linenoise. I suspect enhance and libtecla have been discussed too (alternatives to rlwrap and readline).
Both editline and readline are large, too large to be compiled into every program that could benefit from REPL.
The answer to the bloat is linenoise. Great project.
But then there are all the programs that already have the readline bloat compiled in. How to replace it with something smaller? Can this be done?
There is another editline, not NetBSD's editline. It may predate the web, as it was originally distributed via Usenet. I do not recall it ever being discussed on HN. I suspect the original author probably has an HN account.
From Github:
*call compatible with GNU readline*
small size (<30K)
originally developed for older UNIX and Plan 9
forked from Minix 3, not related to NetBSD editline
does not rely on libtermcap/curses
38 comments
[ 647 ms ] story [ 2735 ms ] threadhttps://github.com/junegunn/fzf
http://owen.cymru/fzf-ripgrep-navigate-with-bash-faster-than...
https://github.com/ocaml/opam/issues/2255
This is one of the reasons I'm reluctant to use fish again, these edge cases just aren't tolerable for everyday work.
If I'm using bash on a machine I don't control, I can type "set -o vi" at the bash prompt to get the same thing temporarily, and that's usually the first thing I type.
I also like to use rlwrap[1] to get readline editing and command history on terminal apps that aren't readline aware and don't have history of their own.
Most of the time, though I spend in zsh, which is not readline-based but has its own readline-like capabilities. There I have ^R bound to reverse history search, and ^E to edit the current line in my $EDITOR.
In addition to this, I use fzy[2] (which I prefer over fzf[3]) to do fuzzy searches over my shell history with something like:
[1] - http://utopia.knoware.nl/~hlub/uck/rlwrap/[2] - https://github.com/jhawthorn/fzy/
[3] - https://github.com/junegunn/fzf
There are (at least) 3 ways to do this:
- `term` and `ansi-term` act as terminal emulators; they run a normal shell, like bash, and act much like e.g. `xterm`. You can even use curses-based programs. I don't use this as I find it quite clunky, since normal Emacs navigation and editing doesn't work (since the key combos would conflict with those used by the shell and applications).
- `eshell` is the opposite extreme: it's a shell which you use instead of bash and friends. It has nice features like piping to a buffer, running Elisp (if that's what you're into) and (my favourite) using TRAMP to invoke SSH and sudo. I tend not to use it much other than for TRAMP. The most obvious problem is the limited support for piping.
- `shell` is half way between. It runs a normal shell like bash, but Emacs keeps control over the buffer. This means we can't use things like curses, but we can navigate and edit the buffer contents just like any other.
Emacs `shell` is my "default" terminal; I currently have 24 shell buffers open. For things like curses, I use a separate `st` window running DVTM.
As a bonus, we can actually use `shell` and TRAMP together: we first use TRAMP to connect somewhere, e.g. `/ssh:me@remote:/home/me` (we can do this using `cd` in `eshell`, or using `dired` mode, or whatever), then from there we invoke `shell`. We'll be dropped into a remote shell, just as if we'd run `ssh`, but Emacs will be able to do things like tab-completion for the remote system.
[0] https://github.com/hanslub42/rlwrap
http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-...
The direct result of this is half-a-trillion dollar company that wrote its own toolchain from scratch and released it to the public for free, giving birth to thousands of modern language projects, while GNU Objective-C is still a dead crap with no demand.
1. (intransitive) To bend the knee, as in servitude or worship
2. (intransitive, figuratively) To behave in a servile manner; to grovel.
Source: https://en.wiktionary.org/wiki/genuflect
That should read CTRL-y to put back the command I just deleted.
The more emacsian way of saying that you removed a line segment from a buffer and put it on the clip-board is to say that you yank the line rather than you kill the line.
C-K runs the command kill-visual-line..."
C-Y says:
C-y runs the command yank...
As an aside, personal opinion: the separation of Control and Command on macOS is the one thing I love as it makes for a very consistent interface whether I'm in a terminal or in an application.
[0]: https://github.com/ttscoff/KeyBindings
I became a reluctant Mac user (work gave me a Mac laptop).
Being able to use ^D, ^N and so on in this text edit box is very useful, especially on a laptop keyboard, and it's something I miss back in KDE. Does anyone know a way to bring the same feature to KDE, Firefox etc?
I’ve also explored the Ctrl/Cmd separation in GNOME/GTK3 but it’s deep into the code, guess what there’s actually a constant or two dedicated for that and it could magically work but they’re entirely unavailabe to configuration, probably pertain to some build time thing for macOS, gated by auto #define’d per platform values. Turns out nobody cares and it requires quite an involvement to get into the thing, build a proper patch, submit it, have it reviewed and accepted.
In the end I stuck for a while in tiled WM land (awesome, i3) with deft configuration, and minimal desktop apps that wouldn’t require such shortcuts, but you always end up needing a browser or something and things become leaky and inconsistent again. So I moved back to macOS.
One of the first things I install on Windows.
* https://jpsoft.com/
> Hello, the first line of my .inputrc is: > # this file can be reloaded by bash using shortcut C-x C-r
So practical!
For example: https://news.ycombinator.com/item?id=5086837
Both editline and readline are large, too large to be compiled into every program that could benefit from REPL.
The answer to the bloat is linenoise. Great project.
But then there are all the programs that already have the readline bloat compiled in. How to replace it with something smaller? Can this be done?
There is another editline, not NetBSD's editline. It may predate the web, as it was originally distributed via Usenet. I do not recall it ever being discussed on HN. I suspect the original author probably has an HN account.
From Github:
source: https://github.com/troglobit/editlinesocat can function as a replacement for rlwrap, something like:
where "q" is a program that could benefit from a REPL.Perceptually I find socat readline exits faster than rlwrap. The later always feels a bit sluggish. Same for libtecla's enhance.
Is there a linenoise-based replacement for rlwrap?