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)
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.
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.
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.
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.
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.
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.
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.
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.