crowd Tecnical Report

The following snippets creates a white background for inline images. The color can be "customized" using M-x customize-variable org-inline-image-background.

;; Background color in inlines images
(defcustom org-inline-image-background "white"
  "The color used as the default background for inline images.
  When nil, use the default face background."
  :group 'org
  :type '(choice color (const nil)))

(defun org-display-inline-images--with-color-theme-background-color (args)
  "Specify background color of Org-mode inline image through modify `ARGS'."
  (let* ((file (car args))
         (type (cadr args))
         (data-p (caddr args))
         (props (cdddr args)))
    ;; get this return result style from `create-image'
    (append (list file type data-p)
            (list :background org-inline-image-background)
            props)))

(advice-add 'create-image :filter-args
            #'org-display-inline-images--with-color-theme-background-color)

Sometimes Org-ref doesn't work properly if not loaded explicity. This creates issues when exporting to LaTeX and HTML. This line of code ensure that the library is loaded.

(require 'org-ref)

Org-mode won't execute LaTeX or any other language source block code by default. Then, if not enabled, all results cannot be exported nor displayed in the buffer.

This snippet enable R, Python, Prolog, Ruby and LaTeX languages for executing and retrieving its results. However Org-mode asks for confirmation when org-confirm-babel-evaluate variable is true (t).

;; Enable org-babel languages
(setq org-confirm-babel-evaluate t)

(org-babel-do-load-languages
 'org-babel-load-languages
 '((emacs-lisp . t)
   (R . t)
   (python . t)
   (prolog . t)
   (ruby . t)
   (latex . t))
 )

It is possible to avoid confirmation for specific languages. For example, the following snippet only evaluates ditaa source blocks without confirmation.

(defun my-org-confirm-babel-evaluate (lang body)
  (not (string= lang "ditaa")))  ; don't ask for ditaa
(setq org-confirm-babel-evaluate 'my-org-confirm-babel-evaluate)

(org-babel-do-load-languages
 'org-babel-load-languages
 '((emacs-lisp . t)
   (ditaa . t)
   (R . t)
   (python . t)
   (prolog . t)
   (ruby . t)
   (latex . t))
 )

More information is available at the Org-mode info, section "Code evaluation and security issues". If you're using org-mode, you can access directly the info through this link.

Using the ox-twbs package created by marsmining, Org-mode can export the content into an HTML page with bootstrap JS support.

The package can be installed by browsing with M-x package-list-package or by following the instructions in its README.org file.

Downloads and more information are available at its repository at the following URL: https://github.com/marsmining/ox-twbs

The test development cycle we use is depicted in Figure fig:test-cycle and consist in the following steps:

1. We propose a new feature idea to be included in crowd.
2. First, we write tests about the feature we want to implement. The tests represents the expected results and usage of the module or modules should have.
3. We implement the feature trying to follow the tests.
4. Then, we run the units tests for that feature. If every tests are green, we ignore the next step.
5. If some tests don't pass, a fix is needed in the code recently implemented. It can happen that the tests we designed needs fixing too, because the goal or usage of the implemented feature changed.
6. Run other tests ensuring that nothing else in the system has been broken. If all tests are green, we ignore the next step.
7. Fix the broken code. This happens when the module needs to modify or add code in already developed modules. If that happens, tests may also needs to be fixed.

For more information about Test Driven Development (TDD) consult TDD2012.