Of the former, the help file says:

What is now called the "old" regexp engine uses a backtracking algorithm. It tries to match the pattern with the text in one way, and when that fails it goes back and tries another way. This works fine for simple patterns, but complex patterns can be very slow on longer text.

The new engine uses a state machine. It tries all possible alternatives at the current character and stores the possible states of the pattern. This is a bit slower for simple patterns, but much faster for complex patterns and long text.

Most notably, syntax highlighting for Javascript and XML files with long lines is now working fine. Previously Vim could get stuck.

The initial work was done in a 2008 Summer of Code project: http://code.google.com/p/vim-soc2008-regexp/source/list

but there were lots of fiddly issues with character classes and Unicode handling, a need for exact equivalence to the old regex engine to avoid arbitrarily breaking existing scripts, and a need for a comprehensive test suite, all of which took a while for people to supply.

http://swtch.com/~rsc/regexp/

To future regexp implementors: Do it this way first!

Russ Cox? You know that regular expressions have existed since Kleene's first proposals, and everyone with a CS degrees knows that you can compile them to deterministic finite state automata. Right?

I'm struggling to understand your negativity here..

Sorry, that was indeed a bit harsh. I wanted to point out that Bram Molenaar is probably well-aware of DFAs given how well-known they are and how many implementations there are available. I don't think Russ Cox has much too do with it and rather that it is driven by demand - linear time matching is attractive for syntax highlighting.

Oh, wait.

However, the problem is that not all regular expressions 'dialects' (most notably Perl regexes) are not regular languages and cannot be represented as a finite state automata. For instance, the introduction of back-references makes regular expressions non-regular.

So, it's not so much being enlightened by Russ Cox, but a trade-off between the convenience of some of the Perl extensions and the ability to apply matching in linear time. Also, for complex expressions, constructing the automaton can be slow.

[1] A small selection:

http://www.brics.dk/automaton/

http://www.let.rug.nl/~vannoord/Fsa/

http://www.complang.org/ragel/

http://open.xerox.com/Services/fst-nlp-tools

Some of the packages can also be used to construct transducers, weighted automata, etc.

The classic DFA engines, like in Thompson's version of grep, provide a fairly minimal regex language (later standardized as POSIX regexes), not much fancier than the regular-language syntax used in textbooks. Perl-style regular expressions get such widespread usage even outside of Perl in part because they have a more full-featured syntax, which provides conveniences people find useful. Cox implemented a significant subset of this functionality as syntactic sugar on top of a classic automaton regex engine, so RE2, unlike POSIX regexes, supports named matches, named character classes like \d (plus Unicode character classes), non-greedy matches, etc. Basically everything that can be done without making the language nonregular, so excluding lookahead, lookbehind, and backreferences.

Since vim regexes (a custom dialect) support some of those supra-POSIX features, those implementation techniques were likely useful for them to look at. Indeed they link to Cox's article somewhere or other in the design docs.

Vim does have lookahead/lookbehind syntax, though; I wonder how they supported that. Fallback to the backtracking engine?

He talks about schooling after his undergrad, but doesn't go into what that was.

[1] http://www.youtube.com/watch?v=aNAtbYSxzuA

Does anyone know more details about new regex matcher? (I don't think I will be able to read the code).

[0]: http://swtch.com/~rsc/regexp/

Today I made it so that every time I open a .markdown file, vim compiles it to html and opens it in my browser (using 'open' command on OS X). It also updates it automatically every time I save or leave insert mode.

I've also hacked together a python REPL inside a vim window. (Wasn't very hard, as vim has python built-in.)

Once you realise that Vim is just an extension of the command line, a new world opens up. Everything you can do from the command line, you can do from Vim. Throw in Python and the options are endless... So much POWER!!

BTW: I also discovered vim has MzScheme built-in, so don't go for emacs just because of lisp... Vim has a nicer lisp! Come to the dark side, we have cookies! (And lisp.)

Edit: Safari reloads the existing tab, so set the default browser to Safari if you want that.

https://github.com/suan/vim-instant-markdown

https://github.com/rcarmo/macvim/releases/tag/7.4

It's a tad controversial, I know, but I find it vastly more friendly than NERDTree, and I know quite a few people were looking for alloy's builds a while back.

EDIT: screenshot, from an older build:

https://f.cloud.github.com/assets/392683/793013/469e0c62-ebd...

you can also get it here - https://gist.github.com/mjhea0/6200588

New patches for 7.4 will be in the patches/7.4 folder.

This is ridiculous.

http://chocolatey.org/packages/vim

Just the other day I was able to update a whole load of software on my laptop using the 'cup' command - which worked almost perfectly. It broke my installation of Libre Office - which I then had to install the old fashioned (for windows) way. But that was still a considerable amount of time saved for me!

http://code.google.com/p/macvim/downloads/list

In ~/.gvimrc:

  " no toolbar
  set go-=T
  " no right scrollbar
  set go-=r
  " no left scollbar
  set go-=L

  :set go=aAcegimtv
  :set go-=vtmigecAa
  :set go? " guioptions=aAcegimtv

  set go-=T go-=r go-=L

Are you sure? Check out my build: https://github.com/rcarmo/macvim/releases/tag/7.4

EDIT: link to fixed release.

$ ./MacVim dyld: Library not loaded: /usr/local/lib/liblua.5.1.5.dylib Referenced from: /Applications/MacVim.app/Contents/MacOS/Vim Reason: image not found

EDIT: fixed! Disabled Lua for now, I have both my own build and brew's installed, and it will take some time to sort out.

The undo branching feature seems like it could be useful as well.

I don't agree with that at all. Vim is useful, perhaps, for a few text matching tricks but typing speed is rarely the bottleneck in programming. It's optimising for the wrong thing.

The only people advocating for vim are those who have already gone through the pointless pain of 5 years learning to use the thing. It's basically a cult, or at least a club. And frankly, watching these vim "power users" is usually quite frustrating - they struggle to do trivial tasks which can be accomplished in sublime with a simple right mouse click.

It is important to know the basic vim commands for when you are editing text via ssh but for everyday use sublime text is, IMO, superior in every way.

> typing speed is rarely the bottleneck in programming

You're right, especially if you're using a language that doesn't require a lot of boilerplate. But between the UNIX shell and the normal vim add-ons, even higher-level editing tasks, i.e. those that aren't strictly about raw editing, shouldn't give vim users trouble.

As with negatmx, I'm convinced you haven't met people who use vim properly. Name a task on which you've either seen or you'd imagine a ST user to outperform a vim "power user". I'll let you know the logical way to do it in vim.

[1] To obtain solid proficiency with the vim editing model, just work through the interactive vimtutor, read up on text objects, and spend a couple hours acclimating yourself to using the following motions and commands in place of hjkl (sort of but not necessarily in order of usefullness):

/ ? n N f F t T # *

gg G <n>G (e.g. 42G)

H M L

^ 0 $ { } ( ) w W b B e E

C-f C-b C-d C-u

zt zz zb

Selecting code and copy and pasting it into a chat client for discussion.

Grabbing someone else's code from a chat client and editing it, then copy and pasting it back to show them my interpretation.

Copying an error message and pasting it into a web browser.

Installing or updating any kind of plugin or package.

Doing anything out of the ordinary (vim users will be googling for the arcane sequence of commands and don't try the "no true scotsman" defence for that - they all do)

Scrolling smoothly through a large file looking for a certain method you will know by shape.

Quickly navigating a tree of files at the side of the window.

Changing the font to something post-1980.

Make it look good (this willl take infinite time)

I could go on, and on, and on.

Anyway, I have no doubt that for some tasks it's possible to train yourself to be very fast in vim, and if you find that measurably speeds up some aspect of your productivity you care about, then more power to you. However, I haven't really observed this being the case.

It's sort of like Linux vs MacOSX on the desktop. Linux people can and do customise their machines to an amazing extent, all sorts of crazy window managers and weird shell extensions, all promising great improvements in window management and shell completion, etc. But at the end of the day, I don't notice linux-using programmers as being any more productive, as a rule, than mac users, who tend to not fetishize the tool so much and just want to get on with the job. If anything, it's the opposite. I admit I'm biased against vim because of how ugly it is, which is sort of why the linux vs mac analogy works for me. I love linux by the way and use it on the server, and I also edit on the server with vim : P

Anyway, I'm making much bigger a deal about the matter in this thread than I actually feel! I just don't think vim is a slam dunk, is all.

Note, due to HN's treatment of asterisks as formatting characters, I'm going to represent a literal asterisk as [asterisk].

In gvim, selecting code to copy into the system clipboard is as easy as "[asterisk]y plus the motion or text object (e.g. `"[asterisk]y3}' for the next three paragraphs or `"[asterisk]yat' for the current HTML/XML tag). You can even configure console vim to copy into the X clipboard: http://vim.wikia.com/wiki/Accessing_the_system_clipboard

> Grabbing someone else's code from a chat client and editing it, then copy and pasting it back to show them my interpretation.

I run vim and irssi from inside GNU screen, so it's as simple as `C-o [' (my screen prefix is `C-o') to access the scrollback buffer, spacebar to start selection, use screen's vim-like selection commands, spacebar again to yank the selection, switch screens, and then `C-o ]' to paste. The whole process is instinctive and takes no more than five seconds.

> Copying an error message and pasting it into a web browser.

See the above two answers.

> Installing or updating any kind of plugin or package.

The vundle package manager takes care of that.

> Doing anything out of the ordinary (vim users will be googling for the arcane sequence of commands and don't try the "no true scotsman" defence for that - they all do)

No, they'd most likely use some combination of the brilliantly orthogonal editing language that is Vim and the brilliantly orthogonal computing environment that is UNIX to reach a solution in time that would amaze a Windows user. In fairness, most Sublime users I know would do the same.

> Scrolling smoothly through a large file looking for a certain method you will know by shape.

How would Vim and Sublime differ on this one?

> Quickly navigating a tree of files at the side of the window.

Vim users do the same. It's called the NERD tree plugin. I personally find it faster to navigate with autojump from the command-line and then open files in vim from the command-line, but many Vim users like the tree approach.

> Changing the font to something post-1980.

You add a line to your ~/.Xdefaults or ~/.Xresources for console vim or to ~/.gvimrc for gvim. It's no harder than changing fonts in Sublime. I personally like 14-pt Bitstream Vera Sans Mono. It looks similar to Sublime's default iirc.

> Make it look good (this willl take infinite time)

I don't know if by "it" you mean the font or the colorscheme, but as with Sublime, some fonts and colorschemes are really nice and some aren't. It sounds like your criticism here, as with virtually all of your points, is that vim's default settings, unlike Sublime's, are not optimized for use as an IDE. That is correct. However, instead of bashing vim for this use case with uninformed, antagonistic statements like making it look good will take infinite time, all you have to do is ask or google how to configure vim for such a use case. A lot of vim plugin writers are ex-Sublime users, so it should be pretty easy to make vim simulate the default Sublime feature set, if you really wanted to. If you're more comfortable with Sublime, it makes total sense to stick with it. Perhaps Sublime Text's greatest strength is that its default configuration is excellent for software development. As you pointed out, typing isn't normally the bulk of development time, so if you're already happy with an editor, you really don't need to switch to a faster one. Just don't tell others who do use one that's said to be faster that you, someone who has only used their editor in a console/ssh capacity (and from the sound of it, a casual capacity at that), knows their editor's shortcomings for development better than they do.

> It's sort of like Linux vs MacOSX on the desktop. Linux people can and do customise their machines to an amazing extent, all sorts of crazy window managers and weird shell extensions, all promising great improvements in window management and shell completion, etc. But at the end of the day, I don't notice linux-using programmers as being any more productive, as a rule, than mac users, who tend to not fetishize the tool so much and just want to get on with the job.

I know quite a few Mac OS X users who care very much about their programming environment/toolset, and I do think they're more productive than those who don't.

> I admit I'm biased against vim because of how ugly it is

But it's not! If you're running it on ssh and if your console font is ugly, then yes, it will be ugly. But that's like saying that ST is ugly if you set it to use whatever ugly font your shell is set to. Vim is configurable, and a sane vim/gvim set-up looks clean and beautiful. Since you're a Linux server user, you should know the power of configuration!

If you want to meet the real vim hacker, try to do some task in vimgolf.com. We will see ;)

I'm not talking out my hat at all. I notice no productivity improvements from using vim. Maybe some appear in different lines of work, but I'm not saying it just to annoy you.

I don't notice Gentoo users being all that much more productive than Ubuntu users, either. It's basically a hobby to endlessly tweak your environment, and so is vim, IMO.

2.-Adding the package name to a file and typing BundleInstall

3.-Basic window management... (Have it mapped to Alt+hjkl)

I know how to do all of these very easily from first week of serious usage. I'm using vim for less than a year and wouldn't call myself a "vim power user".

I think it's a little bit adventurous to judge an editor that popular for that long time based on seemingly (seeing the use cases you said) limited personal experience.

However, in the general case, I don't think it is much of an advantage in and of itself, which is why I disagreed with the poster above matter-of-fact stating:

> Productivity is far greater with vim

as if that was an indisputable fact. It is not. That was the thrust of my argument.

And regardless of typing prowess, knowledge of sound, elegant design is the essence of good programming. How fast you can edit text is almost irrelevant in the long term. I know excellent programmers who basically type with two fingers, and shitty copy and paste hack programmers who do their damage at an amazing rate with vim. The two-finger typists make more than the vim wizards, and for good reason. Don't confuse the tools with the craft itself.

For me, given that Vim is easily powerful enough to compete with any other editor, the benefits of ubiquity override anything else.

I use an IDE for code, FocusWriter for just about everything else involving text and nano for server work (I'm can use vim if needed but I prefer nano for quick config file edits and after using it for a decade muscle memory isn't worth fighting).

For large web programs ( html/js etc), once you use Sublime, no going back to VI. The plugin ecosystem for js fwks are awesome.

/ducks

All editor-fanboyism aside, who cares? I spent $59 on ST2 and it was, by far, the best $59 I've ever spent. But if someone is more comfortable with vim or emacs or nano or gedit, I don't care. It doesn't bother me, as long as you're making something.

I adore Sublime Text, and use it where I can, but there are instances where I need to work on something remotely. Bug fixes, git rebasing, etc; and that's where I lean on Vim.