emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Carsten Dominik <dominik@science.uva.nl>
To: Austin Frank <austin.frank@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: configurable link export
Date: Sat, 20 May 2006 13:01:20 +0200	[thread overview]
Message-ID: <d669ee55a940f6ebf7138ea05248fc60@science.uva.nl> (raw)
In-Reply-To: <446E1D82.4060806@gmail.com>

Hi Austin,

On May 19, 2006, at 21:33, Austin Frank wrote:
>
> I'd like to suggest a configuration option that influences the way 
> links are exported in the org-export-as-* functions.

[...]

I think you are raising a very valid point here.  This is something 
that needs to be handled in an appropriate way.  Anybody knows how 
Emacs Wiki and Muse deal with such things?

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? :-)

Validation of links is really related to publishing.  From the point of 
"exporting", somefile.html is simply a different representation of 
something.org, by default this exported file lives in the same 
directory, so all file links, be they absolute or relative should work 
just fine.

However, publishing is about moving files to a publishing directory, 
and here the issue of validating links becomes really important.  The 
way I would like to go about implementing this is the following:

The org-publish functions should pass a special property to the html 
exporter.  The value of this property should be a function that can be 
used to validate a file link.  I would like to be able to call this 
function with a file name as the argument and maybe the directory of 
the original org file as an additional argument (might be unnecessary). 
  This function should then return if it will be safe to link to this 
file, and maybe even return a modified path to this file.

Org-publish would then be responsible to create the right function, and 
the user could even write her own function.

Besides minimizing the work for me :-), this would have obvious 
advantages.  Org-publish is fully aware of the entire structure of a 
project, so it will know which files will also be exported, to what 
locations, and it can therefore make a very accurate determination on 
if and how a given file will be accessible from the publishing 
location.

There are many ways org-publish could go about doing this.  One would 
be the way you, Austin, proposed, through special configuration setting 
- not variables, but properties then.  Another, more elegant 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.

David, what do you think?  Austin, do you think this could be a viable 
way?

- Carsten

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

  reply	other threads:[~2006-05-20 11:01 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 [this message]
2006-05-20 13:01   ` David O'Toole
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=d669ee55a940f6ebf7138ea05248fc60@science.uva.nl \
    --to=dominik@science.uva.nl \
    --cc=austin.frank@gmail.com \
    --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).