From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.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 2HBpG/k3ymUiwAAAe85BDQ:P1 (envelope-from ) for ; Mon, 12 Feb 2024 16:23:37 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id 2HBpG/k3ymUiwAAAe85BDQ (envelope-from ) for ; Mon, 12 Feb 2024 16:23:37 +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=ANNN77Xr; 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=1707751417; 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=qQUajYVFC3VcYfyxuZNzNSqs5MwKBa8CRn73nFYAfAtECLfsjRqxqFhlA5Xs9pnO7Onbpz WEmImrDtGN1p6lGGYoLHnKhjCTbH979Qips61P0icMNQwEVEOTFhLX2IVqo+Lje95l64WR m7hI71XDzI2Ct0JQGInCXiPj95IG4tMk0zKUgaD/Amn06K/x33Kgr6G/UsZVqpFwT7FzEr 7RD2xwnb7go1Wr/+PiwymRqautvDQSWWcFLmwC4b0q+jK32E18L0aI1hEAQmOatzXkheVI Y6lHjGG/9tSf14FLILGcRz6orxx8x6ZmR+Fvsubs9+e4vi6mqp6XGx+5a7YDwg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=arcor.de header.s=vfde-mb-mr2-23sep header.b=ANNN77Xr; 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=1707751417; a=rsa-sha256; cv=none; b=OB6wsv6FWxKzQjNulCzygR27PhBc7/q0MjQqxqj3EL5M/cALxdvtG1KnlOQN5llZFSiBkz I8q+9jgcnTDmf2WekFuE32DJmY+vhywWVt3/b4TVV7krIrZzTYYi2U3F40EuPMlOPSQjhW XZ6BnRFOGhQgDDuIqelcskZUPqj4C9v8IstPYmQrmhHR+h41DKS5k7cQfR/lY8Qifjf/zB 2R+bjcG3lvfmC/kQP0MiDlqqWsY+NIGotjDD2srq/VoXSrswTuUKmvLbYArpwgy//5PWjN MIumaxrjnDrvCHJhzFql5oTklJuFv8rEipEHYyAM9Pz0l0pP7ZUTTGbaX6UraA== 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 5A20130955 for ; Mon, 12 Feb 2024 16:23:37 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rZY8E-00048s-Te; Mon, 12 Feb 2024 10:22:06 -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 1rY9AO-0001Zu-N5 for emacs-orgmode@gnu.org; Thu, 08 Feb 2024 13:30:32 -0500 Received: from mr6.vodafonemail.de ([145.253.228.166]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rY9AC-0001mG-1Q for emacs-orgmode@gnu.org; Thu, 08 Feb 2024 13:30:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arcor.de; s=vfde-mb-mr2-23sep; t=1707417007; bh=iqDTTewzqjfWoNSVGS+ucvJ6u9y1JFT1Iqs2pdPkWzU=; h=References:User-agent:From:To:Subject:Date:In-reply-to:Message-ID: Content-Type:From; b=ANNN77Xrs2XyV6pp37HvSY+TKsWr9GZlHsFk71J3+uVYkbZCWCuqlTN6jZ4t0TM7O 67kQxb6XWnUAxJLZLVjib1YdUP23fdhWkAJgritaJMpTWHBPeAywDvqx//9QPY+Nz2 49QK+vst83DJCXM5kemxUCqvSNwe13HAruil4AkE= 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 mr6.vodafonemail.de (Postfix) with ESMTPS id 4TW5BR2B9tz1xvk for ; Thu, 8 Feb 2024 18:30:07 +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 4TW5BM0ZHkzHnHj for ; Thu, 8 Feb 2024 18:29:59 +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 19:09:08 +0100 In-reply-to: <87bk8r2ig1.fsf@localhost> Message-ID: <87bk8qreqm.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::1707417003-431AF740-AB61B15E/0/0 Received-SPF: pass client-ip=145.253.228.166; envelope-from=schlemme-wichmann@arcor.de; helo=mr6.vodafonemail.de 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, FREEMAIL_FROM=0.001, 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-Mailman-Approved-At: Mon, 12 Feb 2024 10:22:00 -0500 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: -5.86 X-Spam-Score: -5.86 X-Migadu-Queue-Id: 5A20130955 X-Migadu-Scanner: mx12.migadu.com X-TUID: S4WdVYvtfoYy 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.