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 <[email protected]>
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 <[email protected]>
> wrote:
>
>> Hi,
>>
>> On Sat, Jul 25, 2015 at 9:55 AM, h_east <[email protected]> wrote:
>> > Hi Yegappan and Bram
>> >
>> > 2015-7-25(Sat) 12:27:56 UTC+9 [email protected]:
>>
>> >> 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/\<cmdidx\>/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_\<Esc>:w\<CR>"
>> >
>>
>> 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/\<cmdidx\>/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 "\<cmdidx\>" **/*.[ch]
>> >> > 4. Open quickfix window.
>> >> > :copen
>> >> > 5. Do :cdo command. (Intentionally forget the '| update')
>> >> > :cdo s/\<cmdidx\>/ex_&/g
>> >> >
>> >> > Expect behavior:
>> >> > - E37 occurs once.
>> >> >
>> >> > Actual behavior:
>> >> > - E37 occurs continuously.
>> >> >
>> >> >
>> >> > --------
>> >> > Case#2
>> >> > How to reproduce:
>> >> > 1~4. (Same abobe.)
>> >> > 5. Do :cdo command. (Intentionally forget the ":w\<CR>")
>> >> > :exec "cdo norm!iex_\<Esc>"
>> >> >
>> >> > Expect behavior:
>> >> > - E37 occurs once.
>> >> >
>> >> > Actual behavior:
>> >> > - E37 occurs continuously.
>> >> >
>> >> > And, When press Ctrl-C after the '-- More --' display, buffer.c
>> was modified unexpectedly.
>> >> >
>> >> > [original buffer.c:4901]
>> >> > if (eap->cmdidx == CMD_unhide || eap->cmdidx == CMD_sunhide)
>> >> >
>> >> > [modified buffer.c:4901]
>> >> > if
>> (eap->exexexexexexexexexexexexexexexexexexexexexexexex___________________
>> >> > _____cmdidx == CMD_unhide || eap->cmdidx == CMD_sunhide)
>> >> >
>> >> >
>> >> > --------
>> >> > 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.
>>
>> --
>> --
>> 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 a topic in the
>> Google Groups "vim_dev" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/vim_dev/dfyt-G6SMec/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
--
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.