all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@posteo.net>
To: c.buhtz@posteo.jp
Cc: Emacs orgmode <Emacs-orgmode@gnu.org>
Subject: Re: Presenting Hyperorg version 0.1.0: The Org to HTML Converter
Date: Sun, 24 Mar 2024 14:40:56 +0000	[thread overview]
Message-ID: <878r27bslj.fsf@localhost> (raw)
In-Reply-To: <9e466e7e9d9de12103df770ace706d21@posteo.de>

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	other threads:[~2024-03-24 14:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-19  9:23 Presenting Hyperorg version 0.1.0: The Org to HTML Converter c.buhtz
2024-03-20 13:09 ` Ihor Radchenko
2024-03-23 13:50   ` c.buhtz
2024-03-23 13:58     ` Ihor Radchenko
2024-03-23 19:45       ` c.buhtz
2024-03-24 13:31         ` Ihor Radchenko
2024-03-24 14:22           ` c.buhtz
2024-03-24 14:40             ` Ihor Radchenko [this message]
2024-03-24 16:59               ` c.buhtz
2024-03-24 18:15                 ` Ihor Radchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878r27bslj.fsf@localhost \
    --to=yantar92@posteo.net \
    --cc=Emacs-orgmode@gnu.org \
    --cc=c.buhtz@posteo.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.