Yegappan wrote: > When one plugin is asynchronously updating a quickfix list, currently it > is not possible for another plugin to update another quickfix list > synchronously or asynchronously using the cexpr, cfile, and other > commands. The setqflist() function can update any quickfix list in the > stack. But this function currently doesn't support parsing output using > 'errorformat'. > > For example, let us say one plugin asynchronously updates the quickfix > list with a build tool output. Now if the user runs a query command to > create and update another quickfix list, then both the plugins will end > up updating the same quickfix list. > > This is because the commands like cexpr, cfile, etc. use the > qf_init_ext() function to parse the output and add entries to the > quickfix list. The qf_init_ext() function supports updating only the > last quickfix list. > > This problem can be solved by changing the qf_init_ext() function to > operate on any quickfix list in the stack. But this function currently > saves state information across multiple invocations to support > directory/file stack and multi-line error output. This state information > is stored in qf_info_S (entire quickfix stack) instead of qf_list_T (per > list). This state information needs to be stored per quickfix list by > moving to qf_list_T. Does anyone see any issues with this or any other > suggestions?
Yes, that makes sense. The commands were created when it was all done manually, or using a mapping or plugin. Then it made sense to only change the current quickfix list, the others were just for history. Now it's possible to have several quickfix lists that are "current". Instead of adding an argument to commands like :caddexpr, it might be better to create a function for this. It will be mostly used by plugins, which would need to use :exe and take care of escaping to form a command. With a function it's much easier to use. -- >From "know your smileys": :-E Has major dental problems /// 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.
