On Thursday, July 14, 2016 at 1:44:24 PM UTC-5, Tony Mechelynck wrote: > When the new regexp engine was introduced, it had so many bugs one > after the other that I had cold feet about using it and used ":set > re=1" in my vimrc to "temporarily" disable it. Today I asked myself: > “Is this still needed?” So I downloaded the ftp README and searched > it, ":0/^Individual patches/+3,$g/regexp/" with the following result: > > 2176 7.4.008 new regexp engine can't be interrupted > 2806 7.4.021 NFA regexp: Using \ze may result in wrong end > 3138 7.4.095 (after 7.4.093) regexp for LuaJIT version doesn't work on BSD > 3069 7.4.100 NFA regexp doesn't handle backreference correctly > 2643 7.4.253 crash when using external reference in syntax regexp > 3604 7.4.289 NFA regexp with repeated backreference does not match > 32746 7.4.330 using regexp pattern to show a position match can be slow > 3229 7.4.437 new and old regexp engine are not consistent > 118187 7.4.497 NFA engine is very slow with some regexp patterns > 3709 7.4.527 still confusing regexp failure and NFA_TOO_EXPENSIVE > 4671 7.4.668 can't use a glob pattern as a regexp pattern > 1953 7.4.685 with illegal utf-8 chars old regexp engine may crash > 1873 7.4.887 using uninitialized memory for regexp with back reference > 28965 7.4.1708 new regexp engine does not work properly with EBCDIC > 6286 7.4.1783 old regexp engine doesn't handle character classes correctly > 1579 7.4.1785 (after 7.4.1783) regexp test fails on windows > 5838 7.4.1967 falling back from NFA to old regexp engine has problems > > Problem: No dates. So let's try in a different way, on my hg clone > this time: "hg --config 'ui.verbose=true' log -f src/regexp_nfa.c" > (NB: with ui.verbose=false it doesn't show commit messages). > > The two lists are similar but not identical; however they seem to > indicate that although there have been lulls of more than 6 months > with no change, the latest one was on 28 June 2016, hardly more than a > fortnight ago. > > Conclusion: To every user his/her choice. Me, I'll let it cook a few > more months. Then I'll re-evaluate my policy. > > > Best regards, > Tony.
The latest fix (patch 1967) was not a failing in the new engine, rather a failing in the fallback when the new engine is "too expensive". Forcing either engine rather than letting Vim choose automatically made the pattern work correctly. The failure in question was a false match of a pattern with a lot of backtracking, in a very long line of text. So not even a common case. Most of the fixes for the engine were completed prior to the release of 7.4. Some of the patches you list do not relate at all to the regular expression engine; e.g. patches 95, 668. Others are fixes for the OLD engine. Others are not "fixes" but rather speed improvements. Even so, compare this overcounted list of 17 patches to a similar list from the 7.3 patches, where I filtered lines matching "regex\|regular\|engine" to get 79 patches. So, I don't think your fear of the new engine is all that warranted. I certainly wouldn't call it "unstable"; if I did I would basically need to call all of Vim's source "unstable". I avoided the new engine for several months as well, while it was first being developed near the end of 7.3. But I've been using it since around the time 7.4 came out and have only seen a handful of problems in weird cases, all of which have been fixed so far. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
