At 02:32 AM 2001-03-09 -0800, Jon Ericson wrote:
>[...]
>Another idea (inspired by LaTeX's \footnotemark and \footnotetext) is
>to use N<> to mark the footnote location and supply the text later in
>the pod. Perhaps a "=begin notes" or just "=notes" directive. The
>footnote text could be "=item" paragraphs. Both styles could live
>together, I think.
>[...]
Yes, I like the idea of "this is a footnote reference to an item in the
foootnotes section" existing alongside the "and here, a footnote consisting
of this text", especially since the latter could be considered a shorthand
for the former.
How's about this?
Inlined text syntax:
We ran into my old friend Anna, who was immediately perplexed
at seeing me with another woman.N<|That was no woman, that was
my wife!> I just let her wonder.
External text syntax:
We ran into my old friend Anna, who was immediately perplexed
at seeing me with another woman.N<no_woman_wife> I just let
her wonder.
...later... (Or, in fact, immediately after the current
paragraph ends; it shouldn't make any difference.)
=for footnotes
=item no_woman_wife: That was no woman. That was my wife!
Note that one can have multi-paragraph footnotes this way.
...
=end footnotes
(Where it's up to the renderer to turn the footnotes into numbers as
needed, and correspond on to the other, using the string "no_woman_wife" as
the key.)
Meanwhile, the first format,
We ran into my old friend Anna, who was immediately perplexed
at seeing me with another woman.N<|That was no woman, that was
my wife!> I just let her wonder.
could be considered shorthand for the following (and may even
parse the same, tree-wise);
We ran into my old friend Anna, who was immediately perplexed
at seeing me with another woman.N<x00001> I just let her wonder.
[...whatever...]
=for footnotes
=item x00001: That was no woman. That was my wife!
Note that one can have multi-paragraph footnotes this way.
...
=end footnotes
(where x00001 is just a unique counter value, just so everything will have
a key, internally.)
I do wonder at what point complexifying POD further just becomes just too
nightmarish a prospect, besides being too obviously a case of reinventing
the wheel. But in the use I'm making of POD currently, footnotes are the
top thing that I wish the language could do.
And certainly footnotes can be rendered simply by any output format,
whether as footnotes per se, or as endnotes in an at-the-end =head1 END
NOTES section.
So I don't think this would necessarily be a burden on formatters; if they
can render footnotes as footnotes per se, then it's presumably no problem
to just do so; if they can't do so, then maybe the POD parse-tree-maker
system should have a feature that {automagically / as needed / on request}
renders footnotes as an autogenerated END NOTES section.
(This is as opposed to a feature like, say, tables, or inlined graphics,
which both are no problem for some output formats, a great big hassle for
most, and quite impossible for others.)
As to whether to call the footnote-text section =for notes or =for
footnotes, I'm not happy with just "notes", but just because that's what I
already use, as I'm writing either documentation or code, to just escape
text that's notes to myself, like "hm, move this section up?" or "benchmark
this".
--
Sean M. Burke [EMAIL PROTECTED] http://www.spinn.net/~sburke/
