One with Vim | Hacker News Reader

One with Vim

invisibletheory.com

148 pointsfredoliveira123 comments

I'm aware I may be too pedantic, but it bothers me when people seem to completely conflate vim with vi. For example, -vi- was released in 1976, and vim not until 1991, despite what the article claims. In the meantime, I'll keep happily using nvi, and keeping the kids off my lawn.

edit: links...

http://en.wikipedia.org/wiki/Nvi

http://en.wikipedia.org/wiki/Vi

http://en.wikipedia.org/wiki/Vim_%28text_editor%29

I think you're going to have to lot further than that to be too pedantic for a discussion of programming editors.

As a relative latecomer to vim, I think your distinction is worthy remembering. If you didn't start with vi, it's easy to assume that all the power and cool stuff is the result of improvements and not realize how much just plain old vi could/can do.

About being pedantic, "going a lot further" -- being a pedant is all a cultural construct, though, isn't it? We're in a time where the lack of distinction between vim/vi is displayed so often that it's not hard to imagine a group of people looking at my original comment and saying "to hell with you, you -are- pedantic, old-school, and vim -is- vi. But better."

I'm really happy there are enough people who apparently appreciate (if not fully agree with) my comment to upvote it, though. I don't care about the karma, but happy to see signs of kindred spirits :)

And I thought I was the only person left who still uses nvi...

NetBSD ships w/ nvi in-base. I don't have any other *BSD systems available at the moment, but according to http://en.wikipedia.org/wiki/Nvi#Credits_and_distribution it's the default in at least the "big 3" BSD distros (Net, Free, and Open; I don't know about DragonFly).

There are more than just two of us nvi users, and we're in good company :)

edit: This suggests DragonFlyBSD is nvi too, which isn't really surprising: http://leaf.dragonflybsd.org/cgi/web-man?command=vi

The Command-T plugin [1] was a big help in switching from TextMate to vim. I have no idea how anyone can be productive in vim without it (assuming you're working on a multi-file project).

1. https://wincent.com/products/command-t

:e .

:NERDTree

Fuzzy Finder is also very useful http://www.vim.org/scripts/script.php?script_id=1984

not nearly as much as command-t as it will only look for files in the current folder instead of going recursively down all folders

Not true. FuzzyFinder does search recursively.

It can, in fact, search pretty much anywhere in vim (from the docs):

        - buffers 
        - files 
        - directories 
        - most recently used files 
        - files around most recently used files 
        - most recently used command-lines 
        - bookmarked files 
        - bookmarked directories 
        - tags 
        - files which are included in current tagfiles 
        - jump list 
        - change list 
        - buffer lines 
        - quickfix 
        - help

:FufCoverageFile is what you're looking for.

I use NERDTree and it's not even remotely close to Command-T (or PeepOpen, which is pretty much the same thing).

NERDTree is great for browsing your project and managing your files, but for opening files (when you know their names) you really can't beat the speed of Command-T/PeepOpen. They're in another league.

I don't know how people work without it.

I use vim project. I load all my files in the side pane, and I search with / the file I want to open.

http://www.vim.org/scripts/script.php?script_id=69

I've been using FuzzyFileFinderTextmate for a long time. I'm not sure it's still in active development, but it's worked just fine for me; is there a reason for me to switch to Command-T?

I also stick to buffers rather than tabs (for terminal/gui consistency) and use buftabs, which I quite like.

You should instead consider switching to the mainline FuzzyFinder instead of the FFTextmate fork. FuzzyFinder is undergoing lots of activity.

You can also try using tabs to represent views of several buffers at once -- for example, I use one tab per app when working on Django code. I have the views, models, templates etc. in split buffers inside one tab.

he's better off switching to command-t, FuzzyFinder is pretty limited in comparison

Care to elaborate?

I just glanced over the Command-T docs and it seems to be a one-trick-pony ("search in path") whereas FuzzyFinder supports a wide range of scopes (path, buffers, tags, etc.).

I use "ectags --file-tags ..." and the ordinary tag mechanism in vim (:ts filename.c).

Vim is my primary editor but I think the only really good part of vim is the keyboard navigation. The rest could be much better.

For example, to this day I haven't figured out an easy, built-in way to copy from one vim window to another. I'd love to have some features of other editors have but the key bindings always hold me back.

Have you tried using :split and :vsplit instead of opening new windows?

yes but it doesn't do much for having two monitors

Ah ok. IIRC, gvim has key binds for copying from window to window.

You're not really supposed to run vim in multiple windows. Use your system pasteboard if you need to copy between them. There's probably some plugin that would make it work with yank registers though.

> You're not really supposed to run vim in multiple windows

huh? I run in 3+ windows (terminal shells) all the time and have done so for 5+ years. To cut and paste between windows I use filesystems copy and paste (select and middle click in X)

Vim is flexible and you are suppose to run it however works for you.

Sure, you can -- my only point was that, as far as I know, vim doesn't really provide any help for working across multiple instances of itself.

Simply untrue, the number of upvotes to this saddens me. The * register exists explicitly in the default implementation for the purpose of yanking text into the system clipboard. Open your nearest vim and do :he gui-selection or :he quotestar

Also, the + register has similar intended uses.

With macvim I sometimes end up using cmd-c on a visually selected area, the cmd-v in the other window. It works, even if it isn't built-in. I also avoid having multiple windows open as much as possible (tabs and splits ftw) but when it does happen, I'm very grateful the standard copy/paste commands still work.

I use a simple hack in my .vimrc

  com -range YY :<line1>,<line2>w! ~/tmp/cnp.txt
  com PP :r ~/tmp/cnp.txt

Then :YY, :PP as appropriate

Oh, and this: http://vim.wikia.com/wiki/Copy_and_paste_between_Vim_instanc... has various other solutions. Including something I did not know about: You can save and load vim's state in .viminfo, so conceivably, you could yank what you want to yank, :wv in that vim, then :rv! in the other vim and paste from the exact same register or registers. Cute.. and useful for syncing up two vim windows in general.

I agree with the general point. For your example: on windows I use "yy and "p. You can set "* as default in vimrc and just use yy and p though (don't remember it off the top of my head, I can check it if you want, I use windows though)

you can copy and paste from the system clipboard as the + register - use "+y to yank to the system clipboard and "+p to paste from it (depending on OS, you may need to use * instead of +). This allows cutting and pasting between vim and other applications (including other instances of vim).

For editing multiple docs with vim, I find it's easier to use multiple buffers in the same window. Use :b <start of file name> to jump back and forth.

I never really liked using :b ... for quickly switching back and forth between files, so I bound ^hjkl to move among buffers. Perhaps the best part of my vim experience.

    " Use ctrl + movement keys to move around windows
    map <C-H> <C-W>h<C-W>_
    map <C-J> <C-W>j<C-W>_
    map <C-K> <C-W>k<C-W>_
    map <C-L> <C-W>l<C-W>_

1 ctrl-^ go to buffer 1

2 ctrl-^ go to buffer 2

3 ctrl-^ go to buffer 3

ctrl-^ toggle this buffer with the last one, quickly switching back and forth.

[Of course, ctrl-^ is actually just ctrl-6, you don't need to use the shift key.]

If you have used a tiling window manager before, this is very natural.

But your vim has to be compiled with clipboard support. I use gvim for just this reason for all but basic editing (for which I just fire up vim).

Generally, gvim and vim are the same binary.

Thanks, works great. When memorize the keystrokes I hope it will be as fast as regular yanking.

I actually use tabs for multiple files and these keybindings for navigation:

nmap T :tabedit nmap H :tabprevious<CR> nmap L :tabnext<CR>

So I can go into a project dir and do vim -p .c* which opens the file in tabs and just navigate with Shift-H and Shift-L

proper formatting:

   nmap T :tabedit 
   nmap H :tabprevious<CR> 
   nmap L :tabnext<CR>

You need to learn about registers. You can copy between windows and even use your OS's clipboard via Vim.

Normally y is used to yank. However, you can prefix it with "x to yank in to register x. Then you can "xp to paste from register x. You have registers 0-9 and a-z for regular use. They work within a single window.

If you use register *, the register corresponds to your OS clipboard.

Read :help registers to learn more.

There is a lot of dogma surrounding doing things the "easy way" is Vim. Cut through that and your life will be much easier. For example, I type on Dvorak and "<ESC>:w<ENTER>" is uncomfortable and arduous when all I wish to do is save a file, which I do often. Then one day I woke up and realized Apple-S works perfectly well MacVim and is many times more efficient.

Getting to the point, it is easy to copy and paste between windows using the system buffer. Just map copy and paste to something easy and familiar, say Ctrl-C/V/X, and go on with your life. I'm sure there is a "correct" way to accomplish what you are asking using registers, but quite frankly I don't know it and have never felt the need to learn.

(I know this assumes you are using a graphical Vim.)

One of the features that really got me into Vim was the macros feature. I actually ran into in accidentally several times when I was first learning the basics (and couldn't get out of recording mode). But macros, and especially the temporary nature of macros, have saved me (collectively) many hours:

q <macrokey> <do some stuff>; then q to stop recording. Then @<macrokey> to kick off the macro. Splendid.

As a new vim user, I'm still trying to figure out what to do with them.

What do you find yourself macroing, generally?

For me the most important thing was learning to add a 'j' at the end of each macro and running it multiple times. So lets say you want to crack open an array that looks like this:

    $address = array(
     'name'  => '',
     'line1' => '',
     'line2' => '',
     'state' => '',
     'country' => '',
     'postcode' => '',
    );

That's a lot of commas and quotes etc. Nowadays I usually punch this into vim:

    name
    line1
    line2
    state
    country
    postcode

Then I start on the first line and record a macro that wraps that word in quotes, then appends hashrocket, quotes, comma, and then moves to the next line. Run the macro 5 times with 5@<register> and the you get your array.

If you're a heavy macro user, you might find `:noremap <Space> @q` to be handy. Just stick your temporary macro in q (the easiest one to stick it in :), then press the spacebar to run it whenever you want.

I don't meet many other vim users who like macros but recently I've had call to use them daily. They completely remove any repetitive text editing actions, even relatively complex ones like "take these words, each on a new line and make them keys to an array, with the values initialized to ''"

The only problem is that they take a lot of practice before you get them right first time. After a while though, you learn to record them fairly quickly and they streamline your workflow. They also melt the faces of anyone pairing with you.

The best part is they get better with age. The more vim commands you know, the more opportunities you find for using them.

"been around since 1991"?! while that's probably correct for vim proper, that ignores the much longer history of vi...

you are absolutely right - fixing this now. Vi has been around since the 70s, but I used the date for vim on the post - which was dumb of me.

Please consider bch's comment [1]. Unless you want to write quite a bit more, I believe you should actually go back to '1991' in your text. While most think that vim is indeed 'vi improved', there is a fair consensus that vim is not vi.

[1] http://news.ycombinator.com/item?id=2149367

I've tried to use vim for a while but I've given up pretty quickly. Yes I'm aware that the learning curve for any new editor is steep but that's not why I've given up on vim. I do all my source code editing in a Windows environment and my choice of editor is Source Insight[1]. I haven't found any editor that allows me to navigate the source three so elegant and fast. I only do embedded development so I can't speak for it's abilities outside C.

[1] http://www.sourceinsight.com

Vim is easier on the hands, but Emacs (with ido-mode) still feels better for working with multiple files:

  (length (remove-if (lambda (b) (not (buffer-file-name b))) (buffer-list)))
  42

There are multiple similar plugins for vim.

FuzzyFinder is great. It's no ido-mode though

There are multiple vim emulation packages for Emacs too, it just ain't the real thing.

After I swiched to vi, I stopped feeling the need to work with multiple files; Just pop in and out of the shell.

I've used Vim successfully on Windows/Mac/Linux and you can customized it as you wish.

Interesting post so 1+.

As a side note the font used for the article does not render well on my Chrome browser. What are you using ? :)

really? Damn, it should. It's Meta Pro served by Typekit. Are you on a Mac?

I've read your post on Windows, on Mac it looks OK.

Why does every article about Vim just recently seem to promote it on the Mac to be used via MacVim? Vim does work in the terminal, and apart from tabs I can't see what MacVim is bringing to the party?

Native integration, mostly. I.e. clipboard stuff and a shiny interface. Also, colors.

Me, I compiled vim over ports and use it via rxvt-unicode or as gvim in an XQuartz session. That, and I run XMonad in that same session.

This way, my iMac at work almost feels like a Linux machine, and I can at least get work done here (if I'm not browsing HN.)

Let me share what I stumbled upon yesterday: https://github.com/carlhuda/janus

What is the closest you can get to emacs ido mode in vim?

selfish question here: Does anybody know how to setup vim so that :! recognises aliases?

something like...

  set shellcmdflag=-O\ expand_aliases\ -c

Your aliases are generally sourced from your shell rc file (ie ~/.bashrc). Not sure how vim launches the shell to run ex shell commands but in the interest of portability it's probably just sh with no rc files loaded. This is probably configurable. Try :help shell or :help :! (I'm not at a terminal so not sure what you'll find)

I believe that vim sources env files rather than rc. For example, any aliases placed in my zshenv are available in vim but those in zshrc are not. I would imagine that applies to other shells as well.

Zsh always source zshenv, regardless of login/interactive options. AFAIK, Bash has no equivalent.

By default, Bash, Zsh, and other shells don't source the shell config when started with -c (because it's considered a non-interactive session). For Bash & Zsh, you can force .bashrc/.zshrc to load by adding -i to 'shellcmdflag'.

I always start vim from within xterm (bashrc has already run and aliases are already set up). It just works. I can use :!ll (or ctrl-z and 'll' in the sub-shell) and it just works.

Not sure why it wouldn't for you.

ctrl-z doesn't start a sub-shell, it backgrouns vim and returns you to the parent shell.

And maybe he's running gvim or from a login shell that hasn't sourced his bashrc.

I am waiting for the retro-fashion to go back to ed (http://www.gnu.org/fun/jokes/ed.msg.html).

Am I foolish for not believing the vi/vim hype? I understand that it's been around for as long as rocks, and that it's quite handy since it's available everywhere. I use it daily, in fact, but rarely for more than basic editing.

I'll just come out and say it: my favorite editor is Visual Studio. Sure, it's slow to load and rather fat now, but I'm talking solely about the editing functionality.

With vim, I have to climb an amazing learning curve, regularly practicing all sorts of commands to achieve basic productivity. With VS, any command I don't recall is readily available through the menus. As I access it in the menus, I'm reminded of the keyboard shortcut, so it seems like a much more natural leaning experience to me.

I think so long as you're satisfied with your tool, you should just keep using it. If you "don't believe the hype", then doesn't just that mean that the benefits that people describe from their experience with vim/emacs/whatever aren't that important to you? If when people describe how they like being able to delete 10 lines with 10dd, or use '.' to repeat the last thing they did, and that doesn't sound interesting to you, then don't worry about it.

Personally, I love vim, and have been using it for years and years, and feel hobbled without it, but if you're satisfied with your tool, and don't long for something better, stick with it.

For me, vi/m is like kale -- I know it's very healthy, and I've tried it several times, but it'll be a cold day in hell before I ever eat the damn thing again.

Well, you better eat some kale then. It's just barely above freezing in Hell right now, actually. Might drop below 0 sometime over the weekend I think.

http://www.yr.no/place/Norway/Nord-Tr%C3%B8ndelag/Stj%C3%B8r...

Your comments about Vim's learning curve are spot on, and I don't think any vimmer will disagree with you, but the argument they make (which I agree with) is that the cost/benefit ratio is worth it.

If you only code every now and then, so you've got a lot of time between sessions to forget things, and not a whole lot of time in total, then something like Visual Studio which has good 'discoverability' is going to be better for you - as you say, if you get lost just go to the menu and it does a pretty good job of showing you around.

If, however, you are coding full time for a living, spending at least 8 hours a day 5 days a week coding (and let's face it, for most people on HN it's probably more like 12 hours a day 6 days a week), then spending even 2 whole weeks getting to grips with an esoteric but POWERFUL editor like Vim will very quickly pay off in terms of time saved and productivity gained.

Is there anyone out there that has given eclipse/intellij idea a fair chance and decided Vim was better for coding java? It's difficult for me to imagine coding without the built in refactorings it provides and shortcuts like ctrl+n and ctrl+alt+h.

I've heard from lots of vim people that do actually use Eclipse to make up for Java's inadequacies, yes.

There are Vim emulation plugins for Eclipse, if you want the best of both worlds.

And don't forget eclim, a Vim front-end for Eclipse (or an Eclipse back-end for Vim):

http://eclim.org/

Sounds exciting but a little scary. Have you used it?

I have used it in order to develop an eclipse plugin for vim. It took some time to set up, but then it worked as advertised. I could use vim inside eclipse. It exposes all the mistake detection and completion stuff of the regular Eclipse editor, but triggered by keybindings instead of automatically.

Not exactly. I tried setting up a really complicated system with Eclipse running as a server in a VM and my local Vim serving as the head to it, but haven't gotten that working yet.

I prefer Vim as the frontend, but was hoping to add Eclipse's code correction and refactoring to it. But that's also the most complicated of the three options, and least well supported right now.

Assuming that that java bash was in context, I have to say that the IDE features I mentioned would be useful for almost any language:

Refactorings: I can rename a method in one location and it will change all the calling code. This would be dangerous to do by hand: Best case scenario, there would be a compiler error for all the broken code. Worst case, that method name was already overloaded and you just introduced a bug.

ctrl+n: Open any file that's in your project. It can find the file by camel case or pattern matching and it only includes files in your project.

ctrl+alt+h: See a tree of all the callers of a method. Extremely useful when you're considering a refactoring. You can instantly answer the questions, "Is anyone calling this method?", "Is anyone calling the methods that are calling this method?...", "What will be affected by this change?", and so on.

Although not as comprehensive as the eclipse refactorings, ctags go some way towards giving you similar functionality in vim.

I'm learning Vim because of my three years using Eclipse. Built in refactoring is pretty awesome and the Eclipse debugger is the best debugger there is.

However, over and over, on each of my projects that used Eclipse, inevitably multiple team members would have Eclipse crash and throw their entire workspace into disarray. Sure Eclipse might give you a 20% boost of productivity day to day, but that once every six months catastrophic disaster it would cause negated a lot of it.

Sometimes Eclipse would have trouble talking to the database, sometimes it would screw up its project file, other times it would outright corrupt files, cache things wrong, etc. This wasn't just for me, it was the experience many of our programmers had at various companies.

Now I'm working on my own project, and it's not near as large so I haven't felt the pain of not having magic-refactor. I've been forced to hack on a script to provide step-through debugging capability, and probably once a day I'll google to find the right keystrokes to do something, but I feel in the end, the effort is more than worth it.

Visual Studio which has good 'discoverability'.

Not my experience at all. It's a sea of confusion and pain.

What about the VS editor do you find confusion and painful? Not counting project-related issues (e.g. knowing what project settings to twiddle and how to do so can be difficult to figure out).

.NET

Personally, the god-awful slow file switching, frequently-incorrect highlighting, almost totally worthless JavaScript, ASP, and ASP server-side code support, XML comments with no built-in documentation builder nor viewer, text-column editing that's a total joke, and the always-helpful "too many warnings" error are my most recent peeves.

I hate VS. With a passion. I cannot believe that such a painful-to-use program is held up as the pinnacle of programming experiences.

So why do I use it? Because .NET defies logic; framework-wide intellisense is the only way to do anything in it. Give me almost any other language/framework and in a few days I can get by almost entirely with a programming text editor and occasional official-documentation browsing. Several months into .NET code, I still Google more than I MSDN, StackOverflow more than .NET-developer-blog, and the massive style inconsistencies between different sections of the library mean I cannot go into any new area without Visual Studio to hold my hand and kick me in the nuts.

It sounds like your most of your complaints are with the .Net platform, library layout, and the compiler.

For what it's worth, I've always found Microsoft APIs to vary profoundly in terms of usability and (especially) documentation. And MSDN hasn't been directly useful to me since the VS 6.0 days.

Can you give me an example of an editor with better text column editing? I'm not entirely sure what you mean.

>It sounds like your most of your complaints are with the .Net platform, library layout, and the compiler.

Only about half-so. The first paragraph was all about VS exclusively, minus "too many warnings". But due to the issues in .NET, you essentially must use Visual Studio, which makes it at least bearable due to intellisense. But I crash VS fairly often, it eats up a half-gig or more of memory fairly often, it thrashes my hard drive to bits all the time so everything else crawls, and at one job the visual designer started executing code. Those database-filled combo boxes started querying the database right in the designer. This happened 3 or 4 times over a couple months, and could have been catastrophic if any of the times it happened occurred on deleting fields. I will never hook a database directly up to VS, I'll guarantee you that; this was executing our bound events. Imagine if we actually had direct connections to the DB.

So, one that's more specific to VS: the idiotic Web Site "projects" that have zero capabilities, and not even before / after build events to hot-wire your own in. And I dare you to try compiling documentation on a Web Site project. People have been asking for it and attempting to hot-wire their own for years, and they use gigabytes of memory to parse small projects and choke after an hour and give up without anything more helpful than "MSBuild.exe encountered an unexpected error". I suspect very much that the slowness of the only decent help builders is due to the horrendous reflection side of .NET, but that's not VS's fault. Except that VS wants VS-style documentation and won't accept anything else, but nobody can use it.

And, because it's particularly bad, I'll point to the JavaScript support again (2008. I hear 2010 is a bit better). It throws fits and doesn't always even index global functions you just declared (it's entirely broken on the site I'm working on, it simply refuses to parse anything not in assemblies), Intellisense tries to change "$()" to "$addEventHandler()" as you type, and it has the absolute worst indentation of any code editor in existence. None would be better, but it occasionally decides you're not neat enough and imposes "order" on your nicely readable function.

edit: Ooh! Another one! It's such fun to use VS in a multiple-monitor setup. Either you use the annoying "Multiple Document" layout (inner-windows that waste tons of space and fall behind things when the docked windows change), or you use tabs and can't spread to a second screen effectively. Or you launch two versions, and have them throw fits when you build in one, and the other sees things changing. And there is no higher joy than editing web.config while two instances of the same project are running, and watching the Visual Studio hit the fan.

--- </rant> I feel better. Thanks :)

Nearly any other programming editor, really. Notepad++ is a good example though, and doesn't require install, so I'd suggest experimenting with that.

In VS: hold alt and select a box of text. Note that you can't select less than a single space wide. You can copy, paste, and delete it. Now try hitting space, or typing something: the whole set is erased, and you start entering text at the top-left corner of what you had selected.

In nearly any other editor: hold alt and select a box. Note that you can select a column "0" wide. Copy, paste, and delete work as expected. But start typing; the vast majority I've used will fill the entire column as you type with what you're typing. Backspace removes line by line after the initial replacement. You edit the column, and everything you do is duplicated to the other lines you had the selection in.

It'd be especially useful for .NET as damn near every useful method returns void: want to populate a list with a few items? Select a few columns, type "list.Add(" and you're most of the way there. Plenty of times the refactoring tools (as good as they are in non-VB languages) don't work if you're not changing everything, and having a column editor would make things a lot faster. Besides, they have half a solution working; why did they stop at the nearly-useless step?

Another handy thing many programming text editors will do, but VS does not: soft-tabs go away with a back-space to the next tab-stop (if you start at one). In VS: keep hitting until you reach what might be another tab stop, there are no indicators for such things. Happy counting!

FWIW I'm the author of the Zeus programmer's editor and it can import VS solutions files and once imported you can build and compile all from inside the editor.

Zeus also does a limited amount of intellisensing, but naturally the intellisensing is nowhere near good as that found in VS. But the code navigation is not too back.

Zeus also has full MSDN integration and it can actually do context sensitive queries of the MSDN much faster than VS:

http://www.zeusedit.com/zforum/viewtopic.php?t=2833

So if you are prepared to forgo a bit on intellisensing, it is in fact possible to develop outside of the VS IDE at least some of the time.

I'll be happy to give it a shot. I'm using a Web Site + solution for my current job though, know if it handles that? They're a bit weird. I'll certainly give it a try for more "normal" .NET coding, there's a lot of utility code to be written :)

> I'm using a Web Site + solution for my current job though, know if it handles that?

To be honest I'm not really sure. The big test would be to see if Zeus manages to import the solution file (i.e. from the Workpsace, Import menu).

This import has only been tested for 2005, 2008 and 2010 C# and C++ projects.

If it doesn't feel free to send me a bug report.

> I'll certainly give it a try for more "normal" .NET coding, there's a lot of utility code to be written :)

These are the three 'one off' steps needed to get the Visual Studio compiler to run inside Zeus

http://www.zeusedit.com/zforum/viewtopic.php?t=2707

Tried it a little bit, and I'll experiment more as I get time. Importing the solution which contained the web site only loaded the other "actual" project in the solution, unfortunately. I can poke at it a bit more and see if I can get more into it.

One of the first things I noticed: apparently a couple of your regexes are off in C#, for VS2008 at least. Typed interfaces come up as "T" instead of the interface, and it would be immensely more useful to have the class browser have information about the parameters of functions. I've got a ton of overloads, and they're note even in any useful order, as far as I can tell.

> Importing the solution which contained the web site only loaded the other "actual" project in the solution, unfortunately.

That is what I had feared. It looks like Zeus will need to be tweaked to understand this type of solution file.

> I can poke at it a bit more and see if I can get more into it.

One thing you could try is opening an explorer window and then just drag and drop one of your source code folders onto the Zeus workspace panel.

Zeus will parse the structure of the folder that was dropped and add all files that if finds to the project/workspace.

> One of the first things I noticed: apparently a couple of your regexes are off in C#, for VS2008 at least.

The use of a regexp to identify functions is a Zeus feature that dates back to one of the very early versions and is no longer the primary method of identifying functions.

What should have happened is for Zeus to create a tags database for all the files in the project/workspace and it then uses that tags information to display the function list.

But in this case since the solution was not imported correctly, the workspace is empty of files. As such Zeus reverted back to the older regep approach to identify the functions.

And as you suggest, the regexp that it used is almost certain to be out of date since, it was probably written even before the time of C#.

> it would be immensely more useful to have the class browser have information about the parameters of functions.

Adding the current file (or all the project files) to the workspace should result in a lot more information being seen in the class browser.

The class browser shows the contents of the tags database and if it is not full then it means the tagger is not understanding the code, but for C# that should not be the case.

That's all very interesting. I'm primarily a desktop C++ developer, so I don't run into the headaches of things like VS's database connectivity.

I recommend giving 2010 a go. If I recall correctly, 2010 was the version where they drastically reworked Intellisense. In previous versions, even my moderately-sized projects would break Intellisense upon reaching x lines of code. I don't think the multi-monitor support is any better, though. You can drag documents to their own window on any screen, but I can't seem to group them into sets of tabs.

I'd like to give 2010 a try, and I may at some point here, but everyone else is in 2008 and I'm not sure it'll translate entirely (code has to compile everywhere, and saying ASP is a second-class citizen is insulting to second-class citizens everywhere. I have zero faith it'll work the same way in both versions). I have heard a lot is better in 2010, but in general it's still a Microsoft product; huge, inconsistent, and so tightly bound into everything that they have no proper competition.

Oddly, Intellisense is generally keeping up with me, despite the site being at least a few hundred thousand lines of code (light on the abstraction, though, so it's mostly flat .NET code. Probably not too taxing on intellisense). There are times I just break out Notepad++ and finish up stuff VS was breaking, but it generally catches up any time I build the relevant projects.

And I should be clearer, because it's so weird: the designer-view was actually instantiating the entire window control, as it's init contained the database connecting code, and firing events on the combo box controls that queried the database. At no point was the database actually connected to VS, which you can do; and I'll never even consider trying it, after seeing that happen.

If the intellisense is the complaint, nothing beats the Visual Assist plugin. VS10's intellisense is better than what it used to be but still nowhere near VA.

Also, VS10's WPF-based UI is a nightmare, but that's another discussion...

Finally took a look at Visual Assist, as I've heard about it but never looked at it. That's very impressive. How much does it affect VS's speed on a fairly normal system?

I'd say 'It doesn't', which is objectively impossible but does represent my perception. In 7 or 8 years of using it, I have never found it to be a problem. This is with working on C++ projects with a total size (including third party libraries like boost) of around 400 megabytes of source code. The parsing of code happens behind the scenes; sometimes (when starting VS after a major update from source control or something) you see in the status bar 'Visual Assist: updating databases' or something like that, and sometimes the syntax highlighting takes a few seconds to kick in, but again I've never been annoyed or irritated with delays for which I had any reason to believe that they had anything to do with Visual Assist.

Of course Visual Studio still does its own parsing in the background, for example for the class browser. VA provides something similar, maybe I should use that one and see if there's a way to turn off the Visual Studio Intellisense. It is my subjective impression that this one does sometimes slow down the IDE itself.

My only complaints are the recent price hikes: 249$ -_- ? Those are getting above discretionary purchasing power and although I guess there is some effective productivity gain, it's very hard to quantify and therefore justify... Especially when other people don't want it, because then if you do want it, you look like a wuss who can't hold his own without having his hand held by pretty colors (simplifying of course but let's face it, this is what it looks like from the outside).

> Your comments about Vim's learning curve are spot on, and I don't think any vimmer will disagree with you

I would disagree with the gp's assertion that there is an extreme amount to learn to obtain basic editing efficiency. A dozen commands or so and gvim so you can use the mouse should take you 20 minutes and a bit of practice to feel comfortable with.

>any command I don't recall is readily available through the menus.

Any full featured editor has so many commands, menus are not practical to display them. VS included. So you're either using just using a subset of VS' functionality, or use hotkeys in VS too.

That's true, I misspoke. A wide variety of commands are available through the menus, and the rest are pretty readily discoverable through the Tools | Options | Keyboard.

I'm definitely using hotkeys very heavily in Visual Studio.

I kind of agree. I prefer the middle ground of notepad++ (with plugins for code completion and ftp/file explorer). Light and powerful while still resembling something designed for human consumption.

I'll just come out and say it: my favorite editor is Visual Studio

Not to be overly pedantic, but your favorite IDE is Visual Studio, and you just happen to use whatever crappy editor component comes bundled with it.

If we could have full-blown Vim embedded inside IDEs instead of good-but-incomplete plugins which merely give you some of the key mappings, I'd be elated and couldn't see why anyone would stick with the Notepad-style editor which is the default.

I never tried to make it work, but the vim distribution for Windows used to include a COM object which could be used as your Visual Studio editor.

It works, in a no-frills sort of way. I would much like it if I could get true embedding though.

Have you tried viemu? It's not real vim in that it doesn't have the plugins etc. but I haven't missed a single one of them.

vsvim also provides a lot of Vim goodness in VS. The main lacking feature (for me, personally) is macro support.

I use Visual Studio with ViEmu and Visual Assist X.

While I really hated Visual Studio (and still do), this combination of tools really makes it worthwhile. It is an awesome marriage of a mediocre IDE, some substantial refinements to make it usable, and a phenomenal text editor. The nice thing about ViEmu is that is extremely full-featured. It even reads my entire .vimrc with all my customizations and personal magic!

So, I guess what I want to say is that instead of deciding between using an IDE and a text editor, you should actually use both! Real progress lies in synthesis, not analysis!

Visual Studio? Sure, as long as you're only going to be coding on Windows.

I'm curious, does anyone use Visual Studio for non-code editing? For example, I'm typing this in Vim right now. I use Vim for lots of meant-for-human-readers text.

> as long as you're only going to be coding on Windows.

In the past, I've used VS for editing PHP, which I then deployed to the server using a keyboard shortcut.

I understand what you're saying, but I want to point out that VS can be used as an editor even when the target platform isn't MS.

But can you use it as an editor when the target platform is humans, that is, when you're not writing code at all?

Sure, why not?

I wouldn't start up a VS instance just to edit text, but if I have one running, it's my editor of choice.

Yes I'm sure it can.

What I'm curious about, is it so good an editor that people commonly use it for general text editing for non-code text? I know Vim and Emacs gets used like that a lot, maybe Notepad too.

As I said to another commenter, yes, as long as I have a VS instance running, it's my text editor of choice.

The startup time is too long for off-hand editing (I suppose this is hardware dependent). In that case, I'll open Notepad for quick to-do lists, or vi for non-line-ending-mangling tasks. It's pretty unusual for me not to have VS running, though.

Visual Studio is a great IDE for writing .NET code and is very good at C and C++ on Windows. When I started with PHP on Linux after 7 years of C++ and C# in VS, I quickly realized there was nothing comparable to VS and decided to scale the Vim learning cliff.

I've found Vim's text editing to be better than VS. For example, it's extremely to change a string - ci" - where in VS it's ctrl-leftarrow a few times then ctrl-shift-rightarrow a few times. In Vim it's much harder to compile things, no Intellisense, no refactoring, no decent equivalent to the Solution Explorer, and tons of other missing things. There's no doubt about it. A lot of these things are less useful when working in PHP, so Vim makes sense there.

Not believing the Vim hype is like wondering how anybody could be a Dallas Cowboys fan, which makes a lot of sense to people who grew up or live in Dallas. To people writing code where VS isn't available, there's more focus on editing letters which Vim lets you do more efficiently.

Actually I had the same argument about 15 years ago when I started using vim. Actually vim was forced on me on my first week of uni. We had to use "unix" (woooah)... anyhoo, the first 2 weeks were a total pain as we didnt have (or I couldnt find) alternatives... yes there was emacs but I couldnt be bothered go to another non-UI editor... but after that there was no looking back.. I think it is after that initial two week period that most vimmers remember and appreciate.

I know it is hard to justify plonking down 2 weeks when your current methods work. For me it is the ability to type what I am thinking without having to reach for the mouse (I know in VS you could customize keyboard shortcuts exactly the way you want but somehow it seemed a lot more obvious in vim for me).

By "non-UI", I take it you mean "non-GUI"? emacs certainly has its fair share of user interface, it'd be kind of hard to use otherwise. It can, admittedly, be kind of hard to use anyway, but that's not because it lacks a UI.

gvim has menus and the keyboard-reinforcing shortcut hints. Also, you can copy/paste with other windows (which is why I started using it over vim).

I'll echo the gvim menu hints recommendation for Windows users.

As to copy/paste, does that depend on the platform? I use vim in a terminal on Linux and Ctl+Shft+C/Ctl+Shft+V on selected text works fine for clipboard transfers. I don't use vim on Windows often enough to remember how things work there, however, and the article that prompted this discussion was focused on Mac usage.

I don't recall. I use gvim/vim on linux (although not gvim from term, because I don't like seeing the GLib errors :) ).

Am I foolish for not believing the vi/vim hype?

Not at all. If VS suits your needs, then rock on!

Personally, I enjoy the occasional vi/vim story here, as in reading the comments I almost always come away with several new ways of doing things in vim.

I think there's a better question to be asked, however. Given that programming involves a seemingly endless stream of tools/techniques that seem good enough and alternatives that are promised to be much better, do you have an efficient strategy for determining which alternatives to explore? (This is a question I've been wrestling with myself recently.) How much time should be budgeting for exploring an alternative before writing it off as a time sink instead of productivity multiplier?

In your case, since you already use vi/vim daily for some editing tasks, I'd suggest a low time-investment strategy of lowering the slope of your learning curve: review how you normally use it, isolate one or two procedures that seem awkward or irritating, and then focus a small amount of time on researching/practicing the recommended alternative practices of experienced users. I've found that by focusing on the occasional experiment, learning is much more enjoyable. If I think about how much I don't know about vim, on the other hand, I'm inclined to feel overwhelmed and put off learning anything.

Admittedly, this approach isn't going to help if your resistance point is learning to dump the arrow keys and mouse. On that one, I don't know that there really is any good alternative to a couple of weeks of devoted effort.

Vim certainly seems to have phenomenal potential. One problem I have, however, is the discovery of options, plugins, and "best practices" which lead to high productivity in vim. Basically, I want to pair program with some vim experts and talk about how they use vim.

Incidentally, in relation to your last paragraph, I don't see any advantage to vim's keyboard usage because I use a Kinesis Classic with a Dvorak layout. My arrow keys, home, end, page up, and page down are all within reach from home row. And of course, the Dvorak layout makes some vim shortcuts less intuitive. As for the mouse, I hardly touch it while coding.

Oh, but you need to use viemu (viemu.com), to have the sweet editing goodness of vim with the other great features of the VS IDE. It's awesome.

Reply on news.ycombinator.com