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: Sat, 17 Oct 2015 08:45:23 -0400 Message-ID: <562242E3.10503@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> 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 1445085965 10826 80.91.229.3 (17 Oct 2015 12:46:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Oct 2015 12:46:05 +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 Sat Oct 17 14:45:56 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 1ZnQry-0006rX-UL for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 14:45:55 +0200 Original-Received: from localhost ([::1]:58199 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnQry-0006hB-3c for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 08:45:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36442) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnQra-0006h0-4i for emacs-devel@gnu.org; Sat, 17 Oct 2015 08:45:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnQrW-0005Fj-SR for emacs-devel@gnu.org; Sat, 17 Oct 2015 08:45:30 -0400 Original-Received: from mail-qk0-x22e.google.com ([2607:f8b0:400d:c09::22e]:34150) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnQrW-0005FZ-Mz; Sat, 17 Oct 2015 08:45:26 -0400 Original-Received: by qkfm62 with SMTP id m62so63585553qkf.1; Sat, 17 Oct 2015 05:45:25 -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=cq6yuviHWO6TjtV6SwldkqFio4pUB/XasUAwERX52Ag=; b=ZTBl1JeVX9hQbc5iH6PUzocoxoZuriJxiu/9lc013KKxLJDD4VGWKYNjAAaY0NEorL KQjlYAonMuVxnrtfOu8Gsv8oi4pdDxNPH/OsWlmfaSkwcvi5ZGNTVA9aQA86MMpROpXP 9B/jj1Jyhu7Rtz35uMVny0NIde5xhEERfPdZ8nYxUltW2w2WQOsJHfwkMBsUs1IEkPho vtMUqYUNb7BQopKY2rFRRwE6HlfAxvSIp7ZJUSRf9lKGx3i5LPrndX7mV94uOLqkWaqU tUeqfcZrTFfro+ji2VkBesdixDhyFHv4jba9y5adZq/UQ/PRD9jPpw2O/WFGykQ5qF+g uVRA== X-Received: by 10.55.197.77 with SMTP id p74mr24870517qki.89.1445085925363; Sat, 17 Oct 2015 05:45:25 -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 q185sm223455qha.28.2015.10.17.05.45.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Oct 2015 05:45:24 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: <5621BB2A.5000802@yandex.ru> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c09::22e 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:191821 Archived-At: On 10/16/2015 11:06 PM, Dmitry Gutov wrote: > On 10/17/2015 05:39 AM, Eric Ludlam wrote: > >> The magic of overlays is that the overlays keep the bounds of the tag up >> to date for you. Once you stop editing, and incremental parser fixes up >> any weird things you might have done, such as hacking a tag in half, >> adding new tags, etc. Because it is incremental, is typically >> instantaneous. > > Is that still true if you're editing at the beginning of the file? > Yes. >> I am not familiar with SMIE as an acronym, but a google search makes it >> look like someone made a parser generator, in which case there is no >> real difference except that SMIE is tuned for indentation, and wisent is >> tuned for parsing tags. > > My point is, Semantic grammars don't help with writing indentation > code (could they?), and we already have SMIE grammars for several > languages. It would make sense to be able to make do only with one or > the other, not have them both for the same language. > Ah, I think I see what you are poking at. 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. The difference is that the parser generators in Semantic today have optimizations for skipping parts of the buffer while tagging. This lets it parse whole files more quickly, and more robustly. Since it uses syntax tables to do that, I'll guess SMIE can do it, but I'm not that familiar with it. Also, wisent type grammars could easily dump out data you need for indentation since actions can do anything you can write in lisp. No one has tried to do it though. > >> If by "open all project files" you mean pull file contents into a buffer >> and leave it open, then that is not what semantic does. The data is >> indeed resident in memory, but files stay closed unless the user asks to >> jump there. The first time you make a request that needs searching, it >> will open files to parse them, but then it closes the file. Later, it >> refers only the the cached data, not to the files. > > I mean that you have to use etags at some point anyway. Or gtags, or > id-utils, etc. > Have to, no. Want to, probably. Those tools provide nice short-cuts when doing simple name lookup. 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. The output of the search includes a database table, and tags found in that table. The tags are additionally refined based on whatever the layered criteria is, and when the code decides to work with a detailed tag from the search, it forces it to be real, and pulls it into a buffer if necessary, and any problems with the weak tagger is resolved. 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. > >> CEDET/Semantic usually gets foo.bar() syntax correct, unless you are >> saying something else. Can you elaborate? > > In the few languages it properly supports now? Maybe it does, most of > the time (although not in the problem example I gave in this > discussion: https://gist.github.com/dgutov/19c45ef43d1c90b96483; no > matter the argument tee is called with, `C-c , J' jumps to the first > function with that name). > I missed that before. The answer here is that: C-c , J RET has two results. Since that is a prompt based query and only the string is available once it is up. If instead you put the cursor on "tee" and do M-x semantic-ia-fast-jump RET it will go to the right spot. For the keybinding you were using, the workflow is: C-c , J tee TAB shows you where it would jump, then TAB refines to the next possible target. Hit RET when it shows you the place you do what to jump to. It needs more typing since the default isn't on the prompt. Perhaps that is a possible improvement. Can all this be improved - sure. I agree it would be nicer to mix the two workflows better. Most of my time goes into the parsers etc. > But what about duck typed languages? If a method foo calls bar on its > argument tee, we don't know the type of tee, all we know that it has a > method bar. > In the workflow above, you can just keep pressing TAB to pick the one you want. Eric