Most frequently enabled Emacs packages
adereth.github.io
adereth.github.io
The most useful packages for me, things I wish I'd known about from the beginning:
* package, pointing at GNU and Milkbox repos. Any time I edit a new type of file, I look for packages that work well for it.
* helm, much better than flex matching for my purposes. I use helm for all list completion except find-file, for which I use ido-find-file. helm-git-grep completely changed the way I work with mixed-source RoR projects, to the point I've fully abandoned RubyMine.
* projectile, mostly just for finding files across a whole git repo. I use helm to complete the file to find (setq projectile-completion-system 'helm-comp-read).
In addition, it helps enormously to not be afraid of Lisp. Emacs isn't really worth it if you're not interested in tweaking it, IMO. I had to tweak it quite a bit in order for it to play well with rxvt, my preferred terminal; and even further to get it to work well with screen in rxvt, and with mintty on Windows, and screen inside mintty. A familiarity with how termcap works, the esr's showkey utility, and a bunch of time with define-key got it sorted.
Here's a function I use a lot (bk-helm-occur at the end):
(defun get-point-text ()
"Get 'interesting' text at point; either word, or region"
(if mark-active
(buffer-substring (mark) (point))
(thing-at-point 'symbol)))
(defun helm-occur-1 (initial-value)
"Preconfigured helm for Occur with initial input."
(setq helm-multi-occur-buffer-list (list (buffer-name (current-buffer))))
(helm-occur-init-source)
(helm :sources 'helm-source-occur
:buffer "*helm occur*"
:history 'helm-grep-history
:truncate-lines t
:input initial-value))
(defun bk-helm-occur ()
"Invoke helm-occur with initial input configured from text at point"
(interactive)
(helm-occur-1 (get-point-text)))
(global-set-key (kbd "M-o") 'bk-helm-occur)
It's these kinds of customizations that make emacs shine. Any time you find yourself doing anything repetitive or tedious, you can usually hack a function up in a few minutes that improves your workflow. Prototyping Lisp functions is completely trivial owing to the ability to evaluate Lisp in the buffer.
Additionally, 'EmacsLive' [3] focuses on Clojure support.
[1] https://github.com/bbatsov/prelude
https://github.com/search?q=Emacs&type=Repositories&s=stars
I haven't used any of these starter kits because the starter kits that I've used for other platforms/frameworks caused me more trouble than they were worth and I generally need to devote only one weekend per year to Emacs tinkering, which I enjoy.
It also helps with integration in Windows. I run Cygwin emacs so that I get sane shell commands. There is no native Win32 version of emacs that also links into Cygwin, as far as I'm aware. I'd have to run the Cygwin X server (or some other X server) in order to get a GUI emacs with working M-| and friends.
I rather struggle to think of a good reason to run Emacs outside a terminal. It gets you more colors and marginally better support for keyboard shortcuts. That's about it; not enough to counter the downsides.
Emacs is much better graphically; it benefits from graphics just like any OS benefits. I could talk about minor improvements while debugging, or I could mention that Emacs can open image and PDF files. This is not the 1970’s when text UI’s were the norm – this is the future, where we do have graphical displays, and all programs should take advantage of them. Living life in an emulated 1970 (which a terminal emulator is) is silly.
A text editor for programming is different. It swims best in a sea of programmable components that can be recombined endlessly. Elisp is one part of that; the shell is another.
I've increasingly isolated my dependency on OSes down to two things, the web browser and the terminal window, both because those are the two things that are consistent and available across all platforms I use - from production servers down to my phone - and because they're the best platforms for what I do.
I know UIs will improve over the next 20 years as they have over the past 20 years. But I also know that I spent a good 18 of the past years using one GUI IDE and editor after the next, and had little compounded return on each iterated investment. Meanwhile, the parallel investment I made in the terminal and the shell has paid off handsomely. I'm no longer pissed off at the crap Apple and MS pull with their OSes, because I'm no longer dependent on them. I spend more and more time in the terminal. Using a world-class editor in the terminal is just another extension of that.
Another thing. I transitioned to using Linux on the desktop fulltime at work last February. That transition would have been much more painful if I hadn't lived inside Cygwin on Windows since 1998 or so. If I had to live with the horrific car crash that is X userland, I doubt I could have lasted as long as I have. I want to have little to do with X as possible. It's a colossal pile of crap. Every app beyond a web browser and terminal emulator is an app too many.
The easiest way of fixing it is a couple of small patches to the broken Ubuntu terminfo entries, and some functions in .emacs to handle everything else.
My own .emacs is the result of nearly 10 years of tinkering, which I (like subsection1h) enjoy. Actually, I probably enjoy it too much, I've spent quite a lot of time procrastinating by tinkering with emacs … and this is why something like Prelude doesn't make sense to me, why would I let someone else do all the tinkering for me? =P
By the way, in my experience most packages tend to stay out of the way of others (e.g. turning on ido everywhere doesn't stop you from using jedi/midnight/sauron/org/magit/etc.), unless they are specific to a certain mode (jedi and ropemacs and traad all try to solve more or less the same problem, ie. python code assistance, so don't run them at the same time).
Interesting.
Obviously, this type of data submission should be tied into something like package.el, though it is fraught with error.
For example, I use pry and associated debugger stuff when working with Ruby. Want to set a breakpoint more precisely than a method? Need line numbers. Why would I not want that inside an emacs buffer? Because pry's symbolic completion is integrated with readline.
Pair programming; I just describe the position in the program. Humans are much smarter than computers. "You see where you're catching FooError in Bar?" You can also use your finger to point.
Anyway, I'm not saying you never need to know the line number, but I'm saying it's not the movement idiom in Emacs. In vi, all the motion commands take line numbers as arguments, so you use line numbers to navigate. In Emacs, the commands don't take line numbers as arguments, except for goto-line. (In this case, a leap of faith is necessary. Something tells you, error on line 42. So you tell Emacs to go to line 42. The line you are on now must be line 42. QED.)
(global-set-key "\C-cg" 'goto-line)
Yeah, no wonder I hadn't heard of it:-) I think I've had that binding since version 20 or 21.
For stuff that is not on-screen, then it's the good old ways.
iswitchb-mode seems to do some of what ido-mode (which I've never tried) does.
Correct.
(when (fboundp 'cua-selection-mode)
(setq cua-toggle-set-mark nil) ; o/w C-SPC doesn't set the mark if region-active-p
(cua-selection-mode 1))
I have S-delete, C-insert, and M-insert bound to cut, copy and paste respectively; S-insert pastes the system clipboard in the terminals I use. I use these when doing a lot of moving text around.
I do have C-v bound to yank, and M-v bound to yank-pop. C-y is a very awkward keystroke.
But C-w isn't too hard to use for cut, nor M-w for copy, when avoiding the arrow keys / edit block.
I agree that CUA mode without binding the CUA keys is useful.
You can use C-x and C-c as prefixes even when there's a region, as long as you hit the subsequent key quickly; there's a brief timeout for exactly that purpose. You can also hit C-S-x or C-S-c.
By the time I learned of CUA mode I a) got used to C-y/M-y/C-w/M-w; and b) already written "free-rectangle-mode" which gave me the same freedom of movement when selecting rectangles. It was one of my first emacs hacks :) Combined with rect-mark mode it would probably look very similarly to CUA rectangular selection, but I didn't feel the need for showing visual rectangle. Also default rectangle handling has a big advantage of starting both line and rectangle selections with the same key.
Anyway, I'm not surprised people don't use CUA very much - I think that by the time they learn about it it's already too late for them :)