From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Schulte" Subject: Re: Re: Limited #+INCLUDE ? Date: Tue, 27 Apr 2010 11:58:37 -0600 Message-ID: <87eii0zsj6.fsf@gmail.com> References: <874oj2v2a6.fsf@tandberg.com> <87k4ruy5pd.fsf@mundaneum.com> <87eii26lzg.fsf@stats.ox.ac.uk> <878w89l2pq.wl%ucecesf@ucl.ac.uk> <87wrvtyln2.fsf@gmail.com> <874oiwyfgj.fsf@stats.ox.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6p3c-0002Zd-40 for emacs-orgmode@gnu.org; Tue, 27 Apr 2010 13:58:52 -0400 Received: from [140.186.70.92] (port=56504 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6p3Z-0002Yd-Fj for emacs-orgmode@gnu.org; Tue, 27 Apr 2010 13:58:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6p3V-0000LW-UN for emacs-orgmode@gnu.org; Tue, 27 Apr 2010 13:58:49 -0400 Received: from mail-ww0-f41.google.com ([74.125.82.41]:50534) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O6p3V-0000Kp-NM for emacs-orgmode@gnu.org; Tue, 27 Apr 2010 13:58:45 -0400 Received: by wwi18 with SMTP id 18so152660wwi.0 for ; Tue, 27 Apr 2010 10:58:44 -0700 (PDT) In-Reply-To: <874oiwyfgj.fsf@stats.ox.ac.uk> (Dan Davison's message of "Tue, 27 Apr 2010 13:26:20 -0400") 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: Dan Davison Cc: =?utf-8?Q?S=C3=A9bastien?= Vauban , emacs-orgmode@gnu.org, Giles Chamberlin Dan Davison writes: > "Eric Schulte" writes: > >> Darlan Cavalcante Moreira writes: >> >>> This functionality would be really useful. Since it is more directly >>> applicable for programming, then maybe an easier approach to implement = it >>> would be just a link to a function in a file. For instance >>> >>> [[file_def:/path/to/file::definition_name][linkname]] >>> >>> Org could rely on the capability of the target major-mode to select the >>> region enclosing the function (c-mark-function for C/C++, >>> py-mark-def-or-class for python, mark-defun for lisp, etc.). This would >>> avoid the necessity of including commenting marks in the code and altho= ugh >>> it would be limited to a "function body at a time" it would be enough in >>> many situations. >>> >> >> Following in this "major mode specific behavior" direction, maybe it >> would be possible to make use of the tags functionality for linking to >> specific functions, chapters, etc... based on the mode of the target >> file. > > This sounds like an interesting idea; I have been meaning to use tags > more. However, I wouldn't want to exclude the possibility of using this > functionality in a non-programming context I agree that would be an unwelcome restriction, however maybe TAGS are not restricted to programming text ,----[from (emacs) Tags ] | A "tag" is a reference to a subunit in a program or in a document. In | program source code, tags reference syntactic elements of the program: | functions, subroutines, data types, macros, etc. In a document, tags | reference chapters, sections, appendices, etc. Each tag specifies the | name of the file where the corresponding subunit is defined, and the | position of the subunit's definition in that file. `---- also, they support general regexp tag specification through which they can be extended to arbitrary major modes. -- Eric > -- i.e. collaborative editing of arbitrary text documents -- which > would argue for approaches based on storing arbitrary text context > using Emacs bookmarks or custom text searches. Perhaps the new > functionality could involve a choice of more than one new Org link > type? > > Dan > > > >> >> (info "(emacs)Tags") ;; how great is it that gnus resolves these links=20 >> >> Tags would allow for robust links to points in changing files without >> the need to place text anchors into the files themselves. The immediate >> downside is that tags rely on a TAGS table to resolve links. This table >> can easily be ignored from version control (for collaboration). Then >> Org-mode could use the `find-tag' function to resolve it's links, maybe >> in combination with the function delimiting features Darlan mentioned >> above to references entire function/object ranges. >> >> -- Eric >> >>> >>> Darlan >>> >>> 2010/4/27 Eric S Fraga : >>>> On Mon, 26 Apr 2010 15:40:35 -0400, Dan Davison wrote: >>>>> I'm considering investigating the following and would appreciate >>>>> comments on this idea. The aim is to make it easier to use Org-mode to >>>>> work pure code files which are *external to Org-mode* (i.e. this >>>>> proposal lies outside of the current org-babel tangling framework). >>>>> >>>>> - Extend Org file links to allow links to a range of lines in a >>>>> =C2=A0 file. The syntax could be >>>>> =C2=A0 [[file:/path/to/file::from::to][linkname]] >>>> >>>> +1 >>>> >>>> I like this idea, especially for exporting complex documents. =C2=A0If >>>> org-store-link were enhanced to generate links with this line >>>> information, I would probably use this a lot. >>>> >>>>> - These links will bring up a buffer visiting the target file, narrow= ed >>>>> =C2=A0 to the target region. >>>> >>>> Or could be brought up with a wide view but with the region selected? >>>> >>>>> - 'from' and 'to' could be line numbers, or regexps for text search. >>>> >>>> The latter could be quite appealing, although possibly a little >>>> fragile. >>>> >>>> >>>> _______________________________________________ >>>> Emacs-orgmode mailing list >>>> Please use `Reply All' to send replies to the list. >>>> Emacs-orgmode@gnu.org >>>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode >>>> >> >> >> _______________________________________________ >> Emacs-orgmode mailing list >> Please use `Reply All' to send replies to the list. >> Emacs-orgmode@gnu.org >> http://lists.gnu.org/mailman/listinfo/emacs-orgmode