Skip to main content

Nikola plugin for kramdown

I’m not surprised that markdown has become so successful and ubiquitous. But one of the things I think it lacks is syntax for creating tables.

For this reason, I have been using a txt2tags plugin for a while. My sites all have a lot of tabular data, both as a function of the nature of the sites and also because I just like tables.

But I recently discovered kramdown.

kramdown has a super-set of markdown syntax, including simple, but powerful table-creation syntax.

So I’ve written a plugin for Nikola along the lines of the txt2tags plugin to compile HTML posts and pages from kramdown files. For which I have started using the .kd extension.

This post is written in kramdown.

So this post is somewhat by way of a test of my kramdown plugin for Nikola.

Third-level Heading

The above heading is marked with two hash characters and in the same way that markdown posts have their heading demoted by one level I have done the same with kramdown.

Here is a table of silly data:

Date Weather Activity
01-Feb-2016 Rain Stayed in
02-Feb-2016 Dry and cloudy Stayed in again
03-Feb-2016 Cold, -4C Had to go out for most of the day
04-Feb-2016 Even colder than yesterday Stayed in and wrote a kramdown plugin for Nikola


Lists are the same as in markdown

  • unordered list item one
  • Unordered list item two


The links in the above text are all done like references are done in markdown, with the actual URI of each link at the bottom of the text file. Editor Totally Inaccessible

I've just tried the editor.

I did this because there was to be a talk about it at the Portsmouth LUG, which I went to last Saturday.

It's totally inaccessible on Linux, Debian with the Mate desktop.

Apparently it is an editor written in Javascript and, if I have this correct, it renders the screen with the Chrome browser, or sub-system. There's also something called node.js involved.

These are technologies I know little about, except that it doesn't make a sound with Orca.

So there's another editor we can't use.

Back to good old Emacs.

Transmission Command-line Bit-torrent Programs

I was after a method of downloading and seeding bit-torrents exclusively from the command-line.

I tried aria2 but found it unreliable. I don't know if it was because I was doing something wrong but none of the torrent files I downloaded were not corrupted in some way.

And anyway I wanted something to run in the background.

I tried transmission-cli. Better results but again this was not something that just ran in the background.

So I installed a pair of related programs: transmission-daemon and transmission-remote.

The Daemon part of this program is exactly that, a daemon that runs, as all daemons do, in the background.

And the Remote part is a command-line program to control it.

The remote part is included in the transmission-cli package.


$ sudo apt-get install transmission-daemon transmission-cli

Will install them both on Debian or Debian derivatives. Although why you're running a derivative when you could run Debian I don't know.

The default installation of transmission-daemon is configured for the user it runs to be set to transmission and the password is also set to transmission.

And by default it is only possible to access the daemon and the management web page from the local machine (localhost).

This led to a tedious situation, any command entered to make transmission-remote do anything with the daemon meant this was the command-line:

$ transmission-remote localhost --auth transmission:transmission <command>

I don't want to have to type that in every time.

So I set up an alias in .bash_aliases:

alias trem='transmission-remote localhost --auth transmission:transmission'

Now I can just type:

$ trem <command>

For example, to add a torrent:

$ trem --add <torrent>

To list all the current torrents and their status:

$ trem --list

To remove and delete a torrent:

$ trem -tN --remove-and-delete

(where N is the number in the list returned by the --list command).

To start a torrent:

$ trem -tN --start

And to stop one:

trem -tN --stop

There are loads of other commands but these are the ones I use the most, and mostly --add and --list.

Note also that transmission will handle the magnet links found on the Pirate Bay download site.

Capturing Regions of the Screen

Here are some nice keystrokes that work in Debian, and probably other distros as well as these are essentially Gnome actions:

  • PrintScreen -- Takes a screenshot of your entire desktop and saves it to the Desktop folder
  • Alt + PrintScreen -- Saves a screenshot of the focused window to the Desktop Folder
  • Shift + PrintScreen -- Lets you select an area of the screen, and saves to the Desktop Folder
  • Ctrl + PrintScreen -- Takes a screenshot of your entire desktop and copies it to the clipboard
  • Ctrl + Alt + PrintScreen -- copies a screenshot of the focused window to the clipboard
  • Ctrl + Shift + PrintScreen -- Lets you select an area of the screen, and copies it to the clipboard
  • Ctrl + Shift + Alt + R -- Records a Screencast) of your entire desktop and saves it to your Videos folder

The 'Desktop' folder may be different on other flavours, like 'Pictures' on Fedora.

The commands which allow selection of an area are not much use when you can't see but the others are nice. I particularly like the idea of a screen-cast.

Thanks to the guys on the Surrey Linux User Group email list for these.

More about WYSIWG GUI Designers and VI Programming

I've not always been blind.

For about twenty years I was a programmer, with a varying level of visual impairment.

Before I lost my sight very quickly in 2008 I had a level of sight which was the same for a long time, although it was gradually decreasing.

What this meant to me as a programmer in the early days of MS Windows was:

  • Keeping track of the mouse-pointer on the screen was tiring and not always easy
  • Using Windows graphical IDEs to design forms was hence not always comfortable for long periods
  • It was easier for me to rough-out a form, for example in MS Access with the IDE and then tweak the code with a text editor

For years I used QEdit, which was a very lovely text editor for MSDOS. I miss it.

Actually losing my sight totally, which made it necessary to embrace the use of a screen-reader made things a bit easier in some ways, and flipped things around a bit:

  • Now using the GUI on either MS Windows or Linux was easier, assuming the applications used are accessible

But, now using a drag-and-drop GUI designer was no longer possible, or at least not easy.

GUI Programming using Absolute Positioning

I used to write applications for MS Windows in vanilla C, using the native Win32 API calls.

That involved either generating controls with calls to CreateWindow and it's variants or by using resource (.rc files).

That made programming once I lost my sight difficult because:

  • I could no longer tell if my controls were all lined up correctly vertically and horizontally
  • My head was spinning with arithmetic every time I tried to size and position one control relative to the previous/next one

This approach, using absolute positioning also falls down when another user is not using the same sized font as you, or when the user clicks and drags the corner of your window to resize it. The formatting goes all to pot and looks like a dog's breakfast.

But more recent development tools have started using sizers.

In the sizer approach, controls are added to a kind of invisible net which controls the positioning.

Visualise it like this:

  1. There is a clear flat surface in front of you
  2. You need to place objects on that surface ina controlled way
  3. Imagine an invisible shield which is floating a couple of inches above the surface
  4. Cut into that shield are a number of holes through which you can place the objects on the surface
  5. When the objects are placed, changing the size of the surface will cause the invisible shield to change size as well and the objects will move and resize in a known and predictable way

I know of several GUI toolkits and languages that do this:

  • GTK, on Linux, and (I think) Windows and Mac
  • wxWidgets, multi-platform
  • wx.Python, multi platform
  • Java, multi platform

Varieties of sizer

Each of these tools has a variety of sizer types. Here is a by-no-means exhaustive list of them and a description of each:

Box Sizer

In either horizontal or vertical variants. Controls added either stack across (horizontal) or down/up (vertical).

Grid Sizer

A number of variants exist but essentially an X and Y grid of cells which are filled with controls by specifying their coordinates.

Sizers within Sizers

It is possible to add a sizer to another sizer to create complex GUIs.

For example if your form had a horizontal box sizer into which you have placed two vertical box sizer sizers, you will get left and right vertical sizers.

I know this explanation sounds complex but it really not.

One thing to remember is that the parent of a control is NOT the sizer into which it is placed but the object, usually termed something like panel, to which the sizer containing the control is added.

Using these sizer objects to position controls you will get:

  • A window which handles resizing and font changes correctly
  • A much easier life with no absolute-positioning headaches like arithmetic-overload

Sizers usually have some properties which control the way controls placed upon them will expand, contract and position themselves when the window is stretched or shrunken.

I still don't find WYSIWYG/drag-and-drop form designers very easy, or even possible to use, being totally blind, but the sizer approach has given me back a way to write complex and visually pleasing applications even though I can't see.

And of course the sighted authors of drag-and-drop IDEs tend to either just ignore accessibility, or assume that using them when you can't see is impossible. So keyboard shortcuts may not be included.

My personal favourite toolkit at the moment is wxWidgets, which is giving me a way to teach myself C++. Previously I stuck to C like a limpet.

I have yet to get to grips with:

  • GTK programming in C
  • Qt

Talking of Qt I believe accessibility is improved in version 5. It's been getting better and better. And now my C++ is coming on apace I will take a look at it.

All this is very exciting for the visually impaired programmer in a world where it is not as acceptable any more for an application to only run on one platform.

wxWidgets Accessibility

For a while now I've been writing wx.Python and wxWidgets applications for MS Windows.

But I've always assumed both to be inaccessible on Linux/GTK. In fact that was the response from one of the regular contributors on the Orca mailing list.

But I think there must have been some advance in versions or something because in the last couple of days I have:

  • Written a Hello World! application for Linux in `wx.Python
  • Written the same for Linux using wxWidgets (in C++)

And they are both totally accessible!

OK that's probably a rash statement because the apps I wrote did not have every kind of wxWidgets control. But buttons, message boxes, menus and static labels are all spoken by Orca.

My wxWidgets Hello World! program did have all the above.

So, now I'm on a mission to try out as many of the other native GTK controls as I can, or at least all those which are obviously not irrelevant to blind folks, like bitmaps and stuff.

The versions I am running are:

  • wxWidgets version 3.0
  • GTK 3.0

I don't know about the wx.Python version but it's what is in the Debian Jessie repo so it is probably quite up-to-date at the time of writing.

Next mission, given good results with more controls is to write a tree-based GUI designer, because being a blind programmer, drag-and-drop WYSIWYG GUI designers are not really of any use.

Emacs/Emacspeak Initialization Strategy

This afternoon I have changed the way my emacs and emacspeak initialization works.

Until now I have always used the file:


For my initialization. But today, in reading about how emacs initialization and library-loading works, to try to understand how T.V. Raman does it and how his files in the git repository all hang together, I have made a discovery which has made me understand things a lot better and change my strategy.

Initialization Files

emacs will look for any of these files for it's initialization:

  • ~/.emacs
  • ~/.emacs.el
  • ~/.emacs.d/init.el

So, I changed from using ~/.emacs to ~/.emacs.d/init.el.

Not only that but I have made some other discoveries, things which I did not know about before.

In our .emacs files we have usually had two blocks of lisp that begin with:

  • (custom-set-variables ...
  • (custom-set-faces ...

These two blocks of code are places into which changes are made when the emacs customization screens are used to make adjustments, hence the commentary in these blocks which warn about editing them by hand and not having more than one occurrence of each block.

Now, of course when adding stuff to the emacs initialization files by hand it is very easy to screw something up and stop the initialization from working.

When running emacspeak this is always immediately obvious because it comes up talking very, very slowly. Assuming of course you have emacspeak configured to talk more quickly than the default.

It is possible, it seems, to place the custom-set-variables and custom-set-faces code blocks into a separate file, name it as the custom file and then load it from the main initialization file.

So, bearing in mind we are now using ~/.emacs.d/init.el as our initialization file, place these two lines at the top of it:

(setq custom-file "~/.emacs.d/custom.el")
(load custom-file)

The first of these lines instructs emacs that we want to use a different file from our main initialization file for custom changes made by the emacs customization mechanism.

The second line instructs emacs to load it.

Now we can merrily add other stuff to ~/.emacs.d/init.el, knowing that we are at no risk of messing up those customizations added with the emacs mechanism.

Loading Personal Libraries

Instead of loading everything we want in our initialization file, we can split it up, and make it much more modular. In this way we can tinker with something new, and when something breaks, we know more easily what broke it and probably how to fix it.

The first thing we need to do, again in our shiny new ~/.emacs.d/init.el file, is to add some paths to the load-path variable in emacs. It is this variable which acts a bit like the $PATH environment variable in the bash shell.

Put this fragment of code in your ~/.emacs.d/init.el file, just underneath the top two lines which specify and load the custom file:

;; add some paths to load-path
(let ((default-directory "~/.emacs.d/lisp/"))(setq load-path
(let ((load-path (copy-sequence load-path))) ;; Shadow
(copy-sequence (normal-top-level-add-to-load-path '(".")))

This will add:


And all of the sub-directories thereof to the load-path variable. Well, not ALL the sub-directories. It will ignore things like version-control related paths, sub-directory names that start with a dot etc., very useful if you want to put your initialization stuff in git or CVS.

Now we can add a whole bunch of load-library directives below this to load individual personal libraries of lisp code:

(load-library "elpa-prepare.el")
(load-library "markdown-prepare")
(load-library "rst-prepare.el")
(load-library "abbrev-prepare")
(load-library "c-code-folding-prepare.el")

These are just a few libraries I have created from splitting off the code which I previously used to have in my ~/.emacs file.

It should be obvious from the names what each library is for.

What was left in ~/.emacs?

There were a few lines of code remaining in my original ~/.emacs file which I left in the new initialization file:

(setq-default truncate-lines t)
(setq inhibit-splash-screen t)

Before I did this work today it was very hard to wade through all of the custom stuff, the markdown initialization code, the rst initialization code, and find these lines.


By doing this stuff this afternoon I think I have:

  • Split my original emacs initialization file into multiple library files which I load individually
  • Split my manually added initialization code from the code added and changed by the Emacs customization mechanism, which should make identifying errors easier
  • Dramatically increased the modularity of my initializations, making it more scalable
  • Made tinkering with emacs configuration less scary and hence more inclined to get done
  • Learned some valuable stuff about Emacs and Emacs Lisp

Note About load-library and .elc Files

By adding the path to our personal-libraries to the load-path variable we can leave out the .el extension of our libraries.

If byte-compiled versions of any of our libraries exist in .elc files, these will be loaded in preference to .el files, giving us an appreciable speed advantage.

To batch compile all the .el files in ~/.emacs.d/lisp:

emacs -batch -f batch-byte-compile *.el

The above will create .elc versions of each of the .el files. These will be the files which are loaded in preference to the .el files.