At 07:32 PM 1/20/00 +0000, Larry Riedel wrote:
>
>> Larry Riedel recently asked me about whether jtags handles
>> classes. I answered too hastily in the negative. Actually,
>> jtags does tag classes (and interfaces) and seems to work
>> just fine. I'm not sure why Larry was having a problem.
>>
>> On the other hand, I believe that etags does not tag classes
>> and interfaces. If anybody can confirm this, I'd be greatful.
>
>With regard to finding the definition of a class, etags
>and jtags seem to me pretty much equivalent as far as
>what gets put into the TAGS file. As I said, I do not
>think there is an issue with jtags so much as with using
>the flat TAGS namespace to find class (etc) definitions
>in the hierarchical Java package namespace.
>
>I have included below a little example of a general
>problem. There is a class "Buffer" in each of the packages
>"sub1" and "sub2". When the TAGS file is built, they
>are both tagged as "Buffer", with no particularly useful
>qualification as to the package of which they are part.
>If I am in the "use2.java" file and I try to do "M-." on
>the word "Buffer", it will take me to the definition of
>the class "Buffer" in package "sub1" (presumably because
>it comes first in the TAGS file), even though the file is
>using the "Buffer" class in the package "sub2".
>
I should have looked at the doc for find-tag before I replied. You can
cycle through all the matches in the tags table by using a prefix argument
to find-tag. Thus, for the JDK 1.2.2 source,
M-. Hashtable
finds the declaration of the Hashtable class. Then
C-u M-.
finds the constructor. Subsequent prefixed commands cycle through various
methods that return Hashtable and finally you get back to the class
declaration.
I believe in my old job somebody bound the prefixed find-tag command to M-,
keystrokes. So you could do
M-. Hashtable
M-,
M-,
to cycle through all the hits for Hashtable in the TAGS table.
>I thought the idea of making a function similar to
>"jde-help-class", which "for an unqualified class name,
>[tests] for existence of the class in each package imported
>into the current source file", such that "if the class
>exists in more than one package, it lets you choose which
>one you really want."
>
>I thought it made sense that "the same functionality could
>be extended to jumping to the source file that defines
>the class."
>
>
Yes, this is implemented in the latest beta release.
- Paul
