X-Git-Url: https://sipb.mit.edu/gitweb.cgi/ikiwiki.git/blobdiff_plain/011fe920d162924876170d167be11dc64cf8be2f..931c7b00ccb47371ee6e1d56baf5c52d725a321f:/doc/todo/allow_plugins_to_add_sorting_methods.mdwn?ds=sidebyside

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 156678da7..c6e18505e 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -36,9 +36,11 @@ That earlier version of the branch is also available for comparison:
 >>>>> introducing "sort spec" in the API. I took a cue from
 >>>>> [[ikiwiki/pagespec/sorting]] being a subpage of
 >>>>> [[ikiwiki/pagespec]], and decided that yes, sorting is
->>>>> a bit like a pagespec :-) --s
+>>>>> a bit like a pagespec :-) Which name would you prefer? --s
 
->>>> I would be inclined to drop the `check_` stuff.
+>>>>>> `SortSpec` --[[Joey]] 
+
+>>>> I would be inclined to drop the `check_` stuff. --[[Joey]] 
 
 >>>>> It basically exists to support `title_natural`, to avoid
 >>>>> firing up the whole import mechanism on every `cmp`
@@ -48,15 +50,24 @@ That earlier version of the branch is also available for comparison:
 >>>>> [[field|plugins/contrib/field/discussion]], fail early
 >>>>> (again, not so valuable).
 >>>>>
+>>>>>> AFAIK, `use foo` has very low overhead when the module is already
+>>>>>> loaded. There could be some evalation overhead in `eval q{use foo}`,
+>>>>>> if so it would be worth addressing across the whole codebase.
+>>>>>> --[[Joey]] 
+>>>>>
 >>>>> The former function could be achieved at a small
 >>>>> compatibility cost by putting `title_natural` in a new
->>>>> sortnatural plugin (that fails to load if you don't
+>>>>> `sortnatural` plugin (that fails to load if you don't
 >>>>> have `title_natural`), if you'd prefer - that's what would
 >>>>> have happened if `title_natural` was written after this
->>>>> code had been merged, I suspect. --s
+>>>>> code had been merged, I suspect. Would you prefer this? --s
+
+>>>>>> Yes! (Assuming it does not make sense to support
+>>>>>> natural order sort of other keys than the title, at least..)
+>>>>>>  --[[Joey]]
 
 >>>> Wouldn't it make sense to have `meta(title)` instead
->>>> of `meta_title`? --J
+>>>> of `meta_title`? --[[Joey]]
 
 >>>>> Yes, you're right. I added parameters to support `field`,
 >>>>> and didn't think about making `meta` use them too.
@@ -77,10 +88,12 @@ That earlier version of the branch is also available for comparison:
 >>>>> same place as the meta-title, but occasionally not), while
 >>>>> displaying meta-titles, does look quite odd. --s
 
+>>>>>> Agreed. --[[Joey]]
+
 >>>> As I read the regexp in `cmpspec_translate`, the "command"
 >>>> is required to have params. They should be optional, 
 >>>> to match the documentation and because most sort methods
->>>> do not need parameters. --J
+>>>> do not need parameters. --[[Joey]]
 
 >>>>> No, `$2` is either `\w+\([^\)]*\)` or `[^\s]+` (with the
 >>>>> latter causing an error later if it doesn't also match `\w+`).
@@ -97,22 +110,33 @@ That earlier version of the branch is also available for comparison:
 >>>> "ascending age" both seem useful to be able to explicitly specify.
 >>>> --[[Joey]]
 
->>>>> Perhaps. I do like the simplicity of [[KathyrnAndersen]]'s syntax
+>>>>> Perhaps. I do like the simplicity of [[KathrynAndersen]]'s syntax
 >>>>> from [[plugins/contrib/report]] (which I copied verbatim, except for
->>>>> turning sort-by-`field` into a parameterized spec), and I can't really
->>>>> think of any sensible way to combine sort specs other than "sort by a,
->>>>> break ties by b, ...", possibly with some reversals thrown in.
+>>>>> turning sort-by-`field` into a parameterized spec).
+>>>>>
+>>>>> If we're getting into English-like (or at least SQL-like) queries,
+>>>>> it might make sense to change the signature of the hook function
+>>>>> so it's a function to return a key, e.g.
+>>>>> `sub key_age { return -%pagemtime{$_[0]) }`. Then we could sort like
+>>>>> this:
 >>>>>
->>>>> If no other combinations do make sense, is your proposal that "then"
->>>>> is entirely redundant (easy, just make it a predefined sort spec that
->>>>> returns 0!), or that it's mandatory "punctuation" (add an explicit
->>>>> check, or make "then" expand to "||" and let Perl fail to compile
->>>>> the generated code if it's omitted)?
+>>>>>     field(artistsort) or field(artist) or constant(Various Artists) then meta(titlesort) or meta(title) or title
 >>>>>
->>>>> It is a little unfortunate that reversal has to move into the sort
->>>>> spec - I prefer `reverse=yes` - but that's necessary for multi-level
->>>>> sorting. I can see your point about ascending/descending being more
->>>>> obvious to look at, but they're also considerably more verbose.
+>>>>> with "or" binding more closely than "then". Does this seem valuable?
+>>>>> I think the implementation would be somewhat more difficult. and
+>>>>> it's probably getting too complicated to be worthwhile, though?
+>>>>> (The keys that actually benefit from this could just
+>>>>> have smarter cmp functions, I think.)
+>>>>>
+>>>>> If the hooks return keys rather than cmp results, then we could even
+>>>>> have "lowercase" as an adjective used like "ascending"... maybe.
+>>>>> However, there are two types of adjective here: "lowercase"
+>>>>> really applies to the keys, whereas "ascending" applies to the "cmp"
+>>>>> result. Again, I think this is getting too complex, and could just
+>>>>> be solved with smarter cmp functions.
+>>>>>
+>>>>>> I agree. (Also, I think returning keys may make it harder to write
+>>>>>> smarter cmp functions.) --[[Joey]] 
 >>>>>
 >>>>> Unfortunately, `sort="ascending mtime"` actually sorts by *descending*
 >>>>> timestamp (but`sort=age` is fine, because `age` could be defined as
@@ -124,13 +148,17 @@ That earlier version of the branch is also available for comparison:
 >>>>> directions - it seems clearer to have `ascending` always be a no-op,
 >>>>> and `descending` always negate.
 >>>>>
+>>>>>> I think you've convinced me that ascending/descending impose too
+>>>>>> much semantics on it, so "-" is better. --[[Joey]]
+>>>>>
 >>>>> Perhaps we could borrow from `meta updated` and use `update_age`?
 >>>>> `updateage` would perhaps be a more normal IkiWiki style - but that
 >>>>> makes me think that updateage is a quantity analagous to tonnage or
 >>>>> voltage, with more or less recently updated pages being said to have
 >>>>> more or less updateage. I don't know whether that's good or bad :-)
 >>>>>
->>>>> I'm sure there's a much better word, but I can't see it. --s
+>>>>> I'm sure there's a much better word, but I can't see it. Do you have
+>>>>> a better idea? --s
 
 ## Documentation from sort-package branch
 
@@ -160,6 +188,9 @@ An optional `sort` parameter will be used preferentially when
 
        \[[!meta title="David Bowie" sort="Bowie, David"]]
 
+> I now realise that `author` should also have this, again for use
+> with (Western) names. --s
+
 ### Sorting plugins (added to [[plugins/write]])
 
 Similarly, it's possible to write plugins that add new functions as