From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: Feature Request - Active and inactive links. Date: Tue, 11 Dec 2007 15:59:23 +0100 Message-ID: <87zlwhcm5w.fsf@bzg.ath.cx> References: <3d6808890712030717s4aeccea3oe95960df850d4841@mail.gmail.com> <87bq8zcto6.fsf@bzg.ath.cx> <3d6808890712091651j17631cd6s7234351ac8f35532@mail.gmail.com> <87tzmptr34.fsf@bzg.ath.cx> <3d6808890712110523l5d369faaj5aaf1bcc87a1b55f@mail.gmail.com> <3d6808890712110524x66985a20h3340e9cbacbdadda@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J26aG-0002qX-Gd for emacs-orgmode@gnu.org; Tue, 11 Dec 2007 09:59:44 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J26aC-0002oC-8V for emacs-orgmode@gnu.org; Tue, 11 Dec 2007 09:59:43 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J26aB-0002np-S4 for emacs-orgmode@gnu.org; Tue, 11 Dec 2007 09:59:39 -0500 Received: from nf-out-0910.google.com ([64.233.182.190]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J26aA-0007J1-B7 for emacs-orgmode@gnu.org; Tue, 11 Dec 2007 09:59:39 -0500 Received: by nf-out-0910.google.com with SMTP id f5so1460236nfh for ; Tue, 11 Dec 2007 06:59:32 -0800 (PST) In-Reply-To: <3d6808890712110524x66985a20h3340e9cbacbdadda@mail.gmail.com> (Tim O'Callaghan's message of "Tue, 11 Dec 2007 14:24:04 +0100") 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: emacs-orgmode@gnu.org "Tim O'Callaghan" writes: >> 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. I think we should study this idea incrementally. The first step is to see how we can "import" an Org file (since every other file types would be converted into something that Org should be able to compile.) >> 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. (Maybe the word "link" is confusing at some point: a (web)link is usually something that you go to, not something that sneaks in. But let's say that we try to *import* stuff that are reachable trough a link to a local/remote resource.) >> - 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? The master file is the file that contains references to included files. For exemple: ,---- | #+TITLE: Master file | | org:included-file.org `---- ,---- | #+TITLE: Included file | | Some text. `---- Caveat: we should perhaps have only one level of inclusion, to avoid conflicts emerging from circular references... > 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 this is useful. If you import an external todo.org you just need to be able to refer to the categories it contains, as usual. You don't need its categories to supersede those of the master file. But maybe I don't understand you on this. > 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. I think importing external resources from different formats is a bit overkill. Importing Org files is enough. If the user wants to import iCal files into Org files (as you do), he can do this in a separate process. But this topic is huge. Let's let it rest a bit... -- Bastien