Merge branch 'master' of ssh://git.ikiwiki.info
commit
7cdbc9642f
|
@ -0,0 +1,59 @@
|
|||
[[!template id=plugin name=bibtex author="[[Matthias]]"]]
|
||||
|
||||
# bibtex for ikiwiki #
|
||||
|
||||
(get me at [github]!)
|
||||
|
||||
[github]: https://github.com/ihrke/iki-bibtex
|
||||
|
||||
This [ikiwiki]-plugin provides a
|
||||
|
||||
[[!bibtex ]]
|
||||
|
||||
directive for [ikiwiki].
|
||||
|
||||
So far, it can display a raw or formatted bibtex-entry from a
|
||||
bibtex-file (either checked into ikiwiki, or not) and display a
|
||||
list of all bibtex-keys used on a key.
|
||||
|
||||
[ikiwiki]: http://ikiwiki.info/
|
||||
|
||||
Features:
|
||||
|
||||
* three different output formats for citations:
|
||||
+ cite - Author (year)
|
||||
+ citation - Author1, Author2 (year): **Title.** *Journal*
|
||||
vol(num). pp.
|
||||
+ raw - raw bibtex-entry preformatted
|
||||
* supports websetup
|
||||
* bibliography
|
||||
|
||||
|
||||
## Requirements ##
|
||||
|
||||
* [Text::BibTeX] - available from CPAN
|
||||
|
||||
[Text::BibTeX]: http://search.cpan.org/~ambs/Text-BibTeX-0.61/lib/Text/BibTeX.pm
|
||||
|
||||
## Examples ##
|
||||
|
||||
Output from file mybib.bib, bibtex key 'key1' in a citation-like
|
||||
format (authors (year): journal. volume (number), pages.).
|
||||
|
||||
[[!bibtex file="mybib.bib" key="key1" format="citation"]]
|
||||
|
||||
Combine with toggle-plugin to optionally display the raw bibtex
|
||||
|
||||
[[!bibtex key="Ihrke2011"]] \[[!toggle id="bibtexentry" text="(entry)"]]
|
||||
\[[!toggleable id="bibtexentry" text="""
|
||||
[[!bibtex key="Ihrke2011" format="raw"]]
|
||||
\[[!toggle id="bibtexentry" text="(hide)"]]
|
||||
"""]]
|
||||
|
||||
Add a bibliography that includes all bibtex-directives from that page
|
||||
|
||||
|
||||
## Bibliography ##
|
||||
[[!bibtex_bibliography ]]
|
||||
|
||||
----
|
|
@ -0,0 +1,30 @@
|
|||
I've observed people just seem to get into a dead end whilst reading my ikiwiki instances.
|
||||
|
||||
They don't want to back out of post to an index. They want an easy button to click next or previous post, like what you find on Wordpress sites.
|
||||
|
||||
<http://codex.wordpress.org/Next_and_Previous_Links>
|
||||
|
||||
Thank you
|
||||
|
||||
> This is a perfect use for [[todo/wikitrails]], of which my
|
||||
> [[plugins/contrib/trail]] plugin is an implementation. Code review on that
|
||||
> plugin would be welcome; it might even get merged one day.
|
||||
>
|
||||
> Unfortunately, IkiWiki blogs use a [[ikiwiki/PageSpec]] to define the set of
|
||||
> "posts" in the blog (through which the next/prev trail should range), and
|
||||
> the current implementation of [[plugins/contrib/trail]] in terms of typed
|
||||
> links would have a circular dependency if used with a PageSpec: typed links
|
||||
> have to be added before PageSpecs are evaluated, because "A links to B" is
|
||||
> something that can be in a PageSpec; but if you want to add typed links
|
||||
> ("A is part of trail B" in this case) based on a PageSpec, then the PageSpec
|
||||
> must be evaluated before the typed links can be added. Chicken/egg.
|
||||
>
|
||||
> One solution would be to make the trail plugin use its own data
|
||||
> structure, like [[plugins/contrib/album]] used to do, instead of typed
|
||||
> links: at scan time, the trail plugin would just record what the PageSpec
|
||||
> was, and delay actually *evaluating* the PageSpec until the beginning
|
||||
> of the `render` stage (after all pages have been scanned). This
|
||||
> reduces the generic usefulness of typed links, though - in particular
|
||||
> you can no longer use "is part of trail A" in a PageSpec. --[[smcv]]
|
||||
|
||||
>> Do you have an example? --[[hendry]]
|
Loading…
Reference in New Issue