-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 15-Mar-2015 10:08, 'Andy Wokula' via vim_dev wrote:
> Am 14.03.2015 um 20:14 schrieb Ingo Karkat:
>> -----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.
> I think the current behavior is ok (snafu ...).
Yeah, realistically, the bug would only be included as a low-prio item
on the todo list, and probably not addressed within this decade :-(
Maybe the neovim project will write a different parser and avoid the
problem. I'm a bit sad about this state of affairs, but on the other
hand, Vim is still incredibly useful (even with this minor bug), so
I'm fine with it.
> If you use "[" unescaped, you should know what you are doing.
Agreed. That's why I'm mostly afraid of plugins breaking due the
inconsistency.
> Because: even with "correct" parsing, the pattern may still change,
> eg what if "]" occurs in the replacement part: :s/[/x]/g
No, that's not an unclosed [ followed by ] in the replacement part,
but a correct collection of / and x. The delimiter doesn't have to
escaped inside a collection (didn't find that documented, but it's how
the implementation works).
> Now the original pattern "[" becomes "[/x]" and the only fix is
> :s/\[/x]/g
Right. You can't use unescaped unclosed [ when there's a ] in the
replacement part.
>>> 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)
iQEcBAEBAgAGBQJVBeE/AAoJEA7ziXlAzQ/vwHQH/joTf1L31UjJy+GkBZ2LQ3/O
NgV5IgtNj6XYEx32sGgRfN4D98giOqHddIcDeBgWD7nWVgnk9h9DD0U9AcVKTjWi
ubQgk/Uuup9xM0Gg3Q5Jt9zsYJgQKiEtzkGfWQL5sXt0KLEBRqEkQ9u3R1ESvl8S
0QyAevIh29m7K9BIhGv12G/MNlhX3mGbkZ53hol/UKse4Rkj6pNrhOy2V5KLoevf
BrItCea6JNw37cJIkkq9SyNxKerYMV5v2A+thh0FI1r8ZyR4p8eM71mXrKZRd6O0
ZdiIjOjUVXLfqTbSbQs70E/iD6UfWS3AzEBcLTg3bYFqlrdDukVUN7EDdRDWzw0=
=Vq7g
-----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.
