emacs-orgmode
[Top][All Lists]
Advanced

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

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


From: David O'Toole
Subject: Re: [Emacs-orgmode] Adapting org-mode to my needs
Date: Thu, 20 Apr 2006 22:31:56 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

;; Hi Carsten. In this email you'll find my thoughts on improving the
;; html export features of org-mode. 

;; Contents: 
;;         + data structure for publishing configuration info
;;         + suggestions on how to get this data into org-export
;;           functions
;;         + other suggestions I consider really important

;; It will be very easy for me to write a publish-project function
;; that converts all org files to html via your code, and also uploads
;; auxiliary images etc. to create an entire site. I just want to work
;; out our data exchange details first :-)

;; I would like to contribute this and more, as I think of stuff. I'd
;; be happy to do the required paperwork with the FSF.

;; Read on and let me know what you think.

;;;; 1. The following is an example of a data structure that users
;;      could use to define a set of publishing configurations for an
;;      entire folder full of org files.

(setq org-publish-config-plist 
      (list :orgfiles-dir "~/org"
            :html-dir "/ssh:address@hidden:~/html"
            
            ; we don't actually customize the full html header here.
            ; it would need to have %s %s %s in it. instead we let
            ; org-publish-as-html fill in the header its own way, and
            ; allow user to customize "preamble/postamble" (see
            ; below.) this way people can add menu across the top, or
            ; sidebar full of links, or javascript etc, to a group of
            ; related pages all at once, without messing with <head>
            
            ; inserted just after <body> tag
            :html-preamble  "my-preamble-string"   
            ; inserted just before </body> tag
            :html-postamble "my-postamble-string"  

            ; allow user to turn off the printout of author, email,
            ; date at the top of pages. I really want this. 
           
            :auto-preamble nil

            ; the following are inserted into the right places in the
            ; real html header by org-publish-as-html

            :style "my-css-string"
            :language "en"
            :author user-full-name
            :email user-mail-address

            ; other options that should over-ride global variables
            ; when publishing (of course, options set per orgfile
            ; should override everything.)

            :headline-levels 3
            :toc nil

            ; can you think of more? 
            ))


;;;; 2. How to get the above data into the HTML exporter of Org-mode:

;; The function "org-export-as-html" should accept an optional plist
;; like the one above, and should honor the values in it (subject to
;; per-file override of course).
;;
;; You can retrieve the values like this: 
;; 
;; (plist-get org-publish-config-plist :style)
;; (plist-get org-publish-config-plist :html-preamble)

;; see also (info "(elisp)Other Plists")
;;
;; It seems like most of the changes would then be in the let* section
;; of org-export-as-html, simply checking whether the user has set a
;; given property in the plist, before assigning the current default.
;;
;; See below for an example of such a change.


;;;; 3. Other comments on org-export-as-html:

;; + Setting of "filename" should allow folders other than the same
;;   folder as the orgfile. It's a sensible default to use the same
;;   folder, but it should be configurable by respecting :html-dir
;;   from the org-publish-config-plist. 

;;   reasons: i do not want html files in my org folder. grep would
;;            find everything twice if I grep the folder.  we should
;;            be able to keep org files in the org folder, images in
;;            ../images, html in ../org-html if so desired. 

;;   in that case we'd change the line in the let* from:

(filename (concat (file-name-sans-extension buffer-file-name)
                           ".html"))

;;   to something like 

(filename (let ((html-dir (plist-get org-publish-config-plist :html-dir)))
            (if html-dir
                (concat html-dir 
                        (file-name-sans-extension buffer-name)
                        ".html")  ;; this will work with TRAMP!
              (concat (file-name-sans-extension buffer-file-name)
                      ".html"))))
   
;; + Default page title should be set to 

(file-name-sans-extension (buffer-name)) 

;; instead of just 

(buffer-name)

;;   reasons: Most people will have TOPIC.org, so the page title
;;            should be TOPIC.  (who really wants ".org" at the end of
;;            a big page title?  this is not a useful default and it
;;            really surprised me the first time I saw .org at the end
;;            of the page title. it looks like a website address.)


Carsten Dominik <address@hidden> writes:

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

-- 
Dave O'Toole
address@hidden




reply via email to

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