Re: [Emacs-orgmode] Adapting org-mode to my needs

[David O'Toole]

Carsten Dominik <address@hidden> writes:

> If this is 2%, then you must make heavy use of org-mode. :-)

Heheheh :-) actually I am only using org-mode on a test basis, with an
eye toward using it as my primary organizer soon. I meant that
org-mode seems to do 98% of what I am currently getting out of
planner, and that the 2% is just a few functions/tweaks that make it
possible for me to configure org-mode in a way that will make me happy
:-) Then i will of course share my tweaks and configurations so that
others can do what I'm doing with it. 

I want to switch because org-mode seems to have a much cleaner
conceptual design, and because its modeling of workflow seems more
configurable and more sophisticated. All I have to do is get it to
publish to html the way I like it, and I'm sold!

> If I understand you correctly, you can and want to do Lisp coding
> yourself?

Yes. I wrote a small html-export system for howm mode. 

The source is available at my old website:
http://dto.twu.net/howm-blog.el

It manufactures pages that look like this:
http://dto.twu.net/HowmTutorial.howm.html

You can use this to check my coding style :-)

> I guess we could have variables for the page header and footer that
> will be inserted there, with place holders for author name, date, and
> title.  

I recommend the customizable variable approach for headers/footers,
rather than "header.html" inclusion, because:

1. it is consistent with author, title etc being stored in
   customizable variables, and then everything can be set in .emacs

2. people can always read contents of header.html into org-html-header
   if they really want to keep their headers in a separate file

> This is trivial to implement.  I guess the easy way would be to let
> org-mode export to the current directory as it does now, and then copy
> the file by whatever means to a destination.
>
> What do you mean by TRAMP urls?

Tramp is the part of emacs that allows transparent
editing/reading/writing of remote files/directories. 

syntax: "/protocol:address@hidden:path/"

My planner-publishing-directory is specified as

"/ssh:address@hidden:~/html/wiki/" 

Functions like write-file will automatically handle URLs like this
when Tramp is enabled, i.e. writing a file to a remote host "just
works".

This is especially convenient for me because I have a free account
that has scp and ftp disabled. Tramp writes the files by logging into
the shell on the remote machine via ssh, and shoving the uuencoded
files through the ssh connection. Works as well as ftp!

I can always just re-read the file from where org-mode puts it on the
disk, but if org-mode allowed you to specify the output directory,
then one could publish files to your webserver directly from emacs, by
specifying the right Tramp URL.

Your code wouldn't have to know anything about tramp.

> Inter-file links work like URLs, for example [[file:pagename.org]], so
> all you need to do is to add the "file:" handle in front of the file
> name, and you need to specify the extension explicitly.  Slightly more
> inconvenient than in planner, but easy enough.  It would not be hard
> to implement a switch in the exporter that would convert all "file:"
> links to .org files into "html:" links to an html file.

What about something like [[org:pagename]] to specify links to another
file? This would allow people to still use [[file:pagename.org]] in
the case where they want web users to access the .org source of a
page.

> Other external files are just as easy: [[file:../e/thisfile]].

oh. cool.

> Org-mode has links to images as well, and the HTML output will contain
> the link.  I would have to check if the handling uses absolute or
> relative file paths, but that is also easily modified.  Inlining
> images into an Emacs buffer is something I rarely find useful (the
> most notable exception being preview-latex).

You're probably right here :) though I plan to write an image-heavy
tutorial soon, possibly using org-mode, and it might help if the
images were inline. Nonetheless this isn't crucial. 

> I would propose the following strategy.  You start by creating a
> project, something like org-publish.el.  In that you define what is
> needed to do a publishing project, i.e. variables holding the root
> directory of a project, the directory where to publish the files, and
> anything else.  I guess you can let yourself guide by how Emacs wiki
> and Muse do these things.
>
> Then you write commands to visit each org-file in that directory in
> turn, call the exporter and ship off the resulting file to whatever
> destination you desire, along with any other non-.org files in the
> project directory.
>
> I would make the required hooks in the existing HTML exporter.  As far
> as I can see this mainly means honoring relative path specifications
> correctly, and changing links to .org files from file: to http:.
>
> You also think up a way to define the header and footers for these new
> files, and I would provide ways for you to pass these to the exporter.
>
> With a setup like this, we can develop this relatively independently.
> When the dust settles, we can integrate the new code into org.el, or
> distribute it with it, if that is what you want.

This sounds fantastic! I'll get started...

this is fun :-)

-- 
Dave O'Toole
address@hidden