From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Tim O'Callaghan" Subject: Re: Feature Request - Active and inactive links. Date: Tue, 11 Dec 2007 14:24:04 +0100 Message-ID: <3d6808890712110524x66985a20h3340e9cbacbdadda@mail.gmail.com> References: <3d6808890712030717s4aeccea3oe95960df850d4841@mail.gmail.com> <87bq8zcto6.fsf@bzg.ath.cx> <3d6808890712091651j17631cd6s7234351ac8f35532@mail.gmail.com> <87tzmptr34.fsf@bzg.ath.cx> <3d6808890712110523l5d369faaj5aaf1bcc87a1b55f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J255p-0005V2-KA for emacs-orgmode@gnu.org; Tue, 11 Dec 2007 08:24:13 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J255k-0005I9-Lq for emacs-orgmode@gnu.org; Tue, 11 Dec 2007 08:24:12 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J255k-0005Hn-HF for emacs-orgmode@gnu.org; Tue, 11 Dec 2007 08:24:08 -0500 Received: from nf-out-0910.google.com ([64.233.182.186]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J255k-00034u-4i for emacs-orgmode@gnu.org; Tue, 11 Dec 2007 08:24:08 -0500 Received: by nf-out-0910.google.com with SMTP id f5so1441336nfh for ; Tue, 11 Dec 2007 05:24:04 -0800 (PST) In-Reply-To: <3d6808890712110523l5d369faaj5aaf1bcc87a1b55f@mail.gmail.com> Content-Disposition: inline List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: org-mode mailing list On 11/12/2007, Bastien wrote: > Hi Tim, > > thanks for the details. I think I got confused because I couldn't > understand what you mean by a link being "processed" when compiling > the agenda. Now I understand that it means some kind of inclusion. > > So the issue seems twofold: > > 1. the first issue is about *including* external Org files (or other > external resources, although I'm not sure to understand what does > that mean); > Yes and no. by *including* external resources i was thinking remote org files, and things (local or remote) that can be converted into something usable by org Agenda (only an org file AFAIK). I use an Ical URL as an example because i use google calendar, but the Ical link could be local. Or it could be a nag, remind, an outlook export or whatever. > 2. the second issue is that of *processing* links to external resources > when using your Org file as a source for other purposes (agenda view, > export, etc.) > Yes. My idea was essentially, when i ask org to create an agenda buffer, it knows to auto-pull and process each all of these active links, so as to be able to display them in my Agenda. > I think both issues are very interesting but should be carefully (and > maybe separately) thought. > > You're speaking about a link that would include the targeted Org file > into the list of agenda files. Then attaching meta-data to this link, > you would control how the building of the agenda should process the link > (adding category, etc.) > > Some example of what we could do: > > - a link to an Org file that should be considered part of the master > file (at any time: agenda view, export, etc.) This could be a new > link type like "org:" > > org:~/home/org/header.org > What is a Master file in this context? > - a link to a file that should be included for specific export: > > #+BEGIN_LaTeX > org:~/home/org/latex_footer.org > #+END_LaTeX > > or maybe, if it's not ambiguous: > > org:latex:~/home/org/latex_footer.org > Not quite. Though i can see how some might have use for the export specific org file include. > - a link to a file that should only be processed in agenda views: > > org:agenda:~/home/org/other-todo.org > > - ... and maybe only for a specific agenda view > > org:agenda:n~/home/org/other-todo.org ("n" being the name of the > command key in org-agenda-custom-commands) > > Where you thinking of something like that? > Something similar to the last one. > I'm not sure on how to integrate your idea about specifying categories, > and I doubt this is particularly relevant: the links already belong to > entries that will be categorized. > Well the category is more like a category override. If you consider an imported org: link that is not created by you, then it may have a different flavor. The adding - or probably better - superseding of category/meta information gives you the knowledge needed to search for imported todos for example. > I'm not sure although about your example with iCal. Do you think it > could fit with the picture above? > After thinking about it, for external resources, it would be better to specify a new active link type per resource type "Ical:" for example. Also the meta data might be better if specified per link type to or in the processing code. > Thanks for this neat idea. I'm sure we're getting somewhere... > Not sure how neat it is, but i know I'll use it :) Tim.