This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
From: Frank Gleeson <fgleeson@rcn.com>
Subject: Re: Tags
Date: Sat, 02 Jun 2001 00:37:13 -0400
Can you be more explicit, or were these just general purpose miracles?
As for the quality of the matches, this is not emacs fault. It is 100%
determined
by the tagging utility. Emacs is simply reading the TAG file and presenting
matches
in the order encountered.
Is it possible your boss was not using the standard etags? On many unix
systems etags is sym-linked to ctags (vi). I do not think anyone is actively
supporting either tag utility.
There is a developer Darren Heibert who has written his own etag utility.
It is called "exuberant etags". It is a free download on the web. I really like
this utility it picked up many more tags. I ended up sticking with standard
etags however because there were some obvious ones that were missed.
Aside from the TAG file quality there is the competance of the editor.
In my opinion, although emacs and xemacs are very similar in capabilities there
are several
areas where xemacs demonstates superiority. Support for tags is one of those
areas.
In emacs you can specify either a single TAG file or a list of TAG files to be
searched in order.
If the same hit occurs in more than 1 TAG file they will be displayed in TAG
file list order.
In xemacs' tag-table-alist allows a regex that is matched against the current
buffer name.
If the regex matches and the tag is displayed. This allows you to use absolute
path, relative
path, or file extension to rule in/out a TAG file for matches. This has
important implications
if you have more than one source tree or language to worry about. You can make
your match
criteria as complex as required. If you really do not need the regex a value of
""
will match all buffers.
(setq tag-table-alist
'(
("/MPS_FTF/" . "c:\\vss\\mps_ftf\\TAGS" ) ;Child of MPS_FTF
("\.[ch]" . "C:\\Program Files\\Borland\\CBuilder4\\Source\\TAGS" ) ;c file
use Builder
("\.[ch]" . "C:\\Program Files\\Borland\\CBuilder5\\TAGS" ) ;c file use
Builder
("\.[ch]pp" . "C:\\PROGRA~1\\Borland\\CBUILD~1\\Source\\TAGS" ) ;c file use
Builder
("" . "c:\\XEmacs\\TAGS" ) ;Use xemacs tags file from anywhere
))
To improve the quality of matches from any tag utility you can write a script
that automates the process. To improve the quality of hits you can order the
files intelligently. For "C" put .h files before .c and .cpp. In the general
case
this will cause global definitions to precede local definitions in the TAG
presentation order.
Another cool thing you can do is build the TAGS files from your makefile.
Either as a special target or as a part of your normal build. This ensures that
the TAGS are always up to date.
"Thaddeus L. Olczyk" wrote:
> On Fri, 01 Jun 2001 20:17:07 +0300, Eli Zaretskii <eliz@is.elta.co.il>
> wrote:
>
> >"Thaddeus L. Olczyk" wrote:
> >>
> >> Is there a good online reference to tags?
> >
> >You mean, the `etags' program which creates the TAGS files? There's a man
> >page in the Emacs distribution which documents `etags'.
> No the possible uses of TAGS files in emacs.
> I once had a boss who could do miracles with them, much more than
> what is described in the manual.
> Also it seems that etags picks up the worst possible match.
Path: nntp.stanford.edu!newsfeed.stanford.edu!newsfeed.berkeley.edu!news-hog.berkeley.edu!ucberkeley!news.ycc.yale.edu!tequila.cs.yale.edu!rum.cs.yale.edu
From: "Stefan Monnier <foo@acm.com>" <monnier+comp.emacs/news/@flint.cs.yale.edu>
Newsgroups: comp.emacs
Subject: Re: Tags
Date: 02 Jun 2001 11:35:05 -0400
Organization: Yale University
Lines: 27
===
From: Frank Gleeson <fgleeson@rcn.com>
Subject: Re: Tags
Date: Sun, 03 Jun 2001 02:58:59 -0400
I think you misunderstand what I was saying. I am not trying to fan the flames
of an emacs vs xemacs holy war. Both emacs and xemacs are light years ahead
of all other editors.
I regularly run emacs and xemacs. I have used both editors extensively. There
are only
a small number of significant differences between them. However the original
poster seemed to
be concerned about getting the most out of etags. In my "opinion" this is one
of the areas
where xemacs outshines emacs.
Maybe what I should of said was the etags.el that ships with xemacs provides
superior functionality to the etags.el that ships with emacs. I am sure with a
little
effort you could get the xemacs etags.el to run on the emacs interpreter.
>>This is not always true. There are cases where some heuristic could
>>improve the order in which matches are shown. And since the optimal
>>order usually depends on where the query is made, it can't be solved
>>by `etags' but has to be done in The Editor.
Are you claiming that emacs has this heuristic? As far as I can tell emacs
provides
no way to control which candidate TAG files are used in a given match. xemacs
does provide a way to do this as I explained in my earlier post. Basically the
emacs
approach leads to a monolithic TAGS file. This approach is adequate if you only
program in one language and you only have one active development project.
The xemacs approach lends itself to a modular approach. As an example at my
former
employer we had several libraries that provided equivalent functionality on
different machines.
This allowed the application code to make high level function calls without
knowing or caring
what actual hardware it was running on.
This led to a complictaion for tagging there were usually at least 3 different
versions of any
function name. With one big TAG file or a static list (as provided by emacs) it
would usually
not show the correct function definition.
This really can break your concentration. If you are following a chain of calls
and then suddenly
realize you are looking at the wrong function.
If there is something about emacs TAG support that I failed to grasp please
enlighten me.
"Stefan Monnier " wrote:
> >>>>> "Frank" == Frank Gleeson <fgleeson@rcn.com> writes:
> > Can you be more explicit, or were these just general purpose miracles?
> > As for the quality of the matches, this is not emacs fault. It is 100%
> > determined by the tagging utility. Emacs is simply reading the TAG file
> > and presenting matches in the order encountered.
>
> This is not always true. There are cases where some heuristic could
> improve the order in which matches are shown. And since the optimal
> order usually depends on where the query is made, it can't be solved
> by `etags' but has to be done in The Editor.
>
> > Is it possible your boss was not using the standard etags? On many unix
> > systems etags is sym-linked to ctags (vi). I do not think anyone is
> > actively supporting either tag utility.
>
> Franceso Potor