111475 - (ignore) Missing /ignore command

Status: VERIFIED FIXED

(Other Applications :: ChatZilla, defect)

Description

[Håkan Waara]

I'd like to have a command to ignore people on IRC. /ignore is the widely used
standard command for this feature, AFAIK.

Comment 1

[DaTTa]

What's going on with this?

Comment 2

[Andrei Boros]

Subscribe to the request for /ignore.
(spammers on IRC are very annoying and very persistent)

Comment 3

[Koike Kazuhiko]

This kind of command is necessary, but it seems there's no standard.

/ignore [on|off] nickname

Is this enough?

Comment 4

[Garth Wallace]

That'd probably be sufficient. Some clients provide more features (for example,
ignoring only PMs, only channel text, only CTCPs, etc.) but that sort of thing
could be added later.

Comment 5

[Robert Ginda]

I'd prefer /ignore <nickname> on|off, so that we have the ability to take more
parameters later.

Comment 6

[Koike Kazuhiko]

Attachment: patch v1

(1) I can't write help message, because I'm not a native English speaker.
I need help.

(2) I'd found "ignore <nick> <on|off>" isn't consistent with stalk/unstalk.
Should it be ignore/unignore?

Comment 7

[James Ross]

I'm going to have a go at adapting Koike Kazuhiko's patch for the new command
manager.

Comment 8

[James Ross]

--> me, patch soon. :)

Comment 9

[James Ross]

Attachment: CVS diff -u of /extensions/irc

This patch adds two commands, /ignore [<mask>] and /unignore <mask>. These
manipulate the ignoreList on a network, and support full hostmasks as well as
simple nicknames.

When a message comes in, if it has a user as a source, it is checked against a
cache of hostmasks, and if it's not in the list, it's checked against the
actual ignore list. This means each source hostmask is only checked once (until
the ignore list is changed), which improves the speed since the checking of the
hostmask is quite complicated.

Messages of type PRIVMSG and NOTICE are dropped here, but all others are let
throught, but if needed, can be ignored if e.ignored is true (e.g. for mode
changes it could just not show the message, but still keep track of the actual
change internally).

Comment 10

[Robert Ginda]

Looks great, a few comments:

Why the big try/catch in onRawData?  What's going to raise an error?  Maybe the
try/catch can be made smaller.  With a block that size, it's easy to make a
mistake when changing the routine, and not notice a new, unexpected exception.

makeRegExpSafe... didn't we do something like that for the stalk list, too? 
This could probably move into utils.js, and return a RegExp object instead of a
converted string.  I'd suggest that "?" should translate to ".", and "*" should
become ".*", so that the effect matches what users would expect from a blob search.

As a general rule, I usually put nested functions at the top of the the
enclosing function, before any code in the function, as opposed to defining them
in a block buried later on in the function.  Also, ending nested functions with
a ";" aftert he final "}" makes emacs happier wrt magic indenting.

I'd lean twords seeing the "if (e.ignored) return" type logic move into
handlers.js, so that we could do the actual ignoring with css at some point. 
The would let users retroactively ignore/unignore.  The downside is that we
might need more if (e.ignored) checks.  Like, should we log an ignored message?
 Probably not, I guess.

I don't like how commands.js needs to clear the cache either (I see your FIXME
comment in there.)  How about irc networks (servers?, nah, probably networks)
get a .ignore() and a .unignore method instead, and let all the smarts live
there?  It would be nice to cache the mask RegExp objects on the network too, so
we don't have to build three regexps for each message that comes in.

Comment 11

[James Ross]

Attachment: Patch v3.

This patch is an update of attachement 131263, and should basically cover all
the points in comment 10.

There are a couple of other changes, such as putting ^ and $ into the RegExps,
and using the case-insensitive option. It also does not keep RegExp objects for
items in the mask that are just "*", it stores null instead - this reduces
memory usage, and saves a call or two to .match in the matching code.

I have left the ignoring of PRIVMSG and NOTICE messages where they were,
because I feel ignoring should as early as possible. Other messages could be
ignored later, like NICK for example.

Note: this diff is made from CVS, it won't apply to the latest version from
hacksrus.com, due to diff being rather bad at picking lines. It should only be
the cmdIgnore hunk that has problems, though, and can be patched manually.

Comment 12

[nemo]

Regarding doing the ignore with CSS.
Wouldn't that still result in wasted buffer space and log space?
If you're ignoring someone for flooding, or just being too talkative, that'd be
inconvenient.

Comment 13

[Robert Ginda]

Comment on attachment 136500 [details] [diff] [review]
Patch v3.

yeah, that looks about right ;)  r=rginda

Comment 14

[James Ross]

Comment on attachment 136500 [details] [diff] [review]
Patch v3.

Checked in, and in XPI 0.9.58 on website.

Comment 15

[Lion-O]

after so many years... why isn't this part of chatzilla already?
why does the user need to install a patch (if he even knows how to do that) in-addition to installing chatzilla in-order to not get bothered with spam?