Embedded links expands keywords #377

Open
robvdveer opened this Issue Jul 23, 2013 · 4 comments

Comments

Projects
None yet
3 participants
Collaborator

robvdveer commented Jul 23, 2013

I think its a bug in the markdown processor, but when i do a link like so:

  ![link](../docs/filenameWithKeyword.html) 

and i have a topic named Keyword, the Keyword gets expanded to a topic link as well, messing up the link itself.

Possibly related to #212

Contributor

paulmelnikow commented Jul 23, 2013

Are you using the latest development version? I recently fixed a similar bug in pull request #369.

If the latest development version still has the bug then probably that method needs another line to handle this case.

Collaborator

robvdveer commented Jul 23, 2013

Nope, thats a different bug, paul. And yes, i have the latest version if that matters. My problem involves default expansion of fienames:

![link](../docs/filenameWithKeyword.png)

results in

<img src="../docs/filenameWith<a href="../ Classes/Keyword.html">Keyword</a>.png"></img>

Which is clearly not the intention.
is there a way to stop automatic expansion of keywords, perhaps only marked keywords get autoresolved?

For now i just renamed the images

Collaborator

robvdveer commented Jul 30, 2013

I think I found the root cause of this issue. When I have a class name 'ClassName' and I use the following documentation example:

/** This class makes heavy use of the blablaClassName class */

It gets expanded. However when I do

/** This class makes heavy use of the ClassNameBlablabla class */

It is not replaced. I guess the regex pattern for replacing references misses a 'matches start of word' condition. Investigating.

Collaborator

robvdveer commented Jul 31, 2013

Inside GBCommentsProcessor stringByConvertingSimpleCrossReferencesInString: there is a loop that try to find keywords by moving the match range up by one character at a time (lines 778 - 794):

    if ([links count] == 0) {
        if (isInsideMarkdown) return string;
        if (searchRange.location >= [string length] - 1) break;
        searchRange.location++;
        searchRange.length--;
        if (searchRange.length == 0) break;
        continue;
    }

This is the root cause. The range should advance to the next token (basically any non-word-character) instead of the next character, but parsing has already been completed in the previous phase.

@tomaz tomaz added Bug labels May 16, 2014

@tomaz tomaz added this to the 3.0 milestone May 16, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment