(brief, sorry, via Phone. More details to follow)

I gradually splitting discussion pages into separate comment pages, containing a comment directive.

The "date" attribute is being set to the date output by gig for a commit. (I'd hope this was parseable)

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 ?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 ?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 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 Sort::Naturally, since normal cmp ordering would break pages with more than 9 comments. --s

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

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