X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/6aba0a058cc442083cd60b099e8a5f6c4bb76231..a241942f17b8ffbc0d4f3251aad00708271b8344:/doc/bugs/Comments_are_not_sorted_by_their_date_attribute.mdwn?ds=sidebyside diff --git a/doc/bugs/Comments_are_not_sorted_by_their_date_attribute.mdwn b/doc/bugs/Comments_are_not_sorted_by_their_date_attribute.mdwn index b10691cff..5a4c4b2ae 100644 --- a/doc/bugs/Comments_are_not_sorted_by_their_date_attribute.mdwn +++ b/doc/bugs/Comments_are_not_sorted_by_their_date_attribute.mdwn @@ -7,3 +7,65 @@ The "date" attribute is being set to the date output by gig for a commit. (I'd h The presentation of the resulting comments is not sorted by this date, which I would hope/expect, but instead by the ctime or mtime of the file at the other end, as best I can tell. -- [[Jon]] + +> Yes, comments are displayed via an inline, and usual [[pagespec/sorting]] +> (eg, default of when the file was first seen) is used. The comment +> date only affects the date displayed. +> +> > That's not what I intended - it's meant to be more or less just +> > syntactic sugar for `\[[!meta date=foo]]`, setting the `%pagectime`. +> > The code looks as though it ought to work, but perhaps it's buggy? +> > (edited to add: it is, see below) --[[smcv]] +> +> The only time I've seen this be much problem personally is when moving +> a page, which means moving its comments directory, which tends to +> jumble the order. (And --gettime does not help, as ikiwiki does not +> tell git to follow renames for speed reasons.) +> +> I wonder if it wouldn't be best to just get rid of the extra date +> inside the comment, and rely on the file date as is done for other pages. +> Thoughts [[smcv]]? +> +> Altenatively, since comments tend to be named "comment_N_.....", +> adding a new [[pagespec/sorting]] method that sorts by filename, +> rather than by title, and using it by default for comments might be +> better than the current situation. --[[Joey]] + +>> Since git does not track file time, I tend to prefer to encode date +>> stuff inside files where possible. For other pages, I put an explicit +>> [[plugins/meta]] date into the source when I create the page. I've +>> had to reconstruct ordering after moving to a different git checkout +>> after a server move before, it was painful ☺ +>> +>> In my current situation, I could live with by-filename ordering. By-title +>> ordering would also be workable. — [[Jon]] + +>>> I agree with Jon's reasons for embedding an explicit date in the file. +>>> As I said, this is *meant* to work, but it might not. +>>> +>>> Sorting by filename would only be useful with +>>> [[!cpan Sort::Naturally]], since normal `cmp` ordering would break pages +>>> with more than 9 comments. --s + +---- + +[[!template id=gitbranch author="[[smcv]]" branch=smcv/comments-metadata]] + +I thought that, as internal pages, comments were not preprocessed +(and so their date attributes did not have a chance to take effect) until +they were already being inlined, by which time they have already been +sorted by the files' ctimes. Actually, I was wrong about that - internal +pages have a special case elsewhere - but they did skip the `scan` hook, +which is also fixed in my branch. + +The real bug was that the preprocess hook for comments didn't run +in the scan phase; my branch fixes that, streamlines that hook a bit +when run in the scan phase (so it doesn't htmlize, and only runs nested +directives in scan mode), and adds a regression test. --[[smcv]] + +[[!tag patch]] + +> Thanks.. I am not 100% sure if I just forgot to scan internal pages +> or left it out as some kind of optimisation since none needed to be +> scanned. Anyway, if it was an optimisation it was not much of one +> since they were preprocessed. All applied, [[done]]. --[[Joey]]