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 mKQFGD06gGUlTwEAkFu2QA (envelope-from ) for ; Mon, 18 Dec 2023 13:25:33 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id ULYiEz06gGW3aQAAqHPOHw (envelope-from ) for ; Mon, 18 Dec 2023 13:25:33 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=hKsw2whc; 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=1702902333; 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=nWNW3zIJaddUVS2xQAA4qg6Z+/9SpS5DiyrlsrN4yVk=; b=mqrdrYTUaZ98m/FpUbe5F2v33oC0xxtq3CrCZZyhq1Y+iOX4xuyF4b6ZZBePCrOEm9AnGE u6BbyEwQw8BeI7NtVkP+FLO7UY/qPUG8TnP9IAjGSSxUPCOLuZpGynDfHfzSMyUwtXYL4l j7iv8HRhM1zlayK36plWVwtmH1cSUeY0Qk2CxkKIj0zPHEc94s4I1/vGEP76CplcHqCfpX JfHWfi0lm+wGHwsgbuXHOQgi+vs5Jrd3xECuRgzEF3q6SC5XBQwWdC6L9oP8OSBAgMkXIr H4pFnvioAZKZTBTNUCvByZwLmYjCvCzSeT6OBNpxLsRFSRW49P95axBAkgHscw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=hKsw2whc; 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-Seal: i=1; s=key1; d=yhetil.org; t=1702902333; a=rsa-sha256; cv=none; b=UpHDmrglmiCa2O7RYUaim/i85KIljR84c/MZFWZ/PGh7e0BI31JVCNoohEzSwCDS9ehMb/ Cdlxtyt34j3xV3AE0m8vZfwAzslz9zozz49EKLCpMx2OotQPfVRS2Ixa9cCnI9VHXC+6A3 fflRxUFiFc01QA4yKkXGyYYKGUfq30yek++RfZfO9gUDINsMU+rzYUqh1KxnMV3CYdb0G9 CeAyh9FUTljr9KaQxlkGe1xwFFfKEcCSTjIRldvgNivn954gu5LqOR/SHMJxJcCtQjbwvl mSoM2fmSPW38ovr/Ni+3xtJyxdxExiRVjD9r00t9NIgPh7jxsYequXmPIa6Zdg== 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 40C6564D10 for ; Mon, 18 Dec 2023 13:25:32 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rFCfZ-0000hj-74; Mon, 18 Dec 2023 07:24:25 -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 1rFCfY-0000hT-26 for emacs-orgmode@gnu.org; Mon, 18 Dec 2023 07:24:24 -0500 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rFCfT-0005Lc-4H for emacs-orgmode@gnu.org; Mon, 18 Dec 2023 07:24:22 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id B2D00240027 for ; Mon, 18 Dec 2023 13:24:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1702902256; bh=hLN5t2vekmJOmRNEh3WmrRYECv27DzavU5ctJA90IIw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=hKsw2whcttwj8AjjyDNm4YCIcjnE9zAiNOEbrwmieG7+Xfdcv6QvEJjQp/Syao2or /yw7+ddx/iWOg5zsnzo4xPb3qH43zbUrvbQGlP89zFo57sfUFhlzcIzSy+GmG8CcIL D47lGv17q0+T9oeHSc7YD+F163rUUfSB6A8xu9B0oHPX37nTLyOEXLGX3igXb/pkWV wA8+VsAzG2bPJEtQdWe5wbDLrjkE05Vy4ASQcPhhpfbBiMEwqy5kIdXpBQ0UyWNcw0 ZUtSbhsjepDbCjPBrCB23Vnn5qcuqvisTLPRmLrkl+kbJ3ldekE3M1k7/RSFSGdPKB WaQqUj41loRaw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4StzXH6220z9rxK; Mon, 18 Dec 2023 13:24:15 +0100 (CET) From: Ihor Radchenko To: Rick Lupton Cc: "Y. E." Subject: Re: [PATCH v2] org-id: allow using parent's existing id in links to headlines In-Reply-To: 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> <87zfybzkul.fsf@localhost> <3c5737c8-f489-4144-a27f-c0e0527c79c0@app.fastmail.com> <87bkaqcjpz.fsf@localhost> Date: Mon, 18 Dec 2023 12:27:25 +0000 Message-ID: <87msu7r902.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.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-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -9.44 X-Spam-Score: -9.44 X-Migadu-Queue-Id: 40C6564D10 X-Migadu-Scanner: mx10.migadu.com X-TUID: qIzo7YUQc9/r "Rick Lupton" writes: > Please find attached updated patch which I think addresses all the points discussed. Let me know if you see any further changes needed. Thanks! I played around with the patch a bit and found a couple of rough edges: 1. When I try to open a link to non-existing search target, like , I get a query to create a new heading. If I reply "yes", a new heading is created. However, the heading is created at the end of the file and is always level 1, regardless of the "some-id" parent context. It would make more sense to create a new heading at the end of the id:some-id subtree. 2. Consider the following setting: (setq org-id-link-consider-parent-id t) (setq org-id-link-to-org-use-id 'create-if-interactive-and-no-custom-id) Then, create the following Org file * Sub * Parent here ** This is test :PROPERTIES: :ID: fe40252e-0527-44c1-a990-12498991f167 :END: *** Sub :PROPERTIES: :CUSTOM_ID: subid :END: When you M-x org-store-link, the stored link has ::*Sub instead of the expected ::#subid 3. Consider (setq org-id-link-consider-parent-id t) (setq org-id-link-to-org-use-id t) Then, create a new empty Org file M-x org-store-link with create a top-level properties drawer with ID and store the link. However, that link will not be a simple ID link, but also have ::PROPERTIES search string, which is not expected. More inline comments below. > + #+vindex: org-id-link-consider-parent-id > + When ~org-id-link-consider-parent-id~ is ~t~, parent =ID= properties > + are considered. This allows linking to specific targets, named > + blocks, or headlines (which may not have a globally unique =ID= > + themselves) within the context of a parent headline or file which > + does. It would be nice to add an example, similar to what you did in the docstring. > -(defun org-man-store-link () > +(defun org-man-store-link (&optional _interactive?) > "Store a link to a man page." > (when (memq major-mode '(Man-mode woman-mode)) > ;; This is a man page, we do make this link. > @@ -21312,13 +21324,15 @@ A review of =ol-man.el=: Please, update the actual built-in :store functions in lisp/ol-*.el to handle the new optional argument as well. > +**** =org-link= store functions are passed an ~interactive?~ argument > + > +The ~:store:~ functions set for link types using > +~org-link-set-parameters~ are now passed an ~interactive?~ argument, > +indicating whether ~org-store-link~ was called interactively. Please also explain that the existing functions are not broken. > +*** ~org-id-store-link~ now adds search strings for precise link targets > + > +This new behaviour can be disabled generally by setting > +~org-id-link-use-context~ to ~nil~, or when storing a specific link by > +passing a prefix argument to ~org-store-link~. universal argument. There are several possible prefix arguments in `org-store-link', but only C-u (universal argument) will give the described effect. Also, won't the behavior be _toggled_ by the universal argument? > +When using this feature, IDs should not include =::=, which is used in > +links to indicate the start of the search string. For backwards > +compability, existing IDs including =::= will still be matched (but > +cannot be used together with precise link targets). Please add an org-lint checker that warns about such IDs and mention this checker in the above. Also, this paragraph belongs to "Breaking changes", not "new and changed options". > +*** New option ~org-id-link-consider-parent-id~ to allow =id:= links to parent headlines > + > +For =id:= links, when this option is enabled, ~org-store-link~ will > +look for ids from parent/ancestor headlines, if the current headline > +does not have an id. > + > +Combined with the new ability for =id:= links to use search strings > +for precise link targets (when =org-id-link-use-context= is =t=, which > +is the default), this allows linking to specific headlines without > +requiring every headline to have an id property, as long as the > +headline is unique within a subtree that does have an id property. > + > +By giving files top-level id properties, links to headlines in the > +file can be made more robust by using the file id instead of the file > +path. Please, provide an example here as well. > +(defun org-link--try-link-store-functions (interactive?) > + "Try storing external links, prompting if more than one is possible. > + > +Each function returned by `org-store-link-functions' is called in > +turn. If multiple functions return non-nil, prompt for which > +link should be stored. > + > +Return t when a link has been stored in `org-link-store-props'." Please document INTERACTIVE? argument in the docstring. > + (let ((results-alist nil)) > + (dolist (f (org-store-link-functions)) > + (when (condition-case nil > + (funcall f interactive?) > + ;; XXX: The store function used (< Org 9.7) to accept no > + ;; arguments; provide backward compatibility support for > + ;; them. Use FIXME, not XXX. (I have no idea why it is XXX in the existing code). > +(defun org-link-precise-link-target (&optional relative-to) > + "Determine search string and description for storing a link. > + > +If a search string is found, return cons cell (SEARCH-STRING > +. DESC). Otherwise, return nil. > + > +If there is an active region, the contents is used (see > +`org-link--context-from-region'). It is not clear from this sentence whether the contents is used for SEARCH-STRING of DESC. > +In org-mode buffers, if point is at a named element (e.g. a > +source block), the name is used. If within a heading, the current > +heading is used. Please use double space between sentences. > +Optional argument RELATIVE-TO specifies the buffer position where > +the search will start from. If the search target that would be > +returned is already at this location, return nil to avoid > +unnecessary search strings (for example, when using search > +strings to find targets within org-id links)." It is not clear what will happen if RELATIVE-TO is before/after point. > - (let (link cpltxt desc search custom-id agenda-link) ;; description > + (let ((org-link-context-for-files (org-xor org-link-context-for-files > + (equal arg '(4)))) > + link cpltxt desc search custom-id agenda-link) ;; description > (cond > ;; Store a link using an external link type, if any function is > - ;; available. If more than one can generate a link from current > - ;; location, ask which one to use. > + ;; available. If more than one can generate a link from > + ;; current location, ask which one to use. Negate > + ;; `org-context-in-file-links' when given a single prefix arg. The part of the comment about negation, should probably be moved near the let binding of `org-link-context-for-files'. > +For example, given this org file: > + > +* Parent > +:PROPERTIES: > +:ID: abc > +:END: > +** Child 1 > +** Child 2 > + > +With `org-id-link-consider-parent-id' set to t, storing a link > +with point at \"Child 1\" will produce a link \"id:abc\" to > +\"Parent\". This is actually confusing. May we only consider parent when `org-id-link-use-context' is enabled? > -(defun org-id-get (&optional epom create prefix) > +(defun org-id-get (&optional epom create prefix inherit) > "Get the ID property of the entry at EPOM. > EPOM is an element, marker, or buffer position. > If EPOM is nil, refer to the entry at point. > If the entry does not have an ID, the function returns nil. > +If INHERIT is non-nil, parents' IDs are also considered. > However, when CREATE is non-nil, create an ID if none is present already. > PREFIX will be passed through to `org-id-new'. > In any case, the ID of the entry is returned." What about both CREATE and INHERIT being non-nil? > +;;;###autoload > +(defun org-id-store-link-maybe (&optional interactive?) > + "Store a link to the current entry using its ID if enabled. > + > +The value of `org-id-link-to-org-use-id' determines whether an ID > +link should be stored, using `org-id-store-link'. > + > +Assume the function is called interactively if INTERACTIVE? is > +non-nil." > + (interactive "p") Do we really need to make it interactive? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at