It is difficult to even describe a productive hand tuned to fit the individual Emails setup compared to standard.
Here are some of my favorite Emacs things:
Helm + Projectile. Helm will fuzzy complete almost anything in Emacs. Projectile is project management. Together get to any Git repo and file there in very quick. Helm is an option to compare to IDO. I rarely use IDO due to Helm.
Magit, widely regarded as a good Git UI. Using is believing. Better than command line or most GUIs for me.
Various editing nodes are good enough (Python, Lisp of course, Markdown).
Org mode is it's own beast, but if you like outlines and productivity tools Org is very nice. I use it, not extensively. It holds my todos and meeting notes and makes it easy to ha e very complex notes in one doc.
Basic text editing. I think Vi has some things it does better than Emacs here, but it is still very powerful and rewards learning the finer details.
Realizing you are in a Lisp machine. A calculator is no further than your Emacs window. Learning to hack Lisp and elisp is its own reward.
I think the time spent learning it is worth it. I think the math checks out in terms of efficiency. I also know Emacs is not going anywhere. Same with Vi.
There is much more to it all, but these are things off the top of my head. There are many smaller things that connect up how I work via Emacs... But there is a lot to it.
I love Emacs. But there were no good multimodes 3 years ago. And autocompletion and hints are often a bitch to get working on things which are not C or C++.
The moment you start editing files containing more than one language you're pushed to use a dedicated IDE. And then you discover the joy of "good enough". No need to tinker with config files to get the perfect setup: it works good enough to give you a productivity boost out of the box.
Really? I installed Spacemacs and everything "just works". Python, Javascript, Clojure, and Ruby only required to add the appropriate layer to my .spacemacs and restart the editor. Autocomplete, jump to definition, find usages, refactoring, documentation lookups and hints, etc. Spacemacs has been equal to or better than IntelliJ, Eclipse, Atom, VisualStudio Code, Kate, or Sublime out of the box.
which-key being integrated everywhere has made discovery the easiest of ANY editor/IDE I've used. Imagine if there was a consistent place where the menu would pop up if you faltered any key combination. If I'm trying to go a git command in Android Studio (InteliJ) and I forget the command, I don't get part way through and see a popup list of contextual actions. I'm left to move my mouse to the right place, click, and then hope to find my git action in the menu I picked.
More common is the unified way that helm makes dealing with files (you can find similar things in Sublime / Atom / Vim distributions using Unite (or whatever they used these days)). Even though the better editors have this, it's not universal and still a differentiating factor for usability and consistency.
Spacemacs integrates Magit by default. Magit is the first version control interface complete enough that doesn't make me immediately nope out into a terminal for proper git commands.
In my primary projects, I need to edit XML, Clojure, YAML, SQL, Java, Makefiles, and Python files. Spacemacs handles syntax highlighting, autocomplete, refactoring, repl connection and evaluation (where available), project management (makefiles and maven support), and documentation lookups.
I came to the same realization about Vim about a year ago. I've used Sublime and Vim/Nvim extensively, and I've spent at least a few hours in Textmate, Emacs, Spacemacs, Notepad++, VS Code, and Atom as well.
All of those text editors above have some excellent and unique redeeming qualities. But at the end of the day their actual language support tends to be weak.
Now I do Python work in Pycharm, R work in Rstudio, and SQL work in whatever IDE goes with my database engine. I use Nvim as my system $EDITOR but at work I'm using it less and less often. I love it and I'll never give it up, but it's becoming more of a hobby tool than something that helps me get things done.
I'm hopeful that https://github.com/Microsoft/language-server-protocol will decouple some of these concerns. We've built support for it for our DSL, and it's pretty great so far (esp in VSCode). Emacs LSP support is still pretty slow, so I don't use it when in emacs at present, but it feels like the right direction for getting good language support into editors.
I've gone pretty deep into both vim and emacs over the years, and so it always hurts a little when something like PyCharm comes along, and it works better, and does more out of the box than any finely tuned emacs/vim setup (which often take significant time investments).
You should really give the IdeaVIM plugin a try. I use it in several Intellij editors, PyCharm included, and it is terrific. It has a few quirks and discrepencies from VIM, but it is a far better text editor than the editor that comes stock in any other IDE.
I use vim for everything, but Intellij (because we have the licenses; I mainly use it for Python at the moment) has my attention. Wish I had more time to learn it; it has been a couple of months and I still don't feel really comfortable. But the capabilities actually make a difference.
Vim is never going away for me; muscle memory, if nothing else, ensures it will always be the most efficient way for me to type text and I spend most of my time in the terminal anyway. And as nice as it was when it was my go-to for everything, there are times when a special purpose editor has a place.
I mean, I use autocomplete for work in python, ruby, golang, C/C++, JavaScript, coffeescript, CSS and probably more in enacts.
The trick is the setup, but I've only had problems with minor edge cases (like coffeescript 2). Either way I'll spend an hour and use Elisp to fix it. Really nothing I've found is even close to as robust
I've been using spacemacs for nearly 2 years now and autocomplete has mostly always worked right out of the box after installing the corresponding layer. I rarely even need to reboot Emacs.
I'm reading this on Spacemacs right now! It's excellent - it removes a lot of the initial configuration investment required to be productive, while letting you customize as deeply as you want if that's necessary. Plus, it has vim keybindings out of the box ;)
Evil mode itself allows for keyboard macros. I do believe there are ex-mode things that won't work but most users never even touch this stuff (i.e. if you press Q in vi/vim).
Spacemacs by extension integrates evil mode entirely, so keyboard macros are available.
If you think vi does basic text editing better, try Spacemacs! I switched over recently (the emacs pinky was real...) and I've really gotten to like the vim-y experience (although now I get really frustrated when I vim on a server and the search doesn't work like Spacemacs search).
I used Spacemacs for a while, but switched to a custom configuration with evil, general.el, and which-key. Spacemacs was excessively slow and I also often ran into strange bugs.
I did the exact opposite, I got tired of vanilla Emacs and managing my custom configuration. Then I found about Spacemacs and never looked back.
I didn't get any strange bugs or slowdowns, but then I am using the `develop` branch which is going to be the upcoming .3 release. I also have a few dozen layers installed.
I would miss Spacemacs' layers way too much if I reverted to vanilla. Its integration of evil-mode is also fantastic, something I don't want or need to recreate.
The upcoming .3 release will support a custom package archive. A lot of the bugginess in Spacemacs is caused by frequently pulling 100+ bleeding-edge MELPA packages.
same issue here, spacemacs is a very nice package but I just have no idea how to fix it when ran into bugs, I started to build my own .emacs.d since last month.
If possible, swap Caps Lock with Left Control like it was on the old Sun and Apple keyboards. Having Control on the home row makes it much more comfortable typing common left-hand-only keyboard shortcuts like C-x, C-w, C-a, C-q, C-s, C-e, C-v, and C-z, as well as chords such as M-C-v, M-C-c, or M-C-d. On Windows you can edit the scan code map in the registry to swap the mappings, although this sometimes breaks laptop buttons that are implemented as USB HIDs (e.g., secure attention keys on tablets that work by sending the Control, Alt, and Del scan codes like a real keyboard would). On Macs I also swap Option and Command, since Option usually gets mapped to Left Alt in terminals and in Emacs.
On FreeBSD the syscons driver lets you edit the keyboard maps in a text file. I don't know how to do it in newcons. I forget how to do it in Linux. If all you care about is X, you can also use xmodmap (IIRC).
in OSX, how did you swap opt and cmd? i went through hoops to do that and finally managed to do it without replacing opt/cmd os-wide using cmdkeyhappy.
Before OS-X would let you do that, I took my PowerBook's keyboard out, cut the trace and redrew the traces to connect the CapsLock key to the Control traces. :-)
Now it's done by simply going to System-Preferences=>Keyboard=>Modifier Keys
Helm-ag is great too. I tend to bounce between "helm-projectile-find-file" and "helm-projectile-ag" depending on if I'm grepping or looking for a file name. Fuzzy search makes those terrific. Then within a single file, "helm-swoop" is great. And then "helm-resume" to bring up my previous search.
For another, related approach, there's counsel-ag, and the various other counsel/ivy/swiper tools. I've personally switched to those from helm, and have found them to be both faster and much more intuitive to use than helm was.
I haven't been able to use magit. I've tried and tried, but it's too slow for me. It literaly takes 30 seconds just to magit-status the project on a windows machine. So I'm using vc and git-gutter+ for this job. You can see the changes, stage them, view the log, annotate your file (what commit modified each line), commit, ammend, etc.
I've never tried it on Windows so that might be the issue. Windows is still somewhat a second-class citizen wrt Emacs and Git. Not as bad as is the past and getting better every day but still noticably worse than on a Unix.
I've aliased magit-status in my shell and it spawns a new Emacs instance (no demon) and magit in a few seconds.
Magit is really amazing. Recently learned that it optionally supports saving changes to git when saving a file or doing some destructive git operation, by using the magit-wip modes. Makes git much safer. https://magit.vc/manual/magit/Wip-Modes.html
I used to use Spacemacs, then switched to vim (better C++ support without ctags, multimodes, easier to get running on remote boxes) -- however I still always use magit as a separate git client, I haven't seen any other git client, GUI or terminal, that gets even close.
The first time I got introduced to Emacs, I hated it. Who would like to read email inside a text editor with non-standard keybindings?
I got it all wrong. It's not an editor, it's a text-mode virtual Lisp machine.
The Emacs ecosystem has matured a lot lately. It has two applications I adore. Org, something impossible to describe in a few words, and Magit, the perfect Git porcelain.
Plus it has 3 pretty darn good email clients (Notmuch, Gnus and Mu4e). And some great extras: Dired, Calc, Eshell, Erc, PDF Tools...
Everything is really well integrated. And if something doesn't suit your needs, changing it is a few ELisp lines away.
My computer setup has become very simple: a tiling WM (XMonad), Emacs, Firefox, and a terminal (Urxvt).
I also hated emacs when I first tried it, but once I started moving past my first programming language, I found myself sifting 30 IDEs and decided to give it an honest shot.
I don't use it for much else than programming, so my must-haves are for that purpose. Just the various built-in interpreters make it worth the price of learning.
Unlike both of you, I rapidly loved emacs. The only thing I disliked was the confusion around gnu and xemacs.
The reason I loved it was the indentation logic underneath, it was solid and meaningful. Other IDEs would only do very local logic while in emacs, if something doesn't indent where it should, you know you grammared wrong. It was deeply magical and reassuring to me.
Some IDEs may offer better language-specific features than the community-supported emacs modes, however I haven't found an IDE that actually does the editing (and displaying) of text as well as emacs.
In particular all the little modes that try to emulate emacs functionality (simple things like rainbow-delimiters or slightly more complex things like undo-tree-mode) are always broken in subtle ways in the "modern" applications. Not to mention all the text navigation features: ace-jump & friends, helm-swoop, etc...!
I guess a large part of this is that emacs has had 40 years to mature and that it was originally written at a time where software was judged on different criteria than it is today.
I find that on balance, most of those language-specific features are the ones that matter most to me, and provide the best value wrt. my time (and finished product).
Comparatively, the text editing power of vim/emacs, while nice, just doesn't provide that much value to me anymore, *most of the time.
That being said, it varies by language. If I were working in C, I'd probably use emacs. Working in Go, I still do use emacs (the side effect of the language's simplicity is that solid tooling is a snap to integrate in both vim and emacs). Java or scala? Not a chance in hell I'm going to do anything serious with those two in vim/emacs.
I only really enjoyed Emacs once I learned some ELisp (I think I had tried is 2 or 3 times before that). Honestly I find these guides pretty useless b/c you can copy configs and hack together something without really understanding what you're doing but you'll eventually end up extremely frustrated and unable to work around the quirks and conflicts between configurations.
I know the people behind Emacs like to think the system as usable out-of-the-box but I think selling it like that is ultimately a disservice b/c people end up underwhelmed and frustrated - never taking the time to learn ELisp. (the Emacs intro/tutorial is just a "welcome to this nano with annoying keybindings") I actually would challenge anyone to find someone who loves emacs and doesn't know a bit of ELisp :)
Ultimately ELisp is really not that much work to learn - but the root issue seems to me that ELisp isn't really a general purpose programming language and who wants to invest in learning a language you can't use outside of your editor? It's basically a DSL for a managing text and buffers.. It'd be way sexier to learn if it was a Racket or something
I also wrote a little annotated config intro (these are kinda more personal notes for my org/git/C++ workflow). It's a little terse and to the point and isn't trying to sell Emacs, but unlike most guides I tried to document what each lines in the config really means and help the reader learn how Emacs helps you discover more of Elisp as you go. https://geokon-gh.github.io/.emacs.d/ Maybe someone will find it useful! (I'm by no means an emacs expert or Lisp guru.. so if there are problems, let me know please :) )
Back in the day our teaching assistance got pissed off that most people were using Emacs as if it was Notepad, and spent the rest of the programming lecture teaching how to use Emacs instead (about 1h).
Which then became my to go editor in UNIX systems, until IDEs finally became a thing on UNIX.
Common Lisp is my main language outside work (and I manage to use it for work now and then as well) and I use it with Emacs + Slime. I've been trying to get into Paredit and similar modes but they just annoy the fsck out of me.
Mind, I do use Evil so I'm getting some 'structured editing'-lite from that already.
I would love it if guile-based emacs ever gets off the ground, and the ecosystem gradually moves to scheme for more and more things, and away from elisp.
It's true that you MUST learn Elisp to use Emacs effectively. That said, the thing with Lisp is it's a pretty simple language, and once you know one Lisp dialect learning another one isn't a big deal. As far as Elisp is concerned, you don't need to learn a vast library either. Most of the time you'll be setting variables, hooks and occasionally writing some small function.
right, that's very true - it's in a lot of ways just a mental block. Though it's not likely, I still want to keep the option to reuse my code in a different context and a DSL precludes that
I dunno. Once I took the time to learn the basic keybindings, even before I even knew what .emacs was, I was already pretty impressed with the auto-indent functionality that seemed to work regardless of the language.
It was the lack of basic keybindings that resulted in me never getting going with it. Everytime I wanted to do "trivial thing" I was expected to write a script. Too much yak shaving.
Author here. In reading this thread, I'm struck that most of the objections to emacs are both legitimate (as are the arguments for it) and focused on programmer-specific issues. Back when I wrote the original post, I was experimenting with using emacs as a CEO who writes little code these days, but was dealing with a maelstrom of disparate information and interruption. It's been a very successful experiment, which I'll document in a follow up post soon. Glad that it got some good conversations going!
I'm mostly a C developer that spend most of my time inside Emacs.
I use ivy-mode instead of ido-mode, and avy instead of ace-jump. My setup includes yasnippet, flycheck, company, and ggtags mostly.
I have issues using the number keys. So I use a custom vi like mode, but heavily customized: Pressing spacebar results in "_" ("-" in #include), but intelligently. Double space results in "->", ".." results in (|) (where | is the cursor or point) and ",," results in "=".
Pressing spacebar after "(" results in "&", then "*" (also "!" if just after "if" or "while"). And my capslock key is just another control key.
All the examples above are to be assumed without quotes.
spacebar results in "_" only when the cursor is immediately after [a-zA-Z0-9_]. And if I really need space, I have Shift-Space. Also, pressing spacebar after a keyword (like char, int, if, else, etc) results in real space.
It took me a few years to undertand this, but Emacs is not really a text editor. It is a development and runtime environment for a programming language that is especially useful for building text editors - and more generally, text-related, interactive programs -, and it happens to come bundled with a variety of such programs. But there are many, many more to discover out there on the Internet. In fact, in recent versions, this, too has gotten easier, since Emacs now comes with a package manager. But it can also be an IRC client, an audio player, a web browser, a database frontend, ... the possibilities are practically endless.
And this is why I love Emacs. There are other editors out there that are good, too. Very good. But to me, Emacs takes the prize because it is so much more than an editor.
Always seemed to me less a text editor and more the intended user interface after rms and his gang of misfit lads finished herding up all the daemons into the eventual (past my expiration date) GNU/HURD. Turns out it was a Lisp machine all along!
That said, I too have developed a renewed appreciation for Emacs these past few years.
The tripping block that always gets me out of the emacs flow is integrating org-mode with things my co-workers use to communicate (lately that's and Asana, Jira, and Quip, tomorrow who knows, it's hard for me to dictate choice of issue trackers or wiki based on what integrates with my admittedly nutso setup).
Even if I were to get everything working, then if I were to ever switch jobs suddenly I'm back at square one again.
Emacs and org-mode are perfect, _if_ you don't have to collaborate with anybody.
I once shared an office with another happy user of Emacs and org-mode. We did a small project together and used an org file to manage the project tasks inside the source repo. Even that did not work out so well, because I would also see his tasks on my agenda. I guess this could be improved with tags and filters, but my point is that collaboration with org-mode is difficult beyond the issue of agreeing on the same tool to use.
I started off with Emacs and a month a later tried Vi. I found Vi to be a better fit for me than Emacs and haven't looked back since.
I have huge respect for both editors, they both are much older than me :) I wish I could write something that people would find useful for years to come.
Having said that, I love to jab(friendly) at Emacs users in my circle of friends and colleagues. Makes the conversation even more colourful with a bit of booze inside ;)
Am a 99% emacs user, but I almost prefer vi text editing paradigm. Very precise and regular set of basic operations. Logical and rapid.
It's an interesting two sides of the same coin. Emacs, as lisp legacy, is centric, everything as layers around a lisp core (and C bits). Vi is more island like, complex logic is delegated to external programs most of the time.
It's interesting to compare the two, how to decouple/modularize a system.
Now, Vim. But I would definitely like to give Emacs another try, just for kicks.
Do you think emacs with evil is the path with least resistance for a long term Vi/Vim user?
I’ve been a daily vim user for the past 10 or so years and used it casually before that. Anytime I tried to use emacs I missed the modal aspects of vim and my wrists didn’t like the focus around ctrl in emacs.
I recently gave spacemacs a try and it’s been my daily editor for the past few months. There is a lot to learn, but spacemacs solves the main pain points I had with off the shelf emacs and I’ve found it to be very productive for me.
Author of post here. I have no agenda to convert anyone, but mapping caps lock to control is a good move when trying emacs IMO. If you love vi(m), more power to you!
Oh, yeah I use that mapping (caps to ctrl), but emacs would still always hurt my wrists! I prefer having visual/insert/normal modes and spacebar for modifiers in spacemacs. It’s the best of both worlds for me.
I think Spacemacs (which is an integrated emacs + evil + a whole lot more) is probably the best upgrade path for a vi/vim user. I even got one of the fellows at the office to upgrade from vim using it!
I went from a fully decked out vimrc to Spacemacs when I got tired of managing a .vim directory. I had things like Unite integrated everywhere and a generic repl experience via tmux so I had an inferior-mode for anything I wanted (sql, python, clojure, javascript, bash, ruby), even on remote machines (since it was just copy something from a register to a tmux pane, which could be ssh logged into a remote machine with a repl). I had autocompletion and doc lookups for the languages I cared about. Life was pretty good, but it was beginning to get tedious.
I decided to try Spacemacs hoping I might find their vim imitation to be 90% of what I was using in vim, such that I could take advantage of the excellent CIDER mode for Clojure development rather than hacking an analogue in vimscript + a user.clj file. I found Spacemacs to cover everything I had been doing in vim, almost universally better out of the box than I had before.
In addition to all the other things mentioned (helm, projectile, magit, org), I've found org-ref and interleave great for managing my notes when I read papers or articles. Roughly, I save the PDF to disk and create an org node for it, then add the metadata like file location and bibtex info. Then I have emacs open the PDF and as I'm reading it I can press 'i' to open a note on that page, and then close the note and keep reading.
Very nice. I don't read PDF in Emacs, but I also use an org file for notes, with references to the file and a bibtex file. When I use org-mode to author articles, the references used are multi-purpose: from Emacs, they link to my notes, but when translated to LaTeX, they become citations. See:
"You can recognize emacs by the 'mode line' near the bottom of the screen. If you see anybody using it, fire them immediately - they may be a good programmer but they're going to cause more trouble than they are worth."
This is a great article, not least because of the tangential comments (e.g. that impact test of bicycle-style tubing was weirdly fascinating). All that's said about Emacs is true. I loved it for decades. And then my hand started cramping up because of the key chords. So I tried vim, and hated it for a few days, disliked it for a few more, and then started to like it. I'd never go back, now. Vim is certainly not as powerful as Emacs, and its macro language is disgusting, but for everyday work it's fine. And I really like Vim's "grammar" approach to describing complex actions, which makes semi-complex tasks into puzzles and not memory exercises. (For really complex tasks, though, there's nothing quite so wonderful as Emacs with elisp ... so this comment may say more about the work I'm doing lately than these two editors.)
If you write a small pre-processor (simple to do) you can store your emacs configuration file in a markdown file - allowing you to document all the settings neatly.
As I was reading this piece I was imagining that is what the author had done, as it is what I did too:
No need for a separate preprocessor. org-mode offers org-babel which enables you to practice "literate programming" to create your init file, where you interleave text and code.
There are various schemes to use an org mode file as your configuration, which gives you all the niceties of org mode: collapsible headers, language-aware editing modes, etc.
Hi there. Thanks for the article. I'm a newbie when it comes to emacs config files. You said, that we will put (add-to-list 'load-path "~/.emacs.d/lisp/") in the .emacs file, but that was before we had created it. Then a few paragraphs later, when we finally do create it, you tell us to just put in
;; set up ido mode
(require `ido)
(setq ido-enable-flex-matching t)
(setq ido-everywhere t)
(ido-mode 1)
Where do we put in (add-to-list 'load-path "~/.emacs.d/lisp/") ?
Disclaimer: I spend very little time configuring emacs these days, as it's working well for me, and there are others around who are much better at emacs than I am. There are likely better ways to do everything than I have, but I shared what works for me.
I've got the `(add-to-list 'load-path "~/.emacs.d/lisp/")` pretty early in the file. You can put the `(require `ido) (setq ido-enable-flex-matching t) (setq ido-everywhere t) (ido-mode 1)` where you like. Basically, you just need the lines in your .emacs file - if you add the reference prior to creating the directory and populating it, you'll get an error, but nothing will break. Add the directory and do a `M-x eval-buffer` and it'll pick it up without restarting emacs. Or just restart emacs. Hope this helps. Someone will tell you a better way.
It's probably more idiomatic to use org-mode (not that it makes a difference really). Here's a random example I found: https://github.com/larstvei/dot-emacs
Seems like lots of people here are sharing their experience with #emacs. I like it a lot, and think that it would be part of the ideal #workingset for me. However, I have never found a nice 'jump-to-definition that worked for most languages I edit on emacs. I tried ggtags, ctags, pygments. I think I had trouble setting all of these up, and they would not work for many languages I was using. I have not found a good resource on how to get a nice 'jump-to-definition set-up, and did look within the last 6 months. Maybe something new popped up?
Edit: I think I had trouble with Javascript, React and/or Ruby.
I have good experience on ggtags with GnuGlobal. Here's my setup.
1. Install the ggtags.el package in Emacs and install GnuGlobal outside.
2. Make sure /GnuGlobal/bin is in the path environment variable, so that the global and gtags executables can be launched from Emacs.
3. Build the initial index database outside of Emacs. Emacs will update the index as you add new code. I usually just run the following commands on the root of the source directory. You can modify find to include or exclude certain files.
find . -type f >> filelist
gtags -f filelist
Now M-. should pick up the word at cursor and jump to its definition, or display a list of all its usage if cursor is already at the definition.
Language awareness can be lacking. That is why things like helm-ag and helm-multioccur are so great. They work no matter the language and for things you could never really add awareness for. I find with a few language based cheat codes like helm / git free + it grabbing the symbol at point working out just fine in practice.
Has anyone got any experience using Emacs with one of those mail tools and gmail with 2FA? I started playing with notmuch half-heartedly but it seemed to expect a local mail store, which is fine but I found myself bouncing between setup instructions for several different tools and I quickly gave up.
I would like to get it working; Apple Mail client is a bit slow on my laptop with a high volume, and I'm all about plaintext and keyboards. I'd happily use Emacs.
Has anybody quantified the efficiency gains from using emacs to do work rather than conventional means? Are there certain areas (e.g. Mail, todo, notes,calendar,scheduling) that gains more efficiency than others?
I don't think it would be easy to quantify the gains from Emacs because it's too specific to the user. For me, it's all about automation. If I notice myself doing something that can be automated multiple times, I write a function. If I find myself calling that function frequently, I turn it into a keyboard shortcut. That's a huge win, because it eliminates a lot of work I hate to do, but it's very specific to the user.
Gains and losses, remember. There are tasks where the use of a visual IDE just makes things easier to comprehend and use. Emacs will not give an increase in efficiency across the board for all tasks, otherwise we'd all have switched to it long ago!
Perhaps the real benefits are having some fun and warding off Alzheimer's, as the time spent learning and tweaking probably cancels out with future productivity gains.
I use org-mode and emacs (spacemacs) extensively at my job. I start my day by creating org-mode headers as todos, breaking down the tasks that I think will take longer than an hour, and later taking notes in outline mode as I do the tasks. I like planning a few days and checking in with my manager that I'm focusing my energy on the right things. I also use it to take excellent meeting notes and turn those notes into actionable tasks. People are impressed with my nicely formatted word docs that are just org files exported using pandoc.
When I tried emacs a few years ago I found the learning curve to be far more steep than vim at the time. After trying out https://vim-adventures.com/ (no affiliation, just thought it was useful) I learned it in about 15 minutes.
Is there any equivalent for emacs? I'd love to get it another shot.
To be fair, evil and spacemacs will only get you vim-like keybindings (which is all that vim-adventures gives you too), but there's a lot more to both editors than just keybindings.
There's even more to emacs than to vim, if you start using emacs for more than just editing, doing things that have no equivalent in vim (like reading email, browsing the web, using IRC, or reading RSS news feeds, etc). For every one of these extra things, there's new stuff to learn, and more time to spend configuring emacs first to just work with those things and then to customize it the way you like.
For me the time investment is well worth it, but there's no denying that it takes a lot of time. A lot of time.
The parent question was 15min quick start to emacs, not learn niche usage like reading email, irc etc. You can use spacemacs for a lot of languages with good support, if you are only familiar with vim keybindings.
> ... I also set Emacs to full screen. I'd like to do this on Windows as well, but Windows and Emacs don't really love each other and it always ends up in some wonky state when I try this
I use a nice plugin called maxframe, which apart from resizing the frame after a while and not when it's first displayed is not "wonky". I have yet to try multiple frames on multiple screens.
Salient code:
(defun w32-maximize-frame ()
"Maximize the current frame (windows only)"
(interactive)
(w32-send-sys-command 61488))
I use ivy instead of helm and ido (tried both of them).
Swiper and counsel are awesome for text search.
company, rtags, anaconda are awesome for autocompletion and code navigation in C++ and Python.
I use projectile for project management.
gud is not very useful for running a debugger, so I use realgud which is much nicer.
personally this article would work way better for me with a set of animated gifs instead of turning into a wall of text. And I'd love to see his workflows for what he puts in his different orgs to help with context switching. as I get more senior I'm switching tasks even more and more.
Author of blog post here. I take your point on being more accessible, and you're right about the wall of text. I didn't think anyone would care about my little paen to emacs, and this is one evening's work from a couple years ago.
Regarding organization, I don't have much of a system, other than the filesystem under ~/org with a handful of directories. Works just fine for me. It's more about not-caring than caring, regarding organization of information. We really shouldn't have to organize this stuff. Emacs + org-mode allows me to not care. I love that.
thanks for the follow up. I do appreciate the article and it's very well written for a one evening work.
So is there somthing inherent in org mode that just makes a pile of concurrent projects in a directory usable? eg do you just have project plans and mind maps for each "idea" or "product" in your org directory named by idea or is there just one file? or it doesn't matter and you just basically grep to find where you need to be?
I'm sure you'd love to live in the world of Fahrenheit 451, there they have no 'walls of text' and only big tv screens with colorful images, multiple per room.
I know, don't feed the trolls. Look, I'm a software engineer, likely like you. I read walls of text all day. However having an engineer provide an explanatory narrative of how they use a terminal ide like emacs, which is still a GUI for the most part, is very difficult and takes a lot of understanding. However some of these things can be done in 3 seconds in an animated gif or 20 minutes in a bad youtube video.
And I do have basically the giant tv screens at my desk filling 120 degrees of vision except they're called monitors and there are 7 of them, almost entirely filled with text... except the one that plays baseball all day.
My main problem with learning emacs is usually any explanation from people tries to describe it in words and it's hard to grok, or they do videos but have customized the keyboards bindings so I have no clue how to repeat or translate their magic into operations on my machine. Every time I give it a good go, about once a year for a week, I get going pretty good but then have to really jump back into an urgent task and go back to the tools I know because at the end of the day what I need to do is get work done, not learn emacs. And so I forget. As a counter example I picked up Visual Studio 2017 in about a day having not used anything newer than 2008 in years. VS Code or Sublime were mere minutes. Emacs and vim, I've got basic proficency in them but even after multiple months of total trying with each over 20 year career, they haven't stuck beyond basic git commit editing.
Finally, what a lot of devs don't get, is your logical assertion that emacs or vim or what have you "Is just better" doesn't really resonate with people, even other engineers (who are born skeptics). What resonates with them are examples of WHY it's good, ones they can innately understand. It, like any Don Draper ad, is about translating the fundamentals to another person as succinctly as possible. Like any sales funnel, any friction is going to turn people off. So if you really want to sell Emacs or Vim or any other gospel, have a good sales pitch and don't get mad at people when they give feedback because "they're too much of a mouth breather like those folks in Farenheit 451 to realize what they're not getting".
Maybe. But if you are using PyCharm it will be hard to get used to Emacs. It takes a while to get to a place where Emacs makes more sense than a good IDE. PyCharm is very good at what it does.
Does anyone use it to type in languages that require an IME or specialized keyboard usage? I tried Emacs a while ago, but I was disappointed I couldn't use my normal OS functionality for typing Japanese, Chinese, Korean, etc.
I primarily use vim for writing code. While I use a lot of standard plugins, I find many things that is not correct with them. I know it's kind of a subjective question, but is moving to spacemacs worth it? Any experiences?
Emacs is like Chinese to me, and truthfully to most developers I know. Is there a gentle intro somewhere? Most of what I've seen is just people throwing out package names with no real explanation.
Start with zero add-ons. Don't use any fancy modes, just let it do syntax highlighting and maybe ctags and nothing else. Especially no VCS integration, no debugging or shells. Use it to edit text. Get familiar with: buffers; windows; the mark and the region; the kill ring and how to use it; the standard editing and navigation commands available in every buffer.
Once you feel comfortable with those, then you can think about adding other stuff on, and can add things one at a time.
I've been using Emacs since 2000 or so, and that's how I started. It's also how I still often use Emacs today; I don't particularly care for IDE-like features, and I don't use a lot of packages. And I'm still quite productive with it because the base stuff Emacs is good at is already pretty darned good!
If you don't try it, consider swapping control and caps lock too. Most people use control way more, but caps lock has the superior position on the keyboard. That is, the home row, where your pinky is naturally while resting your index fingers on F and J.
My only complaint about ido-vertical-mode is that it seems to be very slow for long lists. This is why I'm looking for an alternative. I tried helm and ivy, but both of them behave frustratingly differently compared to ido.
I'm now using ivy-mode again. It's much faster and the annoying differences in behaviour (e.g. only "g l" will match "guile" but "gl" will not; double TAB in find-files opens dired; etc) are actually acceptable.
I've never been able to get into graphical emacs, but emacs-nox has been my terminal editor of choice since college. Coming from a Windows background, vi(m) was too weird to get used to.
I currently use Sublime Text 3, but I used to use Vim and NeoVim. One complaint I have with Sublime Text 3 is that many of the keybindings are "chords," and I seem to be developing pains in my wrists and elbows from frequently typing the more awkward ones. I've heard Emacs uses similar, chorded keybindings, only to the extreme. I think the problem with ST3 is that many of the chords are awkward to type. How is Emacs? Are the chords more natural, or would I be facing similar issues with chording?
My experience with an Atreus was quite different. The hand positions were comfortable with the tilted, split sides of the keyboard. Using my thumbs for both Space and Enter was also nice. I especially liked the straight, vertical columns of the keyboard. They made touch typing much easier and faster than on a regular keyboard with offset rows. Overall, the Atreus was beneficial to my typing speed and also to my wrists, elbows, and back, since it helped align my body in a more natural typing position. What aspect of the Atreus keyboard do you feel renders it a white elephant?
Wow I'm an idiot. I completely forgot about the other (mainstream) definition of White Elephant. I was only thinking of the one that I learned in college. Total brain fart, and now my comment above looks like an insult when it was never meant to be one. I meant they're luxuries that I appreciate having but could easily live without.
That's not the definition that I learned: a white elephant is an unnecessary luxury with limited utility that you can't obtain and maintain unless you're pretty far from being in need. That's what I meant here.
The alleged origin is a king who gave them as gifts, knowing they had no practical use and hoping the cost of feeding and caring for them would bankrupt the recipients.
From Thailand. Elephants are sacred there, especially white elephants. So if someone gave you a white elephant you could not refuse or get rid of it without causing offense.
Emacs is great, but is nearing its end. The package ecosystem is too fragile and lack of any kind of support leads to constant breaking and having to dig through elisp code/config at inopportune times.
Core tools like a text editor need to be rock solid and depending on volunteer packages is generally not going to cut it vs. paying a small amount towards a supported product.
Full disclosure I recently gave up on Emacs/Spacemacs after several years of using it for Python development (use Pycharm now), Org-mode (Use taskwarrior), and Magit (just use git + some aliases).
Here are some of my favorite Emacs things:
Helm + Projectile. Helm will fuzzy complete almost anything in Emacs. Projectile is project management. Together get to any Git repo and file there in very quick. Helm is an option to compare to IDO. I rarely use IDO due to Helm.
Magit, widely regarded as a good Git UI. Using is believing. Better than command line or most GUIs for me.
Various editing nodes are good enough (Python, Lisp of course, Markdown).
Org mode is it's own beast, but if you like outlines and productivity tools Org is very nice. I use it, not extensively. It holds my todos and meeting notes and makes it easy to ha e very complex notes in one doc.
Basic text editing. I think Vi has some things it does better than Emacs here, but it is still very powerful and rewards learning the finer details.
Realizing you are in a Lisp machine. A calculator is no further than your Emacs window. Learning to hack Lisp and elisp is its own reward.
I think the time spent learning it is worth it. I think the math checks out in terms of efficiency. I also know Emacs is not going anywhere. Same with Vi.
There is much more to it all, but these are things off the top of my head. There are many smaller things that connect up how I work via Emacs... But there is a lot to it.