* Daniel Clemente <n142...@gmail.com> wrote: > El Sun, 30 Dec 2012 19:04:25 +0100 Karl Voit va escriure: >> >> I plan to implement a new weblog system that parses Org-mode >> files and generates (static) HTML output. Yes, I am aware that >> there are other solutions out there but I do not like them for >> various reasons.[1] > > Nice! I also don't like existing solutions and I was thinking on > writing some Python to do the export. But the complexities of > exporting are so well resolved in elisp that it's much easier to > invoke elisp code than to write your own in Python.
Sorry, I can not use the fabulous elisp because it would take me to develop my blog SW for years - I'd have to learn elisp from scratch. Surely, an elisp primer should not try to write something like a web log as his first elisp project. >> So for my new system, I am thinking of using Org-mode files for >> writing (and parsing) the user-defined preferences. > > I happened to be thinking the same two days ago. >> - In Python I have to parse a basic sub-set of Org-mode format >> anyhow. An additional parser would be more work to do. > > Don't do it from scratch; there are already some parsers which > work. I tried: https://github.com/bjonnh/PyOrgMode I did not start to evaluate current Org-parsers in Python but I am very sceptic that I will be able to use such a parser. I plan to do many "intelligent" transformations on the parser level such as "id:heading42" -> "http://my.bog.com/YYYY/MM/DD/articleofheading42.html" and so forth. But we'll see. >> - Possible methods to store configuration/settings of a weblog system >> that scans Org-mode files to generate HTML: >> - in drawers: see below >> - in tables: see below >> - in tags: see below >> - other possibilities? > From the ones you say, I prefer property drawers. It's the most > DB-like and it's analogous to storing data (well, strings). > You don't need all the table benefits (reordering, exporting, > formatting, formulae, …). Nor the tags benefits (search, > multiple tags, …) Ack. >> My focus is user friendly maintenance and overview including >> in-line documentation of the preferences. > > Of course, storing configuration in .org is very utopic (being > all .org), but I would prefer *not* to do it. I would use a > simple ~/.file.conf with some variables in the usual style: > # a comment > path=~/web/ > # where to export images > images=~/web/images OK, the usual INI format. I've done this a couple of times already. > I think this wins for usability and „friendly maintenance“, > since people know it and it works. And it allows you to define > many projects (e.g. check the configuration file for the program > unison). I wanted to check, whether there is something in the idea of using the same Org format for configuration as well. So far I tend to use INI once more. > But I think it's more important to center efforts in developing > a good exporter web publisher. As you said, the current ones are > not powerful enough. Sorry, there seems to be a misunderstanding. My exporter will be a *very basic one*. At least for the first versions. The issues that drove me to plan my own new blog system are related to completely other areas. If you want to have a "good Org to HTML engine", you definitely don't want to use my future blogging system. -- Karl Voit