From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Wed, 26 Feb 2014 12:27:16 +0100 Organization: Organization?!? Message-ID: <8738j66rmz.fsf@fencepost.gnu.org> References: <83txc1bl83.fsf@gnu.org> <5300189A.9090208@yandex.ru> <83wqgv9fbj.fsf@gnu.org> <20140216180712.236069f6@forcix.jorgenschaefer.de> <87wqgr4v18.fsf@yandex.ru> <53064BD0.7070009@yandex.ru> <87ha7tr5bo.fsf@fencepost.gnu.org> <87ppmhecd8.fsf@yandex.ru> <87y50z90pd.fsf@fencepost.gnu.org> <87txbn8r6x.fsf@fencepost.gnu.org> <87r46qtn8b.fsf@uwakimon.sk.tsukuba.ac.jp> <87eh2q74b4.fsf@fencepost.gnu.org> <87lhwytabr.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1393414056 32458 80.91.229.3 (26 Feb 2014 11:27:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Feb 2014 11:27:36 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 26 12:27:45 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WIceP-0005kt-A8 for ged-emacs-devel@m.gmane.org; Wed, 26 Feb 2014 12:27:45 +0100 Original-Received: from localhost ([::1]:39624 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIceO-0006Sf-S8 for ged-emacs-devel@m.gmane.org; Wed, 26 Feb 2014 06:27:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53286) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIceH-0006SU-C3 for emacs-devel@gnu.org; Wed, 26 Feb 2014 06:27:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIceC-0006qO-3f for emacs-devel@gnu.org; Wed, 26 Feb 2014 06:27:37 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:59915) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIceB-0006qH-QA for emacs-devel@gnu.org; Wed, 26 Feb 2014 06:27:32 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WIce9-0004aw-MG for emacs-devel@gnu.org; Wed, 26 Feb 2014 12:27:29 +0100 Original-Received: from x2f4afcd.dyn.telefonica.de ([2.244.175.205]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 Feb 2014 12:27:29 +0100 Original-Received: from dak by x2f4afcd.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 Feb 2014 12:27:29 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 94 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: x2f4afcd.dyn.telefonica.de X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:dxA5d2QasAoIxtbQP6Bro2lI1nU= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:169882 Archived-At: "Stephen J. Turnbull" writes: > David Kastrup writes: > > "Stephen J. Turnbull" writes: > > > David Kastrup writes: > > > > > 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, > > > > Nice try, but I don't think you can deprecate the value of the > > > information GCC is not allowed to emit that easily. > > > > Emacs's treatment should depend on types and usage [...] > > > Most of your reply has already been addressed in the parts you did not > > quote. > > OK. I guess what you are arguing is that you can throw away the tree > and keep only the local annotations. All I'm saying is that you need > those local annotations, and you need "position in program" > information. Really, I addressed this _exhaustively_ in . I could basically quote the entire message in reply to your "guess what I am arguing" but it seems to make awfully little sense. So perhaps try answering the whole message rather than picking a half-paragraph and blocking the rest out. > However, a conventional xref table is not going to be enough because > you need the scope (which is required to restrict the list of > completions). See above. > Even if your xref table provides enough information to determine > scopes properly, you'll end up rebuilding something very close to a > syntax tree to associate those scopes with each potential use of an > identifier (and thus the most accurate list of potential completions > at each point in the buffer). See above. > IOW, my point is not really that you can't throw away the annotations; > it's that you don't want to throw away either the syntax tree or the > annotations. We already saw where the "I want it all, and now" leads us. In particular since "all" is rather ill-defined and very likely tied into a particular internal representation/focus of GCC. I repeat (now indeed quoting from the mail you "answered" previously): 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. > OTOH, it will be interesting to see if the Ada -fdump-xref feature is > actually good enough to handle the insanity of C++ without a full > syntax-tree. I have no idea. But a full syntax tree is not required. I repeat: [...] 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. An efficient and compact representation might make use of typical scoping structures, like Git's archives rely on "delta chain compression" designed to make use of typical history dependencies without actually delivering any actually useful relation information. You want the data structure for answering the "meaning of x at source location y" question make good use of the typical correlation of identifier sets between source location y and source location y+dy. But that does not mean that digging through the whole syntax tree is going to be what you want. That's more likely than not too inefficient to be fun. At any rate, this is hypothetical, while it would appear that -fdump-xref isn't. There seems to be little point in fighting a lot over it without actually looking what -fdump-xref actually does. -- David Kastrup