From: chris <firstname.lastname@example.org>
Subject: Re: ox-publish: Some starting problems
Date: Fri, 11 Mar 2022 20:21:12 +0100 [thread overview]
Message-ID: <5552297.DvuYhMxLoT@pluto> (raw)
[-- Attachment #1: Type: text/plain, Size: 3634 bytes --]
I've received the following in my personal email box, and I think it is related to this thread,
so I paste it here:
On Thursday, 10 March 2022 06:54:22 CET email@example.com wrote:
> Hello together,
> I do not understand all details. But it seems to me that currently
> ox-publish is not fully capable to generate a linked together HTML
> files out of org-roam-v2 generated org files because of the ID-linking
> of org-roam-v2.
> In my tests it sometimes work and sometimes not. I was not able to
> reproduce this. While writing to the list about that problem I was
> pointed to that bug report here.
And I think that I understand the question, and the general setting related to it.
So, on the one hand you have `org-mode/org-id` links like `[[id:32ba80a3-1982-4f43-becb-
b0e346a91b0d][hello]]`, which seem the thing to do in the 21st century, the most sensible
thing to do IMO, I only use those, `org-roam` only use those.
When with `emacs` the links are followed/resolved through a database. For example, the
database can be updated through functions like `org-id-update-id-locations`, part of
However the use of them is controversial because some deem them as not human friendly
enough. So I suppose guidelines should be defined for anything to happen, but I'm not
sure people would agree on what to do. And internal ID links, resolved locally through
reading in a database, should be thoroughly translated to something accurate and
consistent at export-time, and that seems a lot.
I myself use `org-roam` and `ID`; considering the difficulties of exporting to html through
emacs/org-mode, I just gave up.
PS: I think you are doing an awesome job at trying to have all that working.
On Wednesday, 9 March 2022 17:39:46 CET firstname.lastname@example.org wrote:
> Dear Max,
> thank's a lot for your help and your patience with a newbie.
> Am 09.03.2022 16:32 schrieb Max Nikulin:
> >> 3.
> >> I use (setq org-export-with-broken-links t) with and without
> >> ":with-broken-links "mark"" to prevend ox-publish stopping when there
> >> are broken links. I swear and I also checked that there are only a few
> >> of them. But in the HTML output all links are gone. No links. No text
> >> for the links.
> > If you insist on setq than try
> > (setq org-export-with-broken-links 'mark)
> > without :with-broken-links. You can get correct value using easy
> > customization interface. It does not matter for
> > `org-export-with-broken-links', but some custom variables have :set
> > property, so the following may be generally better
> > (custom-set-variables
> > '(org-export-with-broken-links 'mark))
> Do you mean that (setq org-export-with-broken-links 'mark) is the same
> as :with-broken-links mark? This are just two different ways to set the
> same thing?
> How do I know as a newbie? ;)
> Why using custom-set variables here? Is there something wrong with just
> (org-export-with-broken-links t)
> >> I tried to reproduce this in a minimal example with two new nodes. But
> >> for them the links are generated.
> > It seems, changing project options or global variables does not lead
> > to updating of the files if the sources have not modified.
> I do not understand. Do you a see a solution for the problem?
> > There is a known problem with id links. They may be broken if they
> > lead to another file:
> > inkbottle. org-id with ox-html. Sat, 14 Aug 2021 00:28:35 +0200
> > https://list.orgmode.org/4617246.m1MCmUpgFQ@pluto/
[-- Attachment #2: Type: text/html, Size: 14494 bytes --]
next prev parent reply other threads:[~2022-03-11 19:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-09 8:55 ox-publish: Some starting problems c.buhtz
2022-03-09 9:41 ` c.buhtz
2022-03-09 15:57 ` Max Nikulin
2022-03-09 15:32 ` Max Nikulin
2022-03-09 16:39 ` c.buhtz
2022-03-11 19:21 ` chris [this message]
2022-03-15 13:04 ` Max Nikulin
2022-03-10 21:49 ` Nick Dokos
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:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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
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).