From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id 8F5mDo5BxWWpQQEA62LTzQ:P1 (envelope-from ) for ; Thu, 08 Feb 2024 22:03:10 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id 8F5mDo5BxWWpQQEA62LTzQ (envelope-from ) for ; Thu, 08 Feb 2024 22:03:10 +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=LtzlqQjz; 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=1707426190; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=iqDTTewzqjfWoNSVGS+ucvJ6u9y1JFT1Iqs2pdPkWzU=; b=YED2zeckISLDKZoOOo/Zt8aq56xGlvxP5Jkv6ZNtGj8+K6Xf52TyCRdulKUh6wK+0aHfMa XnCWaD0RcqJUPG/NxNO0u1QvPeutEt4zyAN6vQfckIX9W6zK1KAKLnhPJc05GhSR0E1fwQ AsRse7vb93kzxz2qXStagpKYoCRzzzqTslY8g7CRGbwWIaSURBJ489CMkVhBip0FHdYZPx W3kFW6wYUcub2Jz1s8MlZAGleGHG3ZzskQpdRIvT2HjLTkonwzVA3oIVudvyMYXKZtx2qf XdDWEPAUiS5euirahqR2v+VwC6KyYVkqWNnxFHiCx7u5ctgS09yH8qCpzFhgjg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=arcor.de header.s=vfde-mb-mr2-23sep header.b=LtzlqQjz; 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=1707426190; a=rsa-sha256; cv=none; b=g9LBnq/W6iGUP5JFUJvhMeBN0Qi3KK0DOeEqhoUam2ehC9QvddXG6aqUQFD4Kld7K+T+kn 94w5u+aOUncjVb8wFaSr5uUxJ2nMq83tsvIB5w1FsjupyLmUb0zI8eHNx17aBC61VIu/h4 Z7fS5jBkYn2nZlZiksEPyLxtdC7v/yMMnhf8rr+pcGdRQpgsEdUbd/uOSUwKPBaJ9RoLVq hsHCb5DjNM9V6AHIt4L5MMCD6NJdE9iT1RLMWAYOSLf6ORIZuqF/K7QRkALjCF3Q9Kau/0 nzll9UEWhO0sBJe+G6JQ9mpoUQcqZ6ChmohSHvktI1tcJx5TCoCJLArS9yxCcg== 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 738071BB93 for ; Thu, 8 Feb 2024 22:03:09 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rYBXA-0005Cu-PH; Thu, 08 Feb 2024 16:02: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 1rYBX3-0005Cb-R4 for emacs-orgmode@gnu.org; Thu, 08 Feb 2024 16:02:06 -0500 Received: from mr5.vodafonemail.de ([145.253.228.165]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rYBX1-0002cM-52 for emacs-orgmode@gnu.org; Thu, 08 Feb 2024 16:02:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arcor.de; s=vfde-mb-mr2-23sep; t=1707426109; bh=iqDTTewzqjfWoNSVGS+ucvJ6u9y1JFT1Iqs2pdPkWzU=; h=References:User-agent:From:To:Subject:Date:In-reply-to:Message-ID: Content-Type:From; b=LtzlqQjzxug5n+BnAuQB4mTTtFymXTU16bXrfmlCbXXRajk/pgbttp1K54s44h/BD 6CamRELulebwlR6QXDv8WnvTRt0J72EVewl+Gk3aDeUWL8ysQbK+3NMRBzmEM9neXe 9P/4AF8kRyUOxYUk5shP2PuQkxQ6x5XPT3WK8A8I= 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) server-digest SHA256) (No client certificate requested) by mr5.vodafonemail.de (Postfix) with ESMTPS id 4TW8YT2vVCz1yGd for ; Thu, 8 Feb 2024 21:01:49 +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 4TW8YP0QRxzHnHW for ; Thu, 8 Feb 2024 21:01:42 +0000 (UTC) References: <87le7wkp72.fsf@arcor.de> <87bk8r2ig1.fsf@localhost> User-agent: mu4e 1.10.0; emacs 29.1 From: Tim Wichmann To: emacs-orgmode@gnu.org Subject: Re: Question regarding org-capture-bookmark and org-bookmark-names-plist Date: Thu, 08 Feb 2024 21:58:45 +0100 In-reply-to: <87bk8r2ig1.fsf@localhost> Message-ID: <877cjer7pm.fsf@arcor.de> MIME-Version: 1.0 Content-Type: text/plain X-purgate-type: clean X-purgate: clean X-purgate-size: 2130 X-purgate-ID: 155817::1707426105-7A7FD740-B2C5778D/0/0 Received-SPF: pass client-ip=145.253.228.165; envelope-from=schwurg@arcor.de; helo=mr5.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-Spam-Score: -4.98 X-Spam-Score: -4.98 X-Migadu-Queue-Id: 738071BB93 X-Migadu-Scanner: mx12.migadu.com X-TUID: amACFfXLROxc Dear Ihor, Ihor Radchenko writes: >> My question: Is this the intended way to suppress bookmark creation? > > I think so. Great! > We first introduced `org-capture-bookmark' and only then added > `org-bookmark-names-plist'. Maybe we should obsolete > `org-capture-bookmark' to avoid confusion. Thanks for the clarification. Obsoleting `org-capture-bookmark' sounds good, as the variable does not add new functionality which can not be achieved with `org-bookmark-names-plist' already. >> ...(Note, moreover, that currently >> the :last-capture-marker bookmark is created even in case >> `org-capture-bookmark' is set to nil, see `org-refile'.) > > May you elaborate? Are you sure that it is still the case on the latest main? I double checked in newest version of defun `org-refile' in main branch: The bookmark for :last-capture-marker is set independently of the value of `org-capture-bookmark'. The corresponding code looks like this: ---[snip: org-refile.el, line 608 ff.]--- (when (bound-and-true-p org-capture-is-refiling) (let ((bookmark-name (plist-get org-bookmark-names-plist :last-capture-marker))) (when bookmark-name (condition-case err (bookmark-set bookmark-name) ---[end snip]--- I would have expected that this bookmark is not set in case `org-capture-bookmark' is set to nil, something like this: ---[snip]--- (when (bound-and-true-p org-capture-is-refiling) (when org-capture-bookmark (let ((bookmark-name (plist-get org-bookmark-names-plist [...] ---[end snip]--- But, when obsoleting `org-capture-bookmark', this problem is solved anyhow: Bookmark creation can be fully controlled using the plist variable (and only there). So, I vote for obsoleting `org-capture-bookmark'. Thanks again for your help! Best regards, Tim.