Colon tag troubles, some comment stuff about ldoc HOT 9 CLOSED

As far as I can tell from skim reading this issue has long-since been addressed. Feel free to comment if I missed something and there is still an outstanding problem.

from ldoc.

Ah, I see! This is what happens when we allow too much flexibility, and use a simple recipe like this to switch on 'colon mode'

   if s:match ':%s' and not s:match '@%a' then
      preamble,tag_items = parse_colon_tags(s)
   else
      preamble,tag_items = parse_at_tags(s)
   end

The problem is that you don't want colon mode, but you're getting it anyway!

Best fix for now is yet another config.ld flag - no_colon=true. Or perhaps, since colon mode is not standard and experimental anyway, colon_mode=true.

I can't see in general how simple local string matching can read the programmer's mind....

steve d.

from ldoc.

In fact, the current master has a --nocolon flag (also nocolon=true in config.ld). That should sort you out for now - although I'm tending towards calling it 'colon' for enabling colon tag behaviour.

from ldoc.

Okay, good to know. The trouble spots aren't too terribly plentiful, so I can probably deal with them one by one.

Actually, if that recipe is likely to remain, I'll try alias()-ing something like "e" to the empty string and injecting dummy @ e symbols in the offending blocks.

Thanks.

Edit: Empty string not so great, but @ c -> ":" seems okay.

from ldoc.

On Thu, Jan 24, 2013 at 8:55 PM, Steven Johnson
[email protected] wrote:

Okay, good to know. The trouble spots aren't too terribly plentiful, so I can probably deal with them one by one.

That Flags file you sent actually worked fine once I called LDoc with
-N, except for an error about @callable which I'm still looking at.

Today I will push up new version, in which by default colon mode is
disabled - it really does interfere with things unless you are wanting
to do things the Colon Way (and combining the two styles is a recipe
for confusion)

steve d.

from ldoc.

(and combining the two styles is a recipe for confusion)

So I'm finding. 😄 I probably will end up going the -N way.

Something else I stumbled across, converting some TODO:'s, is that the @ todo tag doesn't seem to play nice if the function summary is empty:

https://github.com/ggcrunchy/corona-sdk-snippets/blob/master/game/Persistence.lua#L215

I did notice the annotations code in LDoc involves a summary, but there's quite a lot of code to wade through.

from ldoc.

On Fri, Jan 25, 2013 at 9:05 AM, Steven Johnson
[email protected] wrote:

So I'm finding. I probably will end up going the -N way.

Right! Latest tagged version switches makes colon mode explicit, no
more funny heuristics!

Should be able to grab 1.3.2 from the tags page:

https://github.com/stevedonovan/LDoc/tags

Something else I stumbled across, converting some TODO:'s, is that the @ todo tag doesn't seem to play nice if the function summary is empty:

Hm, let me have a look at that! Not a terribly well tested feature,
count yourself in as a beta tester!

steve d.

from ldoc.

On Fri, Jan 25, 2013 at 9:05 AM, Steven Johnson
[email protected] wrote:

Something else I stumbled across, converting some TODO:'s, is that the @ todo tag doesn't seem to play nice if the function summary is empty:

Ok, that case does not actually have a todo tag ;) Also remember
that the summary/description must come first, and then the tags.
(That's irritating and I'm working on it currently)

I think the original use case was for @todo to appear anywhere in the
code, but not actually appear in the docs (can be extracted with
--tags flag)

In this case, just move the TODO before the tags.

I think I've assumed that everyone is going to put a summary first...

steve d.

from ldoc.

Ok, that case does not actually have a todo tag ;)

Well, IF you turn it into one, that is. :)

The no-colon-by-default update seems to work well.

I have one more issue to pester you with, probably a separate issue, but I ought to sleep before I write it up. :)

from ldoc.