3 ms·

While Emacs(I'm speaking of emacs here because that's what I use, but it should apply largely to Vi as well) is very configurable and extensible, I wish someth

While Emacs(I'm speaking of emacs here because that's what I use, but it should apply largely to Vi as well) is very configurable and extensible, I wish something was there that is more "batteries included" than them. Recently I tried to use Emacs on a windows machine, and found that grep-find wouldn't work because it actually depends on an external grep program. The same with modern context and language and project aware auto-completion, it's not bundled in, and you need external components like LSPs to work.

brianstrimp 2y ago
That's the unix philosophy of using one tool for one thing, that does it well. The advantage is that it really opens a marketplace which means you are not tied to one solution if that solution turns out to suck. An alternative will quickly pop up, you switch, everybody does that, and in no time the bad piece has been worked around and replaced. This works against the "batteries included" philosophy but avoids being stuck for a long time with sub-par components. Over time, when things stabilize, that approach can change. But nvim is still very much a moving target. Python tries a middle ground. An http server is included, sime crypto libs are as well, but if you need something specialized you can still install alternative modules. That model seems to work well.
jampekka 2y ago
> I wish something was there that is more "batteries included" than them. There are e.g. Spacemacs and Doom emacs that don't only include batteries, but supercritical nuclear reactors about to explode at any moment. :)
iLemming 2y ago
Well, you either have "pre-assembled" hamburger, or freedom to cook your own. Imagine going to McDonalds and asking them to let you into their kitchen to customize your burger from scratch, choose specific ingredients, adjust cooking temperatures, and rearrange their workflow to match your preferences. Asking Emacs to be "batteries included" misses its fundamental nature - it's not a fast-food IDE, it's your own personal kitchen for crafting exactly the development environment you want. Even starter kits - Doom, Prelude, Spacemacs, etc. - are not really "ready-made" products; they're more like recipe books, where you have the freedom to choose and pick from, but they still don't liberate you from having to learn how to "cook things." They don't "magically" solve things for you.
- billfruit 2y ago
  Yes, but is there any argument to not to have intelligent automatic code completion out of the box, as a user today.
  - iLemming 2y ago
    In the context of Emacs, absolutely. I, for one, love the fact that the completions aren't an opinionated set of rules, and anyone can configure them to their liking. Why would I let anyone upstream dictate how those rules should apply, on my computer, in my editor? For example, when working in a Clojure codebase, I don't want to blindly rely on CIDER completions because they work only when you have a connected REPL. I want to leverage LSP completions (if it's connected), and I also want completions for my code snippets, filenames, keywords specific to the language, words in comments, etc. If tomorrow I wanted to use different rules, applying them dynamically based on some conditions - Emacs provides ways to achieve that. So yes, for completions specifically, I don't want them to be rigidly embedded in the core of Emacs. I prefer this feature to be an extension. Interestingly, Emacs is so versatile that some extensions are built so well that sometimes you completely forget they are not built-in features or an afterthought; they feel as if the editor was specifically designed to have them.
    - billfruit 2y ago
      I have nothing against completions being configurable or extensible, but only about not having a reasonable default set of capabilities shipped with the system and having to depend on extensions of various qualities and states of completion and which may further depend on other 3rd party components to provide such a core functionality for modern work.

brianstrimp 2y ago

That's the unix philosophy of using one tool for one thing, that does it well. The advantage is that it really opens a marketplace which means you are not tied to one solution if that solution turns out to suck. An alternative will quickly pop up, you switch, everybody does that, and in no time the bad piece has been worked around and replaced. This works against the "batteries included" philosophy but avoids being stuck for a long time with sub-par components. Over time, when things stabilize, that approach can change. But nvim is still very much a moving target. Python tries a middle ground. An http server is included, sime crypto libs are as well, but if you need something specialized you can still install alternative modules. That model seems to work well.

jampekka 2y ago

> I wish something was there that is more "batteries included" than them. There are e.g. Spacemacs and Doom emacs that don't only include batteries, but supercritical nuclear reactors about to explode at any moment. :)

iLemming 2y ago

Well, you either have "pre-assembled" hamburger, or freedom to cook your own. Imagine going to McDonalds and asking them to let you into their kitchen to customize your burger from scratch, choose specific ingredients, adjust cooking temperatures, and rearrange their workflow to match your preferences. Asking Emacs to be "batteries included" misses its fundamental nature - it's not a fast-food IDE, it's your own personal kitchen for crafting exactly the development environment you want. Even starter kits - Doom, Prelude, Spacemacs, etc. - are not really "ready-made" products; they're more like recipe books, where you have the freedom to choose and pick from, but they still don't liberate you from having to learn how to "cook things." They don't "magically" solve things for you.

billfruit 2y ago
Yes, but is there any argument to not to have intelligent automatic code completion out of the box, as a user today.
- iLemming 2y ago
  In the context of Emacs, absolutely. I, for one, love the fact that the completions aren't an opinionated set of rules, and anyone can configure them to their liking. Why would I let anyone upstream dictate how those rules should apply, on my computer, in my editor? For example, when working in a Clojure codebase, I don't want to blindly rely on CIDER completions because they work only when you have a connected REPL. I want to leverage LSP completions (if it's connected), and I also want completions for my code snippets, filenames, keywords specific to the language, words in comments, etc. If tomorrow I wanted to use different rules, applying them dynamically based on some conditions - Emacs provides ways to achieve that. So yes, for completions specifically, I don't want them to be rigidly embedded in the core of Emacs. I prefer this feature to be an extension. Interestingly, Emacs is so versatile that some extensions are built so well that sometimes you completely forget they are not built-in features or an afterthought; they feel as if the editor was specifically designed to have them.
  - billfruit 2y ago
    I have nothing against completions being configurable or extensible, but only about not having a reasonable default set of capabilities shipped with the system and having to depend on extensions of various qualities and states of completion and which may further depend on other 3rd party components to provide such a core functionality for modern work.