From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Tue, 20 Oct 2015 03:56:54 +0300 Message-ID: <56259156.7010700@yandex.ru> 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> <5624D92E.5020402@gmail.com> 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 1445303685 15663 80.91.229.3 (20 Oct 2015 01:14:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 20 Oct 2015 01:14:45 +0000 (UTC) Cc: adatgyujto@gmail.com, emacs-devel@gnu.org To: Eric Ludlam , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 20 03:14:44 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 1ZoLVk-0007xz-AX for ged-emacs-devel@m.gmane.org; Tue, 20 Oct 2015 03:14:44 +0200 Original-Received: from localhost ([::1]:42827 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoLVi-0005u3-W9 for ged-emacs-devel@m.gmane.org; Mon, 19 Oct 2015 21:14:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39997) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoLEc-0004Rf-03 for emacs-devel@gnu.org; Mon, 19 Oct 2015 20:57:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZoLEX-0004In-0b for emacs-devel@gnu.org; Mon, 19 Oct 2015 20:57:01 -0400 Original-Received: from mail-wi0-x229.google.com ([2a00:1450:400c:c05::229]:33534) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoLEW-0004I1-PJ; Mon, 19 Oct 2015 20:56:56 -0400 Original-Received: by wijp11 with SMTP id p11so23819565wij.0; Mon, 19 Oct 2015 17:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=Ok/ZRvuIpzXaZAaAGOtf6NyD8ytZs6nTLCUPuTPgec8=; b=gqowEnK8rEDz1yvrANqyUXcDD8fANmos7uGSVa2a634gHmlJq8gIzy71zRhpBmvvh8 tfD5mWrWKyGklezm8Y7s+s0nQ4eYdwgg4ERfLA+HGCWrENaJETv8xu8BgLJrBD+vBxzm 48XQOA59fcnEJPfoZHzQDepOUKMEsDJe4/FcAeFx7XVNCe8HPh/g3avinQypEE5smUWF di1M2KpT2kbxwA8ibCkaUkoH+MrahjKcPyZtQXyvSLHiBuFs7UkJGXouhwV/lcq3vj6Z SUoqKw9pBO9jUKiBL/blKai+RNAwj9U0wOp6bJN41GCQNE7lh3777Dx1LxzF0pCBQfi5 4z+Q== X-Received: by 10.180.87.102 with SMTP id w6mr923385wiz.88.1445302616075; Mon, 19 Oct 2015 17:56:56 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id he3sm402677wjc.48.2015.10.19.17.56.54 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Oct 2015 17:56:55 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: <5624D92E.5020402@gmail.com> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::229 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:192138 Archived-At: On 10/19/2015 02:51 PM, Eric Ludlam wrote: > 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. All right. But I would say that IMenu was conceived as a poor cousin to tagging. After all, if we have up-to-date information about tags in the current project, we can jump anywhere, not just in the current file. My point is, we could have a more limited "protocol" to be used when we don't have a list of tags for the current file (and "jump to xxx" command is implemented via overrides, using an external tool). And a "full" protocol for when the tags are available. > 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. Right. It's quite nifty. I was just pointing out that it won't work for some languages. > 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. I suppose so. ctags (not in the Emacs repo) supports more file formats, though. > You are right, I missed that. I've started a new test suite around this > missing feature and will look into it. Thank you. > I've run out of steam trying to design the perfect set of keybindings. > Everyone seems to like something different. ;) I understand the difficulty, but surely you'd want to advertise semantic-ia-fast-jump? It's more precise, and thus, more powerful. > 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. We could use some mix of the current xref behavior, with this one, for xref-find-definitions. xref is static, but shows everything. This one is dynamic, but shows only one option at a time.