Emacs and Magit

Posted Jul 12, 2017 10:08 UTC (Wed) by aggelos (subscriber, #41752)
Parent article: Emacs and Magit

I'm probably missing something that's messing up the "user experience" for people, but I'm having difficulty seeing this as a significant issue. So I need to install an extra distribution (or MELPA) package for magit. I'm sure other people have as much use for magit as I have for gnus — perhaps they prefer to interact with git directly, use a graphical frontend or don't use git at all. Is there really such a pressing need for bundling it with emacs?

Emacs and Magit

Posted Jul 12, 2017 10:43 UTC (Wed) by dskoll (subscriber, #1630) [Link] (2 responses)

This. I use emacs and git and have never felt that I needed them integrated.

Emacs and Magit

Posted Jul 12, 2017 10:56 UTC (Wed) by nix (subscriber, #2304) [Link]

Quite. This is doubly bizarre given that the push these days is for *unbundling* things from the core and pushing them into ELPA. Are we doing all this massive amount of work just so we can avoid putting a non-ELPA package repository into the default config? That seems frankly bizarre.

Emacs and Magit

Posted Jul 13, 2017 22:52 UTC (Thu) by UnwashedMeme (guest, #98571) [Link]

When I use git on the cmdline I always `git add -p` so that I can review hunks being added to ensure what's going in is what I think it is. Frequently I see some tweak, stylistic fixup, malformed-whitespace or something that would be good to fix. I could pop back and forth between emacs and shell, or if I'm in magit i can tap enter on it takes me to the file with my cursor at that point. Aside from that magit also gives better hunk to hunk navigation and manipulation--like stage only selection from hunk.

I highly recommend you give it a try. I didn't think I had any problems with the git cmdline before, but magit does offer a slick experience above and beyond that.

Emacs and Magit

Posted Jul 12, 2017 12:22 UTC (Wed) by madscientist (subscriber, #16861) [Link] (3 responses)

Definitely agree. In fact like nix I would prefer more packages be unbundled! For example as a C++ programmer primarily these days, I find the version of cc-mode that comes with Emacs woefully outdated.

Whenever I restart Emacs (once every few weeks, when I have to reboot due to a new kernel update) I take a few minutes to run M-x package-list-packages and update to the latest versions of the external packages I use such as magit, irony, etc. I also pull the upstream version of cc-mode directly (using mercurial) to get the latest updates.

I've long wished that cc-mode was available via ELPA/MELPA rather than (or at least in addition to) being bundled with Emacs so that it would be simpler to get newer versions. I really have zero interest in tying a critical (and hotly developed!) tool like Magit into the Emacs release cycle.

I understand wanting to ship some version of Magit with Emacs, so that people have a great tool available "out of the box". But I agree with Stefan, this is all on Emacs to figure out.

Maybe instead of doing all that work to bundle or rewrite Magit, they could instead work on beefing up the packaging facilities even more: providing some kind of meta-bundle or tagging facilities where users could select "Git user", "C++ Programmer", "Python Programmer", etc. and have a coherent set of packages supporting those workflows show up as recommended, then tie that into the Emacs intro pages somehow so it's easy and obvious for new users to get started.

Emacs and Magit

Posted Jul 12, 2017 13:04 UTC (Wed) by drag (guest, #31333) [Link] (1 responses)

> providing some kind of meta-bundle or tagging facilities where users could select "Git user", "C++ Programmer", "Python Programmer", etc.

Spacemacs does this with their 'Layers' Feature.

http://spacemacs.org/layers/LAYERS.html

It provides a collection of packages and configs that are community-sourced. It makes it easy to get python support for a language that you are not familiar with, but still allow you to apply your own packages and configurations on top of it if you like. This really cuts down the time it takes to setup things like python support.

Spacemacs is based originally around Evil mode, but there isn't any reason why you can't use it in Holy mode.

When it comes to updates/copying the config around the important thing is your .spacemacs config. So when you setup a new workstation, you copy over the .spacemacs config, install emacs, pull down spacemacs git repo and then it will take care of the work of pulling down the packages from epel, melpa, etc. The spacemacs default page also has links for updating spacemacs and packages as well as diffing your .spacemacs file with the latest version.

Emacs and Magit

Posted Jul 12, 2017 13:06 UTC (Wed) by drag (guest, #31333) [Link]

> It makes it easy to get python support for a language

I guess I am not fully awake yet. I meant to say 'It makes it easy to get Emacs support for a language'

Emacs and Magit

Posted Jul 12, 2017 15:44 UTC (Wed) by NAR (subscriber, #1313) [Link]

This seems to be similar problem to the one with applications and bundled libraries. The user might want to use different (combination) of libraries or extensions than the distributor expects (and supports). What if there's a (big scary) security hole in magit?

Emacs and Magit

Posted Jul 12, 2017 12:56 UTC (Wed) by epa (subscriber, #39769) [Link] (3 responses)

I think it does make a difference if the package is included and maintained as part of Emacs. It will be covered in the Emacs manual, and kept up to date with future Emacs changes. More importantly, by being part of standard Emacs it becomes somehow perceived as standard, and this in itself encourages people to use it. This is a social rather than technical consideration.

But don't forget RMS's underlying reason: in order to enforce the GPL on GNU software it helps to be the sole copyright holder. That also helps if you want to relicense it later. This is an ultra-cautious approach and more than is necessary for most users or authors of free software, but I can see why the FSF does it.

Emacs and Magit

Posted Jul 14, 2017 20:30 UTC (Fri) by giraffedata (guest, #1954) [Link] (2 responses)

You almost, but not quite, said another reason for preferring that something be bundled in Emacs, copyright FSF, to having something distributed separately with copyright owned by others: The code has more power that way to entice other people to distribute free software.

That is as much a goal for FSF as is providing useful software itself.

Emacs and Magit

Posted Jul 14, 2017 22:17 UTC (Fri) by sfeam (subscriber, #2841) [Link] (1 responses)

I totally do not follow your logic here. Why would the co-opting of already free software by requiring copyright assignment to FSF "entice other people to distribute free software"? If anything it would seem like a cautionary example in the other direction.

Emacs and Magit

Posted Jul 14, 2017 22:37 UTC (Fri) by giraffedata (guest, #1954) [Link]

Sorry for being vague.

The idea of copyleft is that you give someone code in exchange for him giving code to the world. Though he might have wanted to develop an entire software package and keep it to himself, he is enticed by the offer of a bunch of otherwise free-beer code to use that code as a base, add his own, and give his part to the world as free software.

That copyleft works a lot better if the copyright owner actually enforces it, and doesn't change his mind about using it for that purpose.

The FSF is more likely than pretty much anyone else to enforce copyright on its free software.

And many people trust that the FSF will always use its copyright this way, whereas some other random group of developers might decide later to license the code without the contribute-back condition.

So that's why some people might think having something like Magit part of Emacs (ergo owned and distributed by FSF) would be better than having it distributed by someone else.

Emacs and Magit

Posted Jul 12, 2017 16:46 UTC (Wed) by ikm (guest, #493) [Link] (1 responses)

I guess what the article tried to point out is that requiring paperwork to incorporate something to Emacs is "not a winning strategy" for the project, without implying that installing that one specific package in question separately is hard.

Winning strategies

Posted Jul 12, 2017 16:53 UTC (Wed) by corbet (editor, #1) [Link]

That's part of it, but the part about going into competition with an established and successful project because you feel the need to own the copyrights is even less of a winning strategy.

Emacs and Magit

Posted Jul 21, 2017 14:57 UTC (Fri) by tvaughan (guest, #117732) [Link]

This. I'm a 20+ year user of Emacs and I absolutely love magit. The two are totally indispensable to the work I do and yet I see no need to bundle magit with Emacs. I've also done a sizable amount of Python development and having python.el bundled with Emacs has been problematic, especially when trying out something else, like elpy or anaconda-mode. I also do a lot of Clojure development and it has never occurred to me that cider should be bundled with Emacs. But yes, if you aren't using Emacs magit could be reason enough to check it out and you're definitely missing out if you're using Emacs without magit.

Emacs and Magit

Posted Jul 22, 2017 20:52 UTC (Sat) by debacle (subscriber, #7114) [Link]

On Debian it is just: <tt>$ sudo apt install elpa-magit</tt>.