From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xavier Garrido Subject: Re: [patch, ox] #+INCLUDE resolves links Date: Thu, 02 Oct 2014 09:29:17 +0200 Message-ID: <542CFECD.5000609@gmail.com> References: <87k34x6bjd.fsf@gmx.us> <87lhpdurfh.fsf@gmx.us> <87bnq984hd.fsf@nicolasgoaziou.fr> <87bnq5zzp7.fsf@gmx.us> <87oau4ems5.fsf@nicolasgoaziou.fr> <87d2af1qyv.fsf@gmx.us> <87tx3po7kj.fsf@nicolasgoaziou.fr> <87mw9hcsy9.fsf@gmx.us> <87zjdh89ll.fsf@nicolasgoaziou.fr> <871tqskce9.fsf@gmx.us> <87y4sz7e1w.fsf@nicolasgoaziou.fr> <87lhoz7a5k.fsf@gmx.us> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:34524) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZapK-0001OK-0c for emacs-orgmode@gnu.org; Thu, 02 Oct 2014 03:29:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XZapF-000430-4N for emacs-orgmode@gnu.org; Thu, 02 Oct 2014 03:29:25 -0400 Received: from mail-wi0-x22c.google.com ([2a00:1450:400c:c05::22c]:40410) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZapE-00042u-UI for emacs-orgmode@gnu.org; Thu, 02 Oct 2014 03:29:21 -0400 Received: by mail-wi0-f172.google.com with SMTP id n3so2954789wiv.11 for ; Thu, 02 Oct 2014 00:29:19 -0700 (PDT) In-Reply-To: <87lhoz7a5k.fsf@gmx.us> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Rasmus , mail@nicolasgoaziou.fr Cc: emacs-orgmode@gnu.org Hi, Following the discussion here http://article.gmane.org/gmane.emacs.orgmode/91322/match=improved+way, I have quickly tested the patch and it perfectly fits my needs. So thanks again. Just one remark : there is an undefined @ref tag in org.texi (line 10011) file that should referred to "search option in file link". Compilation fails due to error in documentation generation. Cheers, Xavier Le 01/10/2014 23:27, Rasmus a écrit : > Hi, > > Nicolas Goaziou writes: > >> It isn't very important, but you forgot full stops at the end of >> comments in the test file. > > Fixed. > >>> 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. >>> >>> WDYT? >> >> I think option 1 is perfect. If a block with org contents is needed, one >> can always do >> >> #+begin_center >> #+include: "file.org::*headline" >> #+end_center >> >> Block and environments are really meant for literal insertion, where >> locations do not apply. > > Great! Less work. > > We can always tune it later as necessary. > >>> + (only-contents >>> + (and (string-match ":only-contents *?\\([^: \r\t\n]\\S-*\\)?" >>> value) >> >> Is the shy *? necessary? > > No! Only the * is necessary to catch an implicit nil. Thanks. > > Feel free to commit the attached patch if there's nothing else. > > —Rasmus >