-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 14-Mar-2015 15:34, Bram Moolenaar wrote:
> 
> Ingo Karkat wrote:
> 
>> On 14-Mar-2015 02:11, James McCoy wrote:
>>> On Fri, Mar 13, 2015 at 09:54:18PM +0100, Ingo Karkat wrote:
>>>> it's possible to avoid escaping a "[" character:
>>>> 
>>>> ,----[ :help E769 ]---- | When the ']' is not there Vim will
>>>> not give an error message but | assume no collection is used.
>>>> Useful to search for '['. `----
>>>> 
>>>> But when using that feature in a :substitute command, the 
>>>> replacement part is mistakenly added to the pattern:
>>>> 
>>>> :s/[//g E486: Pattern not found: [//g
>>> 
>>> No, that's not what's happening.  You can leave off the entire
>>>  replacement and the delimiter before it.  When this happens,
>>> Vim treats it as deleting the matching strings.  To quote:
>>> 
>>> If the {string} is omitted the substitute is done as if it's
>>> empty. Thus the matched pattern is deleted.  The separator
>>> after {pattern} can also be left out then.  Example: >
>>> :%s/TESTING This deletes "TESTING" from all lines, but only one
>>> per line.
>> 
>> Right. My point is that because the "/" delimiters are not
>> actually left off (they are there, in the correct, unescaped
>> form), the :s command *mistakenly* runs into the case you've
>> quoted. Putting it yet another way, the "[" consumes the
>> following characters (including the unescaped separators),
>> assuming they belong to the collection, and when at the end the
>> collection isn't closed, the parsing should backtrack and
>> reinterpret, but it currently doesn't.
> 
> I understand that this is confusing, but it's working as
> documented.

I don't see this particular behavior documented. I would expect
something like this (highlighting the current inconsistencies):
"An unclosed [ will do a literal search, but when such pattern is
directly included in a :substitute command (but not when such pattern
is reused from the last search via :s//...), the remainder is
interpreted as the pattern; i.e. you cannot add a replacement part and
:s_flags there.

> The alternative, detecting the unclosed [ in some circumstances,
> will make it less consistent and probably even more confusing.  So
> let's just leave it as it is.

I've never argued for that. Of course, the unclosed [ would have to be
detected in _all_ circumstances. That shouldn't be too difficult; the
regexp engines already do that.

> It's clear that if you type the wrong command things may go wrong.

I don't think :s/[/x/g is wrong. It simply parses as pattern=[,
replacement=x, flags=g. Unfortunately, Vim's implementation is buggy
and parses it as pattern=[/x/g replacement= flags= (because the [...]
collection parsing suspends the delimiter parsing until the closing ],
but this isn't a collection, so it shouldn't apply!)

If I had wanted that, I would rather type :s/[\/x\/g (or
:s/[\/x\/g//), i.e. properly escape the / delimiters.

> That's what we have undo for.

As I said, I'm mostly worried about plugins blindly putting @/ into
the :substitute (maybe with prepending / appending something else, and
then failing due to the inconsistency caused by the bug. That would be
hard to detect by the user; undo wouldn't help much.

I'm all for consistency, and fixing this bug would IMO increase that,
so that the special case of unclosed [ and the :s/// separators
interact in a benign way. I was motivated to report this because one
Vim user was struggling with just this, and went to Stack Overflow to
ask for help.

- -- regards, ingo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJVBIifAAoJEA7ziXlAzQ/v4TsH+gPD7aPCR98auBnAzamL97QB
kewrhUxGy/VtL3sNq8gfjhK/hHx3TyFT+hmcxEhsKHpHw5XT2WnBnagUVadZ1t6l
JD4yxcdxf2z7Rj5RL5Is4hSP/dCJseYydByZcACaPwdeZJ3YJQz1buRFNTjNF4MU
vf0DBaNi6VIULfaQl2QnWiH3p7B2qcp/qPRkuT7Zt6V9SRRBmUx/GfpRCKMW9BWg
89uHCPV77GqRU8EUawdzq3WnxMEb4PJMZiZVwcxLvm6eBqi8WpCIw9+W/oPWqj+3
j2nwXmOzUybc8rp+Y4zojSLsUuhl/Kr9BVG9xo6h9NN1Eq7uUoMzdS8iBJPC2gE=
=AmaI
-----END PGP SIGNATURE-----

-- 
-- 
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.

Raspunde prin e-mail lui