search

kanru / alienpress

Yet another blog compiler written in Common Lisp
1 stars 0 forks source link

Good idea! #1

Open arademaker opened 12 years ago

arademaker commented 12 years ago

I am dreaming with a CL implementation of jekyll, is that what you planned? Would you like to share some ideas? I really enjoy jekyll but doesn't want to learn Ruby! ;-)

Best, Alexandre

kanru commented 12 years ago

Yeah, the idea is to build a framework like octopress, which uses jekyll. But I only have experiences from ikiwiki so the basic flow will like ikiwiki in the beginning. I also like the route and filter idea from nanoc so I might add that too.

It will use cl-markdown as the markup language, cl-mustache as the template engine. So some cleanup of cl-markdown is also planned.

Feel free to share your ideas too :)

arademaker commented 12 years ago

Hum.. I don't know ikiwiki. Regarding the objective to construct something like octopuses, I would suggest start with something simple! Jekyll seems to have a very simple semantics (https://github.com/mojombo/jekyll/wiki/Usage). The idea is to walk throw a directory, keeping track of the metadata, apply templates and transformations. The two main data structures seems to be a list of pages and posts. I really enjoy the simplicity of Jekyll architecture. octopuses's features would be a nice second step, don't you think?

It would be nice to have something completely compatible with Jekyll. It would help to make the tool popular. The idea is to have something that would be easier to extend, comparable with Jekyll plugins but compatible with Jekyll. Anyone with a jekyll prepared site could run the cl-jekyll (my first idea of name) in the files and produce the same site. Of course, for accomplish that, we would need to use external tools for taking care of whatever we can't find lisp libraries. A tool like that could motivate the CL community to develop more libraries or improve the already available libraries.

nanoc is nice tool too althouth I haven't had a chance to test it. The two sites that I maintain using Jekyll are: http://emap.fgv.br/ and http://arademaker.github.com/. It would be interesting to take a deeper look into nanoc. The only thing that I don't like so much is the command line approach versus file approach. That is, in nanoc, one has to create the pages using a command, right? Is it a shortcut or a necessity to register new items? In Jekyll, everything are only files.. You edit them, you save and run jekyll. But I can't say anything more about nanoc, I really would like to have more time to compare nanoc and jekyll before start a new one.

the moost annoying Jekyll limitations that I am currently facing:

  1. Include directive can't handle parameters.
  2. The construction of archive of posts should be simpler! I like the Jekyll plugin system (https://github.com/mojombo/jekyll/wiki/Plugins) but the generations should be simpler to write!! The paginator is also not so intuitive.. But maybe this is not a Jekyll issue, this is my limitation in writing Ruby code.
  3. it would be nice to have a easier way to handle internal links (cross-reference) avoiding broken internal links.
  4. It would be nice to generalize the _post directory idea. These directories could act as a containers to dynamic data, not only posts that eventually are transformed to pages.

Best, Alexandre

kanru commented 12 years ago

I've never used octopress or jekyll so I can't comment. But from what I read from their website, octopress is like a pre-configured jekyll engine, and jekyll is very similar to ikiwiki and nanoc. They all use static files as backend and can apply filters to the source and output the final html. Ikiwiki has one-to-one mapping between source files and output files, so the generated site will use same the directory structure of the sources.

I have some ideas in mind:

  1. The engine should support various source formats, like markdown, markup, rst. But the source formats should support extensions, so that I can implement extensions/plugins on top of that. The engine should provide a extension proxy layer that can be plugged into supported format engine.
  2. It will have a inline directive like the ikiwiki one http://ikiwiki.info/ikiwiki/directive/inline/
  3. Source files will not be limited to text files.
  4. Extendable hooks at each stage and programmable layout process.
  5. Interfaces to query site metadata.

But the first milestone is to be able to rebuild my ikiwiki generated blog ;-)