When a link falls within another link, such as a URL string within a method call, processing both would result in the processed URL being appended to the processed method call, duplicating the text from the URL. Instead, keep track of the links processed, and ignore a link if it's inside of a previously processed link. Here's a test case which illustrates the problem: ```objc /** `NSURL *baseURL = [NSURL URLWithString:@"http://example.com/v1/"]` */ @interface Fooclass : NSObject @end ``` Result: ```html <p><code>NSURL *baseURL = [NSURL URLWithString:@"http://example.com/v1/"]</code>http://example.com/v1/<code>"]</code></p> ``` With patch: ```html <p><code>NSURL *baseURL = [NSURL URLWithString:@"http://example.com/v1/"]</code></p> ``` The test case does indeed cover this problem but certainly could be improved.
…thod] now works) and markdown generation. Refs #237
…with custom title. Refs #237
The problem with star delimited unordered lists was in appledoc comment preprocessor which consumed single star and replaced them with double star markers so that text would be emitted in bold. That's actually a feature of appledoc which allows single stars be used for bold markers, but may break compatibility with Markdown as the result. As there's no reliable way of determining whether the user wants to have star delimited, I decided to go the route I had in my mind for some time now: introduce another command line switch that would prevent handling single stars. It's on/off solution, so not the best one, but everyone can choose at least... Also updated [online documentation](http://gentlebytes.com/appledoc-docs-examples-basic/index.html#compatibility) with example of using the new switch. **Important:** As of this version on, single star handling is **off** by default! This may break backwards compatibility with some folks, but I feel it's better to keep as Markdown compatible for new people as possible...
**Note:** Should convert to sen test as it's supported natively by Xcode 4 and provides much better IDE integration...
…pans under certain circumstances. Closes #77. The problem was with appledoc treating single star as bold and single underscore as italics while Markdown treats single star or underscore as italics and double star or underscore as bold. This requires appledoc preprocessing comment text and converting any single star marker to double star. However as Markdown processor doesn't convert markers inside code blocks, this effectively changed the layout in there. To further complicate the issue, appledoc preprocessor doesn't know in advance whether certain part of text will be converted to code block or not. To compensate, appledoc now leaves original markers untouched and uses placeholder strings when converting single stars to double ones. These placeholders are caught and properly handled later on, in generated HTML where detecting code block or span is simple.
…ound. We also mark the range to avoid further preprocessing!
If appledoc creates a cross reference link in a text that's later on converted to code block by Markdown processor, all such links are cleaned up when creating HTML value. This is required as Markdown processor doesn't process links inside these blocks. Note that this is not the most elegant solution: first we process the text and convert to links, then we process generated HTML again and remove inserted links. Ideally, this situation should be detected while processing string and prevent creating links there in the first place. However we would require reimplementing detection of code blocks there, so at least for now, this should be good enough - as code blocks are not that common this should not affect performance too much...
…t member isn't. In such case, the object was converted to a link. This is properly handled now by keeping unknown remote member text (i.e. not converting at all)!
… various flags affecting the handling.
Not finished yet, but committed due to refactoring required for finalizing.
There's no need to have objects separated with whitespace! Note that this may yield unexpected results in case like this: `[Class(Unknown) method]`. If the Class is found, but no Class(Unknown) category, the Class word will be converted to a cross reference. This should be solvable by requiring prefix though.
This fixes stuff like `Class(Category)` which should prefer category link if found instead of class link if also found on the same location.
…nit tests to cover formatting conversion.