Emacs and Magit
lwn.net
lwn.net
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.
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.
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.
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).
There's a moral issue too in giving-up copyright to an entity : What if the future the FSF (RMS is not eternal) changes its policy to turn to something completely crazy with your code ? They will own all will own all your copyright-assigned code and you won't be able to do anything about it.
I mean : what if you were agree with GPL2 but not 3 and that now the copyright owner decides to move the code you've written to GPL3 ?
The FSF's copyright assignment contract has clauses that prevent them from doing such things. It's really a very fair contract.
Though Magit seems maybe a bit of a weird thing to be using on a minimal remote system.
The other answer is
apt-get install emacs-core-plus-standard-packages
apt-get install emacs-core emacs-magit emacs-org-mode
If we don't put stuff like org-mode and magit in emacs then the community will produce emacs distributions bundling the standard add-ons.
Specifically addressing this point (since major distros already package magit):
There are environments where it's not allowed to install software that hasn't been cleared by site/department/company IT, let alone software from a rolling repository where packages aren't signed and upstream maintainers can get code in just by tagging it on GitHub. In such an environment it's a lot easier to say something like "I need Debian 12 with build-essential and emacs26".
As cool and handy as it is, MELPA is kind of scary from a security standpoint.
Neither have I, but I have heard of (and been subject to) policies that don't allow installing unapproved 3rd party executable code, and have not seen one that made exceptions based on path.
But also, if such policies were based on (for instance) "noexec", you don't have to be able to run executables to install elisp code.
There were no technical measures in place to stop me from compiling my own binaries (that was in part what I was there to do), and bringing my own elisp also would have worked.
Except for the "breaking my contract" part, if it was unapproved 3rd party code. Given that actual FTEs respected the rule, it seemed unwise to test it.
I've lost count of how many projects I've contributed to, due to how easy Github makes submitting a patch.
Contrast that to contributing to Emacs: I can't recall a single time I tried to send in a change-proposal without regretting it, seeing it fan out for weeks in endless mailing lists discussions and more often than not end up going nowhere.
If Magit ends up under FSF ownership and the Github repo is discontinued, I'll just assume the number of contributors will plummet. At least that sounds like the most likely outcome.
Here's hoping for the best.
No, we would continue to use Github for the foreseeable future. If a FSF hosted Gitlab/Gitea/... instance came to be, then we would likely switch to that.
Also I am not exactly a fan of either the git forge or the mailing list work-flow. So I plan to add "competitive collaboration tools" to Magit that allow a project to continue to use either back-end while also allowing all or some contributors to use collaboration work-flows that are more tightly integrated with the development and version-control work-flows. https://github.com/magit/magit/issues/2972
The primary downsides of assigning copyright to the FSF that I see is the "waiting for papers to be signed" part and that some potential contributors will no longer be able to / be willing to contribute.
The FSF does not consider Github to be a suitable VCS host for its projects. Gitlab has, to my memory, a rating of "good enough", but only Savannah (which the FSF hosts instances of) is truly thought of as excellent, and it's what's used for all the current projects under their control.
If Magit were to become a FSF project, it would be made to migrate.
https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/packag...
https://github.com/magnars/dash.el
> All the Elpa packages are hosted on a Savannah instance.
That's the "publishing repository". You have to push there for a new version of your package to be published on GNU Elpa. But for most packages development happens elsewhere, and in most cases "elsewhere" is Github. Emacs maintainers sometimes commit directly in the Elpa repository (and package maintainers are expected to deal with the consequences, such as "two diverging mainlines"), but development happens elsewhere.
Is a model like this what you mean when you say "No, we would continue to use Github for the foreseeable future"? I guess if you're doing all the legwork, it won't be overly visible to other people who want to contribute. Still though...
It's important to note that when Richard said that Magit should be "part of Emacs", that really meant "part of GNU Elpa and/or GNU Emacs". If Magit is just made part of Elpa (which I believe is all that Richard wants), then that doesn't change much. We get protection at the cost of the assignment overhead.
But I already wanted to add parts of Magit to Emacs itself anyway. Low-level libraries that are useful beyond Magit itself, and which would benefit from being built-in. That includes some existing ui libraries but also new libraries I intend to write to replace old abstractions used in Magit, such as a file-handler for Git blobs and trees. Magit would benefit if other Git related packages used those, instead of everyone reinventing the wheel.
Once some code is part of Emacs itself it will be more difficult to change than if it were living in a separate repository. On the bright side, that would likely motivate me to write tools to make that process less painful.
I.e., it can only be called a low barrier to entry if you're willing redefine "entry" to be something other than "entry".
I've always wondered how you could "contribute" to an FSF project when it was clear that your "contribution" ended up as 100% their work.
Sure, they need to have some kind of legal process around enforcing copyright, but Samba seems to have done fine while accepting individual contributions.
> The package is already licensed under the GPLv3
Exactly. It's clear that the FSF has no interest in GPL code. Instead, they're interested in GPL code that they own. If they can't own it, they don't want to touch it.
For me, this is one more thing where the FSF has an attitude of "my way or the highway". I don't like it from large corporations, and I don't like in the "free" software world, either.
And that's ignoring other issues... most FSF projects I've used are bloated and over-designed. And Hurd? It's been 27 years, and it's still not ready for prime time.
As history shows, the Linux approach of "lower barriers to contribution" works a whole lot better than "make people jump through complicated hoops before accepting their code".
The copyright assignment papers you write aren't as unilateral as you might think. It doesn't say "this belongs to the FSF now, none of it is for you." They're fairly clear in the language and say that the FSF will defend your software and keep it free for everyone, including of course yourself. It's an exchange: you give them your copyright, in return they will use your copyright to forever defend your software from becoming non-free. So your software will always be available to everyone, including yourself. You also only have to sign them once ever; it's not like they require new papers for each contribution you make.
Oh, and you also get a sticker, I think. :-) Due to some legal finnagling, since you're signing your copyright away as part of a contract, you need to receive something of tangible value in return. I think that's why you get back a sticker (or maybe it was dollar bill, I forget).
I don't think the FSF has ever gone to court defending copyleft, but that's not entirely the point. A good weapon can be effective as self-defense merely as a deterrent. It doesn't necessarily have to be fired. Also, the FSF always exhausts all other means to bring about GPL compliance and considers legal action a means of absolutely last resort.
It means you are prohibited from using your own code except as how the FSF sees fit. That's what copyright assignment means.
So if you want to take your code and contribute it to a BSD licensed project? Nope. FSF won't allow that. Or use it in a commercial product? Nope. FSF won't allow that.
You can use it in a GPL product, so long as you keep the FSF copyright.
> A good weapon can be effective as self-defense merely as a deterrent.
Sure. And what about Samba?
Nothing prevents the Samba team from joining together collectively and suing someone for violating their license. The fact that other people have contributed small pieces to the code doesn't matter. A GPL license violation is still a violation of the code they own.
e.g my own project: FreeRADIUS. At this point, I've written at least half of the code. If there's a licence violation, I don't need anyone else's permission (or copyright assignment) to go after the violators.
So what, exactly benefit do I gain by submitting code to the FSF, and assigning copyright?
The FSF copyright assignment grants you back the right to do what you wish with your code, including sell exceptions.
> So what, exactly benefit do I gain by submitting code to the FSF, and assigning copyright?
Because they'll enforce the GPL on your behalf. I assigned copyright for my GNU project to the FSF for that reason: I have no resources for enforcement. Nor do most people.
> e.g my own project: FreeRADIUS. At this point, I've written at least half of the code. If there's a licence violation, I don't need anyone else's permission (or copyright assignment) to go after the violators.
If there's a violation with _your code_.
If someone uses a portion of your code you don't have copyright over, you have no standing. And _this_ is why the FSF wants full copyright over Emacs.
Then it's not my code, and I don't have rights on it, do I?
I believe so - as long as you license it with the GPL.
I can't edit my comment; sorry. I meant "your project's code".
Oh, wait. Perhaps if those contributors assigned their copyright to you under a very permissive contract...
> So you concede that it doesn't matter if you wrote over half the code?
There's just no way you can conclude that from my comments. I explicitely said I could enforce copyright on my code, even if it's only half of the project.
Again, the comment I was replying to said this:
> If someone uses a portion of your code you don't have copyright over,
Does no one see the logical contradiction in that statement?
YOUR code that YOU DON'T OWN.
Uh... then it's not MY CODE, is it? Is that really that hard to figure out?
I'll explain using simple examples, as people apparently aren't getting it.
* If a third-party contributor to my project re-uses his own code elsewhere, I don't care. It's his code.
* If someone violates copyright on a third-party contributors code, again, I don't really care. He's responsible for enforcing copyright on his code. I'm not.
* And if he's contributing code to my project, I'm pretty sure that code is integrated into my project, and is largely useless outside of it. So the odds of a violation of just his code are pretty small.
* If someone infringes on the project as a whole, then I own copyright to the majority, and I can enforce my copyright, independent of anyone else.
* [edit] And if I submit code to the FSF and assign copyright to them, then it's their responsibility to enforce copyright... because they own the copyright. And yes, I have no standing.
Is that clear? Can people please stop down-voting me for pointing out logical inconsistencies?
And can I enforce copyright for those exceptions?
Clearly not, because the FSF owns the copyright.
It's a lot more work and can be more tricky when there are many different copyright holders. For example, the GPL case against VMWare has hinged on proving that Christoph Hellwig in fact owns the copyright to the lines in ESXi that ended up in VMWare's codebase. He tried to provide git blame output, as I recall, but the court didn't consider this to be sufficient. The case got thrown out, although Hellwig has said he will appeal.
If Linux had a single copyright holder, there would be no need for git blame output and Linux could mount a more effective defense.
The FSF explicitly allows that.
> The assignment contract we normally use has a clause that permits you to use your code in proprietary programs [...] Although we believe that proprietary software is wrong, we include this clause because it would serve no purpose to ask you to promise not to do it. You're giving us a gift in the first place.
http://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyrig...
No, because the FSF owns the copyright. They have to do it.
Or maybe the program has mixed copyright (you and the FSF), in which case the same problem (and solution) applies for mixed-copyright software.
So how exactly, does assigning copyright to the FSF make anything better for anyone? It helps the FSF, sure. But everyone else (including the author) is negatively impacted by it.
In contrast, if copyright remains with the author, then the only thing the FSF would lose is the ability to sue for infringement of the code you contributed.
They could still sue for infringement of the code that they own.
The author assigning the copyright benefits from GPL enforcement---enforcement they likely would not have the resources to do themselves.
The code is still free software; the author can continue to use it in other free software projects. Do you have a specific situation in mind where the author might want to still have copyright (aside from a matter of principle) so we can focus on that for discussion?
So no, it's not about a specific situation. It's about the principle of the thing.
i.e. if the FSF can be founded on the principle of freedom, why can't I claim to believe in the principle of freedom too? And why do I have to give up my rights under the law, in order to give the FSF more freedom for themselves?
> The author assigning the copyright benefits from GPL enforcement---enforcement they likely would not have the resources to do themselves.
The logical conclusion of that statement is that copyright doesn't really matter, whether the license is GPL or not. Violators can ignore the copyright, secure in the confidence that the majority of people won't have the resources to sue.
So why don't we assign copyright for all open source projects to the FSF? After all, if the software is free, it doesn't really matter who the copyright holder is, right? And having someone who can enforce is is good, right?
Yes, I'm playing devil's advocate here. There are unstated assumptions in the FSF's position, and in peoples support of it. I'd like to clarify what those assumptions are, and why they're true (or not).
That's fair.
> i.e. if the FSF can be founded on the principle of freedom, why can't I claim to believe in the principle of freedom too?
They're founded on a principle of freedom as defined specifically by the four freedoms.
> The logical conclusion of that statement is that copyright doesn't really matter, whether the license is GPL or not. Violators can ignore the copyright, secure in the confidence that the majority of people won't have the resources to sue.
Yes there's a problem with the Copyright system. But the law does act as a deterrent because there is always risk involved in violating it.
> So why don't we assign copyright for all open source projects to the FSF?
The simple answer: they only accept copyright assignments for GNU projects.
They don't have the staff for enforcing others' copyrights, though; there's other organizations for that, like the Conservancy.
> After all, if the software is free, it doesn't really matter who the copyright holder is, right?
Sure it does: only the Copyright holder has standing in court.
Depends on the country. I signed mine with my GPG key in the United States and simply e-mailed it:
https://www.fsf.org/blogs/licensing/fsf-to-begin-accepting-g...
There's other countries, like Italy:
https://www.fsf.org/blogs/licensing/fsf-to-begin-accepting-g...
Sad to see this outdated info in the top comment.
Uhh, having to scan a printed and signed document is not much better than having to use snail mail.
When I see "full digital support" I understand that to mean I can use just a computer.
Many other projects accept a digital signature (basically filling out a form -- in a browser). Why isn't that sufficient for the FSF?
I still hate when I'm asked to do this but it's vastly more convenient than actually printing and scanning a form.
Wouldn't it make more sense to sign an agreement form with one's GPG private key rather than having to show a physical signature?
For that matter, why not have a blockchain assignment process? Given what a vanguard for technology FSF used to be it's a shame to watch it devolve at the pace of bureaucracy.
The FSF is very careful about the legal system. Signed paper contracts are a robust legal technology. When something important happens, they don't want a judge to be distracted by unfamiliar things.
edit: they also have digital signing in a couple of different forms.
https://www.fsf.org/blogs/licensing/fsf-now-offering-paperle...
Yes, it's a creaky, old system, but that's how it works: with paper and signatures and old, wrinkly men sitting on benches deciding your fate based on their incomplete understanding of modern technology.
As I mentioned in another comment, having an expert witness testify about public/private keys, PKI, "Web of Trust" should be sufficient in court.
Alternatively, passing legislation that gives a digital signature prima facie status in court would work as well.
All US jurisdictions already have such laws (in virtually all states, the same law—UETA—has been adopted, and E-SIGN is the federal law.)
Foreign jurisdictions may or may not have laws with similar effect, though I suspect they are pretty common by now, at least in the developed world.
[1] https://www.assuresign.com/electronic-signatures-vs-digital-...
Obviously, people selling centralized document storage and electronic signature services are incentivized to obfuscate this as much as possible.
If that's the case, then why does the FSF require scanning a printout with a physical signature (as one commenter mentioned) instead of opting for a digital signature of that document?
Does case law pertaining to the laws you cited support the assertion that digital signatures have the same legal meaning as an electronic or physical signature?
I dunno, ask the FSF what their reasoning is. Among the numerous plausible explanations is that they are concerned about laws in some non-US jurisdictions, or that they haven't expended resources examining other options.
> Does case law pertaining to the laws you cited support the assertion that digital signatures have the same legal meaning as an electronic or physical signature?
I didn't assert that case law made digital signatures equivalent to electronic signatures (in fact, I explicitly pointed to one way in which it is possible for a digital signature to fail to meet the similar requirements in UETA and E-SIGN for an electronic signature.)
> I didn't assert that case law made digital signatures equivalent to electronic signatures
You're correct; I didn't read your original response carefully enough. Also, the comment [2] that stated that the FSF does indeed allow for digital signatures (in the US at least) definitely settles the issues and answers my original question.
Presumably, lawyers and judges will understand state (notably, UETA, in all but three states) and federal laws (notably, E-SIGN) governing the use and validity of electronic signatures.
Are you erring on the side of legal caution? 'Cause I assure you the FSF is.
> If you use GPG, you can sign your assignment using a detached signature in the following manner:
> gpg -a --detach-sig ASSIGNMENT
> Where ASSIGNMENT is the PDF file(s) as you have received it from us.
> Then simply email the assignment, key ID, and signature file back to us at assign@gnu.org. Please make sure that your key is listed on a public keyserver.
And one reason for worry, historically, is that international law for paperless/signatureless contract enforcement is sort of a mess. Wikipedia has a page here with links to various nations and their requirements: https://en.wikipedia.org/wiki/Electronic_signatures_and_law
Not a lawyer nor speaking for the FSF. But it seems not entirely unreasonable to me that a conservative approach to copyright assignment would have picked the path they chose. It's just a hard problem.
If you want to ding the FSF, ding them on the copyright assignment requirement. Whining about the process seems a little too much to me.
Same case with orgmode.
i am a happy emacs and magit user. i contribute to emacs packages, and maintain a few myself (emacs-direnv, evil-swap-keys, evil-colemak-basics, evil-text-object-python).
i do all this DESPITE emacs being a fsf/gnu project. i strongly dislike the old-fashioned processes, the extreme stances on things that i do not consider problems, and last but not least, the very negative and non-inclusive community.
the remarks by rms that a magit alternative/competitor would be welcome is POISONOUS. advocating for an unnecessary community divide is destructive for the goodwill of many (potential) contributors to the emacs ecosystem (myself included).
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.
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.
Note that the GNU ELPA is considered to be part of Emacs, whereas MELPA is not. MELPA may also contain unlicensed software or otherwise non-free software.
Some statistics on that: https://emacsmirror.net/stats/licenses.html.
> The Emacs maintainers would not have to maintain Magit
That's not true. They would have to maintain it: deal with bug reports, deal with breakage due to upstream API changes in Emacs core. They wouldn't do feature development.
I used to contribute code to org-mode, so I know how this works. The magit team will make periodic releases, at which point the magit code will be copied over into the emacs code base. From that point on, the emacs maintainers are on the hook for any bugs or other problems occurring with the version of magit that they have included into Emacs. They'll have to deal with/triage magit bug reports received via the Emacs bug tracker.
RMS' opinion is taken very seriously in emacs development community.
Honest question, because from the outside he seems like an absolute grognard whose computing habits are so far removed from those of everyone else that he is incapable of relating to how the modern world does its computing.
Perhaps if he wants a good git interface in emacs, RMS should sling some code instead of giving the same entry-level ethics talk ad nauseam.
Why would that even matter? I find this attitude very puzzling and extremely worrying.
Of all the arbitrary metrics to decide whether to listen to and consider somebody's position "lines of code written" seems like an exceptionally poor choice.
I find your comment to be a good example of what is wrong in circles that like to consider themselves part of hacker culture.
It's not a matter of lines of code, but of contribution at all.
What does RMS enable the emacs project to do that they couldn't do without him?
What does he bring to the table?
I'm not being rhetorical, I mean it: why do people care what he thinks?
False dichotomy: The FSF can drop their requirement for onereous copyright assignments and instead trust the GPL to do its job.
It's not as great as magit, but it works (and it has you to learn very little).
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)
If you don't think that's a worthwhile goal, that's fine, but there is no need to blatantly misinterpret the context of the discussion here.
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
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.
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.
[1] This is my 'configuration', I haven't touched it in years: (setq package-archives '(("gnu" . "http://elpa.gnu.org/packages/") ("melpa-stable" . "http://stable.melpa.org/packages/") ("melpa" . "http://melpa.org/packages/")))
As far as I know, even Windows and MacOS have made moves towards implementing package managers AKA App Stores. I know iOS has it in spades. The Linux distributions have the problem of packet management figured out to their tastes.
Having a _completely_ different extension/package paradigm for every major and minor piece of software is not a user-friendly approach.
The central problem is that from an upstream author's perspective, distro package management is a nightmare.
Once upon a time, I tried maintaining Debian and RPM packages for my software. The process to become a Debian package maintainer was incredibly onerous and bureaucratic. Furthermore, dpkg is designed around the idea that you really should have exactly one version of each dependency across an entire system, for every piece of software that depends on it. And finally, the Debian stable version was usually years out of date.
RPM-based distributions had their own problems: Different, incompatible RPM features, dependency hell, etc. And of course, between dpkg and RPM, there were a half-dozen popular Linux distros, and two popular "distro" package managers on the Mac.
So I gave up. I distribute virtually all of my software using "language" package managers like bundler, npm and cargo. (And the rest as statically linked musl-libc binaries or Docker images.) These have top-notch support for dependency management, semantic versioning, and cross-platform builds. They're about a decade more advanced that dpkg or RPM for the things I care about. And if for some reason I need a GUI app, there's always Electron.
With cargo, TravisCI and AppVeyor, I can package a CLI tool for every popular system (including Windows) in a weekend, with automated cross-platform tests, and I'll rarely ever think about it again. And all my users can always get the latest versions, not three-year-old versions.
Anybody who wants to package my software for a distro is welcome to do so. I wash my hands of it all, and I'm extremely unlikely to provide any support.
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…
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.
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.
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.
- 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.
Unfortunately, there is a great deal of older Emacs Lisp code out there, much of which was not written to any perceptible standard whatsoever beyond "works on my machine lol ¯\_(ツ)_/¯". I say this not to disparage the people who wrote and released that code - indeed, a lot of what's in my own ~/.emacs.d, and which I use daily, comes of the same sort of origin. But either way, the Emacs ecosystem has a serious legacy code problem - something which, of course, you already know full well.
Unfortunately, there's no good single suggestion I can make here.
I can say that learning Emacs Lisp will make it easier to cope with nonsense like people unaccountably refusing to implement package configuration in terms of Customize, and with the occasional package where Customize legitimately isn't flexible enough to support everything that package needs to do.
But learning a whole new programming language, especially one that originates in a paradigm not familiar to most working programmers today, is a hell of a big ask as a prerequisite for effectively using an editor. My own experience is that it's well worth doing so - but if you're already frustrated with the nonsense you've observed, I can hardly blame you for deciding it's not worth your own while.
I can say that, well, it's just a matter of needing to invest the time to learn how to leverage this uniquely powerful tool, and not everything worth doing is easy - but, quite aside from being rude and insulting, such a claim has the same problem as the one I just talked about. I mean, I started using Emacs eight years ago, and it took me three or four of those to achieve something that can reasonably be called proficiency. That's a hell of a learning curve.
I can't reasonably say that the problems you're seeing don't exist, or result from error or misperception on your part rather than failure on the part of the ecosystem. (No one else can reasonably say that, either, and I misdoubt some have tried.) Among other traits, Emacs is older than the entire user interface paradigm that's become ubiquitous since 1985, and that makes many of its core metaphors seem either strange or strangely expressed. "Theme", for example, which everywhere else means a specific visual style packaged as a unit with a name, in Emacs means an entire set of Customize configurations packaged likewise. And then Emacs also, separately, has lately gained themes of the newer sort, with the same name referring to both! Of course it's a huge gotcha for the new user. And there are many more.
All I can say is: the Emacs core maintainers, and those of us building new packages for public release, are working the problem - doing our best to relieve Emacs of the manifold architectural and ecosystemic burdens which make it so easy for people to reasonably regard the platform and its partisans as relics of the past, and replace those legacies with a structure and culture sound enough to support Emacs' next 30 years. There's an almighty lot to do, and as with any free or open source project, never enough capable hands for all the doing. But as we can, we are.
- 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.
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.
It's a third-party package itself at this point, but I believe it's going to be included in Emacs before too long.
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.
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.
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...
I highly recommend that anyone using Emacs and git gives Magit a try.
> 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.
Things that are implemented as command line utilities or call such commandline utilities (which includes Visual Studio and Windows SDK!) tend to cause these cludges to become painfully apparent.
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/msg00...
although GPL is usually forward compatible with its newer versions I still wonder if that's the concern behind Stallman's opinion.
Also I hear plans are for it to switch to using libgit2.
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.
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.