This is ikiwiki's bug list. Link bugs to [[bugs/done]] when done.
-Also see the [Debian bugs](http://bugs.debian.org/ikiwiki).
+Also see the [Debian bugs](http://bugs.debian.org/ikiwiki), and the
+[[TODO]] page.
[[inline pages="bugs/* and !bugs/done and !bugs/discussion and
!link(bugs/done) and !bugs/*/*"
1. Make command-line arguments override settings in the setup file
> This is difficult to do, since reading a setup file replaces values for
-> config items with the values in the setup file.
+> config items with the values in the setup file. Also, when you say
+> --setup foo, you're asking ikiwiki to set up the wiki using the
+> comnfiguration in file foo. Which is what it does.
2. Comment out all settings in the example setup file that are simply
setting options to their default values. That way, the file will
work for these settings while they remain commented out.
> I've done that, I also fixed some issues with --verbose handling earlier.
+> I'm pretty sure that those fixes fix the real issue, so calling this
+> [[done]].
> --[[Joey]]
+++ /dev/null
-Hi,
-
-some operating systems use PREFIX/man instead of PREFIX/share/man as the base
-directory for man pages and PREFIX/libexec/ instead of PREFIX/lib/ for files
-like CGI programs.
-At the moment the location of the installed man pages and the w3m cgi wrapper
-is hard-coded in Makefile.PL.
-The patch below makes it possible to install those files to alternative directories
-while the default stays as it is now.
-
-> It should be possible to use the existing MakeMaker variables such as
-> INSTALLMAN1DIR (though MakeMaker lacks one for man8). I'd prefer not
-> adding new variables where MakeMaker already has them. --[[Joey]]
-
-<pre>
-
- - Introduce two variables, IKI_MANDIR and IKI_W3MCGIDIR, to be set from
- the command line. This enables locations for man pages and the w3m
- cgi wrapper other than the hard-coded defaults in Makefile.PL.
-
---- Makefile.PL.orig 2007-05-20 03:03:58.000000000 +0200
-+++ Makefile.PL
-@@ -3,9 +3,32 @@ use warnings;
- use strict;
- use ExtUtils::MakeMaker;
-
-+my %params = ( 'IKI_MANDIR' => '$(PREFIX)/share/man',
-+ 'IKI_W3MCGIDIR' => '$(PREFIX)/lib/w3m/cgi-bin'
-+ );
-+
-+@ARGV = grep {
-+ my ($key, $value) = split(/=/, $_, 2);
-+ if ( exists $params{$key} ) {
-+ $params{$key} = $value;
-+ print "Using $params{$key} for $key.\n";
-+ 0
-+ } else {
-+ 1
-+ }
-+} @ARGV;
-+
-+
- # Add a few more targets.
- sub MY::postamble {
--q{
-+ package MY;
-+
-+ my $scriptvars = <<"EOSCRIPTVARS";
-+IKI_MANDIR = $params{'IKI_MANDIR'}
-+IKI_W3MCGIDIR = $params{'IKI_W3MCGIDIR'}
-+EOSCRIPTVARS
-+
-+ my $script = q{
- all:: extra_build
- clean:: extra_clean
- install:: extra_install
-@@ -56,23 +79,24 @@ extra_install:
- done; \
- done
-
-- install -d $(DESTDIR)$(PREFIX)/share/man/man1
-- install -m 644 ikiwiki.man $(DESTDIR)$(PREFIX)/share/man/man1/ikiwiki.1
-+ install -d $(DESTDIR)$(IKI_MANDIR)/man1
-+ install -m 644 ikiwiki.man $(DESTDIR)$(IKI_MANDIR)/man1/ikiwiki.1
-
-- install -d $(DESTDIR)$(PREFIX)/share/man/man8
-- install -m 644 ikiwiki-mass-rebuild.man $(DESTDIR)$(PREFIX)/share/man/ma
-n8/ikiwiki-mass-rebuild.8
-+ install -d $(DESTDIR)$(IKI_MANDIR)/man8
-+ install -m 644 ikiwiki-mass-rebuild.man $(DESTDIR)$(IKI_MANDIR)/man8/iki
-wiki-mass-rebuild.8
-
- install -d $(DESTDIR)$(PREFIX)/sbin
- install ikiwiki-mass-rebuild $(DESTDIR)$(PREFIX)/sbin
-
-- install -d $(DESTDIR)$(PREFIX)/lib/w3m/cgi-bin
-- install ikiwiki-w3m.cgi $(DESTDIR)$(PREFIX)/lib/w3m/cgi-bin
-+ install -d $(DESTDIR)$(IKI_W3MCGIDIR)
-+ install ikiwiki-w3m.cgi $(DESTDIR)$(IKI_W3MCGIDIR)
-
- install -d $(DESTDIR)$(PREFIX)/bin
- install ikiwiki.out $(DESTDIR)$(PREFIX)/bin/ikiwiki
-
- $(MAKE) -C po install PREFIX=$(PREFIX)
--}
-+};
-+ return $scriptvars.$script;
- }
-
- WriteMakefile(
-
-</pre>
+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"]]
+
+or some thing to generate a archive of postings.
+
+Roland Mas suggested a separate cron job to generate these archive indices automatically, but that is another thread.
+
+ManojSrivastava
+
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 ]]
--- /dev/null
+Hi,
+
+some operating systems use PREFIX/man instead of PREFIX/share/man as the base
+directory for man pages and PREFIX/libexec/ instead of PREFIX/lib/ for files
+like CGI programs.
+At the moment the location of the installed man pages and the w3m cgi wrapper
+is hard-coded in Makefile.PL.
+The patch below makes it possible to install those files to alternative directories
+while the default stays as it is now.
+
+> It should be possible to use the existing MakeMaker variables such as
+> INSTALLMAN1DIR (though MakeMaker lacks one for man8). I'd prefer not
+> adding new variables where MakeMaker already has them. --[[Joey]]
+
+<pre>
+
+ - Introduce two variables, IKI_MANDIR and IKI_W3MCGIDIR, to be set from
+ the command line. This enables locations for man pages and the w3m
+ cgi wrapper other than the hard-coded defaults in Makefile.PL.
+
+--- Makefile.PL.orig 2007-05-20 03:03:58.000000000 +0200
++++ Makefile.PL
+@@ -3,9 +3,32 @@ use warnings;
+ use strict;
+ use ExtUtils::MakeMaker;
+
++my %params = ( 'IKI_MANDIR' => '$(PREFIX)/share/man',
++ 'IKI_W3MCGIDIR' => '$(PREFIX)/lib/w3m/cgi-bin'
++ );
++
++@ARGV = grep {
++ my ($key, $value) = split(/=/, $_, 2);
++ if ( exists $params{$key} ) {
++ $params{$key} = $value;
++ print "Using $params{$key} for $key.\n";
++ 0
++ } else {
++ 1
++ }
++} @ARGV;
++
++
+ # Add a few more targets.
+ sub MY::postamble {
+-q{
++ package MY;
++
++ my $scriptvars = <<"EOSCRIPTVARS";
++IKI_MANDIR = $params{'IKI_MANDIR'}
++IKI_W3MCGIDIR = $params{'IKI_W3MCGIDIR'}
++EOSCRIPTVARS
++
++ my $script = q{
+ all:: extra_build
+ clean:: extra_clean
+ install:: extra_install
+@@ -56,23 +79,24 @@ extra_install:
+ done; \
+ done
+
+- install -d $(DESTDIR)$(PREFIX)/share/man/man1
+- install -m 644 ikiwiki.man $(DESTDIR)$(PREFIX)/share/man/man1/ikiwiki.1
++ install -d $(DESTDIR)$(IKI_MANDIR)/man1
++ install -m 644 ikiwiki.man $(DESTDIR)$(IKI_MANDIR)/man1/ikiwiki.1
+
+- install -d $(DESTDIR)$(PREFIX)/share/man/man8
+- install -m 644 ikiwiki-mass-rebuild.man $(DESTDIR)$(PREFIX)/share/man/ma
+n8/ikiwiki-mass-rebuild.8
++ install -d $(DESTDIR)$(IKI_MANDIR)/man8
++ install -m 644 ikiwiki-mass-rebuild.man $(DESTDIR)$(IKI_MANDIR)/man8/iki
+wiki-mass-rebuild.8
+
+ install -d $(DESTDIR)$(PREFIX)/sbin
+ install ikiwiki-mass-rebuild $(DESTDIR)$(PREFIX)/sbin
+
+- install -d $(DESTDIR)$(PREFIX)/lib/w3m/cgi-bin
+- install ikiwiki-w3m.cgi $(DESTDIR)$(PREFIX)/lib/w3m/cgi-bin
++ install -d $(DESTDIR)$(IKI_W3MCGIDIR)
++ install ikiwiki-w3m.cgi $(DESTDIR)$(IKI_W3MCGIDIR)
+
+ install -d $(DESTDIR)$(PREFIX)/bin
+ install ikiwiki.out $(DESTDIR)$(PREFIX)/bin/ikiwiki
+
+ $(MAKE) -C po install PREFIX=$(PREFIX)
+-}
++};
++ return $scriptvars.$script;
+ }
+
+ WriteMakefile(
+
+</pre>
--[[JoshTriplett]]
[[tag soc]]
+
+[[wishlist]]
> is that it provides a GUI for editing with widets for italics, etc,
> compared to showdown which still leaves input in markdown and seems more
> geared to a fast preview of the html. --[[Joey]]
+
+> Since we have semi-working wikiwgy and it's better, I'm considering this
+> todo item as [[done]] or rather, will-not-be-done..
[scmbug](http://www.mkgnu.net/?q=scmbug) might help here. --[[JoshTriplett]]
[[tag soc]]
+
+[[tag wishlist]]
>> By Google BTS, do you mean the issue tracker in the Google code
>> project hosting?
>>
->> --Teemu
\ No newline at end of file
+>> --Teemu
+
+[[wishlist]]
--[[JoshTriplett]]
-[[tag soc]]
+[[tag soc]] [[tag wishlist]]
+++ /dev/null
-I think there is a problem in my "dependency graph". As an example,
-[here](http://poivron.org/~nil/misc/ikiwiki_buggy_index) is the index
-ikiwiki generated for [my site](http://poivron.org/~nil/misc/ikiwiki_buggy_index)
-(note that the site changed since this index was generated).
-
-Some **HUGE** dependencies appear, clearly non optimal, like
-
- depends = A｜ B | A | C | A | D | A | E | A | F | A | G | ....
-
-or
-
- depends= A | B | C | D | A | B | C | D | A | B | C | D | ....
-
-Couldn't isolate the cause, but some sources for this problem may be:
-
-* related to the img module
-* easily observable in my sire because one of my pages includes 80 resized images
-
-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 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
- shile tags are also used in tagclouds (in the sidebar and in the main pages)
-* ...
-
-I observed these problems (same *kind*, I didn't check in details) on
-
-* ikiwiki 2.00gpa1 + v5.8.4 + Debian 3.1
-* ikiwiki 2.3 + v5.8.8 + Ubuntu 7.04
-
-I can think about reducung the size of my wiki source and making it available online for analysis.
-
--- NicolasLimare
-
-> As long as these dependencies don't grow over time (ie, when a page is
-> edited and nothing changed that should add a dependency), I wouldn't
-> worry about them. There are many things that can cause non-optimal
-> dependencies to be recorded. For one thing, if you inline something, ikiwiki
-> creates a dependency like:
->
-> (PageSpec) or (file1 or file2 or file3 ...)
->
-> Where fileN are all the files that the PageSpec currently matches. (This
-> is ncessary to detect when a currently inlined file is deleted, and know
-> the inlining page needs an update.) Now consider what it does if you have
-> a single page with two inline statements, that inline the same set of
-> stuff twice:
->
-> ((PageSpec) or (file1 or file2 or file3 ...) or (PageSpec) or (file1 or file2 or file3 ...)
->
-> Clearly non-optimal, indeed.
->
-> Ikiwiki doesn't bother to simplify complex PageSpecs
-> because it's difficult to do, and because all they use is some disk
-> space. Consider what ikiwiki uses these dependencies for.
-> All it wants to know is: does the PageSpec for this page it's considering
-> rebuilding match any of the pages that have changed? Determining this is
-> a simple operation -- the PageSpec is converted to perl code. The perl
-> code is run.
->
-> So the total impact of an ugly dependency like this is:
->
-> 1. Some extra data read/written to disk.
-> 2. Some extra space in memory.
-> 3. A bit more data for the PageSpec translation code to handle. But that
-> code is quite fast.
-> 4. Typically one extra function call when the generated perl code is run.
-> Ie, when the expression on the left-hand side fails, which typically
-> happens after one (inexpensive) function call, it has to check
-> the identical expression on the right hand side.
->
-> So this is at best a wishlist todo item, not a bug. A PageSpec simplifier
-> (or improved `pagespec_merge()` function) could be written and improve
-> ikiwiki's memory and disk usage, but would it actually speed it up any?
-> We'd have to see the code to the simplifier to know.
->
-> --[[Joey]]
-
-[[tag wishlist]]
+++ /dev/null
-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"]]
-
-or some thing to generate a archive of postings.
-
-Roland Mas suggested a separate cron job to generate these archive indices automatically, but that is another thread.
-
-ManojSrivastava
\ No newline at end of file
ikiwiki could support rendering and editing po files via the web. Run against
a software repository, ikiwiki would make for an interesting
-translation-management tool. --[[JoshTriplett]]
\ No newline at end of file
+translation-management tool. --[[JoshTriplett]]
+
+[[wishlist]]
A simple script should be able to poll for the irc topic and update a page,
then run ikiwiki -refresh to update the wiki. No need to put that in
ikiwiki or a plugin, though. --[[Joey]]
+
+[[wishlist]]
That looks pretty good.. putting the passwordauth part in a box of its own with
the submit buttons I don't know how to do.
+I'm happy enough with what we have now though, with the above improvements.
+Hope you are too, as I'm calling this [[done]]..
+
--[[Joey]]
contain the wiki title from `ikiwiki.setup`.
--[[JoshTriplett]]
+
+[[wishlist]]
ikiwiki could provide one or more plugins that provide "add to" links for popular feed readers, such as Google Reader, Bloglines, My Yahoo!, or Netvibes.
Potentially less useful given an implementation of [[todo/integration_with_Firefox_and_Iceweasel_feed_subscription_mechanism]].
---[[JoshTriplett]]
\ No newline at end of file
+--[[JoshTriplett]]
+
+[[wishlist]]
>> I'd love to see support for this and would be happy to contribute towards a bounty (say US$100) :-). [PmWiki](http://www.pmwiki.org/) has a plugin which [implements this](http://www.pmwiki.org/wiki/Cookbook/XMLRPC) in a way which seems fairly sensible as an end user. --[[AdamShand]]
[[tag soc]]
+
+[[tag wishlist]]
We might want some kind of abbreviation and acronym plugin. --[[JoshTriplett]]
- * Not sure if this is what you mean, but I'd love a way to make works which match existing page names automatically like (eg. if there is a page called "MySQL" then any time the word MySQL is mentioned it should become a link to that page). -- [[AdamShand]]
\ No newline at end of file
+ * Not sure if this is what you mean, but I'd love a way to make works which match existing page names automatically like (eg. if there is a page called "MySQL" then any time the word MySQL is mentioned it should become a link to that page). -- [[AdamShand]]
+
+[[wishlist]]
> I agree that having this as an option is reasonable. Although it would
> take a fair amount of work. --[[Joey]]
+
+[[tag wishlist]]
-Wishlist: optionally use the [[plugins/contrib/syntax]] plugin automatically on source code files in the repository with recognized extensions or shebangs, and render them as though they consisted of an [[.mdwn|markdown]] page containing nothing but a single call to the syntax plugin with the file contents as the text argument and the recognized type as the type argument.
+[[Wishlist]]: optionally use the [[plugins/contrib/syntax]] plugin automatically on source code files in the repository with recognized extensions or shebangs, and render them as though they consisted of an [[.mdwn|markdown]] page containing nothing but a single call to the syntax plugin with the file contents as the text argument and the recognized type as the type argument.
-Together with the ability to have [[wiki-formatted_comments|wiki-formatted_comments_with_syntax_plugin]], this would allow the use of ikiwiki for [[wikipedia literate programming]].
\ No newline at end of file
+Together with the ability to have [[wiki-formatted_comments|wiki-formatted_comments_with_syntax_plugin]], this would allow the use of ikiwiki for [[wikipedia literate programming]].
described at [[todo/fileupload]].
--[[JoshTriplett]]
+
+[[wishlist]]
>> That wouldn't use the same style for the RSS and Atom links, and it
>> wouldn't embed the feed link into `<head>` so that browsers can automatically
>> find it.
+
+[[tag wishlist]]
Should be doable w/o touching a single line of code, just
editing the [[wikitemplates]] and/or editing [[style.css]].
+
+[[done]] ([[css_market]] ..)
<ikihacker> \[[setup]]
<ikibot> http://ikiwiki.info/setup.html: "This tutorial will walk you through setting up a wiki with ikiwiki. ..."
---[[JoshTriplett]]
\ No newline at end of file
+--[[JoshTriplett]]
+
+[[wishlist]]
on their site. We could then provide the manual configuration settings as a
[[tip|tips]], and perhaps provide an extension or other mechanism to set them
automatically. --[[JoshTriplett]]
+
+[[wishlist]]
-----
[[tag soc]]
+
+[[tag wishlist]]
However, that also seems like potential overkill, and less important than the
basic functionality of `linktitle`.
--[[JoshTriplett]]
+
+[[wishlist]]
ikiwiki could support manpages (or general groff input files) and convert them
to HTML. --[[JoshTriplett]]
+
+[[wishlist]]
Hmm, I think the pagetemplate hook should allow one to get close enough to
this in a plugin now.
+
+See also: [[Allow_per-page_template_selection]] -- same thing, really.
* Password protection?
-- [[JoshTriplett]]
+
+[[wishlist]]
-Ikiwiki could optionally use rel=nofollow on all external links, or on all those from a configurable subset of pages (such as */discussion if using [[plugins/opendiscussion]]). --[[JoshTriplett]]
\ No newline at end of file
+Ikiwiki could optionally use rel=nofollow on all external links, or on all those from a configurable subset of pages (such as */discussion if using [[plugins/opendiscussion]]). --[[JoshTriplett]]
+
+> This is tricky, and would need a html parser, since external links can be
+> added in lots of ways including raw in markdown. --[[Joey]]
--- /dev/null
+I think there is a problem in my "dependency graph". As an example,
+[here](http://poivron.org/~nil/misc/ikiwiki_buggy_index) is the index
+ikiwiki generated for [my site](http://poivron.org/~nil/misc/ikiwiki_buggy_index)
+(note that the site changed since this index was generated).
+
+Some **HUGE** dependencies appear, clearly non optimal, like
+
+ depends = A｜ B | A | C | A | D | A | E | A | F | A | G | ....
+
+or
+
+ depends= A | B | C | D | A | B | C | D | A | B | C | D | ....
+
+Couldn't isolate the cause, but some sources for this problem may be:
+
+* related to the img module
+* easily observable in my sire because one of my pages includes 80 resized images
+
+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 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
+ shile tags are also used in tagclouds (in the sidebar and in the main pages)
+* ...
+
+I observed these problems (same *kind*, I didn't check in details) on
+
+* ikiwiki 2.00gpa1 + v5.8.4 + Debian 3.1
+* ikiwiki 2.3 + v5.8.8 + Ubuntu 7.04
+
+I can think about reducung the size of my wiki source and making it available online for analysis.
+
+-- NicolasLimare
+
+> As long as these dependencies don't grow over time (ie, when a page is
+> edited and nothing changed that should add a dependency), I wouldn't
+> worry about them. There are many things that can cause non-optimal
+> dependencies to be recorded. For one thing, if you inline something, ikiwiki
+> creates a dependency like:
+>
+> (PageSpec) or (file1 or file2 or file3 ...)
+>
+> Where fileN are all the files that the PageSpec currently matches. (This
+> is ncessary to detect when a currently inlined file is deleted, and know
+> the inlining page needs an update.) Now consider what it does if you have
+> a single page with two inline statements, that inline the same set of
+> stuff twice:
+>
+> ((PageSpec) or (file1 or file2 or file3 ...) or (PageSpec) or (file1 or file2 or file3 ...)
+>
+> Clearly non-optimal, indeed.
+>
+> Ikiwiki doesn't bother to simplify complex PageSpecs
+> because it's difficult to do, and because all they use is some disk
+> space. Consider what ikiwiki uses these dependencies for.
+> All it wants to know is: does the PageSpec for this page it's considering
+> rebuilding match any of the pages that have changed? Determining this is
+> a simple operation -- the PageSpec is converted to perl code. The perl
+> code is run.
+>
+> So the total impact of an ugly dependency like this is:
+>
+> 1. Some extra data read/written to disk.
+> 2. Some extra space in memory.
+> 3. A bit more data for the PageSpec translation code to handle. But that
+> code is quite fast.
+> 4. Typically one extra function call when the generated perl code is run.
+> Ie, when the expression on the left-hand side fails, which typically
+> happens after one (inexpensive) function call, it has to check
+> the identical expression on the right hand side.
+>
+> So this is at best a wishlist todo item, not a bug. A PageSpec simplifier
+> (or improved `pagespec_merge()` function) could be written and improve
+> ikiwiki's memory and disk usage, but would it actually speed it up any?
+> We'd have to see the code to the simplifier to know.
+>
+> --[[Joey]]
+
+[[tag wishlist]]
-How about a direct link from the page header to the source of the latest version, to avoid the need to either use edit or navigate to the current version via the history link?
\ No newline at end of file
+How about a direct link from the page header to the source of the latest version, to avoid the need to either use edit or navigate to the current version via the history link?
----
-Firefox 2 (or whatever it will be in Debian) does this for you, and then there's the mozex extension
\ No newline at end of file
+Firefox 2 (or whatever it will be in Debian) does this for you, and then there's the mozex extension
+
+> Yeah, IMHO gecko's spellchecker nailed this. Spellcheckers server-side
+> are now passe. Calling this [[done]] --[[Joey]]
* We could support editing SVGs via the web interface. SVG can contain unsafe content such as scripting, so we would need to whitelist safe markup.
---[[JoshTriplett]]
\ No newline at end of file
+--[[JoshTriplett]]
+
+[[wishlist]]
This is one good argument for changing ikiwiki so that pages are all
dir/index.html, then a link to just "dir" works.
+
+ So this could be implemented now for userdirs wikis..
-We could support web-based image editing, using something like [Snipshot](http://snipshot.com/). Several comparisons of web-based image editors exist; we would need to choose which one(s) to support. --[[JoshTriplett]]
\ No newline at end of file
+We could support web-based image editing, using something like [Snipshot](http://snipshot.com/). Several comparisons of web-based image editors exist; we would need to choose which one(s) to support. --[[JoshTriplett]]
+
+[[wishlist]]
MoinMoin has a simple implementation of this, [click here to see an example](http://www.spack.org/wiki/SandBox?action=edit&editor=text).
---[[AdamShand]]
\ No newline at end of file
+--[[AdamShand]]
+
+[[tag wishlist]]
-Wishlist item: I'd love to see the ability to optionally switch back to wiki syntax within the comments of code pretty-printed with the [[plugins/contrib/syntax]] plugin. This would allow the use of links and formatting in comments.
\ No newline at end of file
+[[Wishlist]] item: I'd love to see the ability to optionally switch back to wiki syntax within the comments of code pretty-printed with the [[plugins/contrib/syntax]] plugin. This would allow the use of links and formatting in comments.
off in WikiText mode.
[[tag soc]]
+
+[[tag wishlist]]