Limited #+INCLUDE ?

Limited #+INCLUDE ?

[Giles Chamberlin]

I've been using org-mode for some course work: "write an essay about
your software including the interesting bits, add all source code in an
appendix".

#+INCLUDE solves the inclusion of source code files very nicely - I'm 
guaranteed that my document includes the latest versions, type set as I
wish.

Unfortunately at the moment I'm cutting and pasting the snippets of
"interesting" code into the body of the essay.  What I'd like to do is
be able to label interesting regions of code in the source file and then
import the labelled blocks into my essay. Is there a way of doing this?

-- 
Giles

Re: Limited #+INCLUDE ?

[Sébastien Vauban]

Hi Giles,

Giles Chamberlin wrote:
> I've been using org-mode for some course work: "write an essay about
> your software including the interesting bits, add all source code in an
> appendix".
>
> #+INCLUDE solves the inclusion of source code files very nicely - I'm 
> guaranteed that my document includes the latest versions, type set as I
> wish.
>
> Unfortunately at the moment I'm cutting and pasting the snippets of
> "interesting" code into the body of the essay.  What I'd like to do is
> be able to label interesting regions of code in the source file and then
> import the labelled blocks into my essay. Is there a way of doing this?

Have a look at Org-Babel.

Though, it means your source code would be *inside* your Org document, and you
would have to "tangle" it (generate it) from there.

Seb

-- 
Sébastien Vauban



_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Re: Limited #+INCLUDE ?

[Dan Davison]

Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:

> Hi Giles,
>
> Giles Chamberlin wrote:
>> I've been using org-mode for some course work: "write an essay about
>> your software including the interesting bits, add all source code in an
>> appendix".
>>
>> #+INCLUDE solves the inclusion of source code files very nicely - I'm 
>> guaranteed that my document includes the latest versions, type set as I
>> wish.
>>
>> Unfortunately at the moment I'm cutting and pasting the snippets of
>> "interesting" code into the body of the essay.  What I'd like to do is
>> be able to label interesting regions of code in the source file and then
>> import the labelled blocks into my essay. Is there a way of doing this?
>
> Have a look at Org-Babel.
>
> Though, it means your source code would be *inside* your Org document, and you
> would have to "tangle" it (generate it) from there.
>
> Seb

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
  file. The syntax could be
  [[file:/path/to/file::from::to][linkname]]

- These links will bring up a buffer visiting the target file, narrowed
  to the target region.

- The link back in the Org-mode file can be adjusted from the target
  file, by widening and then narrowing again. (During this procedure the
  target region would be highlighted.)

- Export to HTML and LaTeX will have the ability to include the target
  regions, fontified according to the appropriate major-mode, similar to
  how begin_src blocks behave on export.

- 'from' and 'to' could be line numbers, or regexps for text search.

For programmers, this would allow a sort of org-mode mediated literate
programming in projects where it is not feasible/desirable to actually
include the source code in the org-mode file.

Any comments or suggestions?

Dan

Re: Re: Limited #+INCLUDE ?

[Mark Elston]

On 4/26/2010 12:40 PM, 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
>    file. The syntax could be
>    [[file:/path/to/file::from::to][linkname]]
>
> - These links will bring up a buffer visiting the target file, narrowed
>    to the target region.
>
> - The link back in the Org-mode file can be adjusted from the target
>    file, by widening and then narrowing again. (During this procedure the
>    target region would be highlighted.)
>
> - Export to HTML and LaTeX will have the ability to include the target
>    regions, fontified according to the appropriate major-mode, similar to
>    how begin_src blocks behave on export.
>
> - 'from' and 'to' could be line numbers, or regexps for text search.
>
> For programmers, this would allow a sort of org-mode mediated literate
> programming in projects where it is not feasible/desirable to actually
> include the source code in the org-mode file.
>
> Any comments or suggestions?
>
> Dan

Dan,

The use of line numbers seems a little error prone since line numbers
can change dramatically by simply editing the file.  If you edit one
section of a file, even if you update the line numbers for that
section, you will need to search out all the *other* links to sections
in that file and update them as well as they will become stale.  And,
since it will be possible to have multiple org files with links into a
single source file, this will be a *very* difficult thing to manage.

Your idea about regexps sounds promising, though.  You could define
'markers' in comments delimiting the relevant sections of code and
org could search these out easily enough.

Mark

Re: Re: Limited #+INCLUDE ?

[Dan Davison]

Mark Elston <m_elston@comcast.net> writes:

> On 4/26/2010 12:40 PM, 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
>>    file. The syntax could be
>>    [[file:/path/to/file::from::to][linkname]]
>>
>> - These links will bring up a buffer visiting the target file, narrowed
>>    to the target region.
>>
>> - The link back in the Org-mode file can be adjusted from the target
>>    file, by widening and then narrowing again. (During this procedure the
>>    target region would be highlighted.)
>>
>> - Export to HTML and LaTeX will have the ability to include the target
>>    regions, fontified according to the appropriate major-mode, similar to
>>    how begin_src blocks behave on export.
>>
>> - 'from' and 'to' could be line numbers, or regexps for text search.
>>
>> For programmers, this would allow a sort of org-mode mediated literate
>> programming in projects where it is not feasible/desirable to actually
>> include the source code in the org-mode file.
>>
>> Any comments or suggestions?
>>
>> Dan
>
> Dan,
>
> The use of line numbers seems a little error prone since line numbers
> can change dramatically by simply editing the file.  If you edit one
> section of a file, even if you update the line numbers for that
> section, you will need to search out all the *other* links to sections
> in that file and update them as well as they will become stale.  And,
> since it will be possible to have multiple org files with links into a
> single source file, this will be a *very* difficult thing to manage.

Hi Mark,

>
> Your idea about regexps sounds promising, though.

My current thought is that Emacs bookmarks might be the technology to
use here. They seem to be designed for this task (saving a reference to
a location in a file which is robust to mild file alteration), they are
almost 20 years old, and there is already org-bookmarks.el in contrib by
Tokuya Kameshima[1].

(info "(emacs) Bookmarks")

>  You could define
> 'markers' in comments delimiting the relevant sections of code and
> org could search these out easily enough.

My hope was to avoid forcing the target files to receive extra
Org-related content. E.g. suppose that the target files are a
collaborative project involving non-Org users that is under version
control; one wouldn't want to commit those special tags, and one
wouldn't particularly want to have to filter them out them when making
commits.

Dan

[1] I haven't looked into this properly, but to avoid staleness one
possibility would be to modify Tokuya's links to actually include the
lisp form defining the bookmark (i.e. the entry in bookmark-alist) in
the non-visible portion of the link (?). My proposed range links would
employ two bookmarks.




>
> Mark
>
>
> _______________________________________________
> 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

Re: Re: Limited #+INCLUDE ?

[Mark Elston]

On 4/26/2010 7:19 PM, Dan Davison wrote:
> Mark Elston<m_elston@comcast.net>  writes:
>>
>> Dan,
>>
>> The use of line numbers seems a little error prone since line numbers
>> can change dramatically by simply editing the file.  If you edit one
>> section of a file, even if you update the line numbers for that
>> section, you will need to search out all the *other* links to sections
>> in that file and update them as well as they will become stale.  And,
>> since it will be possible to have multiple org files with links into a
>> single source file, this will be a *very* difficult thing to manage.
>
> Hi Mark,
>
>>
>> Your idea about regexps sounds promising, though.
>
> My current thought is that Emacs bookmarks might be the technology to
> use here. They seem to be designed for this task (saving a reference to
> a location in a file which is robust to mild file alteration), they are
> almost 20 years old, and there is already org-bookmarks.el in contrib by
> Tokuya Kameshima[1].

I haven't tried this so I don't know how resilient it is to changes in
the target file.

> (info "(emacs) Bookmarks")
>
>>   You could define
>> 'markers' in comments delimiting the relevant sections of code and
>> org could search these out easily enough.
>
> My hope was to avoid forcing the target files to receive extra
> Org-related content. E.g. suppose that the target files are a
> collaborative project involving non-Org users that is under version
> control; one wouldn't want to commit those special tags, and one
> wouldn't particularly want to have to filter them out them when making
> commits.

It's the non-org users that would, of course, be the 'problem', though.
They are the ones likely to make non-mild edits and not update links.
In a collaborative project you will likely always be trying to keep
your links up-to-date without some kind of marker in the code.

> Dan
>
> [1] I haven't looked into this properly, but to avoid staleness one
> possibility would be to modify Tokuya's links to actually include the
> lisp form defining the bookmark (i.e. the entry in bookmark-alist) in
> the non-visible portion of the link (?). My proposed range links would
> employ two bookmarks.
>

Mark

Re: Re: Limited #+INCLUDE ?

[Eric S Fraga]

On Mon, 26 Apr 2010 15:40:35 -0400, Dan Davison <davison@stats.ox.ac.uk> 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
>   file. The syntax could be
>   [[file:/path/to/file::from::to][linkname]]

+1

I like this idea, especially for exporting complex documents.  If
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, narrowed
>   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.

Re: Re: Limited #+INCLUDE ?

[Darlan Cavalcante Moreira]

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 although
it would be limited to a "function body at a time" it would be enough in
many situations.

Darlan

2010/4/27 Eric S Fraga <ucecesf@ucl.ac.uk>:
> On Mon, 26 Apr 2010 15:40:35 -0400, Dan Davison <davison@stats.ox.ac.uk> 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
>>   file. The syntax could be
>>   [[file:/path/to/file::from::to][linkname]]
>
> +1
>
> I like this idea, especially for exporting complex documents.  If
> 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, narrowed
>>   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
>



-- 
Darlan Cavalcante Moreira

"SDR4all, a new way of teaching telecommunications: http://www.sdr4all.com/

Re: Re: Limited #+INCLUDE ?

[Eric Schulte]

Darlan Cavalcante Moreira <darcamo@gmail.com> 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 although
> 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.

(info "(emacs)Tags") ;; how great is it that gnus resolves these links 

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 <ucecesf@ucl.ac.uk>:
>> On Mon, 26 Apr 2010 15:40:35 -0400, Dan Davison <davison@stats.ox.ac.uk> 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
>>>   file. The syntax could be
>>>   [[file:/path/to/file::from::to][linkname]]
>>
>> +1
>>
>> I like this idea, especially for exporting complex documents.  If
>> 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, narrowed
>>>   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
>>

Re: Re: Limited #+INCLUDE ?

[Dan Davison]

"Eric Schulte" <schulte.eric@gmail.com> writes:

> Darlan Cavalcante Moreira <darcamo@gmail.com> 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 although
>> 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.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 
>
> 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 <ucecesf@ucl.ac.uk>:
>>> On Mon, 26 Apr 2010 15:40:35 -0400, Dan Davison <davison@stats.ox.ac.uk> 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
>>>>   file. The syntax could be
>>>>   [[file:/path/to/file::from::to][linkname]]
>>>
>>> +1
>>>
>>> I like this idea, especially for exporting complex documents.  If
>>> 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, narrowed
>>>>   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

Re: Re: Limited #+INCLUDE ?

[Eric Schulte]

Dan Davison <davison@stats.ox.ac.uk> writes:

> "Eric Schulte" <schulte.eric@gmail.com> writes:
>
>> Darlan Cavalcante Moreira <darcamo@gmail.com> 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 although
>>> 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 
>>
>> 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 <ucecesf@ucl.ac.uk>:
>>>> On Mon, 26 Apr 2010 15:40:35 -0400, Dan Davison <davison@stats.ox.ac.uk> 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
>>>>>   file. The syntax could be
>>>>>   [[file:/path/to/file::from::to][linkname]]
>>>>
>>>> +1
>>>>
>>>> I like this idea, especially for exporting complex documents.  If
>>>> 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, narrowed
>>>>>   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

Re: Limited #+INCLUDE ?

[Giles Chamberlin]

Dan Davison <davison@stats.ox.ac.uk> writes:


> 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.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?

The non-programming context actually suits my original requirement
better than the major-mode version.  Because of the nature of the course
its not uncommon to be working in a language which does not play nicely
with a major mode: recent example Java Markup Language which is held as
comments in a java class file.

-- 
Giles

Re: Re: Limited #+INCLUDE ?

[Samuel Wales]

Another way to look at it is that this is an annotation mechanism.  It
can be used for any type of file or buffer.  This would include text,
websites (i.e. pointing to and annotating documents on the web),
dired, source code, org files, html source, etc.

Modifying existing link syntax will be difficult, especially because
there might be additional features we need a year or two from now.
For maximum flexibility and simplicity, this might be a good first use
of extensible syntax.

Samuel

-- 
Q: How many CDC "scientists" does it take to change a lightbulb?
A: "You only think it's dark." [CDC has denied a deadly disease for 25 years]
==========
Retrovirus: http://www.wpinstitute.org/xmrv/index.html

Re: Re: Limited #+INCLUDE ?

[Dan Davison]

Samuel Wales <samologist@gmail.com> writes:

> Another way to look at it is that this is an annotation mechanism.  It
> can be used for any type of file or buffer.  This would include text,
> websites (i.e. pointing to and annotating documents on the web),
> dired, source code, org files, html source, etc.
>
> Modifying existing link syntax will be difficult, especially because
> there might be additional features we need a year or two from now.
> For maximum flexibility and simplicity, this might be a good first use
> of extensible syntax.

Hi Samuel,

I'm not quite clear what you're referring to when you say "this" in the
above sentences. Also, when you say "extensible syntax", are you
referring to the existing link syntax, or to a proposed extension?

Thanks,

Dan

>
> Samuel

Re: Re: Limited #+INCLUDE ?

[Carsten Dominik]

On Apr 27, 2010, at 9:19 PM, Dan Davison wrote:

> Samuel Wales <samologist@gmail.com> writes:
>
>> Another way to look at it is that this is an annotation mechanism.   
>> It
>> can be used for any type of file or buffer.  This would include text,
>> websites (i.e. pointing to and annotating documents on the web),
>> dired, source code, org files, html source, etc.
>>
>> Modifying existing link syntax will be difficult, especially because
>> there might be additional features we need a year or two from now.
>> For maximum flexibility and simplicity, this might be a good first  
>> use
>> of extensible syntax.
>
> Hi Samuel,
>
> I'm not quite clear what you're referring to when you say "this" in  
> the
> above sentences. Also, when you say "extensible syntax", are you
> referring to the existing link syntax, or to a proposed extension?

Samuel wrote about this a year ago.

http://article.gmane.org/gmane.emacs.orgmode/11896/match=wales+extensible


- Carsten

Re: Re: Limited #+INCLUDE ?

[Samuel Wales]

Hi Dan,

On 2010-04-27, Dan Davison <davison@stats.ox.ac.uk> wrote:
>> Another way to look at it is that this is an annotation mechanism.  It
>> can be used for any type of file or buffer.  This would include text,
>> websites (i.e. pointing to and annotating documents on the web),
>> dired, source code, org files, html source, etc.
>>
>> Modifying existing link syntax will be difficult, especially because
>> there might be additional features we need a year or two from now.
>> For maximum flexibility and simplicity, this might be a good first use
>> of extensible syntax.
>
> Hi Samuel,
>
> I'm not quite clear what you're referring to when you say "this" in the
> above sentences. Also, when you say "extensible syntax", are you
> referring to the existing link syntax, or to a proposed extension?

"this" means the idea in this thread.

Extensible syntax is a specific, documented proposal.  I posted some
of the idea to this list a long time ago, as Carsten pointed out.

One application of extensible syntax is "this".  :)

You can use extensible syntax for any feature you want.  "this" is
links with special subfeatures that would be difficult to program into
ordinary link syntax.

Samuel

>
> Thanks,
>
> Dan
>
>>
>> Samuel
>


-- 
Q: How many CDC "scientists" does it take to change a lightbulb?
A: "You only think it's dark." [CDC has denied a deadly disease for 25 years]
==========
Retrovirus: http://www.wpinstitute.org/xmrv/index.html