Magit 2.13 released

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.

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.

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.

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.

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.

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/

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)

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.

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.

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.

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.

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)

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)

> 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

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