That said, I'm a switcher, too. I got fed up with the vaporware situation and moved to vim full-time a few years ago. I couldn't move back now.

But being on Emacs gave me an advantage of persistence. In past I have changed companies, development machines, operating systems and programming languages but never editor. It was always there, available.

``But even if TextMate 2 drops from the sky fully-formed and marveled at by all, Emacs will still be there, waiting. It will be there when the icecaps melt and the cities drown, when humanity destroys itself in fire and zombies, when the roaches finally achieve sentience, take over, and begin using computers themselves - at which point its various Ctrl-Meta key-chords will seem not merely satisfyingly ergonomic for the typical arthropod, but also direct evidence for the universe’s Intelligent Design by some six-legged, multi-jointed God.''

OK, new rule: Nobody makes a poll about text editors anymore.

I imagine changing vi to vim would be a bit like changing Emacs to GNU Emacs.

There's also Steve Youngs' SXEmacs (a XEmacs fork), which is probably the most well-developed of several efforts to extend Emacs to be a window manager.

vim pros: syntax highlighting is often nice (though when I really care about highlighting, I usually use Emacs), vim's :help is very nice, vim is usually installed

nvi pros: the small TCB I prefer when I'm root (`find /usr/share/vim -name \*.vim | wc -l` just gave me 1103 results, including hundreds of scripts that might be run without me explicitly asking for them), no splash screen, avoids the autoindenting that is often irritating, bound to vi on FreeBSD

I can't say nvi vs. vim efficiency has been an issue for me, but it has been for some people ... http://www.galexander.org/vim_sucks.html

Ed anecdote: A friend of mine once wanted to make an inverted version of sed, which takes commands on stdin and applies them to a file named in the arguments. I think he called it fsed. I facepalmed and gave him my copy of The UNIX Programming Environment.

I do have Notepad++ installed, and if I had to say, I probably use Beyond Compare for my meager text editing needs.

If I switch to other software stacks, I'll probably use Sublime (although I'd like to keep on using an IDE).

Edit: I'm not the only one

https://news.ycombinator.com/item?id=5736817

The only time I edit a text file outside my IDE is when I connect directly to a server, and in that case I use vi.

That seems ridiculous to chose Vi as my primary text editor, when 99.9% of my text editing is done in Intellij.

Well I abstained in this case, however where do you draw the limit ? If there was a poll about "What is your primary IDE" would Vim or Emacs not be listed because they are "just text editor" ?

When I said 99.9% of my text editing is done in Intellij. I also meant text editing outside of the project I'm working on: various config files, log file parsing, remote config files, ... Except for some extreme case like very large file, I rarely find the need to switch to another editor those days.

Those days there is a large overlap between text editors and IDE. Both have made huge progress, so that outside java or c#, some text editor are perfectly serviceable IDE and conversely, IDE editor make decent editor.

Use what you feel good and productive. Be happy.

Even the "vi" mode in a lot of distros is vim with a compatibility flag. And people only use it in an unknown system to edit some admin files in a hurry.

Vi in 2013 == Vim.

Try using heirloom vi or Solaris vi sometime. Even nvi adds a lot of convenience.

Odd that TextWrangler is on there but not BBEdit. Maybe could be grouped together like vi/vim.

Notepad replacement: Notepad++

Prolog, Haskell: Sublime Text (thanks to it, I can get rid of emacs completely)

Even when I was full-time in Linux, my go to IDE was KDevelop. And mcedit for simple text editing.

> Visual Studio

(Also don't forget it's coffee time in Europe)

Logically, you'd be right that it wouldn't make much sense. However geographical trends like that do happen. eg SLES tends to have more traction in Europe than in the US (where RHEL is king of the enterprise space). Opera is more widely used in Europe and some eastern blocks than it is in the States. Apple hardware has a lower foothold in Europe than in America. And so on.

Often it's just a case that people will use what they see their peers use rather than what they're told they should use by the internet.

I can't help you there as I wasn't the one that made that comment.

> If you ask me I'd expect SV to have higher vim/emacs penetration since it's been tech central since before the invention of the terminal.

You could make similar arguments against SV: vim was written by a European (Bram Moolenaar) and GNU emacs was widely popularised by a European OS (Linux). Sadly local statistical trends are rarely that simple to explain (and if we're honest, the results of these polls are anything but trustworthy to begin with)

But you're totally derailing my thread as that is the entire point of my comment. The OP presented it like some sort of foregone conclusion that SV would obviously skew to Sublime. Why!? I am not trying to make a claim that A) geographical variances don't exist or B) SV over-represents vim / emacs (that was merely a wild guess, not meant to state a position, just meant to demonstrate that intuitively the OP's argument makes no sense).

I hope that's clear now.

And accusing me of "totally derailing [your] thread" when it's neither your thread and nor am I going off topic, is rather childish. I appreciate you wanted pyre to expand on his comments, but let's not descend into hair-pulling just because someone else happens to side with a comment that you presumably misinterpreted (and I'm making that presumption because you latter agreed with his comment when I reworded it).

For Android I use Eclipse, but hopefully the new editor from Google will be an improvement.

If you've got time and money to spare, and want to improve the editor you produce (not just use) then learn from the $300 SlickEdit editor. It does a lot of things right. And there's a go package for it.

Under Linux, I use Vim, emacs, and Geany, which is a lightweight IDE also based on Scintilla.

Nower days I mostly work in Eclipse inside a Linux VM (convoluted, but I've found Eclipse in OS X to be severely deficient for python - and I can work on files on my host filesystem via a shared folder.)

When I need to edit in Mac OS I use Textmate 2, but I've never actually used any of the magic of Textmate beyond the syntax highlighting (and the latex compile-to-PDF key shortcut.)

At risk of nitpcking, I think the "other CLI" option should have read "other console based" (that is, unless they were expecting people to answer with the likes of sed hehe).

But re:"other cli" I agree: even ed counts as console-based, not CLI (which would be sed, cat, maybe awk and echo... not fun, but of course real programmers use butterflies)

So in one pane on Acme, you can have the following written down:

    ls ~/dev
    uptime

What's more, the File / Save menus are just a text pane that you can edit, delete and add text to. So Acme follows some of the paradigms of working with the command line in terms of the application being controlled by text rather than hotkeys and widgets. But essentially it's still a mouse-driven application.

Also, I up-voted you just for the subtly of the XKCD reference (usually people just drop the URL with much thought of adding their own wit to the conversation). Nicely done :)

In Acme, middle click executes text under the cursor (and middle selection executes selection,) whereas right-click looks for text/opens file depending on what you point it to. You can also add extra arguments to commands (via the 1-2 chord, where you select something with the left button, select something else with the middle button and click the left button afterwards, so you can have ~/dev in your file pane, ls in another pane and execute ls ~/dev in one go without typing anything else.

Now I understand your comment. Just a side remark, ~ usually doesn't work correctly in Plan9 from User Space and you have to input all the path... I'm sure it can be worked around, but I haven't got time to figure it out.

Re: XKCD reference, I just love that comic. I even went as far as using it as the image in the "landing page" (or index, depending on how you think about it) in my personal page at the department I did my PhD... I'm still the only emacs user among ~30 hardcore unix users that have a preference for vi and vim (yes, both, I didn't forget the "m".) I can understand that they like vim (or I could if they knew more vim than they do, but they mostly don't and miss all the cool stuff vim has to offer, which is lots) but I just can't get why they don't even try emacs to see what other intelligent beings see in it. I have done it with vim, acme and I even try to use sam and ed occasionally to get used to different paradigms in editing. Probably I'm just nuts :)

Sorry you're right. I was having a moment of absentmindedness there. The issue is Plan 9 doesn't use tilde as a shortcut for home[1] so I don't think there's anything you can do (short of editing the source code and aliasing it manually)

[1] http://plan9.bell-labs.com/wiki/plan9/unix_to_plan_9_command...

> I'm still the only emacs user among ~30 hardcore unix users that have a preference for vi and vim (yes, both, I didn't forget the "m".) I can understand that they like vim (or I could if they knew more vim than they do, but they mostly don't and miss all the cool stuff vim has to offer, which is lots) but I just can't get why they don't even try emacs to see what other intelligent beings see in it. I have done it with vim, acme and I even try to use sam and ed occasionally to get used to different paradigms in editing. Probably I'm just nuts :)

People are busy and if you're already efficient in one editor then there's often little incentive to try another. I did give Acme a try though - used it pretty heavily for about a week then came to the conclusion that it was getting in the way more than it was speeding things up (eg it's become habit to use middle click to paste text). Plus most of my work is done inside SSH sessions, so I wasn't really making much use of the Acme's innovative features.

It's a bit of a pity because I do like the concept behind Acme and if it was customisable than I could probably tweak it to fit in better with my work flow. Maybe one day I'll give it another try, but for now it was more jarring than performance enhancing :(

I feel your acme-pain. In some sense it is wonderful, but in many others is just a pain. I still use it (just to get the feeling) for occasional small coding and for plain ol' writing: I just added wwb (the writer's workbench, a set of command line tools to analyse text) to my usual tag line and use it to test my writing for the blog and some lengthy emails and the link. It's handy for that (not that I couldn't do it in emacs)

i'm making something like a transition from vim to sublime, so right now i use both equally.

but it seems to me that using vim on the server in a screen or tmux session is the right thing to do ( no need to leave into bash whatsoever ), while it's extremely pleasant to edit source files over sftp.

so i think i'll choose to use this combination ...

[edit]

Also, one thing that shows how Vim is oriented towards opening and closing it all time is that preventing acidental quitting is quite hard to achieve (only with hacks..)

I've rebound the arrow keys to switch and move tabs and buffers.

* up/down: previous/next buffer

* left/right: previous/next tab

* shift left/right: move tab to left or right

    inoremap <Up> <esc>:bprev<cr>
    inoremap <Down> <esc>:bnext<cr>
    inoremap <Left> <esc>:tabprev<cr>
    inoremap <Right> <esc>:tabnext<cr>
    noremap <Up> :bprev<cr>
    noremap <Down> :bnext<cr>
    noremap <Left> :tabprev<cr>
    noremap <Right> :tabnext<cr>
    nnoremap <silent> <S-Left> :execute 'silent! tabmove ' . (tabpagenr()-2)<CR>
    nnoremap <silent> <S-Right> :execute 'silent! tabmove ' . tabpagenr()<CR>

With a few mappings:

    noremap <leader>b :ls<cr>:buffer 
    noremap <C-a> :b#<cr>
    noremap <C-h> :bprev<cr>
    noremap <C-l> :bnext<cr>

:bn is mapped to backslash on my installation.

:b <tab> for a list of all open files where you can pick the one you want to switch to. Mapped to ",." on my machine.

vim might have its problems. But buffer switching isn't one, for me.

Just kidding, I've only used it in dire emergencies too.

When I worked at Google, I did all my coding in a custom version of nano which I'd hacked up to show an 80-column marker.

very lightweight yet super-flexible!

I consider Aquamacs's stated goal to be a worthy goal, but Aquamacs does not actually change Emacs's behavior to be more like an ordinary GUI app in situations I care about.

For example, in Emacs, if you use the pointing device to select an extent of text then hit the right (left) arrow key, the selection is increased in size by one character to the right (left). In contrast, the vast majority of GUI apps on Windows, OS X and Linux inactivate the selection leaving the insertion point at the right (left) edge of where the selection was (and you can get the behavior that Emacs uses by modifying the right-arrow key press with the shift key). Aquamacs chose the Emacs way of behaving here.

In summary, most of the choices Aquamacs made for when to do things the Emacs way and when to do them the standard GUI way differ from the choice I would have made.

P.S. In the situation examined above, the behavior of Acme (tested on plan9port on OS X) also differs from standard GUI behavior, but in a way different from how Emacs differs: Acme inactivates the selection, but then moves the insertion point one character to the right of the right edge of where the insertion point was, which makes some sort of internal logical sense (if the selection is considered to be a sort of insertion point that has temporarily stretched to be n characters wide) but is a poor design decision for Acme users that have to switch back and forth between Acme and other GUI apps.