I manage all of my email now in `mu4e`. I manage all of my notes, writing, TODOs, time tracking, invoicing in `org-mode`. For interacting with git, `magit` is simply amazing.
The most important thing is how everything works together. There is the obvious window, frame and buffer management, the kill ring, the searching across all open buffers. Less obvious is that while looking at email I can hit a few keys to create a TODO, schedule it for a particular date that will show up in my agenda, and will link back to that same email (which I can now move out of my inbox). Or, in my programming notes file, I can link to a specific commit for a project I'd like to come back to later.
And, the best part, which I've only barely scratched the surface of: everything is programmable. I can write an emacs lisp function to automate almost any part of my workflow.
Are there other good reasons to use mu4e? I'm an Emacs person, but not yet an "I do my email in Emacs" person.
Similarly, if I'm writing, any mail (or attachment) from the last decade is just a few key strokes and a search query away, without ever really taking my eyes off my current buffer.
I know there are other ways to accomplish the same thing, but that close link between my mail and the rest of my writing is the main benefit, for me, of having my mail in emacs.
If I wasn't using org, I don't think I would find it that useful. I'm not really a power user of mu4e. I don't have any complicated email workflows. I like that the search is very fast (for me, anyway -- I only have 100k emails), and, obviously, that my email is stored locally. I like that I can compose in Emacs. I also use two computers and I like that I can easily share configuration. My config, which doesn't do anything too fancy, is here: https://github.com/mjhoy/dotfiles/blob/master/emacs.d/lisp/i...
How good are OS X task management tools? Can they build/export custom reports and stuff?
There is only one big thing I find is missing to Org, and that's its lack of options for collaboration. After all any humans collaborating toward common goals would do best to have a common plan and a common way to track each others progress.
There are many people who use Emacs as their OS, its never been appealing to me, because I like the richness of other tools.
There is a question though, are OSes doing enough to make the integrated experience like Emacs something that's done system wide? I think Apple comes close to providing the set of things you want, but it still feels tacked onto the top, rather than more deeply integrated.
[[rmail:<mbox-path>#<message-id>][link text]]
No need to type that out, M-x org-store-link does that for me in any rmail buffer.I split my mboxes regularly, so I need to link them via mairix instead of rmail. I haven't set it up yet, but that is so trivial I guess it's already done.
If Org mode interests you this may be good advice:
- http://doc.norang.ca/org-mode.html
For the lazy, I have an emacs.d directory packaged with,
Norang's Bernt Hanson Org mode configuration, if you are
eager to try Org mode for the first time, try it out:
- clone https://github.com/ncouture/emacs.d
- replace ~/.emacs.d with the repo's root dir
- launch emacs
- read Bernt Hanson's Org configuration workflow
documentation (http://doc.norang.ca/org-mode.html)
If you start using Emacs and want some advice: There are many well-rounded pre-packaged Emacs
configurations available out there, they may be nice but
they will fool you.
Try them to get a feeling on how Emacs behaves with
other people, but don't stick around too long.
Build your own environment.
The best way to use Emacs is to make it work the way you want.For building a productivity system, I think it's much easier to build it in small pieces, week by week.
Take the org-mode advice with a pinch of salt. It is an incredibly rich and powerful package, but it's possible to get completely enveloped in org-mode, costing time that could be better spent improving ones skills elsewhere.
What I am saying is: emacs can simply be an amazing text editor / programming environment. It doesn't need to be complicated. You don't need to invest time learning kitchen sink frameworks. (But as a bonus, magit is the best interface to git that there is!)
I use it with both fastmail and gmail accounts.
The last major version, 24.1, was released in June 2012, so this represents over 4 years of development.
Among the highlights of this release is Xwidgets, which allows embedding GTK+ widgets inside Emacs buffers.
One such widget is WebKitGTK+, a full-featured port of WebKit for use in GTK+ apps. As a consequence of this you can now browse the internet and maybe watch some YouTube inside Emacs [0].
[0]: https://www.reddit.com/r/emacs/comments/4srze9/watching_yout...
Google "Termux emacs".
+ Is not cross-platform and never will be
+ Depends on X and GTK (bad!)
+ Substantially reduces the stability of Emacs due to GTK memory leaks and bugs (terrible!).
This is also the reason that many Emacs users compile Emacs without GTK toolkit support on Linux.
+ Introduces serious security issues via the webkit part, and no, host/browser process isolation isn't really doing anything to mitigate this.
With all that in mind, I'm wondering why they bothered including it in the first place. It will never amount (at least I hope so) to anything that can be reliably depended upon.
Given Emacs scope age it's sometimes easy to miss some very cool stuff. What's more, lots of things on Internet are outdated.
I will start:
- elscreen - you can configure it to get tmux-lookalike inside emacs. My config: https://gist.github.com/kozikow/58b46c45a2c24406dc7cde3f18610433
- hydra - create mini-menus in the mini buffer. Quick and reduces amount of shortcuts you need to remember. See previous point for example.
- apropos/helm-apropos - search across all variables/functions/commands at once.
- imenu/helm-semantic-or-imenu : get overview of all definitions in current file, including classes or functions. Works in majority of languages without special setup.swiper/ivy - I am already hardly locked in into helm. Even if some competing packages are more powerful (e.g. I used icicles at some point) or faster (e.g. ivy) due to big community helm have lots of community-contributed, helm-optimised packages. Type M-x install-package helm- vs ivy-.
2010~2011: learn vim because I wanted to slack off studying for exams
2012: addicted to vim keybindings at this point, tell people 'I can't use other editors without "proper" vim keybindings'
2012: also discover tmux, because i wanted the ability to use vim keybindings and copy things in/out of shell
2012-2016: dabble with emacs sproadically, put off every time due to my vim keybinding addiction. tried evil mode during this time, and to my limited knowledge of emacs, things like C-u not working (scroll up half a page in vim) tick me off and in different modes the vim keybindings would suddenly disappear which was annoying
2016.04: discover spacemacs, try again, things work quite magically. in addition modes like org-mode are working as I expect (no random de-binding of evil-mode), discover new modes like magit and projectile-helm which keep me in (spac)emacs. also supports screen splitting with (:vsp, :sp) which is great.
one thing i really like about emacs is i still use the shell (awk/sed/ag/etc) for a lot of tasks, and since i can use the shell inside an emacs buffer, copying-pasting out of them are incredibly easy, replacing my tmux usage.
next step for me is to get more proficient in emacs (i hope i can read emails, do simple browsing, etc) and then hopefully setup emacs from scratch for an exercise instead of relying on spacemacs to do everything for me
Why didn't you define your custom keys with global-set-key in Emacs Lisp? This is one of the first things an Emacs novice should learn and do.
I mainly use vim and what I normally do to use shell within vim is to open another window and run something like:
:r !some-shell-command
If I want to filter text within the buffer to the shell command, I can visually highlight it and run. :'<,'> !some-other-command
It's easy enough to undo the result and retry. I can edit the shell command opening the command line window with q: (which allows me to browse through my ex command history and use standard vim keybindings to edit, copy, and paste parts of the commands from the history that I need to run them again.I know you can do something similar in emacs using the M-! keybinding, but I'm sure that's not an orthodox way of doing things in that environment.
(setq search-default-mode #'char-fold-to-regexp)One caveat: I now use vim-mode in Emacs ("evil") which really has taken my Emacs experience to a new level.
Autocomplete even on a major IDE on a fast machine can sometimes still take an extra second to pop up. I can type faster than that, and I can certain snippet a lot faster than that.
Other things like all the different ways to write for loops (the types of iteration) I have snippetized so I can quickly generate the loop I need, which goes much further than autocomplete would.
I also recommend his book, Mastering Emacs [2]. I learned so much from that book. It's great for both beginners and medium/long term users.
I'm mostly an autodidact so I rarely buy technical books, but I wanted to support his efforts based on reading his blog before it was published.
[1] https://www.masteringemacs.org/article/whats-new-in-emacs-25...
Well, now you could write an OpenGL game that uses an OpenAL audio layer and displays in an Emacs frame, all in elisp. Because, why not?
I don't know why the 2002 implementation was reimplemented (without credit and apparently without understanding it properly).
Amusingly, I'm the opposite. Emacs to me is more consistent than the UNIX command line interface, and I feel Emacs satisfies the Unix philosophy better than the command line itself does.
https://en.wikipedia.org/wiki/Unix_philosophy
When people write "applications" on top of Emacs, they frequently come with APIs that let people utilize individual features. Part of the reason org-mode is so successful is its ability to leverage features from many other applications built on top of Emacs (mail, links, calendar, image viewing, etc).
Except for the few core Unix tools, most console applications in Unix do not provide as much flexibility through the command line interface. Nor do they come with APIs that let others build upon them.
To someone not well versed with Emacs, what I'm saying may sound crazy, as for many people, the extent Unix tools do provide these switches/APIs is very satisfactory. But it's not even close compared to Emacs.
This is why when I started my job and we work purely on Windows machines, I had no problem. I installed Emacs for Windows, and had access to much that I used to in Linux.
Visual Studio? What if you are on a Mac? Xcode?, what about linux? Code blocks?
And then what about email and tasks? Gmail? Outlook? Wunderlist?
And notes? Google Keep? Evernote?, wait, no Onenote!, but then they dont have a linux client.
What about file management? Total commander on a PC?, Forklift on a mac? and mc on Ubuntu?
What about sharing settings and shortcuts between all these across multiple OSs?
I use Emacs for all this and it works the same on every OS.
It's a portable OS/Lisp Machine.
I myself tend to agree with you, as a former Emacs user of maybe 10, 15 years. For the things I used to use Emacs for (C, make files, only crude version control integration, etc) I'm sure it'd still do fine. What I found, though, is that my workflow and habits changed, and Emacs couldn't keep up. Or rather, there are good-looking, easy-to-use tools that support my workflow out of the box, and having to spend a day futzing with my editor just to get the same workflow functionality lost its luster a long time ago. Visual Studio Code, for example, it does great intellisense and Git integration without having to do a thing. And I don't really mind having to use the mouse more, because, frankly speaking, I type a lot less than I think these days; I just spend less time on the mechanical act of typing lines of code than I used to, so keeping my hands on the keyboard is less important than it used to be for me.
So for me, Emacs is, as you said, a historical artifact. The tools I use today simply work better for how I work, and even though Emacs could be molded in just about any direction, I no longer feel like it's worth the trade-off. Tools like VSC are good enough, right now.
I'd rather learn one tool once, than re-learn text editing every time my requirements change.
That is what makes it an amazing programming environment.
- removing clutter (zapping toolbars, splash screens and the ilk)
- making very small tweaks to keyboard bindings so that it works more like Epsilon
I don't think that any of the Emacs improvements made over the last decade or more have done anything to my quality of life in Emacs. Rather, each release is more "what do I have to turn off this time?"
Fortunately, getting to bare-bones Emacs is not hard; with commercial editors it's often much harder to undo the damage of gratuitous "marketing checkbox" features. [I'm looking at you, Visual Studio 2013...]
There are packages such as "which-key" that can help by providing popup choices.
That said I've seen some people being more efficient in command line than I've ever been even with the most effective emacs extensions so ..
ps[1]: also higher level and consistency, I like to live in atoms, integers and lists and not regexp and file land
Emacs is an perhaps the most ambitious implementation of a layer above shells and /_/nix philosophy.
The problem I have with Emacs is the surface area feels infinitly large and some features can be buggy.
I choose to use both.
These things are not 'historical', they are the things which have been so permanent that after thirty years they are still useful.
Or does Emacs require a Cygwin / Ubuntu Subsystem?
[1] I installed msys2 which is less crufty than cygwin.
In fact, that's part of what I love about Emacs: for the most part I don't have to worry about learning how to do stuff on Windows, I just do it in Emacs.
As part of this, I want to get my .emacs under version control and shared between computers so I have the same settings everywhere. Is there a good way to do that with Emacs packages installed through MELPA/ELPA?
When you setup your `init.el` you can call `(package-install x)` and if the package is already installed it'll do nothing but just make sure it's there.
If you wanted the whole thing figured out ahead of time I recommend using Spacemacs[1]
[0]: https://github.com/railwaycat/homebrew-emacsmacport [1]: http://spacemacs.org
Spacemacs looks cool. I have so many years of emacs keybindings that I'd have to turn that off, but I really like the look of what they're building.
I wonder if it can handle dependencies like req-package https://github.com/edvorg/req-package
A bunch of (mjhoy/require-package 'package-name) are run on init, and if the package isn't present it's installed. This has worked pretty well for me for keeping my mac and my linux emacs in sync.
Look into use-package for a lot more control over how packages are loaded, as mentioned in another comment.
I've been using spacemacs at work, and while I absolutely love its layers, I really miss prelude. Something which combined the stability and sanity of prelude with the layers of spacemacs would be just about heaven on earth.
From the perspective of usage, while Emacs has a great deal of functionality, you need not use any of it that you don't want to. Indeed, Emacs is so shy and retiring about all it can do that you really need not even know about anything beyond text editing, unless you decide you want to.
The main drawback from my perspective has been interoperability. Org mode is brilliant, but when everybody else uses Evernote or OneNote, Org can't be the only thing you use unless you want to be that guy.
And using Emacs at all makes you likely enough to be seen as "that guy" anyway that it's worth not living up to the stereotype. I wish I were joking when I say that, in adult life, I've been the object of far more unfriendly regard as a result of my choice of text editor than as a result of my homosexuality, which I've never really been at particular pains to hide. It is easier, in the modern tech industry, to be gay, than to be an Emacs user. That's not Emacs' fault or that of its users, but it is real, and perceptions matter; if you're averse to the occasional funny look, this may be worth taking into account in your consideration of whether to try the editor.
What I don't use it for:
email/browsing - the web works better for me.
Scala/Java - IntelliJ.
Python - PyStorm.
file management and git - bash shell is fine.
But I'm wondering, why not provide the PGP signatures for the code over HTTPS instead of HTTP?
(Incidentally, if you just change the url from http to https (or use the EFF's https-everywhere addon) it works fine, the server does support it)