-
Notifications
You must be signed in to change notification settings - Fork 681
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
Correctly handle inline channels in messages #128
Conversation
|
What network does that? I might have a better fix for this in mind, will try. |
irc.w3.org :P |
W3C is following this project and strongly contemplating replacing our qwebirc instance |
If you do, might want to consider closing and opening a new PR instead of amending commit to keep change history :-) |
Okay, pushed a proper fix. |
Wouldn't it be better to parse the |
Yes, that's not a terrible idea. #24 |
@@ -48,6 +38,12 @@ function uri(text) { | |||
}); | |||
} | |||
|
|||
function channels(text) { | |||
return text.replace( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you re-add here the comment you deleted below please?
// Channels names are strings (beginning with a '&' or '#' character)
// of length up to 200 characters.
// See https://tools.ietf.org/html/rfc1459#section-1.3
@xPaw, looks nice at first glance, I'll give it a deeper review and an actual test. Could you comment your code a bit, to be nice with future ourselves, please? |
I've pushed a fix to correctly handle characters that cannot be in the channel name before the |
Code looks good to me and it works very well. Also fixes a whole world of broken link parsing so I like it. 👍 |
👍 |
Correctly handle inline channels in messages
This one should be really hard to break/unbreakable. It should be just as complete as the old one and address thelounge#15, thelounge#128, thelounge#129 and possibly various other unexpected breakages. It solves the problem by making it so when a parser matches, it is responsible for recalling the parser with what it allowed to be parsed further.
This one should be really hard to break/unbreakable. It should be just as complete as the old one and address thelounge#15, thelounge#128, thelounge#129 and possibly various other unexpected breakages. It solves the problem by making it so when a parser matches, it is responsible for recalling the parser with what it allowed to be parsed further.
This one should be really hard to break/unbreakable. It should be just as complete as the old one and address thelounge#15, thelounge#128, thelounge#129 and possibly various other unexpected breakages. It solves the problem by making it so when a parser matches, it is responsible for recalling the parser with what it allowed to be parsed further.
This one should be really hard to break/unbreakable. It should be just as complete as the old one and address thelounge#15, thelounge#128, thelounge#129 and possibly various other unexpected breakages. It solves the problem by making it so when a parser matches, it is responsible for recalling the parser with what it allowed to be parsed further.
This one should be really hard to break/unbreakable. It should be just as complete as the old one and address thelounge#15, thelounge#128, thelounge#129 and possibly various other unexpected breakages. It solves the problem by making it so when a parser matches, it is responsible for recalling the parser with what it allowed to be parsed further.
This one should be really hard to break/unbreakable. It should be just as complete as the old one and address thelounge#15, thelounge#128, thelounge#129 and possibly various other unexpected breakages. It solves the problem by making it so when a parser matches, it is responsible for recalling the parser with what it allowed to be parsed further.
Moves inline channel parser into Handlebars, which means it is parsed before parsing colours and links, should fix a couple of parser related bugs.