Re: [Orgmode] Feature Request - Active and inactive links.

[Bastien]

"Tim O'Callaghan" <address@hidden> 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