Things I wish they told you about Emacs | Hacker News Reader

Things I wish they told you about Emacs

19 pointsreptation29 comments

hit 'q' to dismiss intro page and go directly to scratch buffer

M-x customize gives a menu to change those lisp variables people are always mentioning.

If you'd like a whole book on this topic, I can't recommend Mickey Petersen's "Mastering Emacs" enough: https://www.masteringemacs.org/

Seconded. This is a great book that lays the foundation of emacs knowledge.

I wish they told me about http://www.reddit.com/r/emacs!

Also, the extended MELPA package universe. This and (use-package) allowing me not to worry about installing hundreds of packages really transformed Emacs into a productivity behemoth.

http://melpa.org/#/getting-started

My favorite thing I wish they'd told me about emacs:

M-x shell

Run a shell (or shells) inside emacs. Great for long running apps like servers. You can search back through the output using normal Emacs search commands. For me, one of the killer features of Emacs.

Rename the shell buffer to something else to start another shell.

I had a coworker that'd cringe every time I used it because I used that shell instead of one of Emacs's other shell modes.

It all depends on what you're doing in a shell. For me, shell is preferable precisely because it's not a full fledged terminal. Meaning regular emacs commands work with it.

For more than one shell buffer you can also do C-u M-x shell and then press enter (for the default buffer name) if you can live with shell-2, shell-3, etc. for your shell buffers' names. Saves the time for renaming.

You don't need to rename it. When you want to start a new shell, go C-u M-x shell and it will ask you how to name the new shell you just created, with default being shell<2>.

Just curious, why do you prefer shell instead of term or ansi-term?

Both of those other modes have better support for curses applications and act closer to an actual terminal emulator than M-x shell does.

Also, if you like term, you can use the "multi-term" script (http://www.emacswiki.org/emacs/multi-term.el), which will automatically open a new terminal window with M-x multi-term, and you can cycle through your open terminals with M-x multi-term-next and multi-term-prev

Not the parent, but I also prefer shell to ansi-term for my daily usage.

My 99% use-case is running programs that don't need terminal emulator support, but I do commonly use Emacs keybindings for navigating around the buffer -- which requires switching between char and line modes when using ansi-term.

It does not need to be either/or. I have configured the terminal mode of ansi-term to allow the cursor keys to move around in the buffer as usual exactly because I often like to back up a bit to look at some output and keeping remembering that the normal buffer movement keys was not available became annoying.

Basically what swhipple says. I work on long running servers and it's fantastic to run them in a shell terminal and be able to use emacs' incremental search to look through the server output for interesting log output. I have no need for curses support generally, but when I do I use a different shell, though I can't say I find them nearly as useful.

I found that 'shell' mode occasionally got confused, for instance on what the current directory is. I have changed to 'eshell' as my primary shell emulator, one that implements a number of the basic commands directly in elisp. It works quite well, except when running an interactive command which is does not handle well and there are some issues with piping as well.

Yes, that is irritating though you can run M-x shell-resync-dirs to fix shell when it gets confused.

Generally I like to have bash available so that's why I use shell instead of shell.

You NEED to learn about keyboard macros. And C-/ (which is undo).

Actually, it helps to be around other emacs users. I've seen people do something magic and I stop them so I can learn the trick. Usually they have to do it again before they can explain it because most emacs users have everything "in their fingers". Musicians are the same.

I would credit emacs with 50% of my productivity. Learn it well. It pays huge rewards.

That I could switch from Vim and still have access to nearly all the vim keybindings and motions that I use in real Vim.

I've been using vim + evil (and prior iterations of evil) for probably ~5 years now, and it really is the best of both worlds for me.

Parens turn out to be an asset, not a drawback to the language. Allowing macros. Tooling like lispy/paredit takes advantage of the parens too.

As far as I know, Emacs users are disabling Intro page at all.

Also I can't suggest to use M-x customize because it writes some code into your init.el file. For me, it's important to keep this file as simple as possible with my code only.

But, in case if you're using Emacs for some simple stuff then M-x customize is ok.

Of course, you would

  M-x customize-variable RET custom-file RET

first, to save the customization variables to a separate file, adding:

    (setq custom-file "~/.emacs-custom.el")
    (load custom-file)

to your init file.

I don't use customize either, but there are very few things^1 that will be put in it without you explicitly customizing the variable and choosing to save it. So rather than typing elisp code out by hand, you can use the more user-friendly interface to set a variable. If you're -- for example -- version controlling your init file and you use customize, you want to have your customize block version controlled.

[1] The only one I know about is `package-selected-variables`, which are "packages installed explicitly by user". It's used to make sure those packages are not considered unneeded if they aren't a dependency of anything.

Customize.el is not only about saving on keystrokes from elisp code, but it is highly discoverable, and importantly, type safe. If you need to put some wacky cons shenanigans to define your font locking rules or whatever, all that is taken care of you in customize.

I don't put the output customize.el under version control since I vary my settings somewhat from machine to machine, and I use version control to sync my emacs configuration. However the output is easy to mechanically transform into (setq-default) for things that I do want to synchronize.

Customize is also fast. A few years ago I converted 15 years of elisp cruft over to customize and sped my emacs start up by roughly 10x (used to take about 10 seconds).

  (setq inhibit-startup-screen t)

will disable the startup screen entirely so it always goes to the scratch buffer.

C-h b shows all the key bindings, and C-h f will describe any command (and give access to the source where it was defined).

Emacs is nice. But it's also a fractal of bad usability design. :/

I honestly think the defaults were made bad on purpose to force people to learn how to configure it.

Like apple does with the angles of the laptop screen? makes sense

http://www.forbes.com/sites/carminegallo/2012/06/14/why-the-...

I thought that about Unix too. We have to justify the pain in some way right ?

I disagree. People often tend to forget that Emacs has a very long history and what may appear to a newcomer today to be bad design more often than not, has a logical (even if historical) reason.

It is of course a classic design dilemma when porting something across dozens of different systems and supporting something across many decades, whether to try to adapt to the whims of a new target or to stick with a common core. Emacs will never be the Microsoft Notepad of the common computer user and we, the long time Emacs users, tend to see the stability of the interface as an advantage.

It is possible to use something for a long time and still be aware of its shortcomings.

(I have been using emacs since 1996.)

Reply on news.ycombinator.com