Tags not working
Michael Spertus
although it works fine on GNU Emacs. For example,
mps@bravo:~\> cat foo
foobar
mps@bravo:~\> etags --language none --regex "/foobar/baz/" foo
Under GNU Emacs, the unique tag name is seen as "baz", where XEmacs
incorrectly sees the tag name "foobar" but not "baz". The XEmacs etags
documentation describes the (more useful) behavior seen in GNU Emacs.
Is this a bug? Can anyone shed some light on this?
Thanks,
Mike
Stephen J. Turnbull
Michael> Under GNU Emacs, the unique tag name is seen as "baz",
Michael> where XEmacs incorrectly sees the tag name "foobar" but
Michael> not "baz". The XEmacs etags documentation describes the
Michael> (more useful) behavior seen in GNU Emacs. Is this a bug?
Michael> Can anyone shed some light on this?
AFAIK XEmacs etags is closely synched to GNU Emacs's (ie, Francesco
Portiorí's) etags, and has been for about two years.
Please send a bug report if it doesn't get resolved quickly.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
Michael Spertus
> >>>>> "Michael" == Michael Spertus <m...@geodesic.com> writes:
>
> Michael> Under GNU Emacs, the unique tag name is seen as "baz",
> Michael> where XEmacs incorrectly sees the tag name "foobar" but
> Michael> not "baz". The XEmacs etags documentation describes the
> Michael> (more useful) behavior seen in GNU Emacs. Is this a bug?
> Michael> Can anyone shed some light on this?
>
> AFAIK XEmacs etags is closely synched to GNU Emacs's (ie, Francesco
> Portiorí's) etags, and has been for about two years.
>
> Please send a bug report if it doesn't get resolved quickly.
This appears to be a longstanding problem. Looking through this
newsgroup, there have been several complaints that "named tags" don't
seem to work. Also, a quick look at etags.el doesn't seem to indicate
any knowledge of named tags. This seems like a pretty serious bug in
tags, to say the least, but it looks like no one has been motivated to
fix it. I'll still submit a bug report, though.
Stephen J. Turnbull
Michael> This appears to be a longstanding problem. Looking
Michael> through this newsgroup, there have been several
Michael> complaints that "named tags" don't seem to work.
This group is for users to help each other. The S/N for bugs here is
far too low for it to be worth our while to troll for them. If we
have time, and happen to see something that is clearly a bug, yes,
we'll follow it up. But I often go weeks without reading this group,
and many of the developers (including those who pay attention to
etags internals) do not read it ever.
Michael> Also, a quick look at etags.el
What does etags.el have to do with this? I _have_ seen mention of
etags.el. ... Oh, I see ... as I said, XEmacs 21.4.12's etags is not
broken. It produces exactly the same file that GNU Emacs 21.3.2's
etags does on your example. See what I mean about signal/noise?
I'll see what can be done about synching to GNU Emacs's version of
etags.EL. I seem to recall there was explicit objection to that in
the past, though.
Michael Spertus
> >>>>> "Michael" == Michael Spertus <m...@geodesic.com> writes:
>
> Michael> This appears to be a longstanding problem. Looking
> Michael> through this newsgroup, there have been several
> Michael> complaints that "named tags" don't seem to work.
>
> This group is for users to help each other. The S/N for bugs here is
> far too low for it to be worth our while to troll for them. If we
> have time, and happen to see something that is clearly a bug, yes,
> we'll follow it up. But I often go weeks without reading this group,
> and many of the developers (including those who pay attention to
> etags internals) do not read it ever.
>
> Michael> Also, a quick look at etags.el
>
> What does etags.el have to do with this? I _have_ seen mention of
> etags.el. ... Oh, I see ... as I said, XEmacs 21.4.12's etags is not
> broken. It produces exactly the same file that GNU Emacs 21.3.2's
> etags does on your example. See what I mean about signal/noise?
>
> I'll see what can be done about synching to GNU Emacs's version of
> etags.EL. I seem to recall there was explicit objection to that in
> the past, though.
Stephen,
I'm sorry if my response was offensive. Your point is well taken. I
will file the bug report. Just to clarify, etags.el is the library
that XEmacs uses to interpret the tags file. It does not produce the
tag file. The etags distributed with XEmacs produces excellent tag
files (and has replaced my Cygwin etags, which requires recompilation
to supports regular expressions).
I don't necessarily recommend using the GNU Emacs etags.el, although I
am using it as a stopgap. The XEmacs etags.el has a lot of extra
useful functions that could lead to much better tags browsing in the
future For example, it would be relatively easy to extend the XEmacs
etags.el to have it let you jump to any file referenced in TAGS with
auto-completion on filenames (AFAIK, it is not possible to do this
extremely desirable task with the existing tag functions, although the
XEmacs etags.el comes much closer. Correct me if I'm wrong.) Once the
'named tags' bug is fixed, the XEmacs etags.el will rock.
Stephen J. Turnbull
Michael> I'm sorry if my response was offensive.
It was not offensive. If I seem offended, it's not due to your reply,
it's that I think we should be able to do a better job of keeping up
with bug reports on _any_ channel than we do, and I'm a little
sensitive about it.
Michael> Your point is well taken.
I know :-(. I wish I could do better than to tell users to "work
harder at bug reports" and "use the right channels." But that's what
manpower and technology seem to limit us to these days.
Michael> I don't necessarily recommend using the GNU Emacs
Michael> etags.el, although I am using it as a stopgap.
I was afraid of that. A look at the GNU Emacs version vs. our version
indicates that it will be really hard to sync, and people really do
seem to like ours better in many ways.
At least (thanks to the efforts of Martin Buchholz and Yoshiki Hayashi)
our etags program is identical to that of GNU Emacs, so we're using
the same file format.
There is some interest (I mean on the part of the upstream tags
maintainers) in merging Emacs etags and Exuberant ctags. I don't know
what the status of that is, though.
Michael> Once the 'named tags' bug is fixed, the XEmacs etags.el
Michael> will rock.
Well, I've found and fixed one named tags bug in etags.el (the
completion mechanism didn't know about named tags). The etags.el in
XEmacs 21.5 _does_ purport to know about named tags to some extent
(search for a credit to Kyle Jones, and/or aliases for ASCII SOH such
as \001, ?C-a, etc.).
It's possible that completion is all it needs. I'll send you the
patch, others can follow on xemacs-beta
http://list-archives.xemacs.org/xemacs-beta/
Michael Spertus
> >>>>> "Michael" == Michael Spertus <m...@geodesic.com> writes:
>
> There is some interest (I mean on the part of the upstream tags
> maintainers) in merging Emacs etags and Exuberant ctags. I don't know
> what the status of that is, though.
>
have the potential to outweigh the benefits:
1. For some reason (license?), binary distributions that use Exuberant
ctags, such as cygwin, are built without regular expression support.
Under no circumstance should the XEmacs binary distributions lack
regular expression support in etags.
2. Exuberant ctags command line options appear rather different from
the GNU etags command. Having to have script changes based on which
etags is around would suck. In general, I think you XEmacs maintainers
have done a good job of maintaining just the right level of
compatibility with GNU Emacs, but this still leaves me a little
nervous.
3. Please make sure that the tag file format stays the same. You've
obviously worked hard on this in the current version and it shows. My
site includes a mix of Emacs and XEmacs users. (Indeed, I use Emacs on
Linux and XEmacs on Windows due to the greater control I have over the
configuration of my Windows workstation).
Thanks,
Mike