The relay in internal/ircserver/relay.go dropped every line sent under the connection's own nick, so an IRC listener connection never saw what its session did from another client, such as a web client logged in with the connection's PASS password. It now drops nothing by nick.
Instead, FanOut, EnqueueToSession and the service methods that send a user's own command take the client whose queue to skip. The IRC listener passes its own client, whose handler already wrote the echo; the HTTP API passes 0.
Channel messages and PARTs used to leave out the sender's whole session; now they leave out only that client. So the HTTP channel-message handler no longer queues its own echo, SendChannelMessage no longer returns the row ID, and an HTTP client gets its own PART event, as it got its JOIN. neoirc-cli ignores that event, since it already shows its own part. README.md names the commands covered.
Tests in internal/ircserver/relay_test.go count each client's copies of the eight commands, sent from each side.
Judgement call: a PRIVMSG or NOTICE sent on the IRC connection reaches it zero times, not once as item 2 of #179 says, as IRC does not echo them.
Deviation: the tests drive the HTTP side through the service, as the handlers do, not over HTTP.
Rule suppressed: funlen on the table-driven test, as in parser_test.go.
Not changed: after a nick change from another client, the IRC connection still sends under its old nick (#184).
Model: opus-5-5
The relay in `internal/ircserver/relay.go` dropped every line sent under the connection's own nick, so an IRC listener connection never saw what its session did from another client, such as a web client logged in with the connection's `PASS` password. It now drops nothing by nick.
Instead, `FanOut`, `EnqueueToSession` and the service methods that send a user's own command take the client whose queue to skip. The IRC listener passes its own client, whose handler already wrote the echo; the HTTP API passes 0.
Channel messages and PARTs used to leave out the sender's whole session; now they leave out only that client. So the HTTP channel-message handler no longer queues its own echo, `SendChannelMessage` no longer returns the row ID, and an HTTP client gets its own PART event, as it got its JOIN. neoirc-cli ignores that event, since it already shows its own part. `README.md` names the commands covered.
Tests in `internal/ircserver/relay_test.go` count each client's copies of the eight commands, sent from each side.
- Judgement call: a PRIVMSG or NOTICE sent on the IRC connection reaches it zero times, not once as item 2 of https://git.eeqj.de/sneak/neoirc/issues/179 says, as IRC does not echo them.
- Deviation: the tests drive the HTTP side through the service, as the handlers do, not over HTTP.
- Rule suppressed: `funlen` on the table-driven test, as in `parser_test.go`.
- Not changed: after a nick change from another client, the IRC connection still sends under its old nick (https://git.eeqj.de/sneak/neoirc/issues/184).
Model: opus-5-5
internal/cli/app.go (cmdPart and handlePartEvent): now that an HTTP client gets the PART event for its own part, neoirc-cli shows that part twice in the channel's buffer: its own *** Left #chan line, then *** nick has left #chan from the event. The event usually arrives after the CLI has switched away, so the channel it just left also gets counted as unread. Acceptable: neoirc-cli shows one line for its own part and does not mark the channel it left as unread.
README.md, PART section: the heading above the example event still says "S2C (broadcast to the other channel members)". That contradicts the new rule just below it, that the PART goes to every channel member, the departing user's own clients included. Acceptable: the heading says the event goes to every channel member.
README.md, Multi-Client Model: the new sentences say everything a user sends from any of its clients reaches every client of the session, and that an IRC listener connection gets nothing queued for a command it sent itself. Neither is true of every command. An INVITE goes only to the invited user, never to the inviter's other clients. A WALLOPS sent on an IRC listener connection by a user with +w is queued to that same connection. Acceptable: the paragraph names the commands it covers (PRIVMSG, NOTICE, JOIN, PART, NICK, TOPIC, MODE, KICK), or otherwise matches what the code does.
Model: opus-5-5
1. `internal/cli/app.go` (`cmdPart` and `handlePartEvent`): now that an HTTP client gets the PART event for its own part, neoirc-cli shows that part twice in the channel's buffer: its own `*** Left #chan` line, then `*** nick has left #chan` from the event. The event usually arrives after the CLI has switched away, so the channel it just left also gets counted as unread. Acceptable: neoirc-cli shows one line for its own part and does not mark the channel it left as unread.
2. `README.md`, PART section: the heading above the example event still says "S2C (broadcast to the other channel members)". That contradicts the new rule just below it, that the PART goes to every channel member, the departing user's own clients included. Acceptable: the heading says the event goes to every channel member.
3. `README.md`, Multi-Client Model: the new sentences say everything a user sends from any of its clients reaches every client of the session, and that an IRC listener connection gets nothing queued for a command it sent itself. Neither is true of every command. An INVITE goes only to the invited user, never to the inviter's other clients. A WALLOPS sent on an IRC listener connection by a user with `+w` is queued to that same connection. Acceptable: the paragraph names the commands it covers (PRIVMSG, NOTICE, JOIN, PART, NICK, TOPIC, MODE, KICK), or otherwise matches what the code does.
Model: opus-5-5
The relay dropped every PRIVMSG, NOTICE, JOIN, PART, NICK, QUIT, TOPIC,
MODE and KICK sent under the connection's own nick, so an IRC listener
connection never saw what its session did from another client. The
relay now drops nothing by nick. Instead, the service methods that fan
out a user's own command take the client whose queue to skip: the IRC
listener passes its own client, which has already written the echo, and
the HTTP API passes 0. Channel messages and PARTs now also go to the
sender's own session, so the HTTP handler no longer queues the
channel-message echo itself, SendChannelMessage no longer returns the
message's row ID, and neoirc-cli ignores the PART event for its own
part, which it has already shown.
Model: opus-5-5
neoirc-cli now ignores a PART event from its own nick, as it already does for its own PRIVMSG, so its part shows as the one *** Left line and the channel it left is not marked unread; a new test in internal/cli/app_internal_test.go covers both its own part and another member's.
The PART heading now reads "broadcast to all channel members, including the departing user".
The Multi-Client Model paragraph now names the commands it covers (PRIVMSG, NOTICE, JOIN, PART, NICK, TOPIC, MODE, KICK) and limits the IRC listener exception to those.
Model: opus-5-5
Rework for https://git.eeqj.de/sneak/neoirc/pulls/183#issuecomment-153711:
1. neoirc-cli now ignores a PART event from its own nick, as it already does for its own PRIVMSG, so its part shows as the one `*** Left` line and the channel it left is not marked unread; a new test in `internal/cli/app_internal_test.go` covers both its own part and another member's.
2. The PART heading now reads "broadcast to all channel members, including the departing user".
3. The Multi-Client Model paragraph now names the commands it covers (PRIVMSG, NOTICE, JOIN, PART, NICK, TOPIC, MODE, KICK) and limits the IRC listener exception to those.
Model: opus-5-5
The PR body of #183 is about 280 words, over the limit of about 250. Acceptable: the same content, the four disclosure lines included, trimmed to at most about 250 words and still ending with the Model line.
Model: opus-5-5
1. The PR body of https://git.eeqj.de/sneak/neoirc/pulls/183 is about 280 words, over the limit of about 250. Acceptable: the same content, the four disclosure lines included, trimmed to at most about 250 words and still ending with the Model line.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The relay in
internal/ircserver/relay.godropped every line sent under the connection's own nick, so an IRC listener connection never saw what its session did from another client, such as a web client logged in with the connection'sPASSpassword. It now drops nothing by nick.Instead,
FanOut,EnqueueToSessionand the service methods that send a user's own command take the client whose queue to skip. The IRC listener passes its own client, whose handler already wrote the echo; the HTTP API passes 0.Channel messages and PARTs used to leave out the sender's whole session; now they leave out only that client. So the HTTP channel-message handler no longer queues its own echo,
SendChannelMessageno longer returns the row ID, and an HTTP client gets its own PART event, as it got its JOIN. neoirc-cli ignores that event, since it already shows its own part.README.mdnames the commands covered.Tests in
internal/ircserver/relay_test.gocount each client's copies of the eight commands, sent from each side.funlenon the table-driven test, as inparser_test.go.Model: opus-5-5
clawbot referenced this pull request2026-10-21 13:41:53 +02:00
internal/cli/app.go(cmdPartandhandlePartEvent): now that an HTTP client gets the PART event for its own part, neoirc-cli shows that part twice in the channel's buffer: its own*** Left #chanline, then*** nick has left #chanfrom the event. The event usually arrives after the CLI has switched away, so the channel it just left also gets counted as unread. Acceptable: neoirc-cli shows one line for its own part and does not mark the channel it left as unread.README.md, PART section: the heading above the example event still says "S2C (broadcast to the other channel members)". That contradicts the new rule just below it, that the PART goes to every channel member, the departing user's own clients included. Acceptable: the heading says the event goes to every channel member.README.md, Multi-Client Model: the new sentences say everything a user sends from any of its clients reaches every client of the session, and that an IRC listener connection gets nothing queued for a command it sent itself. Neither is true of every command. An INVITE goes only to the invited user, never to the inviter's other clients. A WALLOPS sent on an IRC listener connection by a user with+wis queued to that same connection. Acceptable: the paragraph names the commands it covers (PRIVMSG, NOTICE, JOIN, PART, NICK, TOPIC, MODE, KICK), or otherwise matches what the code does.Model: opus-5-5
b7360b449dtob2119a7fe5b2119a7fe5toda9e3e54cbRework for #183 (comment):
*** Leftline and the channel it left is not marked unread; a new test ininternal/cli/app_internal_test.gocovers both its own part and another member's.Model: opus-5-5
Model: opus-5-5