diff options
Diffstat (limited to 'doc/todo')
| -rw-r--r-- | doc/todo/Feature_parity_with_Trac.mdwn | 5 | ||||
| -rw-r--r-- | doc/todo/Option_to_make_title_an_h1__63__.mdwn | 6 | ||||
| -rw-r--r-- | doc/todo/Untrusted_push_in_Monotone.mdwn | 28 | ||||
| -rw-r--r-- | doc/todo/applydiff_plugin.mdwn | 56 | ||||
| -rw-r--r-- | doc/todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion.mdwn | 4 | ||||
| -rw-r--r-- | doc/todo/clear_page_to_delete.mdwn | 7 | ||||
| -rw-r--r-- | doc/todo/dynamic_rootpage.mdwn | 7 | ||||
| -rw-r--r-- | doc/todo/firm_up_plugin_interface.mdwn | 2 | ||||
| -rw-r--r-- | doc/todo/plugin.mdwn | 4 | ||||
| -rw-r--r-- | doc/todo/provide_inline_diffs_in_recentchanges.mdwn | 5 | ||||
| -rw-r--r-- | doc/todo/provide_sha1_for_git_diffurl.mdwn | 26 | ||||
| -rw-r--r-- | doc/todo/rcs_updates_needed.mdwn (renamed from doc/todo/rcs_updates_needed_for_rename_and_remove.mdwn) | 5 | ||||
| -rw-r--r-- | doc/todo/syntax_highlighting.mdwn | 89 | ||||
| -rw-r--r-- | doc/todo/syntax_highlighting/discussion.mdwn | 26 | ||||
| -rw-r--r-- | doc/todo/wiki-formatted_comments_with_syntax_plugin.mdwn | 5 |
15 files changed, 264 insertions, 11 deletions
diff --git a/doc/todo/Feature_parity_with_Trac.mdwn b/doc/todo/Feature_parity_with_Trac.mdwn index 8693da5e3..b2d9d43ed 100644 --- a/doc/todo/Feature_parity_with_Trac.mdwn +++ b/doc/todo/Feature_parity_with_Trac.mdwn @@ -5,11 +5,12 @@ Features needed: * Wiki, duh. * Source code viewing: This can be handled quite well with a [[shortcut|shortcuts]] to an external source viewer, or by putting - the source in the wiki itself (see the [[todo/automatic_use_of_syntax_plugin_on_source_code_files]] wishlist item) and using the - [[plugins/contrib/highlightcode]] or [[plugins/contrib/sourcehighlight]] plugins. + the source in the wiki itself (see the [[todo/automatic_use_of_syntax_plugin_on_source_code_files]] wishlist item and [[todo/syntax_highlighting]] todo item). * This could be improved with [[todo/source_link]]. * Currently the source highlighting is a little problematic, as there can be two source files with the same wikiname. e.g. a `hello-world.c` and `hello-world.h`. See [[bugs/multiple_pages_with_same_name]] + > That bug was fixed before you linked to the page. :-) + >> I was the one that fixed it... :) -- [[Will]] * Trac 'Timeline' feature: view history of the RCS - the `recentchanges` button. * Trac 'Roadmap' feature: Which TODOs/bugs are needed for which milestones. Use the [[plugins/progress]] directive to show percentage complete for each milestone. * Bug tracking: see [[tips/integrated_issue_tracking_with_ikiwiki]] and [[todo/Updated_bug_tracking_example]]. diff --git a/doc/todo/Option_to_make_title_an_h1__63__.mdwn b/doc/todo/Option_to_make_title_an_h1__63__.mdwn index efa07ad79..8676bec48 100644 --- a/doc/todo/Option_to_make_title_an_h1__63__.mdwn +++ b/doc/todo/Option_to_make_title_an_h1__63__.mdwn @@ -6,3 +6,9 @@ Currently, the page title (either the name of the page or the title specified wi > way, # is reserved for h1 if you choose to use headers in your page. --[[Joey]] [[done]] + +> For anyone interested, I've written a small plugin called [h1title][] that does the +> latter, making `#` (only when on the first line) set the page title, removing it from +> the page body. --[[JasonBlevins]], October 22, 2008 + + [h1title]: http://code.jblevins.org/ikiwiki/plugins/h1title.pm diff --git a/doc/todo/Untrusted_push_in_Monotone.mdwn b/doc/todo/Untrusted_push_in_Monotone.mdwn new file mode 100644 index 000000000..a8b1cd7c4 --- /dev/null +++ b/doc/todo/Untrusted_push_in_Monotone.mdwn @@ -0,0 +1,28 @@ +As noted in [[tips/untrusted_git_push]] an untrusted push capability was added recently, but only implemented in git. +(See also [[todo/rcs_updates_needed]]) + +This note describes (but does not implement) an approach for this with the [[rcs/monotone]] rcs backend. + +---- + +Monotone behaves a little differently to git in its networking. Git allows anyone to try to push, and then +check whether it is ok before finally accepting it. Monotone has no way to accept or reject revisions +in this way. However, monotone does have the ability to mark revisions, and to ignore unmarked revisions. + +This marking capability can be used to achieve a somewhat similar effect to what happens with git. The +problem with this is that anyone could put anything into the monotone database, and while this wouldn't +affect ikiwiki, it seems bad to leave open, untrusted storage on the web. + +The Plan +===== + +In the `note_netsync_revision_received` hook in the monotone server, have the server check to make sure +that either a) the revision is signed by someone trusted or, b) the revision is checked using the same +hook that git uses in `pre-receive`. If the revision passes the ikiwiki `pre-receive` check then the +monotone hook signs the revision. This gives that revision the 'ikiwiki seal of approval'. + +You'll also want to update the monotone trust hooks to only trust revisions signed by trusted people, or +ikiwiki. + +Now anyone can upload a revision, but only those signed by a trusted person, or which pass the ikiwiki +check and so get signed by the ikiwiki key, will be seen by ikiwiki. diff --git a/doc/todo/applydiff_plugin.mdwn b/doc/todo/applydiff_plugin.mdwn index d3eb9793b..d26b0dfe9 100644 --- a/doc/todo/applydiff_plugin.mdwn +++ b/doc/todo/applydiff_plugin.mdwn @@ -1,4 +1,4 @@ -[[!tag wishlist]] +[[!tag wishlist done]] [[!toc ]] @@ -54,3 +54,57 @@ modify only *one* page may be easier. Implementation ============== + +Also see [[joey]]'s idea on [[users/xma/discussion]], to allow (filtered) anonymous push to this wiki's repository. + +> Ideally the filtering should apply the same constraints on what's pushed +> as are applied to web edits. So locked pages can't be changed, etc. +> +> That could be accomplished by making the git pre-receive hook be a +> ikiwiki wrapper. A new `git_receive_wrapper` config setting could cause +> the wrapper to be generated, with `$config{receive}` set to true. +> +> When run that way, ikiwiki would call `rcs_receive`. In the case of git, +> that would look at the received changes as fed into the hook on stdin, +> and use `parse_diff_tree` to get a list of the files changed. Then it +> could determine if the changes were allowed. +> +> To do that, it should first look at what unix user received the +> commit. That could be mapped directly to an ikiwiki user. This would +> typically be an unprivelidged user (that was set up just to allow +> anonymous pushes), but you might also want to set up +> separate users who have fewer limits on what they can push. And, of +> course, pushes from the main user, who owns the wiki, would not be +> checked at all. So, let's say `$config{usermap}` is a hash, something +> like `{usera => "wikiusera", userb => "wikiuserb"}`, and pushes from +> users not in the hash are not checked. +> +> Then it seems like it would want to call `check_canedit` to test if an +> edit to each changed page is allowed. Might also want to call +> `check_canattach` and `check_canremove` if the attach and remove plugins +> are enabled. All three expect to be passed a CGI and a CGI::Session +> object, which is a bit problimatic here. So dummy the objects up? (To call +> `check_canattach` the changed attachment would need to be extracted to a +> temp file for it to check..) +> +> If a change is disallowed, it would print out what was disallowed, and +> exit nonzero. I think that git then discards the pushed objects (or maybe +> they remain in the database until `git-gc` .. if so, that could be used +> to DOS by uploading junk, so need to check this point). +> +> Also, I've not verified that the objects have been recieved already when +> whe pre-receive hook is called. Although the docs seem to say that is the +> case. --[[Joey]] + +>> Update: The git pre-receive hook stuff is written, and seems to work. +>> I think it makes more sense than using diffs, and so think this todo +>> could probably be closed. +>> --[[Joey]] + +>>> I agree, closing this. I really prefer this solution to the one I was +>>> initially proposing. +>>> Is this pre-receive hook already enabled on ikiwiki.info? +>>> If not, do you plan to enable it at some point? +>>> --[[intrigeri]] + +>>>> [[news/git_push_to_this_wiki]] gave me the answer. Well done! --[[intrigeri]] diff --git a/doc/todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion.mdwn b/doc/todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion.mdwn index 2fad9f19a..467ec350e 100644 --- a/doc/todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion.mdwn +++ b/doc/todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion.mdwn @@ -1,6 +1,6 @@ Here is another [[patch]] for this. It is more up to date than either of the patches linked on the previous page. It is most similar to [[plugins/contrib/sourcehighlight]]. -Note that if this is being used with `c` or `c++` then you'll probably want to wait until [[bugs/multiple_pages_with_same_name]] is fixed. +Updated to use fix noted in [[bugs/multiple_pages_with_same_name]]. -- [[Will]] @@ -92,7 +92,7 @@ Note that if this is being used with `c` or `c++` then you'll probably want to w foreach my $lang (split(/[, ]+/, $config{sourcecode_lang})) { if ($langs{$lang}) { - hook(type => "htmlize", id => $lang, call => \&htmlize); + hook(type => "htmlize", id => $lang, call => \&htmlize, keepextension => 1); } else { error("Your installation of source-highlight cannot handle sourcecode language $lang!"); } diff --git a/doc/todo/clear_page_to_delete.mdwn b/doc/todo/clear_page_to_delete.mdwn index ccb7634e5..50ae246bb 100644 --- a/doc/todo/clear_page_to_delete.mdwn +++ b/doc/todo/clear_page_to_delete.mdwn @@ -24,3 +24,10 @@ the page. That's what the user intended to do in this case. The information content of an empty vs. a deleted page is essentially the same, I'd say. But having ikiwiki remove those stale pages would save some (minimal, admittedly) time needed for manual clean-up. --[[tschwinge]] + +On EmacsWiki, a page is marked for deletion when it contains just the DeletedPage +keyword and if there were no page editions since XX days. Here, I use pages that +can be empty everyday and filled all day long. It does not make sense to me to +delete these pages :). --[[xma]] + +I was not aware of [[plugins/remove]]. I don't think another method is necessary -- [[JonDowland]] diff --git a/doc/todo/dynamic_rootpage.mdwn b/doc/todo/dynamic_rootpage.mdwn index fa0e23254..5cf80b0a8 100644 --- a/doc/todo/dynamic_rootpage.mdwn +++ b/doc/todo/dynamic_rootpage.mdwn @@ -23,3 +23,10 @@ What's your opinion, Joey? I hope it's also useful for another ikiwiki lovers :) >>> Seems like a job for good ol' string interpolation. rootpage="post/$current_year/$current_month/$current_day" >>> Ikiwiki could provide some vars, and it would be nice to write plugins to also provide vars. Sort of like templates. >>> Does that feel OK? --[[sabr]] + +> I want the exact same thing. My compromise was to create a `datedblog` module which overrides `inline`'s `sessioncgi` hook +> with something that sets the new page name to `%Y-%m-%d.$page` and sets up a meta directive at the beginning of +> the content, with the title you wanted. Now if you use the `datedblog` module, you get dated blog entries. But I'd +> like to have traditional `inline` functionality too. This would work great if there were a way to change the `do` +> parameter in the `blogpost` template's form; if I could change it to `datedblog` instead of `blog` then I could hook +> my datedblog module in nicely, without having to override anything. What would be the right way to do that? --[[neale]] diff --git a/doc/todo/firm_up_plugin_interface.mdwn b/doc/todo/firm_up_plugin_interface.mdwn index b0e92e65c..c2e190884 100644 --- a/doc/todo/firm_up_plugin_interface.mdwn +++ b/doc/todo/firm_up_plugin_interface.mdwn @@ -41,7 +41,7 @@ Another problimatic thing is plugins often define functions named 'preprocess', 6 IkiWiki::titlepage These go together; linkpage is needed by all link plugins, and the others are used widely. -All should be exported. +All should be exported. (Done) 7 IkiWiki::saveindex 5 IkiWiki::loadindex diff --git a/doc/todo/plugin.mdwn b/doc/todo/plugin.mdwn index 132de4480..b3e3a7889 100644 --- a/doc/todo/plugin.mdwn +++ b/doc/todo/plugin.mdwn @@ -70,10 +70,6 @@ Suggestions of ideas for plugins: > web-server-specific code to list all users, and openid can't feasibly do so > at all. --[[JoshTriplett]] -* It would be nice to be able to have a button to show "Differences" (or - "Show Diff") when editing a page. Is that an option that can be enabled? - Using a plugin? - * For PlaceWiki I want to be able to do some custom plugins, including one that links together subpages about the same place created by different users. This seems to call for a plugin that applies to every page w/o any diff --git a/doc/todo/provide_inline_diffs_in_recentchanges.mdwn b/doc/todo/provide_inline_diffs_in_recentchanges.mdwn index 7724576f5..39a35d0c6 100644 --- a/doc/todo/provide_inline_diffs_in_recentchanges.mdwn +++ b/doc/todo/provide_inline_diffs_in_recentchanges.mdwn @@ -1,3 +1,8 @@ It would rock if I could view diffs from the web without going via feeds. I envision toggle-style buttons on the recentchanges page, or just links to the CGI, which then displays the diff... --[[madduck]] +> The diffs are actually there, enabled by the `recentchangesdiff` +> plugin, but they are hidden in the XHTML version by the stylesheet. +> You might try a user stylesheet with `div.diff { display: block }`. +> --[[JasonBlevins]] + [[!tag wishlist]] diff --git a/doc/todo/provide_sha1_for_git_diffurl.mdwn b/doc/todo/provide_sha1_for_git_diffurl.mdwn new file mode 100644 index 000000000..9c8b340de --- /dev/null +++ b/doc/todo/provide_sha1_for_git_diffurl.mdwn @@ -0,0 +1,26 @@ +This [[patch]] allows for `\[[sha1]]` substitution in the `diffurl` +for git repositories. This is useful for use with [cgit][] which has +diffurls of the following form: + + /project.git/diff/\[[file]]?id=\[[sha1_commit]] + + [cgit]: http://hjemli.net/git/cgit/ + + diff --git a/IkiWiki/Plugin/git.pm b/IkiWiki/Plugin/git.pm + index 5bef928..164210d 100644 + --- a/IkiWiki/Plugin/git.pm + +++ b/IkiWiki/Plugin/git.pm + @@ -518,6 +518,7 @@ sub rcs_recentchanges ($) { #{{{ + + my $diffurl = defined $config{'diffurl'} ? $config{'diffurl'} : ""; + $diffurl =~ s/\[\[file\]\]/$file/go; + + $diffurl =~ s/\[\[sha1\]\]/$sha1/go; + $diffurl =~ s/\[\[sha1_parent\]\]/$ci->{'parent'}/go; + $diffurl =~ s/\[\[sha1_from\]\]/$detail->{'sha1_from'}/go; + $diffurl =~ s/\[\[sha1_to\]\]/$detail->{'sha1_to'}/go; + +> [[done]], but I called it `sha1_commit` since I think that's what it's +> actually a sha1 of. --[[Joey]] + +>> I was at a loss for something more descriptive...I like that much +>> better :) Thanks! --[[JasonBlevins]] diff --git a/doc/todo/rcs_updates_needed_for_rename_and_remove.mdwn b/doc/todo/rcs_updates_needed.mdwn index 2af659c3b..472a5800f 100644 --- a/doc/todo/rcs_updates_needed_for_rename_and_remove.mdwn +++ b/doc/todo/rcs_updates_needed.mdwn @@ -3,3 +3,8 @@ renaming and removing files using the web interface. The mercurial and tla [[rcs]] backends need implementions of these functions. (The maintainers of these backends have been mailed. --[[Joey]]) + +Also, currently git is the only VCS to have support for +[[untrusted_push|tips/untrusted_git_push]]. It _may_ be possible to +implement it for other DVCS, if they offer a hook that can be used to check +incoming pushes early. diff --git a/doc/todo/syntax_highlighting.mdwn b/doc/todo/syntax_highlighting.mdwn new file mode 100644 index 000000000..bb1c84f02 --- /dev/null +++ b/doc/todo/syntax_highlighting.mdwn @@ -0,0 +1,89 @@ +There's been a lot of work on contrib syntax highlighting plugins. One should be +picked and added to ikiwiki core. + +Ideally, it should support both converting whole source files into wiki +pages, as well as doing syntax highlighting as a preprocessor directive +(which is either passed the text, or reads it from a file). + +## The big list of possibilities + +* [[plugins/contrib/highlightcode]] uses [[cpan Syntax::Highlight::Engine::Kate]], + operates on whole source files only, has a few bugs (see + [here](http://u32.net/Highlight_Code_Plugin/), and needs to be updated to + support [[bugs/multiple_pages_with_same_name]]. +* [[cpan IkiWiki-Plugin-syntax]] only operates as a directive. + Interestingly, it supports multiple highlighting backends, including Kate + and Vim. +* [[plugins/contrib/syntax]] only operates as a directive + ([[not_on_source_code_files|automatic_use_of_syntax_plugin_on_source_code_files]]), + and uses [[cpan Text::VimColor]]. +* [[plugins/contrib/sourcehighlight]] uses src-highlight, and operates on + whole source files only. Needs to be updated to + support [[bugs/multiple_pages_with_same_name]]. +* [[sourcecode|todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion]] + also uses src-highlight, and operates on whole source files. + Updated to work with the fix for [[bugs/multiple_pages_with_same_name]]. Untested with files with no extension, e.g. `Makefile`. + +## General problems + +* Using non-perl syntax highlighting backends is slow. I'd prefer either + using a perl module, or a multiple-backend solution that can use a perl + module as one option. (Or, if there's a great highlighter python module, + we could use an external plugin..) +* Currently no single plugin supports both modes of operation (directive + and whole source file to page). +* Nothing seems to support + [[wiki-formatted_comments|wiki-formatted_comments_with_syntax_plugin]] + inside source files. Doing this probably means post-processing the + results of the highlighting engine, to find places where it's highlighted + comments, and then running them through the ikiwiki rendering pipeline. + This seems fairly doable with [[cpan Syntax::Highlight::Engine::Kate]], + at least. +* The whole-file plugins tend to have a problem that things that look like + wikilinks in the source code get munged into links by ikiwiki, which can + have confusing results. Similar problem with preprocessor directives. + One approach that's also been requested for eg, + [[plugins/contrib/mediawiki]] is to allow controlling which linkification + types a page type can have on it. +* The whole-file plugins all get confused if there is a `foo.c` and a `foo.h`. + This is trivially fixable now by passing the keepextension option when + registering the htmlize hooks, though. +* Whole-file plugins register a bunch of htmlize hooks. The wacky thing + about it is that, when creating a new page, you can then pick "c" or + "h" or "pl" etc from the dropdown that normally has "mdwn" etc in it. + Is this a bug, or a feature? (Even if a feature, plugins with many + extensions make the dropdown unusable.. One way to deal with that is have + a config setting that lists what extensions to offer highlighting for. + Most people won't need/want the dozens some engines support.) +* The per page highlighters can't handle creating wiki pages from + "Makefile", or other files without a significant extension. + Not clear how to fix this, as ikiwiki is very oriented toward file + extensions. The workaround is to use a directive on a wiki page, pulling + in the Makefile. + +## format directive + +Rather than making syntax highlight plugins have to provide a preprocessor +directive as well as handling whole source files, perhaps a generic format +directive could be used: + + \[[!format pl """..."""]] + +That would run the text through the pl htmlizer, from the syntax hightligh +plugin. OTOH, if "rst" were given, it would run the text through the rst +htmlizer. So, more generic, allows mixing different types of markup on one +page, as well as syntax highlighting. Does require specifying the type of +format, instead of allowing it to be guessed (which some syntax highlighters +can do). (This directive is now implemented..) + +Hmm, this would also allow comments inside source files to have mdwn +embedded in them, without making the use of mdwn a special case, or needing +to postprocess the syntax highlighter output to find comments. + + /* \[[!format mdwn """ + + This is a comment in my C file. You can use mdwn in here. + + """]] */ + +Note that this assumes that directives are expanded in source files. diff --git a/doc/todo/syntax_highlighting/discussion.mdwn b/doc/todo/syntax_highlighting/discussion.mdwn new file mode 100644 index 000000000..7a4095c65 --- /dev/null +++ b/doc/todo/syntax_highlighting/discussion.mdwn @@ -0,0 +1,26 @@ +sourcehighlight is annoyingly slow, but it does support wiki directives +in comments. See [here](http://www.cs.unb.ca/~bremner/teaching/java_examples/snippet/ListMerge/) +for an example (tags). + +> I think that is just a result of it expanding directives, and wikilinks, +> everywhere in the file, which is generally a possible problem.. +> --[[Joey]] + +* * * * * + +I think having the option to choose source code page types from the +dropdown list is definitely a feature. This gives users an easy way +to contribute programs (say `.pl` files) or code snippets (like, for +example, the Elisp area of the EmacsWiki). Actually, would there any +other way to create a `.pl` file without write access to the +repository? --[[JasonBlevins]] + +> Well, you can upload them as an attachment if the wiki is configured to +> allow it. Having them in the drop down becomes a problem when there are +> so many wacky extensions in there that you can't find anything. +> --[[Joey]] + +>> I should just note that the +>> [[sourcecode|todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion]] +>> plugin only adds the file extensions listed in the config. This shouldn't cause +>> massive drop-down menu pollution. -- [[Will]] diff --git a/doc/todo/wiki-formatted_comments_with_syntax_plugin.mdwn b/doc/todo/wiki-formatted_comments_with_syntax_plugin.mdwn index 08ca61b0c..a5244c9ef 100644 --- a/doc/todo/wiki-formatted_comments_with_syntax_plugin.mdwn +++ b/doc/todo/wiki-formatted_comments_with_syntax_plugin.mdwn @@ -1 +1,4 @@ -[[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. |