more triage

master
joey 2007-07-25 03:08:10 +00:00
parent 2210c65083
commit 7558a6d8aa
39 changed files with 94 additions and 26 deletions

View File

@ -1,6 +1,7 @@
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/*/*"

View File

@ -17,7 +17,9 @@ So two suggestions to fix this:
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
@ -25,4 +27,6 @@ So two suggestions to fix this:
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]]

View File

@ -1,3 +1,13 @@
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 ]]

View File

@ -8,3 +8,5 @@ the account gets approved.)
--[[JoshTriplett]]
[[tag soc]]
[[wishlist]]

View File

@ -10,3 +10,6 @@ A demo is at <http://www.attacklab.net/showdown-gui.html>
> 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..

View File

@ -7,3 +7,5 @@ This seems somewhat difficult, as ikiwiki would need to maintain a cache of the
[scmbug](http://www.mkgnu.net/?q=scmbug) might help here. --[[JoshTriplett]]
[[tag soc]]
[[tag wishlist]]

View File

@ -45,4 +45,6 @@ be embedded to the source code repository commit messages.
>> By Google BTS, do you mean the issue tracker in the Google code
>> project hosting?
>>
>> --Teemu
>> --Teemu
[[wishlist]]

View File

@ -2,4 +2,4 @@ I would *love* to see a plugin that lets you create one or more BibTeX-formatted
--[[JoshTriplett]]
[[tag soc]]
[[tag soc]] [[tag wishlist]]

View File

@ -1,9 +0,0 @@
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

View File

@ -1,3 +1,5 @@
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]]
translation-management tool. --[[JoshTriplett]]
[[wishlist]]

View File

@ -6,3 +6,5 @@ in version control. --[[JoshTriplett]]
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]]

View File

@ -38,4 +38,7 @@ just have to get stylin'. :-)
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]]

View File

@ -14,3 +14,5 @@ information in `ikiwiki.setup`, and the `title` attribute of the `link` should
contain the wiki title from `ikiwiki.setup`.
--[[JoshTriplett]]
[[wishlist]]

View File

@ -1,4 +1,6 @@
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]]
--[[JoshTriplett]]
[[wishlist]]

View File

@ -10,3 +10,5 @@ blog names would work. --[[JoshTriplett]]
>> 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]]

View File

@ -1,3 +1,5 @@
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]]
* 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]]

View File

@ -8,3 +8,5 @@ comment form.
> I agree that having this as an option is reasonable. Although it would
> take a fair amount of work. --[[Joey]]
[[tag wishlist]]

View File

@ -1,3 +1,3 @@
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]].
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]].

View File

@ -12,3 +12,5 @@ This may actually form a subset of the general concept of content policies,
described at [[todo/fileupload]].
--[[JoshTriplett]]
[[wishlist]]

View File

@ -12,3 +12,5 @@ with all news or the one with the latest news only, I don't know yet.)
>> 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]]

View File

@ -2,3 +2,5 @@ Create some nice(r) stylesheets.
Should be doable w/o touching a single line of code, just
editing the [[wikitemplates]] and/or editing [[style.css]].
[[done]] ([[css_market]] ..)

View File

@ -4,4 +4,6 @@ Random idea: create an ikiwiki IRC bot, which notices the use of ikiwiki syntax
<ikihacker> \[[setup]]
<ikibot> http://ikiwiki.info/setup.html: "This tutorial will walk you through setting up a wiki with ikiwiki. ..."
--[[JoshTriplett]]
--[[JoshTriplett]]
[[wishlist]]

View File

@ -9,3 +9,5 @@ configure their browser to subscribe to feeds via [[plugins/aggregate]] running
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]]

View File

@ -156,3 +156,5 @@ Thanks for the comment.. is fixed.
-----
[[tag soc]]
[[tag wishlist]]

View File

@ -15,3 +15,5 @@ second version did not exist, the first version would apply to both cases.
However, that also seems like potential overkill, and less important than the
basic functionality of `linktitle`.
--[[JoshTriplett]]
[[wishlist]]

View File

@ -1,2 +1,4 @@
ikiwiki could support manpages (or general groff input files) and convert them
to HTML. --[[JoshTriplett]]
[[wishlist]]

View File

@ -7,3 +7,5 @@ specify which pages use the non-default template.
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.

View File

@ -7,3 +7,5 @@ Desired features:
* Password protection?
-- [[JoshTriplett]]
[[wishlist]]

View File

@ -1 +1,4 @@
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]]
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]]

View File

@ -1 +1 @@
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?
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?

View File

@ -6,4 +6,7 @@ Knot adz fair ass eye no --[[Joey]]
----
Firefox 2 (or whatever it will be in Debian) does this for you, and then there's the mozex extension
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]]

View File

@ -4,4 +4,6 @@ We should support SVG. In particular:
* 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]]
--[[JoshTriplett]]
[[wishlist]]

View File

@ -8,3 +8,5 @@ Stuff still needing to be done with tags:
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..

View File

@ -1 +1,3 @@
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]]
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]]

View File

@ -7,4 +7,6 @@ As with [[default_content_for_new_post]] I understand that this falls into a bit
MoinMoin has a simple implementation of this, [click here to see an example](http://www.spack.org/wiki/SandBox?action=edit&editor=text).
--[[AdamShand]]
--[[AdamShand]]
[[tag wishlist]]

View File

@ -1 +1 @@
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.
[[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.

View File

@ -23,3 +23,5 @@ problem. According to the developers, it is possible to do that, and start
off in WikiText mode.
[[tag soc]]
[[tag wishlist]]