
Emacs and Magit - tangue
https://lwn.net/Articles/727550/
======
avar
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.

~~~
sillysaurus3
_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
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).

------
gnuvince
> 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.

~~~
josteink
> False dichotomy: GNU Emacs can simply not ship with a git porcelain.

False dichotomy: The FSF can drop their requirement for onereous copyright
assignments and instead trust the GPL to do its job.

~~~
znpy
friendly reminder: the built-in vc-mode can interface with most version
control systems, including git.

It's not as great as magit, but it works (and it has you to learn very
little).

~~~
josteink
If the FSF wants Magit but can't bundle it because of their own policies (as
Stefan Monnier so eloquently points out), that's a problem for the FSF to
solve, not Magit.

I think this comment on the Lwn-article really highlights how bizarre this has
all turned out:

> GNU began as a project to replace proprietary software with free one, and
> now lives on as a project to replace free software with free software.

I think that about sums it up. (And I say that as a passionate Emacs-user)

------
dkhenry
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

------
rcthompson
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)

------
selectnull
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.

~~~
masklinn
> What it needs is better package manager - built in!

Er… it does? package.el has been included in Emacs since Emacs 24[0], and
there's an official package repository[1] which is included by default,
alongside the older MELPA and Marmalade which you can add to 'package-archives
if you want packages from there.

> I still have not completely comprehended how MELPA works.

MELPA is just a repository for package.el.

> If anything should be more closely built in (and documented and
> standardised) to Emacs, package manager should.

It is…

[0]
[https://www.emacswiki.org/emacs/ELPA](https://www.emacswiki.org/emacs/ELPA)

[1] [http://elpa.gnu.org](http://elpa.gnu.org)

~~~
klibertp
Just like other built-in things, the package.el is way too basic, both in
terms of features and interface. It's also useless for packages you'd like to
closely follow, as it cannot deal with git/bzr/hg/whathaveyou. Inability to
pin some package to the given version is also a major pain.

It's kind-of OK for beginners, but for more advanced users it's disappointing.
It's better, IMHO, to think about package.el as a low-level library
implementing some functions useful for package management - but calling it a
package manager, while technically correct, seems like a bit of a stretch.

There are other projects however, like el-get, which work. So it's not like
Emacs has no package manager. It's just that the "real" package managers are
far away from being built-in.

------
Myrmornis
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
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.

~~~
HelloNurse
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.

~~~
Tenobrus
I agree that Emacs seriously suffers from "anti-Python syndrome" (or maybe a
better term is just "Lisp syndrome") in that there's many ways to do a given
thing and no immediately clear "best" option. However, while it may not be
immediately clear, I think almost everything you mention here has a "pseudo-
consensus" best option. Not something everyone does, but that most people do,
and that you're most likely to see recommended as best practice.

\- You should be defining groups and variables to provide better documentation
and allow use of the interface. But you shouldn't actually use the interface
to do customization (put it in your personal configuration files instead). The
interface is both pretty annoying and disallows documentation of why exactly
you're setting certain options.

\- You use the standard package manager (package.el) and ELPA, MELPA, and
maybe the Org repo. There are a few of these which will require external tools
of some sort, in which case fair enough, that's an extra step. But that's
still pretty standard in my view (although definitely doing that automatically
would be great). I don't think I have any packages that require alternative
package managers anymore.

\- Use use-package. No real question at this point.

I do agree that themes are in general a nightmare.

------
sjm
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.

------
bjpbakker
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
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-
Matter...](https://www.gnu.org/prep/maintain/maintain.html#Legal-Matters)

------
green7ea
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
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.

~~~
tarsius
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
What part of IGNORING THE PATH ENVIRONMENT VARIABLE you didn't understand?
Magit is too clever for its own good.

~~~
kstrauser
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.

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

------
moomin
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
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
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/msg00...](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)

------
zcam
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.

------
kronos29296
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
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
Emacs master moves quite fast.

------
clarete
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.

------
aguynamedben
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.

------
hellofunk
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
That's odd. I've used Magit on OSX for at least a year now with no troubles,
just installed through MELPA.

~~~
hellofunk
I'll have to give it another try.

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

~~~
brlewis
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)

------
timwaagh
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
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
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.

