Most frequently enabled Emacs packages(adereth.github.io)
adereth.github.io
Most frequently enabled Emacs packages
http://adereth.github.io/blog/2013/12/08/most-frequently-enabled-emacs-packages/
40 comments
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.
There are a few that come to mind. 'Prelude'[1] and 'Graphene'[2] both serve as a sensible defaults for most folks. I had intended to link to the 'Emacs Starter Kit', but it seems that project has been abandoned...
Additionally, 'EmacsLive' [3] focuses on Clojure support.
[1] https://github.com/bbatsov/prelude
[2] https://github.com/rdallasgray/graphene
[3] https://github.com/overtone/emacs-live
Additionally, 'EmacsLive' [3] focuses on Clojure support.
[1] https://github.com/bbatsov/prelude
[2] https://github.com/rdallasgray/graphene
[3] https://github.com/overtone/emacs-live
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.
The extended keys are also broken for most terminals in most stock OS installs.
If you have a graphical environment there is no reason to run Emacs in a terminal.
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.
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.
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.
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.
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.
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.
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.
That's a matter of terminal configuration, not configuring Emacs.
No, it's not just a matter of terminal configuration. Terminfo can't describe all the keystrokes that some terminal emulators can generate.
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.
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.
What are your requirements for "something modern", compared to the out-of-the-box experience?
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).
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).
There are multiple starter kits, such as Emacs Starter Kit and Prelude. The following search for "Emacs" at GitHub brings up the aforementioned starter kits and more:
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.
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.
[deleted]
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.
Interesting.
Obviously, this type of data submission should be tied into something like package.el, though it is fraught with error.
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.
Magnar had a great hack to only turn it on when you goto-line: http://whattheemacsd.com/key-bindings.el-01.html
Emacs 24 loaded with -Q (so no customizations are loaded) and linum enabled on a large file makes Emacs sluggish. Other line numbering modes also suffer; it appears to be an issue with the gutter itself.
Line numbering is really the vi way of navigation. In Emacs, most people do an incremental search (or M-x occur) to move around.
Line numbering is the way you communicate when you're pair programming, and it's also the way tools tell you about errors - and not all of those tools are integrated, or necessarily work best when integrated, with mode-aware buffers.
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.
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.
Breakpoints I agree with.
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.)
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)
The current line numbers is visible in the modeline and you can use the goto-line to jump to a specific line. And you can always temporarily enable linum-mode if you really need to see all of the line numbers.
One could argue that for any "on screen" navigation (that is: moving to any visible character), there's nothing faster than vim's EasyMotion stuff, which has been adapted in Emacs as "ace-jump-mode". The latest version allows to jump to any character in any window / frame. I hardly "other-window" (C-x o by default in Emacs) anymore because it already takes two keys while in two to three keys I can use ace-jump to jump directly to any character I want, anywhere (instead of first doing C-x o then moving where I want to).
For stuff that is not on-screen, then it's the good old ways.
For stuff that is not on-screen, then it's the good old ways.
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.
iswitchb-mode seems to do some of what ido-mode (which I've never tried) does.
I thought transient-mark-mode was enabled by default in recent releases?
Correct.
Correct.
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).
Yes, I've found using ido that way together with gtags to be particularly slick.
It is enabled by default. I've updated the list to indicate that transient-mark-mode and blink-cursor-mode are on by default in modern Emacsen and that uniquify will be enabled by default in 24.4.
I'm surprised CUA mode isn't in the list.
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.
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.
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.
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.
I agree that CUA mode without binding the CUA keys is useful.
> 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.
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.
C-c most definitely causes conflicts. It is where "mode-specific-keymap" lives, which is the default and conventional prefix for custom bindings. While it's near-empty by default, various modes bind things inside it.
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 :)
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 :)
I don't use full CUA unless I'm having other people type, but I do have this in my ~/.emacs:
(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))
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):
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.