emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Benjamin Andresen via "General discussions about Org-mode."
Cc: Benjamin Andresen <benny@lambda.icu>
Subject: Re: Public API change: How to handle function signature change gracefully
Date: Tue, 21 Apr 2020 19:57:18 +0200	[thread overview]
Message-ID: <87pnc0pvr5.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <M5GA5XO--3-2@lambda.icu> (Benjamin Andresen via's message of "Sun, 19 Apr 2020 08:42:19 +0200 (CEST)")


Benjamin Andresen writes:
> I would like to change the public API of the :face part of `org-link-set-parameters':
>         (org-link-set-parameters "file" :face 'org-link)
> My ultimate goal is to have org-links be able to be have their face changed based on the contents, not just the path of the link.
> I found the relevant code in org.el in the function `org-activate-links':
>    'face (pcase (org-link-get-parameter type :face)
>    ((and (pred functionp) face) (funcall face path))
>    ((and (pred facep) face) face)
>    ((and (pred consp) face) face) ;anonymous
>    (_ 'org-link))
> and would like to change this to 
>    'face (pcase (org-link-get-parameter type :face)
>    ((and (pred functionp) face) (funcall face path contents)) ;; this is the change
>    ((and (pred facep) face) face)
>    ((and (pred consp) face) face) ;anonymous
>    (_ 'org-link))
> Now that will introduce a host of call issues because the callees don't expect to the amount of arguments changed under their bottom.
> I would like some guidance how I could get what I think is neat: The
> contents of the bracket-style links as an additional parameter to set
> faces on and not breaking existing hookups.

Isn't the function called with point on the link? You may just need to
extract the contents from the environment.

Otherwise, a solution is to catch `wrong-number-of-arguments' error and
call again the function with the old calling convention. See, e.g.,

> To make this more palatable I would suggest it's changed so that the
> 2nd argument will be a list of alists or keywords so to not have this
> function signature problem if someone else comes up with a reason to
> introduce yet more data.

Beware the over-engineering. At this point, someone motivated enough can
put an advice to the link fontification function.


Nicolas Goaziou

  reply	other threads:[~2020-04-21 17:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-19  6:42 Benjamin Andresen via General discussions about Org-mode.
2020-04-21 17:57 ` Nicolas Goaziou [this message]
2020-04-21 20:07   ` John Kitchin
     [not found]   ` <CAJ51ETrUxoWoraMxKTCRnzNxtmj5kwVWBAWvAeL1PSZvJs5hjw@mail.gmail.com-M5TLt9R----2>
2020-04-21 21:56     ` Benjamin Andresen via General discussions about Org-mode.

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=87pnc0pvr5.fsf@nicolasgoaziou.fr \
    --to=mail@nicolasgoaziou.fr \
    --cc=benny@lambda.icu \
    --cc=emacs-orgmode@gnu.org \
    --subject='Re: Public API change: How to handle function signature change gracefully' \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this 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).