-
Notifications
You must be signed in to change notification settings - Fork 152
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
Add mention links extension #171
base: master
Are you sure you want to change the base?
Conversation
Codecov Report
@@ Coverage Diff @@
## master #171 +/- ##
==========================================
+ Coverage 94.33% 94.37% +0.04%
==========================================
Files 3 3
Lines 3088 3112 +24
==========================================
+ Hits 2913 2937 +24
Misses 175 175
Continue to review full report at Codecov.
|
I'm getting a |
I'm no longer getting a segmentation fault. It was something downstream. |
Hello, sorry for the delayed answer. Will take a look in upcoming days, this looks as a something bigger so I don't want to rush this too much. |
Just tried it. Seems to crash more or less with any input containing Here for the input
|
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.
FYI, this is not a full review, take it as just a few cents of what I've just noticed when skimming through the code quickly. I likely won't do anything deeper until you fix the crashing so I can try it more thoroughly to assess it more.
render_mention_link(MD_HTML* r, const MD_SPAN_MENTION_DETAIL* det) | ||
{ | ||
RENDER_VERBATIM(r, "<x-mention data-target=\""); | ||
render_entity(r, det->text, det->size, render_html_escaped); |
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.
Should likely call render_verbatim()
instead. No entity translation should place here I guess.
PUSH_MARK('@', off, index, MD_MARK_RESOLVED); | ||
off = index; | ||
} | ||
else if(line->beg + 1 <= off && ISALNUM(off-1) && |
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.
This condition now should likely explicitly check whether are enabled MD_FLAG_PERMISSIVEEMAILAUTOLINKS
. That was not needed previously because @
was added into the mark_char_map[]
in md_build_mark_char_map()
if and only if that extension was enabled.
MD_SPAN_MENTION_DETAIL det; | ||
if (CH(mark->beg) == '@') | ||
{ | ||
det.text = (char *) ctx->text + mark->beg + 1; | ||
det.size = mark->end - mark->beg - 1; | ||
MD_ENTER_SPAN(MD_SPAN_MENTION, &det); | ||
MD_TEXT(text_type, STR(mark->beg), mark->end - mark->beg); | ||
MD_LEAVE_SPAN(MD_SPAN_MENTION, &det); | ||
break; | ||
} | ||
|
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.
How do you know at this point whether it's a mention link or a permissive e-mail auto-link? Both extensions may be enabled at the same time.
MD_SPAN_U | ||
MD_SPAN_U, | ||
|
||
MD_SPAN_MENTION |
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.
I would prefer renamimg it to MD_SPAN_MENTIONLINK
for the sake of consistency e.g. with MD_SPAN_WIKILINK
etc.
unsigned char size; | ||
MD_CHAR* text; |
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.
I understand it's supposed to contain only a verbatim text (the username) with no possible nested formatting options, yet I wonder whether rather using MD_ATTRIBUTE target
(and initializing it to a single substr_type
of type MD_TEXT_NORMAL
) would not be better, also for the sake of consistency with other detail structures.
@@ -316,6 +324,7 @@ typedef struct MD_SPAN_WIKILINK { | |||
#define MD_FLAG_LATEXMATHSPANS 0x1000 /* Enable $ and $$ containing LaTeX equations. */ | |||
#define MD_FLAG_WIKILINKS 0x2000 /* Enable wiki links extension. */ | |||
#define MD_FLAG_UNDERLINE 0x4000 /* Enable underline extension (and disables '_' for normal emphasis). */ | |||
#define MD_FLAG_MENTIONS 0x8000 /* Enable mention links extension. */ |
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.
Similarly please rename to MD_FLAG_MENTIONLINKS
.
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.
Noticed one more thing.
/* A potential permissive e-mail autolink. */ | ||
if(ch == _T('@')) { | ||
if(line->beg + 1 <= off && ISALNUM(off-1) && | ||
if( (ctx->parser.flags & MD_FLAG_MENTIONS) && (line->beg == off || (CH(off-1) == _T(' '))) ) |
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.
Why only a space? I think any whitespace char would be ok here.
Even maybe some listed (but likely not all) punctuation chars could validly proceed or follow respectivelly. I think things like the following can be common e.g. in a process of any collaborative document writing.
# The Most Important Secret (draft)
The Answer to the Ultimate Question of Life, the Universe, and Everything is 41.
(@zaphod_beeblebrox: Please verify whether it shouldn't be 42)
Or
@alice, @bob and @charlie are sending some packets to @daniel.
if( (ctx->parser.flags & MD_FLAG_MENTIONS) && (line->beg == off || (CH(off-1) == _T(' '))) ) | ||
{ | ||
OFF index = off + 1; | ||
if (index == line->end || CH(index) == ' ') { |
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.
Ditto.
Rebased on the latest master, I'm not getting any errors when running the tests. This is on OS X. I see you're running on Windows. Do any of the checks (Travis CI, codecov, ...) run the test suite? |
Still crashing on Windows. But I can see that if I move the block of lines 4315 - 4318 after that following mention-related I have quite old gcc version on windows, so I can imagine newer compiler versions reorder that code as an optimization because the mention branch block does not depend on those variables and thus hide the bug effectively.
At this time, Travis only (linux) does the tests. Not sure how easy it would be to enable them on AppVeyor (windows) as it requires python but I hope it should be possible. |
Update: On Linux the problem is there too, only it does not manifest by the crash for some reason. Whenever running it under valgrind, enabling mentions generates invalid reads from unallocated memory. |
Which lines exactly? |
These 4 lines make no sense to me in the case of input made of only mentions. That pointer arithmetic leads to the problem. There must be some logic added makeing that code work for links and auto-links but not to be executed for the case of mention which seem to have no closer (or alternatively you need to change the logic that some virtual empty closer marks are created even for the mentions). |
I'm having some issues compiling on Windows. How do you do it? |
I'm generally using mingw-w64, or more specifically very old MSYS (not MSYS2) environment with gcc-toolchain built from https://github.com/niXman/mingw-builds/ and I'm build with Cmake+Ninja. Unfortunately that can be hard-to-replicate environment. That said though, you should be able to build with MSYS 2 (can be downloaded from https://mingw-w64.org) or directly with any recent version of MS Visual Studio (afaik, it now supports building CMake-based projects directly). Or you can generate MSVC solution manually by CMake as appveyor.xml does for the purposes of CI. However note I don't think that making some cosmetic change preventing the most obvious crashes is good enough approach here. The pointed piece of code shows this PR makes a fundamental difference between how the mentions are implemented and how other permissive links are. For the permissive e-mail auto-links we add an extra dummy mark for every potential valid I don't think it's a good idea to depart from this approach for mention links. It could lead to difficult-to-solve collisions of such radically different approaches in all phases of the processing. So please take a look whether mentions could work the same way: In ideal case you would then need to distinguish only at the last moment what constants to use when calling the callback functions for one or the other. I think it should be possible. |
x-mention-data-target is an html tag already in use? |
No. Only in this PR. And even when/if it gets merged you would see it only when enabled with an extension flag. |
This adds support for mention links.