lmao probably don't use this your computer may explode
.travis.yml | ||
caller.go | ||
cap.go | ||
client_test.go | ||
client.go | ||
conn.go | ||
contants.go | ||
ctcp_test.go | ||
ctcp.go | ||
doc.go | ||
event_test.go | ||
event.go | ||
format_test.go | ||
format.go | ||
handlers.go | ||
LICENSE | ||
README.md | ||
source_test.go | ||
source.go | ||
state.go |
girc is a flexible IRC library for Go
Features
- Focuses on simplicity, yet tries to still be flexible
- Only requires standard packages
- Event based triggering/responses
- Documentation is mostly on par
- At this time, expect breaking changes to occur frequently.
TODO
- IRCv3 spec -- details:
- ensure types
User
andChannel
don't have any unexported fields, and that when they are given publically, it's not a pointer to internal state - track with
NAMES
as well? would require rewrite of user existance logic, could also help track user modes - write more function-specific examples as the api becomes much more stable
- client should support ping tracking (sending
PING
's to the server)- with this, we can potentially find lag.
Client.Lag()
would be useful - allow support for changing the frequency of this?
- with this, we can potentially find lag.
- users need to be exposed in state somehow (other than
GetChannels()
) MODE
tracking on a per-channel basisClient.AddTmpCallback()
for one time use callbacks?- add option to enable PRIVMSG/NOTICE text wrapping (and maybe per-default?) (
Config.DisableResponseWrap
?) - optional flood toggle which uses
EventLimiter
so the user doesn't have to implement it themselves? - allow users to supply a custom
VERSION
for the CTCP reply so they don't have to implement their own CTCPVERSION
handler? - allow support for proxy URLs (passing to
golang.org/x/net/proxy
?) - allow users to specify a local/bind address using
net.Dialer{}.LocalAddr
- add more generic helpers:
Away()
,Invite()
,Kick()
,Oper()
, genericPing()
andPong()
,VHost()
,Whois()
andWho()
Installing
$ go get -u github.com/lrstanley/girc
Examples
See the examples within the documentation for real-world usecases.
Contributing
Below are a few guidelines if you would like to contribute. Keep the code clean, standardized, and much of the quality should match Golang's standard library and common idioms.
- Always test using the latest Go version.
- Always use
gofmt
before committing anything. - Always have proper documentation before committing.
- Keep the same whitespacing, documentation, and newline format as the rest of the project.
- Only use 3rd party libraries if necessary. If only a small portion of the library is needed, simply rewrite it within the library to prevent useless imports.
- Also see golang/go/wiki/CodeReviewComments
License
The MIT License (MIT); Copyright (c) Liam Stanley <me@liamstanley.io>