From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id KAC1Ce6opmUSDQAAqHPOHw:P1 (envelope-from ) for ; Tue, 16 Jan 2024 17:03:58 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id KAC1Ce6opmUSDQAAqHPOHw (envelope-from ) for ; Tue, 16 Jan 2024 17:03:58 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=hUzDDkIm; dmarc=pass (policy=none) header.from=posteo.net; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1705421038; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=wePtgYp9+cnJI8wE2KCASIsLI2a2pj/Z+YpU0kUXFhQ=; b=ALGwY4nQ94soaj6058/jgNzw80MVXDFJlwaDGNwdqPsEuAQgG7RGFvS0zGaTxB9Zs67NlO wu6rCiw4lIx36+SHAmhSMkRR4ERaEBjyL8CHMkhcbcwG+Dr13utWbCAChEfevGShxTVAZe YOm7TNoRA1vVdKtgWVa4ykDZ3hzcLF5iTDoCVC6IUeMiVc0vMft5OeowVeqSn52PEDZkeD PZLS/5VNlajHVOAv159dhdXdDrapRkrTYs/o130UBRvFrbOfg/Cnu0sYC63N8RHxr2eQ6f yCAGWIpGANjCQMsH2CiA34Qe42Q4EEuHzWMwux3VKsYFBRO3OWoDXDxf7kmovw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=hUzDDkIm; dmarc=pass (policy=none) header.from=posteo.net; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1705421038; a=rsa-sha256; cv=none; b=OkdhKuF111Rf0cAMgFAwfzZBBkODnawvmFanwnQjzeKKwSVvYRCPTqIlP9oU5o7LhvtHup q956xXyFuS45Ql/ns4Hbq2ihdsGNpuqPQBlkaRTh9YnY1YOALHjLZA1TZOeJJE2fSflmcq M18FDP+BSrY8018EJ++El9JSCpLs939FCzAkcJVOKcUeXCDUeVqL3qCn7D5XVFGEfhIDwP e6zxA8aS0Zembs6T3vSNHlvK1bNYCOMHsOsdD3Ne8eH4ySWelTclalA+mBWsKeJudNI7bv pEIbcLGbmOWAxVX2oOz0s1+jWcJNOJZp4lv5ToCDCs5sdk5AE1znkNo7+nQnUw== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 0C322158C9 for ; Tue, 16 Jan 2024 17:03:58 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rPlu1-00008N-Bc; Tue, 16 Jan 2024 11:03:01 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rPlu0-000083-32 for emacs-orgmode@gnu.org; Tue, 16 Jan 2024 11:03:00 -0500 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rPltx-0006d7-Uk for emacs-orgmode@gnu.org; Tue, 16 Jan 2024 11:02:59 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 8C68A240028 for ; Tue, 16 Jan 2024 17:02:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1705420975; bh=+E/0z6nFEsUDvqXW9RKTq8PDIMgTz+7djP6unqlTL+M=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:From; b=hUzDDkImLRpbe/a4pcULGhpkdkggJuD/+UpF5P2ZE5d8V9ILNU9Hebfbu/upVXwbH RNEbHqcqW0BwePdDHhdtWPYFzTqNeyE9noN1QWeAD3hDofvoiTPPMPTw5E4Ubdv65G cIL0ZeFB9HaWeIGozKG6jMOYvRAlCZipWGxn23ldXUsepzQiyW6W829odNk/Ht/82t SGpcGBynxreMv5k1rUE2fNan4KLBSi/emUcjek4sFbXg7GPpBCvSYL5PDgaVTSRCGc LsFGwSx3m/irR3IB8CbxJ+27iTRzSl5zsNYG0iueQ1W85ccaugnSCaIhkuoZuJzuP4 DAX3HkZ7s2gmA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4TDv1B6CCyz6twM; Tue, 16 Jan 2024 17:02:54 +0100 (CET) From: Ihor Radchenko To: =?utf-8?B?6KW/IOmhvg==?= Cc: "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) In-Reply-To: References: Date: Tue, 16 Jan 2024 16:06:08 +0000 Message-ID: <871qahl0un.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -7.62 X-Spam-Score: -7.62 X-Migadu-Queue-Id: 0C322158C9 X-Migadu-Scanner: mx12.migadu.com X-TUID: NCXfH+NQE3Dh =E8=A5=BF =E9=A1=BE 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. --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at