5 ms·

Why is there a desire to include things like magit in emacs? (Same question regarding e.g. org-mode). Wouldn't it be better to have a lean core, abiding by the

Why is there a desire to include things like magit in emacs? (Same question regarding e.g. org-mode). Wouldn't it be better to have a lean core, abiding by the strict FSF rules, and a high quality package ecosystem and package manager? It needn't be a barrier to beginners, high quality "distributions" bundling the great packages like magit and org-mode would appear immediately (kind of exist already, like spacemacs).

throwanem 9y ago
You tend to have the same kinds of problems as early Linux distros did - namely, fragmentation that accidentally heightens the barrier to entry. Aside from that, much of Emacs's power comes from the ecosystem of Emacs Lisp applications and libraries that come with the base install. I learned Emacs in the first place because of Tramp's appeal, and shortly thereafter discovered in org-mode an amazingly powerful tool I'd never realized I wanted so badly. Absent either of those, I probably would not have kept using Emacs for long. Finally, there's the question of support. A few years back, when I was much more heavily involved in helping new Emacs users on sites like Stack Overflow, I found over time that the problems people were having tended more often than not to originate not in Emacs per se, but rather in the (mis)behavior of the various collections of packages that came with one or another of the "starter kits" then popular, and beset by the same fragmentation mentioned above. When you start out not with Emacs, but with Emacs plus a large collection of random packages tied together with customizations and init unique to the distribution, it's much harder to find useful information when something goes wrong, because there probably aren't all that many people using the same thing you are - and, being very new, you likely don't yet know how to have a productive conversation with Emacs itself, or even that such conversations are possible. Conversely, when you have a problem with something that's part of Emacs, you're much more likely to find something or someone that can help you get past it, because ~everyone using Emacs is running the same code you are, and someone has almost certainly figured out how to solve the same problem before. Fragmenting the ecosystem makes this less likely; incorporating popular packages into Emacs, where that can be accomplished, makes it more so.
- Myrmornis 9y ago
  Thanks for the thoughtful answer. 1. Your main point is clearly correct. But the counterpoint is that it's not scaleable for the emacs core developers to take the responsibility of maintaining the code from every third-party package that seems useful enough to include. A few years ago I wrote quite a bit of code for org-mode, so I've seen how this works. The org-mode team prepares a release (err, no test suite though! At least not back then.) And then some weeks/months ahead of a major emacs release, the org-mode codebase at an agreed commit gets copied over into the emacs code base. But from that point on, emacs core devs are on the hook for any mistakes we made. That clearly doesn't scale to many packages. So what you said notwithstanding, the only viable option long term is to make the package management system excellent, and to make the API via which packages interact with emacs core excellent. 2. Yes to what you say about the "starter kits". But things have completely changed since then with the arrival of package management and package repositories.
- HelloNurse 9y ago
  As a not very committed and not very expert Emacs user, I find annoying fragmentation in Emacs configuration not at the level of individual packages, but of fundamental mechanisms with inconsistent alternatives. - defining customization groups and variables for one's package vs. not bothering and using semi-documented raw global variables (many actively despise the customization system) - properly using the Customization pages vs. just overriding the variables in the init file -packages that need to be built from a cloned Git (usually Github) repository, packages that want to be "installed" by hand, packages that use the "standard" package manager, alternative package managers, packages offering more than one of the above (or multiple sources with different versions) - loading and configuring packages with require statements and setting variables; with use-package in self-contained blocks; implicitly or almost implicitly; in ad hoc ways. Sometimes Emacs itself contributes to the mess; when I thought I exported my faces settings to a theme the "theme" file actually came to contain unrelated settings, preserving obsolete configuration of removed packages and amply overlapping and conflicting with the init file; now, for example, nyan-cat mode only displays a proper wavy trail if I use this magical theme. I'd need to spend hours dismantling the "theme" line by line.
VLM 9y ago
Essentially the same argument as linux-style OS vs freebsd-style OS. Its worth pointing out the analogy that most OS have git as an addon and have emacs itself as an addon. Once someone has gone to the effort of installing git, and installing emacs, installing magit isn't a noticeable or significant barrier. Another interesting thing for non-emacs users to consider is this saves approximately zero time. A quick grep -c use-package .emacs.d/init.el shows I import about 36 packages and I'm kinda a minimalist emacs user. The most effort I could possibly save would be about 3%. Its not like I'm going to stop using cider or flycheck if magit is bundled.
- tbirdz 9y ago
  Is there any difference between use-package and require? I've been using require in my init.el.
  - mark_h 9y ago
    require simply loads a feature, assuming it exists. use-package can do a whole lot more, including installing the package, configuring auto-loads, setting up key-bindings, pre- and post-load configuration, etc. It's a third-party package itself at this point, but I believe it's going to be included in Emacs before too long.
msla 9y ago
Think Python: One of the biggest strengths of the language was always the "Batteries Included" philosophy, which took Perl's CPAN idea (massively important for Perl's success, BTW) one step further and packaged common libraries into the base install. People got up and running faster, and Python prospered.
- Myrmornis 9y ago
  What in the python standard library compares with the extraordinary diversity of functionality present in, say, org-mode?
  - msla 9y ago
    That's a hard comparison to make, but I'm sure if the Python developers had a package they thought would be as well-loved as org-mode is among Emacs users, they'd package it in with the base install.
- kstrauser 9y ago
  OTOH, another big strength is the near universal adoption of certain fast moving third party packages. For example, everyone uses Requests because it's better in almost every way than the built-in stuff, but because it's not included with Python its developer can move at a much faster pace.

throwanem 9y ago

You tend to have the same kinds of problems as early Linux distros did - namely, fragmentation that accidentally heightens the barrier to entry. Aside from that, much of Emacs's power comes from the ecosystem of Emacs Lisp applications and libraries that come with the base install. I learned Emacs in the first place because of Tramp's appeal, and shortly thereafter discovered in org-mode an amazingly powerful tool I'd never realized I wanted so badly. Absent either of those, I probably would not have kept using Emacs for long. Finally, there's the question of support. A few years back, when I was much more heavily involved in helping new Emacs users on sites like Stack Overflow, I found over time that the problems people were having tended more often than not to originate not in Emacs per se, but rather in the (mis)behavior of the various collections of packages that came with one or another of the "starter kits" then popular, and beset by the same fragmentation mentioned above. When you start out not with Emacs, but with Emacs plus a large collection of random packages tied together with customizations and init unique to the distribution, it's much harder to find useful information when something goes wrong, because there probably aren't all that many people using the same thing you are - and, being very new, you likely don't yet know how to have a productive conversation with Emacs itself, or even that such conversations are possible. Conversely, when you have a problem with something that's part of Emacs, you're much more likely to find something or someone that can help you get past it, because ~everyone using Emacs is running the same code you are, and someone has almost certainly figured out how to solve the same problem before. Fragmenting the ecosystem makes this less likely; incorporating popular packages into Emacs, where that can be accomplished, makes it more so.

Myrmornis 9y ago
Thanks for the thoughtful answer. 1. Your main point is clearly correct. But the counterpoint is that it's not scaleable for the emacs core developers to take the responsibility of maintaining the code from every third-party package that seems useful enough to include. A few years ago I wrote quite a bit of code for org-mode, so I've seen how this works. The org-mode team prepares a release (err, no test suite though! At least not back then.) And then some weeks/months ahead of a major emacs release, the org-mode codebase at an agreed commit gets copied over into the emacs code base. But from that point on, emacs core devs are on the hook for any mistakes we made. That clearly doesn't scale to many packages. So what you said notwithstanding, the only viable option long term is to make the package management system excellent, and to make the API via which packages interact with emacs core excellent. 2. Yes to what you say about the "starter kits". But things have completely changed since then with the arrival of package management and package repositories.
HelloNurse 9y ago
As a not very committed and not very expert Emacs user, I find annoying fragmentation in Emacs configuration not at the level of individual packages, but of fundamental mechanisms with inconsistent alternatives. - defining customization groups and variables for one's package vs. not bothering and using semi-documented raw global variables (many actively despise the customization system) - properly using the Customization pages vs. just overriding the variables in the init file -packages that need to be built from a cloned Git (usually Github) repository, packages that want to be "installed" by hand, packages that use the "standard" package manager, alternative package managers, packages offering more than one of the above (or multiple sources with different versions) - loading and configuring packages with require statements and setting variables; with use-package in self-contained blocks; implicitly or almost implicitly; in ad hoc ways. Sometimes Emacs itself contributes to the mess; when I thought I exported my faces settings to a theme the "theme" file actually came to contain unrelated settings, preserving obsolete configuration of removed packages and amply overlapping and conflicting with the init file; now, for example, nyan-cat mode only displays a proper wavy trail if I use this magical theme. I'd need to spend hours dismantling the "theme" line by line.

VLM 9y ago

Essentially the same argument as linux-style OS vs freebsd-style OS. Its worth pointing out the analogy that most OS have git as an addon and have emacs itself as an addon. Once someone has gone to the effort of installing git, and installing emacs, installing magit isn't a noticeable or significant barrier. Another interesting thing for non-emacs users to consider is this saves approximately zero time. A quick grep -c use-package .emacs.d/init.el shows I import about 36 packages and I'm kinda a minimalist emacs user. The most effort I could possibly save would be about 3%. Its not like I'm going to stop using cider or flycheck if magit is bundled.

tbirdz 9y ago
Is there any difference between use-package and require? I've been using require in my init.el.
- mark_h 9y ago
  require simply loads a feature, assuming it exists. use-package can do a whole lot more, including installing the package, configuring auto-loads, setting up key-bindings, pre- and post-load configuration, etc. It's a third-party package itself at this point, but I believe it's going to be included in Emacs before too long.

msla 9y ago

Think Python: One of the biggest strengths of the language was always the "Batteries Included" philosophy, which took Perl's CPAN idea (massively important for Perl's success, BTW) one step further and packaged common libraries into the base install. People got up and running faster, and Python prospered.

Myrmornis 9y ago
What in the python standard library compares with the extraordinary diversity of functionality present in, say, org-mode?
- msla 9y ago
  That's a hard comparison to make, but I'm sure if the Python developers had a package they thought would be as well-loved as org-mode is among Emacs users, they'd package it in with the base install.
kstrauser 9y ago
OTOH, another big strength is the near universal adoption of certain fast moving third party packages. For example, everyone uses Requests because it's better in almost every way than the built-in stuff, but because it's not included with Python its developer can move at a much faster pace.