-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Toggle ommission of subheading content #673
base: main
Are you sure you want to change the base?
Conversation
Previously, when a heading was rendered, each of its subheadings' output was included in the output. With this change, a customizable variable is added that, if set, will omit those subheadings that have the :EXPORT_FILE_NAME property set from the output of their parent. This can be handy for non-blogging sites, where the content is still hierarchical, but doesn't lend itself to the blogging format where a parent page includes the content of each of its children (like a year index page, month index page, etc.) At the rist of being annoyingly verbose, before this change, if you had a post structure like this (in pseudo-org-mode format): * Post A :EXPORT_FILE_NAME: post-a Some text. ** Post B :EXPORT_FILE_NAME: post-b Text that relates to Post B. ** Post C General text, but no :EXPORT_FILE_NAME. When rendered into HTML at the URL of /posts/post-a/, one would see: Post A Some text. Post B Text that relates to Post B. Post C General text, but no :EXPORT_FILE_NAME. … After this change (and when the variable is set): Post A Some text. Post C General text, but no :EXPORT_FILE_NAME. … The premise is that Post B will have its own page (as indicated by the :EXPORT_FILE_NAME property) and so doesn't or shouldn't be included in the content of Post A.
I'm new to Elisp and ox-hugo, so apologies if I've done anything silly. I'll leave this as a draft for now while I go through all the contribution guidelines. However, if this isn't something you'd even be interested in, please let me know, so I don't waste my time with all the contribution hoop-jumping and what not. :) Thanks for all your work, ox-hugo is great! ... oh, I'm off now to update my pandoc and write some tests. |
I'm trying to run the tests, but they're failing in the Emacs version check. I believe this line is the indicator:
Grepping around, I found this:
I uhhh, don't really understand Elisp well enough to know what's going on there, but even if I did, I don't think I'd know how to fix whatever's wrong, since this seems to be a dependency. Do you have any pointers for how I might work around this problem? I guess I'll comment out the emacs version check for now. |
Hello, I cannot take a close look at this as I am on vacation. I'll be able to take a better look after October second week. While you are working on this, also make sure sure that
If it results in complicating the existing code, I'd prefer to keep the simplicity of the current design rule: "A subtree with EXPORT_FILE_NAME cannot nest other post subtrees." |
Hello @ewollesen , I have given some thought to this. I really like the simplicity of the rule that a subtree with Can you please post a real example or point to one where you find the need to do so? |
Previously, when a heading was rendered, each of its subheadings' output was included in the output. With this change, a customizable variable is added that, if set, will omit those subheadings that have the :EXPORT_FILE_NAME property set from the output of their parent.
This can be handy for non-blogging sites, where the content is still hierarchical, but doesn't lend itself to the blogging format where a parent page includes the content of each of its children (like a year index page, month index page, etc.)
At the rist of being annoyingly verbose, before this change, if you had a post structure like this (in pseudo-org-mode format):
When rendered into HTML at the URL of /posts/post-a/, one would see:
After this change (and when the variable is set):
The premise is that Post B will have its own page (as indicated by the :EXPORT_FILE_NAME property) and so doesn't or shouldn't be included in the content of Post A.