Re: Is xemacs' etags.el really "better and faster"?

... as the comments at the top claim? I spent a bit of time trying to use it, and concluded that it's dysfunctional. The "exuberant ctags" FAQ claims the following... %% 5. Why doesn't Xemacs correctly locate the tag in the source file? %% %% This has been observed with version 20.3. It seems that when Xemacs %% searches for a %%tag, it searches using the tag name instead of the %% search string located in the TAGS file. This is a bug in Xemacs and %% does not occur in the GNU version of Emacs. I'm not quite sure yet whether that diagnosis is right, or whether it's doing something else, but it doesn't behave "sensibly" for me. Looking up say a tag "Float" appears to find something like "BoxedFloat::serialize", which seems consistent with one reading of the documentation, but if I read it that way it's a pretty bizarre intentional behaviour. And a patch to sync to the FSF version last year met with no response: >> http://list-archive.xemacs.org/xemacs-patches/200001/msg00187.html >> Message-ID: <FAFE609CB754D311B60C0008C75D35563BDD5D(a)dbwdfx14.wdf.sap-ag.de&gt; >> >> If you have try to find a C typedef in XEmacs (finds all functions with >> that return type) and in Emacs, you know that this is the right patch... I'm sure the current behaviour must make sense to some people, but the FSF emacs etags.el produces far more intuitive behaviour for me. Any pointers to something more smart that maintaining a personal xemacs port of the FSF etags.el would be welcome. Thanks Anthony