emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [patch] Question on resolving links?


From: Rasmus
Subject: Re: [O] [patch] Question on resolving links?
Date: Sun, 21 Sep 2014 00:04:21 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

Hi Nicolas,

Nicolas Goaziou <address@hidden> writes:

> Rasmus <address@hidden> writes:
>
>> I would like to use #+INCLUDE keywords for inputting headlines from
>> other files.  Line-numbers are too volatile and I'm not willing to
>> split up my file.
>
> I think these specifications need to be refined.

If you are saying that INCLUDE needs to be updated I agree.

I was thinking of using normal links with some sort of ATTR, but since
there's not a global ATTR, it's not obvious how to do it.


Perhaps INCLUDE with support for normal links would be enough?

I which direction do you think I should put my effort?  [Of course I
want it to be part of ox]

> Should it only include
> the headline and its section, or the whole tree starting at the headline?

I think it should include the target headline.  That way I can to "*
preliminary model" (which is good for overview) in my notes.org and
use something more interesting in final.org.

Another reason for this is that then in "notes.org" I would also have
a headline with all of the advantages that entails (moving. not losing
it etc.).

When your "stapling together" together files, you'll include more than
just a heading. . .  Are there cases where it makes sense to include
the heading, *when only importing one heading*?

>> The attached patch does not, but I am not very happy about the
>> elegance of the implementation and it relies on a mix of org.el
>> functions and ox functions.  Basically, the patch tries to interpret
>> keywords like this:
>>
>> #+INCLUDE: "~/file.org::*foo"
>>
>> Is there not a function to interpret a link-string, say
>> "~/file.org::*foo", particularly with ox? 
>
> You cannot do this with ox, as include keywords are expanded before the
> export process actually begins.

OK.  Good to know, and somewhat what I expected.

>> The closes thing I found was `org-element-parse-secondary-string` on
>> [[~/file.org::*foo]] which gives me the correct element. Normally,
>> `org-export-resolve-fuzzy-link' should then help me out, but in
>> `org-export-expand-include-keyword' I don't have info! Also,
>> `org-link-search' didn't seem to work across files.
>
> I think `org-open-link-from-string' is what you want:
>
>   (org-open-link-from-string "[[~/file.org::*foo]]")

Right!  I did not know that one, but it's definitely what I was
looking for.  Cool!

—Rasmus

-- 
Enough with the bla bla!



reply via email to

[Prev in Thread] Current Thread [Next in Thread]