* Re: property searches for #+CATEGORY @ 2008-12-07 23:39 Mario E. Munich 0 siblings, 0 replies; 28+ messages in thread From: Mario E. Munich @ 2008-12-07 23:39 UTC (permalink / raw) To: emacs-orgmode Dear all, I am sorry to bother you with a silly question, but I have read all the postings on the orgmode list on how to separate files for work and personal using the CATEGORY stuff. I have implemented the method, but I cannot get org-agenda-custom-commands to search properly in each category. Any pointers/help would be highly appreciated (or other method in case that it would be more appropriated) Best regards, -Mario ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: property searches for #+CATEGORY @ 2008-12-07 23:35 Mario E. Munich 2008-12-08 16:40 ` Carsten Dominik 0 siblings, 1 reply; 28+ messages in thread From: Mario E. Munich @ 2008-12-07 23:35 UTC (permalink / raw) To: emacs-orgmode Dear all, I am sorry to bother you with a silly question, but I have read all the postings on the orgmode list on how to separate files for work and personal using the CATEGORY stuff. I have implemented the method, but I cannot get org-agenda-custom-commands to search properly in each category. Any pointers/help would be highly appreciated. Best regards, -Mario -- Mario E. Munich, PhD VP of Engineering Principal Scientist Evolution Robotics Ph: (626) 993-3317 Fax: (626) 993-3301 mario@evolution.com http://www.evolution.com ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: property searches for #+CATEGORY 2008-12-07 23:35 Mario E. Munich @ 2008-12-08 16:40 ` Carsten Dominik 2008-12-09 0:33 ` Mario E. Munich 0 siblings, 1 reply; 28+ messages in thread From: Carsten Dominik @ 2008-12-08 16:40 UTC (permalink / raw) To: mario; +Cc: emacs-orgmode Hi Mario, the fact that you "have read all the postings" almost contradicts your other statement that you "have implemented *the* method". I guess you need to tell us more about your detailed setup to get a useful reply. - Carsten On Dec 8, 2008, at 12:35 AM, Mario E. Munich wrote: > Dear all, > > I am sorry to bother you with a silly question, but I have read all > the > postings on the orgmode list on how to separate files for work and > personal using the CATEGORY stuff. I have implemented the method, > but I > cannot get org-agenda-custom-commands to search properly in each > category. Any pointers/help would be highly appreciated. > > Best regards, > > -Mario > > -- > Mario E. Munich, PhD > VP of Engineering > Principal Scientist > Evolution Robotics > Ph: (626) 993-3317 > Fax: (626) 993-3301 > mario@evolution.com > http://www.evolution.com > > > > _______________________________________________ > Emacs-orgmode mailing list > Remember: use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: property searches for #+CATEGORY 2008-12-08 16:40 ` Carsten Dominik @ 2008-12-09 0:33 ` Mario E. Munich 2008-12-09 1:41 ` Matthew Lundin 0 siblings, 1 reply; 28+ messages in thread From: Mario E. Munich @ 2008-12-09 0:33 UTC (permalink / raw) To: Carsten Dominik; +Cc: emacs-orgmode Dear Carsten, I am really sorry for not having been clear... let me explain myself a little bit and hopefully you would be able to point me in the right direction. First of all, I would like to mention that I am a planner-el convert given the flexibility that org-mode provides. I have converted all my planner files into org-mode files and I am moving forward using org-mode. My particular use-case scenario (that seemed to be the same scenario that Adam mentioned in this thread) is that I would like to have two set of org files stored in separated directories: one set for the office (work) and another set for home (personal). I am able to run agenda commands in both sets of files using org-agenda-files and I am able to see all the TODO items using the basic C-a a commands. However, I would like to search for TODO items that correspond only to my work or only to my home (basically, have two emacs buffers, one with work TODO lists and another with personal TODO lists to avoid cluttering). From this thread of emails of about a year ago, I thought that the solution to my use-case was to add a #+CATEGORY indicator on the files. I have added the following lines: #+CATEGORY: work my-work-project or #+CATEGORY: personal my-personal-project accordingly in the work and the personal files. So, I am now at the point in which I would like to customize the org-agenda-custom-commands to search for CATEGORY work or personal TODO items. I have looked in the mailing list and in the org-mode documentation and I have not been able to find a good example on how to do this (I should add that my lisp skills are not that great and therefore that might be the root cause of the problem). I have several questions: 1) Given my use-case, is this the right approach? Should I be using something else like FILETAGS? I think that this use-case might be rather common for people working in industry in which you would like to have a separation between work and personal files due to IP and ownership issues. Things might be even worse if you use SVN at work and GIT at home (my case). So, I would think that it would be useful to have a simple skeleton setup in the documentation. In planner, I used to have a way of switching between pointing at work or personal files, but this setup was less than ideal. 2) If using CATEGORY is the right thing to do, how should I write the search function? Thanks a lot for your help and support... And not that you need any more praise for org-mode, but, man, it is really, really good!!!! Thanks again, -Mario Carsten Dominik wrote: > Hi Mario, > > the fact that you "have read all the postings" almost contradicts > your other statement that you "have implemented *the* method". > I guess you need to tell us more about your detailed setup > to get a useful reply. > > - Carsten > > On Dec 8, 2008, at 12:35 AM, Mario E. Munich wrote: > >> Dear all, >> >> I am sorry to bother you with a silly question, but I have read all the >> postings on the orgmode list on how to separate files for work and >> personal using the CATEGORY stuff. I have implemented the method, but I >> cannot get org-agenda-custom-commands to search properly in each >> category. Any pointers/help would be highly appreciated. >> >> Best regards, >> >> -Mario >> >> -- >> Mario E. Munich, PhD >> VP of Engineering >> Principal Scientist >> Evolution Robotics >> Ph: (626) 993-3317 >> Fax: (626) 993-3301 >> mario@evolution.com >> http://www.evolution.com >> >> >> >> _______________________________________________ >> Emacs-orgmode mailing list >> Remember: use `Reply All' to send replies to the list. >> Emacs-orgmode@gnu.org >> http://lists.gnu.org/mailman/listinfo/emacs-orgmode > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: property searches for #+CATEGORY 2008-12-09 0:33 ` Mario E. Munich @ 2008-12-09 1:41 ` Matthew Lundin 2008-12-09 6:51 ` Mario E. Munich 0 siblings, 1 reply; 28+ messages in thread From: Matthew Lundin @ 2008-12-09 1:41 UTC (permalink / raw) To: Mario E. Munich; +Cc: emacs-orgmode Hi Mario, I find the easiest way to filter for personal and professional tasks is to use a filetag at the top of each file, e.g., #+FILETAGS: prof I use filetags because the agenda has a wonderful shortcut for filtering by tags. When I call the agenda, I simply hit "/" and then the shortcut for either my "prof" or "per" tag to filter the items. It's lightning quick and does the job painlessly (i.e., without any custom agenda searches). I have org-use-tag-inheritance set to t, but if you want fine-grained control of what tags are inherited, Org 6.14 has some nice new options. Of course, if you'd prefer to use categories instead of filetags, they also work just fine for custom agenda searches. For example, (setq org-agenda-custom-commands '(("w" tags-todo "CATEGORY=\"work\"") ("h" tags-todo "CATEGORY=\"home\""))) Finally, you can always search by category using C-c a m or C-c a M and then typing the following: CATEGORY="work" In short, there are lot of nice ways to achieve the functionality you're looking for. I hope this helps. Best, Matt "Mario E. Munich" <mariomu@ieee.org> writes: > Dear Carsten, > > I am really sorry for not having been clear... let me explain myself a > little bit and hopefully you would be able to point me in the right > direction. > > First of all, I would like to mention that I am a planner-el convert > given the flexibility that org-mode provides. I have converted all my > planner files into org-mode files and I am moving forward using org-mode. > > My particular use-case scenario (that seemed to be the same scenario > that Adam mentioned in this thread) is that I would like to have two set > of org files stored in separated directories: one set for the office > (work) and another set for home (personal). I am able to run agenda > commands in both sets of files using org-agenda-files and I am able to > see all the TODO items using the basic C-a a commands. However, I would > like to search for TODO items that correspond only to my work or only to > my home (basically, have two emacs buffers, one with work TODO lists and > another with personal TODO lists to avoid cluttering). > > From this thread of emails of about a year ago, I thought that the > solution to my use-case was to add a #+CATEGORY indicator on the files. > I have added the following lines: > > #+CATEGORY: work my-work-project > > or > > #+CATEGORY: personal my-personal-project > > accordingly in the work and the personal files. > So, I am now at the point in which I would like to customize the > org-agenda-custom-commands to search for CATEGORY work or personal TODO > items. I have looked in the mailing list and in the org-mode > documentation and I have not been able to find a good example on how to > do this (I should add that my lisp skills are not that great and > therefore that might be the root cause of the problem). > > I have several questions: > > 1) Given my use-case, is this the right approach? Should I be using > something else like FILETAGS? > > I think that this use-case might be rather common for people working in > industry in which you would like to have a separation between work and > personal files due to IP and ownership issues. Things might be even > worse if you use SVN at work and GIT at home (my case). So, I would > think that it would be useful to have a simple skeleton setup in the > documentation. In planner, I used to have a way of switching between > pointing at work or personal files, but this setup was less than ideal. > > 2) If using CATEGORY is the right thing to do, how should I write the > search function? > > Thanks a lot for your help and support... And not that you need any more > praise for org-mode, but, man, it is really, really good!!!! > > Thanks again, > > -Mario > > Carsten Dominik wrote: >> Hi Mario, >> >> the fact that you "have read all the postings" almost contradicts >> your other statement that you "have implemented *the* method". >> I guess you need to tell us more about your detailed setup >> to get a useful reply. >> >> - Carsten >> >> On Dec 8, 2008, at 12:35 AM, Mario E. Munich wrote: >> >>> Dear all, >>> >>> I am sorry to bother you with a silly question, but I have read all the >>> postings on the orgmode list on how to separate files for work and >>> personal using the CATEGORY stuff. I have implemented the method, but I >>> cannot get org-agenda-custom-commands to search properly in each >>> category. Any pointers/help would be highly appreciated. >>> >>> Best regards, >>> >>> -Mario >>> >>> -- >>> Mario E. Munich, PhD >>> VP of Engineering >>> Principal Scientist >>> Evolution Robotics >>> Ph: (626) 993-3317 >>> Fax: (626) 993-3301 >>> mario@evolution.com >>> http://www.evolution.com >>> >>> >>> >>> _______________________________________________ >>> Emacs-orgmode mailing list >>> Remember: use `Reply All' to send replies to the list. >>> Emacs-orgmode@gnu.org >>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode >> > > > _______________________________________________ > Emacs-orgmode mailing list > Remember: use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: property searches for #+CATEGORY 2008-12-09 1:41 ` Matthew Lundin @ 2008-12-09 6:51 ` Mario E. Munich 0 siblings, 0 replies; 28+ messages in thread From: Mario E. Munich @ 2008-12-09 6:51 UTC (permalink / raw) To: Matthew Lundin; +Cc: emacs-orgmode Dear Matt, thanks a lot for the tips... I have settled down on using FILETAGS and then using C-c a M to get the TODO lists for either personal or work. Thanks a lot for all the help! Best regards, -Mario Matthew Lundin wrote: > Hi Mario, > > I find the easiest way to filter for personal and professional tasks > is to use a filetag at the top of each file, e.g., > > #+FILETAGS: prof > > I use filetags because the agenda has a wonderful shortcut for > filtering by tags. When I call the agenda, I simply hit "/" and then > the shortcut for either my "prof" or "per" tag to filter the items. > It's lightning quick and does the job painlessly (i.e., without any > custom agenda searches). I have org-use-tag-inheritance set to t, but > if you want fine-grained control of what tags are inherited, Org 6.14 > has some nice new options. > > Of course, if you'd prefer to use categories instead of filetags, they > also work just fine for custom agenda searches. For example, > > (setq org-agenda-custom-commands > '(("w" tags-todo "CATEGORY=\"work\"") > ("h" tags-todo "CATEGORY=\"home\""))) > > Finally, you can always search by category using C-c a m or C-c a M > and then typing the following: > > CATEGORY="work" > > In short, there are lot of nice ways to achieve the functionality > you're looking for. > > I hope this helps. > > Best, > > Matt > > "Mario E. Munich" <mariomu@ieee.org> writes: > > >> Dear Carsten, >> >> I am really sorry for not having been clear... let me explain myself a >> little bit and hopefully you would be able to point me in the right >> direction. >> >> First of all, I would like to mention that I am a planner-el convert >> given the flexibility that org-mode provides. I have converted all my >> planner files into org-mode files and I am moving forward using org-mode. >> >> My particular use-case scenario (that seemed to be the same scenario >> that Adam mentioned in this thread) is that I would like to have two set >> of org files stored in separated directories: one set for the office >> (work) and another set for home (personal). I am able to run agenda >> commands in both sets of files using org-agenda-files and I am able to >> see all the TODO items using the basic C-a a commands. However, I would >> like to search for TODO items that correspond only to my work or only to >> my home (basically, have two emacs buffers, one with work TODO lists and >> another with personal TODO lists to avoid cluttering). >> >> From this thread of emails of about a year ago, I thought that the >> solution to my use-case was to add a #+CATEGORY indicator on the files. >> I have added the following lines: >> >> #+CATEGORY: work my-work-project >> >> or >> >> #+CATEGORY: personal my-personal-project >> >> accordingly in the work and the personal files. >> So, I am now at the point in which I would like to customize the >> org-agenda-custom-commands to search for CATEGORY work or personal TODO >> items. I have looked in the mailing list and in the org-mode >> documentation and I have not been able to find a good example on how to >> do this (I should add that my lisp skills are not that great and >> therefore that might be the root cause of the problem). >> >> I have several questions: >> >> 1) Given my use-case, is this the right approach? Should I be using >> something else like FILETAGS? >> >> I think that this use-case might be rather common for people working in >> industry in which you would like to have a separation between work and >> personal files due to IP and ownership issues. Things might be even >> worse if you use SVN at work and GIT at home (my case). So, I would >> think that it would be useful to have a simple skeleton setup in the >> documentation. In planner, I used to have a way of switching between >> pointing at work or personal files, but this setup was less than ideal. >> >> 2) If using CATEGORY is the right thing to do, how should I write the >> search function? >> >> Thanks a lot for your help and support... And not that you need any more >> praise for org-mode, but, man, it is really, really good!!!! >> >> Thanks again, >> >> -Mario >> >> Carsten Dominik wrote: >> >>> Hi Mario, >>> >>> the fact that you "have read all the postings" almost contradicts >>> your other statement that you "have implemented *the* method". >>> I guess you need to tell us more about your detailed setup >>> to get a useful reply. >>> >>> - Carsten >>> >>> On Dec 8, 2008, at 12:35 AM, Mario E. Munich wrote: >>> >>> >>>> Dear all, >>>> >>>> I am sorry to bother you with a silly question, but I have read all the >>>> postings on the orgmode list on how to separate files for work and >>>> personal using the CATEGORY stuff. I have implemented the method, but I >>>> cannot get org-agenda-custom-commands to search properly in each >>>> category. Any pointers/help would be highly appreciated. >>>> >>>> Best regards, >>>> >>>> -Mario >>>> >>>> -- >>>> Mario E. Munich, PhD >>>> VP of Engineering >>>> Principal Scientist >>>> Evolution Robotics >>>> Ph: (626) 993-3317 >>>> Fax: (626) 993-3301 >>>> mario@evolution.com >>>> http://www.evolution.com >>>> >>>> >>>> >>>> _______________________________________________ >>>> Emacs-orgmode mailing list >>>> Remember: use `Reply All' to send replies to the list. >>>> Emacs-orgmode@gnu.org >>>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode >>>> >> _______________________________________________ >> Emacs-orgmode mailing list >> Remember: use `Reply All' to send replies to the list. >> Emacs-orgmode@gnu.org >> http://lists.gnu.org/mailman/listinfo/emacs-orgmode >> ^ permalink raw reply [flat|nested] 28+ messages in thread
* property searches for #+CATEGORY
@ 2007-11-07 11:17 Adam Spiers
2007-11-07 12:49 ` Bastien
` (2 more replies)
0 siblings, 3 replies; 28+ messages in thread
From: Adam Spiers @ 2007-11-07 11:17 UTC (permalink / raw)
To: org-mode mailing list
I have several personal .org files, and several work-related ones too.
In each personal file, I have a line:
#+CATEGORY: personal
and in each work-related file, I have a line:
#+CATEGORY: work
I would like to be able to bind agenda custom commands to do tag
searches which are narrowed to one of these categories, e.g. "show me
all personal priority #A tasks". Such a search needs to span *all*
agenda files, therefore the standard per-buffer narrowing provided by
the '<' binding in the *Agenda Commands* buffer is insufficient.
Would it make sense to include CATEGORY as a special property? After
all, pretty much all other per-task meta-data ("TODO", "PRIORITY"
etc.) are already available via the property interface, and this way,
I could easily achieve what I need with tag searches such as
CATEGORY="personal"+PRIORITY="A"
Thanks!
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: property searches for #+CATEGORY 2007-11-07 11:17 Adam Spiers @ 2007-11-07 12:49 ` Bastien 2007-11-07 12:15 ` Adam Spiers 2007-11-07 13:23 ` Tim O'Callaghan 2007-11-07 14:15 ` Bastien 2 siblings, 1 reply; 28+ messages in thread From: Bastien @ 2007-11-07 12:49 UTC (permalink / raw) To: org-mode mailing list Adam Spiers <orgmode@adamspiers.org> writes: > Would it make sense to include CATEGORY as a special property? Certainly. And it is already there: ,----[ (info "(org)Categories") ] | If you would like to have a special CATEGORY for a single entry or a | (sub)tree, give the entry a `:CATEGORY:' property with the location as | the value (*note Properties and columns::). `---- :) -- Bastien ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: property searches for #+CATEGORY 2007-11-07 12:49 ` Bastien @ 2007-11-07 12:15 ` Adam Spiers 0 siblings, 0 replies; 28+ messages in thread From: Adam Spiers @ 2007-11-07 12:15 UTC (permalink / raw) To: emacs-orgmode On Wed, Nov 07, 2007 at 12:49:44PM +0000, Bastien wrote: > Adam Spiers <orgmode@adamspiers.org> writes: > > > Would it make sense to include CATEGORY as a special property? > > Certainly. And it is already there: > > ,----[ (info "(org)Categories") ] > | If you would like to have a special CATEGORY for a single entry or a > | (sub)tree, give the entry a `:CATEGORY:' property with the location as > | the value (*note Properties and columns::). > `---- I was aware of this, but I don't want to have to set this property in every entry or even at the top of every subtree. I want to be able to use #+CATEGORY, and have it achieve the same effect w.r.t. properties. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: property searches for #+CATEGORY 2007-11-07 11:17 Adam Spiers 2007-11-07 12:49 ` Bastien @ 2007-11-07 13:23 ` Tim O'Callaghan 2007-11-07 13:34 ` Adam Spiers 2007-11-07 14:15 ` Bastien 2 siblings, 1 reply; 28+ messages in thread From: Tim O'Callaghan @ 2007-11-07 13:23 UTC (permalink / raw) To: Adam Spiers, org-mode mailing list On 07/11/2007, Adam Spiers <orgmode@adamspiers.org> wrote: > I have several personal .org files, and several work-related ones too. > In each personal file, I have a line: > > #+CATEGORY: personal > > and in each work-related file, I have a line: > > #+CATEGORY: work > > I would like to be able to bind agenda custom commands to do tag > searches which are narrowed to one of these categories, e.g. "show me > all personal priority #A tasks". Such a search needs to span *all* > agenda files, therefore the standard per-buffer narrowing provided by > the '<' binding in the *Agenda Commands* buffer is insufficient. > > Would it make sense to include CATEGORY as a special property? After > all, pretty much all other per-task meta-data ("TODO", "PRIORITY" > etc.) are already available via the property interface, and this way, > I could easily achieve what I need with tag searches such as > > CATEGORY="personal"+PRIORITY="A" > > Thanks! > It would seem to me that this is exactly what tags does. You could move everything down a level and use tag inheritance: * personal stuff :personal: * work stuff :work: Tim. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: property searches for #+CATEGORY 2007-11-07 13:23 ` Tim O'Callaghan @ 2007-11-07 13:34 ` Adam Spiers 2007-11-07 13:59 ` Tim O'Callaghan 2007-11-07 14:49 ` Bastien 0 siblings, 2 replies; 28+ messages in thread From: Adam Spiers @ 2007-11-07 13:34 UTC (permalink / raw) To: org-mode mailing list On Wed, Nov 07, 2007 at 02:23:12PM +0100, Tim O'Callaghan wrote: > On 07/11/2007, Adam Spiers <orgmode@adamspiers.org> wrote: > > I have several personal .org files, and several work-related ones too. > > In each personal file, I have a line: > > > > #+CATEGORY: personal > > > > and in each work-related file, I have a line: > > > > #+CATEGORY: work > > > > I would like to be able to bind agenda custom commands to do tag > > searches which are narrowed to one of these categories, e.g. "show me > > all personal priority #A tasks". Such a search needs to span *all* > > agenda files, therefore the standard per-buffer narrowing provided by > > the '<' binding in the *Agenda Commands* buffer is insufficient. > > > > Would it make sense to include CATEGORY as a special property? After > > all, pretty much all other per-task meta-data ("TODO", "PRIORITY" > > etc.) are already available via the property interface, and this way, > > I could easily achieve what I need with tag searches such as > > > > CATEGORY="personal"+PRIORITY="A" > > > > Thanks! > > It would seem to me that this is exactly what tags does. > You could move everything down a level and use tag inheritance: > * personal stuff :personal: > * work stuff :work: I could, but this would mean that each file would have a single top-level entry, and the entire contents would be indented an extra level, which I fear is a rather unattractive solution! ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: property searches for #+CATEGORY 2007-11-07 13:34 ` Adam Spiers @ 2007-11-07 13:59 ` Tim O'Callaghan 2007-11-07 14:28 ` Adam Spiers 2007-11-07 16:15 ` Carsten Dominik 2007-11-07 14:49 ` Bastien 1 sibling, 2 replies; 28+ messages in thread From: Tim O'Callaghan @ 2007-11-07 13:59 UTC (permalink / raw) To: Adam Spiers, org-mode mailing list On 07/11/2007, Adam Spiers <orgmode@adamspiers.org> wrote: > On Wed, Nov 07, 2007 at 02:23:12PM +0100, Tim O'Callaghan wrote: > > On 07/11/2007, Adam Spiers <orgmode@adamspiers.org> wrote: > > > I have several personal .org files, and several work-related ones too. > > > In each personal file, I have a line: > > > > > > #+CATEGORY: personal > > > > > > and in each work-related file, I have a line: > > > > > > #+CATEGORY: work > > > > > > I would like to be able to bind agenda custom commands to do tag > > > searches which are narrowed to one of these categories, e.g. "show me > > > all personal priority #A tasks". Such a search needs to span *all* > > > agenda files, therefore the standard per-buffer narrowing provided by > > > the '<' binding in the *Agenda Commands* buffer is insufficient. > > > > > > Would it make sense to include CATEGORY as a special property? After > > > all, pretty much all other per-task meta-data ("TODO", "PRIORITY" > > > etc.) are already available via the property interface, and this way, > > > I could easily achieve what I need with tag searches such as > > > > > > CATEGORY="personal"+PRIORITY="A" > > > > > > Thanks! > > > > It would seem to me that this is exactly what tags does. > > You could move everything down a level and use tag inheritance: > > * personal stuff :personal: > > * work stuff :work: > > I could, but this would mean that each file would have a single > top-level entry, and the entire contents would be indented an extra > level, which I fear is a rather unattractive solution! > It's the technique i've been using, and yes, it is unattractive. When i thought of tags, it was not explicitly for GTD context specifier, it was also for adding searchable metadata to a todo node. I'm finding out that it gets diluted somewhat. It guess its a matter of taxonomy. Roughly i would see this as: 1. State - TODO - DO/CANCEL/DONE 2. Context - tags - :@home:@phone: 3. Date/Time - <2007-10-10> 4. Meta Context - Category - personal, work etc, 5. Meta State - Properties drawer - :EMAIL:emacs-orgmode@gnu.org 6. Meta DateTime - state/time logging - How about adding the context to the tag table with a prefix character, say #? Tim. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: property searches for #+CATEGORY 2007-11-07 13:59 ` Tim O'Callaghan @ 2007-11-07 14:28 ` Adam Spiers 2007-11-07 14:52 ` Tim O'Callaghan 2007-11-07 16:15 ` Carsten Dominik 1 sibling, 1 reply; 28+ messages in thread From: Adam Spiers @ 2007-11-07 14:28 UTC (permalink / raw) To: org-mode mailing list On Wed, Nov 07, 2007 at 02:59:35PM +0100, Tim O'Callaghan wrote: > On 07/11/2007, Adam Spiers <orgmode@adamspiers.org> wrote: > > On Wed, Nov 07, 2007 at 02:23:12PM +0100, Tim O'Callaghan wrote: > > > It would seem to me that this is exactly what tags does. > > > You could move everything down a level and use tag inheritance: > > > * personal stuff :personal: > > > * work stuff :work: > > > > I could, but this would mean that each file would have a single > > top-level entry, and the entire contents would be indented an extra > > level, which I fear is a rather unattractive solution! > > It's the technique i've been using, and yes, it is unattractive. > > When i thought of tags, it was not explicitly for GTD context > specifier, it was also for adding searchable metadata to a todo node. Same here. I used tags for a lot more than GTD contexts, e.g. also for a rough ETC and to group them by areas of responsibility. (N.B. Sometimes a task can be motivated by multiple areas of responsibility, so subheadings aren't good enough.) > How about adding the context to the tag table with a prefix character, say #? I don't follow you, sorry. Perhaps I should state explicitly that my need to distinguish between 'work' and 'personal' categories has nothing to do with my use of GTD contexts. I can (and do very often) work from home, and I also occasionally(!) do personal tasks from the office. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: property searches for #+CATEGORY 2007-11-07 14:28 ` Adam Spiers @ 2007-11-07 14:52 ` Tim O'Callaghan 2007-11-07 16:35 ` Adam Spiers 0 siblings, 1 reply; 28+ messages in thread From: Tim O'Callaghan @ 2007-11-07 14:52 UTC (permalink / raw) To: Adam Spiers, org-mode mailing list On 07/11/2007, Adam Spiers <orgmode@adamspiers.org> wrote: > On Wed, Nov 07, 2007 at 02:59:35PM +0100, Tim O'Callaghan wrote: > > On 07/11/2007, Adam Spiers <orgmode@adamspiers.org> wrote: > > > On Wed, Nov 07, 2007 at 02:23:12PM +0100, Tim O'Callaghan wrote: > > > > It would seem to me that this is exactly what tags does. > > > > You could move everything down a level and use tag inheritance: > > > > * personal stuff :personal: > > > > * work stuff :work: > > > > > > I could, but this would mean that each file would have a single > > > top-level entry, and the entire contents would be indented an extra > > > level, which I fear is a rather unattractive solution! > > > > It's the technique i've been using, and yes, it is unattractive. > > > > When i thought of tags, it was not explicitly for GTD context > > specifier, it was also for adding searchable metadata to a todo node. > > Same here. I used tags for a lot more than GTD contexts, e.g. also > for a rough ETC and to group them by areas of responsibility. > (N.B. Sometimes a task can be motivated by multiple areas of > responsibility, so subheadings aren't good enough.) > > > How about adding the context to the tag table with a prefix character, say #? > > I don't follow you, sorry. Perhaps I should state explicitly that my > need to distinguish between 'work' and 'personal' categories has > nothing to do with my use of GTD contexts. I can (and do very often) > work from home, and I also occasionally(!) do personal tasks from the > office. > My point with the taxonomy is that Categories especially 'personal' and 'work' can be thought of as Meta Contexts (i wanted to say Meta-TAGS, but that might get confusing). So contexts that are arbitrary but are used to group many actual physical contexts (TAGS) of todo nodes. The '#' was the thought that if you treat Categories as a type of tag, then you could add them to the tag search mechanism. To avoid collision, such as work - the physical context and work, the category, prefix them with a meta-character such as # which cannot normally be in a tag name. So a categorised tag-todo search might be: "#work+work+email/TODO" Tim. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: property searches for #+CATEGORY 2007-11-07 14:52 ` Tim O'Callaghan @ 2007-11-07 16:35 ` Adam Spiers 0 siblings, 0 replies; 28+ messages in thread From: Adam Spiers @ 2007-11-07 16:35 UTC (permalink / raw) To: org-mode mailing list On Wed, Nov 07, 2007 at 03:52:55PM +0100, Tim O'Callaghan wrote: > My point with the taxonomy is that Categories especially 'personal' > and 'work' can be thought of as Meta Contexts (i wanted to say > Meta-TAGS, but that might get confusing). So contexts that are > arbitrary but are used to group many actual physical contexts (TAGS) > of todo nodes. I see. > The '#' was the thought that if you treat Categories as a type of tag, > then you could add them to the tag search mechanism. To avoid > collision, such as work - the physical context and work, the category, > prefix them with a meta-character such as # which cannot normally be > in a tag name. > > So a categorised tag-todo search might be: > "#work+work+email/TODO" Sure, that would be good enough for me if it were implemented - I'm not fussy whether what I need was provided via new syntax such as the above, or existing syntax such as CATEGORY="work"+email/TODO ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: property searches for #+CATEGORY 2007-11-07 13:59 ` Tim O'Callaghan 2007-11-07 14:28 ` Adam Spiers @ 2007-11-07 16:15 ` Carsten Dominik 2007-11-07 18:07 ` Adam Spiers 2007-11-08 4:55 ` Bastien 1 sibling, 2 replies; 28+ messages in thread From: Carsten Dominik @ 2007-11-07 16:15 UTC (permalink / raw) To: Tim O'Callaghan; +Cc: org-mode mailing list Thanks for an interesting discussion about the merits of properties versus tags etc. Very illuminating. However, I do think that Adam's initial request to make the category available as a special property for queries in not unreasonble. Or does anyone disagree? I am not sure, though, if the #+CATEGORY category should be available with `org-entry-get', because it would then be very hard for the property API to make a difference between a value that is intimately associated with the current entry, and a value that might be derived by some other mechanism. So here I differ somewhat from Adam's feeling that category is just like TODO or a tag. It is different. But for the search interface, to allow CATEGORY="work", I think that would be a safe thing to do. Will be in 5.14, unless I hear good arguments against this. - Carsten On 7Nov2007, at 2:59 PM, Tim O'Callaghan wrote: > On 07/11/2007, Adam Spiers <orgmode@adamspiers.org> wrote: >> On Wed, Nov 07, 2007 at 02:23:12PM +0100, Tim O'Callaghan wrote: >>> On 07/11/2007, Adam Spiers <orgmode@adamspiers.org> wrote: >>>> I have several personal .org files, and several work-related >>>> ones too. >>>> In each personal file, I have a line: >>>> >>>> #+CATEGORY: personal >>>> >>>> and in each work-related file, I have a line: >>>> >>>> #+CATEGORY: work >>>> >>>> I would like to be able to bind agenda custom commands to do tag >>>> searches which are narrowed to one of these categories, e.g. >>>> "show me >>>> all personal priority #A tasks". Such a search needs to span *all* >>>> agenda files, therefore the standard per-buffer narrowing >>>> provided by >>>> the '<' binding in the *Agenda Commands* buffer is insufficient. >>>> >>>> Would it make sense to include CATEGORY as a special property? >>>> After >>>> all, pretty much all other per-task meta-data ("TODO", "PRIORITY" >>>> etc.) are already available via the property interface, and this >>>> way, >>>> I could easily achieve what I need with tag searches such as >>>> >>>> CATEGORY="personal"+PRIORITY="A" >>>> >>>> Thanks! >>> >>> It would seem to me that this is exactly what tags does. >>> You could move everything down a level and use tag inheritance: >>> * personal stuff :personal: >>> * work stuff :work: >> >> I could, but this would mean that each file would have a single >> top-level entry, and the entire contents would be indented an extra >> level, which I fear is a rather unattractive solution! >> > > It's the technique i've been using, and yes, it is unattractive. > > When i thought of tags, it was not explicitly for GTD context > specifier, it was also for adding searchable metadata to a todo node. > I'm finding out that it gets diluted somewhat. > > It guess its a matter of taxonomy. Roughly i would see this as: > > 1. State - TODO - DO/CANCEL/DONE > 2. Context - tags - :@home:@phone: > 3. Date/Time - <2007-10-10> > 4. Meta Context - Category - personal, work etc, > 5. Meta State - Properties drawer - :EMAIL:emacs-orgmode@gnu.org > 6. Meta DateTime - state/time logging - > > How about adding the context to the tag table with a prefix > character, say #? > > Tim. > > > _______________________________________________ > Emacs-orgmode mailing list > Remember: use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: property searches for #+CATEGORY 2007-11-07 16:15 ` Carsten Dominik @ 2007-11-07 18:07 ` Adam Spiers 2007-11-08 4:55 ` Bastien 1 sibling, 0 replies; 28+ messages in thread From: Adam Spiers @ 2007-11-07 18:07 UTC (permalink / raw) To: org-mode mailing list On Wed, Nov 07, 2007 at 05:15:55PM +0100, Carsten Dominik wrote: > Thanks for an interesting discussion about the merits of properties > versus tags etc. Very illuminating. > > However, I do think that Adam's initial request to make the > category available as a special property for queries in not > unreasonble. Or does anyone disagree? > > I am not sure, though, if the #+CATEGORY category should be > available with `org-entry-get', because it would then be very > hard for the property API to make a difference between a value > that is intimately associated with the current entry, and a > value that might be derived by some other mechanism. Understood. > So here I differ somewhat from Adam's feeling that category is just > like TODO or a tag. It is different. Actually I agree with that :-) I just meant to point out some of the similarities in what they enable you to do. > But for the search interface, to allow CATEGORY="work", I think > that would be a safe thing to do. Will be in 5.14, unless I hear > good arguments against this. Fantastic! Thanks a lot. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: property searches for #+CATEGORY 2007-11-07 16:15 ` Carsten Dominik 2007-11-07 18:07 ` Adam Spiers @ 2007-11-08 4:55 ` Bastien 2007-11-08 8:54 ` Carsten Dominik 1 sibling, 1 reply; 28+ messages in thread From: Bastien @ 2007-11-08 4:55 UTC (permalink / raw) To: emacs-orgmode Carsten Dominik <carsten.dominik@gmail.com> writes: > However, I do think that Adam's initial request to make the > category available as a special property for queries in not > unreasonble. Or does anyone disagree? I'm convinced it's not unreasonable :) > I am not sure, though, if the #+CATEGORY category should be > available with `org-entry-get', because it would then be very > hard for the property API to make a difference between a value > that is intimately associated with the current entry, and a > value that might be derived by some other mechanism. So here I > differ somewhat from Adam's feeling that category is just like > TODO or a tag. It is different. Then a search like CATEGORY="cat" would also return entries which CATEGORY property is not "cat"... ok, maybe this doesn't hurt that much for search purposes. But I expect someone will come in three month complaining that `org-entry-get' didn't return the category, even though he set it up through #+CATEGORY. Anyway, not *that* important, as Adam said earlier... let's try. -- Bastien ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: property searches for #+CATEGORY 2007-11-08 4:55 ` Bastien @ 2007-11-08 8:54 ` Carsten Dominik 0 siblings, 0 replies; 28+ messages in thread From: Carsten Dominik @ 2007-11-08 8:54 UTC (permalink / raw) To: Bastien; +Cc: emacs-orgmode On 8Nov2007, at 5:55 AM, Bastien wrote: > Carsten Dominik <carsten.dominik@gmail.com> writes: > >> However, I do think that Adam's initial request to make the >> category available as a special property for queries in not >> unreasonble. Or does anyone disagree? > > I'm convinced it's not unreasonable :) > >> I am not sure, though, if the #+CATEGORY category should be >> available with `org-entry-get', because it would then be very >> hard for the property API to make a difference between a value >> that is intimately associated with the current entry, and a >> value that might be derived by some other mechanism. So here I >> differ somewhat from Adam's feeling that category is just like >> TODO or a tag. It is different. > > Then a search like CATEGORY="cat" would also return entries which > CATEGORY property is not "cat"... ok, maybe this doesn't hurt that > much for search purposes. But I expect someone will come in three > month complaining that `org-entry-get' didn't return the category, > even though he set it up through #+CATEGORY. OK, here is what we will do. We will make `org-entry-get' return a value from #+CATEGORY if the INHERIT flag is set in the call to `org-entry-get'. In this case the value is inherited not from a higher level entry, but for the "file environment", and even top-level outline entries can ihnerit it. We actually already have this mechanism: #+PROPERTY: Name Value So we could then see #+CATEGORY: work as a short-hand for #+PROPERTY: CATEGORY work ... which makes all of this suddenly look as if it was designed like this from the beginning. I like it. Thanks again to everyone who contributed to this discussion. - Carsten ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: property searches for #+CATEGORY 2007-11-07 13:34 ` Adam Spiers 2007-11-07 13:59 ` Tim O'Callaghan @ 2007-11-07 14:49 ` Bastien 2007-11-07 14:32 ` Adam Spiers 1 sibling, 1 reply; 28+ messages in thread From: Bastien @ 2007-11-07 14:49 UTC (permalink / raw) To: org-mode mailing list Adam Spiers <orgmode@adamspiers.org> writes: >> It would seem to me that this is exactly what tags does. >> You could move everything down a level and use tag inheritance: >> * personal stuff :personal: >> * work stuff :work: > > I could, but this would mean that each file would have a single > top-level entry, and the entire contents would be indented an extra > level, which I fear is a rather unattractive solution! ..which is exactly why your request about using a per-file #+CATEGORY when searching across files is more about *grouping files* than about grouping tasks. Am I wrong? -- Bastien ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: property searches for #+CATEGORY 2007-11-07 14:49 ` Bastien @ 2007-11-07 14:32 ` Adam Spiers 0 siblings, 0 replies; 28+ messages in thread From: Adam Spiers @ 2007-11-07 14:32 UTC (permalink / raw) To: emacs-orgmode On Wed, Nov 07, 2007 at 02:49:28PM +0000, Bastien wrote: > Adam Spiers <orgmode@adamspiers.org> writes: > > >> It would seem to me that this is exactly what tags does. > >> You could move everything down a level and use tag inheritance: > >> * personal stuff :personal: > >> * work stuff :work: > > > > I could, but this would mean that each file would have a single > > top-level entry, and the entire contents would be indented an extra > > level, which I fear is a rather unattractive solution! > > ..which is exactly why your request about using a per-file #+CATEGORY > when searching across files is more about *grouping files* than about > grouping tasks. Am I wrong? You're right. It's a 2-tier grouping mechanism really, e.g. (1) group work-related tasks into ~/work/TODO.org and appointments into ~/work/diary.org, then (2) group all work-related files together so that tag/keyword searches etc. can be performed on them all in one go. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: property searches for #+CATEGORY 2007-11-07 11:17 Adam Spiers 2007-11-07 12:49 ` Bastien 2007-11-07 13:23 ` Tim O'Callaghan @ 2007-11-07 14:15 ` Bastien 2007-11-07 13:52 ` Adam Spiers 2007-11-07 16:20 ` Carsten Dominik 2 siblings, 2 replies; 28+ messages in thread From: Bastien @ 2007-11-07 14:15 UTC (permalink / raw) To: org-mode mailing list Adam Spiers <orgmode@adamspiers.org> writes: > I have several personal .org files, and several work-related ones too. > In each personal file, I have a line: > > #+CATEGORY: personal > > and in each work-related file, I have a line: > > #+CATEGORY: work > > I would like to be able to bind agenda custom commands to do tag > searches which are narrowed to one of these categories, e.g. "show me > all personal priority #A tasks". Such a search needs to span *all* > agenda files, therefore the standard per-buffer narrowing provided by > the '<' binding in the *Agenda Commands* buffer is insufficient. > > Would it make sense to include CATEGORY as a special property? After > all, pretty much all other per-task meta-data ("TODO", "PRIORITY" > etc.) are already available via the property interface, and this way, > I could easily achieve what I need with tag searches such as > > CATEGORY="personal"+PRIORITY="A" I understand now. I think it would be clearer to distinguish between categorizing files and categorizing tasks. In a sense, using #+CATEGORY across several files (as you do) is more a way to group these files under the same ombrella (conveniently called "category"), rather than to group all tasks below each #+CATEGORY in the same category. Let me say it with other words: if several files share the same #+CATEGORY, then this bit of information won't be of any help to distinguish between these files' tasks, it will only help separating files with #+CATEGORY: A from files with #+CATEGORY: B. Then I think the right solution would be to have groups of agenda files. Something like: #+AGENDA_GROUP: personal This would let you restrict any agenda search to a group of agenda files. I don't want to digg too far in this direction, but I think there are a few other things for which such groups might be useful (e.g. publish agenda files per group...) My other concern is that the functionality you're requesting would resurrect #+CATEGORY, while this functionality was mostly maintained for backward compatibility -- at least I understood it like that. It's not that easy for users to understand how to user categories, and staying with two ways of setting them might be confusing IMO. PS: Personally, the problem you encounter is exactly the one that led me to use a single (really) big Org file. But this is entirely personal, of course! -- Bastien ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: property searches for #+CATEGORY 2007-11-07 14:15 ` Bastien @ 2007-11-07 13:52 ` Adam Spiers 2007-11-07 17:16 ` Bastien 2007-11-07 16:20 ` Carsten Dominik 1 sibling, 1 reply; 28+ messages in thread From: Adam Spiers @ 2007-11-07 13:52 UTC (permalink / raw) To: emacs-orgmode On Wed, Nov 07, 2007 at 02:15:22PM +0000, Bastien wrote: > I understand now. > > I think it would be clearer to distinguish between categorizing files > and categorizing tasks. In a sense, using #+CATEGORY across several > files (as you do) is more a way to group these files under the same > ombrella (conveniently called "category"), rather than to group all > tasks below each #+CATEGORY in the same category. > > Let me say it with other words: if several files share the same > #+CATEGORY, then this bit of information won't be of any help to > distinguish between these files' tasks, it will only help separating > files with #+CATEGORY: A from files with #+CATEGORY: B. That's exactly right. > Then I think the right solution would be to have groups of agenda files. > Something like: > > #+AGENDA_GROUP: personal > > This would let you restrict any agenda search to a group of agenda > files. I don't want to digg too far in this direction, but I think > there are a few other things for which such groups might be useful > (e.g. publish agenda files per group...) Well, the documentation says The category is a broad label assigned to each agenda item. By default, the category is simply derived from the file name, [...] so I thought this use case was pretty much exactly what it was intended for. > My other concern is that the functionality you're requesting would > resurrect #+CATEGORY, while this functionality was mostly maintained > for backward compatibility -- at least I understood it like that. No, I don't think it's #+CATEGORY per se which is only there for backward compatibility - it's using it multiple times within a single file. The docs say: (1) If there are several such lines in a file, each specifies the category for the text below it. The first category also applies to any text before the first CATEGORY line. This method is only kept for backward compatibility. The preferred method for setting multiple categories in a buffer is using a property. > It's not that easy for users to understand how to user categories, > and staying with two ways of setting them might be confusing IMO. Surely this is an argument against introducing yet another grouping mechanism! We already have tags, properties, and categories. > PS: Personally, the problem you encounter is exactly the one that > led me to use a single (really) big Org file. But this is entirely > personal, of course! I already have too many problems keeping a good work/life balance! ;-) But also I replicate my TODO files between machines, some owned by me and some by my company, and like to keep replication of company data separate from personal. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: property searches for #+CATEGORY 2007-11-07 13:52 ` Adam Spiers @ 2007-11-07 17:16 ` Bastien 2007-11-07 17:23 ` Adam Spiers 0 siblings, 1 reply; 28+ messages in thread From: Bastien @ 2007-11-07 17:16 UTC (permalink / raw) To: emacs-orgmode Adam Spiers <orgmode@adamspiers.org> writes: >> This would let you restrict any agenda search to a group of agenda >> files. I don't want to digg too far in this direction, but I think >> there are a few other things for which such groups might be useful >> (e.g. publish agenda files per group...) > > Well, the documentation says > > The category is a broad label assigned to each agenda item. By > default, the category is simply derived from the file name, [...] > > so I thought this use case was pretty much exactly what it was > intended for. Lets say that #+CATEGORY is more oriented toward files grouping, and :CATEGORY: is more oriented toward tasks grouping. In fact, when using several #+CATEGORY in the same file (as it is *not* recommended to do), you are virtually splitting your file into several files, each of them corresponding to a category. Your request was to be able to perform a search using #+CATEGORY as a way to search through multiple files. I can see to ways of doing this: 1. implicitely add the #+CATEGORY value of a file to each entry in this file, and search through files having the same #+CATEGORY; 2. clearly separate the group of files from the group of tasks, and perform a group-restricted search. I think (1) is problematic: what if a file has a top #+CATEGORY and several :CATEGORY: properties? What about precedence and inheritance? How to build the search string if we want to search through several :CATEGORY: properties in a single #+CATEGORY ? > No, I don't think it's #+CATEGORY per se which is only there for > backward compatibility - it's using it multiple times within a single > file. The fact that only *one* instance of #+CATEGORY is allowed in a file calls itself for the divorce between #+CATEGORY (possibly renamed as #+GROUP) and the :CATEGORY: property... >> It's not that easy for users to understand how to user categories, >> and staying with two ways of setting them might be confusing IMO. > > Surely this is an argument against introducing yet another grouping > mechanism! We already have tags, properties, and categories. But a category is just a property, even if the search interface raises this property above others. And besides these search considerations, I really believe that having several groups of agenda-files would help. > I already have too many problems keeping a good work/life balance! ;-) Com'on, our daily brain-sport is to feed this list! :) -- Bastien ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: property searches for #+CATEGORY 2007-11-07 17:16 ` Bastien @ 2007-11-07 17:23 ` Adam Spiers 2007-11-08 4:42 ` Bastien 0 siblings, 1 reply; 28+ messages in thread From: Adam Spiers @ 2007-11-07 17:23 UTC (permalink / raw) To: emacs-orgmode On Wed, Nov 07, 2007 at 05:16:26PM +0000, Bastien wrote: > Adam Spiers <orgmode@adamspiers.org> writes: > >> This would let you restrict any agenda search to a group of agenda > >> files. I don't want to digg too far in this direction, but I think > >> there are a few other things for which such groups might be useful > >> (e.g. publish agenda files per group...) > > > > Well, the documentation says > > > > The category is a broad label assigned to each agenda item. By > > default, the category is simply derived from the file name, [...] > > > > so I thought this use case was pretty much exactly what it was > > intended for. > > Lets say that #+CATEGORY is more oriented toward files grouping, and > :CATEGORY: is more oriented toward tasks grouping. I wouldn't quite say it like that. #+CATEGORY is still about task/appointment grouping - but categorising all entries in one file in a convenient, single pass. However if you only had two files, and one file had one #+CATEGORY line and the other had a different one, you wouldn't say you were grouping files together, would you? > In fact, when using > several #+CATEGORY in the same file (as it is *not* recommended to do), > you are virtually splitting your file into several files, each of them > corresponding to a category. Yes - or you could describe it the other way around - enabling you to combine multiple categories in the same file. > Your request was to be able to perform a search using #+CATEGORY as a > way to search through multiple files. Again, at risk of being pedantic I would describe my requirement slightly differently. (N.B. I can already search through multiple files.) Let's first bear in mind the relational data model behind this: - There is a many:one relationship between items (TODOs, appointments etc.) and categories, regardless of whether the category comes from #+CATEGORY or a :CATEGORY: property. - There is a many:one relationship between items and files. - Consequently, there is a many:many relationship between files and categories. In other words, categories are a means of grouping items, not files. (Ditto for tags and any other properties, in fact.) So, there are two orthogonal aspects to my requirement: - I want to be able to perform a search for a particular category across all *items* in all of my agenda files. N.B. this search is essentially item-oriented (think "SELECT * FROM item WHERE category=..."), *not* file-oriented (in an SQL world, the many:many relationship between files and categories would make for a more complex query). - I want to be able to conveniently place whole files in a single category (this is already satisfied by #+CATEGORY), and also maybe be able to add further files at a later date which have multiple categories per file (this is already satisfied by :CATEGORY: properties). > I can see to ways of doing this: > > 1. implicitely add the #+CATEGORY value of a file to each entry in this > file, That's what already happens, no? Each entry in my *Org Agenda* buffer is clearly labelled with the category which came from a #+CATEGORY line or :CATEGORY: property. > 2. clearly separate the group of files from the group of tasks, and > perform a group-restricted search. No, as I said above, this isn't about grouping files. > I think (1) is problematic: what if a file has a top #+CATEGORY and > several :CATEGORY: properties? Then the :CATEGORY: value takes precedence - this is already handled correctly in the existing code which builds the *Org Agenda* buffer. > What about precedence and inheritance? This is too - the most deeply-nested :CATEGORY: value takes precedence. In fact, the only thing missing is that the code for doing a property-based tag search doesn't honour #+CATEGORY, only CATEGORY properties. > How to build the search string if we want to search through several > :CATEGORY: properties in a single #+CATEGORY ? I don't think I understand the question. > > No, I don't think it's #+CATEGORY per se which is only there for > > backward compatibility - it's using it multiple times within a single > > file. > > The fact that only *one* instance of #+CATEGORY is allowed in a file > calls itself for the divorce between #+CATEGORY (possibly renamed as > #+GROUP) and the :CATEGORY: property... What do you mean by a divorce, and why do you think this? #+CATEGORY and :CATEGORY: happily coexist at the moment. > >> It's not that easy for users to understand how to user categories, > >> and staying with two ways of setting them might be confusing IMO. > > > > Surely this is an argument against introducing yet another grouping > > mechanism! We already have tags, properties, and categories. > > But a category is just a property, even if the search interface raises > this property above others. I disagree on two fronts :-) (Although this is not hugely important.) Firstly categories present the user with another interface to learn about. I am certainly not complaining, but you cannot discount the extra complexity they introduce, and therefore we should be careful about introducing yet more complexity. Secondly, categories are more than just properties due to #+CATEGORY - and in fact it is precisely this oddity, or exception to the Principle of Least Surprise, which I am trying to address in this thread. > And besides these search considerations, I really believe that > having several groups of agenda-files would help. Quite possibly, though probably not for me :-) Can you suggest a use case or two? > > I already have too many problems keeping a good work/life balance! ;-) > > Com'on, our daily brain-sport is to feed this list! :) Argh, way too much time spent on this list today ;-) ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: property searches for #+CATEGORY 2007-11-07 17:23 ` Adam Spiers @ 2007-11-08 4:42 ` Bastien 0 siblings, 0 replies; 28+ messages in thread From: Bastien @ 2007-11-08 4:42 UTC (permalink / raw) To: emacs-orgmode Hi Adam, Adam Spiers <orgmode@adamspiers.org> writes: > Again, at risk of being pedantic I would describe my requirement > slightly differently. (N.B. I can already search through multiple > files.) Thanks for the very clear & interesting explanations. > In fact, the only thing missing is that the code for doing a > property-based tag search doesn't honour #+CATEGORY, only CATEGORY > properties. Right. Now I understand it would be consistent to include #+CATEGORY in the category *search*. I was mainly choking on what Carsten mentionned in his reply about whether org-entry-get should return the category as defined by #+CATEGORY -- I guess this is the only consistency-hole. But since where are speaking about search interface, this is not a problem, that's right. > Firstly categories present the user with another interface to learn > about. I am certainly not complaining, but you cannot discount the > extra complexity they introduce, and therefore we should be careful > about introducing yet more complexity. I didn't want to add complexity, but rather expressivity. My line of reasoning was this one: 1. it is not recommended to use #+CATEGORY twice in a file 2. then the main use of #+CATEGORY will be for grouping *files* 3. if we use #+CATEGORY for grouping files (or tasks across files) and :CATEGORY: for grouping tasks, let's separate these two mechanismes more clearly 4. this would spare us the cost of deciding what value `org-entry-get' should return when asked for the category, in case a file uses both #+CATEGORY and :CATEGORY:... But again, this line depends on how fussy we are about (4) and search considerations ask for flexibility -- not fussiness :) >> And besides these search considerations, I really believe that >> having several groups of agenda-files would help. > > Quite possibly, though probably not for me :-) Can you suggest a use > case or two? It's mainly for publishing: for now I have to put each project in each directory so that `org-publish-project-alist' DTRT. I'd rather publish groups of files, thus being able to quickly decide what file is in what group. > Argh, way too much time spent on this list today ;-) :) -- Bastien ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: property searches for #+CATEGORY 2007-11-07 14:15 ` Bastien 2007-11-07 13:52 ` Adam Spiers @ 2007-11-07 16:20 ` Carsten Dominik 2007-11-08 0:04 ` Adam Spiers 1 sibling, 1 reply; 28+ messages in thread From: Carsten Dominik @ 2007-11-07 16:20 UTC (permalink / raw) To: Bastien; +Cc: org-mode mailing list On 7Nov2007, at 3:15 PM, Bastien wrote: > > I understand now. > > I think it would be clearer to distinguish between categorizing files > and categorizing tasks. In a sense, using #+CATEGORY across several > files (as you do) is more a way to group these files under the same > ombrella (conveniently called "category"), rather than to group all > tasks below each #+CATEGORY in the same category. > > Let me say it with other words: if several files share the same > #+CATEGORY, then this bit of information won't be of any help to > distinguish between these files' tasks, it will only help separating > files with #+CATEGORY: A from files with #+CATEGORY: B. > > Then I think the right solution would be to have groups of agenda > files. > Something like: > > #+AGENDA_GROUP: personal The idea to have groups of agenda files has come up before. It is hard to implement because agenda creating commands are *global* commands, so the group should not be a property of the location from where you call the agenda. You can, of course, already make custom commands that are restricted to a specific group of files, by setting `org-agenda-files' as one of the options for a custom command in org-agenda-custom-comands.... - Carsten ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: property searches for #+CATEGORY 2007-11-07 16:20 ` Carsten Dominik @ 2007-11-08 0:04 ` Adam Spiers 0 siblings, 0 replies; 28+ messages in thread From: Adam Spiers @ 2007-11-08 0:04 UTC (permalink / raw) To: emacs-orgmode On Wed, Nov 07, 2007 at 05:20:32PM +0100, Carsten Dominik wrote: > The idea to have groups of agenda files has come up before. > It is hard to implement because agenda creating commands > are *global* commands, so the group should not be a property > of the location from where you call the agenda. > > You can, of course, already make custom commands that are > restricted to a specific group of files, by setting > `org-agenda-files' as one of the options for a custom command > in org-agenda-custom-comands.... Ah! Now that's a nice trick - I hadn't realised you could override variables like that. And given that option values are lisp expressions, one could easily define a group of agenda files via (defvar my-org-personal-agenda-files) and then use that variable in one or more custom agenda commands. Wouldn't that be good enough for most people who want a file-grouping mechanism? (I should make it clear that I still believe it's worth making the tweak we agreed on to support CATEGORY="..." searches which catch #+CATEGORY values.) ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2008-12-09 6:51 UTC | newest] Thread overview: 28+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-12-07 23:39 property searches for #+CATEGORY Mario E. Munich -- strict thread matches above, loose matches on Subject: below -- 2008-12-07 23:35 Mario E. Munich 2008-12-08 16:40 ` Carsten Dominik 2008-12-09 0:33 ` Mario E. Munich 2008-12-09 1:41 ` Matthew Lundin 2008-12-09 6:51 ` Mario E. Munich 2007-11-07 11:17 Adam Spiers 2007-11-07 12:49 ` Bastien 2007-11-07 12:15 ` Adam Spiers 2007-11-07 13:23 ` Tim O'Callaghan 2007-11-07 13:34 ` Adam Spiers 2007-11-07 13:59 ` Tim O'Callaghan 2007-11-07 14:28 ` Adam Spiers 2007-11-07 14:52 ` Tim O'Callaghan 2007-11-07 16:35 ` Adam Spiers 2007-11-07 16:15 ` Carsten Dominik 2007-11-07 18:07 ` Adam Spiers 2007-11-08 4:55 ` Bastien 2007-11-08 8:54 ` Carsten Dominik 2007-11-07 14:49 ` Bastien 2007-11-07 14:32 ` Adam Spiers 2007-11-07 14:15 ` Bastien 2007-11-07 13:52 ` Adam Spiers 2007-11-07 17:16 ` Bastien 2007-11-07 17:23 ` Adam Spiers 2007-11-08 4:42 ` Bastien 2007-11-07 16:20 ` Carsten Dominik 2007-11-08 0:04 ` Adam Spiers
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).