summaryrefslogtreecommitdiff
path: root/doc/todo
diff options
context:
space:
mode:
Diffstat (limited to 'doc/todo')
-rw-r--r--doc/todo/Allow_disabling_edit_and_preferences_links.mdwn15
-rw-r--r--doc/todo/automatic_use_of_syntax_plugin_on_source_code_files.mdwn3
-rw-r--r--doc/todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion.mdwn1
-rw-r--r--doc/todo/comment_by_mail.mdwn52
-rw-r--r--doc/todo/latex.mdwn6
-rw-r--r--doc/todo/matching_different_kinds_of_links.mdwn10
-rw-r--r--doc/todo/mbox.mdwn5
-rw-r--r--doc/todo/section-numbering.mdwn7
-rw-r--r--doc/todo/syntax_highlighting.mdwn141
-rw-r--r--doc/todo/syntax_highlighting/discussion.mdwn2
-rw-r--r--doc/todo/target_filter_for_brokenlinks.mdwn9
-rw-r--r--doc/todo/tracking_bugs_with_dependencies.mdwn480
-rw-r--r--doc/todo/wiki-formatted_comments_with_syntax_plugin.mdwn5
13 files changed, 502 insertions, 234 deletions
diff --git a/doc/todo/Allow_disabling_edit_and_preferences_links.mdwn b/doc/todo/Allow_disabling_edit_and_preferences_links.mdwn
index a356c69df..5b9cc8742 100644
--- a/doc/todo/Allow_disabling_edit_and_preferences_links.mdwn
+++ b/doc/todo/Allow_disabling_edit_and_preferences_links.mdwn
@@ -52,3 +52,18 @@ Patch:
>>> is not controlled by any plugin. It would be nice if it were; I am
>>> trying to achieve a configuration where the only action supported
>>> via CGI is blog-style comments. --[Zack](http://zwol.livejournal.com/)
+
+>>> Like [[puck]], I'd like to keep search available but I want to disable all
+>>> login facitilities and thus disable the "Preferences" link.
+>>>
+>>> After digging a little bit in the source code, my first attempt was to make
+>>> the "Preferences" link appear only if there is `sessioncgi` hooks
+>>> registered. But this will not work as the [[plugins/inline]] plugin also
+>>> defines it.
+>>>
+>>> Looking for `auth` hooks currently would not work as at least
+>>> [[plugins/passwordauth]] does not register one.
+>>>
+>>> Adding a new `canlogin` hook looks like overkill to me. [[Joey]], how
+>>> about making registration of the `auth` hook mandatory for all plugins
+>>> making sense of the "Preferences" link? --[[Lunar]]
diff --git a/doc/todo/automatic_use_of_syntax_plugin_on_source_code_files.mdwn b/doc/todo/automatic_use_of_syntax_plugin_on_source_code_files.mdwn
index cd5ff34de..71b4b88f0 100644
--- a/doc/todo/automatic_use_of_syntax_plugin_on_source_code_files.mdwn
+++ b/doc/todo/automatic_use_of_syntax_plugin_on_source_code_files.mdwn
@@ -12,3 +12,6 @@ this would allow the use of ikiwiki for [[!wikipedia literate programming]].
* I have started something along these lines see [[plugins/contrib/sourcehighlight]]. For some reason I started with source-highlight [[DavidBremner]]
* I wonder if this is similar to what you want: <http://iki.u32.net/setup/Highlight_Code_Plugin/>
+
+> The new [[plugins/highlight]] plugin is in ikiwiki core and supports
+> source code files natively. [[done]] --[[Joey]]
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 8bc75420d..64bc21ee0 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
@@ -51,6 +51,7 @@ I hit a wall the following example (the last commit in the above repo).
</div>
>>> I don't know what is going wrong for you... source-highlight, Markdown or something else.
+>>>> It's a well-known bug in old versions of markdown. --[[Joey]]
>>> I do find it interesting the way the sourcecode `div` and the list get interleaved. That
>>> just looks like a Markdown thing though.
>>> In any case, I've updated the patch below to include most of your changes. -- [[Will]]
diff --git a/doc/todo/comment_by_mail.mdwn b/doc/todo/comment_by_mail.mdwn
index 6d3eeb044..87e57417e 100644
--- a/doc/todo/comment_by_mail.mdwn
+++ b/doc/todo/comment_by_mail.mdwn
@@ -1,53 +1,3 @@
I would like to allow comments on ikiwiki pages without CGI.
-I have in mind something like
- * Use a pagetemplate hook
- in a plugin (DONE)
- * add a mailto: url to each page matching some pagespec
- (currently every page gets a comment footer)
- * this mailto url goes to an address identifying the page (something like
- user-iki-blog~I\_hate\_markdown@host.fqdn.tld). (DONE)
- [more details](http://www.cs.unb.ca/~bremner/blog/posts/encoding)
-
- * on the mail receiving end, these messages are either deleted, or ran through
- a filter to be turned into blog posts. As a first step, I have
-[written](http://pivot.cs.unb.ca/git/?p=ikipostal.git;a=blob_plain;f=filters/postal-filer.pl;hb=010357a08e9)
-a filter that decodes the address and writes the message into an appropriate
-mailbox. I would be interested in any ideas people have about security.
-
- * the same plugin can check for comments on a particular page next time the wiki
- is generated, and add a link. (more or less done)
- > If the filter just checks in the posts into revision control, the
- > post-commit hook would handle updating the wiki to include those
- > posts as they come in. --[[Joey]]
- * work in progress can be
-
- - [cloned](http://pivot.cs.unb.ca/git/ikiperl.git), or
- - [browsed](http://pivot.cs.unb.ca/git/?p=ikipostal.git;a=summary)
-
-
-Any comments? Write them here or send them to [[DavidBremner]]
-
-> I don't want to derail this with too much blue-skying, but I was thinking
-> earlier that it would be nice if ikiwiki could do something sensible with
-> mailbox files, such as turning them into a (threaded?) blog display.
->
-> One reason I was thinking about that was just that it would be nice to
-> be able to use ikiwiki for mailing list archives. But another reason was
-> that it would be nice to solve the problem described in
-> [[discussion_page_as_blog]]. For that you really want a threaded system,
-> and mailbox file formats already have threading.
->
-> If that were done, it would tie into what you're working on in an
-> interesting way, since the incoming mail would only need to be committed to
-> the appropriate mailbox file, with ikiwiki then running to process it.
-> --[[Joey]]
->> It is an interesting idea. I like that it uses an arbitrary MUA
->> as a "moderation" interface. After I killed a debian BTS entry with
->> clumsy pseudoheader editing I think any
->> reference info should also be encoded into the address.
-
-The current version of this plugin is now running on my home page. See for example
-[a recent post in my blog](http://www.cs.unb.ca/~bremner/blog/posts/can-i-haz-a-distributed-rss/).
-Unfortunately although the [[mailbox|todo/mbox]] renderer supports threading, I haven't had
-a chance to implement comments on comments yet. [[DavidBremner]]
+> [[done]], see [[plugins/contrib/postal]]
diff --git a/doc/todo/latex.mdwn b/doc/todo/latex.mdwn
index 604c5e87f..4363003c1 100644
--- a/doc/todo/latex.mdwn
+++ b/doc/todo/latex.mdwn
@@ -7,10 +7,14 @@ render via [HeVeA](http://pauillac.inria.fr/~maranget/hevea/index.html),
similar. Useful for mathematics, as well as for stuff like the LaTeX version
of the ikiwiki [[/logo]].
+> [[users/JasonBlevins]] has also a plugin for including [[LaTeX]] expressions (by means of `itex2MML`) -- [[plugins/mdwn_itex]] (look at his page for the link). --Ivan Z.
+
----
ikiwiki could also support LaTeX as a document type, again rendering to HTML.
+> [[users/JasonBlevins]] has also a [[plugins/pandoc]] plugin (look at his page for the link): in principle, [Pandoc](http://johnmacfarlane.net/pandoc/) can read and write [[LaTeX]]. --Ivan Z.
+
----
Conversely, how about adding a plugin to support exporting to LaTeX?
@@ -25,6 +29,8 @@ Conversely, how about adding a plugin to support exporting to LaTeX?
>>>> Interesting, just yesterday I was playing with pandoc to make PDFs from my Markdown. Could someone advise me on how to embed these PDFs into ikiwiki? I need some guidance in implementing this. --[[JosephTurian]]
+>>>> [[users/JasonBlevins]] has a [[plugins/pandoc]] plugin (look at his page for the link). --Ivan Z.
+
----
[here](http://ng.l4x.org/gitweb/gitweb.cgi?p=ikiwiki.git/.git;a=blob;f=IkiWiki/Plugin/latex.pm) is a first stab at
diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn
index b71d7cc5f..26c5a072b 100644
--- a/doc/todo/matching_different_kinds_of_links.mdwn
+++ b/doc/todo/matching_different_kinds_of_links.mdwn
@@ -35,3 +35,13 @@ Besides pagespecs, the `rel=` attribute could be used for styles. --Ivan Z.
> was not available, which is why I didn't make it differentiate from
> normal links.) Might be better to go ahead and add the variable to
> core though. --[[Joey]]
+
+I saw somewhere else here some suggestions for the wiki-syntax for specifying the relation name of a link. One more suggestion---[the syntax used in Semantic MediaWiki](http://en.wikipedia.org/wiki/Semantic_MediaWiki#Basic_usage), like this:
+
+<pre>
+... the capital city is \[[Has capital::Berlin]] ...
+</pre>
+
+So a part of the effect of [[`\[[!taglink TAG\]\]`|plugins/tag]] could be represented as something like `\[[tag::TAG]]` or (more understandable relation name in what concerns the direction) `\[[tagged::TAG]]`.
+
+I don't have any opinion on this syntax (whether it's good or not)...--Ivan Z.
diff --git a/doc/todo/mbox.mdwn b/doc/todo/mbox.mdwn
index f7744563c..a6af0c3c5 100644
--- a/doc/todo/mbox.mdwn
+++ b/doc/todo/mbox.mdwn
@@ -3,7 +3,7 @@ I'd like to be able to drop an unmodified RFC2822 email message into ikiwiki, an
> We're discussing doing just that (well, whole mailboxes, really) over in
> [[comment_by_mail]] --[[Joey]]
>> The
->> [mailbox](http://pivot.cs.unb.ca/git/?p=ikimailbox.git;a=summary)
+>> [[plugins/contrib/mailbox]]
>> plugin is roughly feature complete at this point. It can read mbox, maildir, and
>> MH folders, does threading, and deals with MIME (now with
>> pagespec based sanity checking). No doubt lots of things could be
@@ -15,5 +15,4 @@ I'd like to be able to drop an unmodified RFC2822 email message into ikiwiki, an
>> It is certainly workable
>>> to use a \[[!mailbox ]] directive. -- [[DavidBremner]]
-> Your gitweb doesn't tell me where I can git pull this from, which I'd
-> like to do ... --[[Joey]]
+[[done]]
diff --git a/doc/todo/section-numbering.mdwn b/doc/todo/section-numbering.mdwn
new file mode 100644
index 000000000..3a2d232a8
--- /dev/null
+++ b/doc/todo/section-numbering.mdwn
@@ -0,0 +1,7 @@
+[[!tag wishlist]]
+
+Optional automatic section numbering would help reading: otherwise, a reader (like me) gets lost in the structure of a long page.
+
+I guess it is implementable with complex CSS... but one has first to compose this CSS in any case. So, this wish still has a todo status. --Ivan Z.
+
+And another aspect why this is related to ikiwiki, not just authoring a CSS, is that the style of the numbers (genereated by CSS probably) should match the style of the numbers in ikiwiki's [[plugins/toc]]. --Ivan Z.
diff --git a/doc/todo/syntax_highlighting.mdwn b/doc/todo/syntax_highlighting.mdwn
index b5d083ba5..3d122829b 100644
--- a/doc/todo/syntax_highlighting.mdwn
+++ b/doc/todo/syntax_highlighting.mdwn
@@ -1,48 +1,76 @@
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
+We want to 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).
+(which is either passed the text, or reads it from a file). But,
+the [[ikiwiki/directive/format]] directive makes this easy enough to
+do if the plugin only supports whole source files. So, syntax plugins
+do no really need their own preprocessor directive, unless it makes
+things easier for the user.
## 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]].
+ support [[bugs/multiple_pages_with_same_name]]. (Currently a 404 :-( )
* [[!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
+* [[plugins/contrib/sourcehighlight]] uses source-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.
+ also uses source-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`.
-* [[users/jasonblevins]]'s code plugin uses src-highlight, and supports both
- while file and directive use.
+* [[users/jasonblevins]]'s code plugin uses source-highlight, and supports both
+ whole file and directive use.
-* [hlsimple](http://pivot.cs.unb.ca/git/?p=ikiplugins.git;a=blob_plain;f=IkiWiki/Plugin/hlsimple.pm;hb=HEAD) is a wrapper for the the perl module Syntax::Highlight::Engine::Simple. This is pure perl, pretty simple, uses css. It ought to be pretty fast (according to the author, and just because it is not external).
+* [hlsimple](http://pivot.cs.unb.ca/git/?p=ikiplugins.git;a=blob_plain;f=IkiWiki/Plugin/hlsimple.pm;hb=HEAD) is a wrapper for the the perl module [[!cpan Syntax::Highlight::Engine::Simple]]. This is pure perl, pretty simple, uses css. It ought to be pretty fast (according to the author, and just because it is not external).
On the other hand, there are not many predefined languages yet. Defining language syntaxes is about as much
work as source-highlight, but in perl. I plan to package the base module for debian. Perhaps after the author
releases the 5 or 6 language definitions he has running on his web site, it might be suitable for inclusion in ikiwiki. [[DavidBremner]]
-## 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).
-
- > This is now fixed by the [[ikiwiki/directive/format]] directive for all
- > whole-source-file plugins, right?
-
+* [[plugins/highlight]] uses [highlight](http://www.andre-simon.de) via
+ its swig bindings. It optionally supports whole files, but also
+ integrates with the format directive to allow formatting of *any* of
+ highlight's supported formats. (For whole files, it uses either
+ keepextension or noextension, as appropriate for the type of file.)
+
+## General problems / requirements
+
+* Using non-perl syntax highlighting backends is slower. All things equal,
+ 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..)
+
+ Of course, some perl modules are also rather slow.. Kate, for example
+ can only process about 33 lines of C code, or 14 lines of
+ debian/changelog per second. That's **30 times slower than markdown**!
+
+ By comparison, source-highlight can do about 5000 lines of C code per
+ second... And launching the program 100 times on an empty file takes about
+ 5 seconds, which isn't bad. And, it has a C++ library, which it
+ seems likely perl bindings could be written for, to eliminate
+ even that overhead.
+ > [highlight](http://www.andre-simon.de) has similar features to source-highlight, and swig bindings
+ > that should make it trivial in principle to call from perl. I like highlight a bit better because
+ > it has a pass-through feature that I find very useful. My memory is unfortunately a bit fuzzy as to how
+ > well the swig bindings work. [[DavidBremner]]
+
+* Engines that already support a wide variety of file types are of
+ course preferred. If the engine doesn't support a particular type
+ of file, it could fall back to doing something simple like
+ adding line numbers. (IkiWiki-Plugin-syntax does this.)
+* XHTML output.
+* Emitting html that uses CSS to control the display is preferred,
+ since it allows for easy user customization. (Engine::Simple does
+ this; Kate can be configured to do it; source-highlight can be
+ made to do it via the switches `--css /dev/null --no-doc`)
* Nothing seems to support
[[wiki-formatted_comments|wiki-formatted_comments_with_syntax_plugin]]
inside source files. Doing this probably means post-processing the
@@ -69,65 +97,24 @@ releases the 5 or 6 language definitions he has running on his web site, it migh
* 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.
+ registering the htmlize hooks, though. There's also a noextension option
+ that should handle the
+ case of source files with names that do not contain an extension (ie,
+ "Makefile") -- in this case you just register the while filename
+ in the htmlize hook.
* 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.
-
- > I wonder how hard it would be to make a patch whereby a file with
- > no `.` in the name, and a name that matches a filetype, and where
- > that filetype was registered `keepextension`, then the file is just
- > chosen as the appropriate type. This would allow `Makefile` to
- > work.
-
-like this:
-
- diff --git a/IkiWiki.pm b/IkiWiki.pm
- index 8d728c9..1bd46a9 100644
- --- a/IkiWiki.pm
- +++ b/IkiWiki.pm
- @@ -618,6 +618,8 @@ sub pagetype ($) {
-
- if ($page =~ /\.([^.]+)$/) {
- return $1 if exists $hooks{htmlize}{$1};
- + } elsif ($hooks{htmlize}{$page}{keepextension}) {
- + return $page;
- }
- return;
- }
-
-## 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 """
+ "h" or "pl" etc from the dropdown that normally has "Markdown" etc in it.
+ Is this a bug, or a feature? Even if a feature, plugins with many
+ extensions make the dropdown unusable..
- This is a comment in my C file. You can use mdwn in here.
+ Perhaps the thing to do here is to use the new `longname` parameter to
+ the format hook, to give them all names that will group together at or
+ near the end of the list. Ie: "Syntax: perl", "Source code: c", etc.
- """]] */
+---
-Note that this assumes that directives are expanded in source files.
+I'm calling this [[done]] since I added the [[plugins/highlight]]
+plugin. There are some unresolved issues touched on here,
+but they either have the own other bug reports, or are documented
+as semi-features in the docs to the plugin. --[[Joey]]
diff --git a/doc/todo/syntax_highlighting/discussion.mdwn b/doc/todo/syntax_highlighting/discussion.mdwn
index 7a4095c65..27cb7084b 100644
--- a/doc/todo/syntax_highlighting/discussion.mdwn
+++ b/doc/todo/syntax_highlighting/discussion.mdwn
@@ -24,3 +24,5 @@ repository? --[[JasonBlevins]]
>> [[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]]
+
+>>> That seems to be the way to go! --[[Joey]]
diff --git a/doc/todo/target_filter_for_brokenlinks.mdwn b/doc/todo/target_filter_for_brokenlinks.mdwn
new file mode 100644
index 000000000..137277c21
--- /dev/null
+++ b/doc/todo/target_filter_for_brokenlinks.mdwn
@@ -0,0 +1,9 @@
+[[!tag wishlist]]
+
+Currently, [[plugins/brokenlinks]] supports filtering by the place where a broken wikilink is used.
+
+Filtering by the target of the broken link would also be useful, e.g.,
+
+ \[[!brokenlinks matching="tagbase/*"]]
+
+would list the tags not yet "filled out". --Ivan Z.
diff --git a/doc/todo/tracking_bugs_with_dependencies.mdwn b/doc/todo/tracking_bugs_with_dependencies.mdwn
index 8b36f1e59..3a761731b 100644
--- a/doc/todo/tracking_bugs_with_dependencies.mdwn
+++ b/doc/todo/tracking_bugs_with_dependencies.mdwn
@@ -196,21 +196,108 @@ 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
+
+>> Good :)
+
> * 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?
+
+>> Because you have to define all the named pagespecs in the pagespec, you sometimes end up with very long pagespecs. I found it useful to split them over multiple lines. That didn't work at one point and I added the 's' to make it work. I may have further altered the regex since then to make the 's' redundant. Remove it and see if multi-line pagespecs still work. :)
+
+>>> Well, I can tell you that multi-line pagespecs are supported w/o
+>>> your patch .. I use them all the time. The reason I find your
+>>> use of `/s` unlikely is because without it `\s` already matches
+>>> a newline. Only if you want to treat a newline as non-whitespace
+>>> is `/s` typically necessary. --[[Joey]]
+
> * 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}`.
+
+>> I'm not a perl hacker. This was a mighty battle for me to get going.
+>> There is probably some battlefield carnage from my early struggles
+>> learning perl left here. Part of this is that @_ / @params already
+>> existed as a way of passing in extra parameters. I didn't want to
+>> pollute that top level namespace - just at my own parameter (a hash)
+>> which contained the data I needed.
+
+>>> I think I understand how the various `%params`
+>>> (there's not just one) work in your code now, but it's really a mess.
+>>> Explaining it in words would take pages.. It could be fixed by,
+>>> in `pagespec_makeperl` something like:
+>>>
+>>> my %specFuncs;
+>>> push @_, specFuncs => \%specFuncs;
+>>>
+>>> With that you have the hash locally available for populating
+>>> inside `pagespec_makeperl`, and when the `match_*` functions
+>>> are called the same hash data will be available inside their
+>>> `@_` or `%params`. No need to change how the functions are called
+>>> or do any of the other hacks.
+>>>
+>>> Currently, specFuncs is populated by building up code
+>>> that recursively calls `pagespec_makeperl`, and is then
+>>> evaluated when the pagespec gets evaluated. My suggested
+>>> change to `%params` will break that, but that had to change
+>>> anyway.
+>>>
+>>> It probably has a security hole, and is certianly inviting
+>>> one, since the pagespec definition is matched by a loose regexp (`.*`)
+>>> and then subject to string interpolation before being evaluated
+>>> inside perl code. I recently changed ikiwiki to never interpolate
+>>> user-supplied strings when translating pagespecs, and that
+>>> needs to happen here too. The obvious way, it seems to me,
+>>> is to not generate perl code, but just directly run perl code that
+>>> populates specFuncs.
+
+>>>> I don't think this is as bad as you make out, but your addition of the
+>>>> data array will break with the recursion my patch adds in pagespec_makeperl.
+>>>> To fix that I'll need to pass a reference to that array into pagespec_makeperl.
+>>>> I think I can then do the same thing to $params{specFuncs}. -- [[Will]]
+
+>>>>> You're right -- I did not think the recursive case through.
+>>>>> --[[Joey]]
+
> * 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.
+
+>> Yeah - I wanted to make named specs syntactically different on my first pass. You are right in that this could be made a fallback - named specs always override pagenames.
+
> * The changes to `match_link` seem either unecessary, or incomplete.
> Shouldn't it check for named specs and call
> `check_named_spec_existential`?
+
+>> An earlier version did. Then I realised it wasn't actually needed in that case - match_link() already included a loop that was like a type of existential matching. Each time through the loop it would
+>> call match_glob(). match_glob() in turn will handle the named spec. I tested this version briefly and it seemed to work. I remember looking at this again later and wondering if I had mis-understood
+>> some of the logic in match_link(), which might mean there are cases where you would need an explicit call to check_named_spec_existential() - I never checked it properly after having that thought.
+
+>>> In the common case, `match_link` does not call `match_glob`,
+>>> because the link target it is being asked to check for is a single
+>>> page name, not a glob.
+
+>>>> A named pagespec should fall into the glob case. These two pagespecs should be the same:
+
+ link(a*)
+
+>>>> and
+
+ define(aStar, a*) and link(~aStar)
+
+>>>> In the first case, we want the pagespec to match any page that links to a page matching the glob.
+>>>> In the second case, we want the pagespec to match any page that links to a page matching the named spec.
+>>>> match_link() was already doing existential part. The patches to this code were simply to remove the `lc()`
+>>>> call from the named pagespec name. Can that `lc` be removed entirely? -- [[Will]]
+
+>>>>> I think we could get rid of it. `bestlink` will lc it itself
+>>>>> if the uppercase version does not exist; `match_glob` matches
+>>>>> insensitively.
+>>>>> --[[Joey]]
+
> * 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
@@ -221,120 +308,304 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W
> 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.)
+
+>> Possibly. I'm not sure which I prefer between the current solution and that one. Each have advantages and disadvantages.
+>> It really isn't much code for the match functions to add a call to check_named_spec_existential().
+
+>>> But if a plugin adds its own match function, it has
+>>> to explicitly call that code to support named pagespecs.
+
+>>>> Yes, and it can do that in just three lines of code. But if we automatically check for named pagespecs all the time we
+>>>> potentially break any matching function that doesn't accept pages, or wants to use multiple arguments.
+
+>>>>> 3 lines of code, plus the functions called become part of the API,
+>>>>> don't forget about that..
+>>>>>
+>>>>> Yes, I think that is the tradeoff, the question is whether to export
+>>>>> the additional complexity needed for that flexability.
+>>>>>
+>>>>> I'd be suprised if multiple argument pagespecs become necessary..
+>>>>> with the exception of this patch there has been no need for them yet.
+>>>>>
+>>>>> There are lots of pagespecs that take data other than pages,
+>>>>> indeed, that's really the common case. So far, none of them
+>>>>> seem likely to take data that starts with a `~`. Perhaps
+>>>>> the thing to do would be to check if `~foo` is a known,
+>>>>> named pagespec, and if not, just pass it through unchanged.
+>>>>> Then there's little room for ambiguity, and this also allows
+>>>>> pagespecs like `glob(~foo*)` to match the literal page `~foo`.
+>>>>> (It will make pagespec_merge even harder tho.. see below.)
+>>>>> --[[Joey]]
+
+>>>>>> I've already used multi-argument pagespec match functions in
+>>>>>> my data plugin. It is used for having different types of links. If
+>>>>>> you want to have multiple types of links, then the match function
+>>>>>> for them needs to take both the link name and the link type.
+>>>>>> I'm trying to think of a way we could have both - automatically
+>>>>>> handle the existential case unless the function indicates somehow
+>>>>>> that it'll do it itself. Any ideas? -- [[Will]]
+
> * 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..
->
+
+>> It worked for me. :)
+
+> * I also need to verify if memoizing the named pagespecs has
+> really guarded against very expensive pagespecs DOSing the wiki..
+
> --[[Joey]]
+>> There is one issue that I've been thinking about that I haven't raised anywhere (or checked myself), and that is how this all interacts with page dependencies.
+>> Firstly, I'm not sure anymore that the `pagespec_merge` function will continue to work in all cases.
+
+>>> The problem I can see there is that if two pagespecs
+>>> get merged and both use `~foo` but define it differently,
+>>> then the second definition might be used at a point when
+>>> it shouldn't (but I haven't verified that really happens).
+>>> That could certianly be a show-stopper. --[[Joey]]
+
+>>>> I think this can happen in the new closure based code. I don't think this could happen in the old code. -- [[Will]]
+
+>>>> Even if that works, this is a good argument for having a syntactic difference between named pagespecs and normal pages.
+>>>> If you're joining two pagespecs with 'or', you don't want a named pagespec in the first part overriding a page name in the
+>>>> second part. Oh, and I assume 'or' has the right operator precedence that "a and b or c" is "(a and b) or c", and not "a and (b or c)" -- [[Will]]
+
+>>>>> Looks like its bracketed in the code anyway... -- [[Will]]
+
+>>>> Perhaps the thing to do is to have a `clear_defines()`
+>>>> function, then merging `A` and `B` yields `(A) or (clear_defines() and (B))`
+>>>> That would deal with both the cases where `A` and `B` differently
+>>>> define `~foo` as well as with the case where `A` defines `~foo` while
+>>>> `B` uses it to refer to a literal page.
+>>>> --[[Joey]]
+
+>>>>> I don't think this will work with the new patch, and I don't think it was needed with the old one.
+>>>>> Under the old patch, pagespec_makeperl() generated a string of unevaluated, self-contained, perl
+>>>>> code. When a new named pagespec was defined, a recursive call was made to get the perl code
+>>>>> for the pagespec, and then that code was used to add something like `$params{specFuncs}->{name} = sub {recursive code} and `
+>>>>> to the result of the calling function. This means that at pagespec testing time, when this code is executed, the
+>>>>> specFuncs hash is built up as the pagespec is checked. In the case of the 'or' used above, later redefinitions of
+>>>>> a named pagespec would have redefined the specFunc at the right time. It should have just worked. However...
+
+>>>>> Since my original patch, you started using closures for security reasons (and I can see the case for that). Unfortunately this
+>>>>> means that the generated perl code is no longer self-contained - it needs to be evaluated in the same closure it was generated
+>>>>> so that it has access to the data array. To make this work with the recursive call I had two options: a) make the data array a
+>>>>> reference that I pass around through the pagespec_makeperl() functions and have available when the code is finally evaluated
+>>>>> in pagespec_translate(), or b) make sure that each pagespec is evaluated in its correct closure and a perl function is returned, not a
+>>>>> string containing unevaluated perl code.
+
+>>>>> I went with option b). I did it in such a way that the hash of specfuncs is built up at translation time, not at execution time. This
+>>>>> means that with the new code you can call specfuncs that get defined out of order:
+
+ ~test and define(~test, blah)
+
+>>>>> but it also means that using a simple 'or' to join two pagespecs wont work. If you do something like this:
+
+ ~test and define(~test, foo) and define(~test, baz)
+
+>>>>> then the last definition (baz) takes precedence.
+>>>>> In the process of writing this I think I've come up with a way to change this back the way it was, still using closures. -- [[Will]]
+
+>> Secondly, it seems that there are two types of dependency, and ikiwiki
+>> currently only handles one of them. The first type is "Rebuild this
+>> page when any of these other pages changes" - ikiwiki handles this.
+>> The second type is "rebuild this page when set of pages referred to by
+>> this pagespec changes" - ikiwiki doesn't seem to handle this. I
+>> suspect that named pagespecs would make that second type of dependency
+>> more important. I'll try to come up with a good example. -- [[Will]]
+
+>>> Hrm, I was going to build an example of this with backlinks, but it
+>>> looks like that is handled as a special case at the moment (line 458 of
+>>> render.pm). I'll see if I can breapk
+>>> things another way. Fixing this properly would allow removal of that special case. -- [[Will]]
+
+>>>> I can't quite understand the distinction you're trying to draw
+>>>> between the two types of dependencies. Backlinks are a very special
+>>>> case though and I'll be suprised if they fit well into pagespecs.
+>>>> --[[Joey]]
+
+>>>>> The issue is that the existential pagespec matching allows you to build things that have similar
+>>>>> problems to backlinks.
+>>>>> e.g. the following inline:
+
+ \[[!inline pages="define(~done, link(done)) and link(~done)" archive=yes]]
+
+>>>>> includes any page that links to a page that links to done. Now imagine I add a new link to 'done' on
+>>>>> some random page somewhere - a page which some other page links to which didn't previously get included - the set of pages accepted by the pagespec, and hence the set of
+>>>>> pages inlined, will change. But, there is no dependency anywhere on the page that I altered, so
+>>>>> ikiwiki will not rebuild the page with the inline in it. What is happening is that the page that I altered affects
+>>>>> the set of pages matched by the pagespec without itself being matched by the pagespec, and hence included in the dependency list.
+
+>>>>> To make this work well, I think you need to recognise two types of dependencies for each page (and no
+>>>>> special cases for particular types of links, eg backlinks). The first type of dependency says, "The content of
+>>>>> this page depends upon the content of these other pages". The `add_depends()` in the shortcuts
+>>>>> plugin is of this form: any time the shortcuts page is edited, any page with a shortcut on it
+>>>>> is rebuilt. The inline plugin also needs to add dependencies of this form to detect when the inlined
+>>>>> content changes. By contrast, the map plugin does not need a dependency of this form, because it
+>>>>> doesn't actually care about the content of any pages, just which pages it needs to include (which we'll handle next).
+
+>>>>> The second type of dependency says, "The content of this page depends upon the exact set of pages matched
+>>>>> by this pagespec". The first type of dependency was about the content of some pages, the second type is about
+>>>>> which pages get matched by a pagespec. This is the type of dependency tracking that the map plugin needs.
+>>>>> If the set of pages matched by map pagespec changes, then the page with the map on it needs to be rebuilt to show a different list of pages.
+>>>>> Inline needs this type of dependency as well as the previous type - This type handles a change in which pages
+>>>>> are inlined, the previous type handles a change in the content of any of those pages. Shortcut does not need this type of
+>>>>> dependency. Most of the places that use `add_depends()` seem to need this type of dependency rather than the first type.
+
+>>>>>> Note that inline and map currently achieve the second type of dependency by
+>>>>>> explicitly calling `add_depends` for each page the displayed.
+>>>>>> If any of those pages are removed, the regular pagespec would not
+>>>>>> match them -- since they're gone. However, the explicit dependency
+>>>>>> on them does cause them to match. It's an ugly corner I'd like to
+>>>>>> get rid of. --[[Joey]]
+
+>>>>> Implementation Details: The first type of dependency can be handled very similarly to the current
+>>>>> dependency system. You just need to keep a list of pages that the content depends upon. You could
+>>>>> keep that list as a pagespec, but if you do this you might want to check that the pagespec doesn't change,
+>>>>> possibly by adding a dependency of the second type along with the dependency of the first type.
+
+>>>>>> An example of the current system not tracking enough data is
+>>>>>> where A inlines B which inlines C. A change to C will cause B to
+>>>>>> rebuild, but A will not "notice" that B has implicitly changed.
+>>>>>> That example suggests it might be fixable without explicitly storing
+>>>>>> data, by causing a rebuild of B to be treated as a change to B.
+>>>>>> --[[Joey]]
+
+>>>>> The second type of dependency is a little more tricky. For each page, we'd need a list of pagespecs that
+>>>>> the page depended on, and for each pagespec you'd want to store the list of pages that currently match it.
+>>>>> On refresh, you'd need to check each pagespec to see if the set of pages that match it has changed, and if
+>>>>> that set has changed, then rebuild the dependent page(s). Oh, and for this second type of dependency, I
+>>>>> don't think you can merge pagespecs. If I wanted to know if either "\*" or "link(done)" changes, then just checking
+>>>>> to see if the set of pages matched by "\* or link(done)" changes doesn't work.
+
+>>>>> The current system works because even though you usually want dependencies of the second type, the set of pages
+>>>>> referred to by a pagespec can only change if one of those pages itself changes. i.e. A dependency check of the
+>>>>> first type will catch a dependency change of the second type with current pagespecs.
+>>>>> This doesn't work with backlinks, and it doesn't work with existential matching. Backlinks are currently special-cased. I don't know
+>>>>> how to special-case existential matching - I suspect you're better off just getting the dependency tracking right.
+
+>>>>> I also tried to come up with other possible solutions: e.g. can we find the dependencies for a pagespec? That
+>>>>> would be the set of pages where a change on one of those pages could lead to a change in the set of pages matched by the pagespec.
+>>>>> For old-style pagespecs without backlinks, the dependency set for a pagespec is the same as the set of pages the pagespec matches.
+>>>>> Unfortunately, with existential matching, the set of pages that each
+>>>>> pagespec depends upon can quickly become "*", which is not very useful. -- [[Will]]
+
+Patch updated to use closures rather than inline generated code for named pagespecs. Also includes some new use of ErrorReason where appropriate. -- [[Will]]
+
+> * Perl really doesn't need forward declarations, honest!
+
+>> It complained (warning, not error) when I didn't use the forward declaration. :(
+
+> * I have doubts about memoizing the anonymous sub created by
+> `pagespec_translate`.
+
+>> This is there explicitly to make sure that runtime is polynomial and not exponential.
+
+> * Think where you wrote `+{}` you can just write `{}`
+
+>> Possibly :) -- [[Will]]
+
----
diff --git a/IkiWiki.pm b/IkiWiki.pm
- index 4e4da11..8b3cdfe 100644
+ index 061a1c6..1e78a63 100644
--- a/IkiWiki.pm
+++ b/IkiWiki.pm
- @@ -1550,7 +1550,16 @@ sub globlist_to_pagespec ($) {
-
- sub is_globlist ($) {
- my $s=shift;
- - return ( $s =~ /[^\s]+\s+([^\s]+)/ && $1 ne "and" && $1 ne "or" );
- + return ! ($s =~ /
- + (^\s*
- + [^\s(]+ # single item
- + (\( # possibly with parens after it
- + ([^)]* # with stuff inside those parens
- + (\([^)]*\))*)* # maybe even nested parens
- + \))?\s*$
- + ) |
- + (\s and \s) | (\s or \s) # or we find 'and' or 'or' somewhere
- + /xs);
- }
-
- sub safequote ($) {
- @@ -1631,7 +1640,7 @@ sub pagespec_merge ($$) {
+ @@ -1774,8 +1774,12 @@ sub pagespec_merge ($$) {
return "($a) or ($b)";
}
-sub pagespec_translate ($) {
- +sub pagespec_makeperl ($) {
+ +# is perl really so dumb it requires a forward declaration for recursive calls?
+ +sub pagespec_translate ($$);
+ +
+ +sub pagespec_translate ($$) {
my $spec=shift;
+ + my $specFuncsRef=shift;
- # Support for old-style GlobLists.
- @@ -1650,12 +1659,14 @@ sub pagespec_translate ($) {
+ # Convert spec to perl code.
+ my $code="";
+ @@ -1789,7 +1793,9 @@ sub pagespec_translate ($) {
|
\) # )
|
- \w+\([^\)]*\) # command(params)
- + define\(\s*~\w+\s*,((\([^()]*\)) | ([^()]+))+\) # define(~specName, spec) - spec can contain parens 1 deep
+ + define\(\s*~\w+\s*,((\([^()]*\)) | ([^()]+))+\) # define(~specName, spec) - spec can contain parens 1 deep
+ |
+ \w+\([^()]*\) # command(params) - params cannot contain parens
|
[^\s()]+ # any other text
)
- \s* # ignore whitespace
- - }igx) {
- + }igxs) {
- my $word=$1;
- if (lc $word eq 'and') {
- $code.=' &&';
- @@ -1666,16 +1677,23 @@ sub pagespec_translate ($) {
+ @@ -1805,10 +1811,19 @@ sub pagespec_translate ($) {
elsif ($word eq "(" || $word eq ")" || $word eq "!") {
$code.=' '.$word;
}
- elsif ($word =~ /^(\w+)\((.*)\)$/) {
- + elsif ($word =~ /^define\(\s*~(\w+)\s*,(.*)\)$/s) {
- + $code .= " (\$params{specFuncs}->{$1}="; # (exists \$params{specFuncs}) &&
- + $code .= "memoize(";
- + $code .= &pagespec_makeperl($2);
- + $code .= ")";
- + $code .= ") ";
+ + elsif ($word =~ /^define\(\s*(~\w+)\s*,(.*)\)$/s) {
+ + my $name = $1;
+ + my $subSpec = $2;
+ + my $newSpecFunc = pagespec_translate($subSpec, $specFuncsRef);
+ + return if $@ || ! defined $newSpecFunc;
+ + $specFuncsRef->{$name} = $newSpecFunc;
+ + push @data, qq{Created named pagespec "$name"};
+ + $code.="IkiWiki::SuccessReason->new(\$data[$#data])";
+ }
+ elsif ($word =~ /^(\w+)\((.*)\)$/s) {
if (exists $IkiWiki::PageSpec::{"match_$1"}) {
- - $code.="IkiWiki::PageSpec::match_$1(\$page, ".safequote($2).", \@_)";
- + $code.="IkiWiki::PageSpec::match_$1(\$page, ".safequote($2).", \%params)";
+ push @data, $2;
+ - $code.="IkiWiki::PageSpec::match_$1(\$page, \$data[$#data], \@_)";
+ + $code.="IkiWiki::PageSpec::match_$1(\$page, \$data[$#data], \@_, specFuncs => \$specFuncsRef)";
}
else {
- $code.=' 0';
- }
+ push @data, qq{unknown function in pagespec "$word"};
+ @@ -1817,7 +1832,7 @@ sub pagespec_translate ($) {
}
else {
- - $code.=" IkiWiki::PageSpec::match_glob(\$page, ".safequote($word).", \@_)";
- + $code.=" IkiWiki::PageSpec::match_glob(\$page, ".safequote($word).", \%params)";
+ push @data, $word;
+ - $code.=" IkiWiki::PageSpec::match_glob(\$page, \$data[$#data], \@_)";
+ + $code.=" IkiWiki::PageSpec::match_glob(\$page, \$data[$#data], \@_, specFuncs => \$specFuncsRef)";
}
}
- @@ -1683,8 +1701,18 @@ sub pagespec_translate ($) {
- $code=0;
+ @@ -1826,7 +1841,7 @@ sub pagespec_translate ($) {
}
- + return 'sub { my $page=shift; my %params = @_; '.$code.' }';
- +}
- +
- +sub pagespec_translate ($) {
- + my $spec=shift;
- +
- + my $code = pagespec_makeperl($spec);
- +
- + # print STDERR "Spec '$spec' generated code '$code'\n";
- +
no warnings;
- return eval 'sub { my $page=shift; '.$code.' }';
- + return eval $code;
+ + return eval 'memoize (sub { my $page=shift; '.$code.' })';
}
sub pagespec_match ($$;@) {
- @@ -1699,7 +1727,7 @@ sub pagespec_match ($$;@) {
+ @@ -1839,7 +1854,7 @@ sub pagespec_match ($$;@) {
+ unshift @params, 'location';
+ }
- my $sub=pagespec_translate($spec);
- return IkiWiki::FailReason->new("syntax error in pagespec \"$spec\"") if $@;
- - return $sub->($page, @params);
- + return $sub->($page, @params, specFuncs => {});
- }
+ - my $sub=pagespec_translate($spec);
+ + my $sub=pagespec_translate($spec, +{});
+ return IkiWiki::ErrorReason->new("syntax error in pagespec \"$spec\"")
+ if $@ || ! defined $sub;
+ return $sub->($page, @params);
+ @@ -1850,7 +1865,7 @@ sub pagespec_match_list ($$;@) {
+ my $spec=shift;
+ my @params=@_;
+ - my $sub=pagespec_translate($spec);
+ + my $sub=pagespec_translate($spec, +{});
+ error "syntax error in pagespec \"$spec\""
+ if $@ || ! defined $sub;
+
+ @@ -1872,7 +1887,7 @@ sub pagespec_match_list ($$;@) {
sub pagespec_valid ($) {
- @@ -1748,11 +1776,78 @@ sub new {
+ my $spec=shift;
+
+ - my $sub=pagespec_translate($spec);
+ + my $sub=pagespec_translate($spec, +{});
+ return ! $@;
+ }
+
+ @@ -1919,6 +1934,68 @@ sub new {
package IkiWiki::PageSpec;
@@ -342,15 +613,14 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W
+ my $page=shift;
+ my $specName=shift;
+ my %params=@_;
- +
- + error("Unable to find specFuncs in params to check_named_spec()!") unless exists $params{specFuncs};
+ +
+ + return IkiWiki::ErrorReason->new("Unable to find specFuncs in params to check_named_spec()!")
+ + unless exists $params{specFuncs};
+
+ my $specFuncsRef=$params{specFuncs};
- +
- + return IkiWiki::FailReason->new("Named page spec '$specName' is not valid")
+ +
+ + return IkiWiki::ErrorReason->new("Named page spec '$specName' is not valid")
+ unless (substr($specName, 0, 1) eq '~');
- +
- + $specName = substr($specName, 1);
+
+ if (exists $specFuncsRef->{$specName}) {
+ # remove the named spec from the spec refs
@@ -361,7 +631,7 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W
+ $specFuncsRef->{$specName} = $sub;
+ return $result;
+ } else {
- + return IkiWiki::FailReason->new("Page spec '$specName' does not exist");
+ + return IkiWiki::ErrorReason->new("Page spec '$specName' does not exist");
+ }
+}
+
@@ -370,14 +640,14 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W
+ my $specName=shift;
+ my $funcref=shift;
+ my %params=@_;
- +
- + error("Unable to find specFuncs in params to check_named_spec_existential()!") unless exists $params{specFuncs};
+ +
+ + return IkiWiki::ErrorReason->new("Unable to find specFuncs in params to check_named_spec_existential()!")
+ + unless exists $params{specFuncs};
+ my $specFuncsRef=$params{specFuncs};
+
- + return IkiWiki::FailReason->new("Named page spec '$specName' is not valid")
+ + return IkiWiki::ErrorReason->new("Named page spec '$specName' is not valid")
+ unless (substr($specName, 0, 1) eq '~');
- + $specName = substr($specName, 1);
- +
+ +
+ if (exists $specFuncsRef->{$specName}) {
+ # remove the named spec from the spec refs
+ # when we recurse to avoid infinite recursion
@@ -389,7 +659,7 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W
+ my $tempResult = $funcref->($page, $nextpage, %params);
+ if ($tempResult) {
+ $specFuncsRef->{$specName} = $sub;
- + return $tempResult;
+ + return IkiWiki::SuccessReason->new("Existential check of '$specName' matches because $tempResult");
+ }
+ }
+ }
@@ -397,12 +667,14 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W
+ $specFuncsRef->{$specName} = $sub;
+ return IkiWiki::FailReason->new("No page in spec '$specName' was successfully matched");
+ } else {
- + return IkiWiki::FailReason->new("Named page spec '$specName' does not exist");
+ + return IkiWiki::ErrorReason->new("Named page spec '$specName' does not exist");
+ }
+}
+
- sub match_glob ($$;@) {
- my $page=shift;
+ sub derel ($$) {
+ my $path=shift;
+ my $from=shift;
+ @@ -1937,6 +2014,10 @@ sub match_glob ($$;@) {
my $glob=shift;
my %params=@_;
@@ -410,30 +682,31 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W
+ return check_named_spec($page, $glob, %params);
+ }
+
- my $from=exists $params{location} ? $params{location} : '';
-
- # relative matching
- @@ -1782,11 +1877,12 @@ sub match_internal ($$;@) {
+ $glob=derel($glob, $params{location});
+
+ my $regexp=IkiWiki::glob2re($glob);
+ @@ -1959,8 +2040,9 @@ sub match_internal ($$;@) {
sub match_link ($$;@) {
my $page=shift;
- my $link=lc(shift);
- + my $fulllink=shift;
+ + my $fullLink=shift;
my %params=@_;
- + my $link=lc($fulllink);
+ + my $link=lc($fullLink);
+ $link=derel($link, $params{location});
my $from=exists $params{location} ? $params{location} : '';
- -
- +
- # relative matching
- if ($link =~ m!^\.! && defined $from) {
- $from=~s#/?[^/]+$##;
- @@ -1804,19 +1900,32 @@ sub match_link ($$;@) {
+ @@ -1975,25 +2057,37 @@ sub match_link ($$;@) {
}
else {
return IkiWiki::SuccessReason->new("$page links to page $p matching $link")
- if match_glob($p, $link, %params);
- + if match_glob($p, $fulllink, %params);
+ + if match_glob($p, $fullLink, %params);
+ $p=~s/^\///;
+ $link=~s/^\///;
+ return IkiWiki::SuccessReason->new("$page links to page $p matching $link")
+ - if match_glob($p, $link, %params);
+ + if match_glob($p, $fullLink, %params);
}
}
return IkiWiki::FailReason->new("$page does not link to $link");
@@ -455,23 +728,24 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W
sub match_created_before ($$;@) {
my $page=shift;
my $testpage=shift;
- + my @params=@_;
+ my %params=@_;
+ -
+
+ if (substr($testpage, 0, 1) eq '~') {
- + return check_named_spec_existential($page, $testpage, \&match_created_before, @params);
+ + return check_named_spec_existential($page, $testpage, \&match_created_before, %params);
+ }
+ +
+ $testpage=derel($testpage, $params{location});
if (exists $IkiWiki::pagectime{$testpage}) {
- if ($IkiWiki::pagectime{$page} < $IkiWiki::pagectime{$testpage}) {
- @@ -1834,6 +1943,11 @@ sub match_created_before ($$;@) {
- sub match_created_after ($$;@) {
- my $page=shift;
+ @@ -2014,6 +2108,10 @@ sub match_created_after ($$;@) {
my $testpage=shift;
- + my @params=@_;
- +
+ my %params=@_;
+
+ if (substr($testpage, 0, 1) eq '~') {
- + return check_named_spec_existential($page, $testpage, \&match_created_after, @params);
+ + return check_named_spec_existential($page, $testpage, \&match_created_after, %params);
+ }
+ +
+ $testpage=derel($testpage, $params{location});
if (exists $IkiWiki::pagectime{$testpage}) {
- if ($IkiWiki::pagectime{$page} > $IkiWiki::pagectime{$testpage}) {
diff --git a/doc/todo/wiki-formatted_comments_with_syntax_plugin.mdwn b/doc/todo/wiki-formatted_comments_with_syntax_plugin.mdwn
index a5244c9ef..7a4a295d4 100644
--- a/doc/todo/wiki-formatted_comments_with_syntax_plugin.mdwn
+++ b/doc/todo/wiki-formatted_comments_with_syntax_plugin.mdwn
@@ -2,3 +2,8 @@
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.
+
+> You can do this using the [[plugins/highlight]] plugin, but you have
+> to explicitly put a format directive in the comment to do it. Thus,
+> I'm leaving this open for now.. ideally, comments would be detected,
+> and formatted as markdown. --[[Joey]]
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-29 10:21:50 +0000