4 ms·
The funny thing is that I put vi more in the "UNIX Philosophy" camp. Specifically, as a user of vi, especially with normal vi (vs vim), a routine workflow for
by whartung 4y ago
The funny thing is that I put vi more in the "UNIX Philosophy" camp.
Specifically, as a user of vi, especially with normal vi (vs vim), a routine workflow for me is !command some block of text, or the entire file to some utility or another.
And the idea here is that with little effort, the entirety of the UNIX environment (at least the CLI tools environment) is at my beck and call. I've munged gobs of text through most any utility imaginable. I've use vi as an interactive pipeline. Running data through one sequence, then running it through another, or a 3rd. It's like an interactive pipeline debugger with undo.
It's not that emacs can not do it, of course it can. You can run a region through a shell command as easily as anything.
But, folks don't. Rather they rely on the extensive, emacs universe to solve those problems. There's lisp for that. Like the Java and JavaScript eco-systems, where "everything" gets rewritten into that world, the drive has been to port the essential utilities into the whole of emacs, rather than having it work with the system surrounding it. There's all sorts of good reasons for this, but at the same time, all of those routines and such are cut off from "unix". While its straightforward to leverage grep, sort, awk, et al from within emacs, it's less so the other way around. I'm sure it's possible, but it's not trivial.
In a world of composite solution development, a monolith stands out because it acts more as an unscalable tower rather than a thing to touch for enlightenment.
- anthk 4y agonvi, entr, xargs, awk, sed, perl...
- gw98 4y agoCompletely agree with this. Unix is centred around composing lots of individual tools that do one job well. Emacs is the antithesis of this. It's closer to Visual Studio. Honestly in the 30 years I've been using Unixes I have never needed anything but vi/vim with a few lines of configuration, mostly to satisfy some of the newer fussier language indent requirements (yaml, python). Most of the non trivial data processing is done with external tools (sed, grep, awk etc) where the knowledge and power is reusable for other tasks external to editing things! Only on Windows have I had to leverage anything more complicated.
- agumonkey 4y agoI think there's strange rotation. Emacs being based on lisp is all about composing lots of individual bits. Unix too.
- gw98 4y agoIndeed. But it's a nested abstraction.
- ParetoOptimal 4y ago> Unix is centred around composing lots of individual tools that do one job well. Emacs is the antithesis of this. It's closer to Visual Studio. Only if you consider emacs as a tool rather than a tool-maker.
- pjmlp 4y agoEmacs is a Lisp machine with a text editor as sample application.
- __d 4y agoI think it's a common misconception that Emacs is not a collection of simple tools. There are two major differences: Emacs' "shell" is the ELisp interpreter, not (eg) bash; and, Unix uses the whitespace-separated text stream as its common language, and Emacs uses the text buffer. There are analogous tools in both environments, although in Emacs, most of the "little language"-driven tools use ELisp instead, giving simpler cooperation. There's a lot of truth in the "Unix is just a device driver collection for Emacs" model though: there's little need for most of the Unix toolset if you're adept at Emacs. I think there's a much more interesting discussion to be had in comparing the relative merits of text streams (Unix) vs text buffers (Emacs) as a unifying abstraction for a suite of programmer's tools.
- gw98 4y agoI'm well aware of how Emacs works. mg probaly fits better. It's just an editor. One small component.
- BlueTemplar 4y agoWhy vi vs vim ? (I have no experience with vi, only vim.)
- jrumbut 4y agoIn vim there are a lot of emacs-like plug-ins that reimplement functionality found elsewhere. You can still use the vi style workflow though.
- shagie 4y agovim is the improved version of vi, which is the visual interface to ex, which is the extended editor ed... the one true editor ( https://www.gnu.org/fun/jokes/ed-msg.txt https://www.gnu.org/fun/jokes/ed-msg.txt ) You will not infrequently find vim and vi links to the same executable. /usr/bin % ls -l ex vi vim lrwxr-xr-x 1 root wheel 3 Aug 24 03:59 ex -> vim lrwxr-xr-x 1 root wheel 3 Aug 24 03:59 vi -> vim -rwxr-xr-x 1 root wheel 5155568 Aug 24 03:59 vim The difference between which way you have argv[0] slightly changes the functionality... but it's the same thing. ed remains its own thing. /bin % ls -l ed -rwxr-xr-x 1 root wheel 235296 Aug 24 03:59 ed THE MIGHTY ED HAS SPOKEN!!! ?
- mrlemke 4y agoTo expand on shagie's answer, vi is a separate utility except when it's not (f.g. Linux vi is usually a minimal vim build running in vi-compatible mode). For a more pure taste of vi, install nvi or use vi on *BSD.
- jrumbut 4y agoExactly, because of bad habits developed elsewhere I sometimes find myself puzzling (as an example) "how do I remove HTML tags in vim?" rather than "how do I remove HTML tags? OK, now do that in vim."