emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: David O'Toole <dto@gnu.org>
To: Carsten Dominik <dominik@science.uva.nl>
Cc: emacs-orgmode@gnu.org
Subject: Re: configurable link export
Date: Sat, 20 May 2006 09:01:56 -0400	[thread overview]
Message-ID: <m3psi8alyz.fsf@gnu.org> (raw)
In-Reply-To: <d669ee55a940f6ebf7138ea05248fc60@science.uva.nl> (Carsten Dominik's message of "Sat, 20 May 2006 13:01:20 +0200")


Carsten Dominik <dominik@science.uva.nl> writes:

> Anyway, I have been thinking about your argumentation and come to the
> conclusion that this is an issue I would like to push almost entirely
> onto Davids table.  David, are you listening? :-)

Yes :-)

> way,  would be that the structure and content of
> org-publish-project-alist is used to fully automatically determine the
> validity of a link.  not trivial to implement, but possible and a nice
> challenge.

I have been thinking about inter-file links in preparation for
implementing some of the more advanced features for org-publish (page
rewriting, sitemap generation, etc) and I think this will be very
simple to straighten out.

All we need is for people to specify a property called :link-base that
is the prefix for a URL. For example, if :publishing-directory is
"/ssh:user@host:~/public_html/images", the user should probably set
the :link-base to "/images" or "http://foosite.org/images"

Given this one extra piece of information, then it is a simple matter
for the :link-transform function to actually generate proper URLs
(instead of simply validating them.) This would free projects from the
requirement that the web server must have the exact same directory
layout as your local project files.

This would allow, as you say, for link targets to be validated and
transformed automatically, given just the structure and contents of
org-publish-project-alist.

I will work on this and let you know how it goes. 

Austin--- how does this sound? 


>> When I create local org files, I link to whatever files on my disk
>> are relevant and useful.  When I publish those org files, some of
>> the org links (like to other published org files) still work and
>> make sense as html links.  Others (like links to local documents or
>> directories) don't make any sense when published-- the resources
>> they pointed to on the local system aren't on the remote filesystem
>> that hosts the html pages.
>>
>> To be more specific, I maintain a directory ~/notes/ and a directory
>> ~/blog/, each with a bunch of org files underneath it.  I then use
>> org-publish to generate the html files, which are then uploaded to
>> my website.  Crucially, this same directory structure is mirrored at
>> my website, so local org links between those files work perfectly as
>> html links when they are published and uploaded.
>>
>> I'd love to be able to specify that I want all org links of
>> [file:///home/aufrank/notes/*] and [file:///home/aufrank/blog/*] to
>> be exported as full html links, and exclude org links to any other
>> files on my filesystem at export time.
>>
>> I think that David has established a good system for including and
>> excluding files during publishing.  Org-publish first generates a
>> list of files to publish based on regex matching of the extensions
>> of files in a directory.  These are filtered through a regex-based
>> exclude list, and then individual files can be added back in with an
>> include list.
>>
>> Applying this strategy to link export, I might want to have
>> something like the following in my org-config.el:
>>
>> (setq org-export-links-extension "org\\|txt"
>>       org-export-links-exclude   "~/*"
>>       org-export-links-include   ("~/notes/", "~/blog/"))
>>
>> This would result in exporting all of the .org and .txt files in
>> ~/notes/ and ~/blog/ as working links in html files, but would
>> ignore links in org files to anything else in my home directory
>> during export.
>>
>> There's certainly a question about how org links that are not
>> exported as html links should be handled.  I would actually be fine
>> with just exporting the double-bracketed notation, but I bet there
>> are better ideas out there.
>>
>> Thanks again for the org suite,
>> /au
>>
>>
>> _______________________________________________
>> Emacs-orgmode mailing list
>> Emacs-orgmode@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>>
>>
>
> --
> Carsten Dominik
> Sterrenkundig Instituut "Anton Pannekoek"
> Universiteit van Amsterdam
> Kruislaan 403
> NL-1098SJ Amsterdam
> phone: +31 20 525 7477
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>

-- 
Dave O'Toole
dto@gnu.org

  reply	other threads:[~2006-05-20 13:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-19 19:33 configurable link export Austin Frank
2006-05-20 11:01 ` Carsten Dominik
2006-05-20 13:01   ` David O'Toole [this message]
2006-05-21 15:02     ` Austin Frank
2006-05-22  9:22     ` Carsten Dominik
2006-05-21 15:02   ` Austin Frank

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3psi8alyz.fsf@gnu.org \
    --to=dto@gnu.org \
    --cc=dominik@science.uva.nl \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).