

Most frequently enabled Emacs packages - Adrock
http://adereth.github.io/blog/2013/12/08/most-frequently-enabled-emacs-packages/

======
barrkel
I only started using emacs about 3 months ago.

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 lets me press Alt-O on any symbol and see all occurrences of that symbol in
the file. I can then jump to uses, then use helm-resume to find the earlier
occurrence and jump back. I have a similar function for a pre-initialized
helm-git-grep.

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.

------
codex
Is there an canonical opinionated configuration of Emacs where each component
works relatively well with all others? I love Emacs but I don't want to spend
100 hours on research and tinkering to have something modern.

~~~
jrockway
I don't think anyone sits down to configure their editor correctly from day
one. You gradually add features as you see potential optimization in your
workflow, or maybe try something when you read an article about it. The
opinionated configuration is the one that comes out of the box. Other than the
fonts and colors, it's 100% fine for any work you might need to do.

~~~
barrkel
The extended keys are also broken for most terminals in most stock OS
installs.

~~~
teddyh
If you have a graphical environment there is no reason to run Emacs in a
terminal.

~~~
barrkel
There is every reason. It's the same whether you're running over ssh or
screen, on OS X, Linux or Windows. A consistent environment is worth a lot
more than the idiosyncratic (and hideous) Emacs GUI. A mouse doesn't add a lot
to the editing experience.

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.

~~~
teddyh
If you don’t like the menu bar or the tool bar, don’t use them. You can even
turn them off if you resent the space they use.

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.

~~~
barrkel
If I want to open a PDF, I use a PDF viewer - or increasingly, a web browser.
If I want to open an image, I use an image viewer - or increasingly, a web
browser.

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.

~~~
teddyh
I don’t see that you give any reason for why you would want to run Emacs in a
crippled (terminal) environment. Except, of course, that you have chosen the
life of a hermit and live in a cave with only stone knives and bear skins.
Your personal lifestyle choice of using only Cygwin and terminals does not
support your general assertion that there is every reason _for everyone_ to
deliberately cripple Emacs’ user interface by running it in a terminal
emulator.

------
codemac
I'm amazed linum is not more popular in that list (~10% usage).. I definitely
thought more people used linum than say something like winner.

Interesting.

Obviously, this type of data submission should be tied into something like
package.el, though it is fraught with error.

~~~
packetslave
At least in my experience, linum makes Emacs 24 unusably slow to respond to
typing. I haven't fully isolated this to "linum" vs "linum and XXX together",
but when linum-mode is enabled, Emacs is noticeably sluggish.

~~~
mark_h
Magnar had a great hack to only turn it on when you goto-line:
[http://whattheemacsd.com/key-
bindings.el-01.html](http://whattheemacsd.com/key-bindings.el-01.html)

------
ams6110
I thought transient-mark-mode was enabled by default in recent releases?

iswitchb-mode seems to do some of what ido-mode (which I've never tried) does.

~~~
jamesjporter
ido doesn't become really amazing until you add ido-ubiquitous (which makes
most minibuffer completions use the ido interface, as opposed to just file
opens) and flx-ido (which allows fuzzy matching).

~~~
a_e_k
Yes, I've found using ido that way together with gtags to be particularly
slick.

------
JoshTriplett
I'm surprised CUA mode isn't in the list.

~~~
barrkel
You're really swimming upstream if you don't use defaults for C-x and C-c.

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.

~~~
JoshTriplett
CUA's C-x/C-c/C-v bindings aside (which don't actually conflict with the
standard Emacs prefix keys), it has a wildly useful rectangle selection mode,
as well as convenient indent/outdent commands for the selected region.

~~~
barrkel
I presume you say that because C-x and C-c don't act as cut and copy when
there is no region, that there is no actual conflict? I use commands involving
C-x and C-c with the region active fairly often; both because the command
applies to the region, and also because I want to keep the region active while
I do something else.

I agree that CUA mode without binding the CUA keys is useful.

~~~
JoshTriplett
> I presume you say that because C-x and C-c don't act as cut and copy when
> there is no region, that there is no actual conflict? I use commands
> involving C-x and C-c with the region active fairly often; both because the
> command applies to the region, and also because I want to keep the region
> active while I do something else.

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.

