From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 6IgbHmqF8F8QBgAA0tVLHw (envelope-from ) for ; Sat, 02 Jan 2021 14:38:34 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id WGjpGWqF8F9hTAAA1q6Kng (envelope-from ) for ; Sat, 02 Jan 2021 14:38:34 +0000 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 CC05C9402A9 for ; Sat, 2 Jan 2021 14:38:33 +0000 (UTC) Received: from localhost ([::1]:35498 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kvi36-0001xo-Gz for larch@yhetil.org; Sat, 02 Jan 2021 09:38:32 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39330) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvi2U-0001xh-Bi for emacs-orgmode@gnu.org; Sat, 02 Jan 2021 09:37:54 -0500 Received: from grinta.net ([109.74.203.128]:45982) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kvi2S-0002TG-0K for emacs-orgmode@gnu.org; Sat, 02 Jan 2021 09:37:53 -0500 Received: from black.local (p4fe7185a.dip0.t-ipconnect.de [79.231.24.90]) (Authenticated sender: daniele) by grinta.net (Postfix) with ESMTPSA id BF098E07DB; Sat, 2 Jan 2021 14:37:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=grinta.net; s=2020; t=1609598267; bh=7Gi1rt47RbrPDkNcxkK5T25Tp+qsk0Axpp8dk1qa/B0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=nmojnNhZ/6b/B/PAr12zmh0HGfIBF9BMqKiwwZiaPZXobJX9hAKXEiWmTQ0KoVBr3 JVOu5wws2y5uqwxpOjaQftM1B75kAgYVUKDnjLqYZtefdynTl+TOZwqCDq7YcyP/0T VjuuSE2ruDzeqvnvHVKpdE2t4dPVV6DtPXGyP/WpnvHAvk16i9LqI7J0Aol49nt01X oQwZpqdKBePh8GuV4u1uDQPdx80uGuX7H+lu8f446IeA28+4/2NsUr5sOvUAZMnEpS +tsE4Z9FUBw5T5x3elCI5R5S8ZF23nbng1OeZ3fJIgsjbkfEhaEsEd1RWZHHZa/W4A Jo6QkckhTvgIw== Subject: Re: what do do when multiple functions store a link To: John Kitchin , org-mode-email References: From: Daniele Nicolodi Message-ID: <54d60a65-eee0-deac-c7ba-9d18dbce27b6@grinta.net> Date: Sat, 2 Jan 2021 15:37:45 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=109.74.203.128; envelope-from=daniele@grinta.net; helo=grinta.net X-Spam_score_int: -31 X-Spam_score: -3.2 X-Spam_bar: --- X-Spam_report: (-3.2 / 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, NICE_REPLY_A=-1.118, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 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-Spam-Score: -1.33 Authentication-Results: aspmx1.migadu.com; dkim=fail (headers rsa verify failed) header.d=grinta.net header.s=2020 header.b=nmojnNhZ; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: CC05C9402A9 X-Spam-Score: -1.33 X-Migadu-Scanner: scn1.migadu.com X-TUID: dBdwgMnLgCLJ On 02/01/2021 14:49, John Kitchin wrote: > Recently I have had an issue where multiple functions may store a link, > e.g. to a bibtex entry.  >   > In this case, org-mode seems to prompt me to ask which function to store > the link with, with an initial input of the first function, which masks > all the options that are available. This happens > inside |org-store-link| in ol.el at line 1495 for me. in > > (apply #'org-link-store-props > (cdr (assoc-string >       (completing-read > "Which function for creating the link? " > (mapcar #'car results-alist) > nil t (symbol-name name)) >       results-alist)))  > > because of the (symbol-name name). >   > Is there an easy way to avoid this, or to modify the order of the > functions used? I want to see all the options for storing, or better, to > just store them all and let me choose later when I use org-insert-link. I have the exact same problem. I think it comes from having org-bibtex and org-ref loaded at the same time. I haven't investigated a possible solution. Cheers, Dan