Now using github to track project issues.

This commit is contained in:
Jonathan Bernard 2012-01-30 14:11:56 -06:00
parent fcdf829cb1
commit 71975412d2
12 changed files with 0 additions and 128 deletions

View File

@ -1,2 +0,0 @@
Implement working internal links using ``jlp://`` schema.
=========================================================

View File

@ -1 +0,0 @@
Implement language-specific code parsing and comprehension.

View File

@ -1 +0,0 @@
Support multi-line block comments.

View File

@ -1 +0,0 @@
Make the parser configurable with respect to comment delimiters.

View File

@ -1,16 +0,0 @@
Fix delimited doc block behavior.
=================================
Delimited doc blocks require that the start token be the first non-space token
on the line it is on and that the end token be on it's own line. This is not in
line with the general nature of delimited comment blocks, which do not place
any restrictions on what comes before the start delimiter or after the end
delimiter.
----
========= ===================
Created : 2011-09-07
Resolved: 2011-12-25T23:26:07
========= ===================

View File

@ -1,25 +0,0 @@
Internal links are not smart enough about cross-file linking.
=============================================================
There are two main problems with internal linking as it works now:
1. The links are resolved relative to the directory of the file being processed
when they should be resolved relative to the root output directory.
For example, consider ``@org id1`` defined in ``dir/file1.src``, then
referenced in ``dir/file2.src`` in this manner: ``[link](jlp://id1``. The
url written in ``dir/file2.html`` is ``dir/file1.html#id1``. However, when
the page is viewed, this url is interpreted relative to the directory of the
current page. So if the docs live at ``file:///docs`` then the url will
resolve to ``file:///docs/dir/dir/file1.src#id1`` instead of
``file:///docs/dir/file1.html#id1``.
2. The links do substitute the ``html`` suffix to the file names in place of the
files' suffixes. In the above example note that the actual urls end in
``.src`` like the original input files, but the expected url ends in
``.html``.
========= ==========
Created: 2011-09-08
Resolved: 2011-09-09
========= ==========

View File

@ -1,12 +0,0 @@
Encode Documentation and Code Characters for HTML
=================================================
The text of the documentation and the code is not being HTML encoded,
so some characters (most notably `<`) are causing wierd display issues
in the resulting output.
----
======== ===================
Created: 2011-12-26T00:43:44
======== ===================

View File

@ -1,12 +0,0 @@
`Include` Directive.
====================
Add a new directive: `include`. This directive allows the author to include
the contents of a URL inline in the documentation (can be an internal JLP
reference URL).
----
======== ===================
Created: 2011-12-29T11:23:52
======== ===================

View File

@ -1,12 +0,0 @@
Automatically create document `org` directives.
===============================================
The author should not have to create an `org` directive at the top of every file.
This should be done for him during parsing. Ideally the system would be smart enough
to notice if he has defined an `org` at the top of a file and use that if he has.
----
======== ===================
Created: 2012-01-04T17:12:59
======== ===================

View File

@ -1,12 +0,0 @@
Add a `title` directive for titling documents.
==============================================
Return to defaulting a title for each document. Instead of the internal document id use
something more reasonable, like the filename without the path and without the extension.
A new attribute `title` could allow the author to override this value.
----
======== ===================
Created: 2012-01-04T17:14:26
======== ===================

View File

@ -1,18 +0,0 @@
Modify `org` behavior to include simple anchors.
================================================
Currently JLP supports at most one `org` directive per block which identifies the block.
It would be useful to support multiple `org` directives within a block, particularly
when there is a large block that may have many interesting internal targets. Maybe the
`org` directive should be handled differently when it is used multiple times within a
block. This would be discovered in the generator parse phase and we could change the
LinkAnchor type at that time. During the parse phase we emit the new type of anchors
as `<a id="link-name"/>` into the document. We would also change our search for block
ids to inly look for the single-occurance type of `orgs`.
----
========= ===================
Created : 2012-01-05T11:40:35
Resolved: 2012-01-06T14:32:46
========= ===================

View File

@ -1,16 +0,0 @@
Abstract `jlp:` link resolution.
================================
I need to think of a system to allow the resolution of `jlp:` protocol links
to be easily configured. Currently the link resolution assumes straigtforward
file-based storage and converts them into relative paths. An example of another
type of resolution strategy might be a DB-backed solution where each document
has a unique id (this is already happening temporarily in the JLP process) and
there is some schema for mapping document id's to URIs for the document. Or
perhaps another file-based solution with different convention for document storage.
----
======== ===================
Created: 2012-01-30T13:55:05
======== ===================