emacs-orgmode
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Presenting Hyperorg version 0.1.0: The Org to HTML Converter

From: Ihor Radchenko
Subject: Re: Presenting Hyperorg version 0.1.0: The Org to HTML Converter
Date: Sun, 24 Mar 2024 14:40:56 +0000 
c.buhtz@posteo.jp writes:

> Am 24.03.2024 14:31 schrieb Ihor Radchenko:
>> Hmm. I thought that you implemented Org parser in python from scratch.
>> Now, I see that you are using orgparse.
>
> The orgparse package do not parse much of on org file. IT does parse the 
> meta infos (property drawers, etc) but not the content of an orgfile. In 
> the long run I might replay orgparse to reduce dependencies.
>
> Beside orgparse yes I implement an org parser.

Thanks for the  clarification.
If it is an option, it would be nice if you upstreamed your additions to
orgparse. This way, we can get a better Python-based Org parser for
everyone's benefit.

>> Wondering what you are referring to when mentioning "resilient when
>> dealing with parser issues".
>
> Orgparse do throw exceptions e.g. UnicodeDecodeError or when timestamps 
> are invalid. Hyperorg catch that exceptions and go on with the next node 
> without interrupting the whole process.

I see. FYI, it is a bug to throw an error when parsing Org document. Any
kind of text file is a valid Org document. There is no notion of invalid
syntax in Org markup.

> Other things are "invalid" links, e.g. unknown orgids, unknown roam 
> links, unsupported "link kinds" ("protocols" in org syntax?; e.g. 
> "inkscape:").

In Org terminology, we call these "broken" links.
"link kinds" are link "types".

> Additionally there are multiple fancy but not supported org features 
> (e.g. tables) currently not supported. Hyperorg shouldn't stop or crash 
> at this point.

Do you mean that orgparse throws an error when encountering tables?
If so, it is slightly odd to see this implementation detail listed in
"Benefits".

Generally, part of the "Benefits" section is a bit hand-wavy. I
recommend using more clear statements. Otherwise, it is not clear what
exactly the benefits are.

I'd suggest the following:

1. Drop "Fairly resilient when dealing with parser issues."
2. Reword "Fairly resilient managing dead and problematic links which
are a common phenomenon when working with a constantly evolving
Zettelkasten or personal wiki." And instead clearly explain how broken
links are exported.
3. Supply "Generates a comprehensive index of all nodes." with a
   screenshot
4. Drop "Adhers to World Wide Web Consortium (W3C) standards for HTML5
   and CSS (<!DOCTYPE html>)." Most other blog exporters for Org mode
   adhere to standards. And those that are not are probably out of
   interest for the purposes of comparison.
5. Maybe mention the "tag cloud" visible in the example screenshot (btw,
   the screenshot is not very sexy; compare it with something like
   https://one.tonyaldon.com/).

>> index can be produced with minimal configuration via ox-publish.
>
> "minimal" is a subjective term here. Again I don't blame the tools or 
> the Emacs universe.
> But for me it is not even minimal to get ox-publish run in the first 
> place. Not speaking about further modifications, e.g. an index.

Clear.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
reply via email to
[Prev in Thread] Current Thread [Next in Thread]