jazzy
jazzy copied to clipboard
realm
Soulful docs for Swift & Objective-C
Jazzy seems to be documenting my NS_ENUMs, but it's not documenting my NS_OPTIONS. Is this a known issue or am I missing something? I'm using Jazzy with an Obj-C project.
For any document, there are a bunch of collapsible items. For example, in the apple theme document, Class have Properties: Element, .... Each of them will expand a box give...
As of #530, they're rendered in exactly the same way: 
e.g. we have the following directory structure: ``` sh jazzy-docs/theme/assets/css ├── components │ ├── _code.css │ ├── _grid.css │ ├── _icons.css │ ├── _main-content.css │ ├── _navbar.css │ ├── _scaffolding.css...
When concatenating sourcekitten runs for different podspec targets, we end up with multiple versions of the same declaration: https://github.com/realm/jazzy-integration-specs/blob/jp-deprecate-swift-1/document_moya_podspec/after/execution_output.txt#L24 This causes incorrect warnings to be displayed, and makes the list...
If I extend a class in several places, the new functions do get documented within the original class, but their order seems to be just whatever order Jazzy parsed the...
From https://github.com/realm/jazzy/issues/492#issuecomment-206525836: > As for the `/*!` comment blocks, I just assumed they are supported, because HeaderDoc, Xcode and Doxygen all recognize them.
For example, Alamofire documents declarations in its protocols, but not the implementations of the types inheriting from those protocols. See [URLStringConvertible](https://github.com/Alamofire/Alamofire/blob/1.1.4/Source/Alamofire.swift#L162-L174) as an example.
This PR aims to improve jazzy's podspec integration in a few ways: 1. Jazzy will try to build specs as few times as possible. By keeping track of what specs...
Asking for support of nesting custom_categories: For example: ``` yaml custom_categories: - name: Classes children: - name: Bar Type children: - RealmBarData - RealmBarDataSet - name: Protocols children: - name:...
