[EPIC] Request for discussion: doubly quoted words
Hello,
I want to discuss doubly quoted words. As you know, words quoted inside
of aren't a special case in the parser, they're just literal s
embedded inside strings.
However, that introduces several deficencies present only by virtue of
having dwords.
No /fe and /for, nor any word-related function except numwords() are
safe for unvalidated data. One might say that these aren't safe for
unvalidated data, but is there any other use for them? Iterating strings
hardcoded in the script?
If you, for instance, store channel ban lists in a word list and a ban
starts with a `' (i.e. [EMAIL PROTECTED]) and another one ends with a `',
too,
when iterating words in the list with /fe or word(), you'll get an
element that contains more than one word.
Same goes for Tab completion. $numwords() doesn't honor doubly quoted
words while word() et al honor them.
There are possibly many other situations where dwords aren't expected
and will cause surprises to unsuspecting scripters.
My proposals (mutually exclusive):
a) Remove dwords from builtin functions and commands completely. This
will set the end of dword pestilence (aka quoting hell), but will
make some people unhappy. I counter by saying that there are other
methods for storing multiword data (e.g. structures, karll's arrays),
but in the current state, dwords, being an edge case, cause word
functions to be unusable.
b) Introduce a way for a function or a command to not honor them at all,
nested functions inheriting this property. For example:
/`fe (foo fine dword bar) i { echo $i; };
yielding:
fine
dword
bar
As opposed to:
/fe (foo fine dword bar) i { echo $i; };
yielding:
fine dword
bar
I recommend the ` character, as it isn't used as an operator in the
Expression Mode.
Objections? Consent?
- nullie
___
List mailing list
List@epicsol.org
http://epicsol.org/mailman/listinfo/list
Re: [EPIC] (important discussion) privmsg in response to a privmsg
Jeremy Nelson [EMAIL PROTECTED] wrote: Since time immemorial, when you are inside of an /on caused by a privmsg (/on msg, /on public*, /on ctcp, etc) and you try to send a PRIVMSG (/msg, /ctcp, /redirect, etc), ircII has always (silently) changed it into a NOTICE. EPIC maintains backwards compatability with ircII in this regard, and changes your PRIVMSGs to NOTICEs because avoiding accidental message loops is one of the responsibilities a client has. While browsing EPIC's home site I found a notice stating that the client's goal is to be more feature-rich while still getting less bloated and overly complicated. Same with that you're just giving tools, as you stated, not the whole product. I may not see any reason for replying to PRIVMSG with another PRIVMSG, but this may cause confusion among ones, who create well-thought innovations by scripting. It's not your responsibility for one's bad creation, you're just giving the tool, ie. the knife. You got the picture. If I were you, I would just remove the code (along with the one preventing replying to NOTICEs) and wash my hands. But it's up to you. regards, -- 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 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
[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
