Hello, Lin <[EMAIL PROTECTED]> wrote: > > > > 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.
Anything that does understand C++ and helps me (or anybody that have more time than I do) to implement some real refactoring solutions. For instance, when we change the signature of a function, we need to change all the calls to that function. In C, there can be only one function with a given name, a grep is enough. Identifying the calls in C++ in more tricky because functions can be overloaded. So far, I've started to implement a few functions that analyse functions signature, extract current scope, ... Even if these functions perform their job quite well, I don't see them as definitive. I'm in the expectation that some day I could ask these information to an external program dedicated to the task. I'm currently implementing a :Override command for my C++ suite. To work correctly, I have to parse ctags results in order to look the override-able functions in a given classes hierarchy. (hierarchy that I must visit in a given order -- which makes me implement a topological sort in VimL...) > 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.) This is only a partial solution: my implementation does not work under Windows, and perl is required. Moreover BuildToolsWrapper initial purpose is quite different. The current version is nothing more than a beta. I still want to plug "compiler plugins" as "compiler filters" on the fly, support filters that highlight the quickfix windows, some that define folding, etc. > (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.) Absolutly not -- I don't even use it :P. The history is a little more complex. I've enhanced Stephen Riehm's initial bracketing system, Gergely Kontra suggested me to use the select mode. That gave birth the placeholders behaviour known today. Then Gergely used a simplified version in mu-template. Then Srinath re-enhanced mu-template's simplified placeholder system. imaps' placeholder system and mine are quite equivalent in terms of features and options, but maintained apart from each other. ------------------------------------------------------ [...] > To let the syntax checker see the buffer, I think the solution can > only be making copies of related files.... Beware of non saved buffers. I often have several modified buffers when I'm refactoring my code. > 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? Parsing only the opened buffers is already an heuristic. Then all depends on the tool that takes care of the analysis: what does it cache? > 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. I also think it should be an external project, for several reasons: - each language requires it own parser - some languages may have several tools that could help. > [...] > Any suggestions on these ideas are welcomed. Even if I would miss > GSoC, I still want to say something about these ideas. I can't help much. Compiling theory is something I don't remember much about. However, I remember several blogging entries about the next code analyser/... Microsoft-VS team is working on. I think you could find interesting information there. -- Luc Hermitte http://lh-vim.googlecode.com/ http://hermitte.free.fr/vim/ --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
