emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Kévin Le Gouguec" <kevin.legouguec@gmail.com>
To: Bastien <bzg@gnu.org>
Cc: emacs-orgmode@gnu.org
Subject: Re: Default description for abbreviated links
Date: Mon, 21 Sep 2020 18:19:07 +0200	[thread overview]
Message-ID: <87363b5chw.fsf@gmail.com> (raw)
In-Reply-To: <874kobcp5w.fsf@gnu.org> (Bastien's message of "Sun, 06 Sep 2020 09:58:19 +0200")

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)



Where DESCRIPTION-FALLBACK could be nil (the default), 'key-tag or 'tag.

Thank you for your time.

      reply	other threads:[~2020-09-21 16:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-16 17:35 Default description for abbreviated links Kévin Le Gouguec
2020-09-06  7:58 ` Bastien
2020-09-21 16:19   ` Kévin Le Gouguec [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:

  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=87363b5chw.fsf@gmail.com \
    --to=kevin.legouguec@gmail.com \
    --cc=bzg@gnu.org \
    --cc=emacs-orgmode@gnu.org \


* 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).