Re: [EPIC] About changing /exec -out to use /send instead of /say
On Thu, 2005-08-04 at 10:26 -0400, Ben Winslow [EMAIL PROTECTED] wrote: Personally, I think you're not really gaining anything by doing this, but you are losing something in breaking backwards compatibility. Consider that, if you currently want to send /exec to the person you're talking to in a query, you need to do /exec -m querydestination; with the change, if you were talking in a query and wanted output to go to the channel, you'd have to do /exec -m channel instead of /exec -o. Basically, I don't see any net in making the change. it's working more untuitively in all other `major' clients. i know many users who think of epic as a really backward client, coders should try and eliminate all not-so-well-thought features and core functionalities, so more people would consider using epic as a good alternative to irssi or xchat. introducing nonblocking connect() calls was a good idea, but there are many more which may discourage new users and scripters. IMHO it's a good approach to change old and unuseful behaviour in development branch. if it's going to include a change which will break each and every script, making the language in overall more feature-rich and intuitive, it's not really bad. -- Stanisław Halik :: http://weirdo.ltd.pl ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
Re: [EPIC] About changing /exec -out to use /send instead of /say
On Wed, 2005-08-03 at 10:22 -0500, Jeremy Nelson wrote: So many of you know this, so bear with me: /SEND sends a message to the window's current target /SAYsends a message to the window's current channel. If you have a /query going in a window with a channel, the /query overrides the channel as the current target. This is the purpose of /say, to be able to msg a channel in a window where you have a /query going. Historically the /exec -out command has always used the /say command to redirect the output. Recently it has been requested that we switch to using /send so it can be possible to /exec -out to a query. This change will mean if you have a channel and a /query in the same window, then /exec -out will send to the query, and not the channel. Personally, I think you're not really gaining anything by doing this, but you are losing something in breaking backwards compatibility. Consider that, if you currently want to send /exec to the person you're talking to in a query, you need to do /exec -m querydestination; with the change, if you were talking in a query and wanted output to go to the channel, you'd have to do /exec -m channel instead of /exec -o. Basically, I don't see any net in making the change. This seems reasonable enough to me, but it is a break from backwards compatability, so it needs to be discussed and vetted in public. What do you all think? I think that a new /exec flag that uses /send instead of /say might be a better approach. Jeremy -- Ben Winslow [EMAIL PROTECTED] ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
Re: [EPIC] About changing /exec -out to use /send instead of /say
I'm in agreement with Jeremy's original proposal. If you have an open /query, /exec -o should most definitely be going there; not doing so is unintuitive, despite years of common IRC practise. And before someone proposes it: I also strongly object to a /set variable to define the behaviour of /exec -o with an open /query. Not that my word rules above anyone elses, but such a toggleable defeats my entire argument. Changing this in EPIC5 would be OK, but (if you're still working on it) for EPIC4, leave the old behaviour. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. | On Thu, Aug 04, 2005 at 11:57:39AM -0500, Jeremy Nelson wrote: On Wed, 2005-08-03 at 10:22 -0500, Jeremy Nelson wrote: This change will mean if you have a channel and a /query in the same window, then /exec -out will send to the query, and not the channel. Personally, I think you're not really gaining anything by doing this, but you are losing something in breaking backwards compatibility. Consider that, if you currently want to send /exec to the person you're talking to in a query, you need to do /exec -m querydestination; with the change, if you were talking in a query and wanted output to go to the channel, you'd have to do /exec -m channel instead of /exec -o. Basically, I don't see any net in making the change. The way it was explained to me by the person who suggested the change was that it was unexpected that you can't use /exec -o to dump to a query, channel or no channel, and if you did have a channel, typing a message would be sent to the query but /exec -o would be sent to the channel, so they claimed it was a POLA violation on both counts. I pledged to bring this matter up for discussion. So I am not trying to persuade you to accept or reject this proposal, only to get your honest opinion, and I do thank you for being willing to offer it. =) Does anyone else wish to offer their opinion on this before I table it? Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] About changing /exec -out to use /send instead of /say
So many of you know this, so bear with me: /SEND sends a message to the window's current target /SAYsends a message to the window's current channel. If you have a /query going in a window with a channel, the /query overrides the channel as the current target. This is the purpose of /say, to be able to msg a channel in a window where you have a /query going. Historically the /exec -out command has always used the /say command to redirect the output. Recently it has been requested that we switch to using /send so it can be possible to /exec -out to a query. This change will mean if you have a channel and a /query in the same window, then /exec -out will send to the query, and not the channel. This seems reasonable enough to me, but it is a break from backwards compatability, so it needs to be discussed and vetted in public. What do you all think? Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
