ox-hugo
ox-hugo copied to clipboard
Auto weight calculation logic
Ref (based on a question via email on how ox-hugo auto weight calculation worked):
I did encounter one problem while testing out ox-hugo regarding the auto-weight calculations and since I'm new to hugo, I didn't know if the behavior I experienced was expected or not.
Yes .. the current behavior is expected because:
- I did not want the weight calculation loop be a bottleneck as the number of posts/sections increased in the file.
- Also if I did not limit the scope, inserting a new post in an unrelated section created shifting of weights in all posts in an unrelated section. I am still not sure if allowing that is the right thing, because that will create a lot of weight shifting noise (which increases with increase in number of posts) with the addition of each new post .. unless you always create a new post at the end of the last section in your Org file.
I set this scope in these lines: https://github.com/kaushalmodi/ox-hugo/blob/9faa9fc6d80422b59be828cb911d7ff9c0178b77/ox-hugo.el#L3586-L3588
I took your deep-nesting.org (https://github.com/kaushalmodi/ox-hugo/blob/master/test/site/content-org/deep-nesting.org) and added
#+hugo_weight: auto
to the top. This successfully adds theweight
to the front-matter of each page withbook1/_index.md
getting the weight of 3001 and bothbook1/chapter1/_index.md
andbook1/chapter2/_index.md
getting the same weight of 4001.
That is expected as per the current design .. I did not expect a use case scenario like yours.
I expected
book1/chapter1/_index.md
to get the value of 4001 andbook1/chapter2/_index.md
to get the value of 4002 since chapter 1 comes first.
If I always set the scope to nil in the above referenced snippet, I kind of get what you expect (though book1/chapter2/_index.md would get 4004 weight instead of 4002 as you see below). Seeing below picture, you can also visualize the "weight shifting noise" I mentioned above. Each time you add a section to chapter1/, your chapter2/ weights will change.
I'm having some problems with this feature.
Should it be possible for the weight field to have the same values for several files, if you use weight auto?
Should it be possible for the weight field to have the same values for several files
Yes, right now, multiple files can have the same weight if they are in different sections.
I need to work on a way so that that does not happen and the export performance doesn't get hit.
ah okay.
Can we come up with a workaround, which doesnt care about performance?
I was thinking maybe advicing one of the weight calculation functions, such as org-hugo--calc-weight ?
The workaround is to simply always set the scope
to nil
on this line:
https://github.com/kaushalmodi/ox-hugo/blob/9faa9fc6d80422b59be828cb911d7ff9c0178b77/ox-hugo.el#L3586
This worked, thanks!
I was confused by this: (concat "+LEVEL=" (number-to-string level) "+EXPORT_FILE_NAME<>""")
because I thought the LEVEL wouldnt pan out.
So this is the second request I got for this .. thinking of adding an option for this. Though, it will be a little bit as I am on vacation for the next 2.5 weeks.
@jave You probably read my first post in this thread but by setting the scope
to nil
, you will now get this artifact as I mentioned in point 2 in that post:
Also if I did not limit the scope, inserting a new post in an unrelated section created shifting of weights in all posts in an unrelated section. I am still not sure if allowing that is the right thing, because that will create a lot of weight shifting noise (which increases with increase in number of posts) with the addition of each new post .. unless you always create a new post at the end of the last section in your Org file.
@kaushalmodi I've read the thread, but I'm not sure what this means in practice.
I am trying it out now. At the moment, sometimes pages do not get weights that I expect, so the order of generated pages are then also unexpected.
At the moment I dont have a nice test case. I am going to publish the project, but its full of image files, so I'm not sure where to put it yet.