Hi, On Fri, Jul 21, 2017 at 3:13 AM, LCD 47 <[email protected]> wrote: > On 20 July 2017, Yegappan Lakshmanan <[email protected]> wrote: >> Hi, >> >> On Thu, Jul 20, 2017 at 6:59 AM, Yegappan Lakshmanan >> <[email protected]> wrote: >> > Hi, >> > >> > I am investigating a memory leak reported by valgrind with this >> > patch. >> > >> >> I am attaching an updated patch with the fix for this memory leak and >> additional tests. >> >> Once this patch is incorporated, output can be parsed using >> 'errorformat' and resulting entries can be added to any >> quickfix/location list by using setqflist(). > > Sadly, this still won't allow one to parse errors with errorformat > to a list in memory, disconnected from the stack. > > You see, the problem with the stack is that in order to use it in > a plugin beyond basic lolder / lnewer navigation, you need to assume > your plugin is the only one manipulating said stack. If another plugin > comes into picture and you try to accomodate it, it immediately becomes > an uphill battle. There is no way to keep track which loclist belong > to which plugin, and there is basically no way to tell the state of the > stack. >
A plugin can associate a context with a quickfix/location list and also save the quickfix/location list number. By checking the context, the plugin can make sure that it is updating the correct list. Of course, this will work only if all the plugins start using/checking the context information before updating the quickfix list. > > The other plugin can add or remove entries, and there is no way > for you to detect that. You could look at the number of elements, but > once the stack gets full that number becomes useless. You could hook > to autocmds, but quickfix commands can be run silent. You could keep > track of the stack pointer, but the other plugin can play tricks with > the stack pointer too. In fact I'd be very curious to see a plugin do > something useful with the quickfix / loclist stack without asserting > exclusive ownership to it. As it is, it's simply too user-hostile. > > Ok, I'll crawl under my rock now, this is likely to be my last > message on this topic. > The current quickfix implementation is heavily tied to managing a list in the quickfix stack. I am incrementally making changes to unwind some of these dependencies and cleaning up the code. The support for creating and managing a quickfix list in memory is coming. - 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
