[9706] in Athena Bugs

home help back first fref pref prev next nref lref last post

Re: decmips 7.4G: Bug in tags.el

daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Wed Jul 29 13:41:38 1992

Date: Wed, 29 Jul 92 13:41:22 -0400
From: "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
To: "Reid M. Pinchback" <reidmp@Athena.MIT.EDU>
Cc: Marc Horowitz <marc@MIT.EDU>, bugs@Athena.MIT.EDU
In-Reply-To: [9703]

   [9703]  daemon@ATHENA.MIT.EDU (Reid M. Pinchback) Athena Bugs 07/29/92 09:26 (28 lines)
   Date: Wed, 29 Jul 92 09:26:18 EDT
   From: "Reid M. Pinchback" <reidmp@Athena.MIT.EDU>

   How is finding the wrong tag first, when the correct tag is available in
   the TAGS file, a feature?

The documentation for the find-tag function says, "Find tag (in
current tag table) whose name *contains* TAGNAME" (emphasis mine).
The current behavior is *documented* as the current behavior, and was
intentional.

It is a feature because people sometimes just want to type part of a
long tag in order to locate it.

   It makes tags.el unreliable for non-interactive
   use in a way that is totally unnecessary.

It is not clear that it is "unnecessary," since the people who wrote
the tags code apparently liked the behavior.  It is also not clear
that the tags stuff was really *intended* to be used
non-interactively.

As has already been pointed out, it would be difficult to make the
tags code find only "word-bound" tags in all cases, since it is not
always clear what a "word-bound" tag is.  Therefore, it seems
reasonable that rather than implement a partially broken word-bound
tag search, they chose to do a substring search.

 Jonathan Kamens
 IS/Athena Quality Assurance

home help back first fref pref prev next nref lref last post