[Top][All Lists]

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

Re: [O] [patch, ox] #+INCLUDE resolves links

From: Nicolas Goaziou
Subject: Re: [O] [patch, ox] #+INCLUDE resolves links
Date: Wed, 01 Oct 2014 22:03:39 +0200


Rasmus <address@hidden> writes:

> Changes are one sentence in the documentations, casing, and I changed
> the regexp so that :only-contents is valid (it's nil).

Thank you.

It isn't very important, but you forgot full stops at the end of
comments in the test file.

> Is it better now?

I think so.

> I want to discuss one more important potential issue before having the
> patch applied.  Currently, location is ignored if the included part is
> not an env (line 3381) and not a block (3392).  I'm not sure this is
> right.  I could do one of the following:
>    1. Nothing (current state)
>    2. Throw an error if location and env or block are combined.
>    3. Try to use location even if block is set.  Recall, though, that
>       location is resolved using org-mode. 
>    4. Let location be a general regexp if env or block is non-nil.
>       But then we are breaking with the org file-link idea.
>    5. Make location work for org files when env or block, otherwise
>       throw an error.

I think option 1 is perfect. If a block with org contents is needed, one
can always do

  #+include: "file.org::*headline"

Block and environments are really meant for literal insertion, where
locations do not apply.

> Less important.  Should the <I "speedkey" (I don't know if that's the
> right term) prompt for a location, or change the cursor position to
> after the filename?

The "right term" is structure template. Since those are configurable,
I think the default, simple, behaviour is preferable.

> +              (only-contents
> +               (and (string-match ":only-contents *?\\([^: \r\t\n]\\S-*\\)?" 
> value)

Is the shy *? necessary?


Nicolas Goaziou

reply via email to

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