Sunset on dutch beach

This post is the result of a little hike along one of the Long Distance walks in the Netherlands: "LAW 05-2 (04) Katwijk aan Zee - de Zilk", part 4 of "Nederlands Kustpad"
I recorded the hike with my Suunto Traverse watch and exported this as a GPX file. I used that gpx file as example data to create a little gpx viewer which can be embeded in html pages. With Leaflet this is almost trivial to do.
The details of the hike are on my Movescount page for this move.
If you zoom in on the map, you'll see that the recorded path is not an exact match with the followed path (the dotted lines). This is because I used a long interval of GPS fixes to record the path. I think it was a 10 second interval, so there's some tuning to do for this in future.
The exported GPX has information about temperature, height, energy, speed and possibly some other stuff. My intention is to have this information incorporated in the map later on, similar to the way this is displayed on the movescount site.
If you're interested, the GPX file is here:
In Working with Jekyll and Org-Mode a simple solution was given to use org-mode format files as posts.
That solution had quite a few limitations:
---
' yaml header to be present on the
first lines, making it invalid org-mode documents#+key: value
syntax of org-mode was not used for settings, or at
least only partiallyWhat follows are some notes on how I solved the issues.
---
' requirement
Jekyll uses the '---
' header to determine which files need to be
processed. If such a header is not present, the file is either copied
verbatim or ignored, depending on the settings. Having this header in
an org-mode file makes it somewhat invalid. Not a bit deal, but luckily
it's rather easy to get rid of.
The function in standard Jekyll that determines this is
has_yaml_header
so by extending that function we can make sure
org-mode files are treated to be processed like there was a header.
1 module Utils
2 def has_yaml_header?(file)
3 !!((File.open(file, 'rb') { |f| f.read(2) } =~ /^#\+/) or
4 (File.open(file, 'rb') { |f| f.read(5) } =~ /\A---\r?\n/))
5 end
6 end
The check is just for the file to start with #+
which is enough for
me, for now.
Getting rid of the '---
'–marker is one thing, but between those
markers are settings which are relevant for the document. At least
title, tags and layout are usually present in the header. With the
yaml-header gone we need a way to register those variables in some
org-mode syntax.
The standard org-mode key/value pairs as mentioned above are suitable for that. The method is implemented statically in the OrgConverter class:
1 def self.process_options(content, data)
2 org_text = Orgmode::Parser.new(content, {markup_file: "html.tags.yml" })
3
4 org_text.in_buffer_settings.each_pair do |key, value|
5 # We need true/false as booleans, not string.
6 if key.downcase == 'published' #(any others?)
7 value = value.to_b
8 end
9 data[key.downcase] = value
10 end
11 data
12 end
The implementation is not very elegant, but it registers all org-mode
buffer settings as values. An exception must be coded for values which
must be boolean. (I use only the published
property, but there may be more)
Here's where things get a bit hairy. Formally, when writing content which requires a liquid construct, it should be enclosed in the proper org-mode block delimiters, something like:
#+BEGIN_HTML {%raw%}{% liquid construct here %}{%endraw%} #+END_HTML
such that the whole document is a normal org-mode document. As my
current documents do not have the 'BEGIN_HTML/END_HTML
' delimiters
this would be annoying to change (again). So, the first thing I tried
is to implement it to avoid all that changing again. That worked, a
fully working implementation is at commit cc2081
However, there are significant issues with this:
After realizing this, I started over and just coded the convert method as:
1 def convert(content)
2 org_text = Orgmode::Parser.new(content, {markup_file: "html.tags.yml" })
3 org_text.in_buffer_settings.delete("TITLE") # We already captured the title on processing the options
4 org_text.to_html
5 end
Given I made the change to all my orgmode files as mentioned above,
which is not that much work with emacs' dired-do-query-replace-regexp
command,
the conversion is complete. The only thing to make sure is that for
each type of source file (post, page, document) the header options are
processed with the process_options
function above.
You can view the end result in commit 40dad2
Many people in the Emacs community use orgmode. Quite a few of them
use the org-babel
system to write and maintain their emacs
configuration, and so am I. I find the biggest advantage to be able to
document my thought process as well as the configuration
details. Emacs configuration can get pretty big and maintaining it
becomes a lot easier for me if I can read back what I was thinking 6
months ago.
The system borrows from literate programming concepts where you write code and documentation in one document and let tools tangle the code and documentation into separate documents.
{%pullquote right %} The default way to publish an Emacs configuration with that system would be to let org-mode export the configuration document to html and publish that somewhere. What I wanted to do was to use the in-place org-mode converter I am using with Jekyll. In short, {"the ideal would be that jekyll fetches the authoritative version of my emacs configuration in org-mode syntax"} and treats that as normal content and publish it. {% endpullquote %}
I started off by defining a collection, a new feature of jekyll, which
gave me a chance to use it. The collection is defined in the
_config.yml
file:
1 # Emacs collection contains emacs 'generated' documents
2 collections:
3 emacs:
4 # Render them, i.e. convert them to html.
5 output: true
This will render source files in the _emacs
folder as if they were
pages. The url generated for them will be prefixed by /emacs/
.
In this folder I placed a file config.org
with the following
contents
1---
2layout: orgmode
3---
4
5[... text left out ..]
6
7{% raw %}
8{% include extern/mrb.org %}
9{% endraw %}
That includes the file <root>/_includes/extern/mrb.org
from the
jekyll installation and renders its content. The only correction I had
to make was to insert a raw...endraw
block around some org-mode
settings.
You can view the result of the rendering in /emacs/config/