[Top][All Lists]

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

Re: [Orgmode] Re: Limited #+INCLUDE ?

From: Mark Elston
Subject: Re: [Orgmode] Re: Limited #+INCLUDE ?
Date: Tue, 27 Apr 2010 17:52:48 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100317 Thunderbird/3.0.4

On 4/26/2010 7:19 PM, Dan Davison wrote:
Mark Elston<address@hidden>  writes:


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

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.


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


reply via email to

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