Re: Re: Limited #+INCLUDE ?

[Mark Elston <m_elston@comcast.net>]

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