Closed abdullah-ishan closed 3 months ago
With your prompt closure, can you confirm that it was resolved? If so, is there anything I could make clearer in the code or docs to avoid this issue for future users?
The issue still persists.
If the issue still persists, why was the issue closed from your side?
I was not sure if it is a bug. So I closed it.
While it might not be a bug in the traditional sense, it is still an issue worth discussing in my eyes - at the minimum we'd have an instance of a lack of documentation (that is, https://kittehorg.github.io/KittehIRCClientLib/8.0.0/org/kitteh/irc/client/library/Client.Builder.html#nick-java.lang.String- would need to include how to define "fallback" nicknames), or a lack of a feature where I'd have to agree might be needed.
On a different note (since we are already discussing documentation), could the online javadocs be built using a newer version of Java? Java 8 does not provide support for a search bar, and I've always felt like it is a necessary feature.
The issue is not about how to define "fallback" nicknames. When KICL connects to a server with a nick and that nick is already in use, no command is sent from the KICL to change the nick automatically by modifying the previously rejected nick. Also "fallback" nick is created when a nick gets rejected according to the implementation of https://kittehorg.github.io/KittehIRCClientLib/8.0.0/org/kitteh/irc/client/library/defaults/listener/DefaultNickRejectedListener.html#nickInUse-org.kitteh.irc.client.library.event.client.ClientReceiveNumericEvent-
Expected behavior If a nick gets rejected by the server, KICL should send a nick change request automatically by modifying the rejected nick(append ` at the end of it).
Actual behavior Nick is not changed because nick change command is not sent to the server.