| Commit message (Collapse) | Author | Age | Lines |
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The set account for control channels is now a comma separeted list of
accounts instead of just one. If the user changes the tag of an accounts
trough `account <id> set tag <new_tag>`, the account set will be updated
to reflect this change for all relevant channels. If an account is
removed trough `account <id> delete` it will be removed from the account
set for all relevant channels.
|
| |
| |
| |
| | |
This reverts commit 56fd7212a75237669de37589fc18e2e02444b3d2.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The set account for control channels is now a comma separeted list of
accounts instead of just one. If the user changes the tag of an accounts
trough `account <id> set tag <new_tag>`, the account set will be updated
to reflect this change for all relevant channels. If an account is
removed trough `account <id> delete` it will be removed from the account
set for all relevant channels.
|
| |
| |
| |
| | |
This reverts commit e9352b3581c2493bec222a259d71a072ac24b762.
|
| |
| |
| |
| | |
This reverts commit 8ad3c8517ecb1d9ac7cf04236f8634c16b9adde0.
|
| |
| |
| |
| | |
This reverts commit d3e3c73a4b194e666fb3a5f59a0badf6eba292ff.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
| |
It only affects irc->user and irc->root, and this was calling it for
everyone.
|
|
|
|
|
|
|
| |
Fixes trac ticket 1108: https://bugs.bitlbee.org/bitlbee/ticket/1108
I would have ignored that ticket (it's about some sort of legacy
migration) but the fix sounds like a sane thing to do
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes issues like getting a blank window with a channel that the
irc client thinks the user is in but bitlbee doesn't.
The error is sent either by returning NULL in the chat_join prpl
function, or by calling imcb_chat_free() before the user is added to the
channel.
This wasn't possible before since purple returned NULL in its chat_join,
which resulted in other bugs too. Since that's fixed, I can finally
apply this, which has been in my stash for a very long while.
|
|
|
|
|
|
|
|
|
| |
We can't actually have multiple prefixes internally, so the only thing
missing for multi-prefix compliance is actually having the prefix in the
WHO reply, which is a rfc1459 thing.
Note to future self: check irc logs for the implementation I threw away.
The one that actually handled multiple prefixes. I hope that's useful.
|
|
|
|
|
|
|
|
|
|
| |
First fallback to ASCII without TRANSLIT, and if that fails too, just
give up by returning NULL.
Basically the same thing as 3a27896 (a netbsd specific fix), but for
channel names. This wasn't needed before because the older version of
this code caught the NULL from the ASCII//TRANSLIT attempt and gave up
immediately, while the refactored version lacked null checking.
|
|
|
|
| |
jgeboski was trying to solve. #1221 for details.
|
|
|
|
| |
Fixes the test suite. I guess it's useful for something.
|
|
|
|
| |
Also split underscore_dedupe from nick_dedupe.
|
|
|
|
|
|
|
| |
Used uncrustify, with the configuration file in ./doc/uncrustify.cfg
Commit author set to "Indent <please@skip.me>" so that it's easier to
skip while doing git blame.
|
|
|
|
|
|
|
|
|
|
|
| |
With similar commands being supported, such as INVITE, the KICK command
should be supported as well. The key motivation behind supporting KICK
is having for having a way to remove users from group chats. As of now,
there is no way for a bitlbee user to remove a user from a group chat.
With no current KICK implementation, it made using this command a prime
candidate for the UI side of this implementation. In addition, the KICK
command has been supported in the control channel as well. This is to
keep the INVITE/KICK pair consistent.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows for users to be declared as being special, which does not
have any specific meaning. The meaning of being special is different
from protocol-to-protocol, which many protocols do not even implement.
This functionality is mainly geared towards a special user state which
only some protocols may actually need to define. For example, with the
third-party Steam plugin, this can be used for denoting a user which is
actively playing a game.
By default, this mode will not actually be used by any plugin. However,
it does default to the half-operator user mode.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the auto_join channel flag set to false, the channel is still
auto-joined. This can lead to the channel being "doubly" joined if
a client previously sent a channel join request. The result of being
"doubly" joined is really undefined, but most notably memory leaks
can occur.
It also appears, based on the comment under the modified condition,
the previous condition was incorrect.
Another patch should probably implement some sort of check to ensure a
channel is not already joined, assuming the auto_join flag is enabled.
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes warnings about passing signed chars to them (apparently they
are implemented as macros that do array lookups without checks in some
platforms, yay)
Specifically:
functions=isalnum|isalpha|isdigit|isspace|isxdigit|tolower|toupper
sed -ir "s/$functions/g_ascii_&/g" **/*.c
|
| |
|
|
|
|
|
|
| |
fix is ugly as it's putting a detail relevant to XML storage elsewhere in
the code. But I don't think we should have any other storage formats anyway.
|
|
|
|
|
|
|
| |
my copyright mentions since some were getting pretty stale. Left files not
touched since before 2012 alone so that this change doesn't touch almost
EVERY source file.
|
|
|
|
|
|
| |
separate control channel with all contacts *not* in a certain group/from
a certain IM account/network, etc.
|
|
|
|
|
|
|
| |
for example when the user gets invited to a channel that already exists.
Separately, I should handle invites like that better. Will file a bug for
that.
|
|
|
|
|
|
|
| |
channel-chatroom reference when leaving a chatroom. This fixes two very
similar crash bugs when leaving a chatroom within the paste_buffer_delay
period.
|
|
|
|
|
| |
a user's message in, instead of just &bitlbee by default.
|
|
|
|
|
| |
bug and preventing a generally confusing and undesirable setup.
|
|
|
|
|
|
|
|
|
|
| |
BitlBee used by a user, and if it looks like s/he hasn't used this one
before, show a list of new features that may be interesting.
Since I don't think im.bitlbee.org users will read any changelogs ever,
this is probably not a bad idea. If you hate it, the following command
should get rid of it forever: set last_version 9999999
|
|
|
|
|
| |
in the current channel.
|
| |
|
|
|
|
|
| |
the last_channel variable, like for any other user.
|
| |
|
|
|
|
|
| |
attribute, not as a setting (since all accounts have it anyway).
|
| |
|
|
|
|
|
|
| |
show_offline and away_devoice and possibly other ideas into one setting
called show_users. Documentation will come soon. :-P
|
|
|
|
|
|
| |
only triggers on channels created by the user. (And not at identify time,
which was causing odd problems on my test setup.)
|
|
|
|
|
| |
what the older version also did so that Irssi won't clean up the window.
|
|
|
|
|
| |
groupchats not reimplemented yet but that's the next step.
|
|
|
|
|
| |
pointless at that stage and may cause crashes.
|
|
|
|
|
| |
channel if the user isn't in it.
|
|
|
|
|
| |
name.
|
|
|
|
|
|
| |
If someone has two MSN accts and wants contacts from both in one channel,
this is now possible.
|