How far are we from Magit becoming part of Emacs?

[deleted]

It *is* a part of emacs, for many of us, already. It's not signed over to the FSF and in the main tree, but if it was it would make exactly zero difference to me and how I use it, and would slow development, so doing so would be entirely pointless. I don't get the "we need a git interface in emacs" argument. Why? You have a plugin model, and hugely popular plugins? Why the desire to make core a kitchen sink out of boredom? Going out of your way to turn a monolithic codebase into an even-more monolithic codebase just so you can avoid installing a package once every six months seems goofy.

[deleted]

I completely understand that. But the point is not that. If people are wanting something in an editor and the project is living its own life since 2008 or 2009. Then it is completely justified to make it part of the editor. Like we did for org mode and many other useful packages.

Why is this a problem that cannot be solved by having a "recommended packages" link on the Download page?

I don’t completely disagree. But if we can have package X then why not Y. In a code editor, from my perspective, magit has more relevance than org.

Yeah, that's the kitchen sink argument. "We already made one mistake, why not two"

Agree. But then we may have to store number of downloads etc. Otherwise on what basis we will recommend.

Yup. Worse was semantic. 50% of which is ingested but other half is completely unmaintained.

Why does Emacs need to ship anything at all? Nothing should be spared, take out dired, org, calendar, calc, everything except the C core. Let the user figure out what elisp they should add to their config /s

> If anything, I'd love for straight to be part of core Emacs. That's a non-goal for straight.el

[deleted]

To be honest, I think it would even be good to remove things from core. It has pretty redundant things like the multiple template libraries (tempo, skeleton), the various mail clients and feed readers (gnus, rmail, newsticker), IRC clients (ERC and Rcirc), etc... I mean, it's nice to have features built-in but I don't think there's a need for more than 1 package providing the same thing. Imo, built-ins should remain minimalistic enough to make maintainance manageable. I'm thinking mastodontes like Gnus and Org would be better as third party for example. I'm not sure if Magit should be in core. Vc.el is already there and it's much better than people give it credit for. Big packages like Org and Magit are probably better off having their own release cycle. I know Org already has its own separate repo you can use to get more recent versions but why keep it builtin? I'm of course asking questions I already know the answer to: Emacs has a long history so this kind of cleanup would risk breaking existing workflows for people who only use built-ins. Built-in features also mean stable features (as unchanging), which can be appreciable, though I'd argue it also means stable bugs in some cases. Unmaintained buggy features should probably be either removed or brought up to speed. Which also raises the problem of limited workforce... Etc etc.. Not that straightforward in the end.

2017...

I’d rather vc-mode keep gaining features. I love Magit but the more I use vc, the more I appreciate it and if by chance I have to use another source control system, I’m covered.

Hopefully it never happens. The whole point of modularity is to separate modules from the core engine.

I know you joke, but would it really be that bad to have a minimal distro, upto a maximal distro? A pick and choose process?

To be honest, that would not necessarily be a bad idea. Not that I really care, but I can't say that I see a major need for having tetris, a chat bot, and several mail & IRC clients included in every emacs instance. I made sense before the time of the ubiquitous domestic internet connection – but nowadays, especially since emacs officilay features a package manager, those are mostly bloat; not very bloaty, but sill bloat.

I really like VC. But the thing is that it is difficult to build a common interface for a variety of VCSes. This is one of the intents of VC. But we are already seeing VCS specific commands in the package. So now I am kind of convinced that it would have been better if there was one package per VCS. I also think that users of a particular VCS know better how something should be done. So they can contribute easily to the package without knowing much about the common superset.

I completely agree that any software should be built like that. And most software are built like that today. But that doesn’t mean that we can’t ship a module with the whole bundle that competes with several IDEs

> Yeah, that's the kitchen sink argument. "We already made one mistake, why not two" They aren't mistakes, though.

> Hopefully it never happens. It *will* happen.

Actually, I propose that the core includes only the build scripts. And maybe the docs. Everything else can be downloaded and built from dedicated repositories outside of the core.

> would it really be that bad to have a minimal distro How hard do you want users to labor before they have a functional Emacs for whatever jobs they need Emacs for? I say installing Emacs should be all they need to do.

> But we are already seeing VCS specific commands in the package. That's mainly due to lack of resources and/or bug reports. VC commands should be VCS-agnostic.

> That's mainly due to lack of resources and/or bug reports. That I completely feel ashamed of. I am shamelessly using Emacs, without contributing much. > VC commands should be VCS-agnostic. I use VC as well as Magit. Mainly for the tasks where Emacs manual suggest using CLI, I use Magit. And I feel that there are many VCS specific commands, those will be difficult to implement in an agnostic way. But yes, there can exceptions in those cases.

It's one of the first plugins I install but it should NOT be part of Emacs. Git is developped independently and so should the integration. There are also people who don't use Git in Emacs. Why bloat their computers?

> I feel that there are many VCS specific commands I don't think "many" is correct. Maybe a few.

This argument is convincing. My only point is that Emacs already has support for git. But the UX is not as good as Magit; due to lack of resources. Ironically people contributed outside Emacs to polish Magit. But they didn’t do so inside Emacs to improve the existing VC subsystem. What could be the cause of this? Why they preferred to not contribute directly to Emacs.

Definitely you know better here. Actually I just use git now a days. Perhaps I should explore more of vc and report missing features.

Sure, will be appreciated.

If I recall correctly its the second most downloaded package on MELPA (with the first being a library package) so its basically part of Emacs, yes

Sure, I do also think that vanilla Emacs can afford to be a lot leaner and lose a lot of the unnecessary redundancy. But the way I see it, the built-in tutorial and manual should be the only thing new users need in order to be productive and comfortable in using Emacs (ideally of course, the work to make this a reality is never truly done, just less not-done). The idea that the mere existence of end-user elisp code and 3rd-party packages obviates the pressing need for vanilla Emacs to continue to improve and be worked on strikes me as counter-productive. It's shifting the work of cultivating and maintaining useful software to downstream end-users and 3rd parties. When taken to its extreme, the logical conclusion really is: why should literally anything good and useful be part of emacs? After all, it's easy for users to just install 3rd party packages. Also emacs is all about configurability and customization. Users aren't going to have the quintessential emacs experience if they're not having to write elisp to fill in the serious, gaping productivity shortcomings in vanilla emacs.

It's a few megabytes of code and object files for a lot of useful functionality out of the box. Why shouldn't it be in the core? We're not in the 80s anymore.

> I completely feel ashamed... shamelessly using Emacs, without contributing much. No one should feel ashamed taking advantage of others who wish to be taken advantage of, i.e., anyone who works anonymously for free. You *should* however be ashamed for patently disingenuous professing shame. Cutting the FSF a hundred bucks which merely powers someone's laptop for a year is a few clicks on their website.

As a programmer by profession I could start a rant against either personal issues between people or "bit-rot" (the code is beyond repair and little to no incentive to fix it). Open source projects are often created by people in their spare time. Some of them are self-taught beginner programmers (who even might not be involved in software engineering at all at their daily jobs!) and therefore their code can be hard to work with or their coding practices are subpar at best. This is less of an issue with Lisp-y languages but still happens. You also can't expect much of soft skills from programmers either, especially the young ones. It can also be hard to contact the original author(s) or their view of what the project should look like in the future is different from yours or the community's (that's e.g. the reason Mate desktop environment exists - at home I use Plasma but at work we have Mate because none of us could stand where Gnome 3 is heading towards and we can't have Plasma for corpo reasons). I tried to join open-source projects in the past to "give back to the community" since I am a heavy user of open-source SW. I walked away from all of them. I have my fair share of commits into open-source projects which I was paid for and the projects were professionally managed by paid specialists, that was much better an experience. But I had to do all the job I normally do at work including unit tests and documentation, maintenance tasks, bug fixes, you name it... all the things which are boring and therefore often neglected in open-source SW. In voluntary work many people simply prefer to have their name associated with a new shiny feature rather than automated test cases, bugfixes and documentation. Hard to blame them... There are many reasons why people don't fix the old code but write completely new one. Some legit, some less so. Unless you pay the people you can't really force them to do so.

Will this happen?

Last I checked Magit depends on `dash`, a package that ignores the global namespace prefixing convention. This is good reason not to include.

>But the thing is that it is difficult to build a common interface for a variety of VCSes This is *technically* true, but there's a ton of common ground between VCSes. My first Emacs package was an integration over TFVC (Microsoft's TFS source control, from before they recommended Git) and I wish I had known about vc-mode back then to make that package play nicely with the built in. Terminology is different, but the actions are 75% similar: commit == check-in, shelveset == stash, branching, syncing to a server...and those actions by far are the ones used more often.

One more counterpoint here, org-mode has become a part of Emacs at some point and the versions sometimes slip apart, so when using a package that depended on the newest version I had to sometimes deal with choosing between the inbuilt and basically always just had to disable it and download the external version if I wanted the solution to be In any way long-term.

Currently, I edit a lot more org files not in git than files that are in git. So for me Emacs is not primarily a code editor. But as an org user I don't care about the built-in org. Every few days I update to whatever is the latest state in the repository. In order to get the newest features and bug fixes. As I do with magit. I saw a value in curated versions and built-in features in the early 90's last century, when I had to get Linux distributions on CDs or DVDs because the only way to get something off the internet was knowing someone working at a university. I'd rather see the Emacs developers pushing forward the core of Emacs, so people don't feel the need to create something like f.el, s.el and dash, than to put work in packages that are already maintained in their own project. So I disagree with the mail from RMS from a few years ago. Don't use precious resources to clone magit because users like it and it has no compatible license. Improve Emacs and elisp. That would be my wish. But as I can't order volunteers that I don't pay around: I'm really happy and grateful for every developer and creator who does anything and then letting me use or consume it. So I'll take every version of Emacs I'm getting, regardless of what the devs decide what packages should be built-in or retired. Those who put the work in get to decide.

I don't know if installing packages has that much of an impact. At least for me configuring and learning to use the packages is most of the time more work than installing them. It wasn't easy before the package managers. But now adding `(use-package gnus)` to my `.emacs` would be realtively easy compared to configuring Gnus as my mail and news client.

I would pretty strongly disagree. I think the biggest reason to include a package with emacs should be library support. When there needs to be a standard for others to use its best to have it as part of the editor so it's there and people can count on it being maintained (enough to work) and remove the guess work. Org most definitely did this and has since done this. Having it become part of emacs has only solidified this. It's used everywhere in emacs and having it as a guarantee means that even built in packages can rely on it. For magit it doesn't really offer much library utility when we already have transient and VC giving us both the interface and a version control library to rely on. Not to mention a more abstracted library at that. What would be the benefit other than having it out of the box for new users who probably won't be using it the moment they startup emacs.