Paul, unfortunately I don't have time to recode find-tag-in-order (it
looks a bit tricky), but I will send a bug report to gnu-emacs and am
also cc'ing this to the jde mailing list in case someone there wants
to try.
-C. Rich
P.S. Note that the only way to change the behavior of tags is to
either clobber the Gnu definition of find-tag-in-order, or to define
jde versions of several intervening functions starting with find-tag
and then rebind M-. to the new jde definition.
> Date: Thu, 04 Jan 2001 13:07:13 -0500
> From: Paul Kinnucan <[EMAIL PROTECTED]>
>
> At 12:43 PM 1/4/01 -0500, Charles Rich wrote:
> >Hi Paul,
> >
> > I would like to contribute the following improvement to the behavior
> >of find-tag for JDE. The basic idea is, when looking for a tag which
> >has multiple matches in the TAGS file, to prefer (find first) the
> >occurrence in the _current_ buffer.
> >
> > A good example of why this is the natural behavior for editing Java
> >code is to imagine that you have many files (classes) with the
> >toString() method defined. If you are editing W.java and do
> >M-. toString, you would almost always be happier jumping to the
> >definition of toString in W.java, rather than the definition in
> >A.java, B.java, etc., which happen to fall in alphabetical order
> >before W.java in the TAGS file..
> >
> > Also, note below that in addition to making the new predicate
> >"current-buffer-exact-name-match-p" the first entry in the
> >find-tag-tag-order, I removed the non-exact match predicates. Again,
> >I think when editing Java code, it is more natural to jump to an exact
> >match only (you can always use the regexp option of find-tag if you
> >really want to look for a pattern). In particular, if you want to
> >visit the multiple occurrences of tag Foo (using C-u M-.), you don't
> >want to have to step through FooBar and FooBaz, etc., to get to them.
> >
>
> Your ideas make a lot of sense. I will incorporate your changes into the
> next release.
>
> > Finally, note the following code only works correctly when there is
> >a _single_ tags table or the current buffer happens to be a member of
> >the first table in tags-table-list. This is because there is IMHB a
> >bug in the way that find-tag-in-order is coded, i.e., the outside loop
> >is over the tags-table-list and the inside loop is over the order
> >predicates---I think it should be the other way around (but I haven't
> >tried to recode it or notify FSF).
> >
>
> It would be great if you could recode find-tag-in-order to do the right
> thing, perhaps under a different name. We could include the revised version
> in the JDE.
>
> Regards,
>
> Paul
>
> > Regards, C. Rich
> >
> >________________________________________________________________
> >
> >(defun current-buffer-exact-name-match-p (tag)
> > (and (tag-exact-match-p tag)
> > (equal (buffer-file-name (window-buffer (selected-window)))
> > (file-of-tag))))
> >
> >(defun jde-etags-recognize-tags-table () ; see etags-recognize-tags-table
> > (let ((recognized (etags-recognize-tags-table)))
> > (if recognized
> > ;; prefer exact match in current buffer to other files
> > (setq find-tag-tag-order '(current-buffer-exact-name-match-p
> > tag-exact-file-name-match-p
> > tag-exact-match-p
> > ))
> > recognized)))
> >
> >(setq tags-table-format-hooks '(jde-etags-recognize-tags-table
> > recognize-empty-tags-table))
> >
> >________________________________________________________________
--
Charles Rich | Mitsubishi Electric Research Laboratories
617-621-7507 phone | 201 Broadway
617-621-7550 fax | Cambridge, MA 02139
[EMAIL PROTECTED] | http://www.merl.com
