Am 14.03.2015 um 20:14 schrieb Ingo Karkat:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1On 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: [//gNo, 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 ...).
If you use "[" unescaped, you should know what you are doing.
Because: even with "correct" parsing, the pattern may still change, eg
what if "]" occurs in the replacement part:
:s/[/x]/g
Now the original pattern "[" becomes "[/x]" and the only fix is
:s/\[/x]/g
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
-- Andy -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
