61

Why do you have to make your regex "very magic" so that you don't have to escape your capture quotes? And if you set your environment to very magic, you are non-standard and may have compliance issues. I am just wondering why vim uses a different regex syntax than say, perl?

dreftymac
  • 31,404
  • 26
  • 119
  • 182
user210757
  • 6,996
  • 17
  • 66
  • 115
  • 1
    Visual Studio's find and replace regex mode is also non-standard, even though they had a perfectly good standardish regex engine in .net. Take from that what you will. – Blindy Aug 30 '10 at 22:26
  • 1
    @Blindy: It's not quite that simple. When the VS flavor was created, the .NET regex flavor didn't exist yet. The could have based the VS syntax directly on Perl's like the .NET team was doing, but they chose to maintain continuity with earlier MS tools. I'm not defending that choice, just pointing out that it wasn't completely brain-dead. ;) – Alan Moore Aug 31 '10 at 04:39
  • 1
    @Alan Moore: Didn't say it was, my point was that VIM wasn't the only one to make this choice. VS is my favorite piece of software ever made :) – Blindy Aug 31 '10 at 07:16
  • 2
    I find vim regexes bulky and arbitrary. Having to escape some operators `\(\)\+` but not others `^$*[]` is kind of stupid. – Mateen Ulhaq Feb 24 '18 at 07:46
  • yes another stupid one is non-greedy match in vim. `a.*?b` in pcre in vim will be `a.\{-}b` PCRE is industry standard nowadays, and there must be some facility in gvim to use pcre... even a new vim that is compiled just to use pcre. – ihightower Dec 02 '20 at 17:03

3 Answers3

74

Most vi (and therefore vim) features were derived from ed. vi and ed both predate perl by at least a decade or two. A better question might be "why doesn't Perl use the same regex syntax as vi?".

Of course, one could also argue that the kinds of regular expressions that one would wish to write inside a text editor to perform common tasks are probably rather different to those you might wish to write inside a programming language.

Gian
  • 13,735
  • 44
  • 51
  • 46
    True, but personally, IMO, there's already too much fragmentation in developer mindspace. PCRE's are pretty much an "industry standard". One of the things I love about VIM is how many options it has. Using PCRE as the search/replace engine should be at least allowed as a ./configure flag – rossipedia Aug 30 '10 at 22:56
  • 11
    It's an open source product. If this is a killer feature for you, why not implement it and submit it as a patch? Maybe there are others who feel the same way and would benefit from this. – Gian Aug 30 '10 at 23:57
  • 2
    @Bryan: Vim's regex has a ton of features not available in PCRE - everything starting with `\%` or `\\_`. – too much php Aug 31 '10 at 02:22
  • @too much php Why `\\_`? I like handling of end-of-line by PCRE more then by vim: `[^\n]` will match everything (including `\n`) in vim and everything except `\n` in PCRE, which is strange (but documented). `\%$` and `\%^` are not needed in PCRE because we have /m and /s flags, so PCRE lacks only match at given position feature. And there are plenty of features in PCRE, that lack in vim (`\p{}`, normal unicode handling, `[\uXXXX-\uYYYY]` where `YYYY-XXXX` is greater then 255, recursive regular expressions, >9 capture groups, ...). – ZyX Aug 31 '10 at 03:12
  • 2
    @Bryan: because \_s is easier than [ \t\r\n]. There are still many plugins and features that rely on the vim regex syntax, so it would be tricky to compile it in. (Admittedly, if you got it working I'd be using it all day ...) – too much php Aug 31 '10 at 07:11
  • @too much php Not `[ \t\r\n]`, but only `[\s\n]`. Conversion of `\r\n` into single linebreak is done before using a regular expression and does not apply to strings (`echo match("\r", '\\_s')` will always show -1). And matching `\r\n` as a single `\n` is also possible in perl. There are two other features that vim has and PCRE has not: non-fixed-length lookbehind and branches (last can be replaced with lookaheads). Note that columns can be replaced with lookbehinds (though it is not so trivial). – ZyX Aug 31 '10 at 08:12
  • I guess compiling vim with the +perl feature is good enough. Totally forgot about that. – rossipedia Aug 31 '10 at 21:54
  • 5
    Want to mention this vim tip to execute perl search/replace in vim compiled with +perl: http://vim.wikia.com/wiki/Perl_compatible_regular_expressions – acorello Oct 16 '11 at 15:28
10

There is a plugin called eregex.vim which translates from PCRE to Vim's syntax. It takes over a thousand lines of vim to achieve that translation!

Evgeni Sergeev
  • 22,495
  • 17
  • 107
  • 124
  • 4
    "It takes over a thousand lines of vim to achieve that translation!" To be fair, (currently) 279 of those lines are comments. :-) But still 803 lines (1082 total) of code! Pretty beefy. – Victor Zamanian Jun 03 '14 at 09:44
  • I'm curious why they can't make the translation using regular expressions – WhyNotHugo Jun 19 '20 at 10:04
2

In addition to the mentioned reasons vim has some cards in the sleeve when it comes to regex, for example, to match positive look behind we do:

:%s/^foo \zsbar/moo/g

The above command will substitute "bar" for "moo" in the lines started with "foo".

the \zs makes easier to set a positive look-behind and \ze makes easier to make a positive look-ahead.

We also have a way to match only in the "visual area" -> \%V

:'<,'>s/\%Vthis/that/g

Although using the global flag "g" the substitution is restricted to the visual are due \%V

To read an awesome article about how amazing vim regexes can be, follow this link: https://bitbucket.org/snippets/sergio/7nzqxx

We can also use some "submatch" tricks on vim substitution https://dev.to/voyeg3r/vim-math-on-vim-substitution-4obo

SergioAraujo
  • 11,069
  • 3
  • 50
  • 40