On Fri, Aug 24, 2007, Jeremy Nelson wrote:
> For example, the channel name may be encoded in iso-8859-1 and the
> users may agree to use utf-8. ***so it's fundamentally important
> to be able to specify a different encoding for privmsgs on the channel
> than is used to specify the encoding of t
On Tue, Oct 10, 2006, Jeremy Nelson wrote:
> We will, by default, make all of the above functions, except for
> getopt globglobi
> not support double quoted words. That means, double quoted words have
> no special meaning, and double quotes are considered regular old ch
On Tue, Oct 03, 2006, Misha wrote:
>> There are users depending on EPIC being as closely compatible to ircII
>> as possible. Gratuitous incompatibilities shouldn't be introduced. I
>> believe this kind of change would be a gratuitous incompatibility. /SET
>> REVERSE_STATUS_LINE neither halts EPIC d
On Tue, Oct 03, 2006, Misha wrote:
>> Given that less trivial incompatible changes have been made, have you
>> considered simply dropping support for reverse_status_line and/or
>> taking out the implicit ^V to the status formats?
> Totaly agree, why not just drop this rudiment?
There are users dep
On Wed, Sep 13, 2006, Jeremy Nelson wrote:
> Although all of the builtin functions
> common, diff, sort, numsort, uniq, remws, prefix, match, rmatch,
> userhost, word, remw, insertw, chngw, {r,}{pattern,filter}, copattern,
> corpattern, cofilter, beforew, key, channelmode, revw, shift, pop,
> fi
On Wed, Sep 06, 2006, Jeremy Nelson wrote:
>> [A modest proposal to be able to turn off support for words with spaces]
> It is my personal opinion (as a user, not as a coder) that support for
> words with spaces is important, and that it is undesirable for there not
> to be a single set of rules on
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 f
Hello,
The behaviour of `/on kick' seems different than the rest of channel
hooks and inadequate for some purposes.
The hook is thrown after the KICK command is processed by the client,
which means that in case we're the ones being kicked from the channel,
its data is lost before we're able to re
On Sat, Jun 10, 2006, Kurt Roeckx wrote:
> Some users might also want the option to not send in UTF-8, but I
> don't think we should keep supporting that. Even mIRC now
> supports UTF-8 and should be able to deal with it.
IMO, it would only decrease the epic userbase. For instance, on most
Polish
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 backwar
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
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),
12 matches
Mail list logo
