Wanna have fun with emacs? Try to integrate evil mode nicely in different plugins. Especially if you use totally different key bindings in vi (non qwerty layout for example). It was very painful experience for me. Yes, vim is far from ideal, yes neo-vim is looking like to be next iteration in vim evolution, yes no parallel tasks execution is pain. But at the same time there is vimproc. For clojure integration there is fireplace.vim which is also amazing in my opinion, for git there is fugitive. I don't see any real comparison in this post, more like "I was bored with vim, now I use emacs".
Yep, pretty much what I have experienced. I'm a vim user who uses emacs for clojure, and I've found a lot of incompatibilities with other plugins. It's not too bad; evil + paredit make up for those deficiencies.
I tried evil-mode myself and came to a similar conclusion re integration.
And for package management there's vundle, neobundle, and pathogen. And after my recent discovery of vimproc, I'm now motivated to resume writing plugins!
Yeah, evil-mode just doesn't play nice with lots of emacs utilities.
It's a good idea to use evil-mode only in code/text buffers and stay out of it when using e.g. GUD debugging. This, unfortunately, means that you're going to have to learn two sets of keybindings, the vanilla emacs ones and vim keys.
You have exactly the same problem with a non-standard key-binding/layout and vim. For instance, the default file browsing plugin netrw hardcodes its shortcuts…
Gah, the tutorial keybindings! They are mad. I've been using emacs for a very long time, and I can't imagine using those to navigate. Emacs has perfectly reasonable default keybindings these days, they just aren't the ones mentioned in the tutorial.
Usually the strong defenders of emacs tell you that you must use c-n c-p c-b c-f to move because those are better and you will adapt in a short time.
Then the strongest defenders of emacs tell you that you must use whatever you want because the purpose of emacs is that the editor must adapt to you and not the opposite.
Actually I think the strongest defenders of emacs say you use C-s and the like for most navigation. Moving character-by-character is slow and inefficient, so the argument about whether C-n C-p etc. are better or worse than hjkl is irrelevant.
I have my own code editor which is more like vi than emacs, but I'm using interactive search in it.
It's the vim defenders who will claim that the home key navigation is a must. Emacs advocates don't much care from what I've seen. Some of them will be roused to suggest that you learn to use searching better.
Vim defenders will also tell you to use search. Also, why would even Emacs fans recommended corded combos over single keypresses? Give my pinky a break man!
Because it means you don't have to jump in and out of different modes. The biggest thing that kept me from using vim was _constantly_ typing in normal mode and trying to issue commands in insert mode.
Is constantly hitting the Escape key (even remapped to Caps Lock, or using ^[) really any better on your pinky?
I use ^[, and I use my pinky a lot less than I would in emacs, because I do a lot more in command mode than I do in a single emacs chord. I view "insert some text" as its own command. Vim's commands are structured so you can combine orthogonal pieces, where emacs has a separate chord for everything.
Vim does the orthogonality thing better, I'll admit, but Emacs' separate chords tend to follow useful patterns, too.
For example, moving forward a character is C-f, moving forward a word is M-f, and moving a balanced expression forward is C-M-f. Same with b for backwards movement. C-a moves to the previous beginning-of-line, C-e to the next end-of-line. M-a and M-e do the same with statements in place of lines.
I can't even remember at this point how much of this is standard, but I've replicated the forward/backward movement for killing: C-d deletes a character forward, M-d kills a word, and C-M-d an expression. C-h deletes a character backward. Guess what M-h and C-M-h do.
Of course, both editors let you do basically whatever you want, so really the text input issue is just one of whether you prefer chording or modal input. And I'm not saying modal input isn't useful; Magit's input system is closer to vim's than to the rest of Emacs, as is Ediff's, and I like it that way, but I prefer chords for editing -- less state to hold in my head.
Sequential chords, though, like C-c C-v C-d, are right out, and using C-n and C-p and co. for up and down sucks, especially when I try to use M-p to select the last input in minibuffer history and hit M-o instead, prompting me to select Bold, Italic, or Other. I'll change them eventually; the hardest part is deciding what to replace them with.
/aimlessramble. I guess it all just boils down to "Use the tool you can best configure to work the way _you_ want it to." I think the linked article was trying to make the case that Emacs can be that tool for vim users.
At least it's a "home-row pinky" with Emacs' Ctrl, too. :)
Personally, though, I don't find the worst strain comes from the placement of Ctrl. The worst comes from the awful staggered layout of keyboards that serves no purpose save for a long chain of HCI backwards compatibility with the typewriter. I hope someday keyboards like the TEK (which, incidentally, gives a perfect spot for Alt or Ctrl under the left thumb) become more commonplace, or eye movement-based systems supplant the use of one's hands for focus control.
Hm, fair complaint. At some point I found that hitting ESC immediately after typing became habitual. I find myself accidentally doing it outside of vim quite frequently. I've heard others make similar statements to yours, though. If rebinding to a different key doesn't solve it, then modal editing may not be for you.
I'm a fan of C-n and C-p; I often find myself using them even in Sublime Text or other editors (even in a text area on a web page). But for some reason I find C-f and C-b much more obtuse. Part of it is that in a QWERTY layout, "f" is to the left of "b", and yet "f" moves the cursor to the right. Also, assuming you press Ctrl with your left hand, "f" is more natural to use with your left hand, while "b" is a bit of an awkward reach, making it natural to use the right. This left-right switch is awkward, especially combined with the aforementioned direction reverse.
On the other hand, C-a and C-k (especially in combination with each other) and C-e are incredibly useful, and once I discovered them I immediately started using them everywhere.
The nice thing about the C-{n,p,f,b,a,e} is they work on the bash shell command line by default. So learning them is actually really useful, even outside of emacs.
I use the arrow keys in both Vim and Emacs. There are enough keys to remember (most of which I forget all of the time... like paging up and down, have to look that one up every time) that I don't need another set of keys to remember. Arrow keys work just fine.
Tell you the truth, I've used Emacs for a long time now (~10 years) and I don't know if I use the C-{n,p,f,b} or arrow keys. I'm more likely to move in larger chunks: search, move by word (M-f, M-b), line (C-a, C-e), etc. If I need to edit a word, I will kill it entirely and re-write it.
same exactly for me, i use sometime the arrows or the other keys or c-s etc.... i don't mind the jk vim keys as well when i am in vim, either way it's all about your brain being good enough to context swift in .... context
Thankfully I am blessed with the ability to move my forearms.
I've heard a lot of people talk about keeping their fingers on the home row, and I more or less do that when I'm typing text like this, but for general navigation? I've sat next to a number of people who do it, and I get around my editor faster than they do. Based on this anecdotal evidence, I don't think moving my hand a short distance to reach another key is a significant speed cost.
Then how do you move multiple lines at a time (4, 16, 64, 256)? To move 16 lines down, I press C-u C-u C-n (of course, the control key stays down the whole time). You either have to press C-u C-u then move your forearm to the arrow key and press down, or press the arrow key 16 times.
(Each C-u is a power of 4. You can specify any number by typing it after the C-u, for example C-u 100 C-n to move down 100 lines.)
I cannot recall the last time I wanted to move 16 lines - that would imply I stopped to count the lines. What I invariably want to do is "move down one paragraph" (C-down) or "move to that spot I can see on the screen" (1-6 lines, tap up/down; 6-30 lines, hold the down key for about a second until I'm within a line or two, then tap up/down a couple times; >30 lines and use pgup/pgdown to get closer). For anything further away than that, I'm going to use isearch to get closer.
Sometimes I want to make a complicated motion in the horizontal and vertical axes at the same time in a context which is not well-formatted source code and hence has no good paragraph/word landing points. For this I move my hand slightly further and grab the mouse. It always amuses me watching people try to do it "the right way" and then spend 30 seconds trying to work out what sequence of buttons will get them there, then spend another 30 seconds remembering what they wanted to do when they got there.
I'm not trying to minimise the number of logical keystrokes, I'm trying to minimise the time and distraction of navigation. A few simple operations combined with key repeat seems to work really well. Lots of people seem to neglect the power offered by key repeat.
I'd love to meet somebody who could navigate source code faster than me and learn how they do it. When I do, I'll probably change my approach. However, I've worked with a lot of different people who used a lot of different approaches (yes, including that one where you display the line offset from point and type the number of every jump) and in the past decade I have not found any of them to be faster than me - although I have found a few who were roughly the same speed.
> I cannot recall the last time I wanted to move 16 lines - that would imply I stopped to count the lines
I'm sure something like this is possible in Emacs, but in vim I have it set up so that my current line shows the absolute line number and other lines show the relative line number.
If I'm eyeing a particular line that I want to jump to, I just read off its relative line number and hit j or k, according to whether it's down or up from where I'm at -- I'm there. Because I use relative line numbers, the number is never more than two digits.
For more precise navigation (jumping to a particular spot on a particular line), I use a plugin called EasyMotion, which basically lets me jump to any text object on the screen with a few key strokes.
I like the idea of knowing relative line numbers, but I have been unwilling to relinqish seeing absolute ones due to how prevalent it is to see them -- diffs, linting errors, and stack traces often include line numbers, and I find it really helpful to be able to easily find that. Go-to-line is supremely useful, but I also find the visual reminder helpful as well.
In VS, I use VSVim which lets me actually have both absolute and relative line numbers, but it probably wouldn't be difficult to write a vimbinding to bind enabling/disabling the line numbers plugin to a chord/hotkey.
This seems to be one of those arguments where we programmers tend to optimize for the wrong problem. Sure, we may be able to input more text more comfortably with the merits of one text editor over another, but really, I think most of the time spent during programming is reading APIs, headers, other code and most importantly thinking. Typing is hardly the bottleneck.
Except when it is... If you can edit fluently and quickly, _then_ coding is more of a nonissue, you're free to try things out, you can find and fix an error and Alt-Tab without blinking, you can harness this kind of physical flow of noninterrupted work, etc. I've worked alongside programmers for whom typing and editing were indeed quite the bottlenecks. Of course, any programming editor is probably good enough if you learn it.
Agreed. I don't know how anybody could use vi with escape unmapped. It's also very useful outside vi though, since esc is the default 'cancel' key in many cases. For example, most browser dialogs (and keyboard-navigable menus) can be closed with esc, and it works for many desktop dialogs too (at least on Linux).
The more common remap is probably capslock->ctrl, for both vim and emacs users, I but I definitely prefer capslock->escape. During normal operation, my left pinky rides the gap between a and escape(aka capslock). Pressing either requires the slightest of deflections to the left or right.
I keep escape as escape as well. Capslock is absolutely worthless to me.
Or use PCKeyboardhack and I forget the other plugin but on a Mac, I have a brief caps lock mapped as esc, but holding it is control. it works effortlessley.
On my chromebook pixel, there is a super/windows key (labeled as a "search" key) where the capslock normally is on a US keyboard. Since I use super as the prefix key for all of my window manager shortcuts, I use xcape (https://github.com/alols/xcape) to allow that key to function both as super (if I hold it down) and as escape (if I tap it).
These sort of systems are a great way to remap keys; I wish such remapping was exposed by operating systems in a nice stock way.
Why? Isn't that more inefficient because you have to move your hand off to the side. I can type 3 C-n before moving my to the right to do a single down arrow. Maybe I am just used to it by now, and forgot how hard it was when I started, but it makes complete sense to me.
that's the old-school Starcraft way. try mapping caps-lock to control sometime, just to see, it's such wasted real-estate. nothing beats muscle memory and years of practice though.
Caps-lock as control is a nice but unsymmetrical mapping. If you want to avoid pain you might want to use the opposite hand to hold control while hitting a key combo. At least, this is what works best for me. I never have to twist my hand into unnatural positions.
I stick with the default emacs key bindings because many of them work outside of emacs. Muscle memory has me constantly using C-k to kill a line for instance, and this also works in Mac Mail and Safari.
Emacs + evil, sure, but please don't forget vim + slimv. I tried emacs for a bit when I was first jumping into lisp, but was also evaluating vim at the same time. After about 6 weeks I was having fun with vim. About a year later, I was really fast in vim. Fast forward another year or two, I think in vim. There are no modes or movements or searches. There's just what's in my brain and it sort of writes itself. Granted, I'll stop and think to record macros here and there, but otherwise it's all really fluid. Add the fact that I do lots of server admin to the mix, and heyyyy there's vim already there. How ya doing ol' buddy?
Then you add slimv to the mix. Honestly I never gave slime a fair shake. I barely scratched the surface. But once I got slimv up and running, I felt like I didn't need to learn emacs+slime. Maybe there are some things I don't know about that I'm missing out on, but slimv, like vim, let's me think in lisp.
So if you're a lisper and you like vim, don't jump ship yet! Give slimv a shot.
I tried slimv recently and couldn't get it to work with Racket. There's a swank Racket project on github but it was extremely buggy. I also tried mit-scheme and it was buggy as well. It randomly freezes and I don't know why. (latest vim, etc.)
What do you use it for? It seems if you're using common lisp it's perfect, for everything else it works "in principle" but not really.
I've been using the plugin vim-slime (https://github.com/jpalardy/vim-slime) recently alongside tmux in order to do REPL development in Scheme / Python.
To be honest I found it more straightforward to use, and the great thing is that it doesn't require any Swank servers to run, and it works with just about any REPL based language. I find it hard to live without it nowadays, though if you're on windows I would expect you'll have difficulties in using this.
Yeah. I was going to say the only Scheme I have seen run in Slime/Swank is Chicken Slime, which is custom fork that overlays slime to handle specific extensions to Chicken scheme. I also play with Racket and had no idea a slime variant existed! Not that I would want it personally, as geiser only intends to support Guile and Racket thus far.
I think someone already mentioned, but Emacs has a plugin called Geiser. You should check it out it's amazing. I was hoping there's something similar for Vim but sadly there's not.
And yes, CtrlP is probably the thing you'll miss most.
But all the other things I got from switching from Vim to Emacs+Evil easily outweigh the missing CtrlP.
Vim was great, until I wanted to customize it heavily. It is simply not made to facilitate things like: child processes, SSH, understanding my code, a visual interface for Git.
Fuzzy file finder was a thing I missed the most. Fuzzy-other-things-finders like ido and helm are there and work very well, but fuzzy file finding is either slow or incomplete with most solutions. So I found one plugin I liked - https://github.com/justinweiss/fuzzy-find-in-project - rewrote most of it and now I use it exclusively: https://github.com/piotrklibert/ffip
It's documented in the code - more or less - and I'm very happy with it, especially with having multiple directory sets I can change between (which I implemented recently) and how fast it is (aside from initial caching done by the ruby backend).
I actually never thought about releasing it publicly, so the readme is non-existent and the Ruby script is hacked with hardcoded ignores, fonts are not customizable, and it's even possible that I hacked the Ruby gem source at one point. I could clean it up a bit if there was some interest in it.
Actually, Vim is the next Vim--it only seems to get better and better.
After switching to Vim full-time about two years ago, I recently tackled exporting the text from a 10-year old PDF to markup it up using AsciiDoc[1] so I can output HTML and ePub.
It’s over 37,000 words but I was amazed how easily I was able to jump anywhere on the screen with just a few keystrokes fix all of the little things that need to be fixed in a text file.
And because editing paragraphs of text is somewhat different than what I normally do (writing HTML and CSS), it was pretty cool being able to leverage the composability[2] of Vim and how seamlessly that knowledge works in new contexts.
Do one thing well. My text editor shouldn't be managing child processes or SSHing or trying to be a visual Git interface, and Vim does a great job displaying my code so I can understand it.
Programs that "do one thing well" are utterly useless unless you can compose them. Emacs is a tool that composes programs that do one thing well, like Bash or X.
Emacs, as has been said time and again, is not a text editor. It is, if anything, a development shell. It contains a text editing program (the default program), and that program does not manage child processes or SSH or Git.
You could also take the stance that Emacs _is_ a program that "does one thing well:" develop programs. That's the actual task of importance. Text editing is a secondary, ancillary task that owes its importance entirely to the archaic practice of representing complex interrelationships between data and operations on those data as a static linear stream of ASCII-encoded bytes.
Unfortunately, almost all programming languages are like this (hence, "languages"), but if you ever use Emacs to edit Lisp, you'll find that it's far less like text editing than it is like directly manipulating the abstract structure of the program. It does a reasonable job trying to replicate this experience in other languages, but when you have utterly inane constructions like seventeen-precedence-level infix notation, there's only so much you can do.
Do one thing well does not really apply to larger user-interface applications that inherently have to aggregate lots of unrelated functionality. It applies to one-shot commands that you'd use in shell pipelines; that's why the other commandment is to use text streams. The point is that by combining these small utilities which do one thing well, you can create the aggregated functionality you need to perform a higher level task. Whereas if you didn't have these little utilities which do one thing well, you'd be scratching your head trying to figure out how to do something that a big monolithic application can do for you but which you need in a different context, i.e. where running that big monolithic application to do that one thing is very very incovenient if not impossible. Why do people quote this out of context?
If you stop and think about it, it's really pretty much impossible to define the "one thing" a code editor does.
Forcing the user build everything out of shell pipelines is not the goal, and achieves nothing. At some point, it is appropriate to build the aggregate and combine these functionalities for the user so that he doesn't have to do it himself. And in many cases, you end up reimplementing the thing because it is more efficient that way. The shell utility is still there for the user should he need it.
I realize that you're joking, but... vim is a better less than less is, in almost all cases, for viewing code, because you get syntax highlighting.
I'm not a vim user, but I use it to replace less because syntax highlighting is the bee's knees: (you may need to change `vim74` to whatever it is on your system.)
Emacs does a great job at that, too. (In fact, it contains a complete Javascript parser, which is invaluable to me since that's the language around which my professional life revolves.)
It also does a great job managing child processes and SSHing. (Or FTPing, or speaking whatever other protocol you need to use to access remote files.) I can't speak to it as a visual Git interface, but I don't doubt it's at least reasonably good at that, too.
"Do one thing well" is a good start, sure. But why not aspire to more?
It's great to aspire to more, and that's why my system has more than one binary in $PATH. If a project wants to release an awesome $thing_doer in addition to their main tool's function, it should be a separate tool. That way I can use esshhelper and egitbrowser and eftp separately from emacs (yes, I know the names are contrived).
Do you consider the shell an overly-featured program because you use it to copy/delete/create/link files, install packages, etc? No, because it's a tool which loads up other tools for your use, providing some conveniences like job control in the process.
Emacs provides a lisp implementation. People have used this lisp implementation to write ftp clients, web browsers, and yes even text editing functionality; you then use emacs to load some of that lisp code and execute it. I don't say the Bourne shell fails at "doing one thing well" since people write shell scripts and run them from within the shell.
That's how Emacs works though! There's a bunch of TeX junk in Emacs but since I never use TeX, Emacs never loads that lisp. It's just sitting around in a directory waiting in case I do need it at some point.
And Emacs has a command line for its stuff: "M-x".
And if you really want to have separate executables you can do that with small 'emacs --eval' wrappers.
Different perspectives; Emacs has a built-in shell, which is closely integrated with most of the editor's functionality -- for example, Tramp, which transparently supports almost every remote access protocol in existence; if I want to copy a directory tree from host A to host B, in bash I might
and all the key management happens automatically, via ~/.ssh/config and ssh-agent, just as it does when I invoke OpenSSH binaries by hand.
Oh, and lest I forget, if I want to edit a remote file in Vim, I have to either ssh to that host and invoke vim there, or scp the file here and invoke local vim on it, or deal with sshfs or something -- the latter of which might seem like a perfect solution, until you consider that I use all of Linux, OS X, and Windows machines extensively in my daily life, and not all of them do sshfs well or at all. By comparison, eshell's
find-file /user@host/foo/bar/file
is exceedingly simple, and works equally well on whatever machine I happen to be using at the moment. I don't have to worry about marshaling temp files or configurations or, indeed, anything at all; Emacs does all of that for me, quietly, in the background, so that I can spend all my time and mental effort on the changes I actually want to make, instead of doing a bunch of annoying sysadmin work just so that I can make them at all.
There's value in having lots of loosely coupled tools, but it's not the only paradigm worth considering. There's also value in a single, unified interface to an enormous range of tightly integrated functionality; indeed, I've found the result to be something of a combinatorial explosion of productivity.
For example, be an outstanding VM, IDE and a thriving ecosystem of libraries for development in a quite nice (and becoming better with each version) Lisp dialect.
Anyway, that's really a matter of preference. It's ok if you want to tell the world about yours, but try to word it in a way which isn't confrontational for people who have different preferences.
Well, yes. That's what makes Unix OSes so great. Programs all the way down to the command line are separate from the OS. Modules and drivers are also semantically separate from the core.
sudo aptitude purge emacs
sudo apt-get install vim gvim
gvim
Edit: Clearly I'm joking. If you wanted a serious answer, Emacs is just a large, easily extensible program. It's not really an OS. That's like saying Google Chrome (contains a package manager, web browser, text editor, scripting language, and much more) is an OS.
Fast proper fuzzy-find completion on files, buffers and tags that works across multiple platforms and even on files not in source control. In Vim I have it bound to <leader>f, <leader>b, <leader>t -- on my multiple trips over to Emacs land -- I have tried lots of ways to get the equivalent working and always come up short.
Lusty Explorer may well satisfy your first two requirements. I don't believe it searches tag files at present, but the capability shouldn't be too hard to add; for files and buffers, I've used it for some years, and find it quite nice.
Actually, I think I have used a clone of Lusty on the Vim side and it worked nicely. Getting tags support working would be nice as well -- I really like the global tags option in CtrlP (I got this function name somewhere in an open file, take me there).
Lusty actually originated on the Vim side, and was ported to Emacs by someone who liked the functionality.
Emacs comes stock with good tags support; once you've built a tagfile, M-. on a tag will take you to its definition. (I don't use tags myself, although I really should, so I don't know whether Emacs can automate construction and update of a tagfile, but I strongly suspect it can; check the relevant documentation for details.)
I only discovered ido about two years ago and, man, I can't imagine emacs without it now ... and I've been an emacs user for over 20 years! Only dabbled with helm a bit, there was one helm-enabled package that I really wanted to try.
I tried Evil for about a month, and couldn't stand it. Some parts didn't work the same (ctags word boundaries), and the need to move back and forth between Evil mode and normal emacs mode when using other emacs plugins (it never worked quite right in plugins like magit) negated much of the benefit of having Evil mode in the first place.
I'll probably be sticking with boring old Vim and the command line.
I'm not sure why you need child processes or SSH (I mean you can use vim over SSH). But have you tried syntastic for the syntax checking? And I'm not sure what kind of visual interface you want for git, bit the combination of fugitive and gitgutter (super simple but awesome) works quite well for me.
Emacs isn't really just a text editor though, it's a Lisp environment whose primary use is as a text editor. It's possible to do many other things in it, so much so that it's joked about as being an operating system in its own right.
Emacs is extremely good at text editing, but it's not just a text editor.
When I visit a file in Emacs, indications appear on the screen (in the "mode line") as to which version-control system, if any, the file is under the control of and whether the file contains any non-checked-in changes.
Perhaps grandparent wants something like that in Vim if it does not exist already.
Both Vim and Emacs have a horrible time trying to syntax highlight Perl, but I find Vim's flaws to be more tolerable. Emacs isn't some sort of panacea.
One of the examples I seem to remember was string interpolation of things like:
" @{[ blah() ]} "
I was never an Emacs user, but paired with Emacs users quite often during a 4 year stint at a Perl shop.
In Vim:
my $variable = <<EOF;
STUFF GOES HERE
EOF
Vim highlights everything from "<<EOF" to "EOF" as a string, but technically the string highlighting shouldn't start until the beginning of the next line. In the example above it's not the end of the world, but you can have examples like this:
my $variable = function_call(<<EOF, $blah);
EOF
where ", $blah);" is highlighted as part of the string, when it isn't.
[edit: I tried to replicated this, and I'm not seeing the HEREDOC portion highlighted as a string, but I also notice that Perl 5.20 has removed <<HEREDOC in favour of <<"HEREDOC" or <<'HEREDOC', so maybe that made parsing for syntax-highlighting easier.]
Also in Vim:
"text @{[ callFunction(sub { }) ]} text"
The first '}' encountered terminates the '@{' instead of parsing matching pairs.
I find Emacs's default Perl mode isn't so good. Luckily Emacs also comes bundled with cperl, which works much better in my experience. So much so that I have this in my .emacs:
(defalias 'perl-mode 'cperl-mode) ; perl-mode sucks; use cperl-mode
Whether it's vim or emacs, I've always been amazed how these tools can become an extension of the brain like an instrument whose purpose is to materialize a thought process. Framed that way, the editor wars look like a pianist debating with a violinist of the superiority of their respective instruments to convey human emotion.
Watching a seasoned vim or emacs user create, mold, shape, reformat text like it was a piece of clay in the hands of a potter is truly inspiring.
As for me, my instrument of choice is Sublime Text (which, I guess, downgrades me to the status of a flute player), though I occasionally use vim for Ops stuff. I think there are some mac-centric UX patterns that I have a hard time giving up.
> I think there are some mac-centric UX patterns that I have a hard time giving up.
I can certainly understand that; I'm a relative newcomer to the platform, and while Emacs (of course) continues to behave regarding meta keys in the fashion I've spent a lifetime learning, getting used to Option-arrows for "move to next/previous word", and Command instead of Control for shortcuts, is really bothering me.
(Of course, that's mostly just because forcing the user to cramp her hand up like that, in order to access even the most commonly used keyboard shortcuts, is just a really stupid and un-Apple-like piece of user interaction design, and I've yet to find a good way to fix it.)
If you'd like to properly remap move to next/previous word and other commands in Mac OS X, I'd recommend Karabiner (which was previously called KeyRemap4Macbook).
I use it to map the emacs navigation keys for use across the OS, and find it really improves my experience. If you're interested in that set up, I use the following options, which are all listed under Emacs Mode:
- Control + PNBF to Up/Down/Left/Right
- Control + A/E to Command + Left/Right
- Option + B/F to Option + Left/Right
- Control + D to Forward Delete
Of course, I have caps lock remapped to Control.
There are also Vi remap options in Karabiner, plus tons of other stuff.
Disclaimer: I'm a bit of an emacs lightweight, so it might be that the remapping options aren't as full-featured as what a more advanced user would like.
I use KeyRemap4Macbook for a variety of purposes, mostly related to making a PC-style USB keyboard play nicely with OS X. It doesn't go as far as I'd like, though.
Maybe I'm misunderstanding you, but it sounds like you're using one of the Mac OSX ports of emacs that tries to make emacs behave more like a Mac app. My advice is don't do that. Use emacsformacos.com [1]. It's plain ol' GNU emacs built for the Mac platform. I was so glad to find this and quickly gave up Aquamacs. I want my emacs to behave the same whether I'm on Mac or Linux (or Windows for that matter, but I'm doing less and less on Windows these days).
You've misunderstood me; my Emacs is a custom-built 24.3.1 with the railwaycat patch for OS X, so it behaves exactly as I intend it to. (All of my Emacsen are hand-built; I learned back in my Perl-hacking days not to trust packagers beyond a certain level of complexity, which Emacs vastly exceeds.) The problem isn't Emacs, but rather everything else.
To expand on that point: what I'm complaining about is the fact that OS X, and native apps, use the Command key, which is where Alt would be on a PC keyboard, as the meta key for shortcuts which on a Windows or Linux box are bound to Control. This is a terrible idea from a UX perspective in general, because every common keybinding requires a hand cramp to invoke. From the special perspective of someone who remaps Caps Lock to Control, it's even worse.
I'm probably going to end up remapping Caps Lock to Command instead, and reconfiguring Emacs and iTerm accordingly; it looks like that'll work out to be a pretty complete solution to the problem. (I hadn't previously thought to check whether iTerm supports meta remapping, but it does, so I can have my Command key behave as Control when I use it in terminal applications.)
Another option for "modal" editing in emacs is god-mode(1). It lets you use emacs commands without modifier keys. I have it set to change my mode-line color when it's activated, it's great if you want a little taste of vim but not the problem of trying to shoehorn vim key-bindings into emacs.
I used to use this, but I found that a lot of the convenience of modal editing comes from the ability to compose commands. I took the time to learn Vim keybindings; now I use evil-mode and I like it a lot better than god-mode.
I don't know why, I find this post greatly uninformative. Yes, you can have some kind of Vim mode in Emacs (as you can in Sublime) and yes it takes time to remember key-bindings. If you have years of experience in Vim, why would you expect to get used to Emacs keybindings in a short time?
It's like moving to a foreign country and then continue to buy and to eat only your old local food, and go out and talk to only people from your old home. You will miss so much.
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.
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.
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.)
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)
I still do not undertand the devotion that people have with these text editors. I prefer Vim however I could see myself using it soley or even half the time. I feel like I know the basic commands and it is fast but with the ease of a sublime text or something similar why do people still use these pieces of software so frequently? (Not a rhetorical question)
Because UNIX shell is the most powerful integrated programming environment for development with any language/technology combination. Instead of your typical menu commands (you are lucky if you have 100 or so commands to do very basic and limited things on a selection that you must build with mouse manually) you literally have tens of thousands of extremely sophisticated commands that can easily be chained together to produce amazing things with very little work.
Vim is just part of that tool chain designed to edit text efficiently. Vim is not so much a text editor as it is a language for manipulating text. Vim has dozens of motion commands to move cursor over chars, words, sentences, paragraphs, code blocks, methods, pages, regex etc. So general form of vim commands is nCm i.e. repeat n times command C to the text cursor moves over with motion command m. So for example w is a command that moves to the next word. d is a delete command. So, dw says delete word. 5dw says delete next 5 words. Let's say you are inside if (.) block and you want to change the if condition. ci( says "change inner bracket text" (i.e. everything inside brackets). This deletes everything inside () and puts you to INSERT mode and let's you type new condition.
This makes Vim extremely predictable and discoverable. You learn a new command say gU (turn to upper case) and you immediately know how to turn to upper case entire word because you know how to move by words with w. gUw turn entire word to upper case. gU) turns entire sentence to upper case, etc.
After a while these things just become part of you, and you become really fast at bending text to your will without even thinking. The fact that you can navigate text/code and get to where you want in matter of milliseconds (faster than it takes you to take the hand off the keyboard and reach for the mouse, shake the mouse to find where the cursor is etc) is amazingly liberating of disruptive context switches.
And then if you add shell integration, it means you can apply advanced filters to your text to do pretty much anything. This gets as esoteric as run filter on regex in lines that match another regex, where regex can be any Perl compatible regular expression. But can also be as simple as reformat code, beautify paragraph, insert current date, listing of directory etc. Then you add code completion, file navigation etc and you have something amazing.
Don't aim to learn everything. Learn to be productive and get to the point where you do things you do fast enough. Vim itself has enormous amount of functionality, so it is useful to read vim reference manual. It comes with one and you can get one in PDF as well here:
Also read entire exhaustive help at least once so you get the idea of what is available (it can be done in one weekend, don't try to memorize too much just familiarize yourself with content, then later when you wonder how would you do that in Vim you will remember you read something about that once).
Vim has really great indexed help that you can access directly:
:h
:h index
:h <topic>
and there is also grep for help to search entire help for matches
:helpgrep <search_term>
No matter what you do understand that you will get slower before you get faster. At first expect your productivity to go down seriously, because everything will be strange and new. But persist with it and force yourself to use it. Once you get to the nicer bits you probably will not want to go back. After 6 months of regular use, you will not be able to back, every other editor will feel dumb and will frustrate you to no end (be careful when typing email: ESC key dismisses the compose dialog in a lot of email programs without asking you anything :D).
As for UNIX shell and tools, again get a good BASH tutorial book and learn the basics of interactive shell, learn how to do loops, globs etc. The rest is then all about learning individual tools, not shell itself, which is rather small command interpreter. Look in your /usr/bin and /usr/local/bin for commands and read their man pages. Experiment a lot with them and look at examples of creative use of these.
Back in the early 90s I had a year long course in vi (not Vim) but started using Vim on Amiga 500 days, and after 20 years I still come across new commands and ways to do things. This is the beauty of Vim, you grow with it and it never stops to amaze you. But it is a skill that you keep for a lifetime. It's like learning to touch type, you do it once and you type efficiently for the rest of your life. You may get faster or slower at times in your life but you are always faster than hunt and peckers. Same with Vim, dumb editors come and go, but none ever approach the completeness of Vim.
Craftsmen and tools. It is an age old story, you grow to trust and understand a tool. Programmers and text editors are an extreme example, because programmers often spend 30+ hours a week using a single too, their editor.
Vim and Emacs have survived because they are "fit for a purpose"... they are really good at editing text! Emacs has a niche in expandability. You can always twist Emacs to do your bidding... and it has a culture of tinkers. Vim has much more of a culture of users, people who want to edit text rather that toy with their editor.
These editors have roots in the 70s and are still kicking -- that isn't some random accident, that is because the fundamental act of editing text hasn't change too much.
>Vim has much more of a culture of users, people who want to edit text rather that toy with their editor.
I don’t know about that. I really got into Vim because it’s so customizable. The number of general purpose and very specific plugins is pretty amazing.
And the Vim Awesome site that tracks plugins is pretty damn awesome: http://vimawesome.com
Vim has great plugins -- but expanding it is often best left to experts. I have a pet theory that part of the reason for the high quality of many vim plugins is the horrors of writing them (and of course, tpope). Most Vim users are simple, "off the shelf" users -- they use plugins, but they don't WRITE plugins and they often don't radically change the environment (it still feels like vim, as expected). Vim is a good editor that works great with other tools.
Emacs is more -- of its own things -- lots of people write little bits of elisp to do their bidding, and the "plugins" can completely reshape the editor into an IRC client... a mail client... a media player ... a connection to spotify ... etc. It is a wild crazy world powered by elisp.
People don't use Vim and Emacs for ease of use, they use them for the power and efficiency they eventually provide once you reach a certain level of proficiency.
Rarely do I need a remote editor, where I don't also need a remote shell. So I'm using GNU screen all the time now.
Years ago, I finally made a little time-investment in learning Screen, and it has definitely paid off. I hear that tmux is better, but I don't have any missing requirements from my current setup, so I haven't tried to learn it.
"They also can run in a remote console which for me is reason alone not to use another editor."
As a developer, that makes no sense to me. Do you really need a powerful remote editor? What do you need a remote editor for, other than checking that a config file was set up correctly, or reading a log file?
Working on code that only makes sense against production data... our current "small" dataset is 20TB, our real one is going to land about 150TB. These datasets are a pain to get locally, and a pain to maintain. Way easier to just have an account on an attached box you can use from anywhere.
Another perk of it is using tmux and having a consistent environment you can tap into from work, home, the road, etc.
Why would I want to use any pc in the world? That makes no sense unless your work doesn't involve security of any kind. Besides you can carry your work environment using a virtual machine too.
Perhaps it (any pc in the world) is an exaggeration, but I can use my phone, personal laptop, work desktop, work tablet, personal tablet to connect to my always running tmux session and pick up where I left of.
And a virtual machine seems portable, but I cannot use it on my phone/tablet, and I also cannot use it on most other machines that don't have that virtualization software installed.
When your pager sounds at three in the morning with a problem that needs fixed Right Now, you start to realize what all the benefits of having your complete bag of tools on the server you're working on are. At the very least, you now have an interactive grep/sed/regex tool that you can use to strip out all the irrelevant info from the log file you're poring over. You can now jump between files with ease because of multiple buffers. You have interactive diffing. Your output of logfiles is now color coded. In short, you have all those tools on the box, with it managing all of the context, etc, for you, so you can more easily fix the problem, and get your butt back to bed.
Hm, I work with Embedded systems and each product has a different virtual machine that's hosted somewhere.
I have nothing in my work machine but a linux shell. I just vi everyplace in the world, edit things there and compile there and then scp to the product. My work is 100% remote.
I use vim because it's bindings correspond with my thought process.
My thought is: "Let's change the next 2 words", my fingers type c2w (change word).
The bindings take quite a while to learn, I started using vi mode in komodo edit, but once I realized that bindings like ci" didn't work I switched over to macvim. I haven't used any other editor since then (4 years ago).
The other reason is that I mainly "develop" (hobby) on my vps, having a vim session open in tmux allows me to use nearly any pc in the world and I'm in business to continue where I left off.
I love this explanation of why you like vim, because it's very honest, and one where I can disagree with your preference while having no problem with your argument.
My brain does not work like vim at all. I do not count words. I do not think about whether I want to change, jump or delete. Therefore, I've never been able to use any vi flavor even semi competently: I can technically work in it, and I have read about all the commands, but I am actually slower in Vim than I'd be in windows Notepad, because it's internals do not 'speak' to me at all.
I had a lot more luck with emacs, because I can ignore anything that even considers those low level operations, and just use it's higher level features, like buffers.
Still, I end up doing better in an IDE, because most of my editing is of code, and an IDE understands the code I am writing far better than emacs or vi could.
I regard my primary task as understanding code so I can write as little code as possible. I still write a lot of code, but I expect my editing environment to surface semantic information for me. Otherwise, I do it all myself. Why would I want to do that?
I've used Vim for a few years. I enjoy editing in it for sure. But it does feel like it optimizes the wrong thing. By the time it's time to write code, I'm more invested in the ideas than the mechanical action of implementing them. I also feel like core Vim is very good, but the experience suffers greatly once you enter Weird Plugin Land, where you need to set SpecialOption if using RandomPlugin version 0.88. I get why it happens; it's also a waste of time.
I don't have the patience for that. I dread maintaining my vimconfig for this reason.
Vim is extremely powerful once you master it. It was released in 1991 and is still around. If you go back to Vi it's history goes back to the 70s. It might not matter to you, but as somebody who has written code for more than a decade, I'm glad I don't have to learn a new interface every time the producer of a proprietary editor goes out of business.
Yes, learning the basics is harder than with other editors. Once you master them you have a superior tool you'll be able to use for the rest of your life.
I couldn't imagine using standalone vim as an IDE either... However, if you want the best of both worlds then Visual Studio has a vim emulation plugin (VsVim) and Sublime has vim emulation mode too!
Yep, it is the vim bindings and mode based editing that I love. XVim for Xcode, IdeaVim for Idea, and all those editors with vim modes. I used to hate vim, but once I got used to it, I'm just so much faster.
It depends, but if you do Haskell, with syntastic and ghcmod-vim, you get most of what I care about in an IDE, namely getting warning of errors before trying to run my program.
The Vim plugin for Visual Studio is very good, in my memory. Note that Kate has also a pretty good Vim mode. There is also a decent free Vim plugin for Eclipse [1].
I think mode-based editing will be the answer of almost everyone, plus the imperative that you have to have a shortcut for everything.
That makes vim/emacs not only fast editors in the processing sense, but editors where you can be really fast at what you do. All this comes at a steep learning curve, which is the only downside I can see.
I do wonder what it would be like to use an editor where the main cursor navigation was forward/backward incremental search. One case of this is the Canon CAT[1] word processor, which used "LEAP" keys for cursor movement (and nothing else).
I'm often curious how productive it would be to use while coding.
The EasyMotion plugin for vim has a feature similar to this. When I start searching it matches incrementally, highlighting matches on each screen which I can cycle through with tab. When I see a screen with the match I want, I press enter and then the first 1 or 2 characters of each match are replaced with something like a, b, or ;a. Pressing the appropriate key combination jumps straight to the desired word.
However, if you're just editing text on the same screen you can skip the search. I have it set up so that I press ,w and then every word after my cursor has its first one or two characters replaced. I can jump to any word by pressing those. There's also a hybrid mode where pressing one key and then the first letter of the desired word highlights only those matching words on the entire screen, which I can then jump to.
I'm both a vim and emacs user. I love vim for all the reasons everyone always mentions, but emacs comes out ahead consistently basically because emacs-lisp is so much more usable to me than vimscript. I find it much easier to create or modify plugins in emacs... Don't like the (often overfeatureful) functionality of a plugin? Change it!
The last time I tried Emacs+Evil I found that when pressing Ctrl+[ there was a slight delay when moving back into command mode. I was constantly tripping up when typing furiously.
This alone was enough to move me back to Vim. Everything else about Emacs was awesome. I would love to go back if I could get over this one problem..
> I completely do not understand how anyone can use Emacs’ default keybindings.
I completely do not understand how switching modes is a good idea in an editor. It just doesn't fit in my brain somehow. I start typing and randomly end up pasting and cutting. I want to paste and cut it randomly types my commands in insert mode.
Emacs cords are pretty intuitive to me. I don't know many: just moving, saving, creating 2 windows, search & replace, cutting and pasting. There are hundreds more, but you can get away with a few basic ones.
Save needing to rebind the Ctrl key to CapsLock, emacs key-bindings are optimized to not have to move the hands to the mouse or arrow keys, which I appreciate. Vim's are as well, but again I don't like modes, so there is that.
I can't find it now, but the guy running http://www.viemu.com/blog/ has a good explanation for this problem. Basically, while there are modes, you don't work like that. You are always in command mode, and you slip briefly into e.g. insert mode, before popping back out to the 'default' command mode. This perfectly described how I work in Vim, and when I passed it around my office, several people had 'ahah!' moments. YMMV.
I know both well, and emacs are essential to navigating Mac OSX UI. If someone ever catches you typing in gmail they will ask how you are moving around so fast.
I tried emacs until my pinky hurt so bad I switched to vim.
So when i'm programming I find myself spending far more time thinking about what to type next than actually typing it, seems to me like there isn't much to gain by learning vim/emacs or am I missing something?
People often mistake the succinctness of vim's commands as an attempt to save a few keystrokes typing, but that's only a side benefit.
The vim command structure makes it trivial to define transformations on common blocks of text; words, sentences, paragraphs (lines), blocks of code inside {..}, etc. It makes it easy to repeat those commands, by repeating them a fixed number of times, applying them to every instance in the file, or asking for confirmation around each one.
But, most importantly, it means that we can now extract that little bit of text-transforming functionality into a script we can save and bind to a new command (if it's something particularly reusable). This is really what vim is about to me - providing a language to describe text transformations, in the form of sequences of commands. This means that the way I code every day, conveniently saving me a few seconds like you mentioned above, is the same method I use when writing/editing plugins/macros for the editor to do more complicated tasks, like say consistently formatting every line of a log file that begins with [ERROR] and removing all other lines, so we can process it with some other tool.
Sure, you could write a script in [python/perl/ruby/etcetcetc] to do all that just as well, but the point is that Vim provides a nice little domain specific language right at your fingertips, optimized for working with text at a higher level, capable of handling one-off jobs as easily as big jobs over a whole log file or even as a little command to be reused later.
There's a reason vim & emacs are referred to as great 'editors': their advantages show mostly when editing & refactoring. They don't help you with code that flows from your head to your hands fully-formed much more than any other editor or IDE. Where they do help is in making actions like 'swap this block of code with this one'; 'replace the text inside these brackets with this', 'execute this sequence of actions on everything matching this regex' etc. efficient.
Doesn't that argument work just as well for touch typing? Would you argue that being a touch typist is useless?
Do you ever use keyboard shortcuts... Ctrl-A, Ctrl-F, Ctrl-C, Ctrl-V, Ctrl-Z, Shift-End, etc.? Extrapolate that to everything you might want to do when reading, reviewing, or editing a text file.
You are thinking about "what to type". In an editor with a rich set of text editing commands, what you can type is expanded. So when you are thinking about it, what you can think is expanded.
My main concern with Emacs (at least on Windows) is that it actually crashes every now and then. I haven't dealt with many programs in the past few years that do still that.
I haven't used Emacs on Windows much but from what I remember crashing wasn't my main issue with it: slow I/O access time were the issue. For some reason they were orders of magnitude slower than on linux/osx.
Then, if you worry about fuzzy project finders, better one exists that does not need fuzzy (I ditched all fuzzy finders for it): http://tuhdo.github.io/helm-intro.html
So many Emacs articles the recent days... please tell me: Should I really switch to Emacs as a web developer? Is it really superior to SublimeText and Brackets for a web dev?
It depends on how you plan your future. I've used quite a few text editors over the years (Bluefish, Scite, Homesite, Phase5, Idle, TextMate, Vim, others). I switched to Emacs more than a year ago with one clear goal: Not having to switch anymore. You see, most of the editors above (except vim) used to be good and then were deprecated, sold, stopped, and so on. Which of those has been existing for more than 20 years and is still able to hold up to new editors. Sadly, none (One could argue for TextMate 2, but in between there were many, many years of staleness).
I was fed up with having to switch to a newfangled editor every so many years, having to identify new plugins, having to learn new keybindings. I've used Vim for 7 years (I think) and it came pretty close, but in the end the archaic VimScript language and the lack of async commands was something that was nagging me. I wanted to call an editor home, and hone my skills until I pass away, increasing my arcane knowledge over 10-20 years, learning ever more about the scripting language, commands, and writing more and more specific plugins that help with my tasks.
I still want to be coding in 10 years, but I don't want to switch text editors ever again. Emacs shall be my final editor [1], and that's why I decided to switch. Because I can see Emacs still going strong in another 20 years. I wouldn't want to say that about Sublime, or really any other editor right now.
[1] There's a case to be made that NeoVim is going to be great, and it may well be, but right now I'm really, really, really happy with Emacs + Evil. Nothing is perfect, of course, but the things that bug me are really, really small things that I could probably even fix, if I'd invest enough time; but they don't bug me enough for that.
Maybe I'm a bit dense, but when are asynchronous commands a pain point in an editor? I mean, you can run eg a script that forks into the background, right? I'm not sure I really want to do "r! long-running-thing-that-updates-buffer". I can see me wanting to do "! long-running-compile &" (in the background). And I can do that in vim?
One of the things that has caught me is syntax checking. I use the syntastic plugin, set to check syntax on write, and I apparently save my changes pretty frequently. Some files can take 2-3 seconds to run an external syntax checker, during which time I can't edit the file.
I guess the real problem is me saving too often. Others may be trying to run a long make from vim and wanting to continue editing or looking through files.
No, that sounds like a valid usecase (and/or a horribly slow syntax check -- I'm not familiar with syntactic... does it do some kind of heuristic grammar check?).
I think usually it just runs the compiler in a syntax-check mode. For instance, it runs gcc with -fsyntax-only. I think I have sometimes seen style warnings too, so maybe there is more than that. Maybe I could configure it better to be faster, but for now it doesn't bother me often enough.
Is this for c++? You might benefit from moving to cmake with the ninja backend (ninja being the important part not cmake) -- depending on what kind of projects etc etc.
No. Use what you are comfortable with. There is a cost incurred for changing (time) that may or may not have a sensible return as an editor is a very personal thing to choose.
How else can you get comfortable with something different that is potentially better than what you're currently using?
Learning Emacs or Vim is an investment, one that last your entire life. I will gladly be less productive for a few weeks to gain much more in the long run.
It could be argued that they also cost a lifetime to learn. With normal, full blown editors (eg: editors that require Java) I get a ton of intuitive functionality for free, and I can start using it right away.
I'm using vim. The thing is for text-based editors you need to configure specific workflows for languages other than C. Ruby and Python (probably others) have acceptable workflows (identation, completion, run, snippets, etc.) The workflow can be extremely optimised.
But for CSS/SCSS and JS I find easier to use espresso[1]. That's because it's made for web-dev and I don't need to setup my own workflow. I believe same thing is with Sublime Text. It's better to use for web-dev IMHO compared to VIM/EMACS.
ps. That said, I always believed that the editor is a tool. It's better to learn your current editor's ins and outs than switching back and forth from editor to editor.
I'm a web dev who has switched to Emacs a few years ago. In the first year I went from throwing profanities at it to writing some basic elisp code to refresh the active browser tab after saving the file, before watch tasks for nodejs were even a thing.
I can't say that you should switch, or that it's superior to anything, but I think you could at least give it a try. And by this I mean: use it as your only text editor for as long as you can invest (a week, maybe a month). Start with the built-in tutorial, install: ido, web-mode, js2-mode, maybe add yas-mode. Install a nice color theme. Learn the key bindings in web-mode to efficiently navigate HTML documents. Try to perform some tasks using macros. While editing try to forget you even have a mouse. Discover the little things, like "undo" being able to be narrowed to the selected lines instead of global linear history, or the kill-ring (you can paste form previous "cut" operations, not just the recent one).
There's some un-learning and re-learning of everyday tings like the shortcuts for copy/paste or the concept of selection vs. region, but for me it was a good investment. I can't say it'll be good for you, but I encourage you to try - if you won't switch you'll at least get a better understanding of what you like about your current editors.
I like that he mentioned CtrlP. It's the single plugin that prevents me from switching to Emacs.
There is currently nothing in Emacs (last I played with this was 3 months ago) that is 100% equivalent to CtrlP. There are some close approximations but they're not as good the real deal. I can understand how Emacs guys won't even notice this because they've not worked with something that's better than the best they have, but for Vim guys it sucks.
I used Vim before switching to Emacs, and also used CtrlP. I've also had the pain of not being able to find a good replacement for CtrlP until I discovered Helm and more specific Helm-ls-git https://github.com/emacs-helm/helm-ls-git . Now I have the opposite problem that Vim doesn't have anything as good as the collection of Helm plugins that I use.
Agree. I'm using projectile[1] for now but that somehow messes things up with caching files so that I actually cannot search my project files. I assume that might be a fault on my side though.
Have you tried projectile? From reading the Readme this was exactly what I was looking for as a Ctrl-P replacement.
I use projectile with caching turned off with flx-ido for sorting. I heavily favor (projectile-find-buffer) once I get going since loading the whole tree is pretty slow on a large project. I'm way more happy with this setup than I was with CtrlP.
I've had some weird things happen too when searching for files in a project using projectile, I fix it by triggering a refresh of the cache by prefixing with a C-u the C-c p f command.
(I'm currently toying with the editor able (ql:quickload "able") (able:start), so at this moment, I'm not in a good position to figth at those thumb wars... but, as long time and happy emacs user, I need to tell the world that "little pinky" is alive and tipping, thanks)
You can have it all, emacs, and vi... so, what is the bigg fuss?
Vim's home-row commands are great... Unless you use a non-QWERTY keyboard layout.
A lot of developers forget that there exist other methods of input, and mnemonic-based shortcuts are one of those things that make a lot more sense than attempting to optimise for a tiny reduction in finger-movement (which ought to be the domain of the input-device anyway).
Actually as a dvorak user I find it tolerable. jk are where cv sit and hl is jp, which means going up/down is left hand, left right on the right hand, and the keys are in the correct orientation as well
I use emacs with the 'viper' mode extension, along with a custom keymap that i made that places the keys i use most on and near the home keys: https://github.com/bshanks/viperre
I actually use viperre with a Colemak keyboard map, but there's a QWERTY mode too.
I really wanted to use Org-mode, but my vim muscle memory and lack of knowledge of keybindings to do useful things like copy/paste and move around with more than just arrow keys were preventing me from being productive. Finally got Evil installed and haven't looked back! Evil and Org-mode work great together.
They do work fine together, but unless you remap the Org-mode control key combinations then none of your Org-mode specific stuff will feel very vim-like. I think one good little project would be to remap all the Org functions to vim-like key sequences. The info in this newslist thread is a small start on that: http://thread.gmane.org/gmane.emacs.orgmode/52815
Is anybody besides me still having the problem with Emacs on Mavericks where the OS X distnoted process gradually eats up gigabytes of RAM? It seems to have to do with running multiple instances of Emacs.
Yes. Frustrating bug. I ended up compiling my own, but I think the newer pretests have the fix. If you want to build your own pretest with the "Yamamoto Mitsuharu" version of Emacs (railwaycat), I posted the commands I ran: http://amitp.blogspot.com/2014/04/building-mac-os-x-emacs.ht...
There is a patch that supposedly solves this problem. Homebrew applies this patch to Emacs and after I started using this I did not notice any more problems with distnoted. I am not sure if other Emacs builds also apply this patch.
You can enable the prelude-evil.el module and start out with a nice set of bindings. It would be sweet if there were some more pull requests to make the evil-mode bindings in prelude more closely match vim.
If you need them, you might consider using the Cygwin(64) version of Emacs. The "w-32" version gives best of both worlds, as it does not need an X server. Be sure to start it with a shortcut so it finds $HOME etc.:
I used to this like this but honestly once an editor like vim or emacs becomes second nature, typing and editing and moving text around the screen feels a lot smoother and make programming more enjoyable.
But I still don't think "you might have to use a machine that only has vim installed and not your preferred editor!" is a good reason to spend time mastering how to use it (which is what I often hear). If you prefer emacs or sublime or whatever, use it, and just put up with vim if you're on this hypothetical scenario where they're not available.
It's still too slow for me. I have often several vims open, usually for a short time, and I'm not going to start a daemon in my session to have a decent startup time, that's unreasonable. Also, even setting a theme like solarized dark turned out to be a headache last time I tried. I think I'll wait for neovim.
You mean startup time without using the server and client setup is too slow, right? (That's easily solved by, well, using the server and client setup, of course.)
I find that in actual operation Emacs is faster and that's the reason I switched from Vim to Emacs. Even after using all the tricks in Vim's :help tex-slow, Vim still lagged when I scrolled or even typed into LaTeX files (unless I turned off syntax highlighting), and I'm not such a great typist. Emacs is perfectly snappy.
Ah, I'm not a Latex person. In my experience, vim works fine, even on very large files, unless you combine syntax highlighting with very long lines, in which case you're going to suffer.
But yes, I admit that I find silly that I should need a 'server' for a text editor. Not to mention that I remote into various VMs regularly which would also need to get their own server/client setup if I wanted a homogeneous working environment.
I use emacs in a work environment that is primarily Vim and where we end up logging in to a lot of machines to do development on, and the two things that turn heads in my emacs setups are my fluent and flexible use of multiple windows and frames, and the fact that I'm always using my local emacs and I use Tramp to remote in to the machines, so I don't have to screw around with .vimrc files on half-a-dozen machines. Both are stock emacs.
It sounds like it's only practical when you know you want to edit things in the first place, as opposed to "it doesn't work, let's restart the service in my existing SSH session and have have a look of the log" sysadmin-style-workflow.
I hate to disappoint, but it really works quite well. Not quite perfectly, but quite well (and most of the trouble I encounter comes from my use of ControlMaster on the SSH side). No, you don't any sort of weird heroics to use it.
I only found Vim syntax highlighting annoyingly slow on TeX, LaTeX and Pandoc Markdown (which supports embedded TeX math formulas), so maybe the TeX syntax highlighter is the single source of slowness. (Also, there is a tex-slow section of the Vim manual, but I think there aren't sections like that for other languages...)
But moving to Emacs had many other benefits, so I'm definitely glad I did it. The LaTeX is just what made me look for other editors, being the one thing that really bothered me about Vim.
And about the remote VMs: as user jerf said, you only run one Emacs, on a local machine, and use Tramp [1] to edit remote files as if they were local. It's great!
