Emacs, naked | Hacker News Reader

Emacs, naked

bzg.fr

294 pointsbzg194 comments

Configure GNU Emacs (24.3 or above) to avoid distraction.

Coming from Vim, when I switched to Emacs, I found the starting aesthetic experience more than lacking (or, ugly). It took me some time (and a helpful HN discussion) until I found good themes and good plugins to make it look aesthetically pleasing (to my eyes, at least, after all people's tastes differ).

If somebody is looking for a nice Emacs theme and feels that the OP is a bit too minimal, have a look at my Emacs conf (I know, shameless plug) here [1]

There's also a screenshot [2]

This configuration is kinda optimized for Emacs+Evil to be more like Vim, so you may just want to have a look at the theme / plugins.

[1] https://github.com/terhechte/emacs.d [2] https://raw2.github.com/terhechte/emacs.d/master/screenshot....

Oh, nice mode-line! I can't figure out how to get the theme from your repo, any hint?

I believe that is emacs powerline: https://github.com/jonathanchu/emacs-powerline

This is it, thanks. Beautiful, but too bad there is no easy way to deactivate it.

Hey, I'm using the Soothe theme, with local modifications: https://github.com/terhechte/emacs.d/tree/master/elpa/soothe...

The original can be found here: https://github.com/emacsfodder/emacs-soothe-theme

Another nice theme is Cyberpunk: https://github.com/n3mo/cyberpunk-theme.el

As jbeja answered, I'm using powerline with the default theme for the status bar: (require 'powerline) (powerline-default-theme)

What line numbering plugin is this? Looks very similar to vim numbers. I've been trying to find something like that for emacs for a while now. All I found wasLinum mode, which clutters the UI and doesnt give relative line numbering.

Hey, I'm using relative-number: https://github.com/terhechte/emacs.d/blob/master/plugins/rel...

It mostly works as well as in Vim, except if you're using Code folding, which confuses it a bit.

Why do you want line numbers next to your code at all? Aren't they just visual clutter? The current line number is shown in the mode-line anyway.

At least in Vim, line numbers help to move around and operate on text really quickly.

Move cursor to ninth line above: 9k

Delete from here to seventh line below: 7dd

Copy thirteenth line above after second line below: :-13t+2

Having line numbers always visible (either relative or absolute) helps for doing this operations quickly.

Emacs offers goto-line on M-g g or M-g M-g, which admittedly is not the handiest of key sequences; I've been thinking about rebinding that to be more useful, but I don't use it often enough to really need to.

Line numbers are also useful, for example, when doing web development, and hunting down the line that's mentioned in a stack trace. Absent integration between the browser's debugger and Emacs, which is something I've fiddled around with (based on mozrepl) but never got working, that's a good second best.

Relative line numbers are especially useful when you have mis- or not configured moving by paragraphs/defuns/classes/etc. for some particular mode. C-16 C-p will move the point 16 lines up, for example, supposedly exactly where you want it to be. But that's not the use case I need line numbers for - actually, well configured movement commands + isearch + ace-jump + iy-goto-char + occur is a combo which makes relative line numbering completely unnecessary.

I use (non-relative) line numbers quite often though, and it when I need to tell my colleague that there is this function in some file, on line 323, with a some interesting statement between lines 330 and 336. This makes it extremely easy for them to get to where I am and see exactly what I see; and on the other hand I don't need to move point to those three lines to read their numbers or - absolutely nightmarish - to count the positions manually - they are just there, for me to see.

It would be better to show and hide linum with some simple binding, but I'm already used to them, so it's not a big deal for me.

I try out emacs every few years. Every time, I get discouraged whenever I attempt to do something simple (change the theme, etc) by the amount of configuration necessary. I may try your repo, since it seems to have a lot of stuff already configured.

The other thing is that Emacs is really slow to start as soon as you have a few plugins, compared to vim.

If you try my repo, have a look at the custom keys that I defined, that helps things a lot.

Also, the one great feature about Emacs is MX (which I bound to CMD-. This opens the minibuffer where you can execute arbitrary EmacsLisp functions. Everything you do in Emacs (even arrow up, left or right) is bound to an Emacs function. So if you start out, and you want to do something, but you don't know the shortcut, just do CMD-. and start typing. The naming is really good. Say you want to deactivate line truncation. You go into MX and type "truncate" and among the results will be "toggle-truncate-lines" you go there, hit enter, and you're done. This is a bit more difficult in stock Emacs, as it has no wildcard search for MX but I'm using the Helm plugin, which offers this feature and makes it really really easy to find functions. I hardly ever use all these Emacs shortcuts like C-c C-e ... I just hit MX and type what I need to do.

Sadly, startup is still really slow for my configuration, which is why I have a Vim config with similar keys for quick Terminal usage. I start Emacs in the morning and keep it open all day. When I need to quickly fix something in the Terminal, I use Vim.

An excellent point; having a command line in your editor is something whose value is hard to recognize until you've tried it, and hard to overstate once you're used to it.

It might, though, be worth using the typical Emacs nomenclature for key sequences, i.e. M-x where you use 'MX' and (assuming your Command key is bound to Meta, as is ordinary for OS X Emacs users) M-. where you use 'CMD-.' -- your choice of preferred nomenclature is of course up to you, but using the standard forms makes it easier for other users, particularly neophytes such as the one to whom your advice here is directed, to understand what you're describing and relate it to the Emacs manual and to whatever other resources they're using.

I changed this because I found M-x to be really really difficult to type. It may be my hands or my fingers, but I have a hard time doing that key sequence correctly. Apart from that I think that you're absolutely right. I shouldn't have advertised this as it will probably confuse users.

Well, there's nothing wrong with rebinding M-x; that key combination requires a lot of hand scrunching, which can get uncomfortable after a while. Nothing wrong with talking about it, either! I'd just recommend describing it in accord with the conventions for Emacs key sequences, is all.

It's a lot better, and easier, in Emacs 24.3.x. Just run

   M-x customize-theme

And pick from a list of themes. New themes are installed via the new, built-in package manager:

   M-x package-list-packages

Might also be worth trying out theme-park-mode[1], which allows you to easily cycle through installed themes till you find something you like.

[1]:https://github.com/emacsmirror/theme-park-mode

When, a few years ago, I really started to get serious about using Emacs, I spent three days or so going through the customization options for pretty much everything, or at least everything I could figure out at that time, and adjusting it to taste. Since then, I haven't had to touch it except for minor tweaks. Emacs is what they used to call "a moby frob"; some initial investment is required, and it took me three or four tries before I had the perseverance to stick with it, but the payoff has been handsome indeed.

As for slow starting, the best way to solve that is by running an Emacs server, and creating and killing client frames at need. You only pay the startup cost once that way, and all your editor instances share history, buffers, and everything else, which is sometimes handy, and doesn't get in your way otherwise.

Slow emacs startup isn't a problem thanks to the new emacs-server stuff. Running emacs with the "--daemon" flag will cause it to do initialization, fork into the background, and become persistent; now edit files using commands like "emacsclient $filename". Eamcsclient will connect to the daemonized emacs server and have it open $filename, bringing it forward either in an existing frame or (using the "-nw" or "-nc" flags) creating a convenient new frame to edit with. Not only does this give you the ability to get into emacs without going through init, the server will maintain all of your editing in the same process so you don't have to manage editor instances.

There are serious problems trying to run it as a server on Mac OS X. Basically it's not a real option on this platofrm.

I've been running emacs server for at least a year or two now on OSX using homebrew.

  "$(brew --prefix)/opt/emacs/Emacs.app/Contents/MacOS/Emacs" --daemon

I wish I could muster the energy to figure out how going that particular route is flawed. I just know that it's one of the ones I tried, and I learned the hard way that it's got problems.

If you accidentally quit the Emacs GUI, does it still kill the daemon?

If you run it with --daemon, the server process doesn't create a frame of its own, but only listens for connections from emacsclient instances; IIRC it also rebinds C-x C-c to delete-frame (also available at C-x 5 0), and the daemon process stays alive through everything short of M-x kill-emacs or similar.

I have this:

    ;; schedule starting of Emacs server after everything else is loaded (5 min
    ;; *should* be anough for startup :))
    (run-at-time "5 min" nil 'server-start)

in my .emacs - this way I get both a window and a "daemon" server for use with emacsclient. I think it dies if the first frame is closed, though.

You can actually just put

    (server-start)

at the end of your init file, and it'll behave more or less as you intend; if you've got a lot of stuff hanging off after-init-hook, you might do well to hang server-start off it as well.

That said, yeah, it will create a window which if killed will shut down Emacs, so I tend to prefer invoking it with the --daemon option instead; that way, I don't have to worry about accidentally killing Emacs if I kill the wrong frame. (I also call server-start in my init file, but I'm not actually sure that is necessary when invoking Emacs with --daemon.)

If you're on a Mac (as I am) it leaves an Emacs application running (complete with menu bar and app switcher icon) that you can't interact with. But otherwise, --daemon works great.

Huh. This works for both -t and -c in emacsclient, with a vanilla build of pre-24.4. It didn't for ages, so thanks for getting me to check this out again!

I'm not very familiar with OS X, and I've had a lot of trouble finding the magic invocation that'll get an Emacs daemon running with the same behavior to which I'm accustomed on Windows and Linux. This looks like it should do the trick, thanks! Now if only I could get emacsclient to behave sensibly in the dock, I'd really be cooking with fire...

I run Emacs on Mac OS X as a server. What I don't do is "emacs --daemon". I launch Emacs and then "M-x server-start RET". This seems to avoid any weird issues.

I use the "ec" script show here: http://emacsformacosx.com/tips

alias edemon='/Applications/Emacs.app/Contents/MacOS/Emacs --daemon"

will give you a more helpful alias.

I'm on Mavericks running Emacs 24.3 installed through `brew`. I invoke `emacs --daemon` once when I start work and I have an alias and an Automator workflow to open files in GUI `emacsclient`s. No problems at all. What sort of issues are you seeing?

Slow emacs startup ... people restart their emacs?

The slow emacs startup problem can be mitigated by lazily loading custom modes as much as possible. The two big things to use here are autoload (instead of require) and eval-after-load.

On my machine, a vanilla emacs startup is ~70ms, and one with my fully-loaded .emacs is ~240ms. Still not as fast as I would like, but not terrible. (You can benchmark emacs startup from the command line with "time emacs --eval '(save-buffers-kill-emacs)'").

(Of course, even a 70ms startup for vanilla emacs is arguably pretty bad -- it's way slower than the ideal of "instant"; I just checked and vanilla vim is something like 8ms, for example, which is just-shy of imperceptible.)

Using the Customize interface also helps. Variables that are customized go in a big list and don't get set individually, nor do they require their library to be loaded before they've been set.

A few years ago I went through my 10 years of accumulated .emacs cruft and switched everything I could to customize, and everything I couldn't to the technique you describe. I sped my emacs startup time from eight seconds down to one.

On top of that I switched to using emacsclient which makes startup instant.

Nice, I didn't know customize was faster. I'll have to try that.

emacsclient doesn't really work w/ my workflow -- when I want a new emacs, I really want a new emacs. Also worth noting you get something similar "for free" when using the gui emacs on MacOS, via open -a Emacs (I use an alias).

I wonder if you couldn't somehow snapshot the state of emacs and dump it for a truly fast startup?

Run emacs as a daemon. Then in a terminal type 'emacsclient -t'.

Instant on.

I switch between Vim and Emacs depending on mood. It's a very hard deal: Emacs is a plateform that can do a lot of things besides editing, but it requires a lot of configuration fiddling, and is a bit too slow on the old machine on which I'm using it (must be a single core Pentium with Mandriva 9). Vim has a lot of things right off the box and is fast, but you have to use other programs to have a comfortable environment (mc, screen, ...).

Anyway. The trick with Emacs is to customize incrementally. Also, use customize-option as much as possible instead of editing your .emacs; too often people make you insert lines in your .emacs when already customization exists. Also, use the package manager (list-packages) that Emacs acquired recently instead of fetching from emacswiki or a github repo. It compiles automatically stuff, so it might help with startup times.

I switched to Emacs after being very impressed with nxml-mode. I found no better xml editor on Linux.

Emacs is great if there is a mode that's written for what you're doing--for instance, nxml-mode. I can imagine it's also great for C, for instance, because that mode is old and has seen lots of work. For lisp I'm sure Emacs is peerless.

Emacs is not so great if there's not a good mode for you. I grew frustrated trying to edit Haskell in Emacs; there are a bunch of half-baked modes out there. The problem is that without a good mode, even basic tasks like indentation are painful in Emacs, while Vim will indent anything well without a specific mode.

Often cited as Emacs' biggest advantages is how it integrates with other tools or, perhaps, how Emacs can become those tools. You can run your debugger in Emacs. You can read mail in Emacs. You can do version control in Emacs. The problem is that Emacs is never truly good at any of those other things. Running a shell in a buffer has problems. (You can run a shell inside a real terminal emulator in Emacs, but by that point you might as well just use a real terminal outside of Emacs.) Emacs is not a great mail reader. It's not great at doing version control and, what's more, it doesn't keep you from having to learn your underlying VCS, so now you have to know two ways to do things. Same goes for dired--it's a completely different way to manage files, but you still need to know how to use a real shell, so it just ends up being too much trouble to learn dired.

The thing is, when you strip out all the other stuff Emacs is supposedly good for--managing files, being a terminal, etc.--all you're left with is a middling editor with a good lisp interpreter. That other stuff is supposed to make Emacs great, but it all ends up being middling too.

So I have switched back to Vim. It excels at being an editor and doesn't try to do other stuff. In some ways Emacs is still better (for instance its support for multiple "frames" is something Vim can't get close to.) But with Vim I spend less time fiddling with the editor and more time editing text. If I ever need to do something for which there is an outstanding Emacs mode (edit XML, for instance) I will load up Emacs for that. But without a good mode Emacs is not worth it.

> I grew frustrated trying to edit Haskell in Emacs; there are a bunch of half-baked modes out there.

What's wrong with the normal haskell-mode? https://github.com/haskell/haskell-mode

(interestingly another commentator here claims that Emacs' Haskell indentation is superior to VIM's https://news.ycombinator.com/item?id=7111521)

> It's not great at doing version control [...]

Have you tried magit? It's probably the best version control support I've ever seen in an editor.

> What's wrong with the normal haskell-mode?

The indentation doesn't work well. It gets the indentation right maybe 80% of the time, but missing it 20% of the time is a big deal when you have to deal with the "tab-cycle." I spent so much time fiddling with indentation that I turned off auto indentation...and Emacs without mode-based auto indentation is much worse than Vim with manual indentation.

I also had problems with inferior-haskell-mode. I could have tried to fix them but I was fed up with futzing with Emacs, especially when I can go to Vim and just use ghci in a terminal.

A response might be "but you can use ghci in a terminal and still use Emacs." Which is true, but then I'm using a not-so-great editor that's not fulfilling its promise of integrating other tools. What's the point?

> Have you tried magit?

Yep. I still need to know Git and its command-line interface. With magit I was spending time learning magit, but not getting functionality beyond what the Git command line offers. Not worth it.

It seemed to me I was spending time learning tools in order to justify my use of Emacs. That's backward, so I stopped. I could have kept using Emacs without the other baked-in Emacs tools...but then you're just left with an editor. In that case I will pick Vim since it's the better editor.

I see where you're coming from here. But my conclusion was that Emacs with Evil is just as good an editor as Vim. And as a bonus I get the complete customizability of Emacs.

So when you say "I will pick Vim since it's the better editor," what Vim features in particular (beyond modeful editing, which Evil provides) make you say that?

>(beyond modeful editing, which Evil provides)

This is exactly my point. The Emacs mentality is that Emacs can do everything...it can even be Vim. Why should I do that when I can just use Vim? Maybe Emacs can do anything, but it doesn't do anything well unless you've got a dynamite mode. Evil is not going to be as good of a Vim as Vim. I can tell that even with a glance at the Evil website. One of the best things about Vim is the extensive documentation. Evil just has a 22 page PDF manual...lots of which is filled with Emacs Lisp. So if I use Evil, I then need to spend time learning Evil and how to customize it with Emacs Lisp. Or I can just use Vim.

Ritchie's riposte seems apropos here: "If you want [Vim], you know where to find it."

Did you try all three indentation modes?

It's a bit unfortunate that there have to be three separate indenters, but most people find that one of them is good enough.

Yep, tried all three, and looked at at least one mode that someone else is developing to see if it had better indentation. I don't remember the names of the three indenters being all that distinguishing, so I had to keep notes in my .emacs just to tell them apart.

One good indenter (maybe with options to select how to style your code) would be better than three. I remember reading a blog post about how hard it is to indent Haskell automatically. It breaks my chain of thought though to have something automatic that works only most of the time. It means I routinely have to stop to fiddle with the editor to make it indent correctly.

Have you tried structured-haskell-mode[1]? There are video demonstrations here[2].

[1]: https://github.com/chrisdone/structured-haskell-mode

[2]: https://www.youtube.com/playlist?list=PLlzKKtH5TyE-R-k86na3b...

I feel exactly the same way.

I was hoping I could get a "minimal" setup to edit Python code, and even that was too much to ask for. "Code folding? What's code folding precious? What's code folding?" --Smeagol

Apparently "minimal" doesn't apply to Emacs. Being complex is in its nature. It wants to become everything.

The worst was how every time you open a different file, your `CWD` always changes to that file's location.

Interesting, I consider that a great feature. That always bugged me in Vim. When I open a file in a different location, most of the time I want to be in that CWD. I guess it depends on how people work.

Oh, yeah, that drives me crazy too. Usually, I cd to the root of whatever project I'm working on, and I want all paths to be relative to the root of that project (though since I started to use ctrlp[1], it's less relevant).

1: https://github.com/kien/ctrlp.vim

As for customize-option, if you don't want options to clobber you main init file you can do this:

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

It's good for version control and for separating manual changes from customizations.

> The other thing is that Emacs is really slow to start as soon as you have a few plugins, compared to vim.

This just mean you are "doing it wrong". Your .emacs file should not be loading anything, but instead setting things to be loaded when needed using autoload, eval-after-load and auto-mode-alist.

It's possible that both of you are actually right, depending on the package. For example, "plugins" (such as Flymake, or modern variants) can indeed cause the editor to slow to a crawl. Likewise, I had to turn off real-time spelling checking for LaTeX documents in Emacs for this very reason -- on dissertation-size documents it was simply unbearable, and every few sentences the editor would just spin for a bit [2].

[1] http://flymake.sourceforge.net/

[2] http://ergoemacs.org/emacs/emacs_spell_checker_problems.html

Also make sure all your plugins are byte-compiled, this can shorten loading time significantly. Not a problem for elpa/package.el plugins, but I have quite a few plugins managed manually (I'm still not using el-get, shame on me) and the way I byte compile them all at once is to place a cursor on a directory with them in dired and issuing:

    C-0 M-x byte-recompile-directory

The C-0 prefix arg causes it to recompile everything without asking for confirmation for every file.

You could automate this with a function hung off the after-load-functions hook. Here's something off the top of my head:

     (defun foo-compile-if-newer (path)
       "A function suitable for hanging off `after-load-functions',
     which will byte-compile an Emacs Lisp source file for which there
     is no pre-existing compiled file, or there is a compiled file 
     older than the source."
       (and (save-match-data
               (not (null (string-match "el$" path))))
            (let ((elc-path (byte-compile-dest-file path)))
              (if (or (not (file-exists-p elc-path))
                      (time-less-p (nth 5 (file-attributes elc-path))
                                   (nth 5 (file-attributes path))))
                  (progn
                    (message "Auto-%scompiling %s..."
                             (if (file-exists-p elc-path) "re" "") path)
                  (byte-compile-file path))))))
     
     (add-hook 'after-load-functions
               'foo-compile-if-newer)

Adding an exclusion list, if you feel the need for one, is left as an exercise for the reader.

Very interesting thing you've got going there, and I love the visual aesthetic. Two quick tips that you probably already know, but just in case it's useful to you or someone else:

* Emacs can wrap lines at word boundaries, while intelligently preserving/extending indentation (something like this: https://gist.github.com/anonymous/8581161)

* If you're using emacs on the mac, it's worth taking a look at the railwaycat fork ("brew install emacs-mac"). Some improvements over vanilla emacs: Emoji (and other fun unicode) display works, fullscreen and maximize work better, scrolling with the trackpad works in a reasonable way.

I think you need to "brew tap railwaycat/emacsmacport" first to install that.

I built it from scratch, only using Brew to install the necessary image format libraries, and that worked fine too.

Thanks for these tips, I'm already using the railwaycat fork, and it is really good. I compiled it myself though, didn't know that I can get it via brew now. That is fantastic, as I'm still on 24.3.1 :)

Also, I didn't know about the wrap-while-keeping indentation, that's something I always wanted. Will try it out later. Thanks!

Also, note that Emacs 24.4 (currently unreleased) will have improved full screen support and better color support (same effect as "brew install emacs --srgb"). I've been using the Emacs head (from a month ago) and it's been very stable for me.

For sane trackpad scrolling in vanilla Emacs I use this:

    '(mouse-wheel-scroll-amount (quote (0.01)))

Seconding the recommendation for the Railwaycat fork, which is excellent. I just wonder about how quickly it'll be integrated into the 24.4 codebase, once that version drops; I'm really looking forward to file change notification support, for example so that Emacs can autorevert my Dropbox-synchronized Org files when it sees that they've been synced.

Thanks for the tip about railwaycat's fork. Note though that before you can run:

    brew install emacs-mac

you first need to run this:

    brew tap railwaycat/emacsmacport

Otherwise, `brew` won't be aware of that version. (Whoops. Noticed just now that someone said this earlier as well. Since the comments are all spread out, I'm leaving mine in case it helps someone see the issue faster.)

Very nice. Which font is this?

I think he's using PragmataPro. If not, it's very similar. Beautiful font, one of my favorites.

It is M+ http://mplus-fonts.sourceforge.jp/

Can't recommend it enough. Beautiful monospaced font for terminal and editor. And the light version works great on my 11" Macbook Air as it consumes less pixels and therefore allows more code to be visible.

Not trying to be a douche, but trying to get an honest answer: if you are coming from Vim, using Evil-Vim to get Vim-like commands why use Emacs in the first place? What features do you use/did you want that made you switch?

Primarily I wanted to write my own extensions in an integrated language with a good, honed, text api. Vimscript is really not so nice, and Emacs has a fantastic text / editor API that's a pleasure to work with.

Other features that were important to me were - Org Mode (I'm using it for all documentation now)

- Usability: As described below, every function in the editor can be accessed with a quick command (with pattern matching to find the correct one) vs. knowledge of arcane commands in vim. Also, most modes offer convenient access to all their features in the menu bar. So when I'm using a Clojure mode, and I can't currently remember the correct command / keystroke for changing the current Repl namespace to my current file, I click the menubar and there it is. All neatly listed. Makes it a lot easier.

- I like the Emacs way of having all in one window. I have one big fullscreen window with multiple buffers, and in there I have a terminal, a repl, multiple code windows, html documentation. So I never have to leave that mode. Keeps me productive. That is also kinda possible with tmux and Vim, but then I always had overlapping keyboard shortcuts for switching windows. All in all Emacs works better for me here.

- Lots of small things, in general Emacs feels like a much more solid editor, with more configuration options to fit it to my liking.

Fair enough.

Lots of people dislike vimscript and although I think you can also write plugins using python, it also seems more difficult to interface with.

I know that you can have a big fullscreen window with multiple buffers and a terminal and a repl in terminal vim without tmux. I guess you are not interested but you could see multiple buffers with :vsplit or :split to get vertical and horizontal splits, respectively. There are plugins for a terminal/repl.

Org mode sounds interesting to me, one of the things that I miss from eclipse is that I could see the javadoc when I held the mouse over an object/method/function, is that what Org mode does?

Thanks for the reply.

I know about vsplit and split, what I meant was a better terminal than conqueterm. Now, the Emacs ansi-term is also not perfect, but way better than Conqueterm.

Org mode is a very sophisticated Todo and documentation and wiki and calendar and management and literal programming system for Emacs. I haven't found anything that compares to it. It is really really good.

The java doc thing is something entirely different, and that's usually made possible by the various language modes.

I haven't made the switch yet, mostly because I am not enamored with elisp (when the hell is that guile-emacs thing going to properly get off the ground? Probably never...), but the basic design of emacs (C core, everything else built up around it with a lisp) appeals to me greatly.

If I ever do make the switch, I'll definitely still be using Evil mode though. I can't drop vi-editing, and don't want to anyway.

emacs's autoindentation for several languages (e.g. haskell) is a lot better than vim's. that all by itself is a compelling reason to use evil for those languages.

I am super glad to see Soothe being used / well loved. Thanks for using it.

I switched to Emacs a year and a half ago when I started using Clojure, and customized it heavily for the first few months. But I avoid customizing it any more. I'm never truly satisfied with what I end up with, and I hit too many frustrating walls trying to make it just right.

One major problem for me is the plugin ecosystem. There's Melpa which is easy to use and has the most up-to-date packages, but they're built off of HEAD which makes them extremely brittle. Many plugin authors decry Melpa and say that if you installed their package from it, then you're on your own. There's also Marmalade but I haven't found it to have nearly the same scope of packages.

Actually, I'm also on the "less configuration, less trouble" side. That's why I like some minor mode to let me get rid of what I don't want to see, sometimes.

Agree with the less is more idea when it comes to configuration. An additional benefit to this is that it's more comfortable to use vanilla emacs when you need to work on hosts you don't typically use.

I like this approach to package mgmt. https://github.com/overtone/emacs-live

Even though it is "manual", i prefer stability of my programming environment over the ability to install packages "quickly".

I walked almost the same path.

For the first couple of months I was customizing the hell out of Emacs. Then the things started falling apart and I've switched to the 20-line long .emacs and empty .emacs.d (well, almost empty if you don't count key-chord/ace-jump-mode combo which makes file navigation a mindreading experience)

Thanks for mentioning ace-jump-mode. I thought that I had a pretty extensive Emacs setup, but it is now much better with ace-jump-mode.

Are you sure that MELPA has issues? I've been running with it since it started and one thing that I can say about it is that its been a joy to use. Hats off to milkypostman & sanityinc for maintaining it.

If you do have an issue, I suggest you open it on MELPA's GitHub issue page and I'm pretty confident that you'll get a quick response.

As for tweaking Emacs' config, yea, I have to admit, I've spent time on it too and things can always improve.

The issue Melpa has is that it builds from HEAD, whereas many package authors treat HEAD as a working state that should not be used directly. Melpa doesn't (or didn't last time I checked) have support for building off tags or non-master branches, which would solve this. And if I remember correctly, when I raised this issue, he disagreed on some philosophical grounds. So it's an inherent problem in Melpa.

On IRC we get a steady stream of confused users (in both the #emacs and #clojure channels) who added melpa because some library recommended it in their readme and they didn't realize it would cause every package they use to also pull from the unstable branch. It is a huge support headache.

However, these days I only very rarely find packages that aren't available on Marmalade. When I do, it's usually enough to ask the maintainer nicely and they start publishing to Marmalade; it's not a difficult process by any means.

Fair point.

But one of the issues with Marmalade is that anybody can fork your project (patch it or not) and just push it. With MELPA, they try to get the original authors to submit the projects. If you've got patches, they are pretty strict about it and encourage you to get them merged in the package rather than accepting a fork.

Hmm. Is there a particular repeated source of breakage? I only use MELPA, and apart from the recent nrepl->cider migration (which was intentionally piloted on MELPA) I've not had any instances where my work was hindered by package issues. And as a maintainer, I update my packages daily.

Or a feature. ;-) Don't forget that el-get has been popular for years, and it pulls dev versions of libraries. I don't see any compelling evidence that breakage is more frequent for MELPA users than for those who only use Marmalade.

It's correct that we don't want our current packages to build off non-master tags or branches, and that's because we've a bigger picture in mind. It's a concrete goal of MELPA is to provide two parallel archives of packages: the existing one, filled with "bleeding edge" packages, and a new archive containing "stable" packages which have been built from the same upstream sources, but using existing version tags found there. We're making progress with this goal: see https://github.com/milkypostman/melpa/pull/1407, for example.

If we can pull this off, this will yield the best of both worlds: users will get known-good versions of packages, and at the same time they will be confident that the stable packages came from the upstream developer's source tree (which isn't at all assured with Marmalade). It will also make releasing a new stable package as easy as tagging a source repository.

Recent versions of `package.el` allow packages to be pinned to specific package archives, which lets those concerned about bleeding-edge breakage pick and choose between "stable" and "unstable" packages on a case-by-case basis.

(shameless plug)

Don't you want a nice Nyan Cat in that modeline in the sky? ;).

http://nyan-mode.buildsomethingamazing.com/

(shameless plug)

And don't you want the current weather to go alongside your Nyan, thanks to an Emacs minor mode inspired by a Hacker News comment?

https://github.com/aaron-em/weatherline-mode.el

Nyan Cat endorses this plugin!

https://dl.dropboxusercontent.com/u/216352/weather.png

Awesome!

Mind if I grab a copy of this image, to use with whatever attribution you like, on the repo README? I don't use nyan-mode myself, and it'd be nice to have the screenshot to show people who find the repository.

Sure, go ahead :).

I'll put link to and/or a screenshot of your project somewhere in the Nyan Mode page/readme, as you wrote it was inspired by a comment about Nyan Mode ;).

Thanks -- but you might want to wait a little while; someone opened a Github issue pointing out that the API offers better weather info than I'm using, and also linking a weather icon font I didn't know existed, so I'm mid-rewrite right now. It'll look a lot better once it's done. :)

Any chance of getting this added to MELPA? :)

Sure! There are a couple of issues I want to close on it first, though, so it may be a little while; on the other hand, once I've done that, it'll be a lot niftier than it is right now, and a bit more reliable besides.

Even though 'Nyan Cat' breaks things other plugins I'd like to use (like Powerline.el) - I still use it anyway.

It's silly and I'm glad you made it.

Thank you! :).

Could you tell me (or open an issue on Github) how it breaks other plugins?

Meh, I have lots of changes to add, but I keep procrastinating here on HN instead...

Ì wonder if some Emacs people intend to migrate to LightTable in a few years?

I'd bet on a clang/gcc evolution, emacs has made adaptation/absorption a native specialty, LT will probably give it a push.

Emacs loves diversity. As a dinner.

I'm still not 100% sure Emacs is LightTable tolerant though.

this, but without the contentious overtones.

wait, let me back up for a moment wrt the original article. that screenshot in the article is not emacs. i can't give you a screenshot of emacs, because emacs doesn't even depend on a windowing system for near-maximum awesomeness. it is my go-to text editor, and i very likely will (progn several of these snippets into my .el files.

that said, we do have have windowing systems now, with some better ones on the way, not to mention touchscreens. i haven't tried out lighttable yet, but i intend to, and i greatly hope that either (1) lighttable follows in emacs footsteps of being fully scriptable (as opposed to the adopting a plugin model that's so typical of java ides) or (2) emacs devours all of that beyond-code-folding -- how best to say it? -- code-exploding (?) awesomeness that lighttable attempts to bring and that, to me, appears to map perfectly onto this new world we find ourselves in where computers are not giant boxes attached to printers anymore but are, instead, whole buildings attached to touchscreens.

doesn't matter if your program's a crocodile or wildabeast: adapt or die.

More than windowing systems it's a different abstraction layer using what appears to me as being dom trees with very capable yet uncoupled presentation capabilities (css) instead of emacs buffer + text-properties, font-lock etc. Hoping it will unleash ideas, just like lisp did in its days, by providing a better language for logic/code interactions.

It's probably worth looking into the scope and design of LT plugins, they do (ostensibly) strive for full scriptability. Seeing some of the stuff people are doing integrating dev tools, tutorials (possibly one of the killer features in the future), etc. gives me some hope as an ardent emacs user that they may be onto something with LT.

I wonder what the fad-editor in LightTable's place will be called in a few years?

What was it a few years ago? I'm going to guess that whatever the answer is, it didn't have anywhere near the extension capability of either Emacs or LightTable.

Only Textmate then ST2. Other editors like Scite, Notepad++, Ultraedit have huge amount of users but they aren't passionate about the subject...

A few years ago I would have gone with Sublime, and TextMate before that. I haven't tried extending LT, so I don't know how easy that is for a mere user. Both Emacs and Eclipse are very extensible, but only the former provides a smooth path to go from tweaking a few config variables and defining some macros, to writing serious extensions. I gather LT is mostly in ClojureScript (?), which suggests it's more like the former, but I would have to spend more time with it to say for sure. I played with it a bit, and it looks pretty, but it's not aimed at the projects I'm dealing with now.

That's pretty uncharitable to LightTable which is doing a number of things differently. Inline evaluation, and great support for ClojureScript with a connected repl to name a few.

Ok, what would be the next fad Javascript wrapper be called in a few years? (does anyone remember CoffeeScript?)

I'll certainly give lighttable.el a try when somebody decides to write it :)

I am curious what the upside of doing so would be.

I'd like to see graphics inline, for example. Another one: in Emacs, to display inline docs, you either use the modeline, or a buffer, or a tooltip. It could be nicer... The amount of hackyness needed for adding something like a Markdown preview bothers me..

To me, LT could be Emacs with better rendering.

I really enjoyed learning Emacs, its a great design, like an open-world game. I want more apps to capture that.

Emacs supports inline graphics; you don't see the capability used all that often, but it certainly exists, and has done for quite some time.

Inline documentation doesn't seem all that desirable in the first place; from the screenshots I've seen, it looks like it would get in the way, which documentation in a separate buffer doesn't do. (I'm half tempted to implement inline documentation for Emacs Lisp mode as a proof of concept, mind you, but I really don't see the point of it.)

> Emacs supports inline graphics; you don't see the capability used all that often, but it certainly exists, and has done for quite some time.

Fwiw, it was added in Emacs 21 (2001): http://www.gnu.org/software/emacs/manual/html_node/efaq/New-...

Previously that had been one of the differentiators between GNU Emacs and XEmacs, the latter more enthusiastically adopting GUI-, image-, and mouse-related features. I believe XEmacs got inline-image support sometime in the mid-'90s, and showed it off by including a display of the XEmacs logo in the default startup buffer.

> Emacs supports inline graphics; you don't see the capability used all that often…

Well, except for every time you start Emacs :-)

(Yes, assuming you haven't disabled the splash screen)

…I'd forgotten all about it, but yeah, you definitely do have a point.

https://github.com/Fuco1/litable

I thought it was a fair question. You're being downvoted by overly-sensitive emacs junkies :)

I know I'm keeping an eye on lighttable (I'm an emacs users since forevs) -- it's definitely the only modern editor that seems geared to possibly being a match for emacs in the flexibility and customizability departments.

But of course, historically, emacs just incorporates whatever's interesting in other editors and continues on, more powerful than ever.

It's the borg of editors.

Much like Linux is "the last OS": http://linux.slashdot.org/comments.pl?sid=101317&cid=8633695

I like the concept of treating the smallest unit as a function. If only the emacs mode wasn't so light weight!

Speaking as an "Emacs [person]", no.

I love the concept of LightTable, basically a new Emacs with a redesigned architecture and plugin system.

I don't love that it's written inside a WebView. I don't love that the best cross-platform graphics library we have is the mess we call HTML+CSS+JS. I don't love that I have to compile Clojure to JavaScript and run it inside a WebView in order to do anything to customize it.

On the other hand, I love the simplicity of the UI of emacs. But I don't love how it's decidedly focused on text-only and its GUI is a second-class citizen. (Try scrolling per-pixel rather than per-line, and consider that tabs can only be implemented as a complete hack based on the ruler area.)

I love that Emacs Lisp compiles to bytecode and is interpreted natively. I love the simplicity of the language and its implementation and how it's integrated with Emacs. But I don't love the language itself.

If you're on a mac, the railwaycat port of emacs has pixel scrolling with the trackpad/mouse out-of-the-box. It's not as crystal smooth as you'd hope for, but it's decent.

http://snag.gy/g8NIF.jpg

Oooh, neat! Might have to check it out, thanks!

I'm 100% with you. Feels dirty to write Clojure that becomes Javascript, I rather be writing Lua or Scheme or Python. But LT already exists, and the imaginary editor we want doesn't.

I tried pretty hard to write it, but gave up because I took the wrong approach.

I tried writing it in C and Objective-C. But this isn't cross platform for starters. Plus, C is really hard to extend cleanly using a scripting language.

I've deleted the project since, but there are probably forks floating around[1]. I'll probably give it another shot one day when I learn more.

[1]: https://github.com/search?q=Leviathan+ide&type=Repositories&...

I don't "plan" to, but I hope for it to be possible. In a couple of years, yes.

LightTable shows great promise as an editor and it's design makes it well suited to being an environment in the future.

I'm just worried that before LT gets to become what I want it to Emacs will already have what is attractive in LT. For me it's ClojureScript and much more flexible UI. If Emacs gets Guile as it's scripting language (and I think: Scheme > Clojure > Elisp) and it's UI somewhat reworked (and threads, and easy bindings to compiled code - all of which is being worked on or at least seriously considered), the decision to migrate to LT will get much harder.

Anyway, LT is the only possible choice for me other than Emacs. There is no other editor which could replace Emacs for my use cases and I don't see new ones emerging.

As a side note: I have some hope for editor embedded in Pharo. It got much better this year and continues to evolve, and being a part of Smalltalk image it is very easily hackable. Having strong editor with things like Moose/Roassal/Glamour natively integrated would be a huge win, but that's probably something I will need to do myself :)

If you are interested in helping with the Editor and improving text support in general... the first step is to help with the new text model. If you are interested, contact us. It would be nice to have that ready for Pharo4 :-)

I was under the impression that the new editor is already in Pharo 3? I don't remember all the details, but I think I at one point saw some rich editing classes while browsing packages in my image. It implemented line-numbers and other niceties. But it may have been something I installed from squeaksource. Anyway, I only recently started playing with Pharo 3, and noticed many improvements to editor, but didn't have the time to investigate so I just assumed it's already done.

I would really like to contribute somehow to Pharo development, it's absolutely fantastic piece of software. I went through tickets on official bug-tracker, but there are many of them and it's hard to tell which are important and which are being worked on. (BTW: Komitter is a very nice idea!) I didn't write to the mailing list, because I don't have (especially lately) enough time to do anything substantial; I just wanted to get some simple regression (for example) which I could fix in a couple of minutes/half an hour. The section of bug tracker with tickets like this would be a great help. Otherwise I'll certainly try to get involved more once I have a bit more free time :)

As a long time emacs user (and lover) I wish RMS and other emacs developers would take his quote to heart more in emacs development. Emacs is shipped with too many things.

Emacs finally has a really nice package manager, so I'd love to see a version with minimal default packages. Do I really need java-mode if I never, ever will use Java? Calc when I have R? SMTP support? No, I need absolutely none of this.

The current policy (as enunciated by Stefan Monnier, who took over as maintainer from RMS a few years ago) is for new packages to be added to the package archive unless there's a very strong argument for their providing core functionality. (Packages that already ship with Emacs are unlikely to be removed from the core, though.)

I've heard it's actually being considered to move org-mode and eshell into packages, provided the release process can be ammended to generate releases which include packages by default.

Obligatory link: http://nullprogram.com/blog/2009/06/23/

I don't get why this is a problem - almost everything that comes with default Emacs installation is not loaded by default and so you don't even need to know it's there. Or you can just remove these modes altogether from your installation, no problem. On the other hand, if something made it to the Emacs core, it's probably more stable and easier integrated with other plugins. There are many plugins in the wild which do a great job by themselves, but fail miserably in the presence of other plugins enabled, and such plugins are not in Emacs (or I didn't see them yet).

So why does it bother you that there are modes which you don't use? They aren't loaded as default anyway.

I've found the latest revisions of Emacs to be incredibly ugly, and I have to turn off most of the crap (menus, etc.) to be comfortable.

Stock Emacs also seems to want to open up a minibuffer when I've told it "please just edit this set of files". It's also got some idea that I want to to suspend the shell I launched it from (er, no, not ever).

The argument I see on forums is: "Well, the right way to use Emacs is to just start it and then never leave, so you only have to get that stuff out of the way once."

So I spend 30 minutes figuring out the right elisp stuff to disable so I can get rid of the crapware.

Crapware in Emacs. What's next, AOL sponsorship splash screens?

UniPress Emacs (aka Gosling Emacs aka Soft Hoarder Emacs) had a VI emulation mode, that when you went :q, switched you back into a shell buffer that had its mode lines hidden, with all the keyboard bindings set so you couldn't tell you were in Emacs.

The only vi command I know is :q!

Earlier this week I was using ed(1) to edit a conf file, because (as the parent says) I only know one vi command :-)

This is the same problem I've run into. I want to try living in Emacs, because there's pretty much a mode or package for everything, but a few of the basics don't work quite right to a point where that is usable yet. For instance, terminal emulation. There's terminal mode and eshell, but if you have even a mildly complicated PS1, all you get are control codes everywhere. Just strange, off-kilter behavior.

At this point, I'd be happy if I could just embed iTerm2 in a buffer and be done with it.

Have you tried "M-x ansi-term" ?

Yup. It only looks slightly less weird than eshell or regular term mode. Still makes my ZSH prompt look screwy and still causes strange breakage with apps (iotop was completely unusable, for instance, as was anything ncurses based)

If you prefer a more vim-like workflow (i.e. jumping in and out of your editor from your shell), a good solution is to fire up emacs in daemon mode to run in the background, and then connect to it using emacsclient.

I automatically run

  emacsclient --daemon

when my OS boots up.

In my .zshrc and .bashrc files, I use the aliases

  alias e='emacsclient -t'
  alias vi='emacsclient -t'

to give me quick access to emacs from the shell.

I'm not sure if this addresses your problems entirely, but it does keep you from having to deal with all of the crap that loads on startup.

I have a moderately well written emacs.d, and I'd be happy to see a few use it/learn from it/correct me/give feedback.

Just startup emacs (24+) with the init.el and it will download dependencies from elpa. Will have to restart once afterwards to make the theme right.

Screeshot : http://i.imgur.com/2wmxir5.png Source: https://github.com/jaseemabid/emacs.d

I hoped the article would be not about look-and-feel, but about building a stripped-down version of Emacs without obsolete parts like TRAMP or LEIM (because there are system-global subsystems for those nowadays), or maybe even trying to tear chunks from MULE.

In a perfectionist "must be a pure gem, no imperfections allowed" sense, ton of seemingly unnecessary libraries is the only thing that actually bothers me about The Editor.

Many of these suggestions seem similar to Steve Yegge's "Effective Emacs" which I can recommend if you are a new Emacs user (or even if you've just not seen it before):

https://sites.google.com/site/steveyegge2/effective-emacs

I like getting rid of toolbars and such, but still like to keep the modeline and gutters.

If you reflect for a moment, obviously a minority of HN will be made alienated and uncomfortable by this sexualized humor. Do you really want this?

Well another minority might view strip teases as an act of empowerment and self expression, and be made alienated and uncomfortable by your sex-negative viewpoint. How would you balance the interests of these two minorities?

Evidently, by changing the title.

Personally I thought "striptease" was a much richer metaphor for what the linked article showed - the removal of "dressing", piece by piece. But then I'm not a prude with a stick up my ass.

Seriously, what the fuck with the title change this time? Is the term "strip tease" offending, really? There used to be a Belgian-French television show called just like that: http://en.wikipedia.org/wiki/Strip-Tease_%28TV_series%29

I'm guessing it was a belated attempt to stifle the inevitable social justice flame war.

Obviously the professional way! By inviting them to the center of the office to discuss frankly their viewpoints on sex until everyone quits from misery. I'd also scatter conservative religious pamphlets and dildos around the office to encourage everyone to participate.

Because obviously it would deprive a reader to explain how to remove GUI widgets from an emacs frame [window], without making a metaphor of the window as a naked female, and the widgets as clothing, and the process as a striptease. This is exactly how a mature team of mixed-sex professionals discuses emacs widgets. An HN thread on removing emacs widgets without overt sexual analogies [0] would be a unnatural, stilted place full of repressed sad people.

[0] https://news.ycombinator.com/item?id=6983088

Mind explaining where it was implied that the window represents a nude female? Just because the post uses some racy humor with the striptease metaphor, doesn't mean it implies any particular sex.

This could just as easily be a man, woman, android or RMS himself stripping (and considering that the whole post is at the backdrop of an RMS quote taken deliberately out of context, I wouldn't be surprised if it was meant to evoke the latter).

RMS himself stripping

When I started reading, I was worried that this is what the article was going to be about.

> Mind explaining where it was implied that the window represents a nude female?

This is actually a great feature in online debates when you want to find something to argue about. In particular, this feature doesn't force the first party to explicitly state offensive things in order for the third party readership to take offence. I call it, offence inference. Can a sentence be interpreted in an offensive light, by anyone? The offence inferer will find the implicit offence!

Thank heavens, I was hanging by the edge of my seat waiting for someone to make the inevitable comment.

If THAT makes you uncomfortable, then obviously you haven't seen THIS: http://www.youtube.com/watch?v=D1sXuHnf_lo

It's the ASCII art social commentary about the cultures surrounding various popular programming languages that I hope people will find the most offensive about that video. Well worth pausing and zooming in when he mentions your pet programming language.

I cackled! Thank you for pointing that out.

Alas, I must confess that I have written Visual Basic (VBscript) code in Emacs.

A while back I was screwing around with a project which attempted to generate, via the Windows speech synthesis API, output vaguely resembling SHODAN from the System Shock games (example: [1]). The most I can say for it is that I didn't entirely fail; despite having access to a quite good female voice (NeoSpeech "Kate"), and despite SAPI 5 offering what I found a surprising degree of flexibility, there's only so much you can do with it; I got closer than I expected, but not close enough to think it worth releasing. [a]

In any case, VBScript is the handiest way I could find to screw around with SAPI, and it turns out there is a Visual Basic mode for Emacs [2]; I found it to be remarkably not bad. Nothing could make working with Visual Basic other than painful, but Emacs comes as close as anything else I've ever used.

[1] http://www.youtube.com/watch?v=5iZMD_eCpEo

[2] http://www.emacswiki.org/cgi-bin/wiki/visual-basic-mode.el

[a] I've just unearthed it, and it hasn't yet succumbed to bit rot; maybe I'll throw it up on my Github account just for the hell of it.

It's a joke. For grown-up people with a sense of humor. This is the internet. If you don't like it, vote with your mouse and don't click on it.

Here is a screenshot of my emacs.

http://farm8.staticflickr.com/7346/12104669276_154ae3d98f_o....

Scroll bars and menu turned off. Theme solarized and transparent background. I feel good when I am programming :)

A transparent background adds too much visual noise in my opinion. The same is true for line numbers.

Line numbers can be handy to locate compiler errors. I removed it once but then it became a lot harder to locate where the program was causing problems or where the compiler errors occurred. I would like to remove them but I guess I am stuck with it ....

You should run the compiler inside Emacs (M-x compile). That way you can easily jump to error locations. (You can also use M-x goto-line to quickly jump to a specific line)

Serious question, are Emacs users seriously in the habbit of typing things like M-x some-long-command-with-minuses? In Vim to go to a line number it's just colon line number, e.g. ":34" goes to line 34. I mean that's the default, not something that's been keymapped. Or do you guys end up keymapping things like that frequently aswell? Then again you guys don't have modal editing so I can see why it's always M-x before doing something non-edity, so it might seem assbackwards for a Vim user :)

I take for instance the most common commands I use in Vim to edit with that I use 95% of the day and they're rarely more than a single character or 3 at the most.

If it's a command we start to use often we bind it to a shortcut (If I may presume to speak for emacs users). It's not much different than shell commands. Some you just type, some you create an alias/function shortcut for.

I recently discovered an emacs package that lets me type M-x and then the first letter or two of a command that I used recently and it completes it for me from there (smex.el). That's even easier than coming up with a new keybinding.

Just to try and help you understand how emacs users see it, your most common vim commands that are a single character are actually sometimes a single character and sometimes they need to be prefixed by an ESC to get you into the right mode. That inconsistency is what killed me when I tried to use vim. In emacs every command is always the same, no need to keep track of what mode I'm in.

Why go to all that trouble? There's always "emacs -nw" to get pretty minimal in an xterm...

You don't get as many color choices and you don't get as many key bindings.

"C-M-%" is pretty much impossible in the terminal. You have to do "M-x query-replace-regexp", or make some other custom binding.

You can hit Esc before the combination to fill in for M and then it is just C-S-5 for me, which is certainly doable?

In some (most, I thought, but maybe I'm wrong) terminals, you can only use the control key to generate an actual control character -- i.e. one of ASCII 0-31. The ctrl key basically unsets bit 64 from the typed key, so ctrl-A through ctrl-Z generate ASCII 1-26, ctrl-@ generates ASCII 0 (though traditionally ctrl-spc gives this as well), and ctrl with [ \ ] ^ _ generate the remaining ASCII 27-31. Ctrl-? sometimes generates ASCII 127 (pretending that ctrl actually subtracts 64 instead of unsetting the bit), but otherwise there are no remaining ASCII values left for such extensions as ctrl-%.

No, you're right. As far as I know, standard vt100/ANSI terminals do not have any special escape sequences for control key combinations that don't map directly into ASCII.

Like Zmacs of the Lisp Machine. Mostly full screen, with a mini buffer and the status line at the bottom.

A lot of interaction then happens with a type-out buffer which comes down from the top and disappears when not needed.

Rule 34, what have you done?

-1, 1 and t have worked for me in setting most modes except that blasted scroll-bar-mode, which it turns out calls for a 0 - what the heck! Thanks for a super post.

(scroll-bar-mode -1) and M-- 1 M-x scroll-bar-mode RET both work for me.

Yeah, when 0 also didn't work, I took another look at it. Turns out I needed to call (add-hook 'server-visit-hook 'my-custom-function) with the call to scroll-bar-mode inside my custom function, because I'm working off an emacsclient. Now I have my choice of -1, 0, nil, etc. Finally sorted out. :)

nice stuff. My .emacs keeps the mode line, which I like, but turns off the scrollbars and menu bars, and sets a wide fringe (though not quite as wide as shown). I don't like text jammed right up to the edge of the window.

Anyone know how to achieve a "fringe" on the top and bottom? And also how to do it in xterm windows?

Just discovered, you can create a "fringe" in xterm by the -b option:

  -b number
      This option specifies the size of the inner border (the
      distance between the outer edge of the characters and the
      window border) in pixels.  That is the vt100 internalBorder
      resource.  The default is ``2''.

If you use Emacs in the terminal, almost none of this applies as they are there by standard.

That fringe is neat. Anybody know if Vim supports something like that? I've never been able to make complete sense of vim's line length options. They never seem to work quite "right".

There are a number of hacks to do it as plugins, but I can never get them to play nice with other plugins :(

It's very unfortunate that Emacs' default appearance is so terrible. I slogged through figuring most of this stuff out myself a few years ago.

emacs -nw

It looks great when it combine it with amber-on-black Glass Tty in my xterm.

:TCTYP GLASS

Nice!

For vim I like to use

    " remove the toolbar
    set guioptions-=T

    " remove scrollbars
    set guioptions-=L
    set guioptions-=r

And in macvim:

  if has("gui_macvim")
    autocmd GUIEnter * set fullscreen
  endif

Ohh! I've been using Cmd-Ctrl-f like a loser all this time!

http://www.gnu.org/fun/jokes/ed-msg.html

Are there usability reasons for a dark text on a light background being default in almost all editors?

It depends on the lighting of the room you're in. In a well-lit room or outside (I love hacking outdoors) a light background will reduce eye strain, but when it's darker around it's less suitable. In any case, it's always easier to darken a light screen than to make a dark screen brighter given that you rarely see laptop screens brighter than 300 nits.

plug: I wrote a minor mode that's similar to this: https://github.com/dandavison/minimal (hi bzg!)

I sleep with emacs regularly, yet I am seduced ...

swalpa uppinakayi haakappa.

Wait, do you mean fall asleep on emacs?

Until I break the habit, thank God for undo.

For some who works with split windows, i don't like the idea to trim the space and hide the status-bar, but everything else is great.

   ./configure --prefix=/usr/local --program-prefix=t --without-x11 --without-all \
   && make -s bootstrap && sudo make -s install

Reply on news.ycombinator.com