72 lines
3.3 KiB
Markdown
72 lines
3.3 KiB
Markdown
(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 [[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]]
|