PSA: Please move discussion over to https://issues.apache.org/jira/browse/NETBEANS-447 :)

Thank you,
Gili

On 2018-03-07 9:48 AM, Niklas Matthies wrote:
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



---------------------------------------------------------------------
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