3 ms·

> These were essentially drop-in replacements with minimal impact to me. Consider what it would take to replace dired or Magit, as perfect as they might be. Th

> These were essentially drop-in replacements with minimal impact to me. Consider what it would take to replace dired or Magit, as perfect as they might be. There's a difference of philosophy there. The Unix way is a good concept to align software, but it's not the only one. In Emacs, the primitives are different. Instead of having pipes, redirectors, thinking in terms of lines,... What you have are buffers, windows to displays those buffers in, frames to hold those windows, a lot of functions to manipulate the text in buffers and keybindings to activate those functions. There's also the minibuffer for input and the echo area for messages. So using those people creates packages that solve each a particular task. But the packages are not closed programs you compose together. They are both libraries and a particular way to use the library. If it does not fit your purpose, you alter it. If it's missing something, you add it. If your workflow requires two or more packages, you link them together, creating a metapackage for that workflow. So Emacs is something to mold to your own needs. The default configuration is just the most common and the traditional way to do stuff. It's not lego bricks like the Unix way, it's clay. You don't replace ls with eza, you turn ls into eza.

imiric 1y ago
Right, the primitives are definitely different. But that's my point. The Unix primitives are simple and generic, which allows the user to quickly and easily adapt a disparate set of tools into an infinite number of workflows. The user is not required to also be a programmer[1]. If they are missing a specific tool, which is very rare, then it can be written in any language and integrated into existing workflows by following the simple design conventions. This generic interface is why programs written decades ago are still useful today. They don't need to be aware of how they're going to be used. They just need to follow the established design conventions. In contrast, if a specific Emacs package doesn't do what the user needs, they must use Elisp to change it, or write their own package. Integrating packages in a cohesive workflow also requires programming, and each integration is special because every package has its own quirks and API. This might be second nature to some Emacs gurus, but I don't want to program whenever I need to change my workflow. I'm sure that I could eventually build the perfect operating system for me this way, but I'd rather rely on an extensive ecosystem of tools written by others. [1]: I would argue that shell scripting is not programming, for better or worse. It's often the best tool for the job for getting things done quickly, but for more sophisticated tasks a programming language is a better fit.
- skydhash 1y ago
  Emac's primitive are much more involved for sure. But the focus on having a simple and common representation for input and output instead of the separation between prompt and output has make it a lot easier to write involved tooling. Instead of a TUI application which breaks the unix philosophy or a script for a single workflow, you have both. The closest I think is now Vim+tmux, but it's now as easy to modify on the fly.

imiric 1y ago

Right, the primitives are definitely different. But that's my point. The Unix primitives are simple and generic, which allows the user to quickly and easily adapt a disparate set of tools into an infinite number of workflows. The user is not required to also be a programmer[1]. If they are missing a specific tool, which is very rare, then it can be written in any language and integrated into existing workflows by following the simple design conventions. This generic interface is why programs written decades ago are still useful today. They don't need to be aware of how they're going to be used. They just need to follow the established design conventions. In contrast, if a specific Emacs package doesn't do what the user needs, they must use Elisp to change it, or write their own package. Integrating packages in a cohesive workflow also requires programming, and each integration is special because every package has its own quirks and API. This might be second nature to some Emacs gurus, but I don't want to program whenever I need to change my workflow. I'm sure that I could eventually build the perfect operating system for me this way, but I'd rather rely on an extensive ecosystem of tools written by others. [1]: I would argue that shell scripting is not programming, for better or worse. It's often the best tool for the job for getting things done quickly, but for more sophisticated tasks a programming language is a better fit.

skydhash 1y ago
Emac's primitive are much more involved for sure. But the focus on having a simple and common representation for input and output instead of the separation between prompt and output has make it a lot easier to write involved tooling. Instead of a TUI application which breaks the unix philosophy or a script for a single workflow, you have both. The closest I think is now Vim+tmux, but it's now as easy to modify on the fly.