From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id QOXpJ9b/MmMkEQEAbAwnHQ (envelope-from ) for ; Tue, 27 Sep 2022 15:51:18 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id SMsBJ9b/MmNiAAEAG6o9tA (envelope-from ) for ; Tue, 27 Sep 2022 15:51:18 +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 66FDAAA81 for ; Tue, 27 Sep 2022 15:51:18 +0200 (CEST) Received: from localhost ([::1]:36464 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1odAzV-0005vt-Ke for larch@yhetil.org; Tue, 27 Sep 2022 09:51:17 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42248) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1od8wQ-0000Zm-Uy for emacs-orgmode@gnu.org; Tue, 27 Sep 2022 07:40:02 -0400 Received: from ciao.gmane.io ([116.202.254.214]:35338) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1od8wK-0004cn-Mb for emacs-orgmode@gnu.org; Tue, 27 Sep 2022 07:39:56 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1od8wG-0004W1-4h for emacs-orgmode@gnu.org; Tue, 27 Sep 2022 13:39:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: [BUG] org-store-link-functions advertizes that the first non-nil return value is used, but it is not how org-store-link handles it Date: Tue, 27 Sep 2022 18:39:40 +0700 Message-ID: References: <878rm7s61r.fsf@therning.org> <87k05qjpwg.fsf@localhost> <87tu4tppb6.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: <87tu4tppb6.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: 5 X-Spam_score: 0.5 X-Spam_bar: / X-Spam_report: (0.5 / 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.25, NICE_REPLY_A=-2.319, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1664286678; 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=rNpcJmZHkxBNGdLnW9fiAZDruEXczRulTgKtFUYfMoI=; b=oOxBqNGrYfPL4rrotXJAl5afzKKJjEuYmV+6EBpFFlDkqeCuHYAByQEaAWIYX5t8vIUpjv Wy/PAYrL2mDDeR1GlywLm7TbeWW2NNsGMnqyWNwdv8tDwJSLpvuk9QywFbTJxtGmhALva+ ztf52IBJ+Oh6Fc4E4TQqjHBWFVsUNUrqyXbGdtHjJj+W5I2t8kz8VV586A6xwvhpDlbaa2 9gIt0TjmrRSfo6lHpqnuEIA7iom7L7tt7Q2tMN+BOwvIkFmImpNg8dWaY6An/g+CzkTtbi mjTJCSgRSvc62GnoZI7RReXWTxZn1NZMhGI5PItCrEvuBeDqroA7aOgukrVTZw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1664286678; a=rsa-sha256; cv=none; b=Noc8bytNs4eF5bAKQwwjGgHClZiFVCXgoEM75G5LOELVljBspxLuM1iII1xibMRrnM2Kfj CommUY1WCE4raLa5opjN7POzA46Bo7hbNFPwQhsRAf4a+rNalSbYiFjC+VA5mPa5kljgEh oj7UQI/sW+ftwK9cDw4RrMNgrs3x6ezditEBBoNsQn2QEly/DPHsWeUpolyvJuXmdSibL5 hOa0ijhg/oCaUs06QnNJxiwfLy2ESQ9z0ea9m7ja08WeFxGUXZDXNfMu0yJT7xEbNnBpc+ nPH7DrFtUTmIMwJE0wRokhgcQ6Sb5qooL02F5he5UnJdxrfPLubyF2GGiLlOSQ== 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: 4.36 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: 66FDAAA81 X-Spam-Score: 4.36 X-Migadu-Scanner: scn0.migadu.com X-TUID: a23+GkBNKeVy On 27/09/2022 08:40, Ihor Radchenko wrote: > Max Nikulin writes: > >> There is the `org-store-link-plist' variable used by :store functions >> from `org-link-parameters' but not by the >> `org-create-file-search-functions' hook. Maybe it is enough to add > > Reading through `org-store-link-functions' docstring and > `org-store-link' code, I noticed that `org-store-link-functions' > promises the following: ... > That is, all the store link functions are actually being executed, not > until first non-nil return value. If multiple non-nil values are > returned, an interactive query is displayed to the user. > > The actual behaviour is indeed nice, but I am wondering how it is going > to work in non-interactive case. There are more inconsistencies. For a heading in an Org file 2 links may be created: title search and #custom_id. Only one link is removed by `org-insert-link'. Only one of them is checked if it has been stored earlier. Usually after several store+insert actions I have a list of stored links that I will never use. I am unsure what is better, to prompt user when link is saved, or store all options with some group ID and remain other links when one item from the group is inserted. I suppose, `org-store-link' should be split into smaller building blocks to allow experiments with alternative implementations and strategies to select from several variants. I was wrong suggestion that changing of :store property of "file" links may be a workaround for original issue. It is easy to store line number instead of search text, but there are a lot of code to detect headings, #custom_id, <>, etc. for "file" links and this code can not be easily reused.