From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eric Ludlam Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Mon, 19 Oct 2015 07:51:10 -0400 Message-ID: <5624D92E.5020402@gmail.com> References: <5610207A.2000300@harpegolden.net> <83fv1r3gzp.fsf@gnu.org> <83bncf3f9k.fsf@gnu.org> <5610E0BC.8090902@online.de> <83si5r106e.fsf@gnu.org> <831td9z18h.fsf@gnu.org> <5612E996.7090700@yandex.ru> <83bnc7tavr.fsf@gnu.org> <5618C92A.3040207@yandex.ru> <83a8rrt9ag.fsf@gnu.org> <5618D376.1080700@yandex.ru> <56194171.1080006@siege-engine.com> <5619E7C7.5000401@yandex.ru> <561A9E6D.8080403@gmail.com> <561BCF54.7060000@yandex.ru> <561D85DE.4090304@gmail.com> <561F1A75.1000909@yandex.ru> <561FA2A3.9030409@gmail.com> <5620F60A.1030104@yandex.ru> <5621B4D5.9040607@gmail.com> <5621BB2A.5000802@yandex.ru> <562242E3.10503@gmail.com> <56225A57.9030705@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1445255484 4537 80.91.229.3 (19 Oct 2015 11:51:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Oct 2015 11:51:24 +0000 (UTC) Cc: adatgyujto@gmail.com, emacs-devel@gnu.org To: Dmitry Gutov , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 19 13:51:23 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 1Zo8yG-0005rS-JS for ged-emacs-devel@m.gmane.org; Mon, 19 Oct 2015 13:51:20 +0200 Original-Received: from localhost ([::1]:38484 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo8yF-0004gl-L5 for ged-emacs-devel@m.gmane.org; Mon, 19 Oct 2015 07:51:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52633) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo8yB-0004ge-VK for emacs-devel@gnu.org; Mon, 19 Oct 2015 07:51:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zo8y8-0000vy-Lz for emacs-devel@gnu.org; Mon, 19 Oct 2015 07:51:15 -0400 Original-Received: from mail-qk0-x230.google.com ([2607:f8b0:400d:c09::230]:35586) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo8y8-0000vq-H9; Mon, 19 Oct 2015 07:51:12 -0400 Original-Received: by qkbl190 with SMTP id l190so20831876qkb.2; Mon, 19 Oct 2015 04:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=/UvEBpQbkvu1s6KZ4awUs7oBPEuZLfvHqP7L3DT6u9Q=; b=F2yXryhH3FZRUwmZ/5yAlfQRi1B213KPQlUUyXVcw+d4ZLPB+WFH1aWYaM63QTHWnr va7PK3vAPbzBNuLnETiQHG8MQQMoIiEcbYXCYjp17Guch3aKJhwC5mWKLbZc0d5VkOCB KALazEjIfsc3fl4MdIdZeY9o/UMR1vyFlfgo7BLJFDGGC10r+ylIyeLHCn2MNC7aVbi6 n+sk992nZwn+4Sf3t8npZJSIWAZnH0pcTz5yR3txuYLPpPtZYWip8NzLD3H1AEWmRWrH t7Cfn1mHRJ7p98NGK3A3KlwtS/KScndUe2zJj5hr5YOlwE06difwRkBthgCAQNhBmIPF 5TKg== X-Received: by 10.55.33.152 with SMTP id f24mr34929457qki.17.1445255472022; Mon, 19 Oct 2015 04:51:12 -0700 (PDT) Original-Received: from [192.168.1.202] (pool-71-184-198-118.bstnma.fios.verizon.net. [71.184.198.118]) by smtp.googlemail.com with ESMTPSA id 138sm14048448qhw.27.2015.10.19.04.51.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2015 04:51:11 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: <56225A57.9030705@yandex.ru> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c09::230 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:192076 Archived-At: On 10/17/2015 10:25 AM, Dmitry Gutov wrote: > On 10/17/2015 03:45 PM, Eric Ludlam wrote: > >> There is nothing about semantic the framework that prevents using >> something like SMIE as a tagging engine. It seems likely that if some >> language not supported by CEDET today has a good SMIE grammar, and if >> SMIE could be adapted to produce compatible tags (which isn't really >> that hard to do), and if SMIE has an entry point that allows parsing a >> tag set out of a region, then it would integrate into the semantic >> framework at the best level. > > With SMIE, though, it might make sense to optimize the process and > only ask it for the current tag (and maybe the nearby ones), because > it would otherwise be slower (no incremental parsing, or anything like > that). So a straightforward conversion might not be optimal. > > But from the main examples you gave of tag usage, knowing the current > tag is by far the most important. There are many reasons why having all the tags in the current buffer is useful. The simplest of which are things like imenu - the menu part, speedbar, or ECB listings of all tags so you can jump to them. There is a command for jumping to a tag in a buffer by name with completion. There's an isearch flavor that searched only tag names in the current buffer. Of course, the most important is that if you have all the detailed tags from a file that is closed, you don't need to open the file again if you need to reference it. >> The mechanism in use is that there are detailed taggers, like those >> currently written for Semantic using wisent type parsers, and weak >> taggers, like GNU Global. >> >> Once a buffer is open, the detailed tagger runs and is truth. When a >> search occurs, a process of pulling all relevant databases together is >> started. This includes tags from the detailed taggers already cached, >> and high level 'omniscient' taggers that are usually weak, but have >> scanned the whole project. > > Well, that's my point: if you don't use etags, to have all project > files indexed you have to open each of them at some point. > Sure - something does have to open them. If not emacs, then something will. > Some languages have import systems where you have to declare all > file's dependencies at its top (and so you can know which files to > reindex if you're only interested in this file; although even that > could be a lot). But in Ruby and pre-ES6 JavaScript, you don't usually > have that. > Using imports and includes, the semantic framework tracks what the dependencies are, and will reparse files that change outside of Emacs. It also will only open files listed as dependencies. It will also, in idle time, pull in things it suspects you might want to open later, but that is to make visiting those things faster. It is easy to turn off, and we could turn it off by default if it is causing problems. > >> The key here is that the detailed tagger is needed to do complex tasks, >> but weak taggers are great to integrate in due to the speed advantage. >> Having a mix gives you the best possible results. > > If the program generating TAGS is smart enough, the result can be > pretty accurate already (and contain qualified method name). Eli has > recently made some improvements to that effect to etags. > If it can produce the needed data, then it would be simple enough to swap it in as an external parser. Since Emacs has full control over etags, it could be adapted to handle regions, and thus fit in just fine. >> If instead you put the cursor on "tee" and do >> >> M-x semantic-ia-fast-jump RET >> >> it will go to the right spot. > > Indeed it does, thanks. But it goes to the second definition > irrespective of which argument is passed to tee. Which brings us back > to the completion problem I reported with that snippet. > You are right, I missed that. I've started a new test suite around this missing feature and will look into it. >> For the keybinding you were using, the workflow is: > > Right, why doesn't semantic-ia-fast-jump have a default keybinding? I > was only looking for the appropriate command in the active keymaps. > I've run out of steam trying to design the perfect set of keybindings. Everyone seems to like something different. ;) >> C-c , J tee TAB >> >> shows you where it would jump, then >> >> TAB > > Oh, so it uses something more advanced than completing-read. That's > unexpected. > Yes. I wrote my own so that the completion engine could weed out the maximum number of possible completions and speed up the process. Some of the tricks others have done that do take all possible completions in their UIs I think have obsoleted that advantage. But also, I was looking for ways to allow selection of different methods of the same name that was easy and quick, and this is what I came up with. Eric