From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id nSlnH3fgG2TKfgEASxT56A (envelope-from ) for ; Thu, 23 Mar 2023 06:15:35 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id IBCAHXfgG2SaPAAAauVa8A (envelope-from ) for ; Thu, 23 Mar 2023 06:15:35 +0100 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 1976C2E973 for ; Thu, 23 Mar 2023 06:15:34 +0100 (CET) Authentication-Results: aspmx1.migadu.com; dkim=none; 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=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1679548535; 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:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=1gcdGbzWB64gKdYBNLWVx348HFMAMcTeDOtNYbvLZyM=; b=LAaUPELHNnXXQrejRbLhiZnD1ePmifQv41Zms23PbRiIBuyK8Y7Jy1GygucxtcYNldqlQd syct6IvE+YH0+TuCmdGliPJK2q3XrEoSBTHNV7AM0EI8OBwZLQt+O9F+YvOX135pReeJ+Q ai5/xfbU7k27HCeDYmd9hSiJTFvf86D0nQWhVx+ozmd2WjxDN/pA+AlLQmHHD4Unj2KXVS wIS4Krp9cNXZAcIlBU8joOvHUBZyYJ/Zx/DT+5Hm5vJuD4bZbTL5SpZ898qe9ZyRGyXJql GLREfiddu/TN9fk/wMBf0K74LMUYRvSkFao5tZ1ypSu904luPh6rMoDeSwUgTQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1679548535; a=rsa-sha256; cv=none; b=Topei8BR75IuxbrTiTrTNlBzT2tKpxFafDZHVBYj9ivWEBSQNR0Hq8d/Vt2BIIS71wxjse FjUarAWV/yGF0AVlWQ/pVW0ldg5HFG6oCulsqDds/KujQWn2J1u8AFzl7ai+6QY4kichl7 iXSjKWP4Udjm4z5rUpdPcthO3xWVs057O1jS37G86JxQQNI64z1wt1QcsKkRBG46iLatqY jZy9iCQrXy6Tx/ubphJovpieRTWUIHs3y0b1dOLFF9PaH1GOeiTZ76zQIa1xtpSn78zb7t 3kppBKjNg5vlzy2ejXr905gf8pCkHmvh6hM82Ju3bViP6cghQzN82OgQ6EZYEQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; 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=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pfDHe-0003vD-Ul; Thu, 23 Mar 2023 01:14:43 -0400 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 1pfDHd-0003v4-F0 for emacs-orgmode@gnu.org; Thu, 23 Mar 2023 01:14:41 -0400 Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pfDHb-00056P-Dc for emacs-orgmode@gnu.org; Thu, 23 Mar 2023 01:14:40 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1pfDHZ-0007Q9-JY for emacs-orgmode@gnu.org; Thu, 23 Mar 2023 06:14:37 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Nick Dokos Subject: Re: org-ctags land grab Date: Thu, 23 Mar 2023 01:14:29 -0400 Message-ID: <87jzz8f3re.fsf@alphaville.usersys.redhat.com> References: <87o7omg4ie.fsf@alphaville.usersys.redhat.com> <87pm91ngb8.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:HdOK7QVu8shD2IZh29R+yiyaeGU= Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 5 X-Spam_score: 0.5 X-Spam_bar: / X-Spam_report: (0.5 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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: X-Migadu-Queue-Id: 1976C2E973 X-Spam-Score: -1.44 X-Migadu-Spam-Score: -1.44 X-Migadu-Scanner: scn0.migadu.com 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-TUID: oP1kHNidZYLZ Ihor Radchenko writes: > Nick Dokos writes: > >> `org-ctags' unilaterally sets the hook `org-open-link-functions' to a >> bunch of org-ctags functions and enables itself by default. That has >> the unfortunate consequence of invalidating the documentation for >> internal CUSTOM_ID links - see >> >> https://emacs.stackexchange.com/questions/76351/how-to-follow-an-internal-link-in-recent-org-mode > > As documented in the top comment of org-ctags.el, the default behaviour > of C-c C-o is modified as you observe: > > ;; By default, with org-ctags loaded, org will first try and visit the tag > ;; with the same name as the link; then, if unsuccessful, ask the user if > ;; he/she wants to rebuild the 'TAGS' database and try again; then ask if > ;; the user wishes to append 'tag' as a new toplevel heading at the end of > ;; the buffer; and finally, defer to org's default behavior which is to > ;; search the entire text of the current buffer for 'tag'. > >> I proposed a work-around, but it seems to me that `org-ctags' >> functionality should be opt-in and there should be a way to turn it >> off. > > It is off by default. It is off until org-ctags is loaded. *When* it is loaded, it runs `(org-ctags-enable)' and the behavior changes. Now I'm not loading it explicitly, but nevertheless, *somebody* does because it goes ahead and mucks with my `org-open-link-functions'. One clue was that it does not happen in 28.2 (which is the version in Fedora 36 and 37) but it *does* happen in a 30.0.50 Emacs built from upstream sources. So I ran some tests, all with -Q so my init file is out of the picture. It turns out that it is enough to ask for help on an Org variable to have `org-ctags' loaded! I put a watch on `org-open-link-functions' and did `C-h v org-latex-pdf-process': it stopped once on setting it to nil and it stopped again with this backtrace (I elided long lines but I left the relevant portion of the one that mentions `org-ctags'): --8<---------------cut here---------------start------------->8--- Debugger entered--setting org-open-link-functions to (org-ctags-find-tag): debug--implement-debug-watch(org-open-link-functions (org-ctags-find-tag) set nil) set-default(org-open-link-functions (org-ctags-find-tag)) add-hook(org-open-link-functions org-ctags-find-tag t) org-ctags-enable() byte-code("\300 \210\301\302!\207" [org-ctags-enable provide org-ctags] 2) load("org-ctags" noerror nomessage) help--load-prefixes((("org-" "ox-latex" "ox" "org-src" "org-refile" "org-protocol" "org-plot" "org-pcomplete" "org-mouse" "org-macs" "org-list" "org-keys" "org-habit" "org-faces" "org-ctags" ... help--symbol-completion-table("org-latex-pdf-process" ... test-completion("org-latex-pdf-process" help--symbol-completion-table ... completion--complete-and-exit(20 41 exit-minibuffer ... completion-complete-and-exit(20 41 exit-minibuffer) minibuffer-complete-and-exit() funcall-interactively(minibuffer-complete-and-exit) call-interactively(minibuffer-complete-and-exit nil nil) command-execute(minibuffer-complete-and-exit) read-from-minibuffer("Describe variable: " nil ... completing-read-default("Describe variable: " help--symbol-completion-table ... completing-read("Describe variable: " help--symbol-completion-table ... byte-code(... call-interactively(describe-variable nil nil) command-execute(describe-variable) --8<---------------cut here---------------end--------------->8--- As you see, `help--load-prefixes' loads `org-ctags'. If you look at the `help-definition-prefixes' radix tree, `org-ctags' is subsumed under the `org-' prefix, so any lookup with that prefix will end up loading it (and therefore enabling it). The reason it does not happen in 28.2 is that it is only under the `org-ctags` prefix. It seems to me that `org-ctags' should be registered under the `org-ctags' prefix only, just like in 28.2 (the registration is in `org-loaddefs.el' but I don't know how it ends up there. I guess `org-fixup.el' is doing it, but I didn't chase it any further). I also think that loading `org-ctags' should not automatically enable it: it should require the user to explicitly run `org-ctags-enable' to do that. That way, if there is a mechanism that loads it surreptitiously, it wouldn't cause the confusion that it causes now. That would require documentation changes, but it would avoid unpleasant surprises, and preserve some toes even if users load it accidentally. Eventually, it might be nice to provide a disabling function as well, although the workaround in the SE post works well enough for now. Maybe the thing to do is to turn it into a proper minor mode. Thoughts? -- Nick