[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs contributions, C and Lisp

From: John Yates
Subject: Re: Emacs contributions, C and Lisp
Date: Thu, 20 Feb 2014 18:12:53 -0500

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:


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?


On Thu, Feb 20, 2014 at 3:51 PM, Dmitry Gutov <address@hidden> wrote:
David Kastrup <address@hidden> 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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]