From mboxrd@z Thu Jan 1 00:00:00 1970 From: David O'Toole Subject: Re: Adapting org-mode to my needs Date: Wed, 19 Apr 2006 09:53:20 -0400 Message-ID: References: <8ad6e8e719e192f5101f6b5f2b9d651b@science.uva.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FWD7Y-0000i9-P4 for emacs-orgmode@gnu.org; Wed, 19 Apr 2006 09:53:28 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FWD7W-0000ex-4o for emacs-orgmode@gnu.org; Wed, 19 Apr 2006 09:53:28 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FWD7V-0000eu-VS for emacs-orgmode@gnu.org; Wed, 19 Apr 2006 09:53:26 -0400 Received: from [66.249.82.199] (helo=xproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FWD8c-0001n8-Su for emacs-orgmode@gnu.org; Wed, 19 Apr 2006 09:54:35 -0400 Received: by xproxy.gmail.com with SMTP id s13so740722wxc for ; Wed, 19 Apr 2006 06:53:24 -0700 (PDT) In-Reply-To: <8ad6e8e719e192f5101f6b5f2b9d651b@science.uva.nl> (Carsten Dominik's message of "Wed, 19 Apr 2006 08:10:15 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Carsten Dominik Cc: emacs-orgmode@gnu.org Carsten Dominik 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:user@host:path/" My planner-publishing-directory is specified as "/ssh:dto@tty.freeshell.org:~/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 dto@gnu.org