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 oKekGEjw8F/YGAAA0tVLHw (envelope-from ) for ; Sat, 02 Jan 2021 22:14:32 +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 GEp1FEjw8F+jCAAA1q6Kng (envelope-from ) for ; Sat, 02 Jan 2021 22:14:32 +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 89ED194042A for ; Sat, 2 Jan 2021 22:14:31 +0000 (UTC) Received: from localhost ([::1]:55464 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kvpAM-00044V-Gd for larch@yhetil.org; Sat, 02 Jan 2021 17:14:30 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:49978) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvpA0-00044N-6r for emacs-orgmode@gnu.org; Sat, 02 Jan 2021 17:14:08 -0500 Received: from out0.migadu.com ([2001:41d0:2:267::]:9986) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvp9w-0002Mf-UQ for emacs-orgmode@gnu.org; Sat, 02 Jan 2021 17:14:07 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kyleam.com; s=key1; t=1609625638; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=lhXvUMGIHA50/pSeky0v0U0tRpwLym5dOxbCRnCFcYw=; b=TVmtHZJdOqYmxOMXPvqhRHQMEEI0eAzF6zeVIz53RH//JlqYFefY3l0zPtXwFEj9YUock/ qA6Ng1JSD+Q1QBnr+eda7/xsUXA/oWaN7pazpzTmW65Kg6THDUZfdSKal5Hs+sikpqcED9 YTNd63Rc4jxlYccv/FculBvzfVK8/DqV2wf281ySwPSAs5ti+xpgZr/Z8LkWgSW/if9t+l uvQm1x6Y96iKPhXGBpbIveZCfnt3EKf4cc2cpeRuYEVyqkbU86+AMNMQaMglWw7O+npoMy zi1nnSsjkzVA7NHzv5HDWr2fPH8oYwdqamcJ3ZgQHCzSMLDdqBxTMrtLuJIrjQ== From: Kyle Meyer To: John Kitchin Subject: [PATCH] ol: Avoid initial input when completing function for storing link In-Reply-To: Message-ID: <87im8fdm1n.fsf@kyleam.com> MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Auth-User: kyle@kyleam.com Date: Sat, 02 Jan 2021 22:13:58 GMT Received-SPF: pass client-ip=2001:41d0:2:267::; envelope-from=kyle@kyleam.com; helo=out0.migadu.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, SPF_HELO_NONE=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: , Cc: org-mode-email Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.53 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=kyleam.com header.s=key1 header.b=TVmtHZJd; 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: 89ED194042A X-Spam-Score: -2.53 X-Migadu-Scanner: scn1.migadu.com X-TUID: s5i11r3nx81p John Kitchin writes: > 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. The "or better" sounds reasonable. Perhaps someone will attempt that, but in the meantime I think just avoiding the discouraged/mostly deprecated INITIAL-INPUT argument would be a good improvement. -- >8 -- Subject: [PATCH] ol: Avoid initial input when completing function for storing link * lisp/ol.el (org-store-link): Use completing-read's DEF argument rather than INITIAL-INPUT, which is discouraged (see Elisp manual) and may hide the other choices depending on the completion framework. Reported-by: John Kitchin Ref: https://orgmode.org/list/CAJ51ETqO9A8mE0W3pgU2cFzaZsESdYXAV0X-8veY+_V9AwPHdQ@mail.gmail.com --- lisp/ol.el | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lisp/ol.el b/lisp/ol.el index 5ba813142..cf105786f 100644 --- a/lisp/ol.el +++ b/lisp/ol.el @@ -1496,9 +1496,9 @@ (defun org-store-link (arg &optional interactive?) (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)) + (format "Store link with (default %s): " name) + (mapcar #'car results-alist) + nil t nil nil (symbol-name name)) results-alist))) t)))) (setq link (plist-get org-store-link-plist :link)) base-commit: 291993888d7b6776d42a86facd26c8bc0f72e475 -- 2.29.2