[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: unifying emacs "go to definition" functionality

From: Jambunathan K
Subject: Re: unifying emacs "go to definition" functionality
Date: Wed, 20 Feb 2013 15:51:48 +0530
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Lawrence Mitchell <address@hidden> 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 


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]