That seems hierarchical, which is ok (as in org-mode itself) but how about
implementing a more general graph mechanism, which could be used to do this
but more flexibly?
On Sat, 14 Dec 2019, 21:04 Gustav Wikström, wrote:
> Hi list and all honored readers!
>
> I have an idea. One that I've mentioned before in side notes. And I want
> to emphasize that this still only is an idea. But I want to present this
> idea to you. As a way to gather feedback and get input. Maybe the idea is
> stupid!? Maybe you think it's already solved? Or maybe it's not, and lots
> of you resonate with it as well. In any case, please let me know what you
> think on the piece below!
>
>
>
> ORG MODE: COLLECTIONS/PROJECTS
>
> Gustav Wikström
>
>
>
> Table of Contents
> _
>
> 1. Motivation
> 2. Idea
> 3. Benefit
> .. 1. For the user
> .. 2. For the developer
> 4. Example use cases
> .. 1. Separate actions from reference
> .. 2. Work / Personal separation
> .. 3. Separated book library
> .. 4. More?
> 5. Risks and challenges
> .. 1. Which configuration to use?
> .. 2. Should project config allow local variables?
> . 1. How to initialize the local variables?
> .. 3. Conflict with other customizations
> .. 4. Files that belong to multiple collections
> .. 5. Dynamic lists of files and folders for a collection?
> 6. Alternatives
> 7. References
>
>
> 1 Motivation
>
>
> Org mode is more than a major mode for emacs buffers. That has been
> clear for quite some time. Org mode can operate on sets of files.
> Consolidate TODO's and calendar information into custom views. Publish
> sets of files. To do this Org mode assumes that the user has a
> configuration for each of those features. Each feature is responsible
> for maintaining its own context. And almost all of that context has
> to be set globally. So even though Org mode has commands and features
> that operate on sets of files and folders it has not yet developed
> that in a congruent, extensible and composable way. Thus, for the
> sanity of our users and developers I think it's time to ... introduce
> another concept! One that hopefully can simplify things both for users
> and developers.
>
>
> 2 Idea
> ==
>
> I propose to introduce `Collection' as a concept in the realm of Org
> mode. [1]
>
> An Org mode collection is defined as the combination of:
> 1. A short name and description
> 2. A collection of Org mode documents
> 3. A collection of files and/or folders called attachments and
> attachment-locations for the project
> 4. A collection of configurations for the given project
>
> Globally available collections are defined in a list,
> `org-collections'. Org mode should include a safe parameter that can
> be set as a folder customization to the local active project,
> `org-collections-active'. The default should be to the first entry in
> `org-collections' unless customized. This local parameter would be
> used to instruct Emacs and Org mode on which collection is active.
> Only one collection at a time can be active.
>
> Org agenda should use `org-collections-active' as default for the
> collection of Org mode documents to operate on. Org agenda should get
> a new command to switch between active projects.
>
> I'm thinking that there could be a special Emacs major mode for the
> collection as well, called "Org collections mode". Not sure exactly
> what to display and how to represent the project there... But
> certainly some kind of list of included documents and attachments.
> When in that mode there should possibly be single key
> keyboard-shortcuts to the most important features that operate on the
> collection. And switch between them.
>
>
> 3 Benefit
> =
>
> 3.1 For the user
>
>
> A user would gain mainly two benefits as I can see right now:
> 1. The ability to clearly define (multiple) collections of files that
> belong together across org mode, with unique configurations.
> 2. Less global configuration state to manage and worry about!
>
> The second point might not look like much but is sooo important! Most
> programmers know that global state should be avoided. Putting things
> in a context most of the time makes things better. And if we can
> configure Org mode connected to a context it makes it much more useful
> for those who use Org mode for multiple purposes.
>
> The first point is equally important in my opinion. Today one must
> configure Org mode per feature. If you want to configure publishing
> you do that globally. If you want to configure the agenda, you have to
> do that globally as well. If you want to define a location for
> attachments, do it globally! What about custom TODO-keywords? Do it
> globally! Track ID-locations? Define a
