Skip to content
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

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

ewollesen
Copy link

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.

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.
@ewollesen
Copy link
Author

ewollesen commented Sep 24, 2022

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.

@ewollesen
Copy link
Author

I'm trying to run the tests, but they're failing in the Emacs version check. I believe this line is the indicator:

Debugger entered--Lisp error: (wrong-type-argument listp \(add-hook)
  loaddefs-generate--parse-file("/tmp/ericw/ox-hugo-dev/elpa_29/biblio-core-2021041..." "/tmp/ericw/ox-hugo-dev/elpa_29/biblio-core-2021041..." nil)

Grepping around, I found this:

/tmp/ericw/ox-hugo-dev/elpa_29/biblio-core-20210418.406/biblio-core.el
834-
835-;;;###autoload
836:3:\(add-hook \\='biblio-init-hook \\='YOUR-BACKEND-HERE).")
837-

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.

@kaushalmodi
Copy link
Owner

kaushalmodi commented Sep 25, 2022

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 C-c C-e H H behaves as expected when the point is in each of the subtrees: A, B and C.

C-c C-e H A should also behave as expected: export 2 posts from your example.

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."

@kaushalmodi
Copy link
Owner

Hello @ewollesen , I have given some thought to this. I really like the simplicity of the rule that a subtree with EXPORT_FILE_NAME property needs to be the top-level for a post, and it cannot nest other EXPORT_FILE_NAME property sub-trees.

Can you please post a real example or point to one where you find the need to do so?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants