@demiguru

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.

#GNUEmacs #Emacs

@weavejester

@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.

@demiguru

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

@Zenie @weavejester

@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.

@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.

@restorante @Zenie @weavejester

@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?