Re: Emacs contributions, C and Lisp

[David Kastrup]

Dmitry Gutov <address@hidden> writes:

> On 24.02.2014 19:33, Richard Stallman wrote:
>> The lookup and completion features that people want can be implemented
>> by making GCC answer questions sent to it, as Aspell does for M-$.
>> That change would be welcome.  I think it could be implemented using
>> GCC's existing plug-in mechanism, but it would be better to put
>> the code into GCC itself.
>
> Could it support a "daemon" mode?
>
> The current situation in Clang is, its executable only supports the
> simplest mode of operation: one process call per completion. This way,
> it has to parse all relevant files (headers, etc) each time completion
> is requested.

That leaves something to be desired.

> But the completion information is available via libclang, and there
> are a few projects that build on it to spin up a persistent server,
> which only processes different files anew when they've changed since
> the last time (or at least that's the intention). These projects also
> support different build systems and extract the necessary dependency
> information, include paths, etc.
>
> I don't really see GCC itself doing that (at least, the last part).
> It would require quite a bit of work that might be better left to
> third-party developers.

The one thing that the basic approach "output the annotated parse tree"
or whatever other cooked summary output via plugin or whatever else has
over "stay resident after compilation and answer queries" is that a
daemon in a separate process that will first read the respective data
and then answer queries about it allows the actual parser process to
terminate and shed all the memory and temporary data and parsing tables
it needed for arriving at the parse tree.

That means that the part staying resident and answering queries will not
have its memory fragmented by lots of stuff that is no longer needed.

The "cooked summary" could include a list of processed source files so
that the daemon can reexec the parser and possibly itself whenever it
finds that a file changed between queries.

So a process and program boundary seems to make a lot of sense.  Whether
the data between processes/programs is passed via file/pipe/shared
memory is a different consideration.

-- 
David Kastrup