Hacker News new | comments | show | ask | jobs | submit login
Magit 2.13 released (emacsair.me)
105 points by signa11 5 months ago | hide | past | web | favorite | 49 comments



My colleagues think I'm weird for using emacs, like i'm some 1980s retro fanboy.

I can access my calendar (org-gcal), my email (mu4e), git (magit), edit files on a remote server (tramp) and have a full code editor with pep8 syntax checker and repl all from a single application.

That same application also encompasses my file manager, my todo list, my pdf reader, my image viewer and if I really need it, a web-browser.


I already have email and calendar in the same application (outlook, thunderbird or just a web browser). What advantage does having my calendar and my PDF reader as the same application have over being two standalone applications? Same question for my editor and my email client - why do they need to be the same application? You need to press something to change from one to the other, it might as well be alt+tab (or whatever your OS of choice uses for changing the window in focus)


Aha, I can answer this one.

> email

One view of email is really reading and composing lightly formatted text with a "send" option. From this perspective, a text editor implementing email makes a lot more sense than an email client implementing text editing. Especially for mostly-text emails or emails discussing, say, code.

> calendar

This one is pretty workflow sensitive, but Org Mode encourages a very holistic approach of writing everything related to a project in one file, then parsing the file for dates and creating a calendar. If this is your workflow, again it makes more sense to implement from a text editor (because the "calendar" is really a parsed text file and maintaining the text file is what the user works on).

I can see a lot of utility in a stand-alone calendar program if the workflow you want isn't based on text, though.

> PDF

Has me stumped, although sometimes when I write documents that are going to be emailed as a pdf I'll use emacs and it makes a lot of sense to preview in place as I go. I must admit, the advantages aren't really there for me on this one, I prefer stand alone viewers.

> changing the window in focus

The secret is that many tasks involve 60% editing text and it then starts to make sense to implement the 40% in an environment where your heavily customised keyboard shortcuts all work. Eg, at the moment I'm writing a comment for a website - if I only viewed sites like Hacker News (mostly text reading and editing) then I would 100% end up doing it from emacs. Emacs falls down with images and navigating modern webpages though (haha modern; anything written in my lifetime), so I use a browser like everyone else.


> PDF

I can envision a scenario such as a REPL for PDF. If you write a lot of latex(or whatever format), it could potentially get converted to PDF and be shown right in your editor.


I write latex (and everything else) in Emacs, but use mupdf to view the results, since it's faster than the docview mode in Emacs. I use xmonad so it's easy enough to switch between windows or have them side-by-side.

For document modes (latex and markdown) I have F9 bound to a function which invokes `make` if there's a `Makefile`, `nix-build` if there's a `default.nix` or `render.sh` if that exists. It then runs `killall -HUP mupdf-x11 || true` to force any mupdf instances to refresh.

Whilst I like to do things like email in Emacs so I can have the same powerful editing capabilities with the same keymappings, PDFs can't really be edited so there's not much incentive there.


Maybe PDF-Tools could be of interest to you? You still cannot edit PDF files inline, but you can jump to the source code from inside the PDF.

Unfortunately, it lacks a continuous scrolling mode.

https://github.com/politza/pdf-tools


Switching applications via alt+tab does cause some distraction for me personally, as I have to _adapt_ to a new environment, because every application differs in its overall appearance and the way how I it is used. Whereas in Emacs you just use one application and everything else feels kind of the same.

Moreover, I don't think that you can do something like manage your to-do list and reference an email directly between different applications but you can do that inside Emacs. This way I don't need to first search inside another email application which email I'm referencing to inside of that to-do list item.

I guess at the end of the day it just boils down to use whatever fits the job perfectly, whether it's combining different applications or use everything inside Emacs. Whatever makes you more productive.


Emacs gives me smooth integration of disparate applications. My email, calendar, notes, todo, git, code, docs, cloud services, k8s, and everything else all work together. And if they don’t, it’s not terribly hard to integrate them.

I do wish there was a modern tool to replace Emacs. I thought it would be Squeak. Maybe it will be VSCode.


I keep hearing stuff like this on HN, just out of curiosity:

> my calendar (org-gcal)

Can org-gcal show calendar notifications? Can it access shared calendars?

> my email (mu4e)

Can you see and/or compose HTML mails?

> my pdf reader

Can you open and render correctly complex PDFs? Graphs, tables, images, tables of contents, maybe even forms, etc.?


You could cobble most of this together.

You could probably get notifications using org-alert.

Emacs does a reasonable job parsing most html including emails to text, but occasionally you may need to view in browser if it's very html heavy. You can compose html emails using org mode syntax with org-mime.

PDFs are rendered as images. So you have limited emacs functionality, but it does a good job rendering PDFs. Doubt you can do forms.


PDF-Tools lets you interact with PDF files in Emacs.

No support for retina screens on Macs though, unfortunately.

https://github.com/politza/pdf-tools


Not the original poster, but although a lot of Emacs users don't use HTML email, it's certainly possible to do it.

I wrote an Emacs package that allowed me to render my emails in that way Outlook does it (comments on top, everything HTML). I write my emails using markup, and then it's all rendered prior to sending.

I had people mention how pretty my emails were.

HTML emails also render fine, with all images as you would expect. Emacs does support online images.


How does this fit in with the Unix philosophy?


Very good question. A lot of the time "Write programs that do one thing and do it well" really means "I don't understand the difference between a procedure and a program." It is much easier to write procedures than it is to write programs, and it is often easier to turn a procedure into a program than vice-versa (emacsclient does the former especially well). Emacs is much better at "Writ[ing] programs to work together" - Emacs extensions usually work with each other without any extra effort, and deep integration is easy to achieve. "Write programs to handle text streams, because that is a universal interface" is the reason why Unix utilities do not integrate well.

To provide an example, I use mu4e[1] as an email client and reader, which uses a separate process running mu to operate on a Maildir. The Maildir is synchronized to multiple MDAs by OfflineIMAP, a command line program, which I set up to retrieve the IMAP passwords from an encrypted file using auth-source.el by execing emacsclient. With auth-source, all the credentials I need to access remote machines are in one GPG encrypted file, and Emacs takes care of handling communications with GPG, gpg-agent, and pinentry.

So Emacs provides both a better way to work with other standalone programs, and, via the emacsclient/server model, a better way for standalone programs to work with Elisp code.

[1] http://www.djcbsoftware.nl/code/mu/ [2] http://www.offlineimap.org/


It doesn't, because "the Unix philosophy", in the meaning implied by your question, is oversimplified nonsense. There is both utility and architectural value to be found in integrated user experiences. To throw out just a few small examples, such experiences done well may reduce context switching and/or build on the user's deep skills in the integrated environment (esp. w/ Emacs' and vim's text manipulation support). Likewise, there is immense utility in a scriptable, user-programmable working environment, especially for developer's tools.

Also note that Emacs and vim often comply with the oft-cited first bullet point (there's more than one!) of "the Unix philosophy" by reusing powerful yet single-purpose external tools under the hood. Case in point: git(this thread!), ag/ack, and so forth.

So please forget the idea that bullet-point-one of the Unix philosophy is a sacred tablet from some ridiculous Unixy religion. It's just an old, occasionally useful, architectural rule of thumb that applies in relatively narrow circumstances relative to the breadth of modern computing experiences and implementations.


Haha, sorry, I know my question was begging for that response. But even if you (and many others) appreciate tighter integration, others would appreciate the flexibility of being able to pick and choose what they like from emacs without being overwhelmed by what is an incredibly foreign environment.


You can use emacs to run elisp the exact same way you'd use a python script, emacs is pretty much an elisp shell. And there is no loss of flexibility, emacs doesn't reimplement everything from the ground up and most features are reliant on "shell programs". Dired for example is pretty much a sophisticated skin over an ls call if i'm not mistaken.


It does and it doesn't.

Emacs is a Lisp environment / runtime and is composed of many small functions. So in a way it is similar to the Unix philosphy, except it runs on Lisp.


It's like saying a shell doesn't follow the Unix philosophy because it runs other programs.

Each package does one thing, presumably well, is interchangable, customizable, and interops with everything else.


Don't remember where I read this quote, but it sums up the situation pretty perfectly:

> Emacs is a Lisp refugee in Unixland. It doesn't follow the Unix philosophy, it follows the Lisp philosophy. But it integrates...


Emacs (~1976/1978) roughy predates Unix and came from a very different tradition (and FWIW wasn't originally written in Lisp either)


But does it run in Electron?


I started using magit about 3 months ago - it's definitely one of my favorite parts of emacs now. I highly recommend it to anyone using emacs as a daily driver.


My favorite feature in magit is the ease of doing block and line level staging of hunks. It's normal in my workflow to touch on code unrelated to what I'm working on, fixing a typo here, a formatting fix there, refactoring or simplifying a statement that was unclear at first glance.

Staging those changes and commiting them right away if there are more working on the code base or simply staging them as a separate commits when the current task done makes it so much easier to keep a clean history - without having to do intermediary commits or stashing.

The feature is called git add --patch[0] in command line git but magit makes it so much more accessible.

[0] https://git-scm.com/docs/git-add#git-add--p


> My favorite feature in magit is the ease of doing block and line level staging of hunks.

Doing so is also easy using command-line git (add -p, commit -p and hunkwise reverts with checkout -p), the great thing about magit is it lets me do so:

1. with a bird's eye view, git's <x> -p shows hunks independent from one another and asks me what I want to do, sometimes I have no idea because I don't really remember what the context of that change is (or if there is one)

2. nonlinearly, similarly to above git's <x> -p goes through each hunk one by one, in magit I can go back and forth in the diff buffer if I need more info, there are shortcuts to process it linearly but it's a help (because that's a common case) not a limitation of the tool


Org-Mode being other other for me, its those two Emacs modules I use frequently, the rest have (for me) been superseded by other tools.


Org-mode, magit, and tramp are the three stools in emacs I keep resting on daily.

Really is nothing quite like the trio of the tools.


REPL integration for python, clojure, etc. is a huge win, too.


Ivy is the other thing that keeps making me come back to emacs.


I haven't tried ivy yet, got hot damn i love helm !!! I use it everywhere :p

and actually, I recently fell in love with dired, I literally use it all the time. I like it better than finder or the command line !!


how would you compare it to other git interfaces ? unless you used to use the bare git program in a shell.


It's the best git client I've used, comparing to git (CLI & gitk), PyCharm's builtin (even with the recent improvements e.g. hunkwise selection), tig, Sourcetree, gitx (various forks) and gitextensions.

The rebase and interactive stage/unstage are especially stellar.

It does get a tad slow on huge repositories, but that's the case of most git clients.

Despite using pycharm for $dayjob, most of my interactions with git are through magit. Basically the only ones which are not are annotations-browsing (IDE integration is too convenient there) and branch-switching ($dayjob repo being huge, switching major branches can take some time and magit completely locks up emacs + has no feedback, so CLI is more convenient)


I found my Magit was particularly slow on my OSX Aquamacs instance, and then learned that it was a known performance regression that apparently stemmed from Aquamacs not using vfork on OSX. A one-character source edit and a rebuild, and my Magit was pretty zippy again.


Emacs in particular, and a lot of Unix software in general, run very poorly in Mac OS X compared to Linux or OpenBSD. I had to look up what vfork was, and learned that it was deprecated in POSIX 2008. Not surprising. Mac OS X seems to be in perpetual beta mode, where it is always half-way behind on basic Unix features, and the other half are proprietary interfaces that get deprecated/broken/incompatible changes every major release. Switch to a better operating system.


”Switch to a better operating system”

Even if better Operating Systems exists, there are no better Deskop Environments ;-)


I agree, there is no better desktop environment than Emacs: https://github.com/ch11ng/exwm


I wouldn't consider a desktop environment that forces one to put up with useless transition animations even a good desktop enviroment.


That doesn’t bother me but to each their own.


Yeah, I had to keep rebasing on a rapidly changing branch a couple of years ago, and magit made it a lot less painful than it otherwise would have been.


It's far superior to the intellij integration as they have a generic "version control".

Magit is just so easy to use for discarding hunks / rebasing / etc. Quick, visually clear. I sometimes use emacs just to use magit when working with java on a fiddly git task even when I'm working in intellij to modify the actual code.


this should be sent to the magit team (even if its mostly Jonas these days I believe)


I think at least Jonas is aware of users like that -- there were some discussions on that concept during his Magit Kickstarter campaign[1]:

> Make Magit more accessible to non-Emacs users

> I think that Magit can be an excellent Git interface for users of other editors and IDEs. It would be a shame if its user-base continued to be limited to people who use Emacs for editing purposes.

> To appeal to non-Emacs users, Magit has to be made more accessible. Additionally I intend to provide simplified Emacs configurations and documentation that teaches just enough Emacs to be able to use Magit. See Magit for users of other editors for more information.

[1]: https://www.kickstarter.com/projects/1681258897/its-magit-th...


Having had tried most git clients (command-line, SourceTree, GH client, Kraken, Fork, IntelliJ built-in and many others), in my opinion Magit beats all of them to the ground.

I used to use Emacs (Spacemacs) as my main IDE - I have since switched to PyCharm/CLion but I still use Spacemacs+Magit as a sort of a standalone git client because nothing else gets close.

Oh, plus, it works beautifully over SSH/X11 in case you need to do any git stuff on a remote box and want a "UI". (terminal version is always there too, of course)


Magit is great. I found myself use the command line git less and less, and just get things done with Magit.

One problem I have is Magit slowing down somehow. I found out that it's because Magit spawns git and the Windows anti-virus kicks in, trying to verify the files it touches. It doesn't seem to be a problem when running git on command line.


I'm not sure about antivirus, but magit forks git a ton of times which is really slow on windows. You are often better off running it from inside a linux VM.


Off topic and rather personal question: I prefer Mercurial for my own VCS needs because (1) it's written in Python so I can hack on it or write extensions using a proper Python library if needed and (2) I find the UI better. But seeing how Git is becoming just as widespread as the English language in the software world, would it be wiser for me to abandon Mercurial for Git?


All of this is transient. Eventually someone will figure out a new paradigm (Darcs/Pijul-style patch theory?) and we'll all move on, like we did from RCS, and CVS, and Subversion. Or something will fall apart on the business side of GitHub, and we'll all go elsewhere. Like we did with SourceForge, CodePlex, and Google Code.

So, what are your goals? Switching to Git might give you access to more tooling, but if you're not presently feeling hindered by Mercurial, it's probably most wise to focus on making software, rather than chasing tools.

Similarly, if you're seeking feedback and patches from strangers online, then going to GitHub is your best bet, which implies forfeiting Mercurial (though maybe something like hg-git [https://hg-git.github.io/] could give you the best of both worlds?)


Thanks! I already use hg-git for pushing some open-source projects to GitHub, as it makes it easier for people to contribute patches and issues, and if I was looking for a professional software job, that's what people look at, among other things to evaluate you. That said, syncing up multiple branches can be confusing (as git branches are mapped to bookmarks, and mercurial branches don't have git equivalents, so if you have say a default and a dev branch in hg and want equivalent branches in git, you need to manually juggle bookmarks in hg).

My worry, more than my goals, is that would it be a major problem not having mastered git should I look for professional jobs? I do know git to some extent, but don't know common medium-advanced tasks.

WRT your first paragraph, there is a story on the front page of MS having agreed to acquire GH: https://news.ycombinator.com/item?id=17221527


Great !! I live magit, it's the reason I started mastering git. Finally I can use the log tree and diffs efficiently !!

I haven't figured out how to vc-rename multiple files or a folder. Currently I rename folders with dired or the command line. But I have to make sure to add the renamed files from untracked manually. I wish that were automated !




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: