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] proposal regarding notify_name
hello,
it's my first post, i wanted to share opinions on how to make notify_name
more generally useful and how to make it provide the same (or better)
functionality as other irc clients, like irssi.
irssi, mirc and other clients use different activity levels for CRAP events
(kick, join and such), public message, private message and/or hilight.
storing them in user-made structure would be extremely painful, as
notify_name is a property of a window, user would have to track all window
number changes, /window kills and more.
it's good for the user to distinguish between crap activity level and
hilight, in which the latter is more important.
i think that activity levels should be kept inside the window struct itself,
sticking to it after /window number, and automagically dissapearing after window
kill. i think of it this way:
multiple activity levels with ability to set a different format to each one
of it, for example, four activity level, with 0 being the 'null' format,
making it dissapear from %{1}F.
/set act_level_1 winchan($*) != [] ? [$*:$winchan($*)] : winquery($*) != [] ?
[$*:winquery($*)] : [$*]
additional levels would have different colors, or bold text, or even
different formatting, as the scripter wishes
with the interface to it being:
@ actctl($winnum($chan) SET num)
and
@ actctl($winnum($chan) GET), which would return the value, so user wouldn't
risk overwriting higher level of activity, if he doesn't wish so.
i think it would come in handy to many scripters, as sometimes it's hard to
distinguish between windows with `hilight' messages and ones in which just a
CRAP event occured
and one more thing, act_level_num should behave just like input_prompt,
allowing tertiary operators, as in my example
refnum and refnum alone is the only thing that's really needed for getting
properties of a window, using tertiary operators it shouldn't get too
complicated and (imho) it would be enough for useful things
what do you think about the whole idea? maybe notify_name is good as it is,
maybe creating custom structures of levels isn't a bad idea after all, or
having different activity levels isn't worth coding required to apply it? or
even if it's indeed a good approach, should anything be changed to be more
flexible, intuitive?
regards
--
Stanisław Halik :: http://weirdo.ltd.pl
___
List mailing list
List@epicsol.org
http://epicsol.org/mailman/listinfo/list
