From: Samuel Wales <samologist@gmail.com>
To: Max Nikulin <manikulin@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Exporting Hyperlinks ?
Date: Fri, 3 Nov 2023 14:55:03 -0700 [thread overview]
Message-ID: <CAJcAo8upgrQ37h9diXUxoJPGQXJiBp9q_j1iJMMfb3684+Tr_g@mail.gmail.com> (raw)
In-Reply-To: <ui2iu4$5a1$1@ciao.gmane.io>
to throw a cat among the pigeons, [[file:contacts.org::#custom_id][My
text]] made me think of the need for global custom id in addition to a
file-specific one like this. idk what a good ui for it would be given
all the options we have considered over the years and recently. just
thought to bring it up.
one thing i dislike is having to specify a file name in #+include or
links. too brittle for my taste. you change the file name and the
inclusion [transclusion package also?] or link is broken. i'm ok with
org id most of the time but suepect global human-readable would be
really really useful.
imo huge value here. in fact, i think we should allow human-readable
id's [/and/ org id's] in non-org files, such as .el.
oref seems to do this, but is not part of org and does not use org id
db yet, and some might or might not want a different syntax [no
opinion].
good concept. as something similar, i found myself using
org-link-minor mode all the time for linking together, in comments,
parts of .el files, such as comments with distant code or code in
another file, or format statements with something that parses them but
is for whatever reason not nearby them. and i also linked org with
.el so that org would do org things. it made tses and links
clickable. id markers [not implemented] would be even better as they
would allow instar and outstar formations and unbreakable bidir links
and tours/cycles and arbitrary graphs if those turn out to be desired.
if desired and not too complex, it could even hook up with the org
link insertion and editing mechanism in principle.
i did look at hyperbole both old and new, and found almost nothing
that i needed there. just personal experience.
also, given especially the org-id stuff and other org aspects, i
actually think this kind of thing should NOT be a
separately-maintained package like oref, but should be a minor mode
that is part of the org-maintained codebase. we do already have at
least one org minor mode for operating on non-org files.
of course, maintainers would have to be on board with it being part of
org-maintained code. i just think org should branch out to this minor
mode.
On 11/3/23, Max Nikulin <manikulin@gmail.com> wrote:
> On 03/11/2023 13:29, David Masterson wrote:
>> the generated LaTeX href looks like
>>
>> \href{contacts.tex}{My text}
>>
>> which looks wrong.
>
> Search part definitely should be retained.
>
> I have realized that in the LaTeX world inter-document cross-linking
> works differently. With the xr-hyper package, labels from another
> document may be used directly or with a prefix:
> https://texfaq.org/FAQ-extref
> It may be implemented for Org random labels.
>
> However I would strongly prefer PDF files having stable anchors based on
> CUSTOM_ID, not ones derived from section, figure, etc. counters. I am
> unsure if there is a package that allows to get such anchors out of the
> box.
>
> When I looked into the code for link targets resolution in the context
> of ox-html, I found it rather complicated.
>
>> I use publish for LaTex (org-latex-publish-to-pdf)
>
> Depending on your requirements, it might be possible to export to HTML
> files and then print them to PDF as a workaround. Chromium supports
> headless printing, so it should be scriptable. However to improve
> quality of formatting almost certainly heavy customization of CSS.
>
> I have realized that Chomium scrolls to proper position in PDF when it
> opens a file URI with #anchor part, but it does not update tab address
> bar when an internal link is clicked and it does not react when URL is
> edited to change #anchor part.
>
>
>
--
The Kafka Pandemic
A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com
next prev parent reply other threads:[~2023-11-03 21:56 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-01 4:24 Exporting Hyperlinks ? David Masterson
2023-11-01 16:36 ` Max Nikulin
2023-11-02 2:11 ` David Masterson
2023-11-02 15:24 ` Max Nikulin
2023-11-03 6:29 ` David Masterson
2023-11-03 10:44 ` Max Nikulin
2023-11-03 21:55 ` Samuel Wales [this message]
2023-11-03 22:06 ` Samuel Wales
2023-11-03 22:07 ` Samuel Wales
2023-11-04 7:10 ` Max Nikulin
2023-11-05 12:38 ` Ihor Radchenko
2023-11-05 22:28 ` David Masterson
2023-11-06 9:37 ` Ihor Radchenko
2023-11-07 12:06 ` Max Nikulin
2023-11-07 12:36 ` Ihor Radchenko
2023-11-07 16:38 ` Max Nikulin
2023-11-08 8:02 ` David Masterson
2023-11-08 10:39 ` Max Nikulin
2023-11-08 9:37 ` Ihor Radchenko
2023-11-08 10:50 ` Max Nikulin
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=CAJcAo8upgrQ37h9diXUxoJPGQXJiBp9q_j1iJMMfb3684+Tr_g@mail.gmail.com \
--to=samologist@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=manikulin@gmail.com \
/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).