Hi all, Bringing this topic back.... :)
On Apr 14, 11:35 pm, [EMAIL PROTECTED] wrote: > > > However, I do am interested in something able to understand C++ > > > constructs in order to built even more powerful code > > > transformations and generations. > > > As such, this GSOC project may initiate the development of the API > > > I'm missing. > > > Hence I'm looking forward to it. Would you be so kind to disclose what API you are looking for? Really curious to know. Just found that you've already made some scripts doing background compilation... So you've beated my thread proposal. (I refered to your BuildToolsWrapper plug-ins.) (And BTW, I also found that the imaps.vim plug-in in the LaTeX-suite is due to you~ I like it very much. Really appreciate it.) Now I also admits it's not that useful to make a "thread" for doing this. But to make the background execution looks "automatic", maybe we can add some time-driven events to the autocmd mechanism? It looks that there are no this kind of events by far. > My main concern is more that ctags itself is not a very good solution -- for > parsing C++ files. A good solution will need to see the current buffer (we are > back to your "thread" proposal), and do a lot of work to really understand the > code. To let the syntax checker see the buffer, I think the solution can only be making copies of related files.... The Flymake plug-in for Emacs, as already referred to in the first post, seems to be running some reasonable heuristics on finding the related files. But I think we can use something like "gcc -MM files" to find the dependencies for the currently opened files in the buffers. We restrict our scope to these files, and put all of them into a temp directory to do the check. This method looks a bit more efficient than doing heuristical brute force search around the current dir, but it would miss the errors in the files depending on current files but not opened. Or we should still do some heuristics to make up for this? Back to the "core" problem, of choosing the syntax checker. As far as I can see, no matter a new syntax parser, or something better than ctags, or even an incremental compiler, it should be in a separate project. I did some research and found that the efficiency of Eclipse's OTF syntax checking is mainly because of the incremental compiler (ecj) they have. (Can ecj do incremental compiling in the stand-alone version? I'm not sure, as I don't know much about java... ) If we are indeed deciding an incremental compiler of C/C++, one of the problem for Vim is how to give the "delta" of the current file every time an incremental compile instruction is issued. If we really need an incremental compiler, I have a crazy idea to simulate incremental effect using a batch compiler, but don't know whether it works... Take C for example. In C the functions are highly localized, and the idea is to put each function in a separate file, including the same set of declaration, and compile only the modified functions. On the first time the compiler receives a source file, it "slices" the code into many localized pieces (e.g. functions) and put them into separate files, and create specific makefiles to manage the pieces. When a "delta" arrives, we just update the corresponding pieces, and run (g)make to update the necessary parts, avoiding looking at the unchanged parts. Again it just "sounds" better, but I'm not sure whether this would incur a lot of overhead by creating such a lot of files... I still don't know how dynamic marking up and preview window in Vim works... (really ashamed) But I probably won't have time to look at them before next Monday, as it is the end of the semester now and so many deadlines are in the way... Any suggestions on these ideas are welcomed. Even if I would miss GSoC, I still want to say something about these ideas. Regards, Lin --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
