Needs better handling of unsupported tags.

[evil-shrike]

It isn't stated clearly in readme what kind of tags are supported. So I'd exprect that DOX support any ones.
But it not the case.
For example:

{
    "tags": [],
    "description": {
      "full": "<p>@module core</p>",
      "summary": "<p>@module core</p>",
      "body": ""
    },
    "isPrivate": false,
    "ignore": false,
    "code": "define([\n\t\"jquery\", \"lib/core.lang\", \"lib/binding\",\n\t\"lib/core.events\", \"lib/core.composition\", \"lib/core.diagnostics\", \"lib/core.commands\", \"lib/core.html\",\n\t\"lib/utils\", \"lib/ui/Part\", \"lib/ui/StatefulPart\", \"lib/ui/Component\", \"lib/ui/handlebars/View\",\n\t\"vendor/cookies\", \"i18n!lib/nls/resources\",\n\t\"vendor/history\", \"vendor/modernizr\", \"lib/core.jquery\"\n], function (\n\t$, lang, binding,\n\tevents, composition, diagnostics, commands, html,\n\tutils, Part, StatefulPart, Component, View,\n\tCookies, resources\n) {\n\t\"use strict\";"
  },

Here tag "@module" was not understand.

So what tags are supported? And why not anyone?

[neogeek]

The tags currently supported by dox are as follows:

• api
• augments
• borrows
• define
• enum
• extends
• implements
• lends
• memberOf
• param
• private
• property
• protected
• public
• return
• returns
• see
• template
• throws
• type
• typedef

Reference: https://github.com/visionmedia/dox/blob/master/lib/dox.js#L191

The reason for a specific set of tags is due to the fact that the values for each of these tags are modified in different ways (see the link above).

[evindor]

I think that we need to implement a bit more intelligent behaviour for default case than tag.string = parts.join(' ');. Will think about it.

[iolo]

I agree with @envindor.

There're 3 types of tag:

1. a tag and values in a single line(ex. @api public)
2. a tag only(ex. @private)
3. a tag and values across multiple lines with perserving linefeed or not.(ex. @example some code snippet...)

In current implementation which depends on split('\n') and join(' '),
the third case makes problematic.

I tried to fix it, but it's too dirty and buggy without rewriting parseTag.