@kaushalmodi I see the default use of -hugo is to use a single file. I'm curious about the impact of always changing the same file over months or even years. Do you have any challenges ever time?


Hello. That's a good question. So far, I have been using the single file approach for my blog posts for 2 years (not that I blog heavily), but that hasn't been an issue.

#Magit / #git interactive commits are a boon to this society. So I can incrementally commit pieces from the same file.

I also use hybrid approach where large single topics (like my notes on the #Nim language) live in separate files - 1/2


If I start creating each new #Org file for each new small post, I lose the goodies of tag/property inheritance. Also I couldn't do Swiper search or "jump to heading" quickly in this approach. So I avoid that. - 2/2

@kaushalmodi I see the same advantage with properties. A perfect setup could be to have one org for structure and properties, and pattern matching includes for posts in small files. Not sure it's possible with org though.


> pattern matching includes for posts in small files.

You can certainly put #+includes for individual Org posts. But I didn't understand the "pattern matching" portion. What would you pattern match with?

> Not sure it's possible with org though.

It might be, with some custom elisp :)


What would be the advantages of such a system?

@kaushalmodi file glob is what I mean. Something like.

* my projects
... Here some properties ...

This would have the advantages of structure and properties at the main org files propagated to the included files. This would prevent changes to previous posts, keep post in small files, have the structure in plain sight in it's own file.

Not sure of this is possible with org today.


You are right. Org wouldn't handle that.

I'm not sure what the best way would be to implement that.

@kaushalmodi maybe there is a way to extend org's export language. Something like #+INCLUDE-GLOB projects/*.org sort-function


There certainly is a way to extend the Org feature set as you suggested. It's Emacs Lisp.

Anybody is always welcome to propose a thorough plan of their feature proposal on the Org mailing list ( Puts details on the syntax and what it should expand to.

If the consensus is to add the feature, you will need to write up a patch (in elisp) to add that feature. But don't worry, you won't be alone in this process - 1/2

@benoitj There would be people in the Org mailing list to help you with syntax refinement, help how to do something specific if you have hit a brick wall, etc.

If the Org mode lead dev has time and interest in this feature, he might even implement this for you.

Just shoot an email to the mailing list with your proposal. - 2/2

@kaushalmodi thanks for the suggestions! I think ill start a blog first, the look at that :-)

Sign in to participate in the conversation

Linux Geeks doing what Linux Geeks do..