On 23-Apr-2014 16:28 +0200, Bram Moolenaar wrote: > Ingo Karkat wrote: > >> I've noticed a regression: >> >> :s/.*/\="foo\nbar"/ >> >> This correctly replaces the current line with two lines containing "foo" >> and "bar", respectively. Now add the confirm flag, and accept the >> replacement: >> >> :s/.*/\="foo\nbar"/c >> >> This replaces the current line with a single line containing "foo^@bar" >> (where ^@ is <Nul>). This is inconsistent and unexpected. Replacing with >> \r instead works (with and without the flag), and can be used as a >> workaround. >> >> Using the attached scriptlet, I've bisected this to the following patch: >> >> ,----[ bad change ]---- >> | 7.3.225 "\n" in a substitute() inside ":s" not handled correctly >> `---- >> >> The problem therefore can be seen in this and all following Vim >> versions, verified up to the latest 7.4.258. (I've used a HUGE build on >> both Windows/x64 and Linux/x64.) > > I cannot reproduce this problem.
Ah, sorry, I missed one crucial detail of my environment (and forgot to
use -N -u NONE). In my 'statusline', I have a custom function that
performs a =~ comparison. Define the following:
function! TitleString()
let check = 'foo' =~ 'bar'
return ""
endfunction
set titlestring=%{TitleString()}
Then, the
:s/.*/\="foo\nbar"/c
command will produce the ^@. So the =~ (probably triggered while the
confirm flag is in action) somehow affects the behavior of :substitute.
Attached is an updated scriptlet.
-- regards, ingo
--
--
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.
bug-s_c-newline.vim
Description: application/octetstream
