From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Tue, 27 Oct 2015 19:58:08 +0200 Message-ID: <83lhao42j3.fsf@gnu.org> References: <5612E996.7090700@yandex.ru> <83bnc7tavr.fsf@gnu.org> <5618C92A.3040207@yandex.ru> <83a8rrt9ag.fsf@gnu.org> <5618D376.1080700@yandex.ru> <831td3t62e.fsf@gnu.org> <561A6199.1020901@cumego.com> <561B9D87.70504@yandex.ru> <87vb9wcpw9.fsf@esperi.org.uk> <83eggkwdgh.fsf@gnu.org> <562BB9C0.4070600@yandex.ru> <834mhgw5ry.fsf@gnu.org> <562BBC9F.9020806@yandex.ru> <8337x0w5dm.fsf@gnu.org> <562BCAB6.7000206@yandex.ru> <83y4esum70.fsf@gnu.org> <871tcgzppn.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1445968789 14077 80.91.229.3 (27 Oct 2015 17:59:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 27 Oct 2015 17:59:49 +0000 (UTC) Cc: adatgyujto@gmail.com, esperanto@cumego.com, emacs-devel@gnu.org, nix@esperi.org.uk, dgutov@yandex.ru, drew.adams@oracle.com To: Oleh Krehel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 27 18:59:39 2015 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 1Zr8X1-0006ia-UO for ged-emacs-devel@m.gmane.org; Tue, 27 Oct 2015 18:59:36 +0100 Original-Received: from localhost ([::1]:33380 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zr8X1-0008LM-6H for ged-emacs-devel@m.gmane.org; Tue, 27 Oct 2015 13:59:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41853) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zr8WR-0008H3-3h for emacs-devel@gnu.org; Tue, 27 Oct 2015 13:59:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zr8Vh-0000on-F1 for emacs-devel@gnu.org; Tue, 27 Oct 2015 13:58:58 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:32776) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zr8Vh-0000nA-44 for emacs-devel@gnu.org; Tue, 27 Oct 2015 13:58:13 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NWW000004FMBB00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Tue, 27 Oct 2015 19:57:55 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWW000H14KI7M20@a-mtaout20.012.net.il>; Tue, 27 Oct 2015 19:57:55 +0200 (IST) In-reply-to: <871tcgzppn.fsf@gmail.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:192741 Archived-At: > From: Oleh Krehel > Cc: Dmitry Gutov , nix@esperi.org.uk, esperanto@cumego.com, adatgyujto@gmail.com, drew.adams@oracle.com, emacs-devel@gnu.org > Date: Tue, 27 Oct 2015 09:21:40 +0100 > > >> > Once again, the issue is not the format of the database. That's > >> > immaterial. > >> > >> Database format can have a real performance impact. > > > > Yes, but the issue is performance, not the database format. > > If I understood correctly what you mean by the database format, it > matters to me. The TAGS files are too simplistic, they don't understand > the language, either C and especially C++. On the other hand, have a > look that these Semantic tags entries for e.g. etags.c: > > ("regex.h" include (:system-flag t) nil [4626 4644]) > ("CTAGS" variable (:constant-flag t) nil [4934 4939]) > ("streq" function > (:typemodifiers ("static") > :arguments > ( ("s" variable > (:pointer 1 > :constant-flag t > :type "char") > (reparse-symbol arg-sub-list) [4973 4987]) > ("t" variable > (:pointer 1 > :constant-flag t > :type "char") > (reparse-symbol arg-sub-list) [4988 5002])) > :type "bool") > nil [4954 5035]) > > This is a lot of useful information in a readable and usable format. > The only problem is that it's a little slow to parse: 190 files in > emacs/src take around 30 seconds for a full reparse. But then, all this > info is kept and is re-parsed only on timestamp changes. > > I did a caching optimization for `moo-jump-local' from function-args > package. When called without update it takes <0.1s to bring up all 19356 > semantic tags. The update (through a call with "C-u") takes ~3 seconds + > reparse time for any out-of-date file. > > My point is that because `moo-jump-local' uses semantic, it's a lot more > precise than e.g. `ggtags-find-definition' that gives only the names of > 9956 tags, with no semantic information. The point I was trying to make is that for users all this is unimportant. All they want is functionality: performance, accuracy, minimum false positives, etc. How this affects the database format is something they expect us the developers to figure out. And even if you take the POV of a developer, first there should be requirements: performance, accuracy, supported languages, etc. Only after that we get to design and implementation, where we select the database which can enable the functionality and support the requirements. Note as you explain above why TAGS might not be appropriate _because_ it cannot support certain important functionality: > In my opinion, the tags format of semantic is very good, much better > than plain TAGS. Maybe some work needs to be done to make them generate > faster/more precise, e.g. make GCC output these tags files. And that's my point exactly: first there's functionality we want, and only after that comes the selection of the database.