Wee-slack: unwanted URL parsing in fenced code blocks

Created on 9 Apr 2018  路  6Comments  路  Source: wee-slack/wee-slack

Hey,

this one made my head scratch a lot:

These code blocks...
img-2018-04-09-081531

..result in:
img-2018-04-09-081519

Notice the unwanted http:// in URL parsing garbage that modifies the code blocks. Those should be transmitted verbatim, not modified. Is this something that Slack screws up? Can wee-slack detect and maybe filter it? Put me on the path of a red herring the other day, while looking at a server log pasted in Slack.

bug

Most helpful comment

Okay, so that's the issue. unfurl_auto_link_display doesn't have any effect when unfurl_ignore_alt_text is set. The reason for that is that they're essentially conflicting settings, so unfurl_ignore_alt_text takes precedence.

When you type something which slack converts to a link, we get back the link and the text you typed, e.g. <http://asd.com|asd.com>. This is also what we receive if an app provide a link, but then the description might be different, e.g. <http://asd.com|some link>. The unfurl_ignore_alt_text is an option to ignore the text and always print the link, while unfurl_auto_link_display is to decide what part is printed if they're equal apart from the protocol. Since you have set it to ignore the description, it will never proceed to checking if the link and description is equal.

Maybe we should change it so unfurl_auto_link_display takes precedence though, since you might want to use that option to prevent slacks auto linking, while still ignoring the description for other links.

All 6 comments

It's slack that makes the text into links, if you hover/click on them in the web client you'll see that they are links there too. However, since we can't show links transparently in the terminal, it becomes this ugly mess.

You can set unfurl_auto_link_display to text to disable this auto-linking, though that will take effect outside of code blocks too.

We should probably not show any links inside code blocks regardless of that setting.

@trygveaa I've tried setting unfurl_auto_link_display to text but it unfortunately doesn't seem to be working. http:// keeps being appended to things looking like a domain.

I've encountered the same kind of issue described above, scratching my head a bit during some debugging.
Not a really dev-friendly feature.

I'm using the latest wee-slack 2.1.1 version, on the latest weechat 2.2 version

@tardypad: Do you have unfurl_ignore_alt_text set to true?

Yes I've changed this one too
https://github.com/tardypad/dotfiles/commit/32603a11e54af78eccccfa3749cdea84e7c74abd

There was an effect with that one as I don't see the "double" link anymore

Okay, so that's the issue. unfurl_auto_link_display doesn't have any effect when unfurl_ignore_alt_text is set. The reason for that is that they're essentially conflicting settings, so unfurl_ignore_alt_text takes precedence.

When you type something which slack converts to a link, we get back the link and the text you typed, e.g. <http://asd.com|asd.com>. This is also what we receive if an app provide a link, but then the description might be different, e.g. <http://asd.com|some link>. The unfurl_ignore_alt_text is an option to ignore the text and always print the link, while unfurl_auto_link_display is to decide what part is printed if they're equal apart from the protocol. Since you have set it to ignore the description, it will never proceed to checking if the link and description is equal.

Maybe we should change it so unfurl_auto_link_display takes precedence though, since you might want to use that option to prevent slacks auto linking, while still ignoring the description for other links.

Ah ok, thanks a lot for the quick answer!
It works fine now.

Those config are indeed quite confusing and difficult to grasp without knowing a bit of those Slack internals (even with the help description within weechat)

As for me, I would ideally have both set together (no protocol appended and no description added)
But for now removing the prefix is more important, I can deal with the extra description text.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

GideonWolfe picture GideonWolfe  路  4Comments

tedwardd picture tedwardd  路  7Comments

BlitzKraft picture BlitzKraft  路  9Comments

neverfox picture neverfox  路  11Comments

chreekat picture chreekat  路  7Comments