Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add support for XMPP URI in the link matcher #83

Open
GoogleCodeExporter opened this issue Apr 18, 2015 · 3 comments
Open

Add support for XMPP URI in the link matcher #83

GoogleCodeExporter opened this issue Apr 18, 2015 · 3 comments
Labels
auto-migrated Priority-Medium Type-Enhancement

Comments

@GoogleCodeExporter
Copy link 

When I try to include XMPP URI in the markup like this:
[test xmpp:username@example.com?message]

I get the following html code generated:
<A HREF="mailto:username@example.com?message">username@example.com?message</A>

whereas the expected output is
<A HREF="xmpp:username@example.com?message">test</A> 


txt2tags version 2.5 <http://txt2tags.sf.net>
Ubuntu 10.10 package Version: 2.5-2


Additional information about XMPP:
"xmpp" URI scheme is IANA assigned URI scheme for Jabber/XMPP instant messaging 
protocol:
http://www.iana.org/assignments/uri-schemes.html
http://tools.ietf.org/html/rfc5122

The primary identifier of a user of this protocol, called JID (Jabber 
Identifier), looks very similar to email: username@jabber-server.example.com
This identifies him as user 'username' at server 'jabber-server.example.com' 
(xmpp network is distributed).


But nevertheless, I suppose e-mail regexes in txt2tags should be fixed to not 
try to search e-mails inside link markup.


------
Regards,
max ulidtko

Original issue reported on code.google.com by ulid...@gmail.com on 20 Nov 2010 at 7:24
@GoogleCodeExporter
Copy link
Author 

it would make sense to include the special xmpp protocol into txt2tags (since 
it's open source and a new standard). 

As a temporary workaround, you can use this preproc rule into your document 
header:

%!preproc(html): '\[([^ ].*?) xmpp:([^ ].*?)@([^ ].*?)\]' ''<A 
HREF="xmpp:\2@\3">\1</A>''

(I've also copied it to http://wiki.txt2tags.org/index.php/Main/Tips#toc6 )


Strangely, I tried this first, but it doesn't work:

%!preproc: '\[([^ ].*?) xmpp:([^ ].*?)@([^ ].*?)\]' '[\1 xmpp:\2@@AROBASE@@\3]' 

%!postproc: '@@AROBASE@@' '@'

the first preproc is converted to [test xmpp:username@example.com?message], 
without expending the link as expected because it is a preproc...

Original comment by eforg...@gmail.com on 20 Nov 2010 at 10:16

@GoogleCodeExporter
Copy link
Author 

actually, since i had no requirement of generalization, i used much simpler 
workaround:

%!postproc: MY_JID user@domain
%!postproc: MY_XMPP_URI xmpp:user@domain?message

[MY_JID MY_XMPP_URI]

:-)


But i can imagine other circumstances where one could encounter the same 
pitfall. This could be, for example, an url of svn repository like 
svn+ssh://username@host.example.net/repo-root/trunk
And similar patterns are not so uncommon. So i suggest to rather restrain the 
email matching pattern to not trigger inside link markup, just to be safe.

Original comment by ulid...@gmail.com on 20 Nov 2010 at 10:54

@GoogleCodeExporter
Copy link
Author 

Hi Max,

You found a bug in the link matcher code, I've opened issue 89 to handle that. 
Thanks for the report!

About you solution with postprocs, it's the cleaner and preferred in those 
cases where funky URLs are needed. I don't want txt2tags to match every 
possible URL scheme out there, because than the possibilities of false 
positives are high. Postprocs are there to help in this specific cases.

Thanks for the info about XMPP. It seems to be a popular protocol and we can 
consider to include it in the URL matcher. Eric already supported this adding 
in comment 1. I'll leave this issue opened for opinions.

Original comment by aureliojargas@gmail.com on 24 Nov 2010 at 10:18

  • Changed title: Add support for XMPP URI in the link matcher
  • Added labels: Type-Enhancement
  • Removed labels: Type-Defect

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
auto-migrated Priority-Medium Type-Enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@GoogleCodeExporter