emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

From: Ihor Radchenko <yantar92@posteo.net>
To: "西 顾" <z.ref@outlook.com>
Cc: "emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: [POLL] Change calling convention for when `org-link-file-path-type' is set to custom function (was: Enhancement Proposal for 'org-link-file-path-type' Behavior)
Date: Tue, 16 Jan 2024 16:06:08 +0000	[thread overview]
Message-ID: <871qahl0un.fsf@localhost> (raw)
In-Reply-To: <OS3P286MB25657ED1C2BF5C9AECCEEF0AF9732@OS3P286MB2565.JPNP286.PROD.OUTLOOK.COM>

西 顾 <z.ref@outlook.com> writes:

> I'd like to suggest a small enhancement to the
> 'org-link-file-path-type' option. When set to 'function', it currently
> passes an absolute path to the user's custom function. This limits
> flexibility as the original path input is not available to the
> function.
>
> For better customization, I propose passing the raw path to the
> function. Users needing an absolute path could use 'expand-file-name'
> within their function.

Thanks for the suggestion!

This makes sense - the current approach with passing absolute path is
indeed limiting the information passed to the custom function.

The docstring is also quite ambiguous about what is passed as an
argument:

    org-link-file-path-type is a customizable variable defined in ol.el.
    <...>
    Alternatively, users may supply a custom function that takes the
    full filename as an argument and returns the path.

"full filename" may or may not mean "absolute filename".

However, changing the absolute path to "as is" path will technically be
breaking.

I cannot find any actual uses of custom function value for
`org-link-file-path-type' in the wild, so I am leaning towards going
ahead with this (minor) breaking change.

Yet, I am starting a poll to give users who may be affected a chance to
chime in.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

next prev parent reply	other threads:[~2024-01-16 16:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-16 12:00 Enhancement Proposal for 'org-link-file-path-type' Behavior 西 顾
2024-01-16 16:06 ` Ihor Radchenko [this message]
2024-01-17  4:59   ` [POLL] Change calling convention for when `org-link-file-path-type' is set to custom function (was: Enhancement Proposal for 'org-link-file-path-type' Behavior) Christopher M. Miles
2024-01-17 13:17     ` Ihor Radchenko
2024-02-17 15:27   ` Ihor Radchenko

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=871qahl0un.fsf@localhost \
    --to=yantar92@posteo.net \
    --cc=emacs-orgmode@gnu.org \
    --cc=z.ref@outlook.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

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