| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
Make groups and MPDMs distinguishable by prefix
|
| | |
|
| | |
|
| | |
|
|\ \
| |/
|/| |
Support `/input set unread` and `/input set_unread_current_buffer`
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This hooks into the weechat commands `/input set_unread` and `/input
set_unread_current_buffer` and implements them. For set_unread we
iterate over all the channels and mark them as read. For
set_unread_current_buffer we mark the current buffer as read.
Fixes #323
|
| |
| |
| |
| |
| |
| |
| | |
This changes the signature of mark_read in SlackTeam to match the one in
SlackChannel. This is done so we can call mark_read on all the items in
the list of buffers (which has both teams and channels), without
checking if the items are channels.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The new_messages property is used by mark_read to determine if it should
excecute. When a channel is initially loaded, new_messages is set to
False, and unread_count_display is set to the number of unread messages.
new_messages is not set to True until a new message arrives.
This means that if you call mark_read after loading a channel, but
before a new message has arrived, it won't do anything, even if the
channel had unread messages when it was loaded. By setting new_messages
in set_unread_count_display, this is fixed.
|
|\ \
| | |
| | | |
Ensure that all lines printed to weechat specifies a prefix
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When we print a message with multiple lines to weechat, we want the
nick/prefix to appear on the first line, and no prefix on the subsequent
lines.
When this message is handled by weechat, it processes each line of the
message separately, and applies a prefix for each line. It seems to me
that if the line doesn't contain any tab characters, it should end up
with an empty prefix, and this is what happens for me.
However, some users are having issues where both the prefix and the
message ends up incorrect (issue #274, #385 and #421), which seems to be
related to this.
Additionally, if the message contains a tab character on any of the
lines after the first, the part before the tab character would be the
prefix for that line, which is completely wrong. I haven't seen that
happen, as it seems that slack replaces tab characters with spaces, but
we should handle it correctly nevertheless.
The weechat documentation states that you should use a space followed by
a tab character to disable the prefix. This patch inserts this after
each newline, so the prefix is disabled for each line except the first.
I can't reproduce the issue, so I can't verify if this fixes the issue.
As far as I can see, for me the behavior is the same with this patch.
Hopefully, this fixes #274.
|
| |/
| |
| |
| |
| |
| |
| | |
Separate the code for wrapping a method so arguments and return values
are encoded/decoded into a new method in WeechatWrapper. This allowes us
to use it outside of __getattr__ as well, so we can handle some specific
methods differently.
|
|\ \
| |/
|/| |
Add support for sending multiline messages
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
While weechat plugins like multiline.pl and edit.py allow you to compose
multiline messages, wee-slack normally receives them line by line, so it
ends up as separate messages. There isn't any direct support for
receiving the complete message from weechat, but it can be done with
sort of a workaround.
There is a callback you can hook on to which allows you to intercept and
edit messages before they are sent to the buffer. This callback receives
the complete message with all the lines. By using this we can process
the whole message, and return an empty string from the callback which
means that the message will not be processed further.
Note that when this happens, weechat commands are not processed, which
is why we only use the callback for messages that contain a newline and
does not start with slash. Otherwise, we are returning the string sent
to the callback, which would be the same as the callback not being
hooked in.
I've also opened a PR in weechat for supporting multiline input
properly[0]. If that is merged, that can be used for newer weechat
versions instead of this.
[0]: https://github.com/weechat/weechat/pull/1063
Fixes #118
|
|\ \
| | |
| | | |
When expanding attachments avoid rendering same link multiple times
|
| | | |
|
|\ \ \
| | | |
| | | | |
Print error message when initial connection fails
|
| | | |
| | | |
| | | |
| | | |
| | | | |
No point in keeping commented out code, especially since this code has
never been active.
|
| | | |
| | | |
| | | |
| | | | |
This makes the error case a bit clearer and easier to read.
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | | |
I chose to print this instead of using dbg since it's a rather critical
error message.
Fixes #432
|
|\ \ \
| |/ /
|/| | |
Fix overzealous regex in unfurl_refs
|
| | |
| | |
| | |
| | | |
Signed-off-by: Ben Kelly <btk@google.com>
|
|\ \ \
| | | |
| | | | |
Improve rendering of changes in multiline messages
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If you update a line with hdata_update and pass a string containing
newlines, the buffer will become a bit broken when bare display mode is
activated (alt+l). It seems that the newlines are printed in bare mode,
but extra lines are not inserted, so the lines are overlapping with each
other.
Fixes #306
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Not sure if this can happen. The weechat documentation doesn't state
that it can, but since the if condition was there, maybe it can. If it
can and does happen, abort the modification, which is better than
something unexpected happening.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously, if a multiline message was edited or reacted to, all of the
new message would be crammed into the last line of the already printed
message.
This change updates each line separately, so if the number of lines in
the message doesn't change, the message will still be rendered correctly
after edits or reactions.
If the number of lines change, the rendering is still improved, however
I don't know if it is possible to insert or delete lines in a weechat
buffer without re-rendering the whole buffer, so it won't be perfect. If
the number of lines of a message decreases after an edit, the extra
lines will still be present, but they will be blanked. If the number of
lines increases, the first lines will be set as normally, but the last
line will contain all of the rest of the lines.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Instead of only updating the last line printed with the id of the
message (ts.minor, set in the date_printed field), update all of the
lines that is printed for that message.
This is necessary for updating all of the lines on changes, instead of
only the last. This will be implemented in the next commit.
This assumes that the lines after the first in messages always has an
empty prefix, and that the first line of a message always has a prefix.
This holds for the messages I have seen (single-line, multi-line as well
as me-messages and joins/quits).
Other approaches I considered was to count the number of newlines in the
message and update the same number of lines, or to check the existing
date_printed field of the messages and update the ones that had 10
digits or more (since current timestamps has that, and the slack id
currently has 6 digits). However, I dropped them in favor of the prefix
solution which seems better.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Instead of just checking that bot_id is not None, check that it exists
in the list of bots. This prevents a KeyError when trying to access a
bot that doesn't exist in the list.
This KeyError would happen if you use a reminder. The message from
slackbot then has bot_id B01 which is not in the list of bots from
rtm.start and gives bot_not_found if trying to look it up with the
bots.info API endpoint.
By ignoring the bot_id we fall back to the user/username, which in the
case of reminders is slackbot, so the name appears just as the other
messages from slackbot.
Fixes #420
|
|/ / /
| | |
| | |
| | |
| | |
| | | |
We have to replace the & before we replace < and >, otherwise the & in
< and > are going to be replaced. Additionally, we need to end the
sequences with ; which was missing.
|
|\ \ \ |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
Closes: #315
|
|\| | |
| | | |
| | | | |
Put users in groups according to presence
|
| | | |
| | | |
| | | |
| | | | |
Fixes #398
|
|\ \ \ \
| | | | |
| | | | | |
Fix AttributeError on /slack status in team buffer
|
| | |/ /
| |/| | |
|
|\ \ \ \
| | | | |
| | | | | |
Set correct number of unread messages in hotlist
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
While the commit 6718e2f fixed buffers not appearing in the hotlist,
after it the number of new messages for each buffer was gone. This makes
the number of messages for each buffer shown again.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Fix opening thread buffers
|
| |/ / / / |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Similar syntax as for adding reactions:
3s/foo/bar/
Fixes: #153
|
|/ / / /
| | | |
| | | |
| | | | |
Not sure this actually matters as weechat seemed happy with the wrong return codes too
|
|/ / /
| | |
| | |
| | |
| | | |
Signed-off-by: Ben Kelly <bk@ancilla.ca>
Signed-off-by: Ben Kelly <btk@google.com>
|
|\ \ \
| | | |
| | | | |
Don't send typing notifications for threads, since Slack doesn't like that
|
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: Ben Kelly <btk@google.com>
|
| | | |
| | | |
| | | |
| | | | |
Fixes #80 (again)
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Send * to the current channel.
Fixes: #191
|
| |/ /
|/| | |
|
| | | |
|
| | | |
|