1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
|
-*- Org -*-
Copyright 2007, 2008, 2009 Ludovic Courtès <ludo@gnu.org>
Copying and distribution of this file, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved.
This is a fairly long list of to-do items for Skribilo, hopefully not
too outdated, but probably somewhat ambitious, as suggested by the
headings below.
XXX: Check items in `[[file:src/guile/README::Skribilo%20Outline][src/guile/README]]'.
* Important Items (1.0 Release Blockers)
** Update the documentation, remove Skribe legacy stuff
Almost done.
** Have a PS/PDF version of the documentation (preferably using Lout)
Almost there. Need to improve layout and style of the Lout PDF.
** Remove calls to `skribe-error', use SRFI-35 exceptions
Almost done.
** Provide markup for emdash and friends
`--' should yield `{-}{-}' in Lout, while `,(--)' should produce `--',
things like that.
** Consistently handle "fixed-widthness" of `code'
Currently, our CSS makes `code' fixed-width in HTML, but it's not so in
Lout et al.
** Validate HTML output
Probably with [[http://www.htmlhelp.com/tools/validator/offline/index.html.en][`wdg-html-validator']], or OpenSP, since xmllint(1) doesn't
do the job (can't load the DTD, returns zero even in the presence of
parse errors, etc.).
** Clean Info output
* Small Items, Known Bugs
** Fix the HTML engine for `html-left-margin'
Left margin doesn't display well when CSS is being used.
** `eq' package: Handle `:number' in the HTML back-end
** `slide' package: Remove `%slide-the-slides'
* Longer-Term Items
** Add a `if-engine' markup to avoid hacks with `engine-format?'
Expressions like `(if (engine-format? "lout") xxx yyy)' are wrong,
because they look at the value of `*current-engine*' rather than the
engine actually used during resolution and output.
** Find a clean way to have packages customize engines
Currently, most packages have side-effects at `use-modules'-time, e.g.,
they `engine-custom-set!' the current engine, which kinda sucks (see,
e.g., `(skribilo package slide)').
Likewise, there's no replacement for the `*load-options*' mechanism
implemented by `skribe-load' (see, e.g., `web-article').
** Add new engines
*** Write an XHTML engine
*** Render equations using MathML when rendering to HTML
*** Write a [[GUI]]
** Add new readers
*** Add an Org-Mode reader
Could be based on [[http://wingolog.org/software/guile-present/][Andy's parser in Guile-Present]].
*** Add a Texinfo reader
Could be based on the one in [[http://home.gna.org/guile-lib/][Guile-Lib]].
** Write a nice GUI based on Andy's STexi browser
** Add a BibTeX parser
** Add stand-alone tools
Such as `skribilo-to-bibtex', `bibtex-to-skribilo', etc.
** Provide better internationalization
*** Add a `:language' keyword to `document'
** Provide a `skribilo-safe' module name space
In `[[file:src/guile/skribilo/module.scm][(skribilo module)]]', the default user-module should not contain any
filesystem-related primitives, nor any standard module allowing such
operations (e.g., `(ice-9 popen)').
** Deal with identifier scope in nested documents at the engine level
Now that node identifiers are scoped, node identifiers in nested
documents could collide with identifiers in the parent document(s).
Thus, engines should work to avoid collisions. That said, nested
documents are not very useful, except in the user manual.
* Much Longer Term Items
** Move to a purely functional style
The goal would be to benefit from referential transparency several
levels, thereby clarifying the code and allowing for a wide range of
improvements (e.g., reusing ASTs or engines in different contexts).
*** Implement a purely functional `resolve'
We'd need to first iterate over the AST:
1. to create a dictionary of nodes (keyed by node `:ident');
2. to create a parent-lookup dictionary, so that things like
`ast-parent' can be implemented.
To that end, VList-based hash lists could come into play. Andy Wingo's
[[http://wingolog.org/pub/fold-and-xml-transformation.pdf][work on `fold-layout']] would certainly be a good source of inspiration.
*** Avoid side effects on engines
**** Customs could be passed at engine instantiation time
**** Main problem is `markup-writer'
*** Find a purely functional representation of ASTs
[[http://pobox.com/~oleg/ftp/Scheme/parent-pointers.txt][Oleg's work on SXML parent pointers]] is probably a good source of
inspiration, especially the "parent pointers as thunks" approach: it's
simple and Just Works!
In addition, we could have the resolution function add a VList "hash
list" (read: functional hash table) to the `document' node so that we
can do `document-lookup-node'.
** Don't name markups using symbols
Markups should be named using unforgeable objects, rather than symbols.
This would be a step in the direction of "capability-object semantics".
;;; Local Variables:
;;; coding: utf-8
;;; ispell-local-dictionary: "american"
;;; End:
|
