16 ms·

Emacs and Magit

274 points by tangue 9y ago

dkhenry 9y ago
Magit is still the reason I haven't jumped ship to Atom of VSCode at this point and I would hate to see anything happen to it that would negatively effect its development. As far as the argument goes, I feel the platform is _better_ by having such a marquee package not be included. The barrier to get it installed it quite simple ( run one command ) and it opens up the user to the package management system which is getting better and allows users to bring in all the features that used to require elisp hacking
moomin 9y ago
Whilst appearing even handed, in practice the article fails to mention a single reason for Stallman wanting the copyright assignment. I don't know what his reasons are, but he does tend to have thought through these issues carefully.
- pm215 9y ago
  I think the article author assumes that the fact and the reasons for the FSF insisting on copyright assignment for its software are well known. https://www.gnu.org/licenses/why-assign.en.html https://www.gnu.org/licenses/why-assign.en.html has the answer, which basically boils down to "it ensures that there aren't going to be any awkward problems if the FSF ever needs to legally enforce the license."
  - Myrmornis 9y ago
    I think you answered a different question from what GP was asking. The question for most people, which is answered in neither the article nor the email threads in emacs-devel, is why this stuff needs to be "in Emacs". What is wrong with it being a third-party package? For example, these quotes from Stallman: > We have a problem in Emacs: it doesn't contain a good interface to git. People often recommend something that is not in Emacs. That's not a good situation. > When people ask here what they should do to use git with Emacs, the usual answer posted is "use Magit". Thus the problem: that the usual way people recommend to use Emacs with Git is via a package we have been unable to include in Emacs. The obvious question is: what is wrong with using a package that is not in core Emacs? https://lists.gnu.org/archive/html/emacs-devel/2017-07/msg00109.html https://lists.gnu.org/archive/html/emacs-devel/2017-07/msg00... https://lists.gnu.org/archive/html/emacs-devel/2017-07/msg00105.html https://lists.gnu.org/archive/html/emacs-devel/2017-07/msg00...
kronos29296 9y ago
So like org mode and other packages they want to include magit in Emacs. Just got bigger but magit being such a great package I think they should do it. Hope the copyright assignment happens and FSF does it.
- masklinn 9y ago
  No, let's not. Magit is a great package, and the ease of contribution and ability to move quickly are great parts of it.
  - gkya 9y ago
    Emacs master moves quite fast.
gnuvince 9y ago
> Either all of the significant contributors to Magit must sign papers with the FSF (with code from the holdouts being replaced), or an entirely new Emacs interface to Git must be written. False dichotomy: GNU Emacs can simply not ship with a git porcelain. Most Emacs users I know typically have dozens of packages installed from MELPA; I don't think most users mind having to install an extra one. If an acceptable agreement regarding copyright assignment cannot be reached, I would really prefer that the status quo be maintained.
- Singletoned 9y ago
  Yeah, maybe Magit is also the killer app for the 'package' system as well.
- lottin 9y ago
  Stallman said he didn't like having to tell users that they need to install a package in order to have the kind of functionality that Magit provides.
  - Myrmornis 9y ago
    So? He's not the maintainer of the project. Anyway, that's clearly a non-scaleable solution. No software engineer would be attracted to this design, only someone with a fanatical obsession with GPL which blinds him to engineering considerations. The emacs core developers can't take on the burden of maintaining every bit of add-on functionality that is written throughout human history and seems useful enough to want to include in emacs. These things should have test suites; maintaining a discrete project like magit or org-mode is the job of the magit/org-mode developers, and should be isolated from the core Emacs code base, interacting via the API provided by Emacs core. One job of the core developers is to design and maintain that API.
    - koolba 9y ago
      It's not even a GPL/non-GPL issue. Magit is licensed under the GPLv3. It's because the FSF doesn't have assignment of the copyright to the code and there's no signed contributor agreements. The insane part of this isn't wanting it to be FOSS (it is!!), it's insisting it to be a part of the core project.
avar 9y ago
If it were to be accepted into Emacs itself that would only be the beginning of the story. Right now Magit is hosted on Github and anyone can contribute by just sending a pull request. If it were part of Emacs you'd need to use the FSF's collaboration tools which have a higher barrier of entry, and if you're a first-time contributor with a non-trivial contribution you're going to have to wait days/weeks as your copyright assignment papers make their way over snail-mail. I've contributed several (trivial) patches to Magit, zero to Emacs itself, and would likely have contributed zero to Magit if it had been an FSF project to begin with. I think the FSF has gotten their priorities seriously wrong. The package is already licensed under the GPLv3, they're wanting to subject everyone to a more onerous contribution process to guard against the edge case of someone ripping off one specific Emacs package and the FSF not being in a position to have standing in court if they wanted to sue them.
- danieldk 9y ago
  The package is already licensed under the GPLv3, I fully agree. I think it is also important to point out that it uses the 'either version 3, or (at your option) any later version'-wording. So, even if the FSF updates the GPL, they are fine.
- sillysaurus3 9y ago
  If it were part of Emacs you'd need to use the FSF's collaboration tools which have a higher barrier of entry, and if you're a first-time contributor with a non-trivial contribution you're going to have to wait days/weeks as your copyright assignment papers make their way over snail-mail. This is as good a reason as any to try to replace Emacs. Maybe Remacs will succeed. Though I suppose it'd be best to have proof of this claim. Not that I don't believe you, but this is the type of thing that turns newbies away from Emacs without giving it a shot.
  - kronos29296 9y ago
    Neovim came along but majority who use vim still use vim. They won't change. This is in a situation where neovim is ahead of vim in certain areas (some may not like it and call it bloat but I call them features). Unless remacs gives a clear advantage over emacs in terms of performance while still retaining compatibility people won't switch easily. Even then the switch should be quick and painless. (Neovim had those and so some people jumped ship).
selectnull 9y ago
Emacs does not need to bundle Magit (or most other packages for that matter). What it needs is better package manager - built in! As of recently, I'm an Emacs user (long time Vim user, just wanted some change) and I still have not completely comprehended how MELPA works. If anything should be more closely built in (and documented and standardised) to Emacs, package manager should. Everything else is better placed into outside packages. If we look at Python world, here and there we can find discussions to include some library into stdlib and there are good reasons not to do it. Yes, batteries included is cool at first but it's no wonder that pythonistas say that "stdlib is place where packages go to die". We can think the same of Emacs and its package system.
- gpderetta 9y ago
  What's the issue with the builtin package manager? After configuring your desired sources, any of the hundreds of packages available are literally an M-x package-install away (or package-list-packages if you want to browse around). [1] This is my 'configuration', I haven't touched it in years: (setq package-archives '(("gnu" . "http://elpa.gnu.org/packages/" http://elpa.gnu.org/packages/") ("melpa-stable" . "http://stable.melpa.org/packages/" http://stable.melpa.org/packages/") ("melpa" . "http://melpa.org/packages/")) http://melpa.org/packages/")))
  - moomin 9y ago
    One of my biggest issues is that you can't request specific versions. Without that, the standard "big distributions" like spacemacs are doomed to constantly break. It's no accident quite a few Emacs power users plain don't use it.
- sillysaurus3 9y ago
  Forget MELPA. Use el-get.
  - lorenzhs 9y ago
    I concur, el-get is quite nice and can install/manage packages from a wide variety of sources, sort of like Arch's AUR. It's at https://github.com/dimitri/el-get https://github.com/dimitri/el-get.
green7ea 9y ago
Magit is my one of my favorite Emacs packages. It's not entirely intuitive at first but once you get the hang of it, it streamlines the git workflow to a very pleasant interaction. I highly recommend that anyone using Emacs and git gives Magit a try.
- HelloNurse 9y ago
  I gave Magit a try on Windows, and it failed miserably at finding git automagically. With no configurable option and no documented or at least easily hackable entry point, Magit was my quickest Emacs package removal.
  - rodonn 9y ago
    Strange. It found git on my system automatically without any trouble.
  - tarsius 9y ago
    Just because you did't make an effort to actually look for these things, that doesn't mean that they don't exist: https://magit.vc/manual/magit/Git-Executable.html https://magit.vc/manual/magit/Git-Executable.html.
    - HelloNurse 9y ago
      What part of IGNORING THE PATH ENVIRONMENT VARIABLE you didn't understand? Magit is too clever for its own good.
      - kstrauser 9y ago
        From that link: > This is necessary because Git on that platform comes with several wrapper scripts for the actual git binary, which are also placed on $PATH, and using one of these wrappers instead of the binary would degrade performance horribly. That sounds like a good reason to be clever.
  - na85 9y ago
freddref 9y ago
If you've already learned to install and use Emacs, one more package aint gonna kill ya.
Myrmornis 9y ago
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
rcthompson 9y ago
So, the reason that FSF wants the hold the copyright to the code they distribute is so that they, as the copyright holder, can enforce the license [1]. But why do they need to be the ones enforcing the license on every bit of code they distribute? They could include Magit with Emacs and just declare that they will not be the ones enforcing the license on that part of the code. The main issue I see with such an arrangement is that if Magit was included with Emacs, then conceivably some low-level Magit functions that have more general use could start to find their way into other Emacs code, and other people writing code for Emacs will use those functions in their code. Then the FSF would be in a situation where some of the code that they hold the copyright to depends on code whose copyright they don't hold. To prevent this, I guess they could establish a "contrib" directory in the emacs source for GPL3+-compatible code that is distributed with Emacs but whose copyright is not owned by the FSF. Any GPL3+ code, or really any free software code with a compatible license, could be added in this directory, without copyright assignment, if the Emacs maintainers feel it's worth including with Emacs. Then, they could require that code outside the contrib directory must not depend on code inside it, and that would be a fairly easy rule to enforce. Then they can include Magit and whatever other GPL3+ Emacs packages they want to with Emacs, but they will still have precise knowledge of which parts of the code they hold the copyright to and can enforce the license on (namely, everything outside the contrib directory). Are there any downsides to such an arrangement that I'm missing? Is there something that makes this kind of solution unworkable? Ultimately, I don't see why the FSF doesn't want to distribute any code that they can't enforce the license on. Maintaining copyright on their own code and distributing other people's code aren't mutually exclusive activities. [1]: https://www.gnu.org/licenses/why-assign.en.html https://www.gnu.org/licenses/why-assign.en.html
bjpbakker 9y ago
As one of the small contributors (ranked #225 to be exact) I just became aware of this and emailed the FSF how I can assign them my copyright. I'm not sure if this is a tedious process but I do believe that it is worth it in the end, when the FSF is able to legally defend this freedom.
- rekado 9y ago
  It's not difficult. The process is described here: https://www.fsf.org/licensing/assigning.html https://www.fsf.org/licensing/assigning.html I've done this in the past for both Guile and Emacs. For project maintainers it is a little bit more involved: https://www.gnu.org/prep/maintain/maintain.html#Legal-Matters https://www.gnu.org/prep/maintain/maintain.html#Legal-Matter...
hacknat 9y ago
The number of people who use emacs, but also need a friendly front end for git has to be vanishingly tiny.
- brlewis 9y ago
  I think the appeal is more how it streamlines workflow, not how newbie-friendly it is. https://news.ycombinator.com/item?id=14819432 https://news.ycombinator.com/item?id=14819432
- ams6110 9y ago
  Magit is the only thing that makes git usable to me.
- gpderetta 9y ago
  magit is the emacs killer app for me. It doesn't try to hide git in a generic VC interface, but it is really a self documenting, streamlined, alternative porcelain for the git plumbing.
timwaagh 9y ago
the reason im not an emacs kind of person is that it comes with too many goodies. it becomes too complex. i have no need for org-mode and if i need a psychiatrist i can use a real one. including git wont help much. its almost as complex as Eclipse the way it is now. including some fancy git interface will not help matters. so vim it is. if it does not have functionality i need i download it (or write it myself, easy enough). its a shame emacs is such a hodgepodge as i would definitely like to write new editor functionality using a lisp.
- kazinator 9y ago
  I.e. you want to be able to program your editor in a Lisp, but nobody should upstream any such code into a distribution which accompanies the editor.
  - timwaagh 9y ago
    its fine if there are such distributions. i just dont think they should be the main distribution. by this i mean: i think the distro you get when you click the 'download editor' button on the site of the author of the editor or enter apt-get install editor, should eliminate these extras to avoid intimidating people too much and achieve a nice cleaned up aesthetic. editors like emacs and vim are already have a steep learning curve without any extras and experts who need the extras will find them. i am a great admirer of what stallman did for free software and i really like the idea of emacs. however i am also aware that its usage is declining. so i do believe taking a more critical look at his decisions is worth it.
hellofunk 9y ago
I tried for a long time to get Magit to work on OSX. Never could; anyone else? The way OSX was setup for emacs to hook into the git process was strange and not smooth for getting them to behave well together.
- chasely 9y ago
  That's odd. I've used Magit on OSX for at least a year now with no troubles, just installed through MELPA.
  - hellofunk 9y ago
    I'll have to give it another try.
- wging 9y ago
  Works really well for me; zero effort to set up. Specific errors/point of difficulty would be interesting. Also I hear plans are for it to switch to using libgit2.
deleted 9y ago
[deleted]
clarete 9y ago
I saw this on Reddit, lwn and now here and I didn't see anyone comment on license upgrades. when FSF released GPLv3 they migrated a ton of software from one version to another. although GPL is usually forward compatible with its newer versions I still wonder if that's the concern behind Stallman's opinion.
zcam 9y ago
I love magit & git but emacs has seen many vcs come and go and I am not sure bundling it by default is crucial. Who knows what vcs we'll be using in 10 years, let alone other specific packages that might follow the same route. I'd rather keep emacs core lean personally.
aguynamedben 9y ago
This seems like an interesting idealogical argument to follow, but anybody using Emacs in the real world is going to just go ahead and install Magit. Nobody uses Emacs on the default settings anyways. Part of learning Emacs is sorting out your init file.
sjm 9y ago
Magit is one of the most powerful pieces of software I use on a daily basis. It's incredibly well designed and I'd be seriously lost without it. That said, I think it's a good thing for MELPA and package.el in general that it's not built-in. It's a killer app, and I can only assume it encourages people to explore more packages. I also totally agree with the post about contributing. Assignments aren't even the major issue, it's that with magit you can discuss issues, send a PR on GitHub and have a patch included in no-time. As part of Emacs, we'd have to go through mailing-list hell for any discussion and that's before considering the difficulties of actually getting a patch pulled in, at which point most people will have to wait for a new release? As part of MELPA I can update as soon as the PR is merged in. Strange that people complain about the packaging system — I find it does the job and is super easy to get updates.

274 points by tangue 9y ago

Magit is still the reason I haven't jumped ship to Atom of VSCode at this point and I would hate to see anything happen to it that would negatively effect its development. As far as the argument goes, I feel the platform is _better_ by having such a marquee package not be included. The barrier to get it installed it quite simple ( run one command ) and it opens up the user to the package management system which is getting better and allows users to bring in all the features that used to require elisp hacking

moomin 9y ago

Whilst appearing even handed, in practice the article fails to mention a single reason for Stallman wanting the copyright assignment. I don't know what his reasons are, but he does tend to have thought through these issues carefully.

pm215 9y ago
I think the article author assumes that the fact and the reasons for the FSF insisting on copyright assignment for its software are well known. https://www.gnu.org/licenses/why-assign.en.html https://www.gnu.org/licenses/why-assign.en.html has the answer, which basically boils down to "it ensures that there aren't going to be any awkward problems if the FSF ever needs to legally enforce the license."
- Myrmornis 9y ago
  I think you answered a different question from what GP was asking. The question for most people, which is answered in neither the article nor the email threads in emacs-devel, is why this stuff needs to be "in Emacs". What is wrong with it being a third-party package? For example, these quotes from Stallman: > We have a problem in Emacs: it doesn't contain a good interface to git. People often recommend something that is not in Emacs. That's not a good situation. > When people ask here what they should do to use git with Emacs, the usual answer posted is "use Magit". Thus the problem: that the usual way people recommend to use Emacs with Git is via a package we have been unable to include in Emacs. The obvious question is: what is wrong with using a package that is not in core Emacs? https://lists.gnu.org/archive/html/emacs-devel/2017-07/msg00109.html https://lists.gnu.org/archive/html/emacs-devel/2017-07/msg00... https://lists.gnu.org/archive/html/emacs-devel/2017-07/msg00105.html https://lists.gnu.org/archive/html/emacs-devel/2017-07/msg00...

kronos29296 9y ago

So like org mode and other packages they want to include magit in Emacs. Just got bigger but magit being such a great package I think they should do it. Hope the copyright assignment happens and FSF does it.

masklinn 9y ago
No, let's not. Magit is a great package, and the ease of contribution and ability to move quickly are great parts of it.
- gkya 9y ago
  Emacs master moves quite fast.

gnuvince 9y ago

> Either all of the significant contributors to Magit must sign papers with the FSF (with code from the holdouts being replaced), or an entirely new Emacs interface to Git must be written. False dichotomy: GNU Emacs can simply not ship with a git porcelain. Most Emacs users I know typically have dozens of packages installed from MELPA; I don't think most users mind having to install an extra one. If an acceptable agreement regarding copyright assignment cannot be reached, I would really prefer that the status quo be maintained.

Singletoned 9y ago
Yeah, maybe Magit is also the killer app for the 'package' system as well.
lottin 9y ago
Stallman said he didn't like having to tell users that they need to install a package in order to have the kind of functionality that Magit provides.
- Myrmornis 9y ago
  So? He's not the maintainer of the project. Anyway, that's clearly a non-scaleable solution. No software engineer would be attracted to this design, only someone with a fanatical obsession with GPL which blinds him to engineering considerations. The emacs core developers can't take on the burden of maintaining every bit of add-on functionality that is written throughout human history and seems useful enough to want to include in emacs. These things should have test suites; maintaining a discrete project like magit or org-mode is the job of the magit/org-mode developers, and should be isolated from the core Emacs code base, interacting via the API provided by Emacs core. One job of the core developers is to design and maintain that API.
  - koolba 9y ago
    It's not even a GPL/non-GPL issue. Magit is licensed under the GPLv3. It's because the FSF doesn't have assignment of the copyright to the code and there's no signed contributor agreements. The insane part of this isn't wanting it to be FOSS (it is!!), it's insisting it to be a part of the core project.

avar 9y ago

If it were to be accepted into Emacs itself that would only be the beginning of the story. Right now Magit is hosted on Github and anyone can contribute by just sending a pull request. If it were part of Emacs you'd need to use the FSF's collaboration tools which have a higher barrier of entry, and if you're a first-time contributor with a non-trivial contribution you're going to have to wait days/weeks as your copyright assignment papers make their way over snail-mail. I've contributed several (trivial) patches to Magit, zero to Emacs itself, and would likely have contributed zero to Magit if it had been an FSF project to begin with. I think the FSF has gotten their priorities seriously wrong. The package is already licensed under the GPLv3, they're wanting to subject everyone to a more onerous contribution process to guard against the edge case of someone ripping off one specific Emacs package and the FSF not being in a position to have standing in court if they wanted to sue them.

danieldk 9y ago
The package is already licensed under the GPLv3, I fully agree. I think it is also important to point out that it uses the 'either version 3, or (at your option) any later version'-wording. So, even if the FSF updates the GPL, they are fine.
sillysaurus3 9y ago
If it were part of Emacs you'd need to use the FSF's collaboration tools which have a higher barrier of entry, and if you're a first-time contributor with a non-trivial contribution you're going to have to wait days/weeks as your copyright assignment papers make their way over snail-mail. This is as good a reason as any to try to replace Emacs. Maybe Remacs will succeed. Though I suppose it'd be best to have proof of this claim. Not that I don't believe you, but this is the type of thing that turns newbies away from Emacs without giving it a shot.
- kronos29296 9y ago
  Neovim came along but majority who use vim still use vim. They won't change. This is in a situation where neovim is ahead of vim in certain areas (some may not like it and call it bloat but I call them features). Unless remacs gives a clear advantage over emacs in terms of performance while still retaining compatibility people won't switch easily. Even then the switch should be quick and painless. (Neovim had those and so some people jumped ship).

selectnull 9y ago

Emacs does not need to bundle Magit (or most other packages for that matter). What it needs is better package manager - built in! As of recently, I'm an Emacs user (long time Vim user, just wanted some change) and I still have not completely comprehended how MELPA works. If anything should be more closely built in (and documented and standardised) to Emacs, package manager should. Everything else is better placed into outside packages. If we look at Python world, here and there we can find discussions to include some library into stdlib and there are good reasons not to do it. Yes, batteries included is cool at first but it's no wonder that pythonistas say that "stdlib is place where packages go to die". We can think the same of Emacs and its package system.

gpderetta 9y ago
What's the issue with the builtin package manager? After configuring your desired sources, any of the hundreds of packages available are literally an M-x package-install away (or package-list-packages if you want to browse around). [1] This is my 'configuration', I haven't touched it in years: (setq package-archives '(("gnu" . "http://elpa.gnu.org/packages/" http://elpa.gnu.org/packages/") ("melpa-stable" . "http://stable.melpa.org/packages/" http://stable.melpa.org/packages/") ("melpa" . "http://melpa.org/packages/")) http://melpa.org/packages/")))
- moomin 9y ago
  One of my biggest issues is that you can't request specific versions. Without that, the standard "big distributions" like spacemacs are doomed to constantly break. It's no accident quite a few Emacs power users plain don't use it.
sillysaurus3 9y ago
Forget MELPA. Use el-get.
- lorenzhs 9y ago
  I concur, el-get is quite nice and can install/manage packages from a wide variety of sources, sort of like Arch's AUR. It's at https://github.com/dimitri/el-get https://github.com/dimitri/el-get.

green7ea 9y ago

Magit is my one of my favorite Emacs packages. It's not entirely intuitive at first but once you get the hang of it, it streamlines the git workflow to a very pleasant interaction. I highly recommend that anyone using Emacs and git gives Magit a try.

HelloNurse 9y ago
I gave Magit a try on Windows, and it failed miserably at finding git automagically. With no configurable option and no documented or at least easily hackable entry point, Magit was my quickest Emacs package removal.
- rodonn 9y ago
  Strange. It found git on my system automatically without any trouble.
- tarsius 9y ago
  Just because you did't make an effort to actually look for these things, that doesn't mean that they don't exist: https://magit.vc/manual/magit/Git-Executable.html https://magit.vc/manual/magit/Git-Executable.html.
  - HelloNurse 9y ago
    What part of IGNORING THE PATH ENVIRONMENT VARIABLE you didn't understand? Magit is too clever for its own good.
    - kstrauser 9y ago
      From that link: > This is necessary because Git on that platform comes with several wrapper scripts for the actual git binary, which are also placed on $PATH, and using one of these wrappers instead of the binary would degrade performance horribly. That sounds like a good reason to be clever.
- na85 9y ago

freddref 9y ago

If you've already learned to install and use Emacs, one more package aint gonna kill ya.

Myrmornis 9y ago

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

rcthompson 9y ago

So, the reason that FSF wants the hold the copyright to the code they distribute is so that they, as the copyright holder, can enforce the license [1]. But why do they need to be the ones enforcing the license on every bit of code they distribute? They could include Magit with Emacs and just declare that they will not be the ones enforcing the license on that part of the code. The main issue I see with such an arrangement is that if Magit was included with Emacs, then conceivably some low-level Magit functions that have more general use could start to find their way into other Emacs code, and other people writing code for Emacs will use those functions in their code. Then the FSF would be in a situation where some of the code that they hold the copyright to depends on code whose copyright they don't hold. To prevent this, I guess they could establish a "contrib" directory in the emacs source for GPL3+-compatible code that is distributed with Emacs but whose copyright is not owned by the FSF. Any GPL3+ code, or really any free software code with a compatible license, could be added in this directory, without copyright assignment, if the Emacs maintainers feel it's worth including with Emacs. Then, they could require that code outside the contrib directory must not depend on code inside it, and that would be a fairly easy rule to enforce. Then they can include Magit and whatever other GPL3+ Emacs packages they want to with Emacs, but they will still have precise knowledge of which parts of the code they hold the copyright to and can enforce the license on (namely, everything outside the contrib directory). Are there any downsides to such an arrangement that I'm missing? Is there something that makes this kind of solution unworkable? Ultimately, I don't see why the FSF doesn't want to distribute any code that they can't enforce the license on. Maintaining copyright on their own code and distributing other people's code aren't mutually exclusive activities. [1]: https://www.gnu.org/licenses/why-assign.en.html https://www.gnu.org/licenses/why-assign.en.html

bjpbakker 9y ago

As one of the small contributors (ranked #225 to be exact) I just became aware of this and emailed the FSF how I can assign them my copyright. I'm not sure if this is a tedious process but I do believe that it is worth it in the end, when the FSF is able to legally defend this freedom.

rekado 9y ago
It's not difficult. The process is described here: https://www.fsf.org/licensing/assigning.html https://www.fsf.org/licensing/assigning.html I've done this in the past for both Guile and Emacs. For project maintainers it is a little bit more involved: https://www.gnu.org/prep/maintain/maintain.html#Legal-Matters https://www.gnu.org/prep/maintain/maintain.html#Legal-Matter...

hacknat 9y ago

The number of people who use emacs, but also need a friendly front end for git has to be vanishingly tiny.

brlewis 9y ago
I think the appeal is more how it streamlines workflow, not how newbie-friendly it is. https://news.ycombinator.com/item?id=14819432 https://news.ycombinator.com/item?id=14819432
ams6110 9y ago
Magit is the only thing that makes git usable to me.
gpderetta 9y ago
magit is the emacs killer app for me. It doesn't try to hide git in a generic VC interface, but it is really a self documenting, streamlined, alternative porcelain for the git plumbing.

timwaagh 9y ago

the reason im not an emacs kind of person is that it comes with too many goodies. it becomes too complex. i have no need for org-mode and if i need a psychiatrist i can use a real one. including git wont help much. its almost as complex as Eclipse the way it is now. including some fancy git interface will not help matters. so vim it is. if it does not have functionality i need i download it (or write it myself, easy enough). its a shame emacs is such a hodgepodge as i would definitely like to write new editor functionality using a lisp.

kazinator 9y ago
I.e. you want to be able to program your editor in a Lisp, but nobody should upstream any such code into a distribution which accompanies the editor.
- timwaagh 9y ago
  its fine if there are such distributions. i just dont think they should be the main distribution. by this i mean: i think the distro you get when you click the 'download editor' button on the site of the author of the editor or enter apt-get install editor, should eliminate these extras to avoid intimidating people too much and achieve a nice cleaned up aesthetic. editors like emacs and vim are already have a steep learning curve without any extras and experts who need the extras will find them. i am a great admirer of what stallman did for free software and i really like the idea of emacs. however i am also aware that its usage is declining. so i do believe taking a more critical look at his decisions is worth it.

hellofunk 9y ago

I tried for a long time to get Magit to work on OSX. Never could; anyone else? The way OSX was setup for emacs to hook into the git process was strange and not smooth for getting them to behave well together.

chasely 9y ago
That's odd. I've used Magit on OSX for at least a year now with no troubles, just installed through MELPA.
- hellofunk 9y ago
  I'll have to give it another try.
wging 9y ago
Works really well for me; zero effort to set up. Specific errors/point of difficulty would be interesting. Also I hear plans are for it to switch to using libgit2.

deleted 9y ago

[deleted]

clarete 9y ago

I saw this on Reddit, lwn and now here and I didn't see anyone comment on license upgrades. when FSF released GPLv3 they migrated a ton of software from one version to another. although GPL is usually forward compatible with its newer versions I still wonder if that's the concern behind Stallman's opinion.

zcam 9y ago

I love magit & git but emacs has seen many vcs come and go and I am not sure bundling it by default is crucial. Who knows what vcs we'll be using in 10 years, let alone other specific packages that might follow the same route. I'd rather keep emacs core lean personally.

aguynamedben 9y ago

This seems like an interesting idealogical argument to follow, but anybody using Emacs in the real world is going to just go ahead and install Magit. Nobody uses Emacs on the default settings anyways. Part of learning Emacs is sorting out your init file.

sjm 9y ago

Magit is one of the most powerful pieces of software I use on a daily basis. It's incredibly well designed and I'd be seriously lost without it. That said, I think it's a good thing for MELPA and package.el in general that it's not built-in. It's a killer app, and I can only assume it encourages people to explore more packages. I also totally agree with the post about contributing. Assignments aren't even the major issue, it's that with magit you can discuss issues, send a PR on GitHub and have a patch included in no-time. As part of Emacs, we'd have to go through mailing-list hell for any discussion and that's before considering the difficulties of actually getting a patch pulled in, at which point most people will have to wait for a new release? As part of MELPA I can update as soon as the PR is merged in. Strange that people complain about the packaging system — I find it does the job and is super easy to get updates.