I would like to hear the gcc developers weigh in on whether such a tool (namely a variant invocation of gcc running through all of its lexing, parsing and semantic analysis) could ever be made to operate at speeds that would make gcc-based completion tolerable. And if not then in what way could the gcc codebase be leverage to support realistic completion? This goes to a crucial part of the discussion that I feel RMS fails to acknowlege. Namely that clang is not a compiler frontend per se but a set of performance-focused components targeted at building C++-aware (often interactive) tools. clang-based completion is not an invocation of a compiler built by grafting clang onto llvm but rather communication with a caching server built using clang components. We have existence proof that one can use clang libraries to build a C++ compiler competing with gcc. I wonder how realistic it is to expect gcc to be turned into components enabling construction of tools similar to those using clang: http://clang.llvm.org/doxygen/classclang_1_1tooling_1_1RefactoringTool.html http://clang-analyzer.llvm.org/ https://code.google.com/p/include-what-you-use/ To what extent does the "do not offer interfaces that might enable repurposing of gcc code for non-free projects" make it unlikely that such components might ever emerge? /john On Thu, Feb 20, 2014 at 3:51 PM, Dmitry Gutov wrote: > David Kastrup writes: > > > I think it would make sense to pass that info via pipe or socket and > > receive the output similarly. That way each file only needs to get > > parsed once, not repeatedly for every completion. > > Isn't this what I wrote in the next paragraph, after the one you quoted? > > I don't see how you would parse the file only once, though. The user > types a new word -> you have to parse it again, no? > >