(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.
Yes, comments are displayed via an inline, and usual(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 Joeymethod that sorts by filename, rather than by title, and using it by default for comments might be better than the current situation. --
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
cmpordering 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
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