which sends the set events to the application explicitly if set
to TRUE. Default action should be FALSE.i
+Sun Oct 20 19:54:55 EEST 2002 Pekka Riikonen <priikone@silcnet.org>
+
+ * Added 'send_events' boolean argument to the function
+ silc_schedule_set_listen_fd which sends the set events to
+ the application explicitly if set to TRUE. Default action
+ should be FALSE. Affected file lib/silcutil/silcschedule.[ch],
+ lib/silcclient/client_internal.h and silcd/server_internal.h.
+
Sun Oct 20 14:12:24 CEST 2002 Pekka Riikonen <priikone@silcnet.org>
* Merged with irssi.org CVS.
Sun Oct 20 14:12:24 CEST 2002 Pekka Riikonen <priikone@silcnet.org>
* Merged with irssi.org CVS.
FAQ
Q: Why doesn't irssi display colors even when ircii etc. displays them?
FAQ
Q: Why doesn't irssi display colors even when ircii etc. displays them?
-A: They force ANSI colors even if terminal doesn't support them. By
- default, irssi uses colors only if terminfo/termcap so says. The
- correct way to fix this would be to change your TERM environment to a
- value where colors work, like xterm-color or color_xterm (eg.
- TERM=xterm-color irssi). If this doesn't help, then use the evil way
+A: They force ANSI colors even if terminal doesn't support them. By
+ default, irssi uses colors only if terminfo/termcap so says. The
+ correct way to fix this would be to change your TERM environment to a
+ value where colors work, like xterm-color or color_xterm (eg.
+ TERM=xterm-color irssi). If this doesn't help, then use the evil way
of /SET term_force_colors ON.
Q: How do I easily write text to channel that starts with '/' character?
of /SET term_force_colors ON.
Q: How do I easily write text to channel that starts with '/' character?
Q: Why doesn't irssi update my realname (or whatever) after I change it with
/SET realname and reconnect with /RECONNECT or /SERVER?
Q: Why doesn't irssi update my realname (or whatever) after I change it with
/SET realname and reconnect with /RECONNECT or /SERVER?
-A: Irssi is trying to be too smart. This will be fixed in future, but
+A: Irssi is trying to be too smart. This will be fixed in future, but
for now you should use /DISCONNECT and /CONNECT.
Q: I connected to some server which isn't responding but now irssi tries to
connect back to it all the time! How can I stop it?
for now you should use /DISCONNECT and /CONNECT.
Q: I connected to some server which isn't responding but now irssi tries to
connect back to it all the time! How can I stop it?
-A: Two ways. The "good way" to do it is with /DISCONNECT. Check the
- server tags first with /SERVER without giving it any parameters,
- reconnections are those that have tag starting with "recon" text. So
+A: Two ways. The "good way" to do it is with /DISCONNECT. Check the
+ server tags first with /SERVER without giving it any parameters,
+ reconnections are those that have tag starting with "recon" text. So
most probably you're going to do /DISCONNECT recon-1. The other way is
to remove all the reconnections with /RMRECONNS, easier but may remove
most probably you're going to do /DISCONNECT recon-1. The other way is
to remove all the reconnections with /RMRECONNS, easier but may remove
- some connections you actually wanted to reconnect (if you used
+ some connections you actually wanted to reconnect (if you used
multiple servers..).
Q: How do I add seconds to timestamp?
multiple servers..).
Q: How do I add seconds to timestamp?
Q: Why does irssi say "Irssi: Channel not fully synchronized yet, try again
after a while" when I try to use /BAN etc?
Q: Why does irssi say "Irssi: Channel not fully synchronized yet, try again
after a while" when I try to use /BAN etc?
-A: Possibly a bug in irssi, or ircd you're using does something that
- irssi didn't really notice. The new code should make this happen far
- less often than before, but one known reason for this is when irssi
- doesn't notice that you were unable to join some channel. Currently
+A: Possibly a bug in irssi, or ircd you're using does something that
+ irssi didn't really notice. The new code should make this happen far
+ less often than before, but one known reason for this is when irssi
+ doesn't notice that you were unable to join some channel. Currently
however I don't know of any such events irssi doesn't know about.
however I don't know of any such events irssi doesn't know about.
- Anyway, if this does happen, do /RAWLOG SAVE ~/rawlog soon after
- joining to channel, and either try to figure out yourself why irssi
- didn't get reply to WHO request, or send the whole log to
- cras@irssi.org. Note that the rawlog is by default only 200 lines and
+ Anyway, if this does happen, do /RAWLOG SAVE ~/rawlog soon after
+ joining to channel, and either try to figure out yourself why irssi
+ didn't get reply to WHO request, or send the whole log to
+ cras@irssi.org. Note that the rawlog is by default only 200 lines and
it may not be enough to show all needed information, so you might want
to do /SET rawlog_lines 1000 or so.
it may not be enough to show all needed information, so you might want
to do /SET rawlog_lines 1000 or so.
A: Read http://irssi.org/?page=about
Q: How do I autorejoin channels after being kicked?
A: Read http://irssi.org/?page=about
Q: How do I autorejoin channels after being kicked?
-A: That's evil and you shouldn't do it. If you get kicked, you should
- stay out, at least until the channel forgot you existed :) Most
- channels I've joined just ban you if you autorejoin after kick. If
- you're joined to channels who kick people for fun, try changing
+A: That's evil and you shouldn't do it. If you get kicked, you should
+ stay out, at least until the channel forgot you existed :) Most
+ channels I've joined just ban you if you autorejoin after kick. If
+ you're joined to channels who kick people for fun, try changing
- Anyway, if you REALLY want to do that, and you understand that you're
- doing evilness, you can use the autorejoin.pl script that comes with
- irssi. You'll still need to specify the channels you wish to rejoin
+ Anyway, if you REALLY want to do that, and you understand that you're
+ doing evilness, you can use the autorejoin.pl script that comes with
+ irssi. You'll still need to specify the channels you wish to rejoin
with /SET autorejoin_channels #chan1 #chan2 ...
Q: How do I announce that I'm away/back in all channels I've joined? Or how
do I change my nick when setting myself away/back?
with /SET autorejoin_channels #chan1 #chan2 ...
Q: How do I announce that I'm away/back in all channels I've joined? Or how
do I change my nick when setting myself away/back?
-A: That's even worse than autorejoin. Who could possibly care every
- time you come and go? Many channels will kick you for using this, and
- I for example have added several ignores so I'd never need to see
- these messages. Learn to use /AWAY command properly and tell it's
- existence to people who don't know about it. /WII yournick shows your
+A: That's even worse than autorejoin. Who could possibly care every
+ time you come and go? Many channels will kick you for using this, and
+ I for example have added several ignores so I'd never need to see
+ these messages. Learn to use /AWAY command properly and tell it's
+ existence to people who don't know about it. /WII yournick shows your
away reason much better for people who actually want to know if you're
there or not.
away reason much better for people who actually want to know if you're
there or not.
- You can script these behaviours if you really wish to of course. But
- currently there's no public scripts for either of these, and the only
- way I'm going to add such to irssi.org is if the script contains a
+ You can script these behaviours if you really wish to of course. But
+ currently there's no public scripts for either of these, and the only
+ way I'm going to add such to irssi.org is if the script contains a
setting to specify which specific channels the announcement is sent.
Q: Why does irssi autojoin on invite by default?
setting to specify which specific channels the announcement is sent.
Q: Why does irssi autojoin on invite by default?
-A: The setting is /SET join_auto_chans_on_invite - it's not the same
+A: The setting is /SET join_auto_chans_on_invite - it's not the same
as regular autojoin-on-invite, which irssi doesn't even have. The only
as regular autojoin-on-invite, which irssi doesn't even have. The only
- channels that are joined on invite, are the ones you've added to
- config with /CHANNEL ADD -auto. This is very useful with +i channels
- when you need to first send an invite request to bot, or if you get
- accidentally kicked from channel, the kicker can invite you back
+ channels that are joined on invite, are the ones you've added to
+ config with /CHANNEL ADD -auto. This is very useful with +i channels
+ when you need to first send an invite request to bot, or if you get
+ accidentally kicked from channel, the kicker can invite you back
- I don't see any bad side effects with this feature, so it's ON by
+ I don't see any bad side effects with this feature, so it's ON by
default. I guess someone could start kicking/inviting you all the time
default. I guess someone could start kicking/inviting you all the time
- but server connection shouldn't drop because of that, and you
+ but server connection shouldn't drop because of that, and you
shouldn't join channels whose operators are that evil.
Q: How to make UTF-8 support work with irssi?
A: xterm -u8, screen -U, /SET term_type utf-8
Q: Will there be /DETACH-like feature?
shouldn't join channels whose operators are that evil.
Q: How to make UTF-8 support work with irssi?
A: xterm -u8, screen -U, /SET term_type utf-8
Q: Will there be /DETACH-like feature?
-A: Maybe. Detach code already is there, attach is just missing :) But
+A: Maybe. Detach code already is there, attach is just missing :) But
I don't have much interest in coding it, and screen works just fine so
why bother?
Q: How do I run scripts automatically at startup?
I don't have much interest in coding it, and screen works just fine so
why bother?
Q: How do I run scripts automatically at startup?
-A: Put them into ~/.irssi/scripts/autorun/ directory. Or better would
- be if you placed them in ~/.irssi/scripts/ and created symlinks to
- autorun directory (eg. cd ~/.irssi/scripts/autorun/ ; ln -s
+A: Put them into ~/.irssi/scripts/autorun/ directory. Or better would
+ be if you placed them in ~/.irssi/scripts/ and created symlinks to
+ autorun directory (eg. cd ~/.irssi/scripts/autorun/ ; ln -s
-
-Q: How do I easily edit existing topic?
-A: /TOPIC <tab>
-
-Q: How can I have /WHOIS replies to active window?
-A: Currently there's no other way than to close the status window, or
- at least do /WINDOW LEVEL -CRAP in it, but that would make a lot other
- messages show up in active window too. I don't have many good ideas
- how this could be easily fixed inside irssi (no, kludging it to only
- work with whois isn't a "fix") - it'd be possible to create a script
- do this though but currently it doesn't exist.
SILC_TASK_PRI_NORMAL); \
} while(0)
SILC_TASK_PRI_NORMAL); \
} while(0)
-#define SILC_SET_CONNECTION_FOR_INPUT(s, fd) \
-do { \
- silc_schedule_set_listen_fd((s), (fd), SILC_TASK_READ); \
+#define SILC_SET_CONNECTION_FOR_INPUT(s, fd) \
+do { \
+ silc_schedule_set_listen_fd((s), (fd), SILC_TASK_READ, FALSE); \
-#define SILC_SET_CONNECTION_FOR_OUTPUT(s, fd) \
-do { \
- silc_schedule_set_listen_fd((s), (fd), (SILC_TASK_READ | SILC_TASK_WRITE)); \
+#define SILC_SET_CONNECTION_FOR_OUTPUT(s, fd) \
+do { \
+ silc_schedule_set_listen_fd((s), (fd), (SILC_TASK_READ | SILC_TASK_WRITE), \
+ FALSE); \
} while(0)
#define SILC_OPER_STATS_UPDATE(c, type, mod) \
} while(0)
#define SILC_OPER_STATS_UPDATE(c, type, mod) \
(void *)ctx, 0, 0,
SILC_TASK_FD,
SILC_TASK_PRI_NORMAL);
(void *)ctx, 0, 0,
SILC_TASK_FD,
SILC_TASK_PRI_NORMAL);
- silc_schedule_set_listen_fd(ctx->client->schedule, sock, SILC_TASK_WRITE);
+ silc_schedule_set_listen_fd(ctx->client->schedule, sock, SILC_TASK_WRITE,
+ FALSE);
(void *)ctx, 0, 0,
SILC_TASK_FD,
SILC_TASK_PRI_NORMAL);
(void *)ctx, 0, 0,
SILC_TASK_FD,
SILC_TASK_PRI_NORMAL);
- silc_schedule_set_listen_fd(ctx->client->schedule, sock, SILC_TASK_WRITE);
+ silc_schedule_set_listen_fd(ctx->client->schedule, sock, SILC_TASK_WRITE,
+ FALSE);
ctx->sock = sock;
return sock;
}
ctx->sock = sock;
return sock;
}
SILC_TASK_PRI_NORMAL); \
} while(0)
SILC_TASK_PRI_NORMAL); \
} while(0)
-#define SILC_CLIENT_SET_CONNECTION_FOR_INPUT(s, fd) \
-do { \
- silc_schedule_set_listen_fd((s), (fd), SILC_TASK_READ); \
+#define SILC_CLIENT_SET_CONNECTION_FOR_INPUT(s, fd) \
+do { \
+ silc_schedule_set_listen_fd((s), (fd), SILC_TASK_READ, FALSE); \
-#define SILC_CLIENT_SET_CONNECTION_FOR_OUTPUT(s, fd) \
-do { \
- silc_schedule_set_listen_fd((s), (fd), (SILC_TASK_READ | \
- SILC_TASK_WRITE)); \
+#define SILC_CLIENT_SET_CONNECTION_FOR_OUTPUT(s, fd) \
+do { \
+ silc_schedule_set_listen_fd((s), (fd), (SILC_TASK_READ | \
+ SILC_TASK_WRITE), FALSE); \
} while(0)
/* Finds socket connection object by file descriptor */
} while(0)
/* Finds socket connection object by file descriptor */
(void *)ctx, 0, 0,
SILC_TASK_FD,
SILC_TASK_PRI_NORMAL);
(void *)ctx, 0, 0,
SILC_TASK_FD,
SILC_TASK_PRI_NORMAL);
- silc_schedule_set_listen_fd(ctx->client->schedule, sock, SILC_TASK_WRITE);
+ silc_schedule_set_listen_fd(ctx->client->schedule, sock, SILC_TASK_WRITE,
+ FALSE);
return;
silc_schedule_set_listen_fd(client->schedule, sock->sock,
return;
silc_schedule_set_listen_fd(client->schedule, sock->sock,
- (SILC_TASK_READ | SILC_TASK_WRITE));
+ (SILC_TASK_READ | SILC_TASK_WRITE), FALSE);
SILC_SET_OUTBUF_PENDING(sock);
}
SILC_SET_OUTBUF_PENDING(sock);
}
- silc_schedule_set_listen_fd(client->schedule, fd, SILC_TASK_READ);
+ silc_schedule_set_listen_fd(client->schedule, fd, SILC_TASK_READ, FALSE);
SILC_UNSET_OUTBUF_PENDING(sock);
silc_buffer_clear(sock->outbuf);
return;
SILC_UNSET_OUTBUF_PENDING(sock);
silc_buffer_clear(sock->outbuf);
return;
return;
silc_schedule_set_listen_fd(server->schedule, sock->sock,
return;
silc_schedule_set_listen_fd(server->schedule, sock->sock,
- (SILC_TASK_READ | SILC_TASK_WRITE));
+ (SILC_TASK_READ | SILC_TASK_WRITE), FALSE);
SILC_SET_OUTBUF_PENDING(sock);
}
SILC_SET_OUTBUF_PENDING(sock);
}
- silc_schedule_set_listen_fd(server->schedule, fd, SILC_TASK_READ);
+ silc_schedule_set_listen_fd(server->schedule, fd, SILC_TASK_READ, FALSE);
SILC_UNSET_OUTBUF_PENDING(sock);
silc_buffer_clear(sock->outbuf);
return;
SILC_UNSET_OUTBUF_PENDING(sock);
silc_buffer_clear(sock->outbuf);
return;
/* Add the fd to be listened, the task found now applies to this
fd as well. */
/* Add the fd to be listened, the task found now applies to this
fd as well. */
- silc_schedule_set_listen_fd(schedule, fd, SILC_TASK_READ);
+ silc_schedule_set_listen_fd(schedule, fd, SILC_TASK_READ, FALSE);
/* If the task is non-timeout task we have to tell the scheduler that we
would like to have these tasks scheduled at some odd distant future. */
if (type != SILC_TASK_TIMEOUT)
/* If the task is non-timeout task we have to tell the scheduler that we
would like to have these tasks scheduled at some odd distant future. */
if (type != SILC_TASK_TIMEOUT)
- silc_schedule_set_listen_fd(schedule, fd, SILC_TASK_READ);
+ silc_schedule_set_listen_fd(schedule, fd, SILC_TASK_READ, FALSE);
silc_mutex_lock(queue->lock);
silc_mutex_lock(queue->lock);
call this directly if wanted. This can be called multiple times for
one file descriptor to set different iomasks. */
call this directly if wanted. This can be called multiple times for
one file descriptor to set different iomasks. */
-void silc_schedule_set_listen_fd(SilcSchedule schedule,
- SilcUInt32 fd, SilcTaskEvent iomask)
+void silc_schedule_set_listen_fd(SilcSchedule schedule, SilcUInt32 fd,
+ SilcTaskEvent mask, bool send_events)
{
int i;
bool found = FALSE;
{
int i;
bool found = FALSE;
for (i = 0; i < schedule->max_fd; i++)
if (schedule->fd_list[i].fd == fd) {
schedule->fd_list[i].fd = fd;
for (i = 0; i < schedule->max_fd; i++)
if (schedule->fd_list[i].fd == fd) {
schedule->fd_list[i].fd = fd;
- schedule->fd_list[i].events = iomask;
+ schedule->fd_list[i].events = mask;
if (i > schedule->last_fd)
schedule->last_fd = i;
found = TRUE;
if (i > schedule->last_fd)
schedule->last_fd = i;
found = TRUE;
+ if (send_events) {
+ schedule->fd_list[i].revents = mask;
+ silc_schedule_dispatch_nontimeout(schedule);
+ }
for (i = 0; i < schedule->max_fd; i++)
if (schedule->fd_list[i].events == 0) {
schedule->fd_list[i].fd = fd;
for (i = 0; i < schedule->max_fd; i++)
if (schedule->fd_list[i].events == 0) {
schedule->fd_list[i].fd = fd;
- schedule->fd_list[i].events = iomask;
+ schedule->fd_list[i].events = mask;
if (i > schedule->last_fd)
schedule->last_fd = i;
if (i > schedule->last_fd)
schedule->last_fd = i;
+ if (send_events) {
+ schedule->fd_list[i].revents = mask;
+ silc_schedule_dispatch_nontimeout(schedule);
+ }
* SYNOPSIS
*
* void silc_schedule_set_listen_fd(SilcSchedule schedule, SilcUInt32 fd,
* SYNOPSIS
*
* void silc_schedule_set_listen_fd(SilcSchedule schedule, SilcUInt32 fd,
+ * SilcTaskEvent mask, bool send_events);
* whenever you need to change the events. This can be called multiple
* times to change the events.
*
* whenever you need to change the events. This can be called multiple
* times to change the events.
*
+ * If the `send_events' is TRUE then this function sends the events
+ * in `mask' to the application. If FALSE then they are sent only
+ * after the event occurs in reality. In normal cases the `send_events'
+ * is set to FALSE.
+ *
***/
void silc_schedule_set_listen_fd(SilcSchedule schedule, SilcUInt32 fd,
***/
void silc_schedule_set_listen_fd(SilcSchedule schedule, SilcUInt32 fd,
+ SilcTaskEvent mask, bool send_events);
/****f* silcutil/SilcScheduleAPI/silc_schedule_unset_listen_fd
*
/****f* silcutil/SilcScheduleAPI/silc_schedule_unset_listen_fd
*
projects / crypto.git / commitdiff