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 18:15:28 +0000 [thread overview]
Message-ID: <87v85ba43j.fsf@localhost> (raw)
In-Reply-To: <4V2j2p2Pf9z9rxS@submission02.posteo.de>
<c.buhtz@posteo.jp> writes:
> I will consider your points and take them into account.
Thanks!
> On 2024-03-24 14:40 Ihor Radchenko <yantar92@posteo.net> wrote:
>> 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.
>
> The code is free. The orgparse maintainer is free to re-use it of
> course. On the other hand in the long run I will consider to separate
> my parsing code into an extra package. But currently it is to unstable
> and do support only a small subset of all org(roam) features.
It would help if you notify orgparse maintainer once your code gets more
stable ;)
>> 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.
>
> You mean throw an error is a bug because it is not possible to
> write invalid org documents?
Yup.
> I am not convinced yet. But I am open to it and willing to learn.
>
> Even org-html-export* itself do throw errors and stop processing when
> there are unknown orgids.
This has nothing to do with the parser.
Erring on unknown ids/paths is a special _feature_ of Org exporter
controlled by `org-export-with-broken-links' variable.
`org-export-with-broken-links' is nil by default simply because (1) Org
export has no sensible way to export links that point to nowhere; (2)
Such links are generally unwanted and need to be corrected by the user
in many use cases.
> What is about an inconsistent block?
>
> #begin_src
> foobar
> #end_example
With your example, the following AST will be produced by Org parser
(`org-element-parse-buffer'):
(org-data
(section
(paragraph
"#+begin" (subscript "src")
"\nfoobar\n#+end" (subscript "example")
"\n"))
>> > 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".
>
> The term "types" is to broad and conflicts with Pythons in build
> functions. ;) That is the main reason why I used "kind". On the other
> hand the org syntax reference IMHO also use the term "protocol".
Syntax reference says the following:
PROTOCOL
A string which is one of the link type strings in org-link-parameters
^^^^^^^^^
We also always say "link type" in the manual.
I just made things more explicit, replacing PROTOCOL with LINKTYPE:
https://git.sr.ht/~bzg/worg/commit/0634eed3
>> 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.
>
> Again. It is also not "clear" for me. There are benefits just for
> myself as an low-level-Emacs-and-org-user, someone who get headaches
> reading Lisp code and feeling very comfortable using Python. In short:
> My opinion is very subjective. And I don't have enough experience to
> compare my tool to others.
> I tried to make this point clear in my benefits section. And this is
> also the reason why there was no benefits section in the first place
> because I wasn't clear enough about what to write in there.
>
> Maybe I should rephrase the section to "Benefits and design goals".
Maybe something like "Motivation"; to emphasize that the listed points
are your subjective reasons to write the exporter.
Still, it would be useful to have an objective comparison; if you want
to get others to use your package. Having a clear list of reasons why
your package is better is important then. (I implicitly assumed that you
are interested to attract users after you announced the package in
public)
>> 1. Drop "Fairly resilient when dealing with parser issues."
>
> Why? The "design goal" is to process all nodes no matter how
> bad/invalid they are.
Simply because Org mode has no notion of invalid nodes.
So, this kind of goal sounds very strange for me.
>> 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.
>
> I don't want to blow up the text. Not sure what you expect here. The
> node is exported as HTML but the link is colorful highlighted and a
> tooltip explaining the problem is added.
Is it something akin when `org-export-with-broken-links' is set to 'mark?
>> 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.
>
> Why?
If Org export does not adhere to standards, it is a bug, it should, and
it will be fixed. And some other blog generators that do not use Org
export (like Hugo) do conform to the standards, AFAIK.
> Btw: Even code generated by org-html-export* (XHTML 1.0 Strict) give
> errors on W3C. e.g. "type" attribute is missing in <style> tag.
May you please provide an example? I cannot reproduce.
>> 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/).
>
> There nothing fancy as a "tag cloud". ;) btw: There is no cloud on the
> link you provided.
I was referring to top line listing tags.
> About the "sexy"ness of Hyperorg output: There is a specific label for
> that issues:
>
> <https://codeberg.org/buhtz/hyperorg/issues?labels=180551>
>
> But as you can see on the "milestone" the priority is low.
Fair. Do note that "sexyness" is what attracts users :)
--
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>
prev parent reply other threads:[~2024-03-24 18:16 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
2024-03-24 16:59 ` c.buhtz
2024-03-24 18:15 ` Ihor Radchenko [this message]
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
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87v85ba43j.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 public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).