Open Bug 432648 Opened 12 years ago Updated 9 years ago

Add a new alias syntax for ChatZilla, with the ability to find a nick's hostmark.

Categories

(Other Applications :: ChatZilla, enhancement)

enhancement
Not set

Tracking

(Not tracked)

People

(Reporter: Thehelpfulonewiki, Assigned: rginda)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
Build Identifier: 0.9.82

Hi there,

I would like to request a new alias syntax for ChatZilla. Currently, banning a user will ban their hostmark/ip address. Therefore, I would like the same to be able to  be applied for quieting users. To create this, I suggest 2 options, a) Create a /quiet command which will quiet a user, so if /ban hello bans hello@example.1234 then /quiet hello will quiet the hostmark of hello@example.1234.

However, if you are unable to create this first option, or can create this, can you also create an additional alias syntax... which could be in the form of $(host)? This would then, if an alias called "q = mode +q $(host)" was created, then if a nick such as "hello" was used in form of the host, it would be able to access that nick's particular hostmark and quiet/ban that.

Thanks for all your creation in advance!

I hope to hear from your soon and see this implemented in a new version of ChatZilla. You guys have done a good job with this, now please make it even better!

Reproducible: Always

Steps to Reproduce:
Feature request - N/A
Actual Results:  
Feature request - N/A

Expected Results:  
Feature request - N/A

Feature request - N/A
changing to all
OS: Windows XP → All
Hardware: PC → All
I'm generally against providing more replacements for aliases, lest we get people wanting conditions/loops/etc. as well, which we really don't want to be implementing.

However, how standard (by IRC standards) is the +q usermode for 'quiet'? If it's reasonably standard (and doesn't mean significantly different things on different servers) adding /quiet and /unquiet would be fine.

(I'll note that banning people will silence them on most servers, but presumably 'quiet' doesn't stop them joining like a ban does. I'm actually not sure what the point of 'quiet' is...)
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
A quiet allows a user to join a channel, but not to talk in the channel.
Can you explain why you think the 'quiet' usermode is useful?

Mitch, did you mean to mark this bug as ASSIGNED but not reassign it to yourself? (Bugzilla's workflow is a little odd - you have to reassign to yourself first if you want to take a bug.)
I meant to self-assign this bug.

"Quiet" usermode lets the user listen, possibly to reasons why they were "quietened", without receiving a full-on ban from channel re-entry.
Assignee: rginda → mitch_1_2
Status: ASSIGNED → NEW
(In reply to comment #4)
> Can you explain why you think the 'quiet' usermode is useful?
> Mitch, did you mean to mark this bug as ASSIGNED but not reassign it to
> yourself? (Bugzilla's workflow is a little odd - you have to reassign to
> yourself first if you want to take a bug.)


A "Quiet" usermode is useful in channels where you want to allow users to join the channels but not to actually speak in the channel. What you said in comment 2 was correct, regarding that "'quiet' doesn't stop them joining like a ban does", it just stops them from talking in the channel.
I'm not against implementing /quiet, but I am curious how this is useful - I don't see much difference between quiet and ban or, if you quiet most of the channel, between quiet and moderation (channel mode +m where people need voice, +v, or better, to talk).

On a somewhat spearate angle, what networks/servers include this quiet feature?
Freenode supports quiet with "+q mask" (and adds q to CHANMODES in the 005), Unreal supports it with "+b ~q:mask" (and has an EXTBAN item).
I had a look around myself about just thye +q mode and found three explanations on how it works - but all different (they were all for different networks).

Implementing a /quiet command is simply not possible in this situation.
(In reply to comment #9)
> I had a look around myself about just thye +q mode and found three explanations
> on how it works - but all different (they were all for different networks).
> 
> Implementing a /quiet command is simply not possible in this situation.
> 

OK then, can you simply create $(mask) which enables the user to get the hostmark of the nick? So, as I had explained, if mask = say $(mask) and "hello" was entered for $(mask) could hello's mask be obtained through that syntax?
(In reply to comment #10)
> (In reply to comment #9)
> > I had a look around myself about just thye +q mode and found three explanations
> > on how it works - but all different (they were all for different networks).
> > 
> > Implementing a /quiet command is simply not possible in this situation.
> > 
> 
> OK then, can you simply create $(mask) which enables the user to get the
> hostmark of the nick? So, as I had explained, if mask = say $(mask) and "hello"
> was entered for $(mask) could hello's mask be obtained through that syntax?
> 

That doesn't match how any of the other aliases work, though. They either refer to a numeric parameter (eg. $(1)) or to something that is implicit in the context of where the command is run (eg. $(recip)) and doesn't require any parameters. What you're asking for is, in effect, some kind of operator which also requires you to give a parameter.

Using the existing variable syntax for something that's not a variable, but in effect an implicit operator on a variable (which you don't specify!) is not a good idea. The behaviour of your proposal would be undefined if you give more than one parameter (of which parameter is it going to try to get the hostmask?).

Doing a proper syntax of such an operator is going to be tricky. Probably something like $(mask[$(1)]). Which is so ugly that I, for one, am not convinced we should be implementing it. Might as well just tell people to use a script. Aliases were never meant to be all-powerful.

I think I'm going to vote for WONTFIX in this case.
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > I had a look around myself about just thye +q mode and found three explanations
> > > on how it works - but all different (they were all for different networks).
> > > 
> > > Implementing a /quiet command is simply not possible in this situation.
> > > 
> > 
> > OK then, can you simply create $(mask) which enables the user to get the
> > hostmark of the nick? So, as I had explained, if mask = say $(mask) and "hello"
> > was entered for $(mask) could hello's mask be obtained through that syntax?
> > 
> 
> That doesn't match how any of the other aliases work, though. They either refer
> to a numeric parameter (eg. $(1)) or to something that is implicit in the
> context of where the command is run (eg. $(recip)) and doesn't require any
> parameters. What you're asking for is, in effect, some kind of operator which
> also requires you to give a parameter.
> 
> Using the existing variable syntax for something that's not a variable, but in
> effect an implicit operator on a variable (which you don't specify!) is not a
> good idea. The behaviour of your proposal would be undefined if you give more
> than one parameter (of which parameter is it going to try to get the
> hostmask?).
> 
> Doing a proper syntax of such an operator is going to be tricky. Probably
> something like $(mask[$(1)]). Which is so ugly that I, for one, am not
> convinced we should be implementing it. Might as well just tell people to use a
> script. Aliases were never meant to be all-powerful.
> 
> I think I'm going to vote for WONTFIX in this case.
> 

OK, fine with that - do you know of anywhere I could obtain such as script? 
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > (In reply to comment #9)
> > > > I had a look around myself about just thye +q mode and found three explanations
> > > > on how it works - but all different (they were all for different networks).
> > > > 
> > > > Implementing a /quiet command is simply not possible in this situation.
> > > > 
> > > 
> > > OK then, can you simply create $(mask) which enables the user to get the
> > > hostmark of the nick? So, as I had explained, if mask = say $(mask) and "hello"
> > > was entered for $(mask) could hello's mask be obtained through that syntax?
> > > 
> > 
> > That doesn't match how any of the other aliases work, though. They either refer
> > to a numeric parameter (eg. $(1)) or to something that is implicit in the
> > context of where the command is run (eg. $(recip)) and doesn't require any
> > parameters. What you're asking for is, in effect, some kind of operator which
> > also requires you to give a parameter.
> > 
> > Using the existing variable syntax for something that's not a variable, but in
> > effect an implicit operator on a variable (which you don't specify!) is not a
> > good idea. The behaviour of your proposal would be undefined if you give more
> > than one parameter (of which parameter is it going to try to get the
> > hostmask?).
> > 
> > Doing a proper syntax of such an operator is going to be tricky. Probably
> > something like $(mask[$(1)]). Which is so ugly that I, for one, am not
> > convinced we should be implementing it. Might as well just tell people to use a
> > script. Aliases were never meant to be all-powerful.
> > 
> > I think I'm going to vote for WONTFIX in this case.
> > 
> 
> OK, fine with that - do you know of anywhere I could obtain such as script? 
> 

For the ChatZilla developers: I found a script that enabled me to do this, so you can close this request. Just FYI, the lines of the script that allows this to be done is: 

                        // Mute a user from the channel - Freenode specific.
                        [ "mute" , cmdMuteuser , CMD_CONSOLE | CMD_NO_HELP | CMD_NEED_CHAN  , "<nick>"          ],

  /* Mute a user with mode +q (to quiet the uesr).
		 Usage: /mute <nickname>
	*/
	function cmdMuteuser(e)
	{
    
    // Firstly, op yourself.
    dispatch("quote chanserv op " + e.channel.unicodeName + " " + e.server.me.unicodeName);
    
    // Mute the user.
    dispatch("quote mode " + e.channel.unicodeName + " -ov+q " + e.nick + " " + e.nick + " *!*@" + e.channel.users[e.server.toLowerCase(e.nick)].host);
    
	}

I hope think that this is what is applied to banning users - anyway's thanks for your comments!
Whats wrong with something like:

$(function(params))

where params is n, n+, n-m or all?

This is simple enough to be used and readable, but unique enough to be noticably different from the other alias replacements.

the list of available callback functions could even be made user extensible (or just keep it somewhere simple like client.aliasCallbacks so plugins and the like can modify it easily.
(In reply to comment #14)
> Whats wrong with something like:
> 
> $(function(params))
> 
> where params is n, n+, n-m or all?
> 
> This is simple enough to be used and readable, but unique enough to be
> noticably different from the other alias replacements.
> 
> the list of available callback functions could even be made user extensible (or
> just keep it somewhere simple like client.aliasCallbacks so plugins and the
> like can modify it easily.

Well, for one thing retrieving the hostmask may be asynchronous (we do not know it in all cases, hence the data manager proposal which I believe atm we still don't have?). So it wouldn't really solve all the problems, and for another I find it extends the functions of aliases to such an extent that people might as well write scripts, as was done in this case (see other comments).
Assignee: mitchell.field → rginda
You need to log in before you can comment on or make changes to this bug.