all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: chris <inkbottle007@gmail.com>
To: emacs-orgmode@gnu.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)
In-Reply-To: <7395938a0e6b06139239bc70ba7c2b19@posteo.de>

[-- Attachment #1: Type: text/plain, Size: 3634 bytes --]

Hi Christian,
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 c.buhtz@posteo.jp 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.
> 
> Kind
> Christian
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 
https://github.com/tkf/org-mode/blob/master/lisp/org-id.el[1].

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.
Thanks,
Chris
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 c.buhtz@posteo.jp 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
> doing
> (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 --]

  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

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=5552297.DvuYhMxLoT@pluto \
    --to=inkbottle007@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /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.