From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id QP0mMuLR92LGcAAAbAwnHQ (envelope-from ) for ; Sat, 13 Aug 2022 18:31:30 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id WHETMuLR92IsgAEAauVa8A (envelope-from ) for ; Sat, 13 Aug 2022 18:31:30 +0200 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 8315A111E for ; Sat, 13 Aug 2022 18:31:30 +0200 (CEST) Received: from localhost ([::1]:40520 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oMu2r-0002da-HR for larch@yhetil.org; Sat, 13 Aug 2022 12:31:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59684) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oMtxZ-00062Z-CR for emacs-orgmode@gnu.org; Sat, 13 Aug 2022 12:26:01 -0400 Received: from ciao.gmane.io ([116.202.254.214]:42964) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oMtxX-0005IX-Su for emacs-orgmode@gnu.org; Sat, 13 Aug 2022 12:26:01 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1oMtxU-0006BU-QV for emacs-orgmode@gnu.org; Sat, 13 Aug 2022 18:25:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: [PATCH v3] Re: [BUG] org-attach-id-ts-folder-format fails on customized IDs [9.6 (9.6-??-2e9999783)] Date: Sat, 13 Aug 2022 23:25:51 +0700 Message-ID: References: <87k084v1wa.fsf@localhost> <871qtxhsm6.fsf@localhost> <87a68ce32u.fsf@localhost> <871qtodygs.fsf@localhost> <87v8qz9zui.fsf@localhost> <35cbf452-c3ed-d97f-db96-dcae57463eff@gmail.com> <87wnbc7ltm.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Content-Language: en-US In-Reply-To: <87wnbc7ltm.fsf@localhost> Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 28 X-Spam_score: 2.8 X-Spam_bar: ++ X-Spam_report: (2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1660408290; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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; bh=1fBDyviEC/DFao2qczUqvhBRaSoRqlZKyy1aFxBYy7Q=; b=CEK4NuCOAnQBFOh59Qvc8sYpVGLxEb9qmH0/aVTWr5oo1DTNjmH0uJaaRRtHlETy5TeSwp Zg6/WgQHDp8GMy+4dhoJlXjU1RLw4ZNSTtswVlOe2b27AyN85kHdv3OhAOoaTp+7R2ofJR a1Eio6Xu3Qr8a1Sb+yQ/2MhxVyv7s1aicjN+8HvLam8+L5dN4BDaW0nhWBGSEd1MwhhFQH PKyueteRSDHvpvtyVaKl0hKIsLO1YySXh5WUDIq3ky6jpdYnE9Lwq7JluhUvMJB25u6RWc glvBazQP5hvRRfgArvD78a2ZoT2RF7s3Lk5In3TDf/4J8KC3dRYA8w7BaNFQpQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1660408290; a=rsa-sha256; cv=none; b=kZqgk/smxKFskVgY2JGyexsDRPLGJem051uQZm7wyj3L7vNn2sqQImVtlnQHNLvFdxolS+ swfdyowr/4I7FpAuWeC+T1aPy5UViJiWlMJDFloeflL439CD8z0WpufFH50Bewk0XH5pF/ AwqJ8vovPuRgdKkTg2AO8/O08fq9jiFyDbP2bdPEe5CkGOV5Inje6XI1zJGgIkhMMqmoBY +1tEDTv6axw+Votk/4ev/iU/AqUpo1F6MOTS5wFWInsbHuhKiyGZh8Jkpoo9giPeputXpT ig7fqQmlzPVFIH0kkU6gmJbk7gN4h/8j0XyEqudqy4AhBREBdSveK2Lt/1y6qg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); 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" X-Migadu-Spam-Score: 2.84 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); 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" X-Migadu-Queue-Id: 8315A111E X-Spam-Score: 2.84 X-Migadu-Scanner: scn0.migadu.com X-TUID: lV17Y0kYUq2k On 13/08/2022 12:29, Ihor Radchenko wrote: > Max Nikulin writes: > >> I believe that interaction between `org-attach-dir-from-id' and members >> of `org-attach-id-to-path-function-list' could be improved. If a too >> short ID is passed to `org-attach-id-uuid-folder-format', >> `org-attach-id-ts-folder-format', or a user-defined function, they may >> return nil and `org-attach-dir-from-id' should try next element from the >> list. If nothing succeeds then a user error should be signaled demanding >> to implement a strategy to properly deal with peculiar IDs. > > I do not think that it is a good idea. We currently promise to use the > first function in the list to generate the IDs. Other functions are > mostly a fallback to catch the existing attach dirs created in the past > using different ID scheme. My idea is to add an extra check that filters out nil values. I do not mind to signal a user error if first entry from `org-attach-id-to-path-function-list' returns nil and paths returned by other function do not exist. > I guess that one option could be demanding a non-nil return value when > generating a new attach dir (without TRY-ALL argument) and wrapping > things into (ignore-errors ...) otherwise. I am against `ignore-errors' because it makes harder bug hunting using debug on errors. I would prefer to force users to justify strategy for non-standard IDs as early as possible. The goal is to avoid manual actions to change directory structure when users have hundreds of folders. My experience that users may easily face performance issues with ~1000 files per directory. The reason is either lack of optimization for such case in particular application or a bug introduced in a new version.