On Thu, May 05, 2011 at 10:49:23PM +0200, Tony Mechelynck wrote:
I don't really know any other regular expressions than Vim's, because
those are exhaustively documented, in a set of cross-linked helpfiles
which I constantly have at my fingertips.
A :helpgrep regex has just now shown me more
On 05/06/2011 05:27 AM, Erik Christiansen wrote:
I've been slow to realise that Vim users don't necessarily use
a variety of posix compliant applications, and so haven't
experienced the great productivity benefit of being able to
move between them _without_ trial and error, or resort to
On 04/05/11 17:04, Erik Christiansen wrote:
On Wed, May 04, 2011 at 10:00:40AM -0400, Charles Campbell wrote:
There's probably a history of regular expressions somewhere; ed
definitely preceded (the original) vi, and I think sed did, too. Awk
followed in sed's footsteps, and Perl came after
[Resending to the list. Originally from BPJ.]
2011-05-04 01:03, Ben Schmidt skrev:
perl returns '1a11c1', BTW!
Mmm. It's a bit debatable whether the second 1 in the 11
represents an
overlapping match or not. That's the problem with zero-length matches
that aren't solidly anchored; there are a
Ben Schmidt wrote:
[Resending to the list. Originally from BPJ.]
2011-05-04 01:03, Ben Schmidt skrev:
perl returns '1a11c1', BTW!
Mmm. It's a bit debatable whether the second 1 in the 11
represents an
overlapping match or not. That's the problem with zero-length matches
that aren't solidly
On Wed, May 04, 2011 at 10:00:40AM -0400, Charles Campbell wrote:
There's probably a history of regular expressions somewhere; ed
definitely preceded (the original) vi, and I think sed did, too. Awk
followed in sed's footsteps, and Perl came after vi. Vim follows
vi's reg-ex (with
Am 04.05.2011 01:03, schrieb Ben Schmidt:
perl returns '1a11c1', BTW!
Mmm. It's a bit debatable whether the second 1 in the 11 represents an
overlapping match or not. That's the problem with zero-length matches
that aren't solidly anchored; there are a lot of funny edge cases.
Ben.
Has it
If I use these command in bash shell:
echo 'abc' | sed 's/b*/1/g'
It would display:
1a1c1
But when I try it in VIM:
(open a document, turn into edit mode and simply type 'abc', and then
turn into command mode)
:s/b*/1/g
it would display:
1a1c
I'm wondering why I get
On 3/05/11 1:29 PM, HaoCheng Zhao wrote:
If I use these command in bash shell:
echo 'abc' | sed 's/b*/1/g'
It would display:
1a1c1
But when I try it in VIM:
(open a document, turn into edit mode and simply type 'abc', and then turn
into command mode)
:s/b*/1/g
it would
2011-05-03 05:29, HaoCheng Zhao skrev:
If I use these command in bash shell:
echo 'abc' | sed 's/b*/1/g'
It would display:
1a1c1
But when I try it in VIM:
(open a document, turn into edit mode and simply type 'abc', and then
turn into command mode)
:s/b*/1/g
it would
perl returns '1a11c1', BTW!
Mmm. It's a bit debatable whether the second 1 in the 11 represents an
overlapping match or not. That's the problem with zero-length matches
that aren't solidly anchored; there are a lot of funny edge cases.
Ben.
--
You received this message from the vim_use
Thanks guys ^_^
So, shall we get the conclusion that:
What sed does is correct according to POSIX, and VIM or PERL or some others
still need a bit improve on handling zero-length matches?
On Wed, May 4, 2011 at 7:03 AM, Ben Schmidt
mail_ben_schm...@yahoo.com.auwrote:
perl returns '1a11c1',
Vim's regular expressions are far from standard. Just browse pattern.txt
and you will see many oddities documented or demonstrated, as well as
many extensions to facilitate things such as syntax highlighting. I'm
pretty sure most other Vi and Vi clone programs have their own oddities,
too.
I'm
13 matches
Mail list logo
