Adapting org-mode to my needs

Adapting org-mode to my needs

[David O'Toole]

Hi folks. 

I was a heavy planner.el user for about 2 years, then switched to
howm-mode for about a year, then switched back to Planner, and have
finally decided to seek a middle ground.

In my view, Org-mode combines about 98% of everything I liked from
both Planner-mode and Howm-mode. I'm already just about sold!

This email is about that other 2 percent :-) as I would like to adapt
Org-mode to my needs. 

One of the main things I have used Planner for is to publish a website
from my notes. I see that org makes nice html output from a given
page, but I have some questions about its configurability.

1. Is there a way to completely suppress the page header, or alter its
   contents (for example, not listing author and date at the top of
   all pages). Planner allows configurable html headers and
   footers. I'd rather just have the title at the top, and put these
   things at the bottom. I'd also like to put a set of common links
   across the top of the page, as a sort of menubar, like many sites
   have. 

2. I want to publish a set of interlinked, related pages as a
   "project." I think it would be easy enough for me to write an elisp
   function that runs through a list of *.org files I want to publish,
   publishes each one in turn, and then uploads each file to my site
   via Tramp. (This would approximate the way Planner publishes my
   stuff. It would help if org would let you specify the folder that
   html output is to go in, and if it allowed Tramp URLs.)

   However, would inter-page links work? In Planner, the link
   [[pagename]] takes me to the file "pagename.muse". Then when the
   pages are published to html, it becomes a link to "pagename.html"
   so that the pages link together correctly in both Emacs buffers and
   in the web browser. 

   What about links to other external files? I have the following
   directory structure in my Planner:

   /home/dto/Plans    (my planner files)
   /home/dto/e        (e-scripts, my *.el that i've written, and other
                      publishable attachments)

   I can make a link to [[../e/thisfile]] and as long as I replicate
   the same directory structure on the webserver, the links resolve
   correctly once the files are published to html.

   This would seem crucial to my publishing a whole website of related
   pages using org. How would I go about making this work in org?

3. Planner/muse allow image links. It will actually put the image in
   the buffer for you, so long as it can find the file. 

4. In howm-mode, one doesn't need to specify an explicit list of pages
   to be searched; instead you give it a folder and everything in that
   folder counts as a page. This makes it easy to make new pages/topics
   (whereas in org it seems like I would have to add them manually to
   the list.) This isn't a crisis, as I can always just write a script
   to update the list based on what's in the folder (and share the
   script so that other org users can take advantage.)
 
5. Is there a way to get TODO etc to publish as something besides <h4>?

Let me know if I can help add these features to Orgmode. I would be
happy to help contribute changes/solutions if a developer can point me
in the right direction.

I'm interested to hear your thoughts. Thank you. 

BTW, org is great!!!


-- 
Dave O'Toole
dto@gnu.org

Adapting org-mode to my needs

[David O'Toole]

My apologies if this is a double-posting; for some reason I'm having
trouble sending emails to this list. (Ops, perhaps you can help out?) 

..... and now for the message itself. 

I was a heavy planner.el user for about 2 years, then switched to
howm-mode for about a year, then switched back to Planner, and have
finally decided to seek a middle ground.

In my view, Org-mode combines about 98% of everything I liked from
both Planner-mode and Howm-mode. I'm already just about sold!

This email is about that other 2 percent :-) as I would like to adapt
Org-mode to my needs. 

One of the main things I have used Planner for is to publish a website
from my notes. I see that org makes nice html output from a given
page, but I have some questions about its configurability.

1. Is there a way to completely suppress the page header, or alter its
   contents (for example, not listing author and date at the top of
   all pages). Planner allows configurable html headers and
   footers. I'd rather just have the title at the top, and put these
   things at the bottom. I'd also like to put a set of common links
   across the top of the page, as a sort of menubar, like many sites
   have. 

2. I want to publish a set of interlinked, related pages as a
   "project." I think it would be easy enough for me to write an elisp
   function that runs through a list of *.org files I want to publish,
   publishes each one in turn, and then uploads each file to my site
   via Tramp. (This would approximate the way Planner publishes my
   stuff. It would help if org would let you specify the folder that
   html output is to go in, and if it allowed Tramp URLs.)

   However, would inter-page links work? In Planner, the link
   [[pagename]] takes me to the file "pagename.muse". Then when the
   pages are published to html, it becomes a link to "pagename.html"
   so that the pages link together correctly in both Emacs buffers and
   in the web browser. 

   What about links to other external files? I have the following
   directory structure in my Planner:

   /home/dto/Plans    (my planner files)
   /home/dto/e        (e-scripts, my *.el that i've written, and other
                      publishable attachments)

   I can make a link to [[../e/thisfile]] and as long as I replicate
   the same directory structure on the webserver, the links resolve
   correctly once the files are published to html.

   This would seem crucial to my publishing a whole website of related
   pages using org. How would I go about making this work in org?

3. Planner/muse allow image links. It will actually put the image in
   the buffer for you, so long as it can find the file. 

4. In howm-mode, one doesn't need to specify an explicit list of pages
   to be searched; instead you give it a folder and everything in that
   folder counts as a page. This makes it easy to make new pages/topics
   (whereas in org it seems like I would have to add them manually to
   the list.) This isn't a crisis, as I can always just write a script
   to update the list based on what's in the folder (and share the
   script so that other org users can take advantage.)
 
5. Is there a way to get TODO etc to publish as something besides <h4>?

Let me know if I can help add these features to Orgmode. I would be
happy to help contribute changes/solutions if a developer can point me
in the right direction.

I'm interested to hear your thoughts. Thank you. 

BTW, org is great!!!


-- 
Dave O'Toole
dto@gnu.org

Re: Adapting org-mode to my needs

[Carsten Dominik]

Hi David,


On Apr 18, 2006, at 17:06, David O'Toole wrote:

> This email is about that other 2 percent :-) as I would like to adapt
> Org-mode to my needs.

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

>
> One of the main things I have used Planner for is to publish a website
> from my notes. I see that org makes nice html output from a given
> page, but I have some questions about its configurability.
>
> 1. Is there a way to completely suppress the page header, or alter its
>    contents (for example, not listing author and date at the top of
>    all pages). Planner allows configurable html headers and
>    footers. I'd rather just have the title at the top, and put these
>    things at the bottom. I'd also like to put a set of common links
>    across the top of the page, as a sort of menubar, like many sites
>    have.

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.  This is a relative minor change.  The menu across the page 
could go in there, but I would suspect that you need to put this into 
the header format yourself.

Another possibility would be to put the header and footer information 
into a special section of the outline in the file, for example

* COMMENT html configuration
** Header
     here the header HTML code which will be inlined into the exported 
file
** Footer
     here the footer HTML code which will be inlined into the exported 
file

>
> 2. I want to publish a set of interlinked, related pages as a
>    "project."

Let me start with some background.  One of the main differences between 
planner and org-mode is that planner was built from the start for 
publishing, org-mode not.  Planner was based originally on Emacs wiki, 
and now is based on Muse.  These are both authoring tools, mainly done 
for publishing to a variety of formats.  Planner is just riding on top 
of these.  So the publishing ability you describe is not really 
planner, its is Emacs wiki, or Muse.

Because of this background, planner adopts the approach of many small 
interlinked files that can be published as a set of interrelated files.

Org-mode on the other hand was designed initially as an organizing tool 
only.  It supports exporting HTML to allow putting a notes file on the 
web, but thats about it.  Org-mode files can be large and contain many 
projects, which is why the linking process focusses on internal linking 
in a file.  Links like [[My target]] link to another place in the same 
file, not to an external file.

>  I think it would be easy enough for me to write an elisp
>    function that runs through a list of *.org files I want to publish,
>    publishes each one in turn, and then uploads each file to my site
>    via Tramp. (This would approximate the way Planner publishes my
>    stuff. It would help if org would let you specify the folder that
>    html output is to go in, and if it allowed Tramp URLs.)

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?

>
>    However, would inter-page links work? In Planner, the link
>    [[pagename]] takes me to the file "pagename.muse". Then when the
>    pages are published to html, it becomes a link to "pagename.html"
>    so that the pages link together correctly in both Emacs buffers and
>    in the web browser.

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 links to other external files? I have the following
>    directory structure in my Planner:
>    /home/dto/Plans    (my planner files)
>    /home/dto/e        (e-scripts, my *.el that i've written, and other
>                       publishable attachments)
>
>    I can make a link to [[../e/thisfile]] and as long as I replicate
>    the same directory structure on the webserver, the links resolve
>    correctly once the files are published to html.
>
>    This would seem crucial to my publishing a whole website of related
>    pages using org. How would I go about making this work in org?

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

>
> 3. Planner/muse allow image links. It will actually put the image in
>    the buffer for you, so long as it can find the file.

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

>
> 4. In howm-mode, one doesn't need to specify an explicit list of pages
>    to be searched; instead you give it a folder and everything in that
>    folder counts as a page. This makes it easy to make new pages/topics
>    (whereas in org it seems like I would have to add them manually to
>    the list.) This isn't a crisis, as I can always just write a script
>    to update the list based on what's in the folder (and share the
>    script so that other org users can take advantage.)

Well, if you start implementing something like a publishing project 
with org-mode, I guess you would assume that all .org files in a given 
folder are part of the project.  What is different in HOWM is that it 
will automatically create links in existing files to new files.  
Org-mode does not have a mechanism for that.  So the question here 
really is: How would you like the older files to interact with newer 
ones?

>
> 5. Is there a way to get TODO etc to publish as something besides <h4>?

TODO entries in org-mode are simply part of the outline tree.  Any 
outline item can be a TODO entry.  When exporting to HTML, the first 4 
outline levels become h1...h4, the remaining ones become itemized 
lists.  You can change this transition with the "H" switch in the 
export "#+OPTIONS" line, have a look in the manual.  Apart from that, 
there are no special HTML constructs currently to wrap the TODO 
entries.

> Let me know if I can help add these features to Orgmode. I would be
> happy to help contribute changes/solutions if a developer can point me
> in the right direction.

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

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

Re: Adapting org-mode to my needs

[Carsten Dominik]

On Apr 19, 2006, at 8:10, Carsten Dominik wrote:

> 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.  This is a relative minor change.  The menu across the page 
> could go in there, but I would suspect that you need to put this into 
> the header format yourself.
>
> Another possibility would be to put the header and footer information 
> into a special section of the outline in the file, for example
>
> * COMMENT html configuration
> ** Header
>     here the header HTML code which will be inlined into the exported 
> file
> ** Footer
>     here the footer HTML code which will be inlined into the exported 
> file

Thinking more about this, I guess it would be better to have files 
"header.html" and "footer.html", and have the exported files refer to 
those.

- Carsten

Re: Adapting org-mode to my needs

[David O'Toole]

Carsten Dominik <carsten.dominik@gmail.com> 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

Re: Adapting org-mode to my needs

[David O'Toole]

;; 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:dto@tty.freeshell.org:~/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 <carsten.dominik@gmail.com> 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
dto@gnu.org

Re: Adapting org-mode to my needs

[Carsten Dominik]

Hi David,

this looks exactly right, I agree on all accounts.  A few comments:

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

Great.  Likely not for Emacs 22.1, but later, yes, I want to integrate 
this.  And if we integrate it, the FSF will need the paperwork done.

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

I actually would like to move author and date into a standard postamble 
because this is more the HTML way of doing things.  Then we will also 
need

	    :auto-postamble 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.im
>
> 	    :headline-levels 3
> 	    :toc nil
>
> 	    ; can you think of more?

I guess for consistency we should support almost all options in 
#+OPTIONS, plus
whatever I have customization options for.

One problem:  I think it is not easy to distinguish a nil property from 
an unspecified property....  Ah, I see there is also `plist-member' for 
this.  Great.

> (file-name-sans-extension (buffer-name))
>
> ;; instead of just
>
> (buffer-name)

Agreed.

Maybe we take the technical details off the mailing list and cc to 
emacs-orgmode only if the mail contains issues of broader interest?  
Anyone on this list who would like to listen to the technical chatter?

- Carsten

Re: Adapting org-mode to my needs

[David Emery]

On Date: Fri, 21 Apr 2006 10:04:16 +0200, Carsten Dominik <carsten.dominik@gmail.com> wrote:
> Maybe we take the technical details off the mailing list and cc to 
> emacs-orgmode only if the mail contains issues of broader interest?  
> Anyone on this list who would like to listen to the technical chatter?

I'd prefer that you copy the list on the technical process if nobody objects.

Regards,
Dave

Re: Adapting org-mode to my needs

[Carsten Dominik]

Hi David,

I have drawn up a complete list of properties I would like to use for  
the HTML extension:


| Plist-tag             | Customization variable                 | ?    
| Default           |
|-----------------------+----------------------------------------+----- 
+-------------------|
| :language             | org-export-default-language            |      
| "en"              |
| :headline-levels      | org-export-headline-levels             |      
| 3                 |
| :section-numbers      | org-export-with-section-numbers        |      
| t                 |
| :table-of-contents    | org-export-with-toc                    |      
| t                 |
| :emphasize            | org-export-with-emphasize              |      
| t                 |
| :sub-superscript      | org-export-with-sub-superscripts       |      
| t                 |
| :TeX-macros           | org-export-with-TeX-macros             |      
| t                 |
| :fixed-width          | org-export-with-fixed-width            |      
| t                 |
| :tables               | org-export-with-tables                 |      
| t                 |
| :table-auto-headline  | org-export-highlight-first-table-line  |      
| t                 |
| :style                | org-export-html-style                  |      
| "..."             |
| :convert-org-links    | org-export-html-link-org-files-as-html |      
| t                 |
| :inline-images        | org-export-html-inline-images          |      
| t                 |
| :expand-quoted-html   | org-export-html-expand                 |      
| t                 |
| :timestamp            | org-export-html-with-timestamp         |      
| nil               |
| :publishing-directory | org-export-html-to-directory           | new  
| "."               |
| :preamble             | org-export-html-preamble               | new  
| ""                |
| :postamble            | org-export-html-postamble              | new  
| ""                |
| :auto-preamble        | org-export-html-auto-preamble          | new  
| t                 |
| :auto-postamble       | org-export-html-auto-postamble         | new  
| t                 |
| :author               | user-full-name                         |      
| user-full-name    |
| :email                | user-mail-address                      |      
| user-mail-address |


If you agree I will go ahead and implement them.

- Carsten

Re: Adapting org-mode to my needs

[David O'Toole]

Looks good to me! Thank you for doing this. 

Once I have the updated version of org-mode, I will write and test my
publishing functions (including something that manufactures an index
of all the pages in a project, and possibly produces other reports.)

I have some more thoughts on org-mode but I will send them a bit later
today. 

Carsten Dominik <carsten.dominik@gmail.com> writes:

> Hi David,
>
> I have drawn up a complete list of properties I would like to use for
> the HTML extension:
>
>
> | Plist-tag             | Customization variable                 | ?
>   | Default           |
> |-----------------------+----------------------------------------+----- 
> +-------------------|
> | :language             | org-export-default-language            |
>   | "en"              |
> | :headline-levels      | org-export-headline-levels             |
>   | 3                 |
> | :section-numbers      | org-export-with-section-numbers        |
>   | t                 |
> | :table-of-contents    | org-export-with-toc                    |
>   | t                 |
> | :emphasize            | org-export-with-emphasize              |
>   | t                 |
> | :sub-superscript      | org-export-with-sub-superscripts       |
>   | t                 |
> | :TeX-macros           | org-export-with-TeX-macros             |
>   | t                 |
> | :fixed-width          | org-export-with-fixed-width            |
>   | t                 |
> | :tables               | org-export-with-tables                 |
>   | t                 |
> | :table-auto-headline  | org-export-highlight-first-table-line  |
>   | t                 |
> | :style                | org-export-html-style                  |
>   | "..."             |
> | :convert-org-links    | org-export-html-link-org-files-as-html |
>   | t                 |
> | :inline-images        | org-export-html-inline-images          |
>   | t                 |
> | :expand-quoted-html   | org-export-html-expand                 |
>   | t                 |
> | :timestamp            | org-export-html-with-timestamp         |
>   | nil               |
> | :publishing-directory | org-export-html-to-directory           | new
>   | "."               |
> | :preamble             | org-export-html-preamble               | new
>   | ""                |
> | :postamble            | org-export-html-postamble              | new
>   | ""                |
> | :auto-preamble        | org-export-html-auto-preamble          | new
>   | t                 |
> | :auto-postamble       | org-export-html-auto-postamble         | new
>   | t                 |
> | :author               | user-full-name                         |
>   | user-full-name    |
> | :email                | user-mail-address                      |
>   | user-mail-address |
>
>
> If you agree I will go ahead and implement them.
>
> - Carsten
>
>

-- 
Dave O'Toole
dto@gnu.org

Interaction of org-mode and Muse (was: Adapting org-mode to my needs)

[Michael Olson]

[-- Attachment #1.1: Type: text/plain, Size: 1671 bytes --]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> Let me start with some background.  One of the main differences
> between planner and org-mode is that planner was built from the
> start for publishing, org-mode not.  Planner was based originally on
> Emacs wiki, and now is based on Muse.  These are both authoring
> tools, mainly done for publishing to a variety of formats.  Planner
> is just riding on top of these.  So the publishing ability you
> describe is not really planner, its is Emacs wiki, or Muse.
>
> Because of this background, planner adopts the approach of many
> small interlinked files that can be published as a set of
> interrelated files.

On that note, in a couple of weeks (once finals and the next Muse
release are done), I'm going to take a look at org-mode and try to
figure out different ways that Muse and org-mode can interact, since
this is something that people on the Muse mailing list have requested
in the past.  Especially since Muse will probably be entering Emacs
once Emacs22 is released.

One of the plans for the next release of Muse + 1 (3.04) is to support
publishing documents that use other markup syntaxes, such as Markdown
and reSt.  Perhaps org-mode syntax could be supported as well.

If someone is familiar with both modes, feel free to suggest ways that
they could complement one another.

-- 
Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/
Interests: Emacs Lisp, text markup, protocols -- Jabber: mwolson_at_hcoop.net
  /` |\ | | | IRC: mwolson on freenode.net: #hcoop, #muse, #PurdueLUG
 |_] | \| |_| Project involvement: Emacs, Muse, Planner, ERC, EMMS

[-- Attachment #1.2: Type: application/pgp-signature, Size: 190 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
emacs-wiki-discuss mailing list
emacs-wiki-discuss@nongnu.org
http://lists.nongnu.org/mailman/listinfo/emacs-wiki-discuss

Re: Interaction of org-mode and Muse (was: Adapting org-mode to my needs)

[Carsten Dominik]

Hi Michael,

On Apr 26, 2006, at 22:16, Michael Olson wrote:
>
> On that note, in a couple of weeks (once finals and the next Muse
> release are done), I'm going to take a look at org-mode and try to
> figure out different ways that Muse and org-mode can interact, since
> this is something that people on the Muse mailing list have requested
> in the past.  Especially since Muse will probably be entering Emacs
> once Emacs22 is released.

Besides the obvious interaction, using the Muse engine to produce
other export formats, can you think of more ways to interact?

> One of the plans for the next release of Muse + 1 (3.04) is to support
> publishing documents that use other markup syntaxes, such as Markdown
> and reSt.  Perhaps org-mode syntax could be supported as well.

I have actually been thinking about an org-to-muse converter as a 
possibility for easy expansion to many more export formats.  So I have 
a number of ideas about what would be needed and where the difficulties 
lie.  A short appetizer:

- Headline detection should be trivial, however
- Org-mode uses (at least: can use) many more levels than the 4
   available in Muse now.  The Org-mode exporters just switch to
   itemized lists at some headline level.
- Org-mode allows plain lists (itemize, bullet, numbered) of
   arbitrary depth and uses indentation to see the end of items.
   Muse, if I remember correctly, has one level of lists and is
   therefore very relaxed about indentation in lists
- Apart from plain lists, indentation is not syntactically significant
   in Org-mode, it is more visual sugar to make outline easily readable.
   Muse uses indentation for syntax, to quote text, for example.
- Links are similar, but not identical.
- Org-mode table lines also start with "|".  Table headlines are
   implicit, before the first horizontal line in the table.  No
   footer lines.
- etc.....

It can be done, but it is not trivial.

- Carsten

Re: [Emacs-orgmode] Interaction of org-mode and Muse

[Michael Olson]

[-- Attachment #1.1: Type: text/plain, Size: 3153 bytes --]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> Besides the obvious interaction, using the Muse engine to produce
> other export formats, can you think of more ways to interact?

Organization of work into publishable projects comes to mind.

One nice feature of Muse is that you can specify the major mode to
call on files inside of a project.

>> One of the plans for the next release of Muse + 1 (3.04) is to
>> support publishing documents that use other markup syntaxes, such
>> as Markdown and reSt.  Perhaps org-mode syntax could be supported
>> as well.
>
> I have actually been thinking about an org-to-muse converter as a
> possibility for easy expansion to many more export formats.  So I
> have a number of ideas about what would be needed and where the
> difficulties lie.  A short appetizer:
>
> - Headline detection should be trivial, however
> - Org-mode uses (at least: can use) many more levels than the 4
>   available in Muse now.  The Org-mode exporters just switch to
>   itemized lists at some headline level.

Muse can publish headings beyond the 3rd level now.  The only
requirement for the built-in heading publishing function is that
either:

 1. The same markup is used for each level beyond the 3rd, or

 2. The markup for different levels varies only by the number of the
    level.

Even if none of these conditions are met, it's easy to tell Muse to
use a different (custom) function for publishing headings.  I do
something like this with Planner headings, since they have level 1 ==
<h2>, and use some specialized <div> stuff.

> - Org-mode allows plain lists (itemize, bullet, numbered) of
>   arbitrary depth and uses indentation to see the end of items.
>   Muse, if I remember correctly, has one level of lists and is
>   therefore very relaxed about indentation in lists

Muse now supports different levels of lists in its development
version, and that aspect is very stable (if undocumented).  Levels are
based on initial indentation.

> - Apart from plain lists, indentation is not syntactically significant
>   in Org-mode, it is more visual sugar to make outline easily readable.
>   Muse uses indentation for syntax, to quote text, for example.
> - Links are similar, but not identical.
> - Org-mode table lines also start with "|".  Table headlines are
>   implicit, before the first horizontal line in the table.  No
>   footer lines.
> - etc.....

This will indeed involve some fine-tuning of the rules.  It should be
feasible though.

The tricky thing will be to make these rules project-dependent, so
that people have the option of having two projects with different
markup syntaxes.

One way of accomplishing this might be to make the regexps in most
publishing rules to be variables, so that buffer-local values for them
can be set.

-- 
Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/
Interests: Emacs Lisp, text markup, protocols -- Jabber: mwolson_at_hcoop.net
  /` |\ | | | IRC: mwolson on freenode.net: #hcoop, #muse, #PurdueLUG
 |_] | \| |_| Project involvement: Emacs, Muse, Planner, ERC, EMMS

[-- Attachment #1.2: Type: application/pgp-signature, Size: 190 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
emacs-wiki-discuss mailing list
emacs-wiki-discuss@nongnu.org
http://lists.nongnu.org/mailman/listinfo/emacs-wiki-discuss