aboutsummaryrefslogtreecommitdiff
path: root/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn
blob: 9bb9c72c4527dbb34f4de4f429c574cefec3d99a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
Re the meta title escaping issue worked around by `change`. 

>   I suppose this does not only affect meta, but other things
>   at scan time too. Also, handling it only on rebuild feels
>   suspicious -- a refresh could involve changes to multiple
>   pages and trigger the same problem, I think. Also, exposing
>   this rebuild to the user seems really ugly, not confidence inducing.
>   
>   So I wonder if there's a better way. Such as making po, at scan time,
>   re-run the scan hooks, passing them modified content (either converted
>   from po to mdwn or with the escaped stuff cheaply de-escaped). (Of
>   course the scan hook would need to avoid calling itself!)
> 
>   (This doesn't need to block the merge, but I hope it can be addressed
>   eventually..)
>  
> --[[Joey]] 
>> 
>> I'll think about it soon.
>> 
>> --[[intrigeri]]
>>
>>> Did you get a chance to? --[[Joey]] 

>>>> I eventually did, and got rid of the ugly double rebuild of pages
>>>> at build time. This involved adding a `rescan` hook. Rationale
>>>> and details are in my po branch commit messages. I believe this
>>>> new way of handling meta title escaping to be far more robust.
>>>> Moreover this new implementation is more generic, feels more
>>>> logical to me, and probably fixes other similar bugs outside the
>>>> meta plugin scope. Please have a look when you can.
>>>> --[[intrigeri]]

>>>>> Glad you have tackled this. Looking at
>>>>> 25447bccae0439ea56da7a788482a4807c7c459d,
>>>>> I wonder how this rescan hook is different from a scan hook
>>>>> with `last => 1` ? Ah, it comes *after* the preprocess hook
>>>>> in scan mode. Hmm, I wonder if there's any reason to have 
>>>>> the scan hook called before those as it does now. Reordering
>>>>> those 2 lines could avoid adding a new hook. --[[Joey]]

>>>>>> Sure. I was fearing to break other plugins if I did so, so I
>>>>>> did not dare to. I'll try this. --[[intrigeri]]

>>>>>>> Done in my po branch, please have a look. --[[intrigeri]]

>>>>>>>> I've merged it. Didn't look at the po.pm changes closely;
>>>>>>>> assume they're ok. [[done]] --[[Joey]] 
>>>>>>>> 
>>>>>>>> My thinking about the reordering being safe is that
>>>>>>>> the relative ordering of scan and preprocess in scan mode hooks
>>>>>>>> has not been defined before, so it should be ok to define it. :)
>>>>>>>> 
>>>>>>>> And as to possible breakage from things that assumed the old
>>>>>>>> ordering, such a thing would need to have a scan hook and a
>>>>>>>> preprocess in scan mode hook, and the two hooks would need to 
>>>>>>>> populate the same data structure with conflicting information,
>>>>>>>> in order for there to be a problem. That seems highly unlikely
>>>>>>>> and would be pretty broken on its own. And no plugin in ikiwiki
>>>>>>>> itself has both types of hooks. --[[Joey]]