[Idea] Org Collections

[Idea] Org Collections

[Gustav Wikström]

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 location globally!

  All above adds cognitive load to the user and makes it difficult to
  maintain the configuration as the use of Org mode grows (as it should
  ;) ). You have to define the context for each and every feature for it
  to know what to operate on. I claim that both the human psyche and the
  system itself will have a much more easy time if it could configure
  these features together, in a given context!


3.2 For the developer
~~~~~~~~~~~~~~~~~~~~~

  I claim there will be benefits for developers as well. Today there
  exists many packages that extend Org mode functionality. Many work
  with the idea of collections. Some that come to mind:
  - Org brain (<https://github.com/Kungsgeten/org-brain>)
  - Org ql (<https://github.com/alphapapa/org-ql>)
  - Ox hugo (<https://ox-hugo.scripter.co/>)

  I think that with the addition of the `collections' concept into Org
  mode, package developers get a concept they can easily attach to. Yes,
  you can easily define your own package-specific concept for that as
  well. But then the user loses out in having to configure another
  feature. And yes, today you as a developer can say that Org agenda
  will be my collection to operate on. But this is a big limitation
  since it limits what your package effectively can only work to a
  single list of files.

  Having a collections concept means you as a developer have another
  base on which you can extend. No need to define your own concept if
  `Org-agenda-files' isn't enough; make it work together with
  `org-collections' instead. Org mode users will be happy because what
  they have already defined as important for them can be reused for new
  things with ease.

  Developing features inside Org mode itself hopefully also can benefit
  from this concept. I'm sure there are many people out there with cool
  ideas on how to extend and work with Org documents. And I'm equally
  sure that the value of developing many of those features will be
  bigger if they could naturally attach to an Org collections
  definition!


4 Example use cases
===================

4.1 Separate actions from reference
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  One practice promoted by GTD is to separate actionable items from
  reference information. While that practice can be overcome by search
  etc. some might still value a clear separation.

  Want to look up something related to my general references? Search the
  Org collection related to reference-information! Maybe set up custom
  views and uses of TODO keywords for reference information for special
  agenda views.

  Want to only display not yet finished tasks? Switch to the Org
  collection for actionable items and browse away.


4.2 Work / Personal separation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  The heading says it all. Some like to separate work and personal stuff
  out from each other. What more clear way to do that than can there be
  than to separate them into their own Org collections? That way you
  potentially could let your work-related workflow (I.e. TODO-keywords)
  be different than the personal workflow. Without having to think about
  a global configuration that has to allow for both.


4.3 Separated book library
~~~~~~~~~~~~~~~~~~~~~~~~~~

  Org mode can be used as a media manager of sort. Just define your
  conventions for the Org collection using TODO-keywords, categories and
  properties. Attach the e-books you have as attachments in an
  attachment-scheme special for your book library. Configure export of
  the library using maybe a custom HTML/CSS-visual and publish it
  somewhere for yourself to look at when on your phone. And do this
  without having to think of how changing all these things will affect
  the global state of Org mode, potentially messing up your other uses
  for task management or other notes and libraries you're trying to
  manage!

  Note that one can still have a holistic view on all Org mode documents
  as well, if important. It only requires a definition of a collection
  as the collection of all other collections!


4.4 More?
~~~~~~~~~

  Please add more ideas when you think of them!


5 Risks and challenges
======================

5.1 Which configuration to use?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  When I'm visiting a file that belongs to a collection, how should
  Emacs resolve configurations for that file?

  There may be configurations in the following places:
  - Global in `emacs-custom.el' or `.emacs.d/init.el'
  - Directory local variables in the tree
  - File local variables
  - Local variables for the project definition in which the file
    belongs?

  Should visiting a file always have to scan the collections list to see
  if the file belongs to any of them, in order to load customizations?
  Hmm... Maybe!? Or - maybe not if Emacs can rely on the fact that the
  user cares to set the local variable `org-collections-active' (or
  whatever it should be called)? In that case, just evaluate the
  settings for that project without doing any scan.


5.2 Should project config allow local variables?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  Should the collections definition allow customization of variables
  that apply for Org mode features? Hmm... Maybe!? One thing that comes
  to mind is that a project should be able to define a custom attachment
  directory... How else would the attachment-feature know what
  attachment directory to use for files in that collection?

  Another option could ofc. be that each feature would have to add
  support for looking into the collection definition and override the
  local variable. But that will add development effort and complexity to
  each feature. Not suggested.


5.2.1 How to initialize the local variables?
--------------------------------------------

  When visiting a file that belongs to a collection, should Emacs at
  that point initialize the collection-configuration for that
  collection? Ideally some kind of collection-resolution would be made.
  Otherwise users will get strange behaviors when the think they are in
  one project but Org mode hasn't changed the local variables to match
  it. On the other hand, it doesn't sound very performant to have to
  check collection-belonging every time an Org mode file is visited!

  Possibly solve this with a variable that can be localized -
  `org-collections-active'?


5.3 Conflict with other customizations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  Maybe I've defined an attachment directory as a directory local
  variables in a folder, for all subfolders and files to inherit. Should
  collection-customizations override that? Or should the directory local
  variables take precedence?

  Maybe could be solved by letting the (advanced) user choose using a
  customization itself, something like
  `org-collections-precede-local-variables' ? Need a intuitive default
  though. Most sane default is probably to let local variables take
  precedence. Those are created by the user anyways, so she should be
  aware.

  The more I think of it, there shouldn't be a customization for this at
  all. I think local definitions always should override the collection
  definition.


5.4 Files that belong to multiple collections
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  What if I'm being a clever user and define multiple collections for
  the same files (I.e. overlap in the Venn-diagram of files grouped by
  collections). Which collection is "active" when I'm visiting the file?

  This depends on if Emacs should evaluate the collection-settings for
  each file visit or not. If they are evaluated for each file visit then
  the first matching project in the list of collections should apply for
  that file. If a cache is created that lists file and collection
  relationships then each file should relate to a list of collections
  where the first collection in that list should apply.

  If Emacs can rely on `org-collections-active' being set, then the
  collection referenced there should be used.


5.5 Dynamic lists of files and folders for a collection?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  Should the list of files allow for folders with recursion and patterns
  should it be required to provide a fixed defined list of files?

  Preferably the same way as `org-agenda-files' work today. Maybe some
  kind of caching-mechanism is needed though, for commands that might
  have to look for file, collection relations. A cache adds potential
  pain for the user though. If a file is added to a folder in a
  collection and a "collection-command" is run then the new file might
  not show up in the results anyway... So the user will be affected by
  caching and will have to know about it. Not good...


6 Alternatives
==============

  Doing research for this feature made me realize that much of what I'm
  proposing already exist! In another form though, as [directory
  variables]. That requires customizations to be defined as safe though.
  And today some of the things I would consider to define a collection
  aren't safe. For example `org-agenda-files', `org-todo-keywords',
  `org-publish-project-alist'.

  Some issues with relying on directory variables (Assuming they also
  are made safe):
  - When invoking Org agenda I will have to first visit a file inside a
    specific folder to get the agenda for the correct project
  - ....


[directory variables] <info:emacs#Directory variables>


7 References
============

  I've mentioned this idea the Org mode mailing list previously, but
  only as short side notes to other topics:
  - <https://lists.gnu.org/archive/html/emacs-orgmode/2018-11/msg00211.html>
  - <https://lists.gnu.org/archive/html/emacs-orgmode/2019-09/msg00010.html>

  Note that I've talked about it as "project". I think that name still
  could be considered instead of "collection". Collection is more
  general and less overloaded in terms of productivity software. And it
  shifts the focus away from task management a bit, which I think can be
  a good thing. Because while Org mode may often start to be used as a
  task/project manager software, it's useful in a much wider context
  than that!



Footnotes
_________

[1] I've previously written about this as "Projects". While Project
was my initial name for this feature I think collection may be a
better option. For the sake of this text both options work just fine.
The idea is the same.

Re: [Idea] Org Collections

[Tim Cross]

In general, I like the idea. While you are correct that most of what you
refer to can be achieved using existing org functionality, I like the
clear separation 'collections' would offer - it is like a namespace for
a collection of org documents. I like the idea of being able to isolate
customization/configuration on a per collection basis - it would
simplify some of my existing customisation plus I could experiment with
new/alternative setups in a manner which is less likely to adversely
impact my existing setup. I also suspect agenda generation and searching
could become more efficient if we can easily isolate such activities to
a collection (would still want 'global' options though). 

I would start by keeping it as simple as possible and I would restrict
configuration options (at least initially) to make things cleaner to
begin with. The .dir-locals approach has some benefits, but I've lost
count of the amount of time wasted trying to track down some
unwanted/incorrect setting only to realise it was from a .dir-locals I'd
forgotten about.

I do work in a number of different contexts - different employers,
contracts, etc. Currently, tags and properties are very useful in such
contexts. However, complete separation of these concerns into
collections sounds very appealing. Setup for a new contract/project
would be very simple and managing the different requirements would be
much easier (for example, these days, I often have to produce documents
with the correct format, logo, colour scheme etc). I have a growing set
of document style definitions that would be easier to manage on a per
collection basis rather than as a global setting).

In some of my work, I have restrictions on where data can be
stored. For example, I might be required to store all documents, data
etc relating to one contract only on a storage device owned by the
contractor. At the same time, I don't want any of my personal or
unrelated contract data stored on the corporate storage server. This can
be a little challenging when it comes to things like capture or
attachments. However, if I could have collections with completely
different 'roots' and have all my capture templates and attachment
actions apply relative to that root, then life might be easier.

Its a +1 from me. 

Gustav Wikström <gustav@whil.se> writes:

> 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 location globally!
>
>   All above adds cognitive load to the user and makes it difficult to
>   maintain the configuration as the use of Org mode grows (as it should
>   ;) ). You have to define the context for each and every feature for it
>   to know what to operate on. I claim that both the human psyche and the
>   system itself will have a much more easy time if it could configure
>   these features together, in a given context!
>
>
> 3.2 For the developer
> ~~~~~~~~~~~~~~~~~~~~~
>
>   I claim there will be benefits for developers as well. Today there
>   exists many packages that extend Org mode functionality. Many work
>   with the idea of collections. Some that come to mind:
>   - Org brain (<https://github.com/Kungsgeten/org-brain>)
>   - Org ql (<https://github.com/alphapapa/org-ql>)
>   - Ox hugo (<https://ox-hugo.scripter.co/>)
>
>   I think that with the addition of the `collections' concept into Org
>   mode, package developers get a concept they can easily attach to. Yes,
>   you can easily define your own package-specific concept for that as
>   well. But then the user loses out in having to configure another
>   feature. And yes, today you as a developer can say that Org agenda
>   will be my collection to operate on. But this is a big limitation
>   since it limits what your package effectively can only work to a
>   single list of files.
>
>   Having a collections concept means you as a developer have another
>   base on which you can extend. No need to define your own concept if
>   `Org-agenda-files' isn't enough; make it work together with
>   `org-collections' instead. Org mode users will be happy because what
>   they have already defined as important for them can be reused for new
>   things with ease.
>
>   Developing features inside Org mode itself hopefully also can benefit
>   from this concept. I'm sure there are many people out there with cool
>   ideas on how to extend and work with Org documents. And I'm equally
>   sure that the value of developing many of those features will be
>   bigger if they could naturally attach to an Org collections
>   definition!
>
>
> 4 Example use cases
> ===================
>
> 4.1 Separate actions from reference
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   One practice promoted by GTD is to separate actionable items from
>   reference information. While that practice can be overcome by search
>   etc. some might still value a clear separation.
>
>   Want to look up something related to my general references? Search the
>   Org collection related to reference-information! Maybe set up custom
>   views and uses of TODO keywords for reference information for special
>   agenda views.
>
>   Want to only display not yet finished tasks? Switch to the Org
>   collection for actionable items and browse away.
>
>
> 4.2 Work / Personal separation
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   The heading says it all. Some like to separate work and personal stuff
>   out from each other. What more clear way to do that than can there be
>   than to separate them into their own Org collections? That way you
>   potentially could let your work-related workflow (I.e. TODO-keywords)
>   be different than the personal workflow. Without having to think about
>   a global configuration that has to allow for both.
>
>
> 4.3 Separated book library
> ~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   Org mode can be used as a media manager of sort. Just define your
>   conventions for the Org collection using TODO-keywords, categories and
>   properties. Attach the e-books you have as attachments in an
>   attachment-scheme special for your book library. Configure export of
>   the library using maybe a custom HTML/CSS-visual and publish it
>   somewhere for yourself to look at when on your phone. And do this
>   without having to think of how changing all these things will affect
>   the global state of Org mode, potentially messing up your other uses
>   for task management or other notes and libraries you're trying to
>   manage!
>
>   Note that one can still have a holistic view on all Org mode documents
>   as well, if important. It only requires a definition of a collection
>   as the collection of all other collections!
>
>
> 4.4 More?
> ~~~~~~~~~
>
>   Please add more ideas when you think of them!
>
>
> 5 Risks and challenges
> ======================
>
> 5.1 Which configuration to use?
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   When I'm visiting a file that belongs to a collection, how should
>   Emacs resolve configurations for that file?
>
>   There may be configurations in the following places:
>   - Global in `emacs-custom.el' or `.emacs.d/init.el'
>   - Directory local variables in the tree
>   - File local variables
>   - Local variables for the project definition in which the file
>     belongs?
>
>   Should visiting a file always have to scan the collections list to see
>   if the file belongs to any of them, in order to load customizations?
>   Hmm... Maybe!? Or - maybe not if Emacs can rely on the fact that the
>   user cares to set the local variable `org-collections-active' (or
>   whatever it should be called)? In that case, just evaluate the
>   settings for that project without doing any scan.
>
>
> 5.2 Should project config allow local variables?
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   Should the collections definition allow customization of variables
>   that apply for Org mode features? Hmm... Maybe!? One thing that comes
>   to mind is that a project should be able to define a custom attachment
>   directory... How else would the attachment-feature know what
>   attachment directory to use for files in that collection?
>
>   Another option could ofc. be that each feature would have to add
>   support for looking into the collection definition and override the
>   local variable. But that will add development effort and complexity to
>   each feature. Not suggested.
>
>
> 5.2.1 How to initialize the local variables?
> --------------------------------------------
>
>   When visiting a file that belongs to a collection, should Emacs at
>   that point initialize the collection-configuration for that
>   collection? Ideally some kind of collection-resolution would be made.
>   Otherwise users will get strange behaviors when the think they are in
>   one project but Org mode hasn't changed the local variables to match
>   it. On the other hand, it doesn't sound very performant to have to
>   check collection-belonging every time an Org mode file is visited!
>
>   Possibly solve this with a variable that can be localized -
>   `org-collections-active'?
>
>
> 5.3 Conflict with other customizations
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   Maybe I've defined an attachment directory as a directory local
>   variables in a folder, for all subfolders and files to inherit. Should
>   collection-customizations override that? Or should the directory local
>   variables take precedence?
>
>   Maybe could be solved by letting the (advanced) user choose using a
>   customization itself, something like
>   `org-collections-precede-local-variables' ? Need a intuitive default
>   though. Most sane default is probably to let local variables take
>   precedence. Those are created by the user anyways, so she should be
>   aware.
>
>   The more I think of it, there shouldn't be a customization for this at
>   all. I think local definitions always should override the collection
>   definition.
>
>
> 5.4 Files that belong to multiple collections
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   What if I'm being a clever user and define multiple collections for
>   the same files (I.e. overlap in the Venn-diagram of files grouped by
>   collections). Which collection is "active" when I'm visiting the file?
>
>   This depends on if Emacs should evaluate the collection-settings for
>   each file visit or not. If they are evaluated for each file visit then
>   the first matching project in the list of collections should apply for
>   that file. If a cache is created that lists file and collection
>   relationships then each file should relate to a list of collections
>   where the first collection in that list should apply.
>
>   If Emacs can rely on `org-collections-active' being set, then the
>   collection referenced there should be used.
>
>
> 5.5 Dynamic lists of files and folders for a collection?
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   Should the list of files allow for folders with recursion and patterns
>   should it be required to provide a fixed defined list of files?
>
>   Preferably the same way as `org-agenda-files' work today. Maybe some
>   kind of caching-mechanism is needed though, for commands that might
>   have to look for file, collection relations. A cache adds potential
>   pain for the user though. If a file is added to a folder in a
>   collection and a "collection-command" is run then the new file might
>   not show up in the results anyway... So the user will be affected by
>   caching and will have to know about it. Not good...
>
>
> 6 Alternatives
> ==============
>
>   Doing research for this feature made me realize that much of what I'm
>   proposing already exist! In another form though, as [directory
>   variables]. That requires customizations to be defined as safe though.
>   And today some of the things I would consider to define a collection
>   aren't safe. For example `org-agenda-files', `org-todo-keywords',
>   `org-publish-project-alist'.
>
>   Some issues with relying on directory variables (Assuming they also
>   are made safe):
>   - When invoking Org agenda I will have to first visit a file inside a
>     specific folder to get the agenda for the correct project
>   - ....
>
>
> [directory variables] <info:emacs#Directory variables>
>
>
> 7 References
> ============
>
>   I've mentioned this idea the Org mode mailing list previously, but
>   only as short side notes to other topics:
>   - <https://lists.gnu.org/archive/html/emacs-orgmode/2018-11/msg00211.html>
>   - <https://lists.gnu.org/archive/html/emacs-orgmode/2019-09/msg00010.html>
>
>   Note that I've talked about it as "project". I think that name still
>   could be considered instead of "collection". Collection is more
>   general and less overloaded in terms of productivity software. And it
>   shifts the focus away from task management a bit, which I think can be
>   a good thing. Because while Org mode may often start to be used as a
>   task/project manager software, it's useful in a much wider context
>   than that!
>
>
>
> Footnotes
> _________
>
> [1] I've previously written about this as "Projects". While Project
> was my initial name for this feature I think collection may be a
> better option. For the sake of this text both options work just fine.
> The idea is the same.


-- 
Tim Cross

Re: [Idea] Org Collections

[Eric Abrahamsen]

Tim Cross <theophilusx@gmail.com> writes:


[...]

> Its a +1 from me. 

And me -- I use Org across so many different contexts (in fact, I'd
propose the name org-contexts over org-collections \end{bikeshed}),
sometimes using the /same data in different contexts/, and while Org has
good tools for localizing config options, it's never felt "clean".

I agree with Tim's point about starting with a limited approach:
restrict it to namespaced collections of config options, and see if
that's sufficient.

Eric

Re: [Idea] Org Collections

[tbanelwebmin]

[-- Attachment #1: Type: text/html, Size: 2719 bytes --]

Re: [Idea] Org Collections

[Adam Porter]

How does this idea compare with Akira Komamura's org-starter package?

https://github.com/akirak/org-starter

Its readme begins:

> Org-starter is a framework for basic configuration of Emacs Org
> Mode. It allows you to configure Org Mode easily even with many files
> and directories.

> The standard way to configure Org Mode is set a bunch of variables
> such as org-agenda-files and org-refile-targets. This makes it hard to
> add/delete files to/from the configuration. Org-starter lets you
> configure Org Mode in a file-centric and incremental manner, which
> scales well especially if you have many Org files and sometimes have
> to tweak the file list.

> In other words, org-starter allows you to configure Org Mode in a
> manner similar to use-package. The following is an example file
> configuration with org-starter:

>    (org-starter-define-file "subjects.org"
>      :agenda t
>      :refile '(:maxlevel . 9))

Re: [Idea] Org Collections

[John Sturdy]

[-- Attachment #1: Type: text/plain, Size: 16250 bytes --]

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, <gustav@whil.se> 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 location globally!
>
>   All above adds cognitive load to the user and makes it difficult to
>   maintain the configuration as the use of Org mode grows (as it should
>   ;) ). You have to define the context for each and every feature for it
>   to know what to operate on. I claim that both the human psyche and the
>   system itself will have a much more easy time if it could configure
>   these features together, in a given context!
>
>
> 3.2 For the developer
> ~~~~~~~~~~~~~~~~~~~~~
>
>   I claim there will be benefits for developers as well. Today there
>   exists many packages that extend Org mode functionality. Many work
>   with the idea of collections. Some that come to mind:
>   - Org brain (<https://github.com/Kungsgeten/org-brain>)
>   - Org ql (<https://github.com/alphapapa/org-ql>)
>   - Ox hugo (<https://ox-hugo.scripter.co/>)
>
>   I think that with the addition of the `collections' concept into Org
>   mode, package developers get a concept they can easily attach to. Yes,
>   you can easily define your own package-specific concept for that as
>   well. But then the user loses out in having to configure another
>   feature. And yes, today you as a developer can say that Org agenda
>   will be my collection to operate on. But this is a big limitation
>   since it limits what your package effectively can only work to a
>   single list of files.
>
>   Having a collections concept means you as a developer have another
>   base on which you can extend. No need to define your own concept if
>   `Org-agenda-files' isn't enough; make it work together with
>   `org-collections' instead. Org mode users will be happy because what
>   they have already defined as important for them can be reused for new
>   things with ease.
>
>   Developing features inside Org mode itself hopefully also can benefit
>   from this concept. I'm sure there are many people out there with cool
>   ideas on how to extend and work with Org documents. And I'm equally
>   sure that the value of developing many of those features will be
>   bigger if they could naturally attach to an Org collections
>   definition!
>
>
> 4 Example use cases
> ===================
>
> 4.1 Separate actions from reference
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   One practice promoted by GTD is to separate actionable items from
>   reference information. While that practice can be overcome by search
>   etc. some might still value a clear separation.
>
>   Want to look up something related to my general references? Search the
>   Org collection related to reference-information! Maybe set up custom
>   views and uses of TODO keywords for reference information for special
>   agenda views.
>
>   Want to only display not yet finished tasks? Switch to the Org
>   collection for actionable items and browse away.
>
>
> 4.2 Work / Personal separation
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   The heading says it all. Some like to separate work and personal stuff
>   out from each other. What more clear way to do that than can there be
>   than to separate them into their own Org collections? That way you
>   potentially could let your work-related workflow (I.e. TODO-keywords)
>   be different than the personal workflow. Without having to think about
>   a global configuration that has to allow for both.
>
>
> 4.3 Separated book library
> ~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   Org mode can be used as a media manager of sort. Just define your
>   conventions for the Org collection using TODO-keywords, categories and
>   properties. Attach the e-books you have as attachments in an
>   attachment-scheme special for your book library. Configure export of
>   the library using maybe a custom HTML/CSS-visual and publish it
>   somewhere for yourself to look at when on your phone. And do this
>   without having to think of how changing all these things will affect
>   the global state of Org mode, potentially messing up your other uses
>   for task management or other notes and libraries you're trying to
>   manage!
>
>   Note that one can still have a holistic view on all Org mode documents
>   as well, if important. It only requires a definition of a collection
>   as the collection of all other collections!
>
>
> 4.4 More?
> ~~~~~~~~~
>
>   Please add more ideas when you think of them!
>
>
> 5 Risks and challenges
> ======================
>
> 5.1 Which configuration to use?
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   When I'm visiting a file that belongs to a collection, how should
>   Emacs resolve configurations for that file?
>
>   There may be configurations in the following places:
>   - Global in `emacs-custom.el' or `.emacs.d/init.el'
>   - Directory local variables in the tree
>   - File local variables
>   - Local variables for the project definition in which the file
>     belongs?
>
>   Should visiting a file always have to scan the collections list to see
>   if the file belongs to any of them, in order to load customizations?
>   Hmm... Maybe!? Or - maybe not if Emacs can rely on the fact that the
>   user cares to set the local variable `org-collections-active' (or
>   whatever it should be called)? In that case, just evaluate the
>   settings for that project without doing any scan.
>
>
> 5.2 Should project config allow local variables?
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   Should the collections definition allow customization of variables
>   that apply for Org mode features? Hmm... Maybe!? One thing that comes
>   to mind is that a project should be able to define a custom attachment
>   directory... How else would the attachment-feature know what
>   attachment directory to use for files in that collection?
>
>   Another option could ofc. be that each feature would have to add
>   support for looking into the collection definition and override the
>   local variable. But that will add development effort and complexity to
>   each feature. Not suggested.
>
>
> 5.2.1 How to initialize the local variables?
> --------------------------------------------
>
>   When visiting a file that belongs to a collection, should Emacs at
>   that point initialize the collection-configuration for that
>   collection? Ideally some kind of collection-resolution would be made.
>   Otherwise users will get strange behaviors when the think they are in
>   one project but Org mode hasn't changed the local variables to match
>   it. On the other hand, it doesn't sound very performant to have to
>   check collection-belonging every time an Org mode file is visited!
>
>   Possibly solve this with a variable that can be localized -
>   `org-collections-active'?
>
>
> 5.3 Conflict with other customizations
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   Maybe I've defined an attachment directory as a directory local
>   variables in a folder, for all subfolders and files to inherit. Should
>   collection-customizations override that? Or should the directory local
>   variables take precedence?
>
>   Maybe could be solved by letting the (advanced) user choose using a
>   customization itself, something like
>   `org-collections-precede-local-variables' ? Need a intuitive default
>   though. Most sane default is probably to let local variables take
>   precedence. Those are created by the user anyways, so she should be
>   aware.
>
>   The more I think of it, there shouldn't be a customization for this at
>   all. I think local definitions always should override the collection
>   definition.
>
>
> 5.4 Files that belong to multiple collections
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   What if I'm being a clever user and define multiple collections for
>   the same files (I.e. overlap in the Venn-diagram of files grouped by
>   collections). Which collection is "active" when I'm visiting the file?
>
>   This depends on if Emacs should evaluate the collection-settings for
>   each file visit or not. If they are evaluated for each file visit then
>   the first matching project in the list of collections should apply for
>   that file. If a cache is created that lists file and collection
>   relationships then each file should relate to a list of collections
>   where the first collection in that list should apply.
>
>   If Emacs can rely on `org-collections-active' being set, then the
>   collection referenced there should be used.
>
>
> 5.5 Dynamic lists of files and folders for a collection?
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   Should the list of files allow for folders with recursion and patterns
>   should it be required to provide a fixed defined list of files?
>
>   Preferably the same way as `org-agenda-files' work today. Maybe some
>   kind of caching-mechanism is needed though, for commands that might
>   have to look for file, collection relations. A cache adds potential
>   pain for the user though. If a file is added to a folder in a
>   collection and a "collection-command" is run then the new file might
>   not show up in the results anyway... So the user will be affected by
>   caching and will have to know about it. Not good...
>
>
> 6 Alternatives
> ==============
>
>   Doing research for this feature made me realize that much of what I'm
>   proposing already exist! In another form though, as [directory
>   variables]. That requires customizations to be defined as safe though.
>   And today some of the things I would consider to define a collection
>   aren't safe. For example `org-agenda-files', `org-todo-keywords',
>   `org-publish-project-alist'.
>
>   Some issues with relying on directory variables (Assuming they also
>   are made safe):
>   - When invoking Org agenda I will have to first visit a file inside a
>     specific folder to get the agenda for the correct project
>   - ....
>
>
> [directory variables] <info:emacs#Directory variables>
>
>
> 7 References
> ============
>
>   I've mentioned this idea the Org mode mailing list previously, but
>   only as short side notes to other topics:
>   - <
> https://lists.gnu.org/archive/html/emacs-orgmode/2018-11/msg00211.html>
>   - <
> https://lists.gnu.org/archive/html/emacs-orgmode/2019-09/msg00010.html>
>
>   Note that I've talked about it as "project". I think that name still
>   could be considered instead of "collection". Collection is more
>   general and less overloaded in terms of productivity software. And it
>   shifts the focus away from task management a bit, which I think can be
>   a good thing. Because while Org mode may often start to be used as a
>   task/project manager software, it's useful in a much wider context
>   than that!
>
>
>
> Footnotes
> _________
>
> [1] I've previously written about this as "Projects". While Project
> was my initial name for this feature I think collection may be a
> better option. For the sake of this text both options work just fine.
> The idea is the same.
>

[-- Attachment #2: Type: text/html, Size: 18330 bytes --]

RE: [Idea] Org Collections

[Gustav Wikström]

[-- Attachment #1: Type: text/plain, Size: 2357 bytes --]

Yes, aware at least. I’m sure there is a big overlap in what I’m trying to achieve and what projectile tries to achieve. Not sure if an Org collection should be a Projectile add-on, or if it should be a facility inside Org mode that projectile could attach to. I think the second option would be better. But not sure yet how to realize it. Thinking in progress.

Thanks
Gustav

From: Emacs-orgmode <emacs-orgmode-bounces+gustav=whil.se@gnu.org> On Behalf Of tbanelwebmin
Sent: den 15 december 2019 10:08
To: emacs-orgmode@gnu.org
Subject: Re: [Idea] Org Collections


Interesting idea!

Is everyone aware of Emacs Projectile?
https://github.com/bbatsov/projectile

Not exactly the Org Collections you talks about, Gustav, but somehow related.

Projectile manages collections of files that belong together. They may be anything (Org Mode, Python, C++, HTML, LibreOffice, anything). It is most often zero-configuration: if a directory contains a .git or .bzr sub-directory, it is a Projectile project. A Maven project is a Projectile project, and so on. If the directory is not of a known type, just adding and empty .projectile sub-directory makes it a Projectile project.

Quite handy.

Could your Org Collections idea be a Projectile add-on?

As an example, there is such an add-on: org-projectile
https://github.com/IvanMalison/org-projectilehttps://github.com/IvanMalison/org-projectile<https://github.com/IvanMalison/org-projectilehttps:/github.com/IvanMalison/org-projectile>
"org-projectile provides functions for the creation of org-mode TODOs that are associated with projectile projects."

Regards
Le 14/12/2019 à 18:32, Gustav Wikström a écrit :

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

                    ________________________________

[-- Attachment #2: Type: text/html, Size: 7447 bytes --]

RE: [Idea] Org Collections

[Gustav Wikström]

Hi Adam,

> -----Original Message-----
> From: Emacs-orgmode <emacs-orgmode-bounces+gustav=whil.se@gnu.org> On
> Behalf Of Adam Porter
> Sent: den 15 december 2019 12:01
> To: emacs-orgmode@gnu.org
> Subject: Re: [Idea] Org Collections
> 
> How does this idea compare with Akira Komamura's org-starter package?
> 
> https://github.com/akirak/org-starter

Haven't looked much at that project before. Interesting, but not quite
what I have in mind here. That project seems like a transpose of Org
mode configurations into something that is file centric. If I play
with the thought of Org collections already being available then I
think org-starter could use that concept to, in a file centric way,
declare if a file belongs to one or multiple collections instead of
(or as a complement to...) belonging to the (default) Org agenda.

Thanks for the pointer
Gustav

RE: [Idea] Org Collections

[Gustav Wikström]

[-- Attachment #1: Type: text/plain, Size: 1853 bytes --]

Hi!

Hmm, not sure if this would classify as something hierarchical. I’d classify it as something set-based. It would allow “many to many” relations between files and collections, with definitions of the relation being declared per collection. I.e. a collection is a set of files. I haven’t thought of adding hierarchical relations between collections. I also haven’t thought of adding arbitrary named relations between collections (i.e. creating a graph). So this, in my mind, is orthogonal to hierarchies and graphs. I haven’t thought of what relations between collections should mean. And haven’t thought that there should be a syntax for that either.

But please explain more on what you think, if I misunderstood you!

/Gustav

From: John Sturdy <jcg.sturdy@gmail.com>
Sent: den 15 december 2019 13:14
To: Gustav Wikström <gustav@whil.se>
Cc: emacs-orgmode@gnu.org
Subject: Re: [Idea] Org Collections

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, <gustav@whil.se<mailto:gustav@whil.se>> 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
                    ________________________________

…

[-- Attachment #2: Type: text/html, Size: 5528 bytes --]

Re: [Idea] Org Collections

[Christian Moe]

+1, that is: This is an interesting idea, there have been times when I
might have found something like this handy, and I might well use if it's
developed, though I'm not sure if it will ease my cognitive load or add
to it. :-) 

Yours,
Christian Moe

Gustav Wikström writes:

[...]
     ________________________________
>
>                      ORG MODE: COLLECTIONS/PROJECTS
>
>                             Gustav Wikström
>                     ________________________________
>
[...]

Re: [Idea] Org Collections

[Roland Everaert]

+1 for this idea.

You speak about one document used by multiple collections, how do you
plan to manage that from a file system point of view?

How will be organized a collection, still from the FS point of view?

As some are delving into the abyss of sementic, I propose aspects
instead of collections or contexts. Ultimately we are trying to manage
various aspects of our life, by splitting those aspects into files or
diretories and what not. So, if it is the intent of your idea, the term
aspect seems more appropriate than collection or context IMHO.

Did you think about the specific UI of aspects management?
Proposal of UI I particularly like:
- Mu4E
- forge/magit

How to keep track of all those aspects?

I will surely have more to say, but, as of know I am at work.

Regards,

Roland.

Gustav Wikström writes:

> 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 location globally!
>
>   All above adds cognitive load to the user and makes it difficult to
>   maintain the configuration as the use of Org mode grows (as it should
>   ;) ). You have to define the context for each and every feature for it
>   to know what to operate on. I claim that both the human psyche and the
>   system itself will have a much more easy time if it could configure
>   these features together, in a given context!
>
>
> 3.2 For the developer
> ~~~~~~~~~~~~~~~~~~~~~
>
>   I claim there will be benefits for developers as well. Today there
>   exists many packages that extend Org mode functionality. Many work
>   with the idea of collections. Some that come to mind:
>   - Org brain (<https://github.com/Kungsgeten/org-brain>)
>   - Org ql (<https://github.com/alphapapa/org-ql>)
>   - Ox hugo (<https://ox-hugo.scripter.co/>)
>
>   I think that with the addition of the `collections' concept into Org
>   mode, package developers get a concept they can easily attach to. Yes,
>   you can easily define your own package-specific concept for that as
>   well. But then the user loses out in having to configure another
>   feature. And yes, today you as a developer can say that Org agenda
>   will be my collection to operate on. But this is a big limitation
>   since it limits what your package effectively can only work to a
>   single list of files.
>
>   Having a collections concept means you as a developer have another
>   base on which you can extend. No need to define your own concept if
>   `Org-agenda-files' isn't enough; make it work together with
>   `org-collections' instead. Org mode users will be happy because what
>   they have already defined as important for them can be reused for new
>   things with ease.
>
>   Developing features inside Org mode itself hopefully also can benefit
>   from this concept. I'm sure there are many people out there with cool
>   ideas on how to extend and work with Org documents. And I'm equally
>   sure that the value of developing many of those features will be
>   bigger if they could naturally attach to an Org collections
>   definition!
>
>
> 4 Example use cases
> ===================
>
> 4.1 Separate actions from reference
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   One practice promoted by GTD is to separate actionable items from
>   reference information. While that practice can be overcome by search
>   etc. some might still value a clear separation.
>
>   Want to look up something related to my general references? Search the
>   Org collection related to reference-information! Maybe set up custom
>   views and uses of TODO keywords for reference information for special
>   agenda views.
>
>   Want to only display not yet finished tasks? Switch to the Org
>   collection for actionable items and browse away.
>
>
> 4.2 Work / Personal separation
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   The heading says it all. Some like to separate work and personal stuff
>   out from each other. What more clear way to do that than can there be
>   than to separate them into their own Org collections? That way you
>   potentially could let your work-related workflow (I.e. TODO-keywords)
>   be different than the personal workflow. Without having to think about
>   a global configuration that has to allow for both.
>
>
> 4.3 Separated book library
> ~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   Org mode can be used as a media manager of sort. Just define your
>   conventions for the Org collection using TODO-keywords, categories and
>   properties. Attach the e-books you have as attachments in an
>   attachment-scheme special for your book library. Configure export of
>   the library using maybe a custom HTML/CSS-visual and publish it
>   somewhere for yourself to look at when on your phone. And do this
>   without having to think of how changing all these things will affect
>   the global state of Org mode, potentially messing up your other uses
>   for task management or other notes and libraries you're trying to
>   manage!
>
>   Note that one can still have a holistic view on all Org mode documents
>   as well, if important. It only requires a definition of a collection
>   as the collection of all other collections!
>
>
> 4.4 More?
> ~~~~~~~~~
>
>   Please add more ideas when you think of them!
>
>
> 5 Risks and challenges
> ======================
>
> 5.1 Which configuration to use?
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   When I'm visiting a file that belongs to a collection, how should
>   Emacs resolve configurations for that file?
>
>   There may be configurations in the following places:
>   - Global in `emacs-custom.el' or `.emacs.d/init.el'
>   - Directory local variables in the tree
>   - File local variables
>   - Local variables for the project definition in which the file
>     belongs?
>
>   Should visiting a file always have to scan the collections list to see
>   if the file belongs to any of them, in order to load customizations?
>   Hmm... Maybe!? Or - maybe not if Emacs can rely on the fact that the
>   user cares to set the local variable `org-collections-active' (or
>   whatever it should be called)? In that case, just evaluate the
>   settings for that project without doing any scan.
>
>
> 5.2 Should project config allow local variables?
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   Should the collections definition allow customization of variables
>   that apply for Org mode features? Hmm... Maybe!? One thing that comes
>   to mind is that a project should be able to define a custom attachment
>   directory... How else would the attachment-feature know what
>   attachment directory to use for files in that collection?
>
>   Another option could ofc. be that each feature would have to add
>   support for looking into the collection definition and override the
>   local variable. But that will add development effort and complexity to
>   each feature. Not suggested.
>
>
> 5.2.1 How to initialize the local variables?
> --------------------------------------------
>
>   When visiting a file that belongs to a collection, should Emacs at
>   that point initialize the collection-configuration for that
>   collection? Ideally some kind of collection-resolution would be made.
>   Otherwise users will get strange behaviors when the think they are in
>   one project but Org mode hasn't changed the local variables to match
>   it. On the other hand, it doesn't sound very performant to have to
>   check collection-belonging every time an Org mode file is visited!
>
>   Possibly solve this with a variable that can be localized -
>   `org-collections-active'?
>
>
> 5.3 Conflict with other customizations
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   Maybe I've defined an attachment directory as a directory local
>   variables in a folder, for all subfolders and files to inherit. Should
>   collection-customizations override that? Or should the directory local
>   variables take precedence?
>
>   Maybe could be solved by letting the (advanced) user choose using a
>   customization itself, something like
>   `org-collections-precede-local-variables' ? Need a intuitive default
>   though. Most sane default is probably to let local variables take
>   precedence. Those are created by the user anyways, so she should be
>   aware.
>
>   The more I think of it, there shouldn't be a customization for this at
>   all. I think local definitions always should override the collection
>   definition.
>
>
> 5.4 Files that belong to multiple collections
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   What if I'm being a clever user and define multiple collections for
>   the same files (I.e. overlap in the Venn-diagram of files grouped by
>   collections). Which collection is "active" when I'm visiting the file?
>
>   This depends on if Emacs should evaluate the collection-settings for
>   each file visit or not. If they are evaluated for each file visit then
>   the first matching project in the list of collections should apply for
>   that file. If a cache is created that lists file and collection
>   relationships then each file should relate to a list of collections
>   where the first collection in that list should apply.
>
>   If Emacs can rely on `org-collections-active' being set, then the
>   collection referenced there should be used.
>
>
> 5.5 Dynamic lists of files and folders for a collection?
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   Should the list of files allow for folders with recursion and patterns
>   should it be required to provide a fixed defined list of files?
>
>   Preferably the same way as `org-agenda-files' work today. Maybe some
>   kind of caching-mechanism is needed though, for commands that might
>   have to look for file, collection relations. A cache adds potential
>   pain for the user though. If a file is added to a folder in a
>   collection and a "collection-command" is run then the new file might
>   not show up in the results anyway... So the user will be affected by
>   caching and will have to know about it. Not good...
>
>
> 6 Alternatives
> ==============
>
>   Doing research for this feature made me realize that much of what I'm
>   proposing already exist! In another form though, as [directory
>   variables]. That requires customizations to be defined as safe though.
>   And today some of the things I would consider to define a collection
>   aren't safe. For example `org-agenda-files', `org-todo-keywords',
>   `org-publish-project-alist'.
>
>   Some issues with relying on directory variables (Assuming they also
>   are made safe):
>   - When invoking Org agenda I will have to first visit a file inside a
>     specific folder to get the agenda for the correct project
>   - ....
>
>
> [directory variables] <info:emacs#Directory variables>
>
>
> 7 References
> ============
>
>   I've mentioned this idea the Org mode mailing list previously, but
>   only as short side notes to other topics:
>   - <https://lists.gnu.org/archive/html/emacs-orgmode/2018-11/msg00211.html>
>   - <https://lists.gnu.org/archive/html/emacs-orgmode/2019-09/msg00010.html>
>
>   Note that I've talked about it as "project". I think that name still
>   could be considered instead of "collection". Collection is more
>   general and less overloaded in terms of productivity software. And it
>   shifts the focus away from task management a bit, which I think can be
>   a good thing. Because while Org mode may often start to be used as a
>   task/project manager software, it's useful in a much wider context
>   than that!
>
>
>
> Footnotes
> _________
>
> [1] I've previously written about this as "Projects". While Project
> was my initial name for this feature I think collection may be a
> better option. For the sake of this text both options work just fine.
> The idea is the same.


--
Luke, use the FOSS

Sent from Emacs

Re: [Idea] Org Collections

[Tim Cross]

I would have to say the hardest thing I ever have to do as a developer
is naming things. It is hard enough to do within a context of a single
group, even harder when speaking about something with a global user base
(language, social/cultural differences etc). Despite this, it is so very
important as it defines expectations, which will in turn determine
satisfaction. 

As an example, 'aspects' for me is more like a different view into a
'thing' while collections are more like distinct, separate collections of
'things'. To some extent, aspects feels like a 'virtual collection'
where collection is more like a concrete separation. I can see pros
and cons with both.  

Roland Everaert <reveatwork@gmail.com> writes:

> +1 for this idea.
>
> You speak about one document used by multiple collections, how do you
> plan to manage that from a file system point of view?
>
> How will be organized a collection, still from the FS point of view?
>
> As some are delving into the abyss of sementic, I propose aspects
> instead of collections or contexts. Ultimately we are trying to manage
> various aspects of our life, by splitting those aspects into files or
> diretories and what not. So, if it is the intent of your idea, the term
> aspect seems more appropriate than collection or context IMHO.
>
> Did you think about the specific UI of aspects management?
> Proposal of UI I particularly like:
> - Mu4E
> - forge/magit
>
> How to keep track of all those aspects?
>
> I will surely have more to say, but, as of know I am at work.
>
> Regards,
>
> Roland.
>
> Gustav Wikström writes:
>
>> 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 location globally!
>>
>>   All above adds cognitive load to the user and makes it difficult to
>>   maintain the configuration as the use of Org mode grows (as it should
>>   ;) ). You have to define the context for each and every feature for it
>>   to know what to operate on. I claim that both the human psyche and the
>>   system itself will have a much more easy time if it could configure
>>   these features together, in a given context!
>>
>>
>> 3.2 For the developer
>> ~~~~~~~~~~~~~~~~~~~~~
>>
>>   I claim there will be benefits for developers as well. Today there
>>   exists many packages that extend Org mode functionality. Many work
>>   with the idea of collections. Some that come to mind:
>>   - Org brain (<https://github.com/Kungsgeten/org-brain>)
>>   - Org ql (<https://github.com/alphapapa/org-ql>)
>>   - Ox hugo (<https://ox-hugo.scripter.co/>)
>>
>>   I think that with the addition of the `collections' concept into Org
>>   mode, package developers get a concept they can easily attach to. Yes,
>>   you can easily define your own package-specific concept for that as
>>   well. But then the user loses out in having to configure another
>>   feature. And yes, today you as a developer can say that Org agenda
>>   will be my collection to operate on. But this is a big limitation
>>   since it limits what your package effectively can only work to a
>>   single list of files.
>>
>>   Having a collections concept means you as a developer have another
>>   base on which you can extend. No need to define your own concept if
>>   `Org-agenda-files' isn't enough; make it work together with
>>   `org-collections' instead. Org mode users will be happy because what
>>   they have already defined as important for them can be reused for new
>>   things with ease.
>>
>>   Developing features inside Org mode itself hopefully also can benefit
>>   from this concept. I'm sure there are many people out there with cool
>>   ideas on how to extend and work with Org documents. And I'm equally
>>   sure that the value of developing many of those features will be
>>   bigger if they could naturally attach to an Org collections
>>   definition!
>>
>>
>> 4 Example use cases
>> ===================
>>
>> 4.1 Separate actions from reference
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>   One practice promoted by GTD is to separate actionable items from
>>   reference information. While that practice can be overcome by search
>>   etc. some might still value a clear separation.
>>
>>   Want to look up something related to my general references? Search the
>>   Org collection related to reference-information! Maybe set up custom
>>   views and uses of TODO keywords for reference information for special
>>   agenda views.
>>
>>   Want to only display not yet finished tasks? Switch to the Org
>>   collection for actionable items and browse away.
>>
>>
>> 4.2 Work / Personal separation
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>   The heading says it all. Some like to separate work and personal stuff
>>   out from each other. What more clear way to do that than can there be
>>   than to separate them into their own Org collections? That way you
>>   potentially could let your work-related workflow (I.e. TODO-keywords)
>>   be different than the personal workflow. Without having to think about
>>   a global configuration that has to allow for both.
>>
>>
>> 4.3 Separated book library
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>   Org mode can be used as a media manager of sort. Just define your
>>   conventions for the Org collection using TODO-keywords, categories and
>>   properties. Attach the e-books you have as attachments in an
>>   attachment-scheme special for your book library. Configure export of
>>   the library using maybe a custom HTML/CSS-visual and publish it
>>   somewhere for yourself to look at when on your phone. And do this
>>   without having to think of how changing all these things will affect
>>   the global state of Org mode, potentially messing up your other uses
>>   for task management or other notes and libraries you're trying to
>>   manage!
>>
>>   Note that one can still have a holistic view on all Org mode documents
>>   as well, if important. It only requires a definition of a collection
>>   as the collection of all other collections!
>>
>>
>> 4.4 More?
>> ~~~~~~~~~
>>
>>   Please add more ideas when you think of them!
>>
>>
>> 5 Risks and challenges
>> ======================
>>
>> 5.1 Which configuration to use?
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>   When I'm visiting a file that belongs to a collection, how should
>>   Emacs resolve configurations for that file?
>>
>>   There may be configurations in the following places:
>>   - Global in `emacs-custom.el' or `.emacs.d/init.el'
>>   - Directory local variables in the tree
>>   - File local variables
>>   - Local variables for the project definition in which the file
>>     belongs?
>>
>>   Should visiting a file always have to scan the collections list to see
>>   if the file belongs to any of them, in order to load customizations?
>>   Hmm... Maybe!? Or - maybe not if Emacs can rely on the fact that the
>>   user cares to set the local variable `org-collections-active' (or
>>   whatever it should be called)? In that case, just evaluate the
>>   settings for that project without doing any scan.
>>
>>
>> 5.2 Should project config allow local variables?
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>   Should the collections definition allow customization of variables
>>   that apply for Org mode features? Hmm... Maybe!? One thing that comes
>>   to mind is that a project should be able to define a custom attachment
>>   directory... How else would the attachment-feature know what
>>   attachment directory to use for files in that collection?
>>
>>   Another option could ofc. be that each feature would have to add
>>   support for looking into the collection definition and override the
>>   local variable. But that will add development effort and complexity to
>>   each feature. Not suggested.
>>
>>
>> 5.2.1 How to initialize the local variables?
>> --------------------------------------------
>>
>>   When visiting a file that belongs to a collection, should Emacs at
>>   that point initialize the collection-configuration for that
>>   collection? Ideally some kind of collection-resolution would be made.
>>   Otherwise users will get strange behaviors when the think they are in
>>   one project but Org mode hasn't changed the local variables to match
>>   it. On the other hand, it doesn't sound very performant to have to
>>   check collection-belonging every time an Org mode file is visited!
>>
>>   Possibly solve this with a variable that can be localized -
>>   `org-collections-active'?
>>
>>
>> 5.3 Conflict with other customizations
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>   Maybe I've defined an attachment directory as a directory local
>>   variables in a folder, for all subfolders and files to inherit. Should
>>   collection-customizations override that? Or should the directory local
>>   variables take precedence?
>>
>>   Maybe could be solved by letting the (advanced) user choose using a
>>   customization itself, something like
>>   `org-collections-precede-local-variables' ? Need a intuitive default
>>   though. Most sane default is probably to let local variables take
>>   precedence. Those are created by the user anyways, so she should be
>>   aware.
>>
>>   The more I think of it, there shouldn't be a customization for this at
>>   all. I think local definitions always should override the collection
>>   definition.
>>
>>
>> 5.4 Files that belong to multiple collections
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>   What if I'm being a clever user and define multiple collections for
>>   the same files (I.e. overlap in the Venn-diagram of files grouped by
>>   collections). Which collection is "active" when I'm visiting the file?
>>
>>   This depends on if Emacs should evaluate the collection-settings for
>>   each file visit or not. If they are evaluated for each file visit then
>>   the first matching project in the list of collections should apply for
>>   that file. If a cache is created that lists file and collection
>>   relationships then each file should relate to a list of collections
>>   where the first collection in that list should apply.
>>
>>   If Emacs can rely on `org-collections-active' being set, then the
>>   collection referenced there should be used.
>>
>>
>> 5.5 Dynamic lists of files and folders for a collection?
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>   Should the list of files allow for folders with recursion and patterns
>>   should it be required to provide a fixed defined list of files?
>>
>>   Preferably the same way as `org-agenda-files' work today. Maybe some
>>   kind of caching-mechanism is needed though, for commands that might
>>   have to look for file, collection relations. A cache adds potential
>>   pain for the user though. If a file is added to a folder in a
>>   collection and a "collection-command" is run then the new file might
>>   not show up in the results anyway... So the user will be affected by
>>   caching and will have to know about it. Not good...
>>
>>
>> 6 Alternatives
>> ==============
>>
>>   Doing research for this feature made me realize that much of what I'm
>>   proposing already exist! In another form though, as [directory
>>   variables]. That requires customizations to be defined as safe though.
>>   And today some of the things I would consider to define a collection
>>   aren't safe. For example `org-agenda-files', `org-todo-keywords',
>>   `org-publish-project-alist'.
>>
>>   Some issues with relying on directory variables (Assuming they also
>>   are made safe):
>>   - When invoking Org agenda I will have to first visit a file inside a
>>     specific folder to get the agenda for the correct project
>>   - ....
>>
>>
>> [directory variables] <info:emacs#Directory variables>
>>
>>
>> 7 References
>> ============
>>
>>   I've mentioned this idea the Org mode mailing list previously, but
>>   only as short side notes to other topics:
>>   - <https://lists.gnu.org/archive/html/emacs-orgmode/2018-11/msg00211.html>
>>   - <https://lists.gnu.org/archive/html/emacs-orgmode/2019-09/msg00010.html>
>>
>>   Note that I've talked about it as "project". I think that name still
>>   could be considered instead of "collection". Collection is more
>>   general and less overloaded in terms of productivity software. And it
>>   shifts the focus away from task management a bit, which I think can be
>>   a good thing. Because while Org mode may often start to be used as a
>>   task/project manager software, it's useful in a much wider context
>>   than that!
>>
>>
>>
>> Footnotes
>> _________
>>
>> [1] I've previously written about this as "Projects". While Project
>> was my initial name for this feature I think collection may be a
>> better option. For the sake of this text both options work just fine.
>> The idea is the same.


-- 
Tim Cross

Re: [Idea] Org Collections

[Roland Everaert]

I do agree that "aspect" is a very abstract term and all depends on the
scope of this proposal, I suppose.

Reading the proposal again, it seems that my proposal could apply, as
the intent seems to define a per "aspect" configuration. On the other
end as aspects are quite abstract, an aspect can be part of another one
and aspects can have different "implementations" (collections,
documents, headlines and TODOs???, ...).

Tim Cross writes:

> I would have to say the hardest thing I ever have to do as a developer
> is naming things. It is hard enough to do within a context of a single
> group, even harder when speaking about something with a global user base
> (language, social/cultural differences etc). Despite this, it is so very
> important as it defines expectations, which will in turn determine
> satisfaction.
>
> As an example, 'aspects' for me is more like a different view into a
> 'thing' while collections are more like distinct, separate collections of
> 'things'. To some extent, aspects feels like a 'virtual collection'
> where collection is more like a concrete separation. I can see pros
> and cons with both.
>
> Roland Everaert <reveatwork@gmail.com> writes:
>
>> +1 for this idea.
>>
>> You speak about one document used by multiple collections, how do you
>> plan to manage that from a file system point of view?
>>
>> How will be organized a collection, still from the FS point of view?
>>
>> As some are delving into the abyss of sementic, I propose aspects
>> instead of collections or contexts. Ultimately we are trying to manage
>> various aspects of our life, by splitting those aspects into files or
>> diretories and what not. So, if it is the intent of your idea, the term
>> aspect seems more appropriate than collection or context IMHO.
>>
>> Did you think about the specific UI of aspects management?
>> Proposal of UI I particularly like:
>> - Mu4E
>> - forge/magit
>>
>> How to keep track of all those aspects?
>>
>> I will surely have more to say, but, as of know I am at work.
>>
>> Regards,
>>
>> Roland.
>>
>> Gustav Wikström writes:
>>
>>> 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 location globally!
>>>
>>>   All above adds cognitive load to the user and makes it difficult to
>>>   maintain the configuration as the use of Org mode grows (as it should
>>>   ;) ). You have to define the context for each and every feature for it
>>>   to know what to operate on. I claim that both the human psyche and the
>>>   system itself will have a much more easy time if it could configure
>>>   these features together, in a given context!
>>>
>>>
>>> 3.2 For the developer
>>> ~~~~~~~~~~~~~~~~~~~~~
>>>
>>>   I claim there will be benefits for developers as well. Today there
>>>   exists many packages that extend Org mode functionality. Many work
>>>   with the idea of collections. Some that come to mind:
>>>   - Org brain (<https://github.com/Kungsgeten/org-brain>)
>>>   - Org ql (<https://github.com/alphapapa/org-ql>)
>>>   - Ox hugo (<https://ox-hugo.scripter.co/>)
>>>
>>>   I think that with the addition of the `collections' concept into Org
>>>   mode, package developers get a concept they can easily attach to. Yes,
>>>   you can easily define your own package-specific concept for that as
>>>   well. But then the user loses out in having to configure another
>>>   feature. And yes, today you as a developer can say that Org agenda
>>>   will be my collection to operate on. But this is a big limitation
>>>   since it limits what your package effectively can only work to a
>>>   single list of files.
>>>
>>>   Having a collections concept means you as a developer have another
>>>   base on which you can extend. No need to define your own concept if
>>>   `Org-agenda-files' isn't enough; make it work together with
>>>   `org-collections' instead. Org mode users will be happy because what
>>>   they have already defined as important for them can be reused for new
>>>   things with ease.
>>>
>>>   Developing features inside Org mode itself hopefully also can benefit
>>>   from this concept. I'm sure there are many people out there with cool
>>>   ideas on how to extend and work with Org documents. And I'm equally
>>>   sure that the value of developing many of those features will be
>>>   bigger if they could naturally attach to an Org collections
>>>   definition!
>>>
>>>
>>> 4 Example use cases
>>> ===================
>>>
>>> 4.1 Separate actions from reference
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>   One practice promoted by GTD is to separate actionable items from
>>>   reference information. While that practice can be overcome by search
>>>   etc. some might still value a clear separation.
>>>
>>>   Want to look up something related to my general references? Search the
>>>   Org collection related to reference-information! Maybe set up custom
>>>   views and uses of TODO keywords for reference information for special
>>>   agenda views.
>>>
>>>   Want to only display not yet finished tasks? Switch to the Org
>>>   collection for actionable items and browse away.
>>>
>>>
>>> 4.2 Work / Personal separation
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>   The heading says it all. Some like to separate work and personal stuff
>>>   out from each other. What more clear way to do that than can there be
>>>   than to separate them into their own Org collections? That way you
>>>   potentially could let your work-related workflow (I.e. TODO-keywords)
>>>   be different than the personal workflow. Without having to think about
>>>   a global configuration that has to allow for both.
>>>
>>>
>>> 4.3 Separated book library
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>   Org mode can be used as a media manager of sort. Just define your
>>>   conventions for the Org collection using TODO-keywords, categories and
>>>   properties. Attach the e-books you have as attachments in an
>>>   attachment-scheme special for your book library. Configure export of
>>>   the library using maybe a custom HTML/CSS-visual and publish it
>>>   somewhere for yourself to look at when on your phone. And do this
>>>   without having to think of how changing all these things will affect
>>>   the global state of Org mode, potentially messing up your other uses
>>>   for task management or other notes and libraries you're trying to
>>>   manage!
>>>
>>>   Note that one can still have a holistic view on all Org mode documents
>>>   as well, if important. It only requires a definition of a collection
>>>   as the collection of all other collections!
>>>
>>>
>>> 4.4 More?
>>> ~~~~~~~~~
>>>
>>>   Please add more ideas when you think of them!
>>>
>>>
>>> 5 Risks and challenges
>>> ======================
>>>
>>> 5.1 Which configuration to use?
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>   When I'm visiting a file that belongs to a collection, how should
>>>   Emacs resolve configurations for that file?
>>>
>>>   There may be configurations in the following places:
>>>   - Global in `emacs-custom.el' or `.emacs.d/init.el'
>>>   - Directory local variables in the tree
>>>   - File local variables
>>>   - Local variables for the project definition in which the file
>>>     belongs?
>>>
>>>   Should visiting a file always have to scan the collections list to see
>>>   if the file belongs to any of them, in order to load customizations?
>>>   Hmm... Maybe!? Or - maybe not if Emacs can rely on the fact that the
>>>   user cares to set the local variable `org-collections-active' (or
>>>   whatever it should be called)? In that case, just evaluate the
>>>   settings for that project without doing any scan.
>>>
>>>
>>> 5.2 Should project config allow local variables?
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>   Should the collections definition allow customization of variables
>>>   that apply for Org mode features? Hmm... Maybe!? One thing that comes
>>>   to mind is that a project should be able to define a custom attachment
>>>   directory... How else would the attachment-feature know what
>>>   attachment directory to use for files in that collection?
>>>
>>>   Another option could ofc. be that each feature would have to add
>>>   support for looking into the collection definition and override the
>>>   local variable. But that will add development effort and complexity to
>>>   each feature. Not suggested.
>>>
>>>
>>> 5.2.1 How to initialize the local variables?
>>> --------------------------------------------
>>>
>>>   When visiting a file that belongs to a collection, should Emacs at
>>>   that point initialize the collection-configuration for that
>>>   collection? Ideally some kind of collection-resolution would be made.
>>>   Otherwise users will get strange behaviors when the think they are in
>>>   one project but Org mode hasn't changed the local variables to match
>>>   it. On the other hand, it doesn't sound very performant to have to
>>>   check collection-belonging every time an Org mode file is visited!
>>>
>>>   Possibly solve this with a variable that can be localized -
>>>   `org-collections-active'?
>>>
>>>
>>> 5.3 Conflict with other customizations
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>   Maybe I've defined an attachment directory as a directory local
>>>   variables in a folder, for all subfolders and files to inherit. Should
>>>   collection-customizations override that? Or should the directory local
>>>   variables take precedence?
>>>
>>>   Maybe could be solved by letting the (advanced) user choose using a
>>>   customization itself, something like
>>>   `org-collections-precede-local-variables' ? Need a intuitive default
>>>   though. Most sane default is probably to let local variables take
>>>   precedence. Those are created by the user anyways, so she should be
>>>   aware.
>>>
>>>   The more I think of it, there shouldn't be a customization for this at
>>>   all. I think local definitions always should override the collection
>>>   definition.
>>>
>>>
>>> 5.4 Files that belong to multiple collections
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>   What if I'm being a clever user and define multiple collections for
>>>   the same files (I.e. overlap in the Venn-diagram of files grouped by
>>>   collections). Which collection is "active" when I'm visiting the file?
>>>
>>>   This depends on if Emacs should evaluate the collection-settings for
>>>   each file visit or not. If they are evaluated for each file visit then
>>>   the first matching project in the list of collections should apply for
>>>   that file. If a cache is created that lists file and collection
>>>   relationships then each file should relate to a list of collections
>>>   where the first collection in that list should apply.
>>>
>>>   If Emacs can rely on `org-collections-active' being set, then the
>>>   collection referenced there should be used.
>>>
>>>
>>> 5.5 Dynamic lists of files and folders for a collection?
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>   Should the list of files allow for folders with recursion and patterns
>>>   should it be required to provide a fixed defined list of files?
>>>
>>>   Preferably the same way as `org-agenda-files' work today. Maybe some
>>>   kind of caching-mechanism is needed though, for commands that might
>>>   have to look for file, collection relations. A cache adds potential
>>>   pain for the user though. If a file is added to a folder in a
>>>   collection and a "collection-command" is run then the new file might
>>>   not show up in the results anyway... So the user will be affected by
>>>   caching and will have to know about it. Not good...
>>>
>>>
>>> 6 Alternatives
>>> ==============
>>>
>>>   Doing research for this feature made me realize that much of what I'm
>>>   proposing already exist! In another form though, as [directory
>>>   variables]. That requires customizations to be defined as safe though.
>>>   And today some of the things I would consider to define a collection
>>>   aren't safe. For example `org-agenda-files', `org-todo-keywords',
>>>   `org-publish-project-alist'.
>>>
>>>   Some issues with relying on directory variables (Assuming they also
>>>   are made safe):
>>>   - When invoking Org agenda I will have to first visit a file inside a
>>>     specific folder to get the agenda for the correct project
>>>   - ....
>>>
>>>
>>> [directory variables] <info:emacs#Directory variables>
>>>
>>>
>>> 7 References
>>> ============
>>>
>>>   I've mentioned this idea the Org mode mailing list previously, but
>>>   only as short side notes to other topics:
>>>   - <https://lists.gnu.org/archive/html/emacs-orgmode/2018-11/msg00211.html>
>>>   - <https://lists.gnu.org/archive/html/emacs-orgmode/2019-09/msg00010.html>
>>>
>>>   Note that I've talked about it as "project". I think that name still
>>>   could be considered instead of "collection". Collection is more
>>>   general and less overloaded in terms of productivity software. And it
>>>   shifts the focus away from task management a bit, which I think can be
>>>   a good thing. Because while Org mode may often start to be used as a
>>>   task/project manager software, it's useful in a much wider context
>>>   than that!
>>>
>>>
>>>
>>> Footnotes
>>> _________
>>>
>>> [1] I've previously written about this as "Projects". While Project
>>> was my initial name for this feature I think collection may be a
>>> better option. For the sake of this text both options work just fine.
>>> The idea is the same.


--
Luke, use the FOSS

Sent from Emacs

RE: [Idea] Org Collections

[Gustav Wikström]

Hi!

> -----Original Message-----
> From: Emacs-orgmode <emacs-orgmode-bounces+gustav=whil.se@gnu.org> On Behalf
> Of Roland Everaert
> Sent: den 16 december 2019 12:26
> To: emacs-orgmode@gnu.org
> Subject: Re: [Idea] Org Collections
> 
> +1 for this idea.
> 
> You speak about one document used by multiple collections, how do you
> plan to manage that from a file system point of view?

The idea was to let the user define the scope of each collection herself. Similar to how an agenda is defined today (Maybe in the same way even?). Most simple configuration would be to let a collection be one folder. But in the end it would be up to the imagination of and usefulness for the user. Having one document in multiple collections wouldn't be any issue because the collections are only pointing to locations of files in the filesystem. And if creating overlap between collections sounds dumb then it's a simple choice by the user to not do it!

> How will be organized a collection, still from the FS point of view?

Maybe the comments above answer that as well?

> As some are delving into the abyss of sementic, I propose aspects
> instead of collections or contexts. Ultimately we are trying to manage
> various aspects of our life, by splitting those aspects into files or
> diretories and what not. So, if it is the intent of your idea, the term
> aspect seems more appropriate than collection or context IMHO.

Many words could work. Context, Project, Group, Aspect, Areas, etc. I first thought of the name "project" to match the Projectile package. But I think collection is a better concept here. It lets the user think not of how it should be used but rather of what it consists. Which is a collection of files (and settings). That collection can ofc. be used for project, as aspects, or be seen as contexts or areas. So in my mind collection is the broader, more applicable term. It has less subjective meaning attached to how this functionality could be used. It IS a collection but can be USED as aspects, for projects, etc. What do you say? 😊

> 
> Did you think about the specific UI of aspects management?
> Proposal of UI I particularly like:
> - Mu4E
> - forge/magit

Not really.. Except I agree with you on magit. The other I haven't used.

> 
> How to keep track of all those aspects?

My first thought was to define them in a simple list.

> 
> I will surely have more to say, but, as of know I am at work.
> 
> Regards,
> 
> Roland.

Thanks for your comments!

Regards
Gustav

Re: [Idea] Org Collections

[William Denton]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 600 bytes --]

On 14 December 2019, Gustav Wikström wrote:

> 2 Idea
> ======
>
>  I propose to introduce `Collection' as a concept in the realm of Org
>  mode. [1]

This is very interesting, and I think I have some cases where I could use this. 
When there's something to test, I'll certainly try it.  It's a good idea, and 
I hope your work on it goes well.

Bill
--
William Denton :: Toronto, Canada   ---   Listening to Art: https://listeningtoart.org/
https://www.miskatonic.org/         ---   GHG.EARTH: https://ghg.earth/
Caveat lector.                      ---   STAPLR: https://staplr.org/

Re: [Idea] Org Collections

[Roland Everaert]

Gustav Wikström writes:

> Hi!
>
>> -----Original Message-----
>> From: Emacs-orgmode <emacs-orgmode-bounces+gustav=whil.se@gnu.org> On Behalf
>> Of Roland Everaert
>> Sent: den 16 december 2019 12:26
>> To: emacs-orgmode@gnu.org
>> Subject: Re: [Idea] Org Collections
>> 
>> +1 for this idea.
>> 
>> You speak about one document used by multiple collections, how do you
>> plan to manage that from a file system point of view?
>
> The idea was to let the user define the scope of each collection herself. Similar to how an agenda is defined today (Maybe in the same way even?). Most simple configuration would be to let a collection be one folder. But in the end it would be up to the imagination of and usefulness for the user. Having one document in multiple collections wouldn't be any issue because the collections are only pointing to locations of files in the filesystem. And if creating overlap between collections sounds dumb then it's a simple choice by the user to not do it!

Have you had a look at org-brain. I don't use is much, but there are
some overlapping functionnality to merge, maybe.

>
>> How will be organized a collection, still from the FS point of view?
>
> Maybe the comments above answer that as well?
>
>> As some are delving into the abyss of sementic, I propose aspects
>> instead of collections or contexts. Ultimately we are trying to manage
>> various aspects of our life, by splitting those aspects into files or
>> diretories and what not. So, if it is the intent of your idea, the term
>> aspect seems more appropriate than collection or context IMHO.
>
> Many words could work. Context, Project, Group, Aspect, Areas, etc. I first thought of the name "project" to match the Projectile package. But I think collection is a better concept here. It lets the user think not of how it should be used but rather of what it consists. Which is a collection of files (and settings). That collection can ofc. be used for project, as aspects, or be seen as contexts or areas. So in my mind collection is the broader, more applicable term. It has less subjective meaning attached to how this functionality could be used. It IS a collection but can be USED as aspects, for projects, etc. What do you say? 😊

I think I can live with it ;)

>
>> 
>> Did you think about the specific UI of aspects management?
>> Proposal of UI I particularly like:
>> - Mu4E
>> - forge/magit
>
> Not really.. Except I agree with you on magit. The other I haven't used.

Mu4E is a major mode for managing e-mails using the mu index. it
provides a main view with bookmarks and entries to perform searches and
composing message, among othe thing, but what I find more useful are the
header view, which displays a multi-columns list of e-mails with
associated meta-data and a message view allowing to view the content of
an e-mail. The header view allows for bulk actions while the message
view act, obiously, on the current message and permit replying and
transfering the current e-mail.

>
>> 
>> How to keep track of all those aspects?
>
> My first thought was to define them in a simple list.
>
>> 
>> I will surely have more to say, but, as of know I am at work.
>> 
>> Regards,
>> 
>> Roland.
>
> Thanks for your comments!
>
> Regards
> Gustav


-- 
Luke, use the FOSS

Sent from Emacs

RE: [Idea] Org Collections

[Gustav Wikström]

Hi,

> -----Original Message-----
> From: Roland Everaert <reveatwork@gmail.com>
> Sent: den 23 december 2019 14:32
> To: Gustav Wikström <gustav@whil.se>
> Cc: emacs-orgmode@gnu.org
> Subject: Re: [Idea] Org Collections

> Have you had a look at org-brain. I don't use is much, but there are some
> overlapping functionnality to merge, maybe.

Yeah, I'm a Org brain user. In my mind the collections and the active
collection would ideally be what the Org brain would operate on. 

> >> Did you think about the specific UI of aspects management?
> >> Proposal of UI I particularly like:
> >> - Mu4E
> >> - forge/magit
> >
> > Not really.. Except I agree with you on magit. The other I haven't used.
> 
> Mu4E is a major mode for managing e-mails using the mu index. it provides
> a main view with bookmarks and entries to perform searches and composing
> message, among othe thing, but what I find more useful are the header
> view, which displays a multi-columns list of e-mails with associated meta-
> data and a message view allowing to view the content of an e-mail. The
> header view allows for bulk actions while the message view act, obiously,
> on the current message and permit replying and transfering the current e-
> mail.

Ah ok, thanks for the description! I think a UI for collections still
is quite far away. This is a hobby project after all and it may take
quite some time before anything useful is created. But it's good with
some pointers to inspirational material!

Regards,
Gustav