@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 '…'

@demiguru

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.

@Zenie @weavejester

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