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.
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.
To provide an example, I use mu4e 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.
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.
Each package does one thing, presumably well, is interchangable, customizable, and interops with everything else.
> Emacs is a Lisp refugee in Unixland. It doesn't follow the Unix philosophy, it follows the Lisp philosophy. But it integrates...
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 in command line git but magit makes it so much more accessible.
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
Really is nothing quite like the trio of the tools.
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 !!
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)
Even if better Operating Systems exists, there are no better Deskop Environments ;-)
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.
> 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.
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)
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.
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?)
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
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 !