| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
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 |