Hugo vs Nikola - some missing features

[Saša Janiška]

Hello,

Sometime ago Nikola’s emoji plugin became unusable since the site which
was provided emojis went down, I was exploring other possiblities since
in one site we are using emojis a lot…

The only real competitor to Nikola is, imho, Hugo and I’ve discovered
that it curently provides two features which I’d like to see in Nikola.[1]

One feature is emoji plugin itself - in Nikola one cannot use them
elegantly, while Hugo solves it by using the package defining map[2]
between emoji names (as defined by Emoji cheat sheet[3]) and Unicode
characters, so my proposal that something like that would be better
option in the long run…

I tried to use something like:

.. |smile| unicode:: U+1f604

This is smile |smile| emoji.

in Nikola/rst, but, similar to the current emoji plugin, its scope is
onlyas role for restructured text, so probably better option would be to
have it as shortcode?

Another nice option which has recently landed in Hugo is direct support
for using Emacs’ org-mode markup for writing content by using native Go
parser[4] for org-mode. This enables one to have correct org-mode markup
for the whole content - similarly to the case when one uses rst in
Nikola when content’s metadata are valid rst markup.

So, I wonder if something similar could be done when using org-mode with
Nikola?[5]

One option is to use Pandoc for converting orgmode –> rst or org-mode’s
ox-publish mechanism[6]…

The question remains whether rst is still the best markup to be used for
Nikola in order to have content written in valid (rst) markup which is
not ’spoiled’ by front-matter data?[7]


Sincerely,
Gour

Footnotes:
[1] In order to contribute to Hugo, I’d have to learn Go, but I
consider that Python is nicer language to code in and also much more
useful to have in my arsenal considering that several important programs
I use are Python-powered.

[2] https://github.com/kyokomi/emoji/blob/master/emoji_codemap.go

[3] https://www.webpagefx.com/tools/emoji-cheat-sheet/

[4] https://github.com/chaseadamsio/goorgeous

[5] The only python tools related to org-mode which I’ve found is
https://github.com/bjonnh/PyOrgMode, but no idea if it could help for
Nikola & org-mode support?

[6] by using https://github.com/masayuko/ox-nikola

[7] I’m regular Emacs/org-mode user, so ability to use it for my other
writings as well would reduce the need of ’changing gears’ between
several markups…

--
One who works in devotion, who is a pure soul, and who controls
his mind and senses is dear to everyone, and everyone is dear to
him. Though always working, such a man is never entangled.

[Chris Warrick]

On 21 March 2017 at 11:20, Saša Janiška <go...@atmarama.com> wrote:
> Hello,
>
> Sometime ago Nikola’s emoji plugin became unusable since the site which
> was provided emojis went down, I was exploring other possiblities since
> in one site we are using emojis a lot…
>
> The only real competitor to Nikola is, imho, Hugo and I’ve discovered
> that it curently provides two features which I’d like to see in Nikola.[1]

> [1] In order to contribute to Hugo, I’d have to learn Go, but I
> consider that Python is nicer language to code in and also much more
> useful to have in my arsenal considering that several important programs
> I use are Python-powered.

Well, why not contribute to Nikola and write plugins that implement those ideas?

> One feature is emoji plugin itself - in Nikola one cannot use them
> elegantly, while Hugo solves it by using the package defining map[2]
> between emoji names (as defined by Emoji cheat sheet[3]) and Unicode
> characters, so my proposal that something like that would be better
> option in the long run…
>
> I tried to use something like:
>
> .. |smile| unicode:: U+1f604
>
> This is smile |smile| emoji.
>
> in Nikola/rst, but, similar to the current emoji plugin, its scope is
> onlyas role for restructured text, so probably better option would be to
> have it as shortcode?

You can make it a shortcode, a reST directive, or both. Just grab the
map from the Go code you linked, and it will be a pretty trivial
plugin to write (especially if you start with the existing image-based
plugin)

Or alternatively, if your OS supports emoji — and it sounds like yours
does, because you don’t mind using it — you can just use your OS
facilities for inserting real emoji in text:

* Windows: add Touch Keyboard to your taskbar
* macOS: ^⌘Space or enable the menu bar extra in Keyboard preferences

By the way: http://www.lunaryorn.com/posts/bye-bye-emojis-emacs-hates-macos.html

> Another nice option which has recently landed in Hugo is direct support
> for using Emacs’ org-mode markup for writing content by using native Go
> parser[4] for org-mode. This enables one to have correct org-mode markup
> for the whole content - similarly to the case when one uses rst in
> Nikola when content’s metadata are valid rst markup.
>
> So, I wonder if something similar could be done when using org-mode with
> Nikola?[5]
>
> One option is to use Pandoc for converting orgmode –> rst or org-mode’s
> ox-publish mechanism[6]…
>
> The question remains whether rst is still the best markup to be used for
> Nikola in order to have content written in valid (rst) markup which is
> not ’spoiled’ by front-matter data?[7]

The front matter isn’t really reST. It’s random HTML comments, which
happen to start with two periods, because that’s what reST wants for
comments.

As an avid vim user, I have absolutely no idea what org-mode metadata
would look like. However, you can just write a custom read_metadata
method for your org-mode Nikola compiler plugin. However you get the
data out of your org-mode file — pyorgmode, some custom elisp code, a
hand-made sloppy string-based parser — does not matter if you can
produce a Python dict in the end.

Here’s an example: in pkgindex_compiler, metadata may come from the
filesystem, text files, ini files, and there’s even a massive HTML
snippet in post meta.
https://github.com/getnikola/plugins/blob/master/v7/pkgindex_compiler/pkgindex_compiler.py

--
Chris Warrick <https://chriswarrick.com/>
PGP: 5EAAEA16

[Saša Janiška]

Chris Warrick <kwpo...@gmail.com> writes:

> Well, why not contribute to Nikola and write plugins that implement
> those ideas?

Well, have to dive more into language as well as Nikola’s codebase
first…

> You can make it a shortcode, a reST directive, or both. Just grab the
> map from the Go code you linked, and it will be a pretty trivial
> plugin to write (especially if you start with the existing image-based
> plugin)

OK, I’ll try to take a look…shortcode seems to be more interesting since
it should be valid even for non-rst markup, right?

Otoh, I was working hard to convert some non-profit site’s content to
Nikola and after finishing it was frustration to see that the current
Nikola’s emoji plugin is non-functional so one gets things like:

Docutils System Messages

System Message: ERROR/3 (<string>, line 4); backlink
Undefined substitution referenced: “sad”.

> Or alternatively, if your OS supports emoji — and it sounds like yours
> does, because you don’t mind using it — you can just use your OS
> facilities for inserting real emoji in text:
>
> * Windows: add Touch Keyboard to your taskbar
> * macOS: ^⌘Space or enable the menu bar extra in Keyboard preferences
>
> By the way: http://www.lunaryorn.com/posts/bye-bye-emojis-emacs-hates-macos.html

Based on the above link, Linux does not support it, but I’ve no problem
using |smile| in my editor. ;)

> The front matter isn’t really reST. It’s random HTML comments, which
> happen to start with two periods, because that’s what reST wants for
> comments.

Well, it’s reST comment. :-)

> As an avid vim user, I have absolutely no idea what org-mode metadata
> would look like.

See example[1]:

#+TITLE: This is the title of the document
#+AUTHOR: Author
#+EMAIL: maila...@example.com
#+DATE: 2013/12/31 00:00
#+DESCRIPTION: description text
#+KEYWORDS: tag1, tag2
#+OPTIONS: author:nil
#+NIKOLA_TYPE: text

> However, you can just write a custom read_metadata method for your
> org-mode Nikola compiler plugin. However you get the data out of your
> org-mode file — pyorgmode, some custom elisp code, a hand-made sloppy
> string-based parser — does not matter if you can produce a Python dict
> in the end.

That help – thank you!

> Here’s an example: in pkgindex_compiler, metadata may come from the
> filesystem, text files, ini files, and there’s even a massive HTML
> snippet in post meta.
> https://github.com/getnikola/plugins/blob/master/v7/pkgindex_compiler/pkgindex_compiler.py

Thank you, although it’s obvious one has to become somewhat familiar
with the Nikola’s architecture.


Sincerely,
Gour

Footnotes:
[1] https://github.com/masayuko/ox-nikola


--
As the ignorant perform their duties with attachment to results,
the learned may similarly act, but without attachment, for the
sake of leading people on the right path.

[Andy Cowling]

Good news. There is already an excellent orgmode plugin for Nikola which works great. 

https://plugins.getnikola.com/v7/orgmode/

HTH - Andy