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.
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.
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.
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.
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.
Unfortunately, it lacks a continuous scrolling mode.
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.
I do wish there was a modern tool to replace Emacs. I thought it would be Squeak. Maybe it will be VSCode.
> 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 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.
No support for retina screens on Macs though, unfortunately.
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.
Each package does one thing, presumably well, is interchangable, customizable, and interops with everything else.
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.
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.
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/
> Emacs is a Lisp refugee in Unixland. It doesn't follow the Unix philosophy, it follows the Lisp philosophy. But it integrates...