From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id 8Ln1BdPkw2WUfQEAe85BDQ:P1 (envelope-from ) for ; Wed, 07 Feb 2024 21:15:15 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id 8Ln1BdPkw2WUfQEAe85BDQ (envelope-from ) for ; Wed, 07 Feb 2024 21:15:15 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=arcor.de header.s=vfde-mb-mr2-23sep header.b="BhRIAr/X"; dmarc=pass (policy=quarantine) header.from=arcor.de; 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=1707336915; a=rsa-sha256; cv=none; b=a6m0fjV8wrlex0t8VWkxq/NhLTPSYVUDpb7nIfzXQEwP1n9SufcRBMVqzX9FDYNX4UX1gW km9SBfnfb9+g5s9EKEq0tnry/k0358WHLGC/DWjDhSfxn6lk4ArvQdw+ob2qsKya6842r2 rsWjRU32jGu/rGxQziTcWBYFBBiZWNSeN6TCWv9p+yGZLQHz90ENweslh/55S+RFNooUoT 0Jh82gcgQdlzl2QfIpU7CFqC9CaLn6bLF0oL9I+soBWv4p2J0tDO9gmV9ZJtFGDEJHPIqO zszq0zexlyNOb6W4FHmrTLvHAivofEwHnPbLAuThSBuCFqqQlJ2PPzCL8agkWg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=arcor.de header.s=vfde-mb-mr2-23sep header.b="BhRIAr/X"; dmarc=pass (policy=quarantine) header.from=arcor.de; 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=1707336915; 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:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=Xppg7SAoalxhLohjXsvKAQ6cVN+UXBrGMH2Hu8VOOgI=; b=rALUiy4XnW8n8koCsarh/AiZoAEPgQ69p3ziYsO5dooamH0xk60L8LGX+orAn3c925LwvT Y6idHN2nRCo6TyM639idoCyU2LCh2tdYz/PLXXsOfK6veIRcEIrzbc/iZV/5YsG8S8it8E UlWTQFjTiWf3Bq3QwQGP6iz1kY3EjuLfJyQ5zwbVpUUTEhy0BycjKvaKHjO0pDo+m/DDMp Q//85w9HP07NeQYW7N9cFpBkEhXJP9iq0rW6ewmFjakVt/0B9aRI9H1Mh5Omtns6Ey0UU6 OZufmViW/0LfSK/3hyVqD2hiKihf/7D+AGB5ZQVLMup/dljjqT0Jbs3+kfZWqQ== 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 5A637E960 for ; Wed, 7 Feb 2024 21:15:14 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rXoJA-0001UY-HJ; Wed, 07 Feb 2024 15:14:12 -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 1rXoJ8-0001UP-Mw for emacs-orgmode@gnu.org; Wed, 07 Feb 2024 15:14:10 -0500 Received: from mr4.vodafonemail.de ([145.253.228.164]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rXoJ6-0005wl-GR for emacs-orgmode@gnu.org; Wed, 07 Feb 2024 15:14:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arcor.de; s=vfde-mb-mr2-23sep; t=1707336834; bh=Xppg7SAoalxhLohjXsvKAQ6cVN+UXBrGMH2Hu8VOOgI=; h=User-agent:From:To:Subject:Date:Message-ID:Content-Type:From; b=BhRIAr/XZajkjY/kCRUmLNtnLhBLWVwWXWouMLVU+pRDCIA3E0bS0c8rQHpVHrLmJ uC8Rt1VMkywlnEnQXthyD9Ysapm2SsXZ7V61uSgusC2MitwgZO3WuvIjND723yJThi nMNeLJ6kAOw9swcY7SVniaNLtQeDBNRa0hfpOINc= Received: from smtp.vodafone.de (unknown [10.0.0.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mr4.vodafonemail.de (Postfix) with ESMTPS id 4TVWXf2btkz1yDL for ; Wed, 7 Feb 2024 20:13:54 +0000 (UTC) Received: from ebmobile6 (dslb-084-062-182-065.084.062.pools.vodafone-ip.de [84.62.182.65]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp.vodafone.de (Postfix) with ESMTPSA id 4TVWXZ1QMHzHnHm for ; Wed, 7 Feb 2024 20:13:47 +0000 (UTC) User-agent: mu4e 1.10.0; emacs 29.1 From: Tim Wichmann To: emacs-orgmode@gnu.org Subject: Question regarding org-capture-bookmark and org-bookmark-names-plist Date: Wed, 07 Feb 2024 21:07:44 +0100 Message-ID: <87le7wkp72.fsf@arcor.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-type: clean X-purgate: clean X-purgate-size: 1229 X-purgate-ID: 155817::1707336830-BAFFC740-ED147D78/0/0 Received-SPF: pass client-ip=145.253.228.164; envelope-from=schwurg@arcor.de; helo=mr4.vodafonemail.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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-Scanner: mx10.migadu.com X-Spam-Score: -4.98 X-Migadu-Queue-Id: 5A637E960 X-Migadu-Spam-Score: -4.98 X-TUID: 45vIKwi4s+Ht Hi all, during last OrgMeetup, I proposed a new user option `org-refile-bookmark', similar to the already existing option `org-capture-bookmark'. Setting this new option to nil, `org-refile=E2=80= =99 would not create a bookmark when refiling. (Use case: I am using alphapapa's org-bookmark-heading package and want to prevent that each captured/refiled entry gets an id.) I was just about to send the corresponding feature request when I stumbled across the documentation of `org-bookmark-names-plist'. It states: =E2=80=9EWhen a key does not show up in the property list, the corresponding bookmark is not set.=E2=80=9C So, there is no need for a new user option: I simply have to remove the :last-refile key from the plist, and no bookmark will be created on refiling. My question: Is this the intended way to suppress bookmark creation? If so: Why is there the extra user option `org-capture-bookmark'? Isn't it superfluous, as the same behavior can be achieved by removing the :last-capture keyword from the plist? (Note, moreover, that currently the :last-capture-marker bookmark is created even in case `org-capture-bookmark' is set to nil, see `org-refile'.) Best regards, Tim.