E749 on switching to buffer
Vim warns E749 on switching to a buffer which used to be checked diff. How to reproduce. 1. vim -u NONE -N 2. :e test | diffthis 3. :vnew test2 | diffthis 4. :e test3 5. :buffer # Error message E749: empty buffer What I expect Vim opens the test2 with no error message. Environment Vim 7.4.796 VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jul 23 2015 08:48:19) MacOS X (unix) version Included patches: 1-796 Compiled by Homebrew Huge version without GUI. Features included (+) or not (-): +acl +cmdline_hist-dnd -footer +lispindent -mouse_jsbterm +perl+scrollbind -tcl +viminfo -xterm_save +arabic +cmdline_info-ebcdic +fork() +listcmds +mouse_netterm +persistent_undo +signs +terminfo +vreplace-xpm +autocmd +comments+emacs_tags -gettext +localmap +mouse_sgr +postscript +smartindent +termresponse +wildignore -balloon_eval+conceal +eval-hangul_input+lua -mouse_sysmouse +printer -sniff +textobjects +wildmenu -browse +cryptv +ex_extra+iconv +menu +mouse_urxvt +profile +startuptime +title +windows ++builtin_terms +cscope +extra_search+insert_expand +mksession +mouse_xterm +python +statusline -toolbar +writebackup +byte_offset +cursorbind +farsi +jumplist +modify_fname+multi_byte -python3 -sun_workshop +user_commands -X11 +cindent +cursorshape +file_in_path+keymap +mouse +multi_lang +quickfix+syntax +vertsplit -xfontset -clientserver+dialog_con +find_in_path+langmap -mouseshape -mzscheme+reltime +tag_binary +virtualedit -xim +clipboard +diff+float +libcall +mouse_dec +netbeans_intg +rightleft +tag_old_static +visual -xsmp +cmdline_compl +digraphs+folding +linebreak -mouse_gpm +path_extra +ruby-tag_any_white +visualextra -xterm_clipboard system vimrc file: "$VIM/vimrc" user vimrc file: "$HOME/.vimrc" 2nd user vimrc file: "~/.vim/vimrc" user exrc file: "$HOME/.exrc" fall-back for $VIM: "/usr/local/share/vim" Compilation: /usr/bin/clang -c -I. -Iproto -DHAVE_CONFIG_H -DMACOS_X_UNIX -Os -w -pipe -march=core2 -msse4.1 -mmacosx-version-min=10.10 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 Linking: /usr/bin/clang -L. -L/usr/local/lib -L/usr/local/lib -Wl,-headerpad_max_install_names -o vim-lm -lncurses -liconv -framework Cocoa -pagezero_size 1 -image_base 1000 0 -L/usr/local/lib -lluajit-5.1 -fstack-protector -L/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE -lperl -framework Python -lruby.2.0.0 -lobjc Hope it fixed. Thanks. -- -- 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.
Re: Patch to add the :cdo and :ldo commands
I agree with h_east that if you’re planning to run the :substitute command across multiple files, it makes sense to use: :cfdo %s/pattern/replacement/g and not: :cdo s/pattern/replacement/g I can also see myself wanting to use the :cdo command in combination with :normal for certain types of task. But I’ve come across another problem. Suppose that we have a text file containing these four lines of text: http://example.com http://example.org http://example.net http://example.com http://example.org http://example.net Now let’s say that we want to turn each occurrence of ‘http’ to ‘https’. (We could use the :substitute command here, but let me use this to demonstrate a problem with using :normal). We’ll use :vimgrep to populate the quickfix list with 6 matches: :vimgrep /http\zs:/g % Then we’ll insert the ’s’ character in front of the colon with this command: :cdo normal is The resulting text looks like this: https://example.com https://example.org https://example.net https://example.com httsp://example.org htstp://example.net In the last line, we get ‘https’, then ‘httsp’, then ‘htstp’. Not ideal! The problem here is that the quickfix list records line and column numbers. If characters are added or removed near the start of the line, the column numbers for later matches on that line will no longer line up with the match that created the original quickfix list entry. I’m not sure if this is a problem with the quickfix list, with :cdo, or with :normal. Drew On Sat, Jul 25, 2015 at 6:22 PM, Yegappan Lakshmanan wrote: > Hi, > > On Sat, Jul 25, 2015 at 9:55 AM, h_east wrote: > > Hi Yegappan and Bram > > > > 2015-7-25(Sat) 12:27:56 UTC+9 yega...@gmail.com: > >> Hi Hirohito, > >> > >> On Fri, Jul 24, 2015 at 3:42 PM, h_east wrote: > >> > Hi Yegappan, Bram and List > >> > > >> >> >> > > >> >> >> > Thanks for testing the patch. I will send out an updated patch > in a few days. > >> >> >> > Hopefully this time it will get included. This has been > outstanding for more > >> >> >> > than two years. > >> >> >> > > >> >> >> > >> >> >> The updated patch (against vim 7.4.796) is attached. > >> >> > > >> >> > Thanks. So now it's ready to include, right? > >> >> > > >> >> > >> >> Yes. Of course :-) > >> > > >> > I confirmed this patch. > >> > > >> > I found unexpected behaviors. > >> > > >> > >> Thanks for testing the patch and sending the bug report. I am attaching > >> an updated patch that fixes the two problems. Let me know if you see any > >> issues with this attached patch. > > > > I confirmed that reported problem have been fixed. > > Thank you for quickly fixes. > > > > I think it is better to discuss. > >> > This is my opnion. > >> > When the search pattern exists more in a row, I think :cdo/:ldo > confuse to use. > >> > and the processing time tends to be long. > > > > Do you understand that the results of the following two commands are > different, > > When the search pattern exists more in a row? > > > > The ":cdo" command executes the supplied command for every valid entry > in the quickfix list. It is upto the supplied command to perform the > appropriate > action for every entry. > > > > > (1) :cdo s/\/ex_&/g | update > > > > In this case, the supplied substitute command replaces all the occurrences > of > cmdidx in the current line. > > > > > (2) :exec "cdo norm!iex_\:w\" > > > > In this case, the supplied replaces only the first occurrence of cmdidx. > This is > not a problem with the ":cdo" command. This is a problem with the user > supplied > command. > > > > > The (1) is processed all search pattern. > > But, The (2) is processed first search pattern in a row. > > > > This is the expected behavior as this is a problem with the user > supplied command. > > > > > ':cdo' is not necessary, When use only :substitute. > > > > When we use the ':cfdo' command such as ':cdo', Speed is also faster. > > > > :cfdo %s/\/ex_&/g | update > > > > So I propose to including patch only ':cfdo' and ':lfdo'. > > > > How do you think? > > > > No. In some cases the ":cdo/:ldo" commands are useful and in some > other cases ":cfdo/:lfdo" commands are useful. > > You are assuming that the ":cdo/:cfdo" commands will only be used > to perform substitutions and the results in the quickfix/location lists are > from a search command (e.g. vimgrep). This is not always the case. > You can populate the quickfix list with output from various tools > (e.g. cscope, tags, lid, global, build output, static analysis output, > etc.). > > Regards, > Yegappan > > >> > > >> > Case#1 > >> > How to reproduce: > >> > 1. cd to vim src dir. > >> > $ cd (Vim clone dir)/vim/src > >> > 2. Start Vim. (including this patch version Vim) > >> > $ vim -N -u NONE > >> > 3. Grep word "cmdidx" from source and header using vimgrep. > >> > :vimgrep "\" **/*.[ch] > >> > 4. Open quickfix window. > >> > :copen > >> > 5. Do :cdo command. (Intentionally forget the '| update') > >> >
Re: Patch to add the :cdo and :ldo commands
Using the same example as before, with this text: http://example.com http://example.org http://example.net http://example.com http://example.org http://example.net This time running the commands: :vimgrep /http\zs:/g % :cdo normal o That should create a new empty line after each match in the quickfix list. To my surprise this worked just fine, producing this output: http://example.com http://example.org http://example.net http://example.com http://example.org http://example.net [eof - three blank lines before end of file] I was expecting this to suffer from a similar problem as the previous example. This time it’s the line numbers (not column numbers) that would fall out of sync with the matches. But it doesn’t happen. Here’s the addresses in the quickfix list before running those commands: 1 col 5 2 col 5 3 col 5 4 col 5 4 col 24 4 col 43 After running the `:cdo normal o` command, the quickfix list contains these addresses: 1 col 5 3 col 5 5 col 5 7 col 5 7 col 24 7 col 43 This suggests that the quickfix list is somehow updated between edits that modify the number of lines in a file. Would it be possible to update the quickfix list could also between edits that modify the number of characters in a line? Drew On Sun, Jul 26, 2015 at 12:53 PM, Drew Neil wrote: > I agree with h_east that if you’re planning to run the :substitute command > across multiple files, it makes sense to use: > > :cfdo %s/pattern/replacement/g > > and not: > > :cdo s/pattern/replacement/g > > I can also see myself wanting to use the :cdo command in combination with > :normal for certain types of task. But I’ve come across another problem. > Suppose that we have a text file containing these four lines of text: > > http://example.com > http://example.org > http://example.net > http://example.com http://example.org http://example.net > > Now let’s say that we want to turn each occurrence of ‘http’ to ‘https’. > (We could use the :substitute command here, but let me use this to > demonstrate a problem with using :normal). We’ll use :vimgrep to populate > the quickfix list with 6 matches: > > :vimgrep /http\zs:/g % > > Then we’ll insert the ’s’ character in front of the colon with this > command: > > :cdo normal is > > The resulting text looks like this: > > https://example.com > https://example.org > https://example.net > https://example.com httsp://example.org htstp://example.net > > In the last line, we get ‘https’, then ‘httsp’, then ‘htstp’. Not ideal! > > The problem here is that the quickfix list records line and column > numbers. If characters are added or removed near the start of the line, the > column numbers for later matches on that line will no longer line up with > the match that created the original quickfix list entry. > > I’m not sure if this is a problem with the quickfix list, with :cdo, or > with :normal. > > Drew > > > > On Sat, Jul 25, 2015 at 6:22 PM, Yegappan Lakshmanan > wrote: > >> Hi, >> >> On Sat, Jul 25, 2015 at 9:55 AM, h_east wrote: >> > Hi Yegappan and Bram >> > >> > 2015-7-25(Sat) 12:27:56 UTC+9 yega...@gmail.com: >> >> >> Hi Hirohito, >> >> >> >> On Fri, Jul 24, 2015 at 3:42 PM, h_east wrote: >> >> > Hi Yegappan, Bram and List >> >> > >> >> >> >> > >> >> >> >> > Thanks for testing the patch. I will send out an updated patch >> in a few days. >> >> >> >> > Hopefully this time it will get included. This has been >> outstanding for more >> >> >> >> > than two years. >> >> >> >> > >> >> >> >> >> >> >> >> The updated patch (against vim 7.4.796) is attached. >> >> >> > >> >> >> > Thanks. So now it's ready to include, right? >> >> >> > >> >> >> >> >> >> Yes. Of course :-) >> >> > >> >> > I confirmed this patch. >> >> > >> >> > I found unexpected behaviors. >> >> > >> >> >> >> Thanks for testing the patch and sending the bug report. I am attaching >> >> an updated patch that fixes the two problems. Let me know if you see >> any >> >> issues with this attached patch. >> > >> > I confirmed that reported problem have been fixed. >> > Thank you for quickly fixes. >> > >> > I think it is better to discuss. >> >> > This is my opnion. >> >> > When the search pattern exists more in a row, I think :cdo/:ldo >> confuse to use. >> >> > and the processing time tends to be long. >> > >> > Do you understand that the results of the following two commands are >> different, >> > When the search pattern exists more in a row? >> > >> >> The ":cdo" command executes the supplied command for every valid entry >> in the quickfix list. It is upto the supplied command to perform the >> appropriate >> action for every entry. >> >> > >> > (1) :cdo s/\/ex_&/g | update >> > >> >> In this case, the supplied substitute command replaces all the >> occurrences of >> cmdidx in the current line. >> >> > >> > (2) :exec "cdo norm!iex_\:w\" >> > >> >> In this case, the supplied replaces
Re: [patch] fixed access to invalid memory when parsing :autocommand
Dominique Pellé wrote: > Asan (address sanitizer) detects use of invalid > memory with vim-7.4.796 on Linux x86_64 when doing: > > $ vim -u NONE -c 'au CursorHoldI ,~' > > = > ==31962== ERROR: AddressSanitizer: heap-buffer-overflow on address > 0x6062000168ff at pc 0x55c7fa bp 0x7ffd361811c0 sp 0x7ffd361811b8 > READ of size 1 at 0x6062000168ff thread T0 [...] > ==31962== ABORTING > > Attached patch fixes it. > Bug was found using afl-fuzz + asan. Thanks! -- Edison's greatest achievement came in 1879, when he invented the electric company. Edison's design was a brilliant adaptation of the simple electrical circuit: the electric company sends electricity through a wire to a customer, then immediately gets the electricity back through another wire /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[patch] fixed use of free memory in do_one_cmd(...) in ex_docmd.c
Hi Vim-7.4.797 uses free memory when doing: $ vim -u NONE -S crash.vim ... where crash.vim is the attached file. = ==4903==ERROR: AddressSanitizer: heap-use-after-free on address 0x60215490 at pc 0x528f70 bp 0x7ffddfc709a0 sp 0x7ffddfc70998 READ of size 1 at 0x60215490 thread T0 #0 0x528f6f in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2381 #1 0x523378 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:1133 #2 0x51d886 in do_source /home/pel/sb/vim/src/ex_cmds2.c:3353 #3 0x51c3d6 in cmd_source /home/pel/sb/vim/src/ex_cmds2.c:2962 #4 0x51c1ae in ex_source /home/pel/sb/vim/src/ex_cmds2.c:2935 #5 0x52af9f in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2940 #6 0x523378 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:1133 #7 0x521f5c in do_cmdline_cmd /home/pel/sb/vim/src/ex_docmd.c:738 #8 0x944237 in exe_commands /home/pel/sb/vim/src/main.c:2926 #9 0x93db0d in main /home/pel/sb/vim/src/main.c:961 #10 0x7fa872e1eec4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4) #11 0x40ea18 (/home/pel/sb/vim/src/vim+0x40ea18) 0x60215490 is located 0 bytes inside of 2-byte region [0x60215490,0x60215492) freed by thread T0 here: #0 0x7fa875bef5c7 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x545c7) #1 0x666c79 in vim_free /home/pel/sb/vim/src/misc2.c:1707 #2 0x528ed6 in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2367 #3 0x523378 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:1133 #4 0x51d886 in do_source /home/pel/sb/vim/src/ex_cmds2.c:3353 #5 0x51c3d6 in cmd_source /home/pel/sb/vim/src/ex_cmds2.c:2962 #6 0x51c1ae in ex_source /home/pel/sb/vim/src/ex_cmds2.c:2935 #7 0x52af9f in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2940 #8 0x523378 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:1133 #9 0x521f5c in do_cmdline_cmd /home/pel/sb/vim/src/ex_docmd.c:738 #10 0x944237 in exe_commands /home/pel/sb/vim/src/main.c:2926 #11 0x93db0d in main /home/pel/sb/vim/src/main.c:961 #12 0x7fa872e1eec4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4) previously allocated by thread T0 here: #0 0x7fa875bef7df in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x547df) #1 0x66442c in lalloc /home/pel/sb/vim/src/misc2.c:921 #2 0x664210 in alloc /home/pel/sb/vim/src/misc2.c:820 #3 0x664ded in vim_strnsave /home/pel/sb/vim/src/misc2.c:1265 #4 0x528e94 in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2365 #5 0x523378 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:1133 #6 0x51d886 in do_source /home/pel/sb/vim/src/ex_cmds2.c:3353 #7 0x51c3d6 in cmd_source /home/pel/sb/vim/src/ex_cmds2.c:2962 #8 0x51c1ae in ex_source /home/pel/sb/vim/src/ex_cmds2.c:2935 #9 0x52af9f in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2940 #10 0x523378 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:1133 #11 0x521f5c in do_cmdline_cmd /home/pel/sb/vim/src/ex_docmd.c:738 #12 0x944237 in exe_commands /home/pel/sb/vim/src/main.c:2926 #13 0x93db0d in main /home/pel/sb/vim/src/main.c:961 #14 0x7fa872e1eec4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4) SUMMARY: AddressSanitizer: heap-use-after-free /home/pel/sb/vim/src/ex_docmd.c:2381 do_one_cmd Shadow bytes around the buggy address: 0x0c047fffaa40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffaa50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffaa60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffaa70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffaa80: fa fa fa fa fa fa fa fa fa fa fd fa fa fa fd fa =>0x0c047fffaa90: fa fa[fd]fa fa fa 00 02 fa fa 07 fa fa fa fd fa 0x0c047fffaaa0: fa fa 05 fa fa fa 00 02 fa fa 07 fa fa fa fd fa 0x0c047fffaab0: fa fa 05 fa fa fa 00 02 fa fa 07 fa fa fa fd fa 0x0c047fffaac0: fa fa 05 fa fa fa 00 02 fa fa 07 fa fa fa fd fa 0x0c047fffaad0: fa fa 05 fa fa fa 00 02 fa fa 07 fa fa fa fd fa 0x0c047fffaae0: fa fa 05 fa fa fa 00 02 fa fa 07 fa fa fa fd fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Contiguous container OOB:fc ASan internal: fe ==4903==ABORTING Attached patch fixes it. Bug was found using afl-fuzz + asan on Linux x86_64. Regards Dominique -- -- 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 mes
Re: [patch] fixed use of free memory in do_one_cmd(...) in ex_docmd.c
Dominique Pellé wrote: > > Vim-7.4.797 uses free memory when doing: > > $ vim -u NONE -S crash.vim > > ... where crash.vim is the attached file. > > = > ==4903==ERROR: AddressSanitizer: heap-use-after-free on address > 0x60215490 at pc 0x528f70 bp 0x7ffddfc709a0 sp 0x7ffddfc70998 > READ of size 1 at 0x60215490 thread T0 > #0 0x528f6f in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2381 > #1 0x523378 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:1133 > #2 0x51d886 in do_source /home/pel/sb/vim/src/ex_cmds2.c:3353 > #3 0x51c3d6 in cmd_source /home/pel/sb/vim/src/ex_cmds2.c:2962 > #4 0x51c1ae in ex_source /home/pel/sb/vim/src/ex_cmds2.c:2935 > #5 0x52af9f in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2940 > #6 0x523378 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:1133 > #7 0x521f5c in do_cmdline_cmd /home/pel/sb/vim/src/ex_docmd.c:738 > #8 0x944237 in exe_commands /home/pel/sb/vim/src/main.c:2926 > #9 0x93db0d in main /home/pel/sb/vim/src/main.c:961 > #10 0x7fa872e1eec4 in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4) > #11 0x40ea18 (/home/pel/sb/vim/src/vim+0x40ea18) > > 0x60215490 is located 0 bytes inside of 2-byte region > [0x60215490,0x60215492) > freed by thread T0 here: > #0 0x7fa875bef5c7 in __interceptor_free > (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x545c7) > #1 0x666c79 in vim_free /home/pel/sb/vim/src/misc2.c:1707 > #2 0x528ed6 in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2367 > #3 0x523378 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:1133 > #4 0x51d886 in do_source /home/pel/sb/vim/src/ex_cmds2.c:3353 > #5 0x51c3d6 in cmd_source /home/pel/sb/vim/src/ex_cmds2.c:2962 > #6 0x51c1ae in ex_source /home/pel/sb/vim/src/ex_cmds2.c:2935 > #7 0x52af9f in do_one_cmd /home/pel/sb/vim/src/ex_docmd.c:2940 > #8 0x523378 in do_cmdline /home/pel/sb/vim/src/ex_docmd.c:1133 > #9 0x521f5c in do_cmdline_cmd /home/pel/sb/vim/src/ex_docmd.c:738 > #10 0x944237 in exe_commands /home/pel/sb/vim/src/main.c:2926 > #11 0x93db0d in main /home/pel/sb/vim/src/main.c:961 > #12 0x7fa872e1eec4 in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4) [...] > Attached patch fixes it. > Bug was found using afl-fuzz + asan on Linux x86_64. Thanks! -- GOD: That is your purpose Arthur ... the Quest for the Holy Grail ... "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch to add the :cdo and :ldo commands
Hi, On Sun, Jul 26, 2015 at 4:53 AM, Drew Neil wrote: > I agree with h_east that if you’re planning to run the :substitute command > across multiple files, it makes sense to use: > > :cfdo %s/pattern/replacement/g > > and not: > > :cdo s/pattern/replacement/g > Depending on the task, you can use either the ":cdo" or the ":cfdo" commands. If you want to perform text search/replace across all the files in the quickfix list, then the ":cfdo" command with ":%s/.../g" is the correct option (as it is more optimal). This is similar to using the "g" argument to the ":substitute" command to replace all the matching text in a single line. And using the "%" range to replace text in all the lines. If you want to replace multiple matching text across all the lines in a file, then you have to pass both "%" and "g". If you don't, then the text will not be correctly replaced. This is not a problem with the ":substitute" command. > > I can also see myself wanting to use the :cdo command in combination with > :normal for certain types of task. But I’ve come across another problem. > Suppose that we have a text file containing these four lines of text: > > http://example.com > http://example.org > http://example.net > http://example.com http://example.org http://example.net > > Now let’s say that we want to turn each occurrence of ‘http’ to ‘https’. (We > could use the :substitute command here, but let me use this to demonstrate a > problem with using :normal). We’ll use :vimgrep to populate the quickfix > list with 6 matches: > > :vimgrep /http\zs:/g % > > Then we’ll insert the ’s’ character in front of the colon with this command: > > :cdo normal is > > The resulting text looks like this: > > https://example.com > https://example.org > https://example.net > https://example.com httsp://example.org htstp://example.net > > In the last line, we get ‘https’, then ‘httsp’, then ‘htstp’. Not ideal! > > The problem here is that the quickfix list records line and column numbers. > If characters are added or removed near the start of the line, the column > numbers for later matches on that line will no longer line up with the match > that created the original quickfix list entry. > > I’m not sure if this is a problem with the quickfix list, with :cdo, or with > :normal. > This is a problem with the quickfix list functionality. Currently when a line is added or removed, then the line numbers in the quickfix list entries are updated. But when a line is modified, the column numbers in the quickfix list entries are not updated. Refer to the qf_mark_adjust() function. In the above example, you should use ":s/../g" instead of the ":normal" command. Regards, Yegappan > > On Sat, Jul 25, 2015 at 6:22 PM, Yegappan Lakshmanan > wrote: >> >> Hi, >> >> On Sat, Jul 25, 2015 at 9:55 AM, h_east wrote: >> > Hi Yegappan and Bram >> > >> > 2015-7-25(Sat) 12:27:56 UTC+9 yega...@gmail.com: >> >> >> Hi Hirohito, >> >> >> >> On Fri, Jul 24, 2015 at 3:42 PM, h_east wrote: >> >> > Hi Yegappan, Bram and List >> >> > >> >> >> >> > >> >> >> >> > Thanks for testing the patch. I will send out an updated patch >> >> >> >> > in a few days. >> >> >> >> > Hopefully this time it will get included. This has been >> >> >> >> > outstanding for more >> >> >> >> > than two years. >> >> >> >> > >> >> >> >> >> >> >> >> The updated patch (against vim 7.4.796) is attached. >> >> >> > >> >> >> > Thanks. So now it's ready to include, right? >> >> >> > >> >> >> >> >> >> Yes. Of course :-) >> >> > >> >> > I confirmed this patch. >> >> > >> >> > I found unexpected behaviors. >> >> > >> >> >> >> Thanks for testing the patch and sending the bug report. I am attaching >> >> an updated patch that fixes the two problems. Let me know if you see >> >> any >> >> issues with this attached patch. >> > >> > I confirmed that reported problem have been fixed. >> > Thank you for quickly fixes. >> > >> > I think it is better to discuss. >> >> > This is my opnion. >> >> > When the search pattern exists more in a row, I think :cdo/:ldo >> >> > confuse to use. >> >> > and the processing time tends to be long. >> > >> > Do you understand that the results of the following two commands are >> > different, >> > When the search pattern exists more in a row? >> > >> >> The ":cdo" command executes the supplied command for every valid entry >> in the quickfix list. It is upto the supplied command to perform the >> appropriate >> action for every entry. >> >> > >> > (1) :cdo s/\/ex_&/g | update >> > >> >> In this case, the supplied substitute command replaces all the occurrences >> of >> cmdidx in the current line. >> >> > >> > (2) :exec "cdo norm!iex_\:w\" >> > >> >> In this case, the supplied replaces only the first occurrence of cmdidx. >> This is >> not a problem with the ":cdo" command. This is a problem with the user >> supplied >> command. >> >> > >> > The (1) is processed all search pattern. >> > But, The (2) is processed first search pat
Re: Patch to add the :cdo and :ldo commands
Hi, On Sun, Jul 26, 2015 at 5:06 AM, Drew Neil wrote: > Using the same example as before, with this text: > > http://example.com > http://example.org > http://example.net > http://example.com http://example.org http://example.net > > This time running the commands: > > :vimgrep /http\zs:/g % > :cdo normal o > > That should create a new empty line after each match in the quickfix list. > To my surprise this worked just fine, producing this output: > > http://example.com > > http://example.org > > http://example.net > > http://example.com http://example.org http://example.net > > > > [eof - three blank lines before end of file] > > I was expecting this to suffer from a similar problem as the previous > example. This time it’s the line numbers (not column numbers) that would > fall out of sync with the matches. But it doesn’t happen. Here’s the > addresses in the quickfix list before running those commands: > > 1 col 5 > 2 col 5 > 3 col 5 > 4 col 5 > 4 col 24 > 4 col 43 > > After running the `:cdo normal o` command, the quickfix list contains these > addresses: > > 1 col 5 > 3 col 5 > 5 col 5 > 7 col 5 > 7 col 24 > 7 col 43 > > This suggests that the quickfix list is somehow updated between edits that > modify the number of lines in a file. Would it be possible to update the > quickfix list could also between edits that modify the number of characters > in a line? > As I mentioned in my previous e-mail, the qf_mark_adjust() function is used to adjust the line numbers in the quickfix list whenever a line is added or removed from a file. But when a line is modified, the column numbers in the quickfix list are not currently updated. This is a bug in the quickfix functionality and needs to be fixed. - Yegappan -- -- 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.
Another Unicode symbol shows with wrong width: U+0A02 GURMUKHI SIGN BINDI
I encountered this character which first shows as 2 black boxes, then it disappears completely when cursor is over it, then it again shows as 2 black boxes. Might be again a bug in terminal interpreter, but this symbol has a very low, 16-bit code point value. So I decided to report it here. vim-7.4.778 konsole from kde4 -- -- 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. -->ਂ<--
Core Dump When Decrementing Visual Block
Hi, all. When attempting to decrement non-numerical characters selected via visual block, vim crashes: https://nosuckdotorg.files.wordpress.com/2015/07/vim-decrement-crash.gif Otherwise, vim is a perfect piece of bug-free software--so don't touch a thing. Thanks and take care. Grady -- -- 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.
Re: Core Dump When Decrementing Visual Block
Hi Grady! 2015-7-27(Mon) 11:58:45 UTC+9 Grady Martin: > Hi, all. When attempting to decrement non-numerical characters selected via > visual block, vim crashes: > > https://nosuckdotorg.files.wordpress.com/2015/07/vim-decrement-crash.gif > > Otherwise, vim is a perfect piece of bug-free software--so don't touch a > thing. Thanks and take care. > > This problem fixed by Vim 7.4.782. See the following thread. https://groups.google.com/d/msg/vim_dev/QCfASVc0Qds/JWzCe9twPzwJ Thanks. -- Best regards, Hirohito Higashi (a.k.a h_east) -- -- 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.
