From 5e1b3c0c363f4da91413b11905cce3a6d9af7abd Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 22 Apr 2009 16:00:36 -0400 Subject: plan of attack --- .../Post-compilation_inclusion_of_the_sidebar.mdwn | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Post-compilation_inclusion_of_the_sidebar.mdwn b/doc/todo/Post-compilation_inclusion_of_the_sidebar.mdwn index 7586c060b..568b75747 100644 --- a/doc/todo/Post-compilation_inclusion_of_the_sidebar.mdwn +++ b/doc/todo/Post-compilation_inclusion_of_the_sidebar.mdwn @@ -28,3 +28,23 @@ NicolasLimare > sidebar could be done as you describe using .shtml. --[[Joey]] [[wishlist]] + +> I have a plan for a way to avoid unecessary rebuilds caused by the +> sidebar. The idea is to use wikistate to store what a sidebar renders to. +> Then in the needsbuild hook, render sidebar(s) and compare with their +> previous stored rendering. If a sidebar's rendered content has changed, +> then all pages that display that sidebar need to be forced to be rebuilt. +> +> Also, if there is no previous stored rendering for a sidebar, or +> if there is a stored rendering for a sidebar page that no longer exists, then +> the pages need to be rebuilt. (This should deal with the [[bugs/Building_a_sidebar_does_not_regenerate_the_subpages]] bug. +> +> This would also save significant time, since the stored sidebar rendering +> could just be dumped into the page by the pagetemplate hook. Current code +> re-loads and renders the same sidebar file for every page built! +> +> The sticky part is relative links on the sidebar. These would need to +> be modified somehow depending on the page that the sidebar is placed on. +> Doing that seems hard/tricky. Maybe it would not be worth the optimisation +> of using the stored rendering after all, and instead still re-render it for +> each page? --[[Joey]] -- cgit v1.2.3 From 86d6b40070023409882a5768a4db899e523bba71 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 22 Apr 2009 16:12:54 -0400 Subject: two problems --- .../Post-compilation_inclusion_of_the_sidebar.mdwn | 27 ++++++++++++++++++---- 1 file changed, 22 insertions(+), 5 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/Post-compilation_inclusion_of_the_sidebar.mdwn b/doc/todo/Post-compilation_inclusion_of_the_sidebar.mdwn index 568b75747..36161e8b4 100644 --- a/doc/todo/Post-compilation_inclusion_of_the_sidebar.mdwn +++ b/doc/todo/Post-compilation_inclusion_of_the_sidebar.mdwn @@ -43,8 +43,25 @@ NicolasLimare > could just be dumped into the page by the pagetemplate hook. Current code > re-loads and renders the same sidebar file for every page built! > -> The sticky part is relative links on the sidebar. These would need to -> be modified somehow depending on the page that the sidebar is placed on. -> Doing that seems hard/tricky. Maybe it would not be worth the optimisation -> of using the stored rendering after all, and instead still re-render it for -> each page? --[[Joey]] +> The sticky part is (relative) links on the sidebar. These would need to +> be modified somehow depending on the page that the sidebar is placed on, +> to not break the link. +> +> Another wrinkle is changing subpage links on a sidebar. Suppose a sidebar +> links to page `foo`. If page `bar/foo` exists, the sidebar on page bar will, +> currently, link to that page, in preference to a toplevel `foo`. +> If `bar/foo` is removed, it will update to link to `foo`. With the new +> scheme, the stored sidebar rendering is not for page `foo`, and so +> the change of the `bar/foo` link will not be noticed or acted on. +> Granted, it's unlikely that anyone relies on the current behavior. You +> generally want links on a sidebar to link to the same place on every page +> that displays it. So finding some way to force all links on a sidebar to +> be handled absolutely and documenting that would avoid this problem. +> +> So, one way to handle both the above problems would be to use the +> pre-rendered sidebar for each page, but use a html parser to look for +> links in it, and munge them to work as relative links on the page the +> sidebar is being added to. Or, if the wiki's url is known, just do this +> once when rendering the sidebar, adding the full url to the links. +> (Maybe require `url` be set when using sidebar?) +> --[[Joey]] -- cgit v1.2.3 From 5dd1e097501a4076c19d4a372ca8528e01508b6e Mon Sep 17 00:00:00 2001 From: Jon Dowland Date: Fri, 24 Apr 2009 14:26:45 +0100 Subject: new todo item: more flexible inline postform --- doc/todo/more_flexible_inline_postform.mdwn | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 doc/todo/more_flexible_inline_postform.mdwn (limited to 'doc/todo') diff --git a/doc/todo/more_flexible_inline_postform.mdwn b/doc/todo/more_flexible_inline_postform.mdwn new file mode 100644 index 000000000..112220394 --- /dev/null +++ b/doc/todo/more_flexible_inline_postform.mdwn @@ -0,0 +1,14 @@ +Using the [[plugins/inline]] plugin, you can get an inline-postform for +creating new pages. + +It would be quite nice to have the flexibility to do this outside of the +inline directive. + +I've got a proof-of-concept hacked inline comment submission example at + for example. I've just copied the HTML from +the post form and stuck it inside a [[plugins/toggle]]. + +(Before Simon completed the comments plugin, I thought this would the a +logical first step towards doing comment-like things with inlined pages). + +-- [[Jon]] -- cgit v1.2.3 From 24177f8433510b2418dc78b234ea8f6da4c91c77 Mon Sep 17 00:00:00 2001 From: Jon Dowland Date: Fri, 24 Apr 2009 14:34:32 +0100 Subject: interactive todo lists todo item --- doc/todo/interactive_todo_lists.mdwn | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 doc/todo/interactive_todo_lists.mdwn (limited to 'doc/todo') diff --git a/doc/todo/interactive_todo_lists.mdwn b/doc/todo/interactive_todo_lists.mdwn new file mode 100644 index 000000000..69b610696 --- /dev/null +++ b/doc/todo/interactive_todo_lists.mdwn @@ -0,0 +1,26 @@ +This is a fleshed out todo based on discussions at +[[forum/managing_todo_lists]]. + +I would like to have TODO lists inside ikiwiki wikis. This would mean: + +* a new markup plugin to support a language suitable for TODO lists (OPML, + XOXO are two possible candidates) +* some javascript to provide interactive editing. + +As [[chrysn]] pointed out on the forum page, this has some crossover with +[[structured page data]]. In particular, if the markup language chosen had a +concept of invalid markup (existing plugins just tend to ignore stuff that +isn't explicitly part of their markup) we would need to sensibly handle that. +Perhaps rejecting web edits and providing context help on why the edit was +rejected, although that sounds like a significant headache. + +I have started working on this, albeit slowly. A proof of concept is at +. + +There are two git repositories associated with my WIP: one contains the +javascript, the plugin, the changes made to page templates; the other contains +the contents of that wiki-site (so the test todos and the contents of bugs/ +which forms a sort-of todo list for the todo list :)) I will endeavour to get +mirrors of those repos up on github or similar asap. + +-- [[Jon]] -- cgit v1.2.3 From 31fff76651610a736baa4ba6a8d67a8658be1d99 Mon Sep 17 00:00:00 2001 From: Jon Dowland Date: Fri, 24 Apr 2009 14:44:28 +0100 Subject: add a ' ' to prevent autosmiley eating a ) --- doc/todo/interactive_todo_lists.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/interactive_todo_lists.mdwn b/doc/todo/interactive_todo_lists.mdwn index 69b610696..cf248bd41 100644 --- a/doc/todo/interactive_todo_lists.mdwn +++ b/doc/todo/interactive_todo_lists.mdwn @@ -20,7 +20,7 @@ I have started working on this, albeit slowly. A proof of concept is at There are two git repositories associated with my WIP: one contains the javascript, the plugin, the changes made to page templates; the other contains the contents of that wiki-site (so the test todos and the contents of bugs/ -which forms a sort-of todo list for the todo list :)) I will endeavour to get +which forms a sort-of todo list for the todo list :) ) I will endeavour to get mirrors of those repos up on github or similar asap. -- [[Jon]] -- cgit v1.2.3 From 9e69aa574751601a925c57ec61d767c3a475cac7 Mon Sep 17 00:00:00 2001 From: "http://jmtd.net/" Date: Sat, 2 May 2009 07:54:00 -0400 Subject: WIP todo list javascript in a demonstratable state --- doc/todo/interactive_todo_lists.mdwn | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/interactive_todo_lists.mdwn b/doc/todo/interactive_todo_lists.mdwn index cf248bd41..fd88fe764 100644 --- a/doc/todo/interactive_todo_lists.mdwn +++ b/doc/todo/interactive_todo_lists.mdwn @@ -24,3 +24,15 @@ which forms a sort-of todo list for the todo list :) ) I will endeavour to get mirrors of those repos up on github or similar asap. -- [[Jon]] + +---- + +Just to report the WIP plugin for this is now in a reasonably good state. I ended +up just inventing a new markup language -- for now, items are divided by newlines +and lists are one-dimensional, for simplicity. I got fed up thinking about how to +handle the structured data issues / needing a lot of boilerplate around items and +the implications for the "new item" dialogue. + +Still quite a lot to do though! + +-- [[Jon]] -- cgit v1.2.3 From 559c0c42c8db7a883b536e0c370c3f40798a80d6 Mon Sep 17 00:00:00 2001 From: "http://jmtd.net/" Date: Sat, 2 May 2009 09:26:37 -0400 Subject: published at http://github.com/jmtd/ikiwiki_todolist/ --- doc/todo/interactive_todo_lists.mdwn | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/interactive_todo_lists.mdwn b/doc/todo/interactive_todo_lists.mdwn index fd88fe764..22b92953a 100644 --- a/doc/todo/interactive_todo_lists.mdwn +++ b/doc/todo/interactive_todo_lists.mdwn @@ -36,3 +36,14 @@ the implications for the "new item" dialogue. Still quite a lot to do though! -- [[Jon]] + +I've pushed a copy of the work in progress which consists of + + * A change to page.tmpl + * A javascript underlay directory + javascript file + * a few CSS bits in a local.css + * a plugin + +to + +-- [[Jon]] -- cgit v1.2.3 From 50d6abf28b71234b424eb8349f85eb465bc83983 Mon Sep 17 00:00:00 2001 From: "http://stefano.zacchiroli.myopenid.com/" Date: Tue, 5 May 2009 04:41:15 -0400 Subject: --- doc/todo/blogspam_training.mdwn | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 doc/todo/blogspam_training.mdwn (limited to 'doc/todo') diff --git a/doc/todo/blogspam_training.mdwn b/doc/todo/blogspam_training.mdwn new file mode 100644 index 000000000..f1d71f763 --- /dev/null +++ b/doc/todo/blogspam_training.mdwn @@ -0,0 +1,24 @@ +The [[blogspam plugin|plugins/blogspam]] is just great. + +However, it lacks support in the web interface to [train comments as +SPAM](http://blogspam.net/api/classifyComment.html), when they were +erroneously identified as ham. It would be great to have such +support, also in the spirit of helping +[blogspam.net](http://blogspam.net) to get better and better. + +What would consist the most appropriate user interface is not entirely +clear to me in the general case (wiki page editing). The case of blog +comments look easier to: when the admin user is logged in (and if the +blogspam plugin is enabled), each comment can have an extra link "mark +as SPAM" which would both delete/revert the comment and submit it to +the configured blogspam server for training. + +Similarly, ham training can be plugged directly into the current +comment moderation interface. Each comment that gets approved by the +admin, can be sent to blogspam.net as ham. If this is considered too +"aggressive", this behaviour can need to be explicitly enabled by +turning on a configuration option. + +-- [[Zack]] + +[[!tag wishlist]] -- cgit v1.2.3 From 6f991c7a1c2441b5110e2d895a12a73c63895b44 Mon Sep 17 00:00:00 2001 From: "http://smcv.pseudorandom.co.uk/" Date: Wed, 6 May 2009 06:11:53 -0400 Subject: --- doc/todo/blogspam_training.mdwn | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/blogspam_training.mdwn b/doc/todo/blogspam_training.mdwn index f1d71f763..f15eba59d 100644 --- a/doc/todo/blogspam_training.mdwn +++ b/doc/todo/blogspam_training.mdwn @@ -13,6 +13,13 @@ blogspam plugin is enabled), each comment can have an extra link "mark as SPAM" which would both delete/revert the comment and submit it to the configured blogspam server for training. +> Comments can't have an extra link when the admin user is logged +> in, because the admin user sees the same static pages as everyone +> else (non-admins still see the "remove" link provided by the remove +> plugin, too). Perhaps a better UI would be that the action of that +> link was overridden by the blogspam plugin to go to a form with +> a checkbox for "also submit as spam"? --[[smcv]] + Similarly, ham training can be plugged directly into the current comment moderation interface. Each comment that gets approved by the admin, can be sent to blogspam.net as ham. If this is considered too -- cgit v1.2.3 From 6a7a279b18b0dc5ba13c0d89973ee16e36d15a45 Mon Sep 17 00:00:00 2001 From: mgpfxfgaqo Date: Fri, 8 May 2009 13:43:07 -0400 Subject: edit form: no fixed size for textarea --- doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn (limited to 'doc/todo') diff --git a/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn new file mode 100644 index 000000000..ae03021b1 --- /dev/null +++ b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn @@ -0,0 +1,3 @@ +At the moment the text area in the edit form has a fixed size of 20 rows. + +On longer pages its not very comfortable to edit pages with such a small box. The whole screen size should be used instead([example](http://img3.imagebanana.com/img/bl10u9mb/editingtodo_1241804460828.png)). -- cgit v1.2.3 From 6d0498658a01dc9cec6cc243ee0de98ff980b60a Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 8 May 2009 15:30:35 -0400 Subject: response --- doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn index ae03021b1..ccacebdb5 100644 --- a/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn +++ b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn @@ -1,3 +1,13 @@ At the moment the text area in the edit form has a fixed size of 20 rows. On longer pages its not very comfortable to edit pages with such a small box. The whole screen size should be used instead([example](http://img3.imagebanana.com/img/bl10u9mb/editingtodo_1241804460828.png)). + +> The whole screen width is used, via the following +> from style.css: +> +> { +> width: 100%; +> } +> +> Perhaps you have replaced it with a modified style sheet that does not +> include that? --[[Joey]] [[!tag done]] -- cgit v1.2.3 From 929ac1361d0b34324fa5c44cbedc111ef9ed0e61 Mon Sep 17 00:00:00 2001 From: mgpfxfgaqo Date: Sun, 10 May 2009 17:03:42 -0400 Subject: problem is the height --- doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn index ccacebdb5..2adef079d 100644 --- a/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn +++ b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn @@ -11,3 +11,5 @@ On longer pages its not very comfortable to edit pages with such a small box. Th > > Perhaps you have replaced it with a modified style sheet that does not > include that? --[[Joey]] [[!tag done]] + +>> The screen shot was made with http://ikiwiki.info/ where i didn't change anything. The width is optimally used. The problem is the height. -- cgit v1.2.3 From 83961e4668bc62d8d19dd5dfa17437b64d940998 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 12 May 2009 14:15:34 -0400 Subject: response --- doc/news/version_3.11.mdwn | 5 ----- doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn | 17 +++++++++++++++++ 2 files changed, 17 insertions(+), 5 deletions(-) (limited to 'doc/todo') diff --git a/doc/news/version_3.11.mdwn b/doc/news/version_3.11.mdwn index 2ef1b8c12..2d1dc7063 100644 --- a/doc/news/version_3.11.mdwn +++ b/doc/news/version_3.11.mdwn @@ -1,8 +1,3 @@ -You may want to run `ikiwiki-transition deduplinks /path/to/srcdir` -after upgrading to this version of ikiwiki. This command will -optimise your wiki's saved state, removing duplicate information -that can slow ikiwiki down. - ikiwiki 3.11 released with [[!toggle text="these changes"]] [[!toggleable text=""" * Avoid using python-support. Closes: #[525086](http://bugs.debian.org/525086) diff --git a/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn index 2adef079d..526523dcd 100644 --- a/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn +++ b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn @@ -13,3 +13,20 @@ On longer pages its not very comfortable to edit pages with such a small box. Th > include that? --[[Joey]] [[!tag done]] >> The screen shot was made with http://ikiwiki.info/ where i didn't change anything. The width is optimally used. The problem is the height. + +>>> You confused me by talking about rows... +>>> I don't know how to allow CSS to resize a textarea +>>> to the full browser height. The obvious `height: 75%;` +>>> does not work, at least in firefox and epiphany. +>>> +>>> Ah, of course, if it did work, it'd make it be 75% of +>>> the full *page* height, and not the browser window height. +>>> +>>> According to +>>> [this page](http://stackoverflow.com/questions/632983/css-height-if-textarea-as-a-percentage-of-the-viewport-height): +>>>>>50% of what? Parent says ‘auto’, which means base it on the height of the child content. Which depends on the height on the parent. Argh! etc. +>>>>> +>>>>>So you have to give its parent a percentage height. And the parent's parent, all the way up to the root. +>>> So, other than a javascript-based resizer, some very tricky and invasive CSS +>>> seems to be needed. Please someone let me know if you succeed in doing that. +>>> --[[Joey]] -- cgit v1.2.3 From 19cb93507bf650f307cd7b8c26b0b02a0733ed26 Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Wed, 13 May 2009 21:51:55 -0400 Subject: tagging (to find this page easier when studying ikiwiki) --- doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn index ab9263556..5d3f96c88 100644 --- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn +++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn @@ -1,4 +1,6 @@ -It would be great if I could tell ikiwiki to automatically instantiate pages for each tag, according to a template, especially when `$tagbase` is set. +[[!tag tags]] + +It would be great if I could tell ikiwiki to automatically instantiate pages for each [[tag|directive/tag]], according to a template, especially when `$tagbase` is set. Tags are mainly specific to the object to which they’re stuck. However, I often use them the other way around, too: as concepts. And sometimes I’d like to see all pages related to a given concept (“tagged with a given tag”). The only way to do this with ikiwiki is to instantiate a page for each tag and slap a map on it. This is quite tedious and I’d really love to see Ikiwiki do so by default for all tags. @@ -10,7 +12,7 @@ I would love to see this as well. -- dato --- -I have create a patch to tag.pm for add the option for auto create tag pages. +I have create a patch to [[tag.pm|plugins/tag]] for add the option for auto create tag pages. A new setting is used to enable or disable auto-create tag pages, `tag_autocreate`. The new tag file is created during the preprocess phase. The new tag file is then complied during the change phase. -- cgit v1.2.3 From 21ae50ffeb619a09a53a436a3049f7b71fe0e507 Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Wed, 13 May 2009 21:54:37 -0400 Subject: tagging --- doc/todo/tags.mdwn | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/tags.mdwn b/doc/todo/tags.mdwn index 682acfa1f..7a7fdccde 100644 --- a/doc/todo/tags.mdwn +++ b/doc/todo/tags.mdwn @@ -1,4 +1,5 @@ -Stuff still needing to be done with tags: +[[!tag /tags]] +Stuff still needing to be done with [[tag|ikiwiki/directive/tag]]s: * It's unfortunate that the rss category (tag) support doesn't include a domain="" attribute in the category elements. That would let readers -- cgit v1.2.3 From d5a97dde270051c179acb27bae81f5459f684d33 Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Wed, 13 May 2009 21:57:25 -0400 Subject: better link targets --- doc/todo/tags.mdwn | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/tags.mdwn b/doc/todo/tags.mdwn index 7a7fdccde..686f21341 100644 --- a/doc/todo/tags.mdwn +++ b/doc/todo/tags.mdwn @@ -1,5 +1,4 @@ -[[!tag /tags]] -Stuff still needing to be done with [[tag|ikiwiki/directive/tag]]s: +Stuff still needing to be done with [[tags]]: * It's unfortunate that the rss category (tag) support doesn't include a domain="" attribute in the category elements. That would let readers -- cgit v1.2.3 From 24857352b195db24b9a477d430f3fd58f0b20a1c Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Wed, 13 May 2009 21:58:19 -0400 Subject: fix the prev.edit: only abs.path will work --- doc/todo/tags.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/tags.mdwn b/doc/todo/tags.mdwn index 686f21341..ee9151116 100644 --- a/doc/todo/tags.mdwn +++ b/doc/todo/tags.mdwn @@ -1,4 +1,4 @@ -Stuff still needing to be done with [[tags]]: +Stuff still needing to be done with [[/tags]]: * It's unfortunate that the rss category (tag) support doesn't include a domain="" attribute in the category elements. That would let readers -- cgit v1.2.3 From cb3cb16d9cfa8480051b03fdf61cb22b964afdbd Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Wed, 13 May 2009 22:00:16 -0400 Subject: better targets for link in the prev.edit --- doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn index 5d3f96c88..4e3bda54d 100644 --- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn +++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn @@ -1,6 +1,4 @@ -[[!tag tags]] - -It would be great if I could tell ikiwiki to automatically instantiate pages for each [[tag|directive/tag]], according to a template, especially when `$tagbase` is set. +It would be great if I could tell ikiwiki to automatically instantiate pages for each [[tag|/tags]], according to a template, especially when `$tagbase` is set. Tags are mainly specific to the object to which they’re stuck. However, I often use them the other way around, too: as concepts. And sometimes I’d like to see all pages related to a given concept (“tagged with a given tag”). The only way to do this with ikiwiki is to instantiate a page for each tag and slap a map on it. This is quite tedious and I’d really love to see Ikiwiki do so by default for all tags. -- cgit v1.2.3 From e29d35f40198e47c0ecab1f4c2a2b60e107d8276 Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Thu, 14 May 2009 06:30:08 -0400 Subject: Wikilinked a "term". --- doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn index 4e3bda54d..30a217413 100644 --- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn +++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn @@ -96,7 +96,7 @@ _tag.pm from version 3.01_ + -This uses a template called `autotagpage.tmpl`, here is my template file: +This uses a [[template|wikitemplates]] called `autotagpage.tmpl`, here is my template file: \[[!inline pages="link()" archive="yes"]] -- cgit v1.2.3 From b67bd17a0326d16d9e0962b0e98a2b5704f4bd73 Mon Sep 17 00:00:00 2001 From: "http://jmtd.net/" Date: Thu, 14 May 2009 08:31:18 -0400 Subject: javascript rough approach --- doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn index 526523dcd..4ca07c633 100644 --- a/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn +++ b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn @@ -30,3 +30,5 @@ On longer pages its not very comfortable to edit pages with such a small box. Th >>> So, other than a javascript-based resizer, some very tricky and invasive CSS >>> seems to be needed. Please someone let me know if you succeed in doing that. >>> --[[Joey]] + +>>>> the javascript approach would need to work something like this: you need to know about the "bottom-most" item on the edit page, and get a handle for that object in the DOM. You can then obtain the absolute position height-wise of this element and the absolute position of the bottom of the window to determine the pixel-difference. Then, you set the height of the textarea to (current height in px) + determined-value. This needs to be re-triggered on various resize events, at least for the window and probably for other elements too. I may have a stab at this at some point. -- [[Jon]] -- cgit v1.2.3 From facee6e83e0ed9e398179344a6a9c620c956e7f0 Mon Sep 17 00:00:00 2001 From: "http://jmtd.net/" Date: Thu, 14 May 2009 08:34:23 -0400 Subject: quote depth --- doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn index 4ca07c633..4c9c2352a 100644 --- a/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn +++ b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn @@ -31,4 +31,4 @@ On longer pages its not very comfortable to edit pages with such a small box. Th >>> seems to be needed. Please someone let me know if you succeed in doing that. >>> --[[Joey]] ->>>> the javascript approach would need to work something like this: you need to know about the "bottom-most" item on the edit page, and get a handle for that object in the DOM. You can then obtain the absolute position height-wise of this element and the absolute position of the bottom of the window to determine the pixel-difference. Then, you set the height of the textarea to (current height in px) + determined-value. This needs to be re-triggered on various resize events, at least for the window and probably for other elements too. I may have a stab at this at some point. -- [[Jon]] +>>>>>> the javascript approach would need to work something like this: you need to know about the "bottom-most" item on the edit page, and get a handle for that object in the DOM. You can then obtain the absolute position height-wise of this element and the absolute position of the bottom of the window to determine the pixel-difference. Then, you set the height of the textarea to (current height in px) + determined-value. This needs to be re-triggered on various resize events, at least for the window and probably for other elements too. I may have a stab at this at some point. -- [[Jon]] -- cgit v1.2.3 From 8e7b0113847eb0975fa5dc13e9654a52ea0494d1 Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Thu, 14 May 2009 11:06:49 -0400 Subject: Comment: this patch doesn't work correctly. --- .../auto-create_tag_pages_according_to_a_template.mdwn | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn index 30a217413..87b30891e 100644 --- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn +++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn @@ -106,3 +106,20 @@ I am not sure if that is the best way to handle it. [[!tag patch]] -- Jeremy Schultz + +No, this doesn't help: + + + # This refresh/saveindex is to fix the Tags link + + # With out this additional refresh/saveindex the tag link displays ?tag + + IkiWiki::refresh(); + + IkiWiki::saveindex(); + +On the second extra pass, it doesn't notice that it has to update the "?"-link. If I run ikiwiki once more, it is updated. I don't know yet how this should be fixed, because I don't know the internals of ikiwiki good enough. Something inhibits detecting the need to update in refresh() in Render.pm; perhaps, this condition: + + if (! $pagemtime{$page}) { + ... + push @add, $file; + ... + } + +is not satisfied for the newly created tag page. I shall put debug msgs into Render.pm to find out better how it works. --Ivan Z. -- cgit v1.2.3 From e31a9c4d0916397773882be259d7fbf33411e418 Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Thu, 14 May 2009 11:07:55 -0400 Subject: minor: style. --- doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn index 87b30891e..f60fc3d6e 100644 --- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn +++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn @@ -114,7 +114,7 @@ No, this doesn't help: + IkiWiki::refresh(); + IkiWiki::saveindex(); -On the second extra pass, it doesn't notice that it has to update the "?"-link. If I run ikiwiki once more, it is updated. I don't know yet how this should be fixed, because I don't know the internals of ikiwiki good enough. Something inhibits detecting the need to update in refresh() in Render.pm; perhaps, this condition: +On the second extra pass, it doesn't notice that it has to update the "?"-link. If I run ikiwiki once more, it is updated. I don't know yet how this should be fixed, because I don't know the internals of ikiwiki well enough. Something inhibits detecting the need to update in refresh() in Render.pm; perhaps, this condition: if (! $pagemtime{$page}) { ... -- cgit v1.2.3 From 9476c95e0aa4448c93f95c6952ead09abd3ba14a Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Sat, 16 May 2009 04:40:56 -0400 Subject: observed indeed the mentioned confusing behavior --- doc/todo/tag_pagespec_function.mdwn | 3 +++ 1 file changed, 3 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/tag_pagespec_function.mdwn b/doc/todo/tag_pagespec_function.mdwn index 681a1f661..5548cfd8d 100644 --- a/doc/todo/tag_pagespec_function.mdwn +++ b/doc/todo/tag_pagespec_function.mdwn @@ -12,6 +12,9 @@ match tagged pages independent of whatever the tagbase is set to. > > The only problem I see is it could be confusing if `tag(foo)` matched > a page that just linked to the tag via a wikilink, w/o actually tagging it. + +>> Yes, this is confusing and not nice. I observed this misbehavior, because I wanted to match two different lists of pages (only tagged or linked in any way), but it didn't work. Would this feature require a complex patch? --Ivan Z. + > > One other thing, perhaps it should be called `tagged()`? --[[Joey]] -- cgit v1.2.3 From 36b1aa8af357e3f987ff6a4b350665297d663a76 Mon Sep 17 00:00:00 2001 From: "http://jmtd.net/" Date: Sat, 16 May 2009 07:43:53 -0400 Subject: a different tag plugin? --- doc/todo/tag_pagespec_function.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/tag_pagespec_function.mdwn b/doc/todo/tag_pagespec_function.mdwn index 5548cfd8d..71f3e81bc 100644 --- a/doc/todo/tag_pagespec_function.mdwn +++ b/doc/todo/tag_pagespec_function.mdwn @@ -15,6 +15,8 @@ match tagged pages independent of whatever the tagbase is set to. >> Yes, this is confusing and not nice. I observed this misbehavior, because I wanted to match two different lists of pages (only tagged or linked in any way), but it didn't work. Would this feature require a complex patch? --Ivan Z. +>>> If you link to a page 'foo' which happens to be a tag then the page you link from will turn up in the set of pages returned by tagged(foo). The only way to avoid this would be for the tag plugin to not use wikilinks as an implementation method. That itself would not be too hard to do, but there might be people relying on the older behaviour. A better alternative might be to have a "tag2" plugin (or a better name) which implements tagging entirely separately. -- [[Jon]] + > > One other thing, perhaps it should be called `tagged()`? --[[Joey]] -- cgit v1.2.3 From ce23a29bff8acb02f025c96aa7b1fb4466d60cbb Mon Sep 17 00:00:00 2001 From: Jon Dowland Date: Sat, 16 May 2009 14:05:11 +0100 Subject: friendly markup names for UI: e.g. 'Markdown' not 'mdwn' (patch) --- doc/todo/friendly_markup_names.mdwn | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/todo/friendly_markup_names.mdwn (limited to 'doc/todo') diff --git a/doc/todo/friendly_markup_names.mdwn b/doc/todo/friendly_markup_names.mdwn new file mode 100644 index 000000000..2b54cabab --- /dev/null +++ b/doc/todo/friendly_markup_names.mdwn @@ -0,0 +1,10 @@ +On the edit form when you are creating a new page, you are given an option of +page types that can be used. The string presented to the user here is not +particularly friendly: e.g., mdwn, txtl... it would be nice if the drop-down +contents were "Markdown", "Textile", etc. (the values in the option tags can +remain the same). + +I've written a first-take set of patches for this. They are in +git://github.com/jmtd/ikiwiki.git in the branch "friendly_markup_names". + +-- [[Jon]] -- cgit v1.2.3 From d96bedef6b65d61f05c2e204292f67b68279e7b3 Mon Sep 17 00:00:00 2001 From: Jon Dowland Date: Sat, 16 May 2009 14:08:23 +0100 Subject: tag patch --- doc/todo/friendly_markup_names.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/friendly_markup_names.mdwn b/doc/todo/friendly_markup_names.mdwn index 2b54cabab..f2789ea28 100644 --- a/doc/todo/friendly_markup_names.mdwn +++ b/doc/todo/friendly_markup_names.mdwn @@ -5,6 +5,6 @@ contents were "Markdown", "Textile", etc. (the values in the option tags can remain the same). I've written a first-take set of patches for this. They are in -git://github.com/jmtd/ikiwiki.git in the branch "friendly_markup_names". +git://github.com/jmtd/ikiwiki.git in the branch "friendly_markup_names". [[!tag patch]] -- [[Jon]] -- cgit v1.2.3 From c177ede3031306799555403490de56436fde95ea Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 16 May 2009 10:39:52 -0400 Subject: More friendly display of markdown, textile in edit form selector (jmtd) --- debian/changelog | 2 ++ doc/todo/friendly_markup_names.mdwn | 3 +++ 2 files changed, 5 insertions(+) (limited to 'doc/todo') diff --git a/debian/changelog b/debian/changelog index d8c67b5a6..c2819d0c5 100644 --- a/debian/changelog +++ b/debian/changelog @@ -4,6 +4,8 @@ ikiwiki (3.13) UNRELEASED; urgency=low containing .ikiwiki, abort with an error rather than creating it. * Allow underlaydir to be overridden without messing up inclusion of other underlays via add_underlay. + * More friendly display of markdown, textile in edit form selector + (jmtd) -- Joey Hess Wed, 06 May 2009 20:45:44 -0400 diff --git a/doc/todo/friendly_markup_names.mdwn b/doc/todo/friendly_markup_names.mdwn index f2789ea28..f88e3c1c7 100644 --- a/doc/todo/friendly_markup_names.mdwn +++ b/doc/todo/friendly_markup_names.mdwn @@ -8,3 +8,6 @@ I've written a first-take set of patches for this. They are in git://github.com/jmtd/ikiwiki.git in the branch "friendly_markup_names". [[!tag patch]] -- [[Jon]] + +[[merged|done]], TFTP! (I have not checked if any other format plugins +would benefit from a longer name) --[[Joey]] -- cgit v1.2.3 From 28f8d1d6cabf8ac2440663e615b17c547071b7fd Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Sat, 16 May 2009 15:32:15 -0400 Subject: Added wikilinks for faster navigating through the available info. --- doc/todo/hidden_links__47__tags.mdwn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/hidden_links__47__tags.mdwn b/doc/todo/hidden_links__47__tags.mdwn index 43d7a8797..2a4749394 100644 --- a/doc/todo/hidden_links__47__tags.mdwn +++ b/doc/todo/hidden_links__47__tags.mdwn @@ -5,9 +5,9 @@ Using the tag functionality I could group some news items for including them int The tagged items should not differ from the items, that are not tagged. I didn't find any way to hide the tag list or links and I don't want to have to create a "hidden" page containing links to the pages and then using the backlink functionality, because this is more prone to errors. It's easier to forget adding a link on a second page than forgetting to add a needed tag to a new newsitem. -> I found out, that using the meta plugin it is possible to create the hidden link, that I wanted. +> I found out, that using the [[meta plugin|plugins/meta]] it is possible to create the hidden link, that I wanted. -- [[users/Enno]] ->> Yes, meta link will not show up as a visible link on the page, while +>> Yes, [[meta link|ikiwiki/directive/meta]] will not show up as a visible link on the page, while >> also not showing up in the list of tags of a page, so it seems what you >> want. [[done]] --[[Joey]] -- cgit v1.2.3 From 751618c4883f9740aeaf069e73f35b4fe06b5028 Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Sat, 16 May 2009 15:49:06 -0400 Subject: Added an anchor for referring to this place. --- doc/todo/structured_page_data.mdwn | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/structured_page_data.mdwn b/doc/todo/structured_page_data.mdwn index 22f67cc0a..d9133b4aa 100644 --- a/doc/todo/structured_page_data.mdwn +++ b/doc/todo/structured_page_data.mdwn @@ -82,6 +82,7 @@ See also: > rather than all pages linked from a given page. > >The first use case is handled by having a template in the page creation. You could + >have some type of form to edit the data, but that's just sugar on top of the template. >If you were going to have a web form to edit the data, I can imagine a few ways to do it: > @@ -243,7 +244,7 @@ in a large number of other cases. > would match `data_eq(Depends on,6)`, `data_link(Depends on,bugs/bugA)`, `data_link(Depends on,bugs/bugB)` > or, if you applied the patch in [[todo/tracking_bugs_with_dependencies]] then you can use 'defined pagespecs' -> such as `data_link(Depends on,~openBugs)`. The ability to label links like this allows separation of +> such as `data_link(Depends on,~openBugs)`. The ability to label links like this allows separation of > dependencies between bugs from arbitrary links. ---- -- cgit v1.2.3 From c2dbf0d618d0ab115ab5f3b1c28dd8e17c1b013b Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Sat, 16 May 2009 16:05:03 -0400 Subject: Referred to some work that could give such a feature (disitinguishing kinds of links). --- doc/todo/tag_pagespec_function.mdwn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/tag_pagespec_function.mdwn b/doc/todo/tag_pagespec_function.mdwn index 71f3e81bc..0f2d306af 100644 --- a/doc/todo/tag_pagespec_function.mdwn +++ b/doc/todo/tag_pagespec_function.mdwn @@ -13,11 +13,11 @@ match tagged pages independent of whatever the tagbase is set to. > The only problem I see is it could be confusing if `tag(foo)` matched > a page that just linked to the tag via a wikilink, w/o actually tagging it. ->> Yes, this is confusing and not nice. I observed this misbehavior, because I wanted to match two different lists of pages (only tagged or linked in any way), but it didn't work. Would this feature require a complex patch? --Ivan Z. +>> (My [[!taglink wishlist]].) Yes, this is confusing and not nice. I observed this misbehavior, because I wanted to match two different lists of pages (only tagged or linked in any way), but it didn't work. Would this feature require a complex patch? --Ivan Z. >>> If you link to a page 'foo' which happens to be a tag then the page you link from will turn up in the set of pages returned by tagged(foo). The only way to avoid this would be for the tag plugin to not use wikilinks as an implementation method. That itself would not be too hard to do, but there might be people relying on the older behaviour. A better alternative might be to have a "tag2" plugin (or a better name) which implements tagging entirely separately. -- [[Jon]] +>>>> I see; at least, your response is encouraging (that it's not hard). I could even find some work that can give similar features: [[structured page data#another_kind_of_links]] -- they envisage a pagespec like `data_link(Depends on,bugs/bugA)`, thus a "separation of dependencies between bugs from arbitrary links". Indeed, having many relations that can be used in the formulas defining classes of objects (like pagespecs here) is a common thing, so this would be a nice feature. (I'll be trying out the patches there first, probably.) In general, extending the language of pagespecs to something more powerful (like [[!wikipedia description logics]]) seems to be a nice possible feature. I saw a discussion of similar ideas about the extension of the pagespec language somewhere here. --Ivan Z. -> > One other thing, perhaps it should be called `tagged()`? --[[Joey]] [[!tag patch done]] -- cgit v1.2.3 From 48457b6ce3a783b68549ea4fa63b222d28663fe5 Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Sat, 16 May 2009 16:33:14 -0400 Subject: Referred to related things. --- doc/todo/tracking_bugs_with_dependencies.mdwn | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/tracking_bugs_with_dependencies.mdwn b/doc/todo/tracking_bugs_with_dependencies.mdwn index 2832e37aa..b8c5b8f20 100644 --- a/doc/todo/tracking_bugs_with_dependencies.mdwn +++ b/doc/todo/tracking_bugs_with_dependencies.mdwn @@ -11,6 +11,8 @@ I like the idea of [[tips/integrated_issue_tracking_with_ikiwiki]], and I do so > >> I thought about this briefly, and got about that far.. glad you got >> further. :-) --[[Joey]] + +>> Or, one could also refer to the language of [[!wikipedia description logics]]: their formulas actually define classes of objects through quantified relations to other classes. --Ivan Z. > > Another option would be go with a more functional syntax. The concept here would > be to allow a pagespec to appear in a 'pagespec function' anywhere a page can. e.g. @@ -67,13 +69,15 @@ I like the idea of [[tips/integrated_issue_tracking_with_ikiwiki]], and I do so >>>> Yeah, guess that'd work. :-) -> One quick further thought. All the above discussion assumes that 'dependency' is the +> One quick further thought. All the above discussion assumes that 'dependency' is the > same as 'links to', which is not really true. For example, you'd like to be able to say > "This bug does not depend upon [ [ link to other bug ] ]" and not have a dependency. > Without having different types of links, I don't see how this would be possible. > > -- [[Will]] +>> I saw that this issue is targeted at by the work on [[structured page data#another_kind_of_links]]. --Ivan Z. + Okie - I've had a quick attempt at this. Initial patch attached. This one doesn't quite work. And there is still a lot of debugging stuff in there. -- cgit v1.2.3 From 5ea5f6546ea828ef45fa9e380899e8ce291e6dcb Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 16 May 2009 16:36:48 -0400 Subject: long-delayed code review This patch requires some fortitude to fully understand, but is worth it! --- doc/todo/tracking_bugs_with_dependencies.mdwn | 37 +++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/tracking_bugs_with_dependencies.mdwn b/doc/todo/tracking_bugs_with_dependencies.mdwn index 2832e37aa..ba653fdcc 100644 --- a/doc/todo/tracking_bugs_with_dependencies.mdwn +++ b/doc/todo/tracking_bugs_with_dependencies.mdwn @@ -188,6 +188,43 @@ The following three inlines work for me with this patch: I've lost track of the indent level, so I'm going back to not indented - I think this is a working [[patch]] taking into account all comments above (which doesn't mean it is above reproach :) ). --[[Will]] +> Very belated code review of last version of the patch: +> +> * `is_globlist` is no longer needed +> * `pagespec_translate` is already memoized, so the explicit call +> to memoize when handling a define seems unnecessary? +> * I don't understand why the pagespec match regexp is changed +> from having flags `igx` to `ixgs`. Don't see why you +> want `.` to match '\n` in it, and don't see any `.` in the regexp +> anyway? +> * Some changes of `@_` to `%params` in `pagespec_makeperl` do not +> make sense to me. I don't see where \%params is defined and populated, +> except with `\$params{specFunc}`. +> * Seems that the only reason `match_glob` has to check for `~` is +> because when a named spec appears in a pagespec, it is translated +> to `match_glob("~foo")`. If, instead, `pagespec_makeperl` checked +> for named specs, it could convert them into `check_named_spec("foo")` +> and avoid that ugliness. +> * The changes to `match_link` seem either unecessary, or incomplete. +> Shouldn't it check for named specs and call +> `check_named_spec_existential`? +> * Generally, the need to modify `match_*` functions so that they +> check for and handle named pagespecs seems suboptimal, if +> only because there might be others people may want to use named +> pagespecs with. It would be possible to move this check +> to `pagespec_makeperl`, by having it check if the parameter +> passed to a pagespec function looked like a named pagespec. +> The only issue is that some pagespec functions take a parameter +> that is not a page name at all, and it could be weird +> if such a parameter were accidentially interpreted as a named +> pagespec. (But, that seems unlikely to happen.) +> * I need to check if your trick to avoid infinite recursion +> works if there are two named specs that recursively +> call one-another. I suspect it does, but will test this +> myself.. +> +> --[[Joey]] + ---- diff --git a/IkiWiki.pm b/IkiWiki.pm -- cgit v1.2.3 From d25ddda9246935849dbd3860d3848acde495ef11 Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Sat, 16 May 2009 16:37:53 -0400 Subject: Referred to related discussions. --- doc/todo/structured_page_data.mdwn | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/structured_page_data.mdwn b/doc/todo/structured_page_data.mdwn index d9133b4aa..faeb7192a 100644 --- a/doc/todo/structured_page_data.mdwn +++ b/doc/todo/structured_page_data.mdwn @@ -83,6 +83,7 @@ See also: > >The first use case is handled by having a template in the page creation. You could + >have some type of form to edit the data, but that's just sugar on top of the template. >If you were going to have a web form to edit the data, I can imagine a few ways to do it: > @@ -246,7 +247,7 @@ in a large number of other cases. > or, if you applied the patch in [[todo/tracking_bugs_with_dependencies]] then you can use 'defined pagespecs' > such as `data_link(Depends on,~openBugs)`. The ability to label links like this allows separation of > dependencies between bugs from arbitrary links. - +>> This is issue (the need for distinguished kinds of links) has also been brought up in other discussions: [[tracking_bugs_with_dependencies#another_kind_of_links]] (deps vs. links) and [[tag_pagespec_function]] (tags vs. links). --Ivan Z. ---- #!/usr/bin/perl -- cgit v1.2.3 From b859373d67edbc5818295fbbe8ac2c8e74e8d76e Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Sat, 16 May 2009 16:41:01 -0400 Subject: minor: Fixing the crazy formatting in the prev.edit. --- doc/todo/structured_page_data.mdwn | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/structured_page_data.mdwn b/doc/todo/structured_page_data.mdwn index faeb7192a..72bfd8dea 100644 --- a/doc/todo/structured_page_data.mdwn +++ b/doc/todo/structured_page_data.mdwn @@ -84,6 +84,8 @@ See also: >The first use case is handled by having a template in the page creation. You could + + >have some type of form to edit the data, but that's just sugar on top of the template. >If you were going to have a web form to edit the data, I can imagine a few ways to do it: > @@ -247,7 +249,8 @@ in a large number of other cases. > or, if you applied the patch in [[todo/tracking_bugs_with_dependencies]] then you can use 'defined pagespecs' > such as `data_link(Depends on,~openBugs)`. The ability to label links like this allows separation of > dependencies between bugs from arbitrary links. ->> This is issue (the need for distinguished kinds of links) has also been brought up in other discussions: [[tracking_bugs_with_dependencies#another_kind_of_links]] (deps vs. links) and [[tag_pagespec_function]] (tags vs. links). --Ivan Z. +>> This issue (the need for distinguished kinds of links) has also been brought up in other discussions: [[tracking_bugs_with_dependencies#another_kind_of_links]] (deps vs. links) and [[tag_pagespec_function]] (tags vs. links). --Ivan Z. + ---- #!/usr/bin/perl -- cgit v1.2.3 From aca5479a3a1a0cfee1285f176f7015a53ed6cf2b Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 16 May 2009 16:45:11 -0400 Subject: remove bad item --- doc/todo/tracking_bugs_with_dependencies.mdwn | 2 -- 1 file changed, 2 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/tracking_bugs_with_dependencies.mdwn b/doc/todo/tracking_bugs_with_dependencies.mdwn index 3043cd9f2..974bf8dbb 100644 --- a/doc/todo/tracking_bugs_with_dependencies.mdwn +++ b/doc/todo/tracking_bugs_with_dependencies.mdwn @@ -195,8 +195,6 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W > Very belated code review of last version of the patch: > > * `is_globlist` is no longer needed -> * `pagespec_translate` is already memoized, so the explicit call -> to memoize when handling a define seems unnecessary? > * I don't understand why the pagespec match regexp is changed > from having flags `igx` to `ixgs`. Don't see why you > want `.` to match '\n` in it, and don't see any `.` in the regexp -- cgit v1.2.3 From 6f8d8ca1e8a0ad52b1febff3bc70bb907a2a2d72 Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Sat, 16 May 2009 17:12:12 -0400 Subject: Referred to a related thing: description logics again. --- doc/todo/pagespec_relative_to_a_target.mdwn | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/pagespec_relative_to_a_target.mdwn b/doc/todo/pagespec_relative_to_a_target.mdwn index 4757988e0..00030cce6 100644 --- a/doc/todo/pagespec_relative_to_a_target.mdwn +++ b/doc/todo/pagespec_relative_to_a_target.mdwn @@ -90,8 +90,12 @@ diff -urNX ignorepats ikiwiki/IkiWiki/Plugin/relative.pm ikidev/IkiWiki/Plugin/r [[!tag patch]] -> This looks really interesting. It reminds me of XPath and its conditionals. +> This looks really interesting. It reminds me of [[!wikipedia XPath]] and its conditionals. > Those might actually work well adapted to pagespecs. For instance, to write > "match any page with a child blah", you could just write *[blah] , or if you > don't want to use relative-by-default in the conditionals, *[./blah]. > -- [[JoshTriplett]] + +> And it [[!taglink also_reminds_me|pagespec_in_DL_style]] of [[!wikipedia description logics]]: of course, given the relation `subpage` one could write a description-logic-style formula which would define the class of pages that are ("existentially") in a given relation (`subpage` or `inverse(subpage)*subpage`) to a certain other class of pages (e.g., named "blah") ("existentially" means there must exist a page, e.g., named "blah", which is in the given relation to the candidate). + +> Probably the model behind XPath is similar (although I don't know enough to say this definitely).--Ivan Z. -- cgit v1.2.3 From 92da3c40b04d2f37f7602846949773a33ec05109 Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Sat, 16 May 2009 17:15:43 -0400 Subject: tagging description-logic-related ideas (at least, for myself) --- doc/todo/tracking_bugs_with_dependencies.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/tracking_bugs_with_dependencies.mdwn b/doc/todo/tracking_bugs_with_dependencies.mdwn index 974bf8dbb..990d39a93 100644 --- a/doc/todo/tracking_bugs_with_dependencies.mdwn +++ b/doc/todo/tracking_bugs_with_dependencies.mdwn @@ -12,7 +12,7 @@ I like the idea of [[tips/integrated_issue_tracking_with_ikiwiki]], and I do so >> I thought about this briefly, and got about that far.. glad you got >> further. :-) --[[Joey]] ->> Or, one could also refer to the language of [[!wikipedia description logics]]: their formulas actually define classes of objects through quantified relations to other classes. --Ivan Z. +>> Or, one [[!taglink could also refer|pagespec_in_DL_style]] to the language of [[!wikipedia description logics]]: their formulas actually define classes of objects through quantified relations to other classes. --Ivan Z. > > Another option would be go with a more functional syntax. The concept here would > be to allow a pagespec to appear in a 'pagespec function' anywhere a page can. e.g. -- cgit v1.2.3 From 362524e2d44df917591c1d6ba6829613773777f7 Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Sat, 16 May 2009 17:20:29 -0400 Subject: tagging description-logic-related ideas (at least, for myself) --- doc/todo/tag_pagespec_function.mdwn | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/tag_pagespec_function.mdwn b/doc/todo/tag_pagespec_function.mdwn index 0f2d306af..3604a83d9 100644 --- a/doc/todo/tag_pagespec_function.mdwn +++ b/doc/todo/tag_pagespec_function.mdwn @@ -16,7 +16,9 @@ match tagged pages independent of whatever the tagbase is set to. >> (My [[!taglink wishlist]].) Yes, this is confusing and not nice. I observed this misbehavior, because I wanted to match two different lists of pages (only tagged or linked in any way), but it didn't work. Would this feature require a complex patch? --Ivan Z. >>> If you link to a page 'foo' which happens to be a tag then the page you link from will turn up in the set of pages returned by tagged(foo). The only way to avoid this would be for the tag plugin to not use wikilinks as an implementation method. That itself would not be too hard to do, but there might be people relying on the older behaviour. A better alternative might be to have a "tag2" plugin (or a better name) which implements tagging entirely separately. -- [[Jon]] ->>>> I see; at least, your response is encouraging (that it's not hard). I could even find some work that can give similar features: [[structured page data#another_kind_of_links]] -- they envisage a pagespec like `data_link(Depends on,bugs/bugA)`, thus a "separation of dependencies between bugs from arbitrary links". Indeed, having many relations that can be used in the formulas defining classes of objects (like pagespecs here) is a common thing, so this would be a nice feature. (I'll be trying out the patches there first, probably.) In general, extending the language of pagespecs to something more powerful (like [[!wikipedia description logics]]) seems to be a nice possible feature. I saw a discussion of similar ideas about the extension of the pagespec language somewhere here. --Ivan Z. +>>>> I see; at least, your response is encouraging (that it's not hard). I could even find some work that can give similar features: [[structured page data#another_kind_of_links]] -- they envisage a pagespec like `data_link(Depends on,bugs/bugA)`, thus a "separation of dependencies between bugs from arbitrary links". + +>>>> Indeed, having many relations that can be used in the formulas defining classes of objects (like pagespecs here) is a commonly imagined thing, so this would be a nice feature. (I'll be trying out the patches there first, probably.) In general, extending the language of pagespecs to something more powerful (like [[!wikipedia description logics]]) seems to be a nice possible feature. I saw more discussions of ideas [[!taglink about_the_extension_of_the_pagespec_language_in_the_direction_similar_to_description_logics|pagespec_in_DL_style]] somewhere else here. --Ivan Z. > One other thing, perhaps it should be called `tagged()`? --[[Joey]] -- cgit v1.2.3 From f827a2af9dfc2519d85ae328b3dca3c752e1bd80 Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Sat, 16 May 2009 17:23:39 -0400 Subject: minor: Fixed the wikicode in my prev.edit. --- doc/todo/tracking_bugs_with_dependencies.mdwn | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/tracking_bugs_with_dependencies.mdwn b/doc/todo/tracking_bugs_with_dependencies.mdwn index 990d39a93..8b36f1e59 100644 --- a/doc/todo/tracking_bugs_with_dependencies.mdwn +++ b/doc/todo/tracking_bugs_with_dependencies.mdwn @@ -12,7 +12,7 @@ I like the idea of [[tips/integrated_issue_tracking_with_ikiwiki]], and I do so >> I thought about this briefly, and got about that far.. glad you got >> further. :-) --[[Joey]] ->> Or, one [[!taglink could also refer|pagespec_in_DL_style]] to the language of [[!wikipedia description logics]]: their formulas actually define classes of objects through quantified relations to other classes. --Ivan Z. +>> Or, one [[!taglink could_also_refer|pagespec_in_DL_style]] to the language of [[!wikipedia description logics]]: their formulas actually define classes of objects through quantified relations to other classes. --Ivan Z. > > Another option would be go with a more functional syntax. The concept here would > be to allow a pagespec to appear in a 'pagespec function' anywhere a page can. e.g. @@ -60,6 +60,7 @@ I like the idea of [[tips/integrated_issue_tracking_with_ikiwiki]], and I do so >> So, equivilant example: `define(bugs, bugs/* and !*/Discussion) and define(openbugs, bugs and !link(done)) and openbugs and !link(openbugs)` >> + >> Re recursion, it is avoided.. but building a pagespec that is O(N^X) where N is the >> number of pages in the wiki is not avoided. Probably need to add DOS prevention. >> --[[Joey]] -- cgit v1.2.3 From 631e7e0b20d301a00a04db72d0c020afa4ec2e71 Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Mon, 18 May 2009 17:10:26 -0400 Subject: a development on the topic of defining classes of pages --- doc/todo/inlines_inheriting_links.mdwn | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 doc/todo/inlines_inheriting_links.mdwn (limited to 'doc/todo') diff --git a/doc/todo/inlines_inheriting_links.mdwn b/doc/todo/inlines_inheriting_links.mdwn new file mode 100644 index 000000000..54249bdee --- /dev/null +++ b/doc/todo/inlines_inheriting_links.mdwn @@ -0,0 +1,16 @@ +[[!tag wishlist]] + +Continuing the ideas in [[bugs/Inline doesn't wikilink to pages]]. + +I thought of a use case for another feature: making [[directives/inline]] inherit the link relations of the included pages (optionally, say, with `inheritlinks=yes`). For example, if I want to list `elements/*` that have been linked to in any of `new_stuff/*`, I could try to write a [[ikiwiki/pagespec]] like +`elements/* and backlink(new_stuff/*)`. + +This is not yet possible, as discussed in [[todo/tracking_bugs_with_dependencies/]]. + +It would be possible to work around this limitation of pagespecs if it was possible to create a page `all_new_stuff` with `\[[!inline pages="new_stuff/*" inheritlinks=yes]]`: then the desired pagespec would be expressed as `elements/* and backlink(all_new_stuff)`. + +This is not just an ugly workaround. The availability of this feature has some reason: the classes of pages you want to refer to "recursively" (in that kind of complex pagespecs) tend to have some meaning themselves. So, I might indeed want to have a page like `all_new_stuff`, it would be useful for me. And at the same time I would like to write pagespecs like `elements/* and backlink(all_new_stuff)` -- and using the proposed feature in [[todo/tracking_bugs_with_dependencies/]] would be less clean because then I would have to enter the same information at two places: the possibly complex pagespec in the inline. And having redundant information leads to inconsistency. + +So in a sense, in some or most cases, it would indeed be cleaner to "store" the definition of a class of pages referred to in complex pagespecs as a separate object. And the most natural representation for this definition of a class of pages (adhering to the principle of wiki that what you mean is entered/stored in its most natural representation, not through some hidden disconnected code) is making a page with an inline/map/or the like, so that at the same time you store the definition and you see what it is (the set of pages is displayed to you). + +I would actually use it in my current "project" in ikiwiki: I actually edit a set of materials as a set of subpages `new_stuff/*`, and I also want to have a combined view of all of them (made through inline), and at another page, I want to list what has been linked to in `new_stuff/*` and what hasn't been linked to.--Ivan Z. -- cgit v1.2.3 From b00f5a5f522ee4e9d48dc418d70852195d0262d7 Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Mon, 18 May 2009 17:13:42 -0400 Subject: Fixed a wikilink target. --- doc/todo/inlines_inheriting_links.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/inlines_inheriting_links.mdwn b/doc/todo/inlines_inheriting_links.mdwn index 54249bdee..5560b19c6 100644 --- a/doc/todo/inlines_inheriting_links.mdwn +++ b/doc/todo/inlines_inheriting_links.mdwn @@ -2,7 +2,7 @@ Continuing the ideas in [[bugs/Inline doesn't wikilink to pages]]. -I thought of a use case for another feature: making [[directives/inline]] inherit the link relations of the included pages (optionally, say, with `inheritlinks=yes`). For example, if I want to list `elements/*` that have been linked to in any of `new_stuff/*`, I could try to write a [[ikiwiki/pagespec]] like +I thought of a use case for another feature: making [[ikiwiki/directive/inline]] inherit the link relations of the included pages (optionally, say, with `inheritlinks=yes`). For example, if I want to list `elements/*` that have been linked to in any of `new_stuff/*`, I could try to write a [[ikiwiki/pagespec]] like `elements/* and backlink(new_stuff/*)`. This is not yet possible, as discussed in [[todo/tracking_bugs_with_dependencies/]]. -- cgit v1.2.3 From 10c82d48247989412a66fd849743ea1d98335ff1 Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Mon, 18 May 2009 17:26:32 -0400 Subject: A further development of the idea. --- doc/todo/inlines_inheriting_links.mdwn | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/inlines_inheriting_links.mdwn b/doc/todo/inlines_inheriting_links.mdwn index 5560b19c6..12531990c 100644 --- a/doc/todo/inlines_inheriting_links.mdwn +++ b/doc/todo/inlines_inheriting_links.mdwn @@ -5,10 +5,14 @@ Continuing the ideas in [[bugs/Inline doesn't wikilink to pages]]. I thought of a use case for another feature: making [[ikiwiki/directive/inline]] inherit the link relations of the included pages (optionally, say, with `inheritlinks=yes`). For example, if I want to list `elements/*` that have been linked to in any of `new_stuff/*`, I could try to write a [[ikiwiki/pagespec]] like `elements/* and backlink(new_stuff/*)`. -This is not yet possible, as discussed in [[todo/tracking_bugs_with_dependencies/]]. +This is not yet possible, as discussed in [[todo/tracking_bugs_with_dependencies]]. It would be possible to work around this limitation of pagespecs if it was possible to create a page `all_new_stuff` with `\[[!inline pages="new_stuff/*" inheritlinks=yes]]`: then the desired pagespec would be expressed as `elements/* and backlink(all_new_stuff)`. +> Or, instead of specifying whether to inherit at the place of the inline, add more relations (`inline`, `backinline`) and relation composition (say, `*`, or haskell-ish `$` in order not confuse with the glob `*`) and explicitly write in the pagespecs that you want to follow the inline relation backwards: `elements/* and backlink$backinline(all_new_stuff)` or, equivalently, if [["classes"|todo/tracking_bugs_with_dependencies]] are implemented in pagespecs: `elements/* and backlink(backinline(all_new_stuff))`. Of course, this suggestion requires the powerful extension to pagespecs, but it gives more flexibility, and the possibility to avoid redundant information: the same pagespec at two places -- the inline and the other matching construction. +> +> BTW, adding more relations -- the `inline` relation among them -- would satisfy [[the other feature request|bugs/Inline doesn't wikilink to pages]]. --Ivan Z. + This is not just an ugly workaround. The availability of this feature has some reason: the classes of pages you want to refer to "recursively" (in that kind of complex pagespecs) tend to have some meaning themselves. So, I might indeed want to have a page like `all_new_stuff`, it would be useful for me. And at the same time I would like to write pagespecs like `elements/* and backlink(all_new_stuff)` -- and using the proposed feature in [[todo/tracking_bugs_with_dependencies/]] would be less clean because then I would have to enter the same information at two places: the possibly complex pagespec in the inline. And having redundant information leads to inconsistency. So in a sense, in some or most cases, it would indeed be cleaner to "store" the definition of a class of pages referred to in complex pagespecs as a separate object. And the most natural representation for this definition of a class of pages (adhering to the principle of wiki that what you mean is entered/stored in its most natural representation, not through some hidden disconnected code) is making a page with an inline/map/or the like, so that at the same time you store the definition and you see what it is (the set of pages is displayed to you). -- cgit v1.2.3 From 0e82950125d9f6182689cf74921dbb57f1140f96 Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Mon, 18 May 2009 17:47:24 -0400 Subject: formlating the thing with multiple kinds of links --- doc/todo/matching_different_kinds_of_links.mdwn | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 doc/todo/matching_different_kinds_of_links.mdwn (limited to 'doc/todo') diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn new file mode 100644 index 000000000..d3c3a1375 --- /dev/null +++ b/doc/todo/matching_different_kinds_of_links.mdwn @@ -0,0 +1,9 @@ +[[!tag wishlist]] + +As noted in [[todo/tag_pagespec_function]], there is a "misbehavior" of a `tagged()` pagespec: it matches even pages which have plain links to the tag page. + +And in general, it would be quite useful to be able to distinguish different kinds of links: one more kind, in addition to "tag", is "bug dependency" noted in [[todo/structured_page_data#another_kind_of_links]] and [[todo/tracking_bugs_with_dependencies#another_kind_of_links]]. + +It could distinguish the links by the `rel=` attribute. ([[Tags already receive a special rel-class|todo/rel_attribute_for_links]].) This means there is a general need for a syntax to specify user-defined rel-classes on wikilink (then bug deps would simply use their special rel-class, either directly, or through a special directive like `\[[!depends ]]`), and to refer to them in pagespecs (in forward and backward direction). + +Besides pagespecs, the `rel=` attribute could be used for styles. --Ivan Z. -- cgit v1.2.3