There might as well be no concept of "words" or "lines" in a seasoned lisp programmer's mind, there's only sexps and forms. And it's so much easier to reason that way, which is not a fault of vi's grammar but arguably a fault of most programming languages' grammars. It's that fabled saying that you should rather have one data structure (sexps) with 100 operations on it than 10 structures (words, lines, bracketed expressions, paras) with 10 operations each. Vi at least makes those operations consistent across structures and thus trivially deducible.
I tend to use vi-bindings in my Emacs coding (Clojure), but I'm more and more relying on Paredit. However I'm immensely happy to have vi commands for editing prose on Emacs, and I don't think there's anything more powerful than vi for that.
Forgive me for plugging my own project, but vim-sexp¹ provides exactly this abstraction as Vim text-objects, which in turn may be composed with _any_ of the operations in Vim.
S-expressions as text-objects is an amazing marriage of ideas. For example, the sexp text object can be used equally as an argument to eval, yank, delete, change, select, move, and every other operator, builtin or user-defined, each optionally accepting a count. After that, the whole operation can be repeated on a new S-expression with a simple tap of the repeat command. Because Lisp forms are so regular, these actions are precise and highly reliable.
The origin of this saying is Epigrams in Programming, by Alan Perlis.
This really can't be overstated.
Even if you don't really use Paredit or any kind of special tool S-expressions lend themselves to easy modification. Since a Lisp program is, by virtue of the structure, organized by default into easily separated components there is no need to think about anything else other than just expressions.
When I write Racket code (in Emacs), I organize and move code in expressions instead, and if I wanted to move a certain expression I would just move to the enclosing paren and hold shift while saying "move to matching paren" and the whole expression will be marked and I can do whatever I want with it.
I used to use vim before and while I did "get it" after a while I switched to Emacs when I started learning Lisp because I figured I could immerse myself in Lisp code with Emacs.
The thing about it is that since I've coded almost exclusively in Lisps since then I haven't really needed what vim does best. At some point a while ago there were a slew of posts about vim and I looked at maybe getting evil-mode for emacs, but I don't know if I see the point when I almost exclusively deal with sexps.
I once crashed a Squeak image by telling it "true := false".
Since then constants became a little more constant.
Language files blank comment code
Lisp 1608 148211 196355 1073066
C 255 52208 62868 246635
Vi took to the unix philosophy: it's all here and can be composed as you need. Even with Vim's extensibility, it hasn't gotten close to Emacs at the functional level of composability.
Sublime, et al, took as Emacs "big idea" the same thing the author did, "you can create commands", but that is too narrow of a view, and that's why those editors haven't displaced Emacs.
On that topic, Emacs is also a multi-mode editor. There is editing mode, which most people are familiar with, and there is programming mode, where one makes the editor more able to handle the problems one is facing. Until one masters programming mode, Emacs will just seem to be the "editor with cumbersome key mappings".
I've used emacs for about a decade, and Vim for about another. I switched to Vim for practical reasons but place both editors at equivalent levels of quality. Both are great. Not perfect, but great. The article is spot on at identifying the core lessons in each.
The funny thing is both vim and Emacs have these weird learning curves: Emacs starts easier (you can actually type something; wtf is a mode?!), then vim becomes easier (modes and command composing over finger gymnastics and pages-long key bindings), then (and this is, of course, my opinion) Emacs with its programmable everything starts to shine. I wonder how much of the editor wars are simply where people are along that continuum.
Lately though, after near a decade of using vim, I've been trying to unlearn vim. Many editors provide easy ways to navigate, search and replace the way you do in vim 80% of the time without all the baggage that modes bring. The baggage that vim creates is muscle memory training to navigate with hjkl which is incompatible with non-vim input boxes. I'm also not a fan of the vim source code or its creator and it may be too late for me to care about neovim.
Another negative aspect of vim is that at least in myself and maybe in others it leads to an unearned increase level of engineering confidence as you master an arguably useless, esoteric skillset that doesn't translate into better understanding of basic computer science topics. Vim does help improve regular expression familiarity, but that may be it.
So for example, Clojure has vim-fireplace for an excellent clojure experience. Same thing with Haskell.
Go to where the users are and your life will be easier.
I don't use Syntastic, but haskellmode-vim and ghcmod-vim integrate nicely with ghci, and neco-ghc gives autocompletion.
I don't use tags files or other project-level stuff, the above is good enough to get started.
Also once you have ghcmod-vim you can map a key to tell you the type of an expression:
au FileType haskell nnoremap <buffer> <F12> :GhcModType<CR>
In emacs i just gave up and tried to learn vanilla emacs even though i am a vim user.
I started out in Emacs, used it and customized it for years. Then I decided to see what I was missing in Vim, so I switched entirely for two years. I became very comfortable with that world.
Then I spent about a year in the strange netherworld of viper-mode and vimacs, switching around more or less at random.
Eventually, I landed back in plain emacs for most things and have been there for the last ten years. I have nothing against vim and still use it from time to time, particularly when I'm working on a remote server. I just realized that for me, emacs was at least as capable on every front and seemed to suit my way of working better.
This proves my point. These features are just the "porcelain" of Emacs.
Russ Cox has a great video tour of Acme's features here: http://www.youtube.com/watch?v=dP1xVpMPn8M
Acme with keybindings for chord actions might be interesting
I am of course so ingrained in the emacs way that I probably will never change editors.
In video editing, Avid Media Composer has an unparalleled function composition feature. All of the UI depends on it - the alt-keys form related commands, every tool has a semantic that you can't escape. In Avid, you can only edit the keybindings for keys with/without shift pressed. No alt-pressed or alt-shift etc. Semantics of all of these come overloaded out of the box.
Final Cut and Premiere are a completely different thing. Infinitely customisable, you can define any key (or cmd-key or cmd-fn-alt-shift-key) to do any thing. What a redundant idea. Tools don't carry any semantics, so if you're trying to, say, trim 10 frames forward, but you're not in trim mode - error beep. In Avid, the idea of modes is so powerful that each function key has maximum functionality outside that mode.
It's a shame how many UI designers get it wrong.
- a way to combine primitives
Combining instructions together (and giving it a name) is just a function. This is nothing extraordinary for us programmers. However exposing that ability to users of a program for extensibility is rarely done, Yet it yields immense power for little complexity from the user comprehension standpoint.
Around the time Windows came out I had a PC and learned how to edit files with it. I learned to select things (character, paragraph, end of line etc) using combinations like shift-arrow, control-shift-arrow, shift-end, and copy-paste with control-c, control-v. It has always seemed intuitive to me and works well.
I believe that the reason that vim and Emacs have different keys and ways of editing which are less intuitive to me is because they were created in an earlier and more primitive era. I believe those interfaces are inferior.
Now, I do use vim on a daily basis because I can use it when I shell into a remote machine and because there is almost always syntax highlighting available for any given language. So it is my everyday editor. When I want to indent, I use visual mode. If I want to copy a few lines sometimes I use visual mode, or I use the mouse and the copy and paste menu options in the terminal right-click menu. Or shift-insert to paste.
If I want to increase the indent, copy, etc. in vim, I can select/mark an area and do like I just explained. If I were in Atom, I would use the nice shift-arrow and control-shift-arrow stuff. I don't feel that it is important to be able to parameterize those operations the way he suggests, because I have adequate and/or nicer less primitive ways of doing it.
Its pretty amazing to me how the same people who can look at a web application and complain about a minor usability issue like not having an autocomplete for a search field can go into their editor from 1976 and think that all of the old fashioned cryptic keyboard interface schemes are the best thing ever.
Anyway, the only reason it can't replace vim, which he didn't mention, is that it doesn't run in the terminal, and sometimes that is more convenient.
That's a bit like a native Esperanto speaker saying "I don't know what's all the fuss about English being a lingua franca, I learned how to say hello and goodbye and I don't feel I can access all that wealth of knowledge people claim is available to them." Obviously they would have said that in Esperanto, but I don't know it.
"Mi ne scias kio estas tuta vanti angla estante pontolingvo, mi lernis kiel diri saluton kaj adiaŭo kaj mi ne sentas mi povas aliri ĉiujn kiuj riĉeco de scio personoj asertas disponeblas al ili."
Esperanto seems roughly as dense as english, maybe slightly less.
Moreover, although I use vi on occasion (because it's ubiquitously installed and readily accessible in a terminal) I don't like it at all. It fails almost totally on the level of discoverability. That is, those wonderfully composable commands are impossible to discover in vi itself. It also fails at the level of giving good feedback about what you're doing right now. Finally, it fails because it's confusing because modal editing is confusing. It makes much more sense to me to use "out of band" input (like meta keys and mouse input) which is psychologically orthogonal to actually entering text. Not to mention the fact that in situations where you want to move and edit a lot, you actually add a LOT of keystrokes.
In any event, arguing about text editors truly is like religious argument: if you enjoy using emacs, vi, or notepad, I'm happy for you! In the end, if it works for you then it's good, and it seems rather counter-productive to try to convince people one way or another.
Things are not inferior or superior, they are only different. If you can open your mind and understand this, then you will realize vi and Emacs for what they are.
I honestly _cannot_ believe people are still writing posts like the OP did. It's getting so old to even talk about it. Yeah yeah, nobody ever said Atom would replace vi or Emacs. They'll live forever...we get it.
I keep hoping a better Vim will come alone. KDE's Kate gets closer as its Vi bindings improve, but it's still a big enough uncanny valley that I can't switch over (and I'm a KDE dev!).
Every GUI text editor requires a combination of a cursor and keystrokes to accomplish things like this, and they probably will for a very long time.
(Remember that the slur against Emacs -- itself once considered by some too heavyweight to compete with vi -- was that it used "eight megs" of memory.)
For the uninitiated: http://www.gnu.org/fun/jokes/ed-msg.html
This page has lots more: http://www.gnu.org/fun/jokes/gnuemacs.acro.exp.html
Having said that I default to 'vi foo.txt' on the command line and feel like vi competency is a core server skill ...
emacs lisp is much nicer to write extensions in than vimscript, though. It's too bad vim didn't copy that part.
And it is mainly due to the ergonomic design. I can absolutely fly through code in vim without so much as a crick of the wrist.
I realize that Emacs and vi are different in many ways. And despite my love for Emacs, it's obviously not everyone's cup of tea. But if the argument here is that vi's keystrokes are such that learning one lets you learn many others, I think that the default keybindings in Emacs actually do a pretty good job on this front, once you get over the (admittedly very high) learning curve.
In vi 'd' is one operation that takes a 'region' (line, word, char,...). Whatever the region, 'd' will always be a single piece of code.
The irony is that lisp being heavily function based, often orients toward composability in code, but that didn't translate into emacs keybindings at the time.
c-w will kill the active region.
10 matches for "^(defun kill-" in buffer: simple.el.gz
3218:(defun kill-new (string &optional replace yank-handler)
3270:(defun kill-append (string before-p &optional yank-handler)
3340:(defun kill-region (beg end &optional yank-handler)
3411:(defun kill-ring-save (beg end)
3605:(defun kill-forward-chars (arg)
3611:(defun kill-backward-chars (arg)
3679:(defun kill-line (&optional arg)
3734:(defun kill-whole-line (&optional arg)
5049:(defun kill-visual-line (&optional arg)
5354:(defun kill-word (arg)
I vastly prefer doing operations over explicit regions, instead of composing editing operations as in vi. Especially since this maps better to other forms of editing.
Also, what do you mean, maps better to other forms of editing?
I think Sublime Text's multiple-cursor editing is nice because I can see where the focus is and get immediate feedback, much better than "replace-all" even if the end result would be the same. Bret Victor style.
So most of the real complexity in the interface is about region-selection, and the operations are actually trivial.
Of course, you need to first select regions (like interesting lines), then select other regions within those, others within those etc. How to chain it all in a natural way?
 - http://www.vim.org/scripts/script.php?script_id=4523
 - http://emacsrocks.com/e13.html
 - https://github.com/magnars/multiple-cursors.el
Sometimes you want feedback without leaving the declarative paradigm.
I want to delete a domain object (in the context of text, most objects are chars, words, sentences, paragraphs). So I tell the system delete ('d'), then what I want to delete, almost declarative (the what).
Emacs requires to explicitely tell him to create two pieces of data (begin and end marks) then ask for deletion (~the how).
Quantitatively it's also heavier, since it's a 2 keystrokes in vi, and 3 in emacs.
Thus the whole select the object, execute sequence is the same:
* emacs keystrokes
* mouse manipulation
* Lisp functions: get the arguments, execute a function
Thus it is a very consistent model.
Maybe I'm more a schemer than a lisper then because even though the function call protocol is eval args, eval body, one of the nicest thing about lisps is higher order functions. Vi feels exactly like this; a move is an abstract operation that can live on its own, or be passed to another abstract operation to be combined.
To the extreme it reminds me of point-free programming where you dont even pass ~toplevel arguments, you just accumulate hof.
That's just unfamiliarity. Spanish initially seemed backwards to me because they say "casa blanca" and not "white house", but you get used to it.
It's an unnecessary explicit operative order. Like saying writing assembly code is just like C backwards, you'll get used to write callee saved arguments on the stack.
I glanced a bit at the actual elisp, it's not trivial dispatch, it's multiline intertwined bits of logic.
And even then, to the user it doesn't matter, the composability is hidden from him, making learning longer and failing to expose a very valuable concept entirely.
Some very interesting software pushed the idea of composability to visual tools even, look at Luxology Modo, where you can merge small widgets/tools into the one you need. Very neat.
The post also fails the mention the concept of region in Emacs: you select a region than perform one (or multiple) commands on it, instead of encoding the region in the command like in vi.
All around, Emacs is harder on the fingers (more keypresses for the same functionality), but that's the price to pay if you don't want a separate edit and command modes; which personally I find very awkward (but perhaps it's a question of habit).
It is a completely different way of working, but when you realise that you spend most of your time coding not writing, you can see that spending a lot of time in normal mode, with your keys now doing useful stuff, can save a lot of keypresses.
Of course, I'm not saying that vi is perfect, and if emacs works for you, then there's really no reason to switch, unless you want to try it out for funs.
I don't buy that. When I'm using an editor writing, moving and reading is totally mixed.
So even if I only have to move x words to the left, delete until the first occurrence of character y, or change the text inside the very next quotation marks (one of my favorite tricks), the 'hassle' of switching between modes is worth the ease of moving around the document. In the few cases where I need to do something even more trivial, I can still navigate the 'regular' way in insert mode.
Furthermore, I find that I generally work better if I don't just rapidly and constantly switch (mental) modes, even for prose. I'm starting to feel my 'instant' connection to the output makes me sloppier and makes it harder for me to reason about what I'm exactly trying to do. So for me it even has a psychological benefit to use an editor that has modes.
For example in emacs you can move around, cut, paste, do minor manipulations like swapping words or case all while holding control down. When you want to enter text you let up.
Now I'm not a vim god, but I've used it enough that I have muscle memory that affects my use at the command line - I'll want to change something in a parenthesis and will type "ci(" (change inside parenthesis), only to find the literal characters appear... :)
Having used emacs and vim for several years, I now am in favour of vim's editing modes. The only thing I don't like about it is the column numbering at the first or last position of the line (a problem you become only aware of when developing plugins though).
I think the best answer is "sorta, but not really."
The biggest reason why is that Emacs commands don't all work on a region by default. Yes, there's C-w to kill-region, but there's still C-k to kill-line and other special-purpose commands out there. In Vim, there aren't four special-purpose delete commands and then a general-purpose one, they all work the same way. This feels like a qualitative difference to me -- both in theory, and in practice.
When I used Emacs for many years, I definitely did use the region commands, but only when the special purpose ones wouldn't work reasonably (like deleting large chunks of code). If I just wanted to delete (for instance) the stuff inside an HTML tag, I wouldn't try to mark off a region and then delete it, I'd just delete by word/character until it was gone. In Vim, I'd "dt>" automatically, because that just makes a lot more sense than repeatedly typing "dw".
And ironically, Emacs has a command (M-z is the mapping for kill-to-character) that would do exactly the same as that Vim command. But in fourteen years of Emacsing, I never even looked for it, because Emacs doesn't steer you that way. Vim makes you always think about what object you're applying your command to, and because you always have to make a choice, you look for good choices; Emacs generally defaults you to one of a few often-decent choices, and you don't get into general-purpose mode unless the built-ins are unworkable.
Would the visual mode selected areas in vim be equivalent to this?
I agree that Vim's style of composed commands is somehow more natural. But Atom's core value is hackability. Atom's vim-mode package performs every operation in the article and countless more, and does it all without any special APIs or permissions. The commands that are not in the editor API, or are but are slightly different from Vim, are written using editor primitives. That hackability is Atom's special sauce, not the set of convenience commands the editor API supports.
Sublime would have been a better "target" for this comparison.
While the vim keybindings and modes in the editor are ok, it really lacks the keyboard-driven window and panel control you have with vim. Basically, the UI still needs to be driven with a mouse, which totally breaks my workflow. As another commenter put it, vim-mode is a bolt-on, rather than an integral part of the editor.
And while vim-mode is impressive, I don't think it's really quite enough, unfortunately. Because the problem is that vim-mode isn't core to Atom's design philosophy, it's a bolt-on that tries to import a different philosophy to Atom. Other extensions (and native commands) don't expect to be in vim-mode and don't natively work in a way that extends vim-mode.
I like the atom effort, and I think it may come a long way. But it also still has a long way to go until it is as mature as emacs.
:%! perltidy # runs whole buffer through perltidy
:123,456! jsontidy # run lines 123..456 through jsontidy
!} htmltidy # htmltidy to end of para
The ! command can also sort just a range of lines (in place, in the file), which can be even more useful. The range can be selected either by start and end line numbers, as in the parent comment's 2nd example, or by start and end marks (set by ma, mc, etc.) or even by a combination of the two, e.g. starting line number, end mark:
Another example - turn a list of constant definitions in your code, into uppercase:
!Gtr [a-z] [A-Z]
And so on ...
, so for the sort example I gave, too, you may not need to shell out to the external sort command. On the other hand, you may want to, since it has more functionality.
Plus, vim doesn't have every filter command that Unix does, so the ! command is still very useful.
(uppercase U in the command, as opposed to the OP's use of guG - lowercase u).
You can modify the default keybindings and even add more emacs compatible keystrokes if you find it helpful and most Cocoa apps will inherit the new keystrokes: http://www.hcs.harvard.edu/~jrus/site/cocoa-text.html
(it's a good article that also has some interesting info on Input Managers and modifying keyboard layouts)
drdrang wrote an article that linked to several other good sources on the subject:
Having really powerful text-editing commands is just fantastic. I don't need an extensible shell that can work as a browser or email client. I need great text editing added to my IDE.
Also, a plug for the fantastic VIM Adventures, which can ease the process of becoming proficient inside vim: http://vim-adventures.com/
On work, we deploy our site to customers on Win Servers. We use Notepad++ on them. It's the shittiest editor, I've ever used.
On my own machine I'm able to use Sublime. From time to time Brackets. We use self-made IDEs for our own stuff. It's pretty awkward.
Ever used SE80 in SAP? That's the pinnacle of crappy editors.
On my after work machine I test Atom at the moment, I quite like it. The git integration is nice.
And I also used vi/emacs, but only briefly. I use a German layout with my keyboard, but everything is designed with the US layout in mind. Therefore, many things don't work, and I wasn't able to learn the US layout yet.
Vi/Emacs not bad, but takes a lot of time to customize and learning all the commands. I'm not even sure if it makes me anymore productive.
But the business programmer world is full of Eclipse and other IDEs. Using an editor like Sublime is madness here.
I don't have any issues with using emacs and a german keyboard (and haven't come across anything that didn't work..)
Emacs uses regions for that. I mark the position, move in any way I want, kill-region c-w.
The article claimed: 'Emacs and Atom don’t have commands for deleting to the end of a file or a paragraph — even when they have commands to move to those places. But in Vim, if you can move to a location, you can delete to that location.'
I delete to the end of the file all the time in GNU Emacs. mark, move, delete. It's just a different model.
> Your argument does not defeat the argument about the lack of proper command-and-movement composition.
It's not a 'lack'. Like an airplane does not lack a proper steering wheel.
> This neither diminishes nor augments the value of your favourite editor, so no need for religiousness here.
GNU Emacs is not my favorite editor.
At the same time I, as a Lisp expert, don't like the technical base of GNU Emacs. Single threaded, poor Lisp dialect, just now support for lexical binding, not object-oriented, ugly UI, complex key bindings, ...
For editing Lisp code I prefer to use the LispWorks editor. It is also an Emacs, but written in Common Lisp and based on the Hemlock Emacs of CMU. But this does not have the capabilities of GNU Emacs outside of Lisp coding.
From a usability and coolness view, Zmacs is still way ahead. But no longer practical - unless one could use it for some extensive Lisp project, which would justify its use.
Thus, I have no overall favorite editor. GNU Emacs is great, but it has too many and very diverse problems. I use it, but not without frustration.
If you consider holding down bucky bit keys to be command-mode, then it's:
C-<spc> M-e C-w
I don't see how this is any different than giving "d" an argument, other than it's three keystrokes instead of two, and the fact that there's a region leaks. (Of course, in vi you still have to enter and leave command-mode, making the total number of keystrokes greater in this particular case.)
All said, I don't get this article.
I still use vi (vim, actually) when I ssh to servers for quick editing local configuration files.
I agree that command composability and . (don't forget the dot command) are great and I sometimes miss them in emacs, especially the dot command which is like automatically defining a macro for the last command and running C-x e with a single keypress. I think this might be the defining tract of vi as much as ESC and command composability.
All considered I still prefer emacs to the vastly improved vim we have nowadays. I just don't want to have to press ESC all the time before moving to another place in the edit buffer. I wonder if somebody could come out with a great idea for merging the two paradigms in some natural way. I'd love to have both emacs and vi in the same editor.
This article is right... vim does take some customization to make optimally (and personally) useful.
to me, the beauty of vim is that I can use it anywhere with minmal set-up or privileges (e.g. root).
 - http://www.emacswiki.org/emacs/Evil
With the latter, it's every bit as composable as vim, as you can use vim keystrokes to edit in Emacs.
Take the "dt>" example from the post you linked to. You can do that directly in Emacs using evil-mode by typing those exact keystrokes. There's absolutely no difference.
If the author wanted a better comparison he would have chosen Sublime Text, Textmate or any other GUI based editor.
There is no other popular editor that goes out of its way to show it's modifiable at every turn. Emacs is really asking for it.
Well I haven't seen atom since I don't have a Mac but I'm prepared to risk the statement!
You could replicate this by starting a selection and manually moving to the end (either by a combination of commands), but it looses its coherency as a single expression to be executed.
In the words of someone smarter than me, you have a conversation with vim - "delete three words", whereas you micromanage another editor - "start selection, move one word, move one word, move one word, delete".
I understand why in some cases the kind of low level power you get with editors like vi and emacs etc is of an advantage, and I use vi regularly myself for basic editing on remote shells, but I am more of a visual person and I much prefer the usability over power approach.
Every movement is composable with every action. There's a lot of movements, and a lot of actions. Delete three lines is the simplest possible command, but it's hardly the only one.
You could just remap jj or jk to ESC.
How can you use regular letters in place of ESC in vim? How would you type "Dijkstra"?
Also see :
See the 'jj' part in the 'Mappings' section.
As a long-time vim user I'm very excited for a new cross-platform text-editor when I need a mode-less editor. I use vim for different purposes.
In some ways, vi could be considered an evolution of TECO (though I've seen no evidence that there was direct influence). They both use the same core syntax of a numeric count followed by a letter command optionally followed by an ESC-terminated argument. For example, «itextESC» is the same operation in both. (That vi calls it entering a mode rather than supplying an argument is, IMO, an impediment to understanding its compositional nature.)
Which editor would you recommend, should I quit Vim and try Emacs, or perhaps another editor?
I have at various different times felt a lot of strain hit some of my fingers, especially the pinkies. My right pinky complained first, and I realized how much it was used for.
I first switched from Dvorak to Programmer Dvorak so that my pinky wouldn't have to do curly braces and square brackets anymore, and so that both those and parens no longer required a shift press (also helping the other pinky), since Programmer Dvorak switches numbers with symbols (the latter of which I use far more as a coder.) I also got used to Ctrl-H instead of Backspace and Ctrl-M instead of Enter, wherever I could. They didn't work in the editor's command mode, so I created mappings so that they would.
The issues went away. More recently, more than a year after that, I started feeling my other pinky, the left one. I severely reduced my Tab usage and began using the Left Alt as a Left Ctrl more, so my pinky shares Ctrl usage (which was already on Caps Lock, but still..) with my thumb. Also worked.
An ergonomic keyboard would also be a fine acquisition. By the way, trouble in the "ulnar nerve which emanates from the neck" leading to "mild muscle wastage" sounds quite sci-fi to me (not disbelieving, just thought it sounded rather exotic.)
"ulnar nerve which emanates from the neck" - I should have said "my left ulnar nerve is pinched or aggravated in the neck", that's more accurate.
I have pondered this before, using speech to text software, the muscles in your face and jaw have relatively good stamina. But it might be a bit of a tongue twister trying to 'speak' C. From my experience most programming languages are like Latin, easier to read than listen to.
He came up with ways to make things more pronounceable.
I use a Kinesis contoured keyboard with ESC on the thumb cluster (where DEL is on the default Kinesis layout).
If you get trouble using a mouse, Emacs/Vi are better than IDEs. If you have general troubles with keyboards, IDEs are better.
Emacs has imho superior functionality. But if your neck gives you problem with the "chording" you use in Emacs (lots of cases with multiple keys pressed down at once), then Vi's modes would be helpful. [Edit: goldfeld's comments re keyboards are spot on. I have some early neck troubles, I might have to go that way too. The doctors tell me it is common in our profession, we sit still too many hours.]
Anyway, Emacs is really optimized for editing, not for learning to edit. I still recommend the trip.
An anecdote about the last paragraph:
I read online that Org Mode was the best thing since sliced bread. So I sat down and spent lots of hours to learn it. Afterwards, I thought -- "wtf did I just do?! I could get > 50% of that functionality from a web/iPad app I would learn in ten minutes?! Was that really worth the time?" Then I realised that I can write/edit Org modes lists almost as good as todo lists on paper; it was so far down in the brain stem it took no attention from what I was writing.
If the goal is to eliminate the need to hold down a key while pressing another key, turning on "sticky keys" would a lot easier than adapting to a different text editor.
"Sticky keys" is available as an option (usually accessed via Settings > Accessibility) in OS X, Gnome 2, the Linux console, Windows and probably other environments (though ISTR some bugginess in how it worked in Windows the one time I test-drove it in Windows).
Source: I have been using sticky keys with Emacs (on OS X, Gnome 2 and the Linux console) for the last 15 years or so.
So maybe I shouldn't be scared of losing all life quality every time I use a knife in the kitchen. :-)
You can add a yank ring to vim.
What? I've never installed half a dozen anything to vim, and some of my machines don't have anything added to them, so I don't know where he's coming from.
Of course, I don't find it to be all that hard to re-create my working environment: simply copying my .vim and .vimrc from one machine to another "just works".
Usually directly after I open the first configuration file on the new box in vim and have a "what the heck??" moment when it doesn't behave as expected.