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
@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?
The code example above is intended to be run on a shell. It invokes echo and pipe the output to emacs.
Emacs processes the input (echo's output) and creates the output.txt.
Option -batch means using emacs non interactively while option -eval is to evaluates elisp code.
Again, I am just a casual user. I am not in any way an elisp expert. Please correct me if I am wrong.
@restorante @Zenie @weavejester
sed and awk take stdin → stdout, so they compose cleanly in pipelines.
Your Emacs example isn’t really doing that — your code runs Elisp that prompts for input and writes to a file. That shows your extensibility, not your composability.
Composability is about external contracts (stdin/out), not embedding everything into your Lisp runtime.
Ah yes you are right. There us (read-from-minibuffer "input: ") which means waiting for input from minibuffer.
Sorry, I didn't really read and run the code. I just copied and pasted it from the Internet.
@crandel @restorante @Zenie @weavejester sed and awk are Unix tools first — they compose through stdin/out, and their scripting just extends that model.
#Elisp only runs inside #Emacs, which makes it extensibility inside a runtime, not Unix-style composability. #Vim is more limited, but #Neovim adds real extensibility while still keeping to the file-centric #Unix model.
@crandel @restorante @Zenie @weavejester
#Vim may not have been part of early #Unix, but it does embody a Unix-like approach: file-centric, scriptable, and able to operate in pipelines (vi -es). That aligns with composability more than #Emacs’s “Lisp machine” model.
@demiguru @crandel @restorante @Zenie @weavejester Ah, you’re right. Ed clearly is a foreign tool to the true unix philosophy.
It wasn’t until the mid seventies that sed finally allowed dmr and ken to learn what it meant to be Unix, huh? Except shoot, that wasn’t from either of them. Nor were pipes in shells until after the last Thompson shell. I guess neither of them really understood Unix at all.
@demiguru @crandel @restorante @Zenie @weavejester Really, the true origin of the unix philosophy was obviously TECO on Multics, https://web.archive.org/web/20000819071104/http%3A//www.multicians.org/mepap.html
What had more powerfully files than Multics or more composability than TECO?
@josephholsten @crandel @restorante @Zenie @weavejester
If TECO on Multics was the origin, then Unix philosophy was mostly about running the other way.
GNU - Gnus not unix.
Weavejester
Zach 🇮🇱 🇺🇸
restorante
Zenie
Alfred M. Szmidt
superketchup 
Craig Brozefsky
eruwero
lispm
Jamie in Cuckooland
Crandel 🇺🇦 
Dave Spector
Vassil Nikolov | Васил Николов
Panicz Maciej Godek
: j@fabrica:~/src; 
Andrew Wigglesworth