]> sipb.mit.edu Git - ikiwiki.git/blobdiff - doc/bugs.mdwn
add --refresh and make it with with --setup
[ikiwiki.git] / doc / bugs.mdwn
index 2c712de6d33b59afe9b9c41a75ccce32eb94ae63..3d6ea906b00ce07fe13ec813ef3dec1deda544b8 100644 (file)
@@ -5,10 +5,8 @@
   And if Foo/Bar/Baz is then removed, it forgets to update Foo/Bar to link
   back to Foo/Baz.
 
-  Basically this makes creating new pages painful, top of TODO list..
+    -- is this still true?
 
-* Foo/Bar/Baz shows up as Bar/Baz in the linkbacks on page Foo/Bar. Should
-  show as just Baz there.
 * If I try to do a web commit, to a svn+ssh repo, it fails with
   "Host key verification failed."
   I think that the setuid isn't fully taking; it should be running as me,
 * RecentChanges is a regular page, perhaps it should be automatically
   replaced with a link to the [[CGI]]?
 * [[ikiwiki]] should go to the same place as [[index]] (on this wiki).
-* There's no way to escape a [[WikiLink]] when discussing one on a wiki.
-* Wikilinks are even expanded in the middle of [[MarkDown]] code blocks,
-  and probably shouldn't be (nor in blockquotes?)
-
-  Hmm, the best way to fix this would be to add WikiLink support into
-  markdown, but that will probably be a bear. I guess the question is how
-  common "[[ ]]" is, and maybe we should just provide a way to escape a
-  wikilink..
+* Web browsers don't word-wrap lines in submitted text, which makes editing a
+  page that someone wrote in a web browser annoying (`gqip` is vim user's
+  friend here). Is there any way to improve this?
+* The diff links in RecentChanges go to a viewcvs backtrace if the rev in question is when the page was added. Is this a viewcvs bug, or a behavior ikiwiki needs to work around?
+* If a page stops inlining anthing, its rss feed file
+  will linger around and not be deleted.
+* Currently only one blog is supported per page. Attempts to add more
+  will make it only update one of the blogs on the page.
+* If I edit blog/entry/blog_moved, add a link to code/ikiwiki, and hit
+  preview, it doesn't get the link right because it makes it relative to
+  where the page will be saved to, not to where the cgi script is.