I'm not sure why there should be an option here, instead of always
inserting the non-qualified name for imported names. There is no
option for inserting fully qualified names in regular Java code
either. IMHO the javadoc code completion should just work the same way
as the code completion in regular Java code.

A related issue is that javadoc code completion currently doesn't
support camel case initials-based code completion, e.g., typing "BAOS"
to complete to "ByteArrayOutputStream" doesn't work in javadoc
context, unlike in regular Java code.

Niklas


On Wed 2018-03-07 at 09:51h, Thomas Kellerer wrote on users:
> I expected that to be an option either in the "Code Completion"
> section or maybe the "Formatter" section for JavaDocs. 
> 
> Btw: The fully qualified path is not necessary in the JavaDocs if
> that class is already imported. The class names in the JavaDocs
> share the same "visibility" rules as regular classes.
> 
> Thomas
> 
> Paul Szudzik schrieb am 06.03.2018 um 18:34:
> > Hopefully this would be an option flag.. Otherwise I wouldn't know
> > if I was overriding something by accident via a library load.. so,
> > I would vote for option check, where if it was CHECKED, would drop
> > the fully qualified class names for base and non-overridden
> > functions..  If I do override a function, then the fully qualified
> > path should show..
> > 
> > Just concerned about this request
> > 
> > 
> > -----Original Message----- From: Thomas Kellerer
> > Sent: Monday, March 05, 2018 11:42 PM
> > To: NetBeans Users
> > Subject: Disabling fully qualified class names in JavDoc completion
> > 
> > When using code-completion in JavaDocs (e.g. for a @see
> > attribute), NetBeans always inserts fully qualifed class names for
> > parameters, e.g.
> > 
> >    @see #someMethod(java.lang.String, java.lang.String)
> > 
> > Is it possible (in 8.2 or 9.0) to disable this, so that the above is 
> > written as:
> > 
> >    @see #someMethod(String, String)
> > 
> > This is not so much a problem with JDK classes, but with our own classes 
> > which tend to have longer package names.
> > 
> > Thomas
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
> > For additional commands, e-mail: users-h...@netbeans.apache.org
> > 
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
> > For additional commands, e-mail: users-h...@netbeans.apache.org
> > 
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: users-h...@netbeans.apache.org
> 
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Reply via email to