Ingo Karkat wrote: > On 23-Apr-2014 17:37 +0200, Christian Brabandt wrote: > > > Am 2014-04-23 16:28, schrieb Bram Moolenaar: > >> 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. > > > > I see the problem with vim-airline. I think, it is caused by the > > evaluation of the statusline resetting reg_line_lbr when displaying the > > confirmation message. Attached patch fixes this, but I think one should > > also reset all the other internal static variables. > > Thanks Christian, that patch indeed fixes the problem for me. Good hunch > about the statusline, that is indeed a necessary condition (as I have > added in my updated message). > > You seem to be really knowledgable about Vim's internals. The question I > have in mind right now is whether you still feel comfortable about those > "internal static variables", or whether you think this poses long-term > risks to Vim's stability. At least some people think so, and have > suggested / started a complete rewrite (in a language like C++ that has > better means to avoid such). Is there anything (apart from more test > coverage) that we can do with the current code base?!
Traditionally Vim has been using a lot of global variables. Gradually I have been moving them into structs. This started when supporting multiple buffers and windows. There still is more to do. A complete rewrite is likely to introduce lots of new problems, another language won't help much. Refactoring is a much better solution. -- >From "know your smileys": :-) Funny |-) Funny Oriental (-: Funny Australian /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- 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.
