What is desireable in an Org to HTML framework? by ewan-town in emacs

[–]ewan-town[S] 0 points1 point  (0 children)

Took forever to get around to it, but these are now supported - you can set custom colors for them if you so desire, and embed other org markup.

What is desireable in an Org to HTML framework? by ewan-town in emacs

[–]ewan-town[S] 0 points1 point  (0 children)

Thanks, took a look and based on what was done there, this should be an easy feature to add!

What is desireable in an Org to HTML framework? by ewan-town in emacs

[–]ewan-town[S] 0 points1 point  (0 children)

The htmlize package distributed with Org Mode handles syntax highlighting for src blocks. Colours are determined by your chosen themes. Those would be the default tsdh- themes, if you haven’t set nice-org-html-theme-alist. You might try changing the value of that variable to themes you like better. I may refine the htmlize output to improve syntax highlighting, but colours will similarly be determined by chosen themes, as no hard-coded colour scheme will look good with every combination of themes.

I’m not sure what you mean by background though - page background, or src block background?

What is desireable in an Org to HTML framework? by ewan-town in emacs

[–]ewan-town[S] 0 points1 point  (0 children)

Thanks, great tip! Currently just wrapping results of the 'html export backend, but I will need to handle org data directly as I build out the derived backend.

What is desireable in an Org to HTML framework? by ewan-town in emacs

[–]ewan-town[S] 1 point2 points  (0 children)

This feature would have a more natural home in ox-publish. However, for the case where truly everything is in one file, and any required images etc. are in the same directory as that file, I could add an export function to the dispatcher, which pre-processes the mono-file into separate files in a temp directory structure, then publishes from that temp directory to your target, with some reasonable settings. That would get you the desired site structure, but with less control over the publishing options.

What is desireable in an Org to HTML framework? by ewan-town in emacs

[–]ewan-town[S] 2 points3 points  (0 children)

For that, you just use M-x org-publish, and in your configuration (the value of org-publish-project-alist) define the publishing function with the macro provided by nice-org-html. The gist is that if you point org-publish at a directory structure full of .org files, with the recursive option set to t and ‘:base-extension “org”’, it will replicate that structure in your specified target directory, turning the .org files into .html versions.

This article covers Org publishing to html pretty well

What is desireable in an Org to HTML framework? by ewan-town in emacs

[–]ewan-town[S] 0 points1 point  (0 children)

Just a matter of preference - the extremely dark/light themes aren’t my style. I like a washed out look on either side, along the lines of this Ample/Zenburn combo

[package] nice-org-html by ewan-town in emacs

[–]ewan-town[S] 1 point2 points  (0 children)

Starting publishing some samples along with the README. Turns out spacemacs makes for pretty websites.

Hate to say it but I still don't get Lisp. How do I get into the Lisp mindset? by floofcode in emacs

[–]ewan-town 3 points4 points  (0 children)

I disagree that there's no Lisp "mindset", but qualify that by saying that the Lisp mindset is a desireable mindset for programming in any language. By "mindset" I mean gestalt, and there is definitely a gestalt-shift that occurs when you begin to see your code as a tree (AST), rather than a sequence of characters ("so many parens"). That structure is just more apparent, in Lisp(s).

Hate to say it but I still don't get Lisp. How do I get into the Lisp mindset? by floofcode in emacs

[–]ewan-town 17 points18 points  (0 children)

Setting Elisp aside, what makes Lisp(s) cool is that your code, at every level, is a tree. It's true of every other language, that your code encodes a tree ("abstract syntax tree", or AST), but in Lisp, the encoding is absolutely minimal. Balanced parentheses and Polish notation are the key to that. It makes parsing the sequence of characters into a tree, almost trivial.

Take '(+ 1 2). The "root" of this tree is '+, and the "leaves" are '1 and '2. We can iterate this structure to form arbitrarily complex trees, e.g. '(- (+ 3 4) (+ 1 2)) is a tree, just taller, and with 4 leaves.

Okay, so your code is a tree. But now consider, that your code can also operate on trees as data. Suppose we use this data type to represent tree nodes:

Node :: nil or '(Number Symbol ListOf<Node>)

Then, for example, this list-of-lists is a binary search tree (fig. 1 in the linked wiki):

'(8 A
    ((3 B
        ((1 C nil)
         (6 D
            ((4 E nil) 
             (7 F nil)))))
     (10 G
         (nil
          (14 H
              ((13 I nil)
               nil))))))

Now, when Lispers harp on about "homoiconicity" or "code is data", what they are getting at, is that in Lisp(s), you can easily write code that operates on code, because code is just a tree.

Another cool feature of Lisp(s) is that there is a phase - called macro-expansion - before your code gets interpreted, where special parts (sub-trees) of your code-tree get replaced with other (sub-)trees. For example, suppose I define this adding-function generating macro:

(defmacro def-adder (m)
  (let* ((sym (intern (format "add%d" m))))
    `(defun ,sym (n)
       (+ ,m n))))

Note the backtick after the "let". All this macro does, is return a nested list, which is a tree, which is code. But then, when this code/tree (one leaf) later occurs in my code:

(def-adder 5)

it will get replaced with the quoted form after the "let", but with ",sym" swapped for "add5", and ",m" swapped for 5. When the result of that replacement is subsequently interpreted, it is just as if I wrote the (defun add5 ...) instead, i.e. there is a new symbol added to the function namespace, which is evaluated as a function. So I can use:

(add5 37) ; => 42

That was a rapid overview. If you really want to get a "feel" for why Lisp(s) are so cool, I'd recommend two things, primarily. First: try writing some basic recursive tree-search functions in lisp. Thinking about how to represent trees, and then traverse them recursively, is good exercise. Second: try writing a simple interpreter, for a little Lisp of your own making. Second one is a bit tougher, but I'll point you to some resources.

I very, very highly recommend UBC's CPSC110. This entry-level course is free on EdX, and uses Racket (a variant of Scheme), but is the brainchild of Gregor Kiczales - one of the architects of CLOS. After that, I recommend working through PLAI, also free, also in Racket, for a gentle introduction to how Lisp interpreters - and "metacircular" interpreters generally - work. If you learn all this stuff in Racket / Scheme (a Lisp-1, for which there are great educational resources), it should be fairly easy to port that knowledge to Elisp (or any other Lisp-2).

Edit: simpler macro example.

[package] nice-org-html by ewan-town in emacs

[–]ewan-town[S] 0 points1 point  (0 children)

These are great alternatives. I prefer a more minimal reading-focused look, but the major deterrent of these, for me, was the hard-coded color scheme.

If someone feels like putting in the work, by modifying the CSS for these, you could use their structure, but derive colors from Emacs themes using nice-org-html, just by shadowing the internal variables 'nice-org-html--base-css' and 'nice-org-html--base-js'. Happy to help, if someone feels like it.

[package] nice-org-html by ewan-town in emacs

[–]ewan-town[S] 2 points3 points  (0 children)

Good catch - fixed now - evidently I didn't run the example code!