doc/bugs/Comments_are_not_sorted_by_their_date_attribute.mdwn

   1 (brief, sorry, via Phone. More details to follow)
   2
   3 I  gradually splitting discussion pages into separate comment pages, containing a comment directive.
   4
   5 The "date" attribute is being set to the date output by gig for a commit. (I'd hope this was parseable)
   6
   7 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.
   8
   9 -- [[Jon]]
  10
  11 > Yes, comments are displayed via an inline, and usual [[pagespec/sorting]]
  12 > (eg, default of when the file was first seen) is used. The comment
  13 > date only affects the date displayed.
  14 >
  15 > > That's not what I intended - it's meant to be more or less just
  16 > > syntactic sugar for `\[[!meta date=foo]]`, setting the `%pagectime`.
  17 > > The code looks as though it ought to work, but perhaps it's buggy?
  18 > > (edited to add: it is, see below) --[[smcv]]
  19 >
  20 > The only time I've seen this be much problem personally is when moving
  21 > a page, which means moving its comments directory, which tends to
  22 > jumble the order. (And --gettime does not help, as ikiwiki does not
  23 > tell git to follow renames for speed reasons.)
  24 >
  25 > I wonder if it wouldn't be best to just get rid of the extra date
  26 > inside the comment, and rely on the file date as is done for other pages.
  27 > Thoughts [[smcv]]?
  28 >
  29 > Altenatively, since comments tend to be named "comment_N_.....",
  30 > adding a new [[pagespec/sorting]] method that sorts by filename,
  31 > rather than by title, and using it by default for comments might be
  32 > better than the current situation. --[[Joey]]
  33
  34 >> Since git does not track file time, I tend to prefer to encode date
  35 >> stuff inside files where possible.  For other pages, I put an explicit
  36 >> [[plugins/meta]] date into the source when I create the page.  I've
  37 >> had to reconstruct ordering after moving to a different git checkout
  38 >> after a server move before, it was painful ☺
  39 >>
  40 >> In my current situation, I could live with by-filename ordering. By-title
  41 >> ordering would also be workable. — [[Jon]]
  42
  43 >>> I agree with Jon's reasons for embedding an explicit date in the file.
  44 >>> As I said, this is *meant* to work, but it might not.
  45 >>>
  46 >>> Sorting by filename would only be useful with
  47 >>> [[!cpan Sort::Naturally]], since normal `cmp` ordering would break pages
  48 >>> with more than 9 comments. --s
  49
  50 ----
  51
  52 [[!template id=gitbranch author="[[smcv]]" branch=smcv/comments-metadata]]
  53
  54 I thought that, as internal pages, comments were not preprocessed
  55 (and so their date attributes did not have a chance to take effect) until
  56 they were already being inlined, by which time they have already been
  57 sorted by the files' ctimes. Actually, I was wrong about that - internal
  58 pages have a special case elsewhere - but they did skip the `scan` hook,
  59 which is also fixed in my branch.
  60
  61 The real bug was that the preprocess hook for comments didn't run
  62 in the scan phase; my branch fixes that, streamlines that hook a bit
  63 when run in the scan phase (so it doesn't htmlize, and only runs nested
  64 directives in scan mode), and adds a regression test. --[[smcv]]
  65
  66 [[!tag patch]]
  67
  68 > Thanks.. I am not 100% sure if I just forgot to scan internal pages
  69 > or left it out as some kind of optimisation since none needed to be
  70 > scanned. Anyway, if it was an optimisation it was not much of one
  71 > since they were preprocessed. All applied, [[done]]. --[[Joey]]