git.oblomov.eu Git - ikiwiki/blob - doc/plugins/contrib/texinfo.mdwn

   1 [[!template id=plugin name=texinfo author="[[tschwinge]]"]]
   2
   3 [[I|tschwinge]] started writing a plugin to render
   4 [GNU Texinfo](http://www.gnu.org/software/texinfo/)
   5 inside the ikiwiki environment.
   6
   7 This plugin is not neccessarily meant to enable people to write arbitrary
   8 wiki pages in the Texinfo format (even though that is possible, of course),
   9 but rather to ease collaboration on existing Texinfo documents.
  10
  11 The plugin is available at
  12 <http://git.savannah.gnu.org/cgit/hurd/web.git/plain/.library/IkiWiki/Plugin/texinfo.pm>.
  13
  14 It's very basic at the moment, but will be improved over time.
  15
  16 It also has not really been audited for any security issues.
  17
  18
  19 # Issues
  20
  21 ## How can I use verbatiminclude?
  22
  23 I only can post a file ...
  24
  25 ## N-to-M Mapping of Input and Output Files
  26
  27 Conventional ikiwiki [[*htmlize*ing|plugins/write#index6h3]] plugins
  28 have a one-to-one mapping of input file and output file:
  29 `some/where/page.mdwn` is rendered to `some/where/page.html`.
  30 This can also be achieved for Texinfo files, but is somewhat
  31 unusual there, when rendering them to HTML.  In general, there
  32 is a N-to-M mapping:
  33
  34 * N Texinfo input files (a main `.texi` file,
  35   several helper files (`fdl.texi`, `version.texi`, ...), and
  36   additional text files which are included from the main `.texi`
  37   file, e.g. `history.texi`, `libfoo.texi`, `libbar.texi`.  --[[tschwinge]]
  38
  39 > As far as multiple input files, you'd need to use add_depends()
  40 > to let ikiwiki know that a change to any of those files should cause a
  41 > rebuild of the "main" file. --[[Joey]]
  42
  43 >> (?) I'll see about a frob to get `makeinfo` provide me with a list of additional files
  44 >> it used for rendering a given `.texi` file. --[[tschwinge]]
  45
  46 > I guess you'd also have to somehow deal with
  47 > it wanting to render pages for each of the helper files. Not quite sure
  48 > what the best way would be to avoid that. --[[Joey]]
  49
  50 >> Might it be an option to simply not render the pages that are already
  51 >> being used as an `include` file for another `.texi` file?
  52 >> But how to assemble that list before actually having rendered all `.texi` files?
  53 >> One possibility might be to already render them at ikiwiki's *scanning* stage and
  54 >> store the rendered HTML files into temporary directories, and then at ikiwiki's
  55 >> *rendering* stage simply install the desired ones into the main tree and discard
  56 >> the others.  --[[tschwinge]]
  57
  58 * M Texinfo output files: the main `.texi` file (which `include`s
  59   the other input files) is usually rendered into a (flat) hierarchy
  60   of HTML files, one file per node, see the table on
  61   <http://www.gnu.org/software/texinfo/manual/texinfo/html_node/#Top>
  62   for an example.  --[[tschwinge]]
  63
  64 > Ikiwiki is perfectly happy with a page creating other files (see eg, the
  65 > img and teximg plugins, as well as the inline plugin's rss generation).
  66 > The will_render() function supports that.
  67 >
  68 > What hasn't been done though is a page creating more than one other _page_.
  69 > Perhaps you could call IkiWiki::genpage by hand for each additional page.
  70 > You might also want to manipulate each data structure that tracks info about
  71 > pages, adding the additional pages to them, so that they're first class
  72 > pages that work as pages everywhere in ikiwiki (ie, can be inlined,
  73 > appear in a site map, be linked to, etc). Not sure how to do that,
  74 > and perhaps you could get away without doing it actually. --[[Joey]]
  75
  76 >> Currently I use `makeinfo --no-split` and render to stdout, so that I can
  77 >> easily capture the output and stuff it into the appropriate ikiwiki data structure.
  78 >> If we want to have multiple output files (which we'll eventually want to have,
  79 >> to avoid having such large single-file outputs), we won't be able to
  80 >> do this anymore.
  81 >> (?) Then we'll need a way to find the main output file, which
  82 >> will be the one to be copied into what ikiwiki expects to be the main output
  83 >> of the rendered `.texi` file.
  84 >> Perhaps (again) parse the `.texi` file for a `@setfilename` statement?
  85 >> The other generated files will also have to
  86 >> copied somewhere (preferably into a subdirectory named alike the main file
  87 >> to avoid name space collisions; but need to take care of links between the files then)
  88 >> and need to be registed within the ikiwiki system.
  89 >> --[[tschwinge]]
  90
  91 There needs to be some logic to establish a mapping between the *N* input files
  92 and the *M* output files.
  93 (At least for web-editing via CGI this is needed: ikiwiki (currently) needs to be able
  94 to deduce *one* input file from a given output file)
  95 Easiest would be either to have *N = 1*
  96 (plus perhaps some input files that are not meant to be editable, like `gpl.texi`)
  97 or to have
  98 *M = N* and have a (?) one-to-one mapping between *input file n* and *output file m*
  99 (which is not possible in Texinfo's `makeinfo` at the moment).
 100 --[[tschwinge]]
 101
 102
 103 ## `makeinfo` Output
 104
 105 `makeinfo --html` is being used for rendering.  It creates stand-alone
 106 HTML files, while ikiwiki only needs the files' `<body>`s.
 107
 108 (?) One possibility (which is what I'm doing at the moment) is to simply cut away
 109 everythin until `<body>` is seen and after `</body>` has been seen.  --[[tschwinge]]
 110
 111
 112 # Bugs
 113
 114 ## Non-functional Texinfo Commands
 115
 116 Those commands are know to not work currently:
 117
 118 * `@printindex`
 119 * `@shortcontents`
 120 * `@contents`
 121
 122 This is due to `makeinfo` not providing this functionality if rendering to stdout.