Re: RFE: support POSIX standard and developing RE's

About this I think the following:

1. If implemented, PCRE syntax support should be like current engine
select option support, though without possibility to use `set re` to
switch to PCRE globally. I.e. `\%#=P` as the first charaters in
pattern will enable PCRE syntax and select libpcre (or whatever will
be used) as an engine. But `set re=P` is a error and `P` is literal
`P` and not some number. This way it will not break anything existing.
2. `g/` and `g?` are still free. As well as `z/` and `z?`. These
should be reserved for users because it is natural to map `g/` to
`/\%#=P`. But it is not needed to create such a standard mapping:
maybe some time later better re syntax (e.g. perl6) will be added; and
this mapping is very trivial for users to write. Mapping should be in
the vimrc_example though.
3. Most of bugs created by introducing new re engine were bugs in the
new re engine, not in the code that selects engine to use. If it is
possible to employ libpcre or regex engine from libc then most of
these bugs will not occur because new code is code that integrates
regex engine. Integration code is not going to be as huge as regex
engine itself, and regex engines like libpcre are thoroughly tested.
4. Even though Vim regex syntax sucks, it does not have many features
missing. Basically I miss named capturing groups (i.e. `(?<name>…)`),
recursive regular expressions (i.e. `(?R…)`), unicode support (i.e.
\p{character set description based on unicode properties}), sometimes
I think that I may make use of (?{expr}) (zero-width atoms that
executes perl (perl only, it is not PCRE feature) code when this atom
is matched, and this atom always matches when it has a chance to). In
applications which use libpcre I miss non-fixed-width look-behinds:
this is the only way I know to match non-escaped something (i.e. the
only way I know to check whether number of preceding backslashes is
even or odd).

So as @LCD 47 said "what you are asking for might not actually
make as much sense as it first seems". It is better to have these
features in core then to have PCRE syntax support.
5. One cannot implement PCRE-enabled s/// based on :perldo or :pydo.
Some regular expressions may match more then one line (and I *do* use
these), so one needs the whole buffer. This is going to be slow on
large buffers. This is also going to be hacky: one cannot take the
whole buffer contents, run regular expression and assign buffer
contents back: such action will make Vim think that the whole buffer
was replaced. So it is needed to compute where change starts and ends
and replace only these lines. Likely :undojoin also needs not be
forgotten.

So it is not too easy to make :s command with PCRE syntax and such
action does not provide much benefit. Of course there is no hurry.

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.