nylas-mail
nylas-mail copied to clipboard
nylas-mail-lives
The links in the message are not clickable.
The links in the message are not clickable. It is very comfortable instead of copying
I can click URLs and they go to the desired location; can you please elaborate and maybe take screenshots/videos of what you mean?
It’s not a link without http:// or similar starting the url.
On Nov 20, 2017, at 4:00 PM, lutek [email protected] wrote:
I mean links written plain text.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
What version do you have? You can can check in the triple dot menu in the top right. Could also be the URL parsing now only has a list of TLDs instead of a catch all. Not sure if we have the .pl TLD in that list; and if we did, it may be difficult to distinguish a domain name with a file name (.pl is a perl script file extension as well)
Lamixer, yes we can say that's not link by definition but reality is different. Gmail online is dealing with such links. Will be great have the same functionality inside the client.
Seesenuichaelj, latest v2.2.2 (linux version, my os is Elementary OS, based on Ubuntu 16.04)
We actually don't look for http:// in the url parsing. I'm fairly certain this is due to the .pl TLD not being in the list of domains. I would expect your .com URLs being parsed and hyperlinked properly
Ok, that could be a reason. Maybe using this list for TLD domain will be solution: https://www.icann.org/resources/pages/tlds-2012-02-25-en
Ya, the problem is that we used to get anything that looked like a URL, but this would create hyperlinks if someone referenced a file name (i.e. hello.txt would be hyperlinked), so @nirmit changed it to only create hyperlinks for a certain list of TLDs: https://github.com/nylas-mail-lives/nylas-mail/blob/d441e5d2b0aa26173c7eb44b15e1148d672dd05a/packages/client-app/src/regexp-utils.coffee#L42
This is why the .pl domain is not hyperlinked. Unfortunately, .pl is also a file extension. We will need a path forward on how to deal with whether or not it's a file. Would people be against pinging the name to see if it's actually a website? Seems a bit overkill to ping everytime there's a URL
It seems to me that more links are sent than paths to files, from a usability perspective it is better to show a false link than its lack. Nylas mail I use for a few days and the lack of links is from my perspective an element to go back to gmail online.
@dweremeichik @simonft what do you think? I agree not having the hyperlink is pretty bad, and I'm fine with erroneous links if the TLD is also a file extension. Would be nice to know that "/path/to/file.pl" is not a link but "file.pl" can be a link
i think we should use the icann tld list too
@seesemichaelj I think ping would be an overkill and would delay the render. If we all agree, we can bring in the catch-all but that would give us a certain percent failure! let me know and I can add the catch-all to the regex.
Pinging the name to see if it's a website would be a pretty big privacy leak, similar to (though not as bad as) https://www.bleepingcomputer.com/news/security/iterm2-leaks-everything-you-hover-in-your-terminal-via-dns-requests/
Why not use a library that does this? Link detection rules are very hard (think about urls with port numbers, ip addresses), it seems like it would make sense to use someone from someone who has spent time thinking about this a lot already.
Two options: https://alexcorvi.github.io/anchorme.js/ http://soapbox.github.io/linkifyjs/
@seesemichaelj I think that file links should work. Think office environment where someone sends you a link to network resources. If it's a valid link, it is a valid link. Not our problem if the link actually works or not. I checked out the options that @simonft linked. I think https://alexcorvi.github.io/anchorme.js/ looks like the best option.
