I've used Spacemacs for some years now as my primary editor, but recently I've been looking into #neovim.
It starts up a lot quicker, even with a bunch of plugins, and surprisingly for a terminal editor it has a more sophisticated UI than windowed Emacs.
I understand that emacs is designed to be invoked and then one will live in it until the end of his session. While vi is designed to be invoked as needed.
But on today's computer, emacs usually is also super fast, whether their invocation, opening files or when processing something.
I understand that emacs is not following Unix philosophy at all.
But in a sense, emacs is nothing but elisp interpreter with some addition to aid text editing.
All of those elisp packages are not emacs. They are just elisp packages, running on emacs. And those elisp packages usually are highly specialized tools.
I understand composability means each tools can be combined to build a more complex solution, such as through piping and redirection.
In a sense, elisp packages are just functions. We can use them in our own elisp code. But I know, it is different with the Unix composability.
@restorante @demiguru @weavejester
Vi isn't composable either. Sed and Ed and awk are composable.
That argument is out of context when talking about things with user interfaces.
I would say that emacs is ultimately more composable than vi, vim, or neovim. Emacs can integrate easily with other systems and tools.
That's the thing that it does amazingly well. Just because it's a super power doesn't mean that it's not within the philosophy.
The extensibility of #Emacs through integration with other tools is off the charts. That to me is completely within the Unix philosophy. I've been a Unix dev for 45 years. I think I know.
@Zenie @restorante @weavejester Vi (and later vim/neovim) may not fit that classical mold perfectly, but they do adhere to it in a limited way:
They operate directly on plain text files (not opaque binary state).
They can be scripted through ex commands.
They can be invoked non-interactively to perform transformations (vi -es).
That’s composability in the Unix sense: predictable input/output behavior and scriptable interfaces.
@Zenie @restorante @weavejester That’s philosophically different.
Vim is composable in the Unix tradition because it’s file-centric, scriptable, and plays in pipelines.
Emacs is extensible and integrative, but its model of absorbing everything into itself arguably violates the spirit of “do one thing well.”
In other words, if we’re being strict about Unix philosophy, Emacs is powerful, but it’s less “composable” than vim—it’s more of an operating system in itself.
I am not an expert of elisp. But may be you are interested to:
https://www.gnu.org/software/emacs/manual/html_node/emacs/Command-Example.html
echo "Hello World" | emacs --batch --eval '(progn (insert (read-from-minibuffer "Input: ")) (write-region (point-min) (point-max) "output.txt"))'
I just simply copy paste the code above
@restorante @Zenie @weavejester
What you’ve shown is Emacs scripting, which is fine, but it’s internal extensibility — you’re writing Emacs Lisp that runs inside Emacs. That’s not the same as taking existing Unix tools and composing them through standard input/output.
In your example: echo "Hello World" | emacs --batch --eval '…'
@restorante @Zenie @weavejester
Notice that echo isn’t actually feeding data through stdin to Emacs in a composable pipeline — instead Emacs is prompting and inserting via Elisp. Compare that to: echo "Hello World" | sed 's/World/Unix/'
@restorante @Zenie @weavejester echo "Hello World" | awk '{ print toupper($0) }'
Here, the tools are directly transforming streams, no custom scripting language needed.
Well, perhaps emacs is exactly a tool to run elisp code. May be, when we use Org Mode, we do not really use emacs, but Org Mode. It is Org Mode that using emacs.
That is one of the reason I wrote emacs is different with the Unix philosophy.
@restorante @Zenie @weavejester
I get it — Emacs is a Lisp machine and modes like Org build on top of that. That’s exactly why it sits outside the Unix philosophy.
Unix composability is about chaining small tools with stdin/out. Emacs is extensibility through Elisp. Both are powerful, but by your own framing, Emacs isn’t Unix-composable — it’s a different philosophy altogether.
Yes, indeed Unix philosophy and Lisp are two different ways of life.
Ability to edit the code of the programs we are using and then reload it. Or having the whole systems as a gigantic set of Lisp libraries which we can use it in our own Lisp code.
Yes, these way of life is vastly different with Unix philosophy.
@restorante There is no such thing as "Unix philosophy".
Yes, I agree totally that GNU is all about freedom. It is a social movement, just happening in the field of software.
I think, discussing GNU Emacs as a piece of free software (libre software) or as a lisp programming environment or as an editing system is okay and fruitful.
GNU Emacs is such a wonderful and magnificent piece of software afterall.
@demiguru Emacs is an editor. GNU Emacs is a "Lisp Machine".
People make this mistake to confuse Emacs the Editor and GNU Emacs which implements a version of Emacs, plus lots more things.
@demiguru In Emacs the composability is done from the Lisp side, where you "chain together seamlessly objects".
At the end of the day Emacs is just an editor like vi, vi is not composable, neither is ed. The difference is that Emacs and other parts of the system can share code -- on Unix this is impossible (vi cannot share the implementation of g/RE/p with e.g grep -- in Lisp you can).
@demiguru @restorante @Zenie @weavejester no custom scripting language but the shell, which can be tcsh, sh, ksh, bash, fish, zsh, or scsh…
The differentiator is the process boundary between the components, and text stream as the only interchange data true. Emacs also uses sub-processes and their stdin/out like a shell would. One could argue it’s a shell with a better language and data types then the previously mentioned shells, and buffer abstraction to handle the text in and out of a process
I think your being a bit flippant in calling structured composition of data and functions a mimicry of composition.
I enjoy vi, helix, emacs and all those shells with the exception of t/csh — which is for people of no account anyways.
@craigbro @restorante @Zenie @weavejester
#Emacs can spawn subprocesses, sure — but most of its “composition” happens inside the Lisp runtime.
#Unix composability is black-box tools chaining via text streams across process boundaries. Emacs is powerful, just a different model of composition.
@demiguru @restorante @Zenie @weavejester
echo "Hello World" | emacs --batch --eval '(progn (insert (read-from-minibuffer "")) (princ (string-replace "World" "Unix" (buffer-string))))'
This does the same as 's/World/Unix/' in sed and prints it again to standard output. It's not that #emacs is not composable like that, but that it's usually used interactively (because that's more fun).
@eruwero
I get that view — #Emacs can feel like a universal interface to the system, and its #Lisp functions are composable in their own right.
Where I see the #Unix philosophy diverge is in the boundary: tools designed as separate executables, with contracts enforced by the #OS, versus composition inside a single runtime. Both routes achieve interoperability, but one leans on external guarantees, the other on internal extensibility.
@demiguru @restorante @Zenie @weavejester ok I get your point. I still prefer the lisp machine/emacs approach were there are as few arbitrary boundaries as possible and everything can be modified dynamically, but that's a philosophical issue :)
What I still don't get is how vi/vim/neovim better fits into this unix model because you use it in a similar way as emacs, you usually don't use it in some pipeline in the shell, even if you could do that. So AFAIU they are equivalent wrt that
You’re right — pure #Unix minimalism couldn’t survive once systems became interactive and persistent. Early Unix assumed short-lived processes and text as shared state.
Once #editors became programmable and long-running, that boundary blurred. #Vi/#Neovim kept the file-centric DNA; #Emacs internalized it. Both descend from Unix, just different branches of its evolution.
Thank you saying this so well.
I think it just my experience. I was a vi user many years before the vimulator came along. I didn't like the key-bindings for buffers and the developer wasn't nice. I stuck with my ways in vi until 95.
I switched to emacs but used viper the vi emulator in emacs. Emacs buffers and keymaps are amazing compared to vim. Eventually I kept a reasonably configured vim around. But I'd never use it for more than a quick look at something. 2011 I used vim for a year, for work. It was very lacking despite a ton of vim script. Which is awful. I switched back to emacs with evil.
Recently I've realized I don't like evil is it's goal to emulate vim.
@jamie
So really it comes down to my view that #Vim is emulating #Vi, and so is #Emacs.
If you then look at the infrastructure around that,
Emacs is much more capable and less limiting in what you can do. That everything is a buffer means that it's buffer management is amazing.
The modes and key-bindings are awesome and it's all
pleasantly programmable in lisp.
Vi is a great editor, but there isn't much to it. It's a lightweight editor that works well. I think people confuse what is emulating Vi versus what is the application surrounding the emulator.
Emacs has, Evil, Viper, Meow, Boon and Meep modal editors. That says something too.
@jamie quoted:
> «Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features."»
Hmmm... how does this apply to the GNU Compiler Collection?
Briefly:
Firstly, "GNU's Not UNIX" comes from a very different context.
Secondly, the meaning of "not UNIX¹" is in the GPL sense, not in the engineering sense.
_________
¹ What was UNIX at the time and whose intellectual property was it?
My point is:
One context is Stallman's drive (at the time):
Free Software, FSF, GPL, etc.
In other words, my view is that "GNU's Not UNIX" came out
first and foremost as a political slogan,
rather than an engineering one.
(Don't take my word for this, of course;
there are enough primary sources from those days.)
Another very different context is that of
"make it small to do one thing well", an engineering principle,
and in this context I gave GCC as a (counter)example.
@vnikolov
FWIW the GNU manifesto is available here:
https://www.gnu.org/gnu/manifesto.html.en
In particular:
"Why GNU Will Be Compatible with Unix
Unix is not my ideal system, but it is not too bad. The essential features of Unix seem to be good ones, and I think I can fill in what Unix lacks without spoiling them. And a system compatible with Unix would be convenient for many other people to adopt."
Yes, as [email protected] pointed out in the end of one of the earlier posts in this thread (perhaps a sibling branch).
Yes.
A well-known example from that time
is the ability to continue ("restart") a failing system call
under ITS:
impressive, but a _lot_ of work to implement.
If I recall correctly, Gabriel's "Worse Is Better" is one of the sources that give some detail.
@vnikolov If you every looked at GCC you'd realise that it is a lot of small programs specialised for one thing sharing a library/framework for doing what is shared between them.
@jamie wrote:
> a listing is about printing source code? ... information about the compilation process
Right.
A listing has line numbers and shows compiler input.
(Punch cards can be loaded in the wrong order...)
It also lists all symbols and their locations for reading dumps.
> Stallman has always been pretty clear that he's never been a big fan of Unix.
Not just Stallman.
Perhaps the best single paper about this view at MIT at the time is Gabriel's "Worse Is Better" (as is usually called).
@jamie wrote:
> unix purists have always complained about GNU tools being too big and complex and too many options?
Not just purists and not just about GNU tools.
This Bell Labs (kt? dmr?) quote comes to mind:
"cat came back from Berkeley waving flags".
P.S.
Notice of Correction:
That quote is attributed to Rob Pike.
I don't know if I should mention him with the at-sign here.
P.P.S.
Forgot to mention _The UNIX-HATERS Handbook_,
an important historical document, whether you are for or against.
That is certainly a good way of looking at this matter.
Do those people consider compilation as a whole to be opaque,
or just the optimization part of it?
(I don't know: I haven't come across such texts.)
And now for a different area—the above made me wonder in which of those three categories mathematics falls:
"Mathematics is a science of simple things,
arranged appropriately."
(I do regret that I don't know who said this.)
Weavejester
Zach 🇮🇱 🇺🇸
restorante
Zenie
Alfred M. Szmidt
superketchup 
Craig Brozefsky
eruwero
lispm
Jamie in Cuckooland
Crandel 🇺🇦 
Dave Spector
Vassil Nikolov | Васил Николов
Panicz Maciej Godek