Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Until it goes wrong or you have to delve into elisp or you get carpal tunnel...

After 20 years of switching back and forth I decided I wanted an extensible editor not a programming language with an editor built in. That's worked well for me.

I really always just want the simplest thing that will work as I need to rely on it entirely and understand how it works. If I was to use emacs, I'd probably use mg as shipped with OpenBSD.



> Until it goes wrong

Why? Emacs reports errors fine in my experience and if not it includes a debugger.

> or you have to delve into elisp

What's the problem with elisp? I guess its a matter of preference, but in my opinion elisp is easier to understand than vim script. Emacs includes extensive(!) documentation for it in it's base distribution. Granted, it's a dated language nowadays, but 3rd party libraries - easily installed through elpa - like dash.el and s.el make it a much more pleasant experience.

> or you get carpal tunnel...

Again: Why? This article is about viper-mode which emulates vims key bindings so RSI should be exactly as likely as with vim itself. You could also adapt them to your needs, of course.


>What's the problem with elisp?

So I was trying to make Emacs not drop its stupid temp files next to the opened file and found this piece of incomprehensible code:

    (setq backup-directory-alist
          `((".*" . ,temporary-file-directory)))
While in Vim:

    set backupdir=~/.vim/backups
Oh, and it seems I'm missing line numbers, let's google on how to enable them and found this page http://www.emacswiki.org/emacs/LineNumbers

I still haven't gotten it to work.

Meanwhile in Vim

    set number


This seems to boil down to "I don't understand things written in a language I don't understand" which is fine and all but haven't you ever been curious why so many people will assert it is worth the time to learn?

I think the second part kind of misses the point, as someone in vim has already implemented the feature you wanted, the way that you wanted. So you are basically turning on a parameter.

What is much more important to ask here is how would I implement that functionality [in whichever editor] from scratch, and can I even do that?


That's because EmacsWiki is old, poorly organized and not always up to date. It's to be expected when the area to cover is this huge. "Meanwhile", in recent Emacsen, what you want is

    linum-mode
You can also customize this with

    M-x customize-group RET linum
where you can set font, format for numbers and enable/disable line numbers globally.


Things that look like (a . b) are pairs of things a and b. Enclosing them in brackets, ((a . b)) means making a list, with one element, which is that pair (you need a quote or a backquote before it). (list (cons a b)) is the verbose equivalent. In this case, I think, ".*" is a regular expression matching file names, and temporary-file-directory is the directory for file names that match the regular expression.

This is actually quite nice to customize because you can change little bits of behaviour by just adding another pair (regex . string) to the list. Typing "C-h v backup-directory-alist" also explains what the list is for and lets you customize it with a gui.


The reason the backup-directory in emacs is an association list instead of a simple string is that some people might want some backups in some dirs and other backups other places. More powerful → more complex.

Turn on line numbers everywhere by putting this in ~/.emacs.d/init.el:

    (global-linum-mode)
(Yeah, EmacsWiki is a mess, but that's not emacs' fault.)


When I spent a few weeks learning Emacs -- I had to filter out EmacsWiki because it lied to me so many times. :(


Inner system effect for you that is.

I don't really want masses of extensibility but what I want is something that works out of the box, is understandable and doesn't require masses of customisation that I have to drag around with me everywhere.

On this basis using viper with Emacs is as illogical as using vsvim with visual studio. One should use vim (or vi which I'm equally happy with)


This assumes you're free to choose your development environment. I've seen many projects forcing everyone to use the same development environment.

Things like vsvim or emacs for eclipse become incredibly useful when you want to keep your productive habits in these clunky IDEs.


Mentioning elisp in the face of viml is questionable...


Unless you need neither at which point less is more.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: