From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jambunathan K Newsgroups: gmane.emacs.devel Subject: Re: unifying emacs "go to definition" functionality Date: Wed, 20 Feb 2013 15:51:48 +0530 Message-ID: <87bobf2slf.fsf@gmail.com> References: <87vc9n8fx5.fsf@gmx.li> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1361355750 4692 80.91.229.3 (20 Feb 2013 10:22:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Feb 2013 10:22:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: Lawrence Mitchell Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 20 11:22:52 2013 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 1U86p9-0003iG-MF for ged-emacs-devel@m.gmane.org; Wed, 20 Feb 2013 11:22:51 +0100 Original-Received: from localhost ([::1]:58207 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U86on-0002Lp-L5 for ged-emacs-devel@m.gmane.org; Wed, 20 Feb 2013 05:22:29 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:36850) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U86og-0002Kk-CG for emacs-devel@gnu.org; Wed, 20 Feb 2013 05:22:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U86od-00028q-Bm for emacs-devel@gnu.org; Wed, 20 Feb 2013 05:22:22 -0500 Original-Received: from mail-pa0-f43.google.com ([209.85.220.43]:39093) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U86od-00028E-4x for emacs-devel@gnu.org; Wed, 20 Feb 2013 05:22:19 -0500 Original-Received: by mail-pa0-f43.google.com with SMTP id bh2so4015773pad.16 for ; Wed, 20 Feb 2013 02:22:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=0hHUMcGwRBbBbslGSo0RdF/rhq44FjskloJeURALDS4=; b=aLoDS/pzp8rycPGoF9Z8ErhVN0uFAjYRUpMraeZ1MbzwTFqE+5EIqUvnDp0hLwapRg VVa/d0/1cFDZwE/TPqkyxvK777dsMdY7qJghgNCLoUt1oAg34G+Nzbobu72x+ZqIHteM /jG+UoMW7dAddNN04ptkaw6VGFTtx9mhU41AFWTZVXIQ+ErGwPqJXq+pLXM/AKONGi8L ZdPTBvrp4WlYJO5hxffXJ74riNhf7guh+hE9pJ6SBk6Zys1f0pEBm9OzLeB+UoudJr+l 7YQiqif3atr6lLY9hEPOVg7HXBolTwuP2KZW2kbmFV8dEt3LK7JFMxg1d5rHov0h4EuQ izEA== X-Received: by 10.68.189.169 with SMTP id gj9mr48575637pbc.67.1361355738140; Wed, 20 Feb 2013 02:22:18 -0800 (PST) Original-Received: from debian-6.05 ([101.63.253.46]) by mx.google.com with ESMTPS id i10sm21222963pbd.1.2013.02.20.02.22.13 (version=TLSv1.1 cipher=RC4-SHA bits=128/128); Wed, 20 Feb 2013 02:22:16 -0800 (PST) In-Reply-To: <87vc9n8fx5.fsf@gmx.li> (Lawrence Mitchell's message of "Wed, 20 Feb 2013 09:59:02 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.220.43 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:157198 Archived-At: Lawrence Mitchell writes: > I don't like etags' interface for jumping through multiple definitions > and prefer a method which allows the user to see and pick which > definition they want. I suggest a grep-like interface where one can get an overview of the results and also persist the results. Search results for a tag should stack one on top of one another in the search buffer. There is a unique search buffer at the project root to which results are prepended or appended. Provide outline capabities in the search buffer - For example, that which is searched could be level-1 org heading and the results of search could be level-2 org headings. One can imagine a command that automagically populates a level-1 heading with level-2 headings which are look-up-references. One can edit (this is important) and get a quick overview of one's treasure hunt buffer through org/outline navigation. One can type quick notes outside of codebase right within the search buffer. I am quite used to M-g M-n and M-g M-p for navigating between the search results while getting an overview in the grep results buffer. IMNSHO, the Emacs tying together of search results with compilation-regexps is "too tight". What I mean is that one can in no way annotate the "search results" richly - function names in search results, is an example of such an annotation - without at all messing with search results themselves. For example, I use 'after-string property to display function names while I would have actually wanted to get the function name right within the buffer itself for reasons of persistence to disk. See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13549 and an enhanced rgrep at http://debbugs.gnu.org/cgi/bugreport.cgi?msg=5;filename=grep-proof-of-concept-cf-cscope.png;att=3;bug=13549 I propose that the right way to think about what is being discussed is this: Look at the "search results buffer" as a single-window controlling dashboard for making sense of huge code bases. The search interface is very important for people who want to make sense of code base that they haven't written themselves. --