[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Default description for abbreviated links
From: |
Kévin Le Gouguec |
Subject: |
Re: Default description for abbreviated links |
Date: |
Mon, 21 Sep 2020 18:19:07 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Hello Bastien! Thank you for following up on this.
Bastien <bzg@gnu.org> writes:
> Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
>
>> I like #+LINK keywords because they make documents self-sufficient:
>> anyone opening my document can follow these links or export the buffer;
>> they do not need to run some Elisp to add to org-link-parameters.
>>
>> One thing I don't know how to customize, however, is how these links are
>> exported when they have no description.
>
> thanks for sharing your need and ideas.
>
> I think we can allow
>
> #+LINK: bug [[https://debbugs.gnu.org/%s][bug:%s]]
>
> to define an abbreviated link producing the output you want.
>
> Same in org-link-abbrev-alist(-local):
>
> (("bug" . "[[https://debbugs.gnu.org/%s][bug:%s]]"))
>
> What do you think? I'd rather not add an option or modify the
> structure of org-link-abbrev-alist(-local).
That's an interesting idea! It sounds fairly more powerful than what I
had in mind (only allowing KEY:TAG or TAG), but I'm sure someone could
find some use for free-form formatting.
I'm not sure how to implement it though. I just came back from a hike
through ox-html.el, ox.el, org-element.el and ol.el; going backward,
here is how descriptions are given to export backends:
(1) Link-transcoding functions (e.g. org-html-link) are given two
arguments: a link object, and its description.
(2) The description argument is set in org-export-data, from whatever
org-element-contents returns.
(3) This (IIUC) is defined by what org-element--parse-objects `push'es
on the link object, which is determined by a recursive call to
org-element--parse-objects from the link's :contents-begin property
to its :contents-end property.
(4) org-element-link-parser sets these properties to the bounds of
org-link-bracket-re's optional second group, if it exists.
AFAICT steps (2) and (3) are not specific to links; they are generic
steps that are independent of what kind of elements they are processing.
I don't think this is where the "description fallback" feature should be
implemented, since it would add special-casing just for links.
I'm guessing I should keep aiming at step (4), like in my first patch;
my problem is that this step just defines the link's :contents-begin and
:contents-end properties. My first patch works because I'm only
allowing KEY:TAG and TAG, so I can re-use positions inside
org-link-bracket-re's first group.
If we are to create a completely new format string, how can we pass it
to the backends?
FWIW, I would still favor only allowing KEY:TAG and TAG, since that
covers all use-cases I've thought of so far (the one you quoted, and the
"doc:" links in ORG-NEWS).
I know you said you'd rather not modifying the structure of
org-link-abbrev-alist, but maybe adding an optional third item would be
the least intrusive way to go? I.e. going from:
("linkkey" . REPLACE)
To:
("linkkey" REPLACE [DESCRIPTION-FALLBACK])
Where DESCRIPTION-FALLBACK could be nil (the default), 'key-tag or 'tag.
Thank you for your time.