[Top][All Lists]

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

Re: Emacs contributions, C and Lisp

From: David Kastrup
Subject: Re: Emacs contributions, C and Lisp
Date: Tue, 25 Feb 2014 10:41:42 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

David Kastrup <address@hidden> writes:

> Glenn Morris <address@hidden> writes:
>> John Yates wrote:
>>> I would like to hear the gcc developers weigh in [...]
>> They probably would do, if this discussion were happening on a gcc
>> mailing list.
> Good thing that it isn't, then.  A discussion as opposed to a fist
> fight is something where there is a chance of people leaving with a
> different opinion than what they started with.

To followup on myself: smart completion is a concrete actual application
for Emacs within the GNU universe so this discussion is less likely to
get lost in an abstract showdown.

It's definitely an issue that can be solved using special-casing.  It's
non-trivial enough to discuss its implications concretely.

In this particular case, the "annotated syntax tree" question in
particular is mostly uninteresting since we are talking about
characterizing identifiers.  It is "mostly" uninteresting since the
resolution of an identifier depends on scopes, so the basic question
that likely needs solving is "given the following source location and
the following identifier, what data structures and definitions does it
refer to".  Resolving identifiers based on source location efficiently
will require suitable data structures, and any daemon answering
questions accordingly will have to get raw data for building them.

Accessing that raw data and preparing a dump suitable for turning into a
data structure for such a daemon would seem like an obvious case for a
GCC plugin.  So we are getting more at something like "source location
dependent data structure dump" here.

The "annotated syntax tree" question would become more relevant for
things like sourcecode highlighting.  But in the interest of usefully
fast feedback when editing, it would likely make more sense to let Emacs
do the highlighting with local rules on its own and only converse with
GCC when it becomes necessary to resolve ambiguities (like
declaration/expression distinctions): GCC can only make helpful
suggestions regarding the last time the source code was syntactically
correct, so most of the time Emacs will need to go ahead with _some_
idea anyway.

At any rate, figuring out from the angle of Emacs and completion what
would be required from GCC will provide us with a better idea about the
balance of utility for us and possible proprietary systems trying to
make use of the same code or data.

David Kastrup

reply via email to

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