| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
Previously running /thread with a message id for a thread reply (or
pressing T on the message in cursor mode, which is the same thing) would
open a buffer with just the thread reply. Now the thread buffer for the
thread the message is in is opened instead.
|
|
|
|
|
|
|
|
|
| |
If a reaction has more than 50 users, the list of users will be cropped
to just 50 users. This made the counts wrong since we used the number of
users rather than the count property. Fix it by using the count property
instead and adding "and others" to the list of users if
show_reaction_nicks is enabled (the same as the Slack client shows when
you hover over the reaction).
|
|
|
|
| |
Fixes #912
|
|
|
|
|
|
|
|
| |
I tried to do a fix for this in commit 6478c141, but it only fixed
normal text, not e.g. code blocks and attachments. With this I think it
should be correct everywhere.
Fixes #908
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Slack documentation claims that the “ts” flag on attachments
is “An integer Unix timestamp”. However, evidently it can be in
milliseconds (i.e., a timestamp multiplied by 1000), causing
out-of-range exceptions when trying to feed them to date.fromtimestamp().
This can cause all messages after such attachments to just vanish,
as if they were never there, as parsing stops.
Accept both; as a heuristic, the Slack web interface seems to use
100000000000 as a threshold, so we do the same and divide by 1000
if so.
Co-authored-by: Steinar H. Gunderson <steinar+git@gunderson.no>
|
|
|
|
|
| |
It already marks it as read when `/input set_unread_current_buffer` is
run, but this command was replaced with `/buffer set unread` in WeeChat 3.8.
|
|
|
|
|
|
|
|
|
| |
Only subscribed threads can be marked as read. This means that if we
open other threads, they will be opened every time you reload wee-slack
which is impractical and annoying. Previously, any thread with a
highlight (in WeeChat, not necessarily a Slack highlight) was opened.
Fixes #803, fixes #830
|
|
|
|
|
|
| |
This fixes a regression in commit 74da303 which caused certain messages
to include the bold/italic/strikethrough characters (but not the color
attributes) even though the style should not be active.
|
| |
|
| |
|
|
|
|
|
|
|
| |
When you're invited to a new channel, it's useful that it shows up in
the hotlist so you notice it. Previously it would not do that until a
message was posted to the channel after you joined. Now the join message
itself will also be added to the hotlist.
|
|
|
|
|
|
| |
If someone invited you to a private channel, it wouldn't work because
the channel would be unknown to wee-slack and the join function didn't
create a new channel instance.
|
|
|
|
|
|
|
| |
In commit 6478c14 the block rendering was changed to escape `<` and `>`.
However, this caused links and refs in normal (not rich_text) blocks to
be shown as refs instead of rendered correctly. The correct behavior is
to not process refs in rich_text blocks, but do it in normal blocks.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 74da30342e8d328fc085d2158e37afda3b908f2c added support for using
rich_text blocks to format messages. With this change, the use of
replace_string_with_emoji() for text type "emoji" can result in running
the replacement twice as replace_string_with_emoji() is also called as
one of the last steps in SlackMessage.render().
This works fine in the default case when render_emoji_as_string = "",
however render_emoji_as_string = "both" results in output like:
😄 (😄 (:smile:))
instead of the intended:
😄 (:smile:)
This excludes blocks rendered earlier in the method from the second
call of replace_string_with_emoji().
|
|
|
|
| |
Slack began to require this for xoxc tokens today.
|
|
|
|
| |
Fixes #900
|
|
|
|
|
|
|
| |
This fixes a regression in commit 74da303 which caused < and > to be
removed from messages. Escaping them in unfurl_block_element so they can
be unescaped later isn't the nicest fix, but it's the easiest so I'll do
it this way until this is rewritten in the new version.
|
|
|
|
|
| |
After using blocks to render messages in commit 74da303, huddle
messages got the text twice since they already used blocks.
|
| |
|
|
|
|
|
|
|
|
|
| |
This caused some nicks and bots to be colored as offline if the option
weechat.look.color_nick_offline was enabled because not all nicks and
bots are included in the nicklist. Revert this for now, and see if we
can bring it back later.
This reverts commit 7310fe88d6fbf94d1bda7c10f24fa9e396d80311.
|
|
|
|
|
| |
This option wasn't accounted for when the message rendering was changed
to using blocks in commit 74da303.
|
| |
|
|
|
|
| |
Fixes #550 properly.
|
|
|
|
|
|
|
| |
When a Slack message is linked and unfurled (previewed) the footer
previously contained the channel name for the message, but now it just
says "Slack Conversation" or "Thread in Slack Conversation" instead.
This brings back display of the channel name.
|
|
|
|
|
|
|
|
| |
The commit 74da303 introduced a regression with messages not being shown
as deleted anymore because deleting only changed the text field, and
that's not being used anymore with that commit.
Fixes #897
|
|
|
|
|
| |
For some reason these errors were not reported by flake8 before version
6.1.0.
|
|
|
|
|
| |
It can be difficult to find a specific channel if there are thousands
of them in your slack workspace. This enhancement allows you to
filter the channels based on a regular expression.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of just using the text field of a message, use the rich_text
blocks to format the message.
The main reason for doing this was that messages that include images
suddenly started just having "This message contains interactive
elements." in the text field.
There are some other benefits as well:
- It fixes some bugs with multiple formatting styles not being applied
correctly.
- It fixes links in code blocks not being rendered verbatim (but with
text and url, like outside code blocks).
- It fixes code blocks sometimes having newlines after/before ``` and
sometimes not, depending on how the message was sent.
It looks like messages with images are now back to having the proper
text in the text field (for new messages), so this change isn't
necessary to fix that after all (except for for messages in the history
sent in the last couple of days), but since it fixes other issues as
well, it's best to keep it.
There is one bug left when inline code blocks contains links. Then there
will be ` characters before and after the link, which shouldn't be
there, but I'll leave fixing this for later.
Fixes #354, fixes #550, fixes #893
|
|
|
|
| |
Not sure if this ever occurs, but better safe than sorry.
|
|
|
|
| |
Fixes #888
|
|
|
|
| |
Fixes #889
|
| |
|
|
|
|
|
|
| |
Automatically set completion_default_template on wee-slack buffers, so
emojis and usergroups can be tab completed without having to set
weechat.completion.default_template manually.
|
|
|
|
|
|
|
|
|
| |
If the line isn't found, line_pointer becomes an empty string which will
crash WeeChat when it's used with hdata_update. This happened when the
history for a channel that contained a reply also posted to the channel
was loaded, because in that case wee-slack tries to modify the parent
message before the channel history is printed, so it couldn't find the
line.
|
|
|
|
|
|
|
|
|
|
| |
Since WeeChat now has multiline support, the problems with using
prefix_nick_<color> (mainly that it isn't possible to distinguish
between a multiline message and multiple messages when
weechat.look.prefix_same_nick is set) isn't present anymore, so we can
use this tag to properly mark lines as chat messages from a nick. This
also means that we don't have to use prefix_same_nick or
nick_prefix/suffix ourselves anymore.
|
|
|
|
|
|
|
|
|
| |
Since WeeChat now has multiline support, the whole message is in one
chat line. This means that we don't need to look for all the lines
belonging to a message and modify them, we can just modify the line for
the message directly. This has the benefit of making it possible to
increase and decrease the number of lines for a message, rather than
having to join extra lines or get blank lines.
|
|
|
|
|
|
| |
Don't insert a prefix at the start of each line of a message so it
renders normally in WeeChat 4.0.0 which supports chat lines with
multiple lines.
|
|
|
|
|
|
|
|
|
| |
Without spaces, WeeChat will consider all the nicks as one word, which
means that rather than wrapping between nicks, it will fill the whole
line and wrap in the middle of nicks. Additionally, if you have disabled
weechat.look.align_multiline_words it will start from the beginning of
the line when wrapping, rather than after the prefix, which doesn't look
nice.
|
|
|
|
|
| |
Remove a space before a colon and add a comma after a sentence starting
with if.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The url_private link for Slack posts just downloads a json of the post,
which isn't very useful to click on. The permalink goes to the web view
for a post, which is what we want. The web client adds origin_team and
origin_channel, which makes the post page show info about where the post
is shared, so add that here as well.
We still want to use url_private for images etc., not permalink there as
well, because that links to the Slack client with the image shown in the
sidebar, which is much more inconvenient than just getting the image
directly.
|
|
|
|
|
|
|
|
| |
If a link preview was added by an app, like GitHub, instead of directly
by Slack, it was not detected by wee-slack as a link preview, so it
would be shown even if link_previews was set to false.
Fixes #834
|
|
|
|
|
|
|
|
|
|
|
| |
One user experiences receiving a "HTTP/1.1 200 Connection established"
header block before a "HTTP/2 200" header block with the headers. I'm
not sure why specifically this happens, but I know a similar response
will happen if redirects are followed.
This wasn't supported by the http_check_ratelimited function which
splits the header from the body. It now splits out all the header blocks
from the body and uses the status and headers from the last one.
|
|
|
|
| |
Fixes #871
|
|
|
|
|
| |
This is only required for WeeChat < 1.5, and we require >= 2.2, so
there's no point in keeping this.
|