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
