GithubHelp home page GithubHelp logo

coffeedoc's People

Contributors

alexjwayne avatar apg avatar chenglou avatar ddlsmurf avatar grncdr avatar jnordberg avatar manuelschneider avatar meettya avatar omarkhan avatar ulikoehler avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

coffeedoc's Issues

Flag to ignore files or folders

It would be nice to add a option to the generator to ignore certain files or folders.

coffeedoc src --output doc --ignore src/test/

For example I do not want to generate entries for the files containing my tests.

DocBlock before statements (functions)

Hi there,

I was wondering the other day, why the docblocks are IN the functions? I mean I totally understand it makes sense from a developing point of view, grab the first docblock inside of a function and that's it. On the other hand, other doctools have the blocks before the function. In comparison to these other tools this is a bit broken.

Nevertheless, I tried this new approach (well I had no other choice :D) and after using this for a while now I still feel a little uncomfortable with it and I tell you why:
Programming and documentation gets mixed. I have my function statement on top and then indented a bunch of documentation and then code again. Some of these docblocks get really big and the distance between function definition and its code gets bigger and bigger which makes the actual code from the function decoupled from its definition. With the docblock before the function defition you have a clear distinction between documentation and code, which I personally feel more comfortable with.

My question is to possibly rethink this positioning or additionally allow the position of the docblock before such statements.

Pygments syntax highlighting issue

If you look at the source code you'll notice that block comments like this

###
This is a block comment
###

completely mess up the syntax highlighting on Github. This kind of sucks as this project relies on block comments extensively, so I've submitted a patch to the pygments devs here. I'm hoping the patch will be committed soon and should eventually make it onto Github...

Participate in DocSpec

Hi,

I currently worked out a specification to make results of DocTools interoperable. This is completely new and the spec is just one day old. The idea of this spec is, that doctools deliver their output in this interoperable format and generating the output can be done by others, that don't want to work on the parsing part.

The benefits would be:

  • End users can choose whatever doctool they want and which output generator they want.
  • Doctool developers can focus on parsing the code, generate a standardised output and leave the output generation to the end users (doesn't that sound like less work for you?)

My blog post with my motivation for creating this: http://gos.si/blog/docspec-as-interoperable-file-format-between-doctools

As I said the DocSpec is not older than a day, you are invited to join here. Also if you feel like this idea suits your doctool, feel free to jump over to express your interesst in participating as an implementor.

The DocSpec is on github, ready to fork: https://github.com/gossi/docspec

Thank you
gossi

weird stuff happens with classes defined in index.coffee

I have a node module with an index.coffee exporting a few small classes written in that file along with classes from files in the module. I ran coffeedoc on the module directory. It seemed to trip up on the classes in index.coffee, omitting their documentation or putting it after the /html tag in the output index.html. This is easy to work around (by putting the small classes in their own files) but it was confusing, so would be worth fixing or documenting.

String literal in the beginning of the class declaration makes coffeedoc to fail

Example code:

class Foo
  """String Here"""

Fails with the following exception:

TypeError: Cannot read property 'length' of undefined
    at /opt/local/lib/node_modules/coffeedoc/src/coffeedoc.coffee:106:37
    at /opt/local/lib/node_modules/coffeedoc/src/coffeedoc.coffee:113:10
    at /opt/local/lib/node_modules/coffeedoc/src/coffeedoc.coffee:51:25
    at Object.documentModule (/opt/local/lib/node_modules/coffeedoc/src/coffeedoc.coffee:54:8)
    at Object.<anonymous> (/opt/local/lib/node_modules/coffeedoc/src/docgen.coffee:120:24)
    at Object.<anonymous> (/opt/local/lib/node_modules/coffeedoc/src/docgen.coffee:148:4)
    at Module._compile (module.js:441:26)
    at Object.<anonymous> (/opt/local/lib/node_modules/coffee-script/lib/coffee-script/coffee-script.js:22:21)
    at Module.load (module.js:348:31)
    at Function._load (module.js:308:12)

Sphinx integration

Hey this is really cool. I recently created a (hacky and incomplete) Sphinx extension that parses the output of the nodes_to_json.coffee script I snagged from github.com/showell/CoffeeCoffee to add a "coffee" domain to Sphinx with an automodule directive. You can see an example of the result (documenting this sourcecode). As you can see, it doesn't properly support Sphinx indexing yet, that was going to be my next step before I came across coffeedoc.

Would you be interested in some patches to enable a --json output mode to the coffeedoc script? With that I could then re-write my Sphinx extension to depend on that output in favour of the AST traversals I'm already doing (which are probably just duplicates of yours). I think Sphinx support would be awesome for a few reasons:

  • document multi-language web-apps in one documentation system.
  • all the power of restructured text for doc comments.
  • ability to use intersphinx to link back and forth between multiple coffeescript (and non-coffeescript) projects.

To be clear: I'm not asking you to do this, just wanted to see if it's something you are interested in collaborating on.

Docstring parsing isn't compatible with requireJS define()

Consider the following file format:

###
# My Module #

Some module comments
###

define ['import1', 'import2', ...], (import1, import2) ->

    moduleObject =
        ### object docstring ###

        func1: (arg1, arg2, ...) ->
            ### func1 docstring ###

        func2: (arg1, arg2, ...) ->
            ### func2 docstring ###

    return moduleObject

This currently isn't parsed correctly for 2 reasons:

  • Only the top-level nodes of the AST are being parsed, so anything located underneath a define() function won't be reached
  • There currently is no getObjects() equivalent to the getClasses() function.

@variable not documented

When using the @variable shortcut as function parameters, they don't get documented

constructor: (@param1, @param2) ->
    ###
    comment
    ###     

docs output

constructor(,)

Parse Error

MoonBookPro:LocalResponse shamoon$ coffeedoc dev
Error: Parse error on line 15: Unexpected ','
at Object.parseError (/Users/shamoon/local/node/lib/node_modules/coffeedoc/node_modules/coffee-script/lib/parser.js:472:11)
at Object.parse (/Users/shamoon/local/node/lib/node_modules/coffeedoc/node_modules/coffee-script/lib/parser.js:548:22)
at Object.nodes (/Users/shamoon/local/node/lib/node_modules/coffeedoc/node_modules/coffee-script/lib/coffee-script.js:42:21)
at /Users/shamoon/local/node/lib/node_modules/coffeedoc/src/helpers.coffee:17:30
at Object.documentModule (/Users/shamoon/local/node/lib/node_modules/coffeedoc/src/coffeedoc.coffee:27:13)
at Object. (/Users/shamoon/local/node/lib/node_modules/coffeedoc/src/docgen.coffee:142:27)
at Object. (/Users/shamoon/local/node/lib/node_modules/coffeedoc/src/docgen.coffee:198:4)
at Module._compile (module.js:402:26)
at Object. (/Users/shamoon/local/node/lib/node_modules/coffee-script/lib/coffee-script.js:14:21)
at Module.load (module.js:334:31)

<Object> has no method 'existsSync'

Can't make it work, getting this:

set@set:~/www/incident$ coffeedoc coffee/angularjs/services/chat_channel.coffee -o docs/
TypeError: Object #<Object> has no method 'existsSync'
    at Object.run (/usr/local/lib/node_modules/coffeedoc/src/command.coffee:172:12)
    at Object.<anonymous> (/usr/local/lib/node_modules/coffeedoc/bin/coffeedoc:3:42)
    at Object.<anonymous> (/usr/local/lib/node_modules/coffeedoc/bin/coffeedoc:5:4)
    at Module._compile (module.js:446:26)
    at Object.run (/usr/lib/coffee-script/lib/coffee-script/coffee-script.js:79:25)
    at /usr/lib/coffee-script/lib/coffee-script/command.js:175:29
    at /usr/lib/coffee-script/lib/coffee-script/command.js:150:18
    at [object Object].<anonymous> (fs.js:123:5)
    at [object Object].emit (events.js:64:17)
    at Object.oncomplete (fs.js:1190:12)
set@set:~/www/incident$ node -v
v0.8.21

Does not generate html files only index.html

I am running coffeedoc on a subfolder and all it generates is the index.html with invalid links in it.
Say, I have a build/doc.cmd file that has this content:
coffeedoc %~dp0..\project\js

It correctly fetches all coffee files from this dir and includes them in the index but it does not generate the html files with the docs.
The links then point to ..\project\js\foo.html which does not exist.

Is this a relative path issue?

I have installed coffeedoc locally not globally.

Class instance method not documented

On this source file:

# Copyright 2012 The Apache Software Foundation
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http:#www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

###
# core/spi (Service Provider Interface)

This is the core of the abstraction layer that allows the majority of components to operate without caring whether the
underlying infrastructure framework is Prototype, jQuery, or something else.  This is the standard SPI, which wraps
Prototype ... but does it in a way that makes it relatively easy to swap in jQuery instead.
###
# TODO: Define a dependency on "prototype" when that's exposed as a stub module.
define ["_", "core/console"], (_, console) ->
  split = (str) ->
    _(str.split " ").reject (s) -> s is ""

  ###
  Converts content (provided to ElementWrapper.update() or .append()) into an appropriate type. This primarily exists
  to validate the value, and to "unpack" an ElementWrapper into a DOM element.
  ###
  convertContent = (content) ->
    if _.isString content
      return content

    if _.isElement content
      return content

    if content.constructor?.name is "ElementWrapper"
      return content.element

    throw new Error "Provided value <#{content}> is not valid as DOM element content."

  class EventWrapper

    ###
    Generic view of an DOM event that is passed to a handler function.

    Properties:

    * nativeEvent - the native Event object, which may provide additional information.
    * memo - the object passed to `ElementWrapper.trigger()`.
    * type - the name of the event that was triggered.
    * char - the character value of the pressed key, if a printable character, as a string.
    * key -The key value of the pressed key. This is the same as the `char` property for printable keys,
      or a key name for others.
    ###
    constructor: (event) ->
      @nativeEvent = event
      @memo = event.memo
      @type = event.type

      @char = event.char
      @key = event.key

    ###
    Stops the event which prevents further propagation of the DOM event,
    as well as DOM event bubbling.
    ###
    stop: ->
      @nativeEvent.stop()

  # Value returned from on(); an EventHandler is used to stop listening to
  # events, or even temporarily pause listening.
  class EventHandler

  # Registers the handler as an event listener for matching elements and event names.
  # Note: it is possible to add handlers for events on the window object, but
  # start() and stop() do not do anything for such events.
  #
  # elements - array of DOM elements
  # eventNames - array of event names
  # match - selector to match bubbled elements, or null
  # handler - event handler function to invoke; it will be passed an Event instance
    constructor: (elements, eventNames, match, handler) ->
      throw new Error("No event handler was provided.") unless handler?

      wrapped = (prototypeEvent, matchedElement) ->
        # Set "this" to be the matched element (jQuery style), rather than
        # the element on which the event is observed.
        handler.call(matchedElement, new EventWrapper prototypeEvent)

      # Prototype Event.Handler instances
      @protoHandlers = []

      _.each elements, (element) =>
        _.each eventNames, (eventName) =>
          if element is window
            unless _.isEmpty match
              throw Error("Matching of elements by selector is not supported for window events.")
            Event.observe element, eventName, wrapped
          else
            @protoHandlers.push element.on eventName, match, wrapped

    # Invoked after stop() to restart event listening. Returns this EventHandler instance.
    start: ->
      _.each @protoHandlers, (h) -> h.start()

      this

    # Invoked to stop or pause event listening. Returns this EventHandler instance.
    stop: ->
      _.each @protoHandlers, (h) -> h.stop()

      this

  # Wraps a DOM element, providing some common behaviors.
  # Exposes the original element as property 'element'.
  class ElementWrapper

    constructor: (element) ->
      @element = $(element)

    # Hides the wrapped element, setting its display to 'none'. Returns this ElementWrapper.
    hide: ->
      @element.hide()
      this

    ###
    Displays the wrapped element if hidden. Returns this ElementWrapper.
    ###
    show: ->
      @element.show()
      this

    # Removes the wrapped element. Returns this ElementWrapper.
    remove: ->
      @element.remove()
      this

    # Returns the value of an attribute as a string, or null if the attribute
    # does not exist.
    getAttribute: (name) ->
      @element.readAttribute name

    # Set the value of the attribute to the given value, then returns this ElementWrapper.
    #
    # Note: Prototype has special support for values null, true, and false that may not be duplicated by other
    # implementations of the SPI.
    setAttribute: (name, value) ->
      # TODO: case where name is an object, i.e., multiple attributes in a single call.
      # Well, you can just do it, but its not guaranteed to work the same across
      # different SPIs.
      @element.writeAttribute name, value
      this

    # Returns true if the element has the indicated class name, false otherwise.
    hasClass: (name) ->
      @element.hasClassName name

    # Removes the class name from the element, then returns this ElementWrapper.
    removeClass: (name) ->
      @element.removeClassName name
      this

    # Adds the class name to the element, then returns this ElementWrapper.
    addClass: (name) ->
      @element.addClassName name
      this

    # Updates this element with new content, replacing any old content. The new content may be HTML text, or a DOM
    # element, or null (to remove the body of the element).
    #
    # Returns this ElementWrapper.
    update: (content) ->
      @element.update (convertContent content)
      this

    # Appends new content (Element or HTML markup string) to the element.
    #
    # Returns this ElementWrapper.
    append: (content) ->
      @element.insert bottom: (convertContent content)
      this

    # Finds the first child element that matches the CSS selector.
    #
    # Returns the ElementWrapper for the child element, or null if not found.
    find: (selector) ->
      match = @element.down selector

      # Prototype returns undefined if not found, we want to return null.
      if match
        new ElementWrapper match
      else
        return null

    # Returns an ElementWrapper for this element's containing element. The ElementWrapper is created lazily, and
    # cached. Returns null if this element has no parentNode (either because this element is the document object, or
    # because this element is not yet attached to the DOM).
    getContainer: ->
      unless @container
        return null unless element.parentNode
        @container = new ElementWrapper(element.parentNode)

      @container

    # Returns true if this element is visible, false otherwise. This does not check to see if all containers of the
    # element are visible.
    visible: ->
      @element.visible()

    # Fires a named event. Returns this ElementWrapper.
    #
    # eventName - name of event to trigger on the wrapped Element
    # memo - optional value assocated with the event; available as WrappedeEvent.memo in event handler functions
    trigger: (eventName, memo) ->
      throw new Error("Attempt to trigger event with null event name") unless eventName?

      @element.fire eventName, memo
      this

    # Adds an event handler for one or more events.
    #
    # events - one or more event names, separated by spaces
    # match - optional: CSS expression used as a filter; only events that bubble
    # up to the wrapped element from an originating element that matches the CSS expression
    # will invoke the handler.
    # handler - function invoked; the function is passed an EventWrapper object.
    #
    # Returns an EventHandler object, making it possible to turn event observation on or off.
    on: (events, match, handler) ->
      exports.on @element, events, match, handler

  parseSelectorToElements = (selector) ->
    if _.isString selector
      return $$ selector

    # Array is assumed to be array of DOM elements
    if _.isArray selector
      return selector

    # Assume its a single DOM element

    [selector]

  bodyWrapper = null

  # Performs an asynchronous Ajax request, invoking callbacks when it completes.  options.method - "post", "get", etc.,
  # default: "post". Adds a "_method" parameter and uses "post" to handle "delete", etc.
  # options.contentType - default "context "application/x-www-form-urlencoded"
  # options.parameters - optional, additional key/value pairs
  # options.onsuccess - handler to invoke on success. Passed the XMLHttpRequest transport object. Default does nothing.
  # options.onfailure - handler to invoke on failure (server responds with a non-2xx code). Passed the response. Default
  # will log and error to the console.
  # options.onexception - handler to invoke when an exception occurs (often means the server is unavailable). Passed
  # the exception. Default will log an error to the cnsole and throw the exception.
  # TODO: Clarify what the response object looks like and/or wrap the Prototype Ajax.Response object.
  ajaxRequest = (url, options = {}) ->
    finalOptions =
      method: options.method or "post"
      contentType: options.contentType or "application/x-www-form-urlencoded"
      parameters: options.parameters or {}
      onException: (ajaxRequest, exception) ->
        if options.onexception
          options.onexception exception
        else
          console.error "Request to #{url} failed with #{exception}"
          throw exception

      onFailure: (response) ->
        if options.onfailure
          options.onfailure response
        else
          message = "Request to #{url} failed with status #{response.getStatus()}"
          text = response.getStatusText()
          if not _.isEmpty text
            message += " -- #{text}"

          console.error message + "."

      onSuccess: (response) ->

        # Prototype treats status == 0 as success, even though it may
        # indicate that the server didn't respond.
        if (not response.getStatus()) or (not response.request.success())
          finalOptions.onFailure(response)
          return

        # Tapestry 5.3 includes lots more exception catching ... that just got in the way
        # of identifying the source of problems.  That's been stripped out.
        # Still sorting out how this will all work, especially in terms
        # of the abstraction.
        options.onsuccess and options.onsuccess(response)

    new Ajax.Request(url, finalOptions)

  exports =
    ajaxRequest: ajaxRequest

    # Invokes the callback only once the DOM has finished loading all elements (other resources, such as images, may
    # still be in-transit). This is a safe time to search the DOM, modify attributes, and attach event handlers.
    # Returns this modules exports, for chained calls.
    domReady: (callback) ->
      document.observe "dom:loaded", callback

      exports

    # on() is used to add an event handler
    # selector - CSS selector used to select elements to attach handler to; alternately,
    # a single DOM element, or an array of DOM elements
    # events - one or more event names, separated by spaces
    # match - optional: CSS expression used as a filter; only events that bubble
    # up to a selected element from an originating element that matches the CSS expression
    # will invoke the handler.
    # handler - function invoked; the function is passed an Event object.
    # Returns an EventHandler object, making it possible to turn event observation on or off.
    on: (selector, events, match, handler) ->
      unless handler?
        handler = match
        match = null

      elements = parseSelectorToElements selector

      return new EventHandler(elements, (split events), match, handler)

    # Returns a wrapper for the provided DOM element that includes key behaviors:
    # hide(), show(), remove(), etc.
    # element - a DOM element, or the window, or the unique id of a DOM element
    # Returns the ElementWrapper.
    wrap: (element) ->
      throw new Error("Attempt to wrap a null DOM element") unless element
      new ElementWrapper element

    # Returns a wrapped version of the document.body element. Care must be take to not invoke this function before the
    # body element exists; typically only after the DOM has loaded, such as a domReady() callback.
    body: -> bodyWrapper ?= (exports.wrap document.body)

    # Returns the current dimensions of the viewport. An object with keys width and height is returned.
    viewportDimensions: -> document.viewport.getDimensions()

The generated documentation does not include documentation for EventWrapper.stop().

I've tried a few variations, such as stop: () ->, but this didn't change anything.

coffeedoc 0.2.5

I use this command to compile:

coffeedoc -o build/coffeedoc --parser requirejs src/main/coffeescript/META-INF/modules/core

reserved word "private"

Error

$ coffeedoc --renderer gfm --stdout lib/
SyntaxError: reserved word "private" on line 16
    at SyntaxError (unknown source)
    at Lexer.error (/usr/local/lib/node_modules/coffeedoc/node_modules/coffee-script/lib/coffee-script/lexer.js:682:13)
    at Lexer.identifierToken (/usr/local/lib/node_modules/coffeedoc/node_modules/coffee-script/lib/coffee-script/lexer.js:86:16)
    at Lexer.tokenize (/usr/local/lib/node_modules/coffeedoc/node_modules/coffee-script/lib/coffee-script/lexer.js:33:19)
    at Object.nodes (/usr/local/lib/node_modules/coffeedoc/node_modules/coffee-script/lib/coffee-script/coffee-script.js:63:33)
    at CommonJSParser.getNodes (/usr/local/lib/node_modules/coffeedoc/src/parsers.coffee:37:31)
    at Object.documentModule (/usr/local/lib/node_modules/coffeedoc/src/coffeedoc.coffee:33:20)
    at Object.<anonymous> (/usr/local/lib/node_modules/coffeedoc/src/docgen.coffee:115:24)
    at Object.<anonymous> (/usr/local/lib/node_modules/coffeedoc/src/docgen.coffee:141:4)
    at Module._compile (module.js:432:26)

node:

$ node -v
v0.6.6

coffee:

$ coffee -v
CoffeeScript version 1.1.3

Classes and Functions inside a top-level function won't be parsed

I'm writing my code using a namespacing convention, meaning all my files start with something like namespace 'ModuleName', -> and that seems to be causing CoffeeDoc to ignore the entire file.

Is there any way to get CoffeeDoc to just ignore the namespace function?

No --requirejs when installed via npm, version 0.1.11

Hey there,

I installed coffeedoc via npm.

see npm info:

$ npm info coffeedoc
{ name: 'coffeedoc',
  description: 'An API documentation generator for CoffeeScript',
  'dist-tags': { latest: '0.1.11' },

and coffeedoc cli options:

$ coffeedoc
Usage: coffeedoc [options] [targets]

Options:
    -o, --output: Set output directory (default: ./docs)
    --commonjs  : Use if target scripts use CommonJS for module loading (default)

I have no --requirejs option. Did I do something wrong?

I was going down to the coffeedoc source folder, and did cat docgen.coffee, here is a snippet:

# Command line options
OPTIONS =
    '-o, --output': 'Set output directory (default: ./docs)'
    '--commonjs  ': 'Use if target scripts use CommonJS for module loading (default)'
#    '--requirejs ': 'Use if target scripts use RequireJS for module loading'

A spec/ folder is not present. Maybe that helps.

Thanks

Feature Request: Don't render AST nodes that aren't commented

At the moment if I run coffeedoc across my coffeescript file it renders every single method, even those that you maybe don't want to expose to documentation. Personally it's something that I need and I'd rather work together than creating a separate repository.

How would you implement something like this? From a users point of view I think it could be an setting, I'd be happy to give it a go.

do keyword seems to crash coffeedoc

Given this coffee file:

getVar = do ->
  someVar = 10
  -> someVar

coffeedoc can't seem to handle it:

/usr/local/lib/node_modules/coffeedoc/lib/coffeedoc.js:90
        if (n.value.type === 'Call' && n.value.variable.base.value === 'requir
                                                            ^

TypeError: Cannot read property 'value' of undefined
    at /usr/local/lib/node_modules/coffeedoc/lib/coffeedoc.js:90:61
    at Object.documentModule (/usr/local/lib/node_modules/coffeedoc/lib/coffeedoc.js:28:13)
    at /usr/local/lib/node_modules/coffeedoc/lib/docgen.js:52:29

Suggestion: headers beyond h2

Is it perhaps an option to allow some form of shorthand notation like instead of doing

\#\#\#\#\# something

you'd allow the use of

#5 something or
#h5 something etc.

to avoid the closing of multi-line comments? I'd might even suggest logic that goes as far as replacing any instances of #### and ##### and ###### (ends at 6 right?) because there is no sane use-case imaginable that would justify such a use intended to be coffeescript comments (this must be intended as headers, right?) but this might go a bit too far for certain people I guess...

Just my two cents...

Class docstring is null when using tabs for indenting

Everything works fine when using spaces for indenting.
Version 0.2.9

###
file desc
###

class MyClass
    ###
    class desc
    ###

    fce: ->
        ###
        function desc
        ###

outputs:

[{
        "docstring": "file desc\n",
        "deps": {},
        "classes": [{
                "name": "MyClass",
                "lineno": 4,
                "docstring": null, // <- bug here
                "parent": null,
                "staticmethods": [],
                "instancemethods": [{
                        "name": "fce",
                        "lineno": 9,
                        "docstring": "function desc\n",
                        "params": []
                    }
                ],
                "privatemethods": []
            }
        ],
        "functions": [],
        "privateFunctions": [],
        "path": "test.coffee",
        "basename": "test.coffee"
    }
]

Best,
Patrik

Hide non-public class methods from documentation

I suppose it is necessary to implement - hide non-public methods, but can`t to decide how it must be done.

Why its important future - private methods is NOT a public interface and its clutter up documentation with unnecessary details.

For my code I use classical naming notation for 'private' methods - '_methodName' - name started by underscore.

May be add to CLI args something like
--private-method group (by default) - group all non-public methods in one category, placed at the end of class docs
--private-method fold group AND fold methods list, unfolding by click
--private-method hide to wipe out from documentation all private methods

I may try to implement this behavior, so I looks for some help:

  • correct name for CLI key
  • correct name for CLI key options
  • is concept is ok?

PS.Sorry for 'broken English', not my mother tongue.

Using tabs for indentation causes code blocks where not wanted

If you use tabs for indentation in your *.coffee file and write multiline coffeedoc comments like you have in your example in README.md the whole comment is converted to a <pre><code></code></pre> block.

Example:

foo = ->
    ###
    This will be a preformatted code block in the generated html
    if you happen to use tabs for indenting your *.coffee files
    ###

@tags

Could @tags be used so that you could document method arguments:

@param String Description ...
@param Name Description ...
 method: (param1, param2) ->
   ...

Great tool btw!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.