Paul, thank you for your speedy reply. I agree with your reaction to
(2) below as a stylistic idiosyncrasy. However, I think the case (1)
is a genuine bug, since it is perfectly legal Java syntax to use a fully
qualified class name anywhere (and sometimes you have no choice when
there is ambiguity due to imports).
Thanks for your volunteer work. I would try to fix this myself, but I have
had bad luck with trying to get complicated regexp's to work.
-CR
P.S. Making the regexp builder customizable seems like an easy and
reasonable idea.
> Date: Wed, 19 Apr 2000 11:23:20 -0400
> From: Paul Kinnucan <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset="us-ascii"
>
> At 11:05 AM 4/19/00 -0400, you wrote:
> >In beta23, I believe I have found two bugs in the method tagging
> >expressions:
> >
> >(1) If the return type of a method has a "." in it, that method does not show
> >up in the speedbar method listing. For example, try
> >
> > public Foo.Bar myMethod () {}
> >
> >I use a lot of nested classes, so I seem to be stumbling on places where
> >various patterns assume pre-JDK-1.2 syntax, in which types did not have
> >On the other hand, even in pre-1.2, a fully qualified type name should
> >be allowed anywhere a type is allowed.
> >
>
> I'll look at this. Indexing based on regular expressions is an exercize in
> trading off speed for generality. I can't guarantee that I can find a
> tolerable fix for this requirement.
>
>
> >(2) If the method header definition contains has an inline commen, that method
> >does not show up in the speedbar method listing. For example, try
> >
> > public Foo /* or null */ myMethod () {}
> >
> >I evolved this particular style of comment to highlight the fact that a
> >method may return null. In general, inline comments should be allowed
> >anywhere in the header.
> >
> >Thanks! -CR
>
> This is essentially the same question you asked about font-locking and the
> answer is essentiall the same. My belief, based on fairly extensive
> experience writing regexps, is that trying to accommodate your style would
> slow down indexing substantially. You may be willing to tolerate the
> slowdown but I'm not sure others would. In other words, I'm not inclined to
> tinker with the buffer indexing regular expressions to accommodate
> stylistic idiosyncracies.
>
> If there is enough interest, I could make the function that the JDE uses to
> build the indexing regular expressions customizable. That way, you could
> substitute your own regexp building function.
>
>
> ------------------------------------------------------------
> TECH SUPPORT POLICY
>
> I respond only to requests that contain a complete problem report. The
> easiest way to ensure that your report is complete is to include the output
> of the JDE->Help->Submit Problem Report command in your request.
>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> JDE website: http://sunsite.auc.dk/jde/
>
> JDE mailing list archive:
> http://www.mail-archive.com/[email protected]/maillist.html
>
--
Charles Rich | Mitsubishi Electric Research Laboratory (MERL)
617-621-7507 phone | 201 Broadway
617-621-7550 fax | Cambridge, MA 02139
[EMAIL PROTECTED] | http://www.merl.com
