From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Oleh Krehel Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Tue, 27 Oct 2015 09:21:40 +0100 Message-ID: <871tcgzppn.fsf@gmail.com> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1445934085 10287 80.91.229.3 (27 Oct 2015 08:21:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 27 Oct 2015 08:21:25 +0000 (UTC) Cc: adatgyujto@gmail.com, esperanto@cumego.com, emacs-devel@gnu.org, nix@esperi.org.uk, Dmitry Gutov , drew.adams@oracle.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 27 09:21:18 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 1ZqzVO-0006FE-0Y for ged-emacs-devel@m.gmane.org; Tue, 27 Oct 2015 09:21:18 +0100 Original-Received: from localhost ([::1]:58043 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqzVN-0004jo-Ic for ged-emacs-devel@m.gmane.org; Tue, 27 Oct 2015 04:21:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56623) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqzVK-0004ji-5f for emacs-devel@gnu.org; Tue, 27 Oct 2015 04:21:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZqzVG-00059g-9h for emacs-devel@gnu.org; Tue, 27 Oct 2015 04:21:14 -0400 Original-Received: from mail-wi0-x22d.google.com ([2a00:1450:400c:c05::22d]:34011) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqzVF-00059Z-UI; Tue, 27 Oct 2015 04:21:10 -0400 Original-Received: by wikq8 with SMTP id q8so199421265wik.1; Tue, 27 Oct 2015 01:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=incimlZ9629HL95EpVuJekkIaFZM4kRyH9E8TjpX/FI=; b=x/j3KZkZxoL5wYDIGA/VznF6SnMDfG7D4LvX4Ynr7UQJYp3rclMYkYbs6mBu7TLuA3 HPI27recv/n8jSgqW5VgIySjXRuqfMGROmO1C74Q4RMWrEiSHU2dokb3pLhlIiYaoWOW 7rivXazbvSpBAIfI4TPOURNyreca92i+NVd5Aj+CqbyDVxy7omMgmhsEYkpVVwBVaCr0 WtgMVMJLHa+ZE64PNvx/KRBclolf7vNihO78Wk8woz49rvLuKI+M5X3oTTbD2sRzUYiz 4kOe2wFpGQyYCVVpfW/nu9VA3OJAXUXjR2+7BIorU5zRbmjaka7ePyguTMLhog6KAwps ieUg== X-Received: by 10.180.182.49 with SMTP id eb17mr26860647wic.82.1445934069270; Tue, 27 Oct 2015 01:21:09 -0700 (PDT) Original-Received: from firefly (dyn069045.nbw.tue.nl. [131.155.69.45]) by smtp.gmail.com with ESMTPSA id ev1sm14048988wic.21.2015.10.27.01.21.08 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 27 Oct 2015 01:21:08 -0700 (PDT) In-Reply-To: <83y4esum70.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 24 Oct 2015 21:59:47 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22d 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:192711 Archived-At: Eli Zaretskii writes: >> From: Dmitry Gutov >> Date: Sat, 24 Oct 2015 21:15:18 +0300 >> Cc: nix@esperi.org.uk, esperanto@cumego.com, adatgyujto@gmail.com, >> drew.adams@oracle.com, emacs-devel@gnu.org >> >> > 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. Compare: MAX_PARAGRAPH_SEARCH x_parse_color to: #include xterm.h #include xterm.h #define BLACK_PIX_DEFAULT xterm.h #define WHITE_PIX_DEFAULT xterm.h #define STANDARD_EVENT_SET xterm.h x_bitmap_record xterm.h Pixmap pixmap xterm.h bool have_mask xterm.h Pixmap mask xterm.h char* file xterm.h int refcount xterm.h int height xterm.h int width xterm.h int depth xterm.h color_name_cache_entry xterm.h color_name_cache_entry* next xterm.h XColor rgb xterm.h char* name xterm.h Status x_parse_color (frame *f, const char *color_name, XColor *color); xterm.h 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.