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

@crandel @alerque @restorante @Zenie @weavejester

Extensibility and composability aren’t the same axis. #Emacs wins on extensibility — you can rewire its internals in #Elisp, no question.

But #Unix composability was never about replacing internals; it was about chaining small tools over simple contracts. #Vim/#Neovim fit that model more closely, even if they’re less malleable inside.

@demiguru

As far as I know, in Lisp Machine, the entire software, from the operating system into user applications are all available as gigantic Lisp functions.

We can use the functions in our code. We can also edit the code, even the code of the program we are currently running, save the code, then reload it.

Yes, the operating system itself can be edited, saved and reloaded.

But it is different with Emacs. It is basically an elisp interpreter with some functionalities to aid text editing. These two are all C code.

They cannot be edited, saved and reload.

Emacs in Unix possibly is different with Emacs (EINE, ZWEINE) on Lisp Machine.

#GNUEmacs #Emacs #LispMachine

@crandel @alerque @Zenie @weavejester

@restorante @crandel @alerque @Zenie @weavejester

Right — that’s the key difference. #Lisp Machines exposed the whole stack as live, editable Lisp, while #Emacs runs an #Elisp interpreter on top of a fixed #C substrate.

So no, it isn’t a Lisp Machine in the literal sense — but the way it internalizes extensibility and lets you rewire behavior in Lisp is what makes the comparison stick in spirit. That’s also why it feels so different from the Unix “small tools + pipes” model.

@demiguru @restorante @crandel @alerque @Zenie @weavejester GNU Emacs typically runs on top of another OS (UNIX, Windows, Linux, ...), using its own Lisp implementation as an OS process with its own memory.

Zmacs (an editor application) runs in a Lisp system, which itself acts as the operating system of a Lisp Machine, in a single shared memory space of Lisp objects.

@symbolics @demiguru @restorante @crandel @alerque@mastodon.social @Zenie @weavejester

Oh, my. Haven't seen that one in years!

A bit of nostalgia: some of his code contains names beginning with "pc-ppr".

This stood for "piece of paper". It was the desktop metaphor before every body switched to "windows". After all, on every desk I've ever had, there are pieces of paper, but not windows. :-)

@charliemac @symbolics @demiguru @restorante @crandel @Zenie @weavejester

Sheet, as I recall, was an abstraction in the lispm window system. (I can check the Encyclopaedia Symbolica upstairs, in case it matters.)

CLIM exposed that as a fundamental thing.

CLIM was pretty great. McCLIM still is.