From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:5f26::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id MMR4EA5MfGWjHwEAkFu2QA (envelope-from ) for ; Fri, 15 Dec 2023 13:52:30 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id 4IxVCw5MfGXQMQEAqHPOHw (envelope-from ) for ; Fri, 15 Dec 2023 13:52:30 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=UQ7coOLq; 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"; dmarc=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1702644750; h=from:from:sender:sender: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: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=45vUbyyjeSzTBY5BX5a+lpQJeiCT/42DjKHOVpe6A6Q=; b=qVxJr7lhQtXcKBXZh2AulgDtQtWPe70iwK6SZt+zOVn8Pfg8LHYj3I69I4a3/tuxDU8dDt 6EXNL/UdPkW89SufJXM6xbExOF1xO+dM4uYO1JzOzcctEmHSHsb0ynDbrETiA5bIMkb2El 5c/FPWHQ5E96Z9JlWF3fCHq9yN5X8H85QRaGxqQXMNSalIL1ih5JdVolqR7lfQCpuiiXzr TFCZV0/FcEsVgJXGxCZnrg9lrj5DFvThUjtMVsneXJp46FUknc5vifJIj5EwMgfTc0UcSe lRr29wzOD6IYfXzl7DPlCrjPfg5xldxO42UYf8RqjNAEKF9Z32hbHc5T00WKDA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1702644750; a=rsa-sha256; cv=none; b=BBhxz3ZD38PjnggvuQp07WY+I/PFyqfG0zlJ6lxJu4Jm7p+J4/eGXCPDqa3gVg4jRPas0G 7DauTsudSAj1Oe2QYpePKDshv/xRHsPxgdBa8J+pDVIlQCmcYEsffo6zkZe01d6J7lVLWp kViMSSxK5+RRESooqSzDcl9Ea8yf7FvspjaLN0OWltgGkLK7ghUBskMXhITr2GlkvJM1tg 3d9E00p1sfSIrf4OADs5kc7TObJJ+seGUpcFkr+n71AMBwJg6P+i1wn35WrKX+CmKmMvaq 4vq3O3PbRoLsEV41FvEVXdvbOhcNlb+5yWkwR9W+uHEdQfFkupvaDsZYEhYV8w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=UQ7coOLq; 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"; dmarc=pass (policy=none) header.from=posteo.net 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 7C11951EFD for ; Fri, 15 Dec 2023 13:52:29 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rE7fq-0000pk-EN; Fri, 15 Dec 2023 07:52:14 -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 1rE7fo-0000pZ-BS for emacs-orgmode@gnu.org; Fri, 15 Dec 2023 07:52:12 -0500 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rE7fl-0000mt-UQ for emacs-orgmode@gnu.org; Fri, 15 Dec 2023 07:52:12 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id C7433240103 for ; Fri, 15 Dec 2023 13:52:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1702644726; bh=C3SWMLuQBgALxD5fYHjnuxycYdvDfrinnBRc/fNss6k=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=UQ7coOLqj1hTWWF6yklZnDF25x6unK5w+ZSmaK0qETkdTFwL1MTnockVWWoGI2gWA MYbxBxfUoeZIA64KX+MfLUrEkIUl7cCV89dMrIJwrmg9+cAssGmz4loezNwZx6deQ4 TeEbT/OUch8gJJaj2tDgYXzTtBTBDDOhSi8JvYP+qCb6KEVgoW2V8Kf/nEA0vjozj9 ttalUTw26hkjrW2bBZo89csgni4qt+2TlYyqwqvYjA6bTNcZkf28S9rsDs9+JJ1fyf PSkOT962+0VDmsmz/444ua9NN6mFolETXMWz2Kw/g03mCxjz7Gv2uFbsVH3kWiFFl7 jrLn4jxExyFMg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Ss8Hp272sz9rxL; Fri, 15 Dec 2023 13:52:06 +0100 (CET) From: Ihor Radchenko To: Rick Lupton Cc: "Y. E." Subject: Re: [PATCH] org-id: allow using parent's existing id in links to headlines In-Reply-To: <2cdfefbf-e9e3-4aeb-a410-1ff3a9d6168e@app.fastmail.com> References: <118435e8-0b20-46fd-af6a-88de8e19fac6@app.fastmail.com> <87edkwsafe.fsf@localhost> <87cywh2ad6.fsf@localhost> <87jzpmqiy0.fsf@localhost> <2cdfefbf-e9e3-4aeb-a410-1ff3a9d6168e@app.fastmail.com> Date: Fri, 15 Dec 2023 12:55:14 +0000 Message-ID: <87zfybzkul.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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-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: -9.38 X-Spam-Score: -9.38 X-Migadu-Queue-Id: 7C11951EFD X-Migadu-Scanner: mx11.migadu.com X-TUID: wbznr4KmZ+tb "Rick Lupton" writes: >>> +(defcustom org-id-link-use-context t >> ... >> It does not look like integer value is respected in the patch. > > You're right. Do you have a preference between > > (a) sticking to this docstring, which creates the possibility of using different numbers of lines for id: and file: links' context, and makes the code slightly more complicated, but keeps the meaning of `org-link-context-for-files' specifically `for files'; or > > (b) Always use `org-link-context-for-files' to set the number of lines of context used for all links; `org-id-link-use-context' is just a boolean. The code is simpler. > > ? I think that (b) makes sense. There is no reason to make the customization yet more granular and complex when there is no clear need. We can always do it later, if necessary, anyway. >>> - (let ((id (org-entry-get epom "ID"))) >>> + (let ((id (org-entry-get epom "ID" inherit))) >> >> This makes your description of INHERIT argument slightly inaccurate - for >> `org-entry-get', INHERIT can also be a special symbol 'selective. > > Good point; I think the answer is to force INHERIT to t or nil, rather than documenting and continuing to accept 'selective (when INHERIT is used, it should definitely take effect). Agree. >>> + ;; Prefix to `org-store-link` negates preference from `org-id-link-use-context`. >>> + (when (org-xor current-prefix-arg org-id-link-use-context) >> >> This is not reliable. `org-id-store-link' may be called from a completely >> different command, not `org-store-link'. Then, the effect of prefix >> argument will be unexpected. You should instead process prefix argument >> right in `org-store-link' by let-binding `org-id-link-use-context' >> around the call to `org-id-store-link'. > > Now that `org-id-store-link' is called via :store link property, `org-store-link` does not have special logic for org-id, which I thought was an improvement, so it would be a step backwards to add in special logic for `org-id-link-use-context'? > > Instead, I think this logic could be in `org-id-store-link-maybe' as above. That is, it is safe to take account of `current-prefix-arg' within a link :store function, and assume it represents prefix args as used with `org-store-link'? No, it is generally not safe. For a different reason. Let me illustrate with an example: (defun yant/test2 () (message "current-prefix-arg: %S" current-prefix-arg)) (defun yant/test (arg) (interactive "P") (yant/test2)) When you call M-x yant/test, you will see "current-prefix-arg: nil". However, when you call C-u M-x yant/test, you will see "current-prefix-arg: (4)". Similar logic applies to the non-interactive calls to `org-store-link'. If some Elisp code implements a command like (defun yant/my-command (arg) (interactive "P") (org-store-link nil)) then, `org-store-link' may call `org-id-store-link-maybe' and `org-id-store-link-maybe' will still "see" the top-level prefix argument passed to `yant/my-command' - the prefix argument that has nothing at all to do with prefix arguments of `org-store-link'. Conclusion: It is unsafe to use `current-prefix-arg' value. We need to pass this information some other way. The way I proposed is actually not any special for ID links. What I meant it to let-bind `org-link-context-for-files' around the whole call to `org-store-link-functions', so that the custom :store functions will get access to the adjusted value of `org-link-context-for-files'. Does this explanation make more sense? >>> + (pcase (org-link-precise-link-target id-location) >> >> Why not passing the RELATIVE-TO argument? > > The `id-location' is the RELATIVE-TO argument. Or do I misunderstand you? I just did not notice ID-LOCATION :facepalm: >>> + (when option >>> + (org-link-search option)) >>> (org-fold-show-context))) >> >> `org-link-search' does not always search from point. So, you may end up >> matching, for example, a duplicate CUSTOM_ID above. >> Moreover, regular expression match option will be broken - >> `org-link-search' creates sparse tree in the whole buffer and will >> disregard the ID part of the link. I suspect that you will need to make >> dedicated modifications to `org-link-search' as well in order to >> implement opening ID links with search option cleanly. > > Thanks, yes. It looks to me (from the code and some testing) that narrowing to the target heading first before calling `org-link-search' does the right thing. Was there a particular reason you thought `org-link-search' would need to be changed? Because a lot of the code (except some part `org-link-open') assumes that `org-link-search' searches the whole buffer, not just the narrowed part. But that's not your problem - I will update the docstring of `org-link-search' to explicitly specify that it is searching within the accessible portion of the buffer and update the callers to account for this. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=89164e605 https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5c543cd9d https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=cb71bde7c https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=63ef7b924 But does your code do narrowing? I did not notice it. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at