RE: IDE versus emacs

[Drew Adams]

> No. tags is mostly horrible. I can only use it for finding 
> definition and even that, only sometimes. Modern C++
> codebases (lots of templates) just do not do well with tags.

Not to disagree, but I would just like to point out where (I think) the real
problem is.  It is not with the Emacs tags mechanism or with the ability to look
up and navigate among tags.  It is with the generation of the TAGS file.

Emacs tags can really be anything at all.  The mechanism is quite general.  The
term "definition" is appropriate for most existing tags: what is indexed are in
fact definitions of functions, structs, whatever.

But that need not be the case.  Really, anything at all can be indexed.  And
tags need not even be limited to programming languages - you could tag a
thesaurus or Shakespeare's works in various ways, if you wanted to.

So what's needed (again, just trying to clarify) are programs to generate tags
(i.e. a TAGS file) that are appropriate for your use.  No doubt the existing
tag-generating programs (ctags, etags, ...) are too limited at present to index
the kinds of things you and others would like.

That's where I think the problem lies.  And guess what?  AFAIK, that has very
little to do with Emacs (see below).

Think of that as an opportunity (for Someone(TM)) to write a program that
generates a more useful TAGS file for your context/environment.  Once that's
done, I expect that you will find the existing Emacs tags mechanism and
navigation among your (appropriate) tags to be satisfactory.

Yes, there are other limitations, which you hinted at by mentioning wanting to
limit searches based on your current context.  There is currently no way AFAIK
to filter a set of candidate tags to those you might consider appropriate based
on where you are currently.

But that could be done, and it probably would not be difficult to do, depending
on precisely what you mean.  It is trivial to get hold of all of the tags
matching your input and filter those - you just need to be able to define that
filtering, based on your context and what you mean/want.  That, at least, is an
Emacs-Lisp job, unlike the rest of what I expect is needed for you.

(Of course, prefiltering, i.e., limiting the tags to search before matching your
input (presumably for better performance), could be more involved.)

One design limitation of the tags mechanism is that a TAGS file is a static
snapshot, which might not be up-to-date when you use it.  Navigating to existing
tag locations is typically not a problem, even if the file is not up-to-date.
But being out of date means that it does not index thingies that were created
after the file was generated, obviously.  

This is an inherent limitation, but of course the TAGS file can be regenerated
on demand, provided users have the program to do so.

The Emacs tags mechanism is pretty good, I think.  The main thing that's missing
for you is an up-to-date program that generates tags for the kinds of things you
are interested in.

That really has little to do with Emacs itself (depending on one's point of
view), and it just awaits some interested programmer to get 'er done.

To do that requires knowledge of your programming language (syntax, and
semantics to some extent).  And it requires general programming knowledge to
write the program (e.g. a program somewhat like etags).  And it requires
knowledge of the TAGS file structure.  And it requires some time and motivation.

But AFAIK it does not really require any knowledge of Emacs or Emacs Lisp.
That's why I say that it in fact has little to do with Emacs itself.

Of course, Emacs _users_ like yourself will be grateful, once it's done.  Since
we see such complaints here from time to time, perhaps this task would make a
good school, or summer of code, project.  Dunno.

One part of the task would be deciding just what it is that you would like to
index, for what languages, etc.  IOW, specify the requirements.