for a given (user, page, operation), as in:
<pre>
- \[[acl user=joe page=*.png allow=upload]]
- \[[acl user=bob page=/blog/bob/* allow=*]]
- \[[acl user=* page=/blog/bob/* deny=*]]
- \[[acl user=http://jeremie.koenig.myopenid.com/ page=/todo/* deny=create
+ \[[!acl user=joe page=*.png allow=upload]]
+ \[[!acl user=bob page=/blog/bob/* allow=*]]
+ \[[!acl user=* page=/blog/bob/* deny=*]]
+ \[[!acl user=http://jeremie.koenig.myopenid.com/ page=/todo/* deny=create
reason="spends his time writing todo items instead of source code"]]
</pre>
Possibly could refer to other ACL pages, as in:
<pre>
- \[[acl user=* page=/subsite/* acl=/subsite/acl.mdwn]]
+ \[[!acl user=* page=/subsite/* acl=/subsite/acl.mdwn]]
</pre>
any feed.
I found that the problem only occurs in the presence of a file that
-contains \[[inline pages="*"]].
+contains \[[!inline pages="*"]].
> How is this unexpected? By inlining _every_ page in the wiki, you're
> making that page depend on every other page; any change to any page in
cd /tmp
mkdir ikiwiki-test; cd ikiwiki-test; mkdir src
- echo '\[[inline pages="blog/*"]]' > src/myblog.mdwn
+ echo '\[[!inline pages="blog/*"]]' > src/myblog.mdwn
mkdir src/blog; echo "A blog entry" > src/blog/entry.mdwn
echo 'use IkiWiki::Setup::Standard {
srcdir => "src",
echo "not a blog entry" > src/not-a-blog.mdwn
ikiwiki --setup setup
ls -l --time-style=full-iso output/myblog/index.rss
- echo '\[[inline pages="*"]]' > src/archives.mdwn
+ echo '\[[!inline pages="*"]]' > src/archives.mdwn
ikiwiki --setup setup
ls -l --time-style=full-iso output/myblog/index.rss
echo "still not blogging" >> src/not-a-blog.mdwn
done
$ ls -l --time-style=full-iso output/myblog/index.rss
-rw-r--r-- 1 cworth cworth 459 2007-06-01 06:34:36.000000000 -0700 output/myblog/index.rss
- $ echo '\[[inline pages="*"]]' > src/archives.mdwn
+ $ echo '\[[!inline pages="*"]]' > src/archives.mdwn
$ ikiwiki --setup setup
refreshing wiki..
scanning archives.mdwn
Plugin can be downloaded from [here](http://myweb.unomaha.edu/~ajain/gallery.tar).
It can be used as : <br>
-\[[gallery imagedir="images" thumbnailsize="200x200" cols="3" alt="Can not be displayed" title="My Pictures"]]
+\[[!gallery imagedir="images" thumbnailsize="200x200" cols="3" alt="Can not be displayed" title="My Pictures"]]
where-<br>
* imagedir => Directory containing images. It will scan all the files with jpg|png|gif extension from the directory and will put it in the gallery.<br>
My current plan is :
-- thanks to the edittemplate plugin, `/view/dev/*` and `/view/howto/*` would contain respectively `\[[template id=dev_direction]]` and `\[[template id=howto_usage]]`
+- thanks to the edittemplate plugin, `/view/dev/*` and `/view/howto/*` would contain respectively `\[[!template id=dev_direction]]` and `\[[!template id=howto_usage]]`
- `/templates/dev_direction.mdwn` and `/templates/howto_usage.mdwn` would use `\[[!map ...]]` directives to build their views
# My issue
page inserting the template. But `BASENAME` does not exist. I found
that `<TMPL_VAR PAGE>` is replaced with the full path to the page, but
I did not found how to get the page's basename in a template included
-with a `\[[template id=...]]` directive.
+with a `\[[!template id=...]]` directive.
Any idea ?
most possible of these pages.
> The following patch adds a `basename` `TMPL_VAR` variable that can be
-> used in the templates inserted by \[[template plugin]] :
+> used in the templates inserted by \[[!template plugin]] :
> diff --git a/IkiWiki/Plugin/template.pm b/IkiWiki/Plugin/template.pm
> index a6e34fc..bb9dd8d 100644
* The inability to use spaces in wikilinks or link text
* The requirement to use a trailing space on a preprocessor directive
- with no arguments, such as `\[[toc ]]`
+ with no arguments, such as `\[[!toc ]]`
--[[JoshTriplett]]
-[[done]] in version 2.21, using the '!'-prefixed syntax. --[[JoshTriplett]]
\ No newline at end of file
+[[done]] in version 2.21, using the '!'-prefixed syntax. --[[JoshTriplett]]
-Currently, the page title (either the name of the page or the title specified with `\[[meta title="..."]]`) shows up in a `<div class="header">`. I tend to follow the [w3c guideline recommending the use of h1 for the title](http://www.w3.org/QA/Tips/Use_h1_for_Title); for this purpose, how about an option to make the page title an `<h1 class="header">`, and shift the markdown headings down by one (making # an h2, ## an h3, etc; or alternatively making # equivalent to `\[[meta title="..."]]`)?
+Currently, the page title (either the name of the page or the title specified with `\[[!meta title="..."]]`) shows up in a `<div class="header">`. I tend to follow the [w3c guideline recommending the use of h1 for the title](http://www.w3.org/QA/Tips/Use_h1_for_Title); for this purpose, how about an option to make the page title an `<h1 class="header">`, and shift the markdown headings down by one (making # an h2, ## an h3, etc; or alternatively making # equivalent to `\[[!meta title="..."]]`)?
> The reason I don't use a h1 for the navbar is that while it incorporates
> the page title, it's not just a page title, it has the links to parent pages.
> I agree that a plugin would probably be more cumbersome, but it is very
> doable. It might look something like this:
- \[[link bar]]
+ \[[!link bar]]
- \[[link bar=VeryLongPageName]]
+ \[[!link bar=VeryLongPageName]]
>> This is, however, still missing specifying the link text, and adding that option would seem to me to complicate the plugin syntax a lot, unless support is added for the |-syntax for specifying a particular parameter to every plugin.
>> ... Returning to this, the syntax infact wouldn't be so bad with the |-syntax, given a short name for the plugin:
[[whatever|ref 1]]
- \[[ref 1=page_with_long_name]]
+ \[[!ref 1=page_with_long_name]]
>>> A way to do this that doesn't need hacking at the preprocessor syntax
>>> follows: --[[Joey]]
- \[[link bar=1]]
- \[[dest 1=page_with_long_name]]
+ \[[!link bar=1]]
+ \[[!dest 1=page_with_long_name]]
>>>> But this doesn't work so well for links that aren't valid keys. Such
>>>> as stuff with spaces in it. I'd like to be able to write any kind of
>>>>> You're right, and to fix that it could be turned around: --[[Joey]]
- \[[link 1=bar]]
- \[[dest 1=page_with_long_name]]
+ \[[!link 1=bar]]
+ \[[!dest 1=page_with_long_name]]
>> It also shouldn't be difficult to support non-wiki links in this same
>> way, so that you could still link everywhere in an uniform manner, as
my blog to simply consist of all pages that have been tagged. That is,
I'd like to have my blog page look like this:
- \[[inline pages="link(tag/*)"]]
+ \[[!inline pages="link(tag/*)"]]
That doesn't work in ikiwiki 2.1, but I have it
[working](http://www.cworth.org/blog) with the following patch:
**OPT_DELAY** = delay=**D** | empty (*immediatelly*)
-\[[meta forward="**WHITHER**" **OPT_DELAY**]]
+\[[!meta forward="**WHITHER**" **OPT_DELAY**]]
# Extensions and Ideas
An option to have absolute urls in wikilinks instead of relative ones would be useful,
for pages included into other pages out of the wiki rendering process (shtml for example)
-since these pages can be included from a subdir. Ditto, links from \[[ inline ..]] or \[[map ..]].
+since these pages can be included from a subdir. Ditto, links from \[[!inline ..]] or \[[!map ..]].
> You can make a wikilink absolute by prefixing it with a /, see
> [[ikiwiki/subpage/linkingrules/]]. Pagespecs match absolute by default. But what do
> change. --Ethan
>> I want the "last pages" in my sidebar. and some links to a few special pages.
->> \[[inline ]] or \\[[map ]] in the sidebar is a bad idea, (because each update rebuilds
+>> \[[!inline ]] or \\[[!map ]] in the sidebar is a bad idea, (because each update rebuilds
>> all the wiki), so I use server-side-include instead of the sidebar plugin;
>> this reduces the dependencies
>> my sidebar is generated as http://foo.org/menu/index.html, so all the links generated by
->> \[[inline ]] or \[[map ]] are relative to this position.
+>> \[[!inline ]] or \[[!map ]] are relative to this position.
>> Included from http://foo.org/section/sub/blah/index.shtml, the links are broken.
>>
>> — NicolasLimare
I am serving notice that I am starting work on a calendar plugin inspired by Blosxom's calendar plugin. The current plan is to create a plugin that looks through all the source files matching a certain pagespec, and optionally spit out a month view for the specified month (default to current), or spit out a year view for a given year (defaulting to the current year), of a list of year with posts in them. The output would be a table, with the same CSS directives that the Blosxom plugin used to use (so that I can just reuse my css file). The links would be created to a $config{archivedir}/$year or $config{archivedir}/$year-$month file, which can just have
- \[[inline pages="blog/* and !*/Discussion and creation_year($year) and creation_month($month)" rss="no" atom="no" show="0"]]
+ \[[!inline pages="blog/* and !*/Discussion and creation_year($year) and creation_month($month)" rss="no" atom="no" show="0"]]
or some thing to generate a archive of postings.
This plugin is inspired by the calendar plugin for Blosxom, but derivesno code from it. This plugin is essentially a fancy front end to archives of previous pages, usually used for blogs. It can produce a calendar for a given month, or a list of months for a given year. To invoke the calendar, just use the preprocessor directive:
- \[[calendar ]]
+ \[[!calendar ]]
or
- \[[calendar type="month" pages="blog/* and !*/Discussion"]]
+ \[[!calendar type="month" pages="blog/* and !*/Discussion"]]
or
- \[[calendar type="year" year="2005" pages="blog/* and !*/Discussion"]]
+ \[[!calendar type="year" year="2005" pages="blog/* and !*/Discussion"]]
The year and month entities in the out put have links to archive index pages, which are supposed to exist already. The idea is to create an archives hierarchy, rooted in the subdirectory specified in the site-wide customization variable, archivebase. archivebase defaults to "archives". Links are created to pages "$archivebase/$year" and "$archivebase/$year/$month". The idea is to create annual and monthly indices, for example, by using something like this sample from my archives/2006/01.mdwn
- \[[meta title="Archives for 2006/01"]]
- \[[inline rootpage="blog" atom="no" rss="no" show="0" pages="blog/* and !*/Discussion and creation_year(2006) and creation_month(01)" ]]
+ \[[!meta title="Archives for 2006/01"]]
+ \[[!inline rootpage="blog" atom="no" rss="no" show="0" pages="blog/* and !*/Discussion and creation_year(2006) and creation_month(01)" ]]
I'll send in the patch via email.
> `<span>`. A preprocessor directive is not really any less ugly than html
> tags, though at least it could play nicely with nested markdown: --[[Joey]]
>
-> \[[color red,green """
+> \[[!color red,green """
> Xmas-colored markdown here
> """]]
I'd like to see some way to conditionally include wiki text based on
whether the wiki enables or disables certain features. For example,
-[[ikiwiki/formatting]], could use `\[[if (enabled smiley) """Also, because
+[[ikiwiki/formatting]], could use `\[[!if (enabled smiley) """Also, because
this wiki has the smiley plugin enabled, you can insert \[[smileys]] and
some other useful symbols."""]]`, and a standard template for [[plugins]]
pages could check for the given plugin name to print "enabled" or
> As to the syntax, to fit it into standard preprocessor syntax, it would
> need to look something like this:
>
-> \[[if test="enabled(smiley)" """foo"""]]
+> \[[!if test="enabled(smiley)" """foo"""]]
>
> --[[Joey]]
>>
>> A few use cases for `included`, which I would really like to see:
>>
->> * On the sidebar page, you could say something like \[[if test="!included"
+>> * On the sidebar page, you could say something like \[[!if test="!included"
>> """This page, without this help message, appears as a sidebar on all
>> pages."""]]. The help text would then only appear on the sidebar page
>> itself, not the sidebar included on all pages.
Is there a way to test features other than plugins? For example,
to add to [[ikiwiki/Markdown]] something like
- \[[if test="enabled(multimarkdown)" then="You can also use..."]]
+ \[[!if test="enabled(multimarkdown)" then="You can also use..."]]
(I tried it like that just to see if it would work, but I wasn't that lucky.)
--ChapmanFlack
>> Hmmm, what do you mean? Adding a syntax such as the one below?
>> Or something else?
- \[[if test="map(" then="..." else="..."]]
+ \[[!if test="map(" then="..." else="..."]]
>> What would you write in the `then` clause?
>> I'm not opposed at all to rewrite my two-liner, but I don't understand.
>> --[[intrigeri]]
- \[[if test="foo/*" then="""
- [[map pages="foo/*"]]
+ \[[!if test="foo/*" then="""
+ [[!map pages="foo/*"]]
""" else="no pages"]]
--[[Joey]]
height, compression, etc. which could be initially created by 'ikiwiki --generate-meta-stuff'.
Then PageSpec should be
teached to use these. Galleries could then be generated by means of
-\[[inline pages="type(image/*) and year(2007)" template="gallery"]]. It
+\[[!inline pages="type(image/*) and year(2007)" template="gallery"]]. It
should of course be possible to edit this information via ikiwiki.cgi and with any
text editor (Name: value). This should also allow for creations of default .html pages with
the image/video/file/... and a discussion page. Probably named image.mdwn and image/discussion.
Here is a patch for the [[plugins/meta]] plugin. It adds the possibility to define the language
-used for a page, with \[[meta lang="ja"]]
+used for a page, with \[[!meta lang="ja"]]
It doesn't insert the langage information in the xhtml meta elements, but defines a LANG
variable to use in the templates, for example with
> I'm thinking about renameing the preprocessor directive to teximg.
-> \[[teximg code="" alt="foo"]] makes sense.. Would it make sense to rename
+> \[[!teximg code="" alt="foo"]] makes sense.. Would it make sense to rename
> the whole plugin, or do you think that other tex stuff should go in this
> same plugin?
> So the idea is you'd write something like:
>
-> \[[meta rcsid="$Id$"]]
+> \[[!meta rcsid="$Id$"]]
>
> And this would be put at the bottom of the page or somewhere like that by
> the template?
There should be a way to add metadata to a page. Probably a plugin could do
this, for example:
- \[[meta foo="bar"]]
+ \[[!meta foo="bar"]]
Uses for this include:
something like this:
<pre>
-[[!missingparents pages="posts/* and !posts/*/*" generate="""[[template id=year text="$page"]]"""]]
-[[!missingparents pages="posts/*/* and !posts/*/*/*" generate="""[[template id=month text="$page"]]"""]]
-[[!missingparents pages="posts/*/*/* and !posts/*/*/*/*" generate="""[[template id=day text="$page"]]"""]]
+[[!missingparents pages="posts/* and !posts/*/*" generate="""[[!template id=year text="$page"]]"""]]
+[[!missingparents pages="posts/*/* and !posts/*/*/*" generate="""[[!template id=month text="$page"]]"""]]
+[[!missingparents pages="posts/*/*/* and !posts/*/*/*/*" generate="""[[!template id=day text="$page"]]"""]]
</pre>
And it scans the whole wiki for pages that match the pagespecs but are missing
>
> For example, I *think* you can unambiguously parse the following:
>
-> \[[if test="enabled(template) and templates/foo" then="""
-> [[template id=foo content="""Flying Purple People Eater"""]]
+> \[[!if test="enabled(template) and templates/foo" then="""
+> [[!template id=foo content="""Flying Purple People Eater"""]]
> """]]
>
> --[[JoshTriplett]]
Maybe this can be enhanced with a [[ikiwiki/PreprocessorDirective]]:
<pre>
-\[[suggest op=merge dstfile=trunk srcfile=branches/jk oldrev=1234 newrev=1342]]
+\[[!suggest op=merge dstfile=trunk srcfile=branches/jk oldrev=1234 newrev=1342]]
-\[[suggest op=move srcpage=/blog dstpage=/blog_support]]
+\[[!suggest op=move srcpage=/blog dstpage=/blog_support]]
-\[[suggest patch="""
+\[[!suggest patch="""
Index: IkiWiki/CGI.pm
===================================================================
--- IkiWiki/CGI.pm (révision 4119)
Here's a full design for redoing recentchanges, based on Ethan's ideas:
* Add a recentchanges plugin that has a preprocessor directive:
- \[[recentchanges num=100 pages=* template=recentchanges.tmpl]]
+ \[[!recentchanges num=100 pages=* template=recentchanges.tmpl]]
If put on the [[recentchanges]] page, this would result in up to 100
recentchanges/change_$id.mdwn files being created.
* Which means the plugin has to store state and use a checkconfig hook
[[plugins/shortcut]] creates link shortcut [[ikiwiki/PreprocessorDirective]]s,
which substitute their argument into the specified shortcut URL to generate
the link target, and use the argument as the link text. For example, given
-the example [[shortcuts]], `\[[wikipedia ikiwiki]]` generates a link to
+the example [[shortcuts]], `\[[!wikipedia ikiwiki]]` generates a link to
<http://en.wikipedia.org/wiki/ikiwiki>, with the link text "ikiwiki". This
works well in many cases; however, for things like the `debbug` example, it
simply uses the number as the link text, which does not always provide
enough context to understand the link at first glance. For example,
-`\[[debbug 397501]]` generates a link to <http://bugs.debian.org/397501>,
+`\[[!debbug 397501]]` generates a link to <http://bugs.debian.org/397501>,
with just "397501" as the link text. While [[plugins/template]] provides a
general solution for arbitrary cases, it would help to have a simple option
via the shortcut plugin to set the link text, with a `%s` substitution.
-Thus, something like `\[[shortcut name=debbug
+Thus, something like `\[[!shortcut name=debbug
url="http://bugs.debian.org/%s" desc="bug #%s"]]` might suffice on a
Debian-specific wiki to indicate a bug number, while a more general wiki
-might use something like `\[[shortcut name=debbug
+might use something like `\[[!shortcut name=debbug
url="http://bugs.debian.org/%s" desc="Debian bug #%s"]]`.
> [[todo/done]] --[[Joey]]
To create a "debfiles" [[shortcut|shortcuts]] that takes a package name, you
could just hardcode the architecture and distribution:
- \[[shortcut name=debfiles url="http://packages.debian.org/cgi-bin/search_contents.pl?word=%s&searchmode=filelist&case=insensitive&version=unstable&arch=i386"]]
- \[[debfiles ikiwiki]]
+ \[[!shortcut name=debfiles url="http://packages.debian.org/cgi-bin/search_contents.pl?word=%s&searchmode=filelist&case=insensitive&version=unstable&arch=i386"]]
+ \[[!debfiles ikiwiki]]
But what if you could have them as optional parameters instead? The syntax
for the invocation should look like this:
- \[[debfiles ikiwiki dist=testing]]
+ \[[!debfiles ikiwiki dist=testing]]
Some possible syntax choices for the shortcut definition:
- \[[shortcut name=debfiles url="http://packages.debian.org/cgi-bin/search_contents.pl?word=%s&searchmode=filelist&case=insensitive&version=%(dist)s&arch=%(arch)s" dist="unstable" arch="i386"]]
- \[[shortcut name=debfiles url="http://packages.debian.org/cgi-bin/search_contents.pl?word=%s&searchmode=filelist&case=insensitive&version=%(dist=unstable)s&arch=%(arch=i386)s"]]
- \[[shortcut name=debfiles url="http://packages.debian.org/cgi-bin/search_contents.pl?word=%s&searchmode=filelist&case=insensitive&version=%{dist=unstable}&arch=%{arch=i386}"]]
- \[[shortcut name=debfiles url="http://packages.debian.org/cgi-bin/search_contents.pl?word=$*&searchmode=filelist&case=insensitive&version=${dist=unstable}&arch=${arch=i386}"]]
+ \[[!shortcut name=debfiles url="http://packages.debian.org/cgi-bin/search_contents.pl?word=%s&searchmode=filelist&case=insensitive&version=%(dist)s&arch=%(arch)s" dist="unstable" arch="i386"]]
+ \[[!shortcut name=debfiles url="http://packages.debian.org/cgi-bin/search_contents.pl?word=%s&searchmode=filelist&case=insensitive&version=%(dist=unstable)s&arch=%(arch=i386)s"]]
+ \[[!shortcut name=debfiles url="http://packages.debian.org/cgi-bin/search_contents.pl?word=%s&searchmode=filelist&case=insensitive&version=%{dist=unstable}&arch=%{arch=i386}"]]
+ \[[!shortcut name=debfiles url="http://packages.debian.org/cgi-bin/search_contents.pl?word=$*&searchmode=filelist&case=insensitive&version=${dist=unstable}&arch=${arch=i386}"]]
--[[JoshTriplett]]
Well, you can already do this kind of thing with templates. Invocation does
look different:
- \[[template id=debfiles package=ikiwiki dist=testing]]
+ \[[!template id=debfiles package=ikiwiki dist=testing]]
--[[Joey]]
> I think I would find templates sufficient, if:
>
> 1. I could use the name of the template as a preprocessor directive
-> (`\[[templatename ...]]`), rather than using the `template` directive
-> with an `id` argument (`\[[template id=templatename]]`).
+> (`\[[!templatename ...]]`), rather than using the `template` directive
+> with an `id` argument (`\[[!template id=templatename]]`).
> 2. Template invocation allowed bare values in addition to `key=value`
> arguments, and template definition supported some means to access the
-> value. This would allow `\[[debfiles ikiwiki]]` rather than
-> `\[[debfiles package=ikiwiki]]`.
+> value. This would allow `\[[!debfiles ikiwiki]]` rather than
+> `\[[!debfiles package=ikiwiki]]`.
> 3. I could use ikiwiki syntax in the template, not just HTML and
> HTML::Template. (If I can already do that, then [[/plugins/template]]
> should make that more clear.)
> If I don't understand this, can you give an HTML example? --[[JeremyReed]]
>> The problem is like that in [[bugs/shortcuts_don't_escape_from_Markdown]]. We would like to use
->> the shortcuts plugin but add a descriptive text -- in this case \[[xcbgit src/xcb.xsd|XML Schema...]]
+>> the shortcuts plugin but add a descriptive text -- in this case \[[!xcbgit src/xcb.xsd|XML Schema...]]
>> The file src/xcb.xsd could be any url, and the point of shortcuts is that you get to shorten it.
>> --Ethan
>>> However, I want to define a [[plugins/shortcut]] to save the typing. If I
>>> define something like `protogit` pointing to
>>> `http://gitweb.freedesktop.org/?p=xcb/proto.git;a=blob;hb=HEAD;f=%s`, then
->>> I can write `\[[protogit src/xcb.xsd]]`; however, I then can't change the
+>>> I can write `\[[!protogit src/xcb.xsd]]`; however, I then can't change the
>>> link text to anything other than what the shortcut defines as the link
>>> text. I want to write something like
>>> `\[[XML Schema for the X Window System Protocol|protogit src/xcb.xsd]]`,
---
-One possible alternative, would be a general `\[[url ]]` scheme for all kinds of links. As mentioned in [[Short_wikilinks]], I have wanted a way to enter links to the wiki with markdown-style references,
+One possible alternative, would be a general `\[[!url ]]` scheme for all kinds of links. As mentioned in [[Short_wikilinks]], I have wanted a way to enter links to the wiki with markdown-style references,
specifying the actual target elsewhere from the text, with just a short reference in the text. To facilitate automatic conversion from earlier (already markdownised) "blog", I finally ended up writing a custom plugin that simply gets the location of wikipage, and use markdown mechanisms:
Here [is][1] a link.
So that the 'l' plugin inserts the location the page there, and markdown does the rest. My plugin currently fails if it can't find the page, as that is sufficient for my needs. Differing colouring for non-existing pages is not doable in a straightforward manner with this approach.
-For external links, that is no concern, however. So you could define for each shortcut an alternative directive, that inserts the URL. Perhaps `\[[url shortcutname params]]` or `\[[@shortcutname params]]` (if the preprocessor supported the @), and this could be extended to local links in an obvious manner: `\[[url page]]` or `\[[@page]]`. Now, if you could just get rid off the parantheses for markdown, for the short inline links --[[tuomov]] (who'd really rather not have two separate linking mechanisms: ikiwiki's heavy syntax and markdown's lighter one).
+For external links, that is no concern, however. So you could define for each shortcut an alternative directive, that inserts the URL. Perhaps `\[[!url shortcutname params]]` or `\[[@shortcutname params]]` (if the preprocessor supported the @), and this could be extended to local links in an obvious manner: `\[[!url page]]` or `\[[@page]]`. Now, if you could just get rid off the parantheses for markdown, for the short inline links --[[tuomov]] (who'd really rather not have two separate linking mechanisms: ikiwiki's heavy syntax and markdown's lighter one).
---
-I've added code to make the \[[foo 123]] syntax accept a _desc_
+I've added code to make the \[[!foo 123]] syntax accept a _desc_
parameter. I've named it like this to signal that it overrides the
_desc_ provided at description time. `%s` is expanded here as well.
> `url` still seems reasonable, and simple. You could also use such shortcuts
> without markup at all, as an abbreviation mechanism:
>
-> \[[shortcut name=spi desc="Software in the Public Interest, Inc."]]].
-> \[[shortcut name=sosp desc="Symposium on Operating System Principles"]]].
-> \[[shortcut name=cacm desc="Communications of the ACM"]]].
+> \[[!shortcut name=spi desc="Software in the Public Interest, Inc."]]].
+> \[[!shortcut name=sosp desc="Symposium on Operating System Principles"]]].
+> \[[!shortcut name=cacm desc="Communications of the ACM"]]].
>
> --[[JoshTriplett]]
Other special things in my templates and site:
-* a sidebar with \[[include pages="notes/\*" template=foo]] while notes.mdwn has
- a \[[include pages="notes/*"]] and uses the sidebar; removed it, doesn't change
+* a sidebar with \[[!include pages="notes/\*" template=foo]] while notes.mdwn has
+ a \[[!include pages="notes/*"]] and uses the sidebar; removed it, doesn't change
* a template (biblio.tmpl) calling the "img" plugin with a template parameter as the
image filename; removed it, doesn't change
* some strange games with tags whose page calls a "map" directive to show other tags
How about a skip option for [[plugins/inline]]? This would allow things like the following:
- \[[inline pages="news/*" show="5"]]
- \[[inline pages="news/*" skip="5" show="5" archive="yes"]]
+ \[[!inline pages="news/*" show="5"]]
+ \[[!inline pages="news/*" skip="5" show="5" archive="yes"]]
> I just wrote a patch. --Ethan
It would be great if I could to this:
- \[[toc levels=3 skip=1]]
+ \[[!toc levels=3 skip=1]]
I use h1 for big title on each page, and don't want it in my toc on that page.
> another option is added, I wonder why you're using a h1 for a title on
> each page when the page name already appears at the top of each page. And
> if the page name isn't right for the title, you can use
-> \[[meta title="foo"]] to override it. And this purposefully doesn't show
+> \[[!meta title="foo"]] to override it. And this purposefully doesn't show
> up in the toc. --[[Joey]]
>> aaaahhh, I made a mistake. U used some other page.tmpl and title was hidden,
> I think you could now implement "toplvl" using [[conditionals|/plugins/conditional]]:
>
-> \[[if test="destpage(/index)" then="""...""" else="""..."""]]
+> \[[!if test="destpage(/index)" then="""...""" else="""..."""]]
>
> --[[JoshTriplett]]
projects / ikiwiki.git / commitdiff