RE: [Idea] Org Collections
Hi, > -Original Message- > From: Roland Everaert > Sent: den 23 december 2019 14:32 > To: Gustav Wikström > 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
Re: [Idea] Org Collections
Gustav Wikström writes: > Hi! > >> -Original Message- >> From: Emacs-orgmode 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
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
Hi! > -Original Message- > From: Emacs-orgmode 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
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 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, >>>
Re: [Idea] Org Collections
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 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
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? 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
Re: [Idea] Org Collections
+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
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 Sent: den 15 december 2019 13:14 To: Gustav Wikström 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, mailto:gus...@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 …
RE: [Idea] Org Collections
Hi Adam, > -Original Message- > From: Emacs-orgmode 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
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 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
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, 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
Re: [Idea] Org Collections
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
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 "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
Re: [Idea] Org Collections
Tim Cross 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
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 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
[Idea] Org Collections
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!
