From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id 8NWpAwwU1GSwWQAASxT56A (envelope-from ) for ; Thu, 10 Aug 2023 00:32:44 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id gGq9AgwU1GRecgEAG6o9tA (envelope-from ) for ; Thu, 10 Aug 2023 00:32:44 +0200 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 40C055F5FD for ; Thu, 10 Aug 2023 00:32:43 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=vodafonemail.de header.s=vfde-mb-mr2-21dec header.b=HcdJjsqh; 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=quarantine) header.from=vodafonemail.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1691620363; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=126dxL9zLgPcNtwEIr365A9UTPgMJkSolEXzjFo/nUU=; b=Vh+QJO63WuFqAiWvgEmVb88D9Qv7qbZ59PfJzR64hTJiBs87XLEYwqY7VkMFm9IZd0jPy3 aG+X29YA4t/CjlFZ4Pj39phVr0XzQyn4+ioBm8PBjzqya4MuiwfBgURlyZMV75IV/q6krM Kx2U4EIOXnNbTzygPKUPAujOh8rjDueko+UKz7F9WwJ0yUUK8sudKDxc+pIBO/hsZtjjik /PBEnS0G4RxO7YS6Bevp8/qErmP1sNwC5lCPNJ7p/BSg8scnG7J0DT+ErugeIHONiquOxN 1WhZDFb/m/twHGDXjaOMd9vqFi4v+NCiMvPaiiC41yvcjxQz8FWjbCWYGdjd7w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=vodafonemail.de header.s=vfde-mb-mr2-21dec header.b=HcdJjsqh; 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=quarantine) header.from=vodafonemail.de ARC-Seal: i=1; s=key1; d=yhetil.org; t=1691620363; a=rsa-sha256; cv=none; b=WuLV/KSFeNMBThnm8dZK3NwWHiHhnSQ5aCMNVGXx6YbPI9DqpfiCnYUtdtc/cELKlMpvg4 DS/eCNBRsoP5RNocNE4Q07p9cd28188VVONN1WKv7CShfCIohAIl3ERxECD+k3X9fEJvKa TIT7YjMmvP16coFdCmpJOvZpNPU2pU9oQEv6vVZVUj4lJAKqUL1RYSwJTzm+4Jp9htUjwd ht5ULQSrfh8kMQ7o6Oh2zuZtnSHxnYa1yM5zaLmIkz6Ontgjb4RCz9LM/bK6Z2akw/UBsi OuAPn6gd1tDqawDHcWNEwN2TK/1dDTsQNJ46Tm0CceaUHugJlcfEf2O8BFDGXg== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qTriR-0005tK-NB; Wed, 09 Aug 2023 18:31: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 1qTriP-0005st-UH for emacs-orgmode@gnu.org; Wed, 09 Aug 2023 18:31:41 -0400 Received: from mr4.vodafonemail.de ([145.253.228.164]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qTriL-0005zB-AN; Wed, 09 Aug 2023 18:31:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vodafonemail.de; s=vfde-mb-mr2-21dec; t=1691620283; bh=126dxL9zLgPcNtwEIr365A9UTPgMJkSolEXzjFo/nUU=; h=Message-ID:Date:User-Agent:Subject:To:References:Content-Language: From:In-Reply-To:Content-Type:From; b=HcdJjsqh0MbMEd78Y0Zns+oCKTylK7W+DK0awWh6fhxwfa5sBtcUN58jkpZn1Pto2 04IFhlzTcO+28EnsEUja/YbmqiYua7T+eOXX184d1T9wqFd3oHUgHtRxaFUDuDoHUj 6HA43sHuIwjiZozpbep4UYxA/V5eY6e75DuPbH7s= 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 mr4.vodafonemail.de (Postfix) with ESMTPS id 4RLlCH00Hwz1y10; Wed, 9 Aug 2023 22:31:22 +0000 (UTC) Received: from [192.168.178.41] (port-92-194-27-48.dynamic.as20676.net [92.194.27.48]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp.vodafone.de (Postfix) with ESMTPSA id 4RLlC13b3hz9s3q; Wed, 9 Aug 2023 22:31:06 +0000 (UTC) Message-ID: <528a8a8c-14a4-4d16-6aa0-1a9d76d45d15@vodafonemail.de> Date: Thu, 10 Aug 2023 00:30:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: Or probably just fix the org-ctags hook functions? (was: Should we accept breaking changes ...) To: Ihor Radchenko Cc: Max Nikulin , Bastien Guerry , emacs-orgmode@gnu.org References: <87o7omg4ie.fsf@alphaville.usersys.redhat.com> <87pm91ngb8.fsf@localhost> <87jzz8f3re.fsf@alphaville.usersys.redhat.com> <87mt43agk6.fsf@localhost> <874jq8ohbr.fsf@localhost> <87bkfip3mo.fsf@gnu.org> <87r0odrkbp.fsf@localhost> Content-Language: de-DE-frami, en-US From: Jens Schmidt In-Reply-To: <87r0odrkbp.fsf@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-type: clean X-purgate: clean X-purgate-size: 5505 X-purgate-ID: 155817::1691620278-72FC286E-B1B9EA10/0/0 Received-SPF: pass client-ip=145.253.228.164; envelope-from=jschmidt4gnu@vodafonemail.de; helo=mr4.vodafonemail.de X-Spam_score_int: -68 X-Spam_score: -6.9 X-Spam_bar: ------ X-Spam_report: (-6.9 / 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, NICE_REPLY_A=-4.14, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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-Queue-Id: 40C055F5FD X-Migadu-Scanner: mx1.migadu.com X-Spam-Score: -9.75 X-Migadu-Spam-Score: -9.75 X-TUID: iFMFUR+mIUgL On 2023-08-08 10:48, Ihor Radchenko wrote: > The situation is a bit more complex. To make it even more complex, here a different point of view. Sorry, I don't have any earlier mails ready I could reply to ... * TL;DR Probably the problem is not the side-effects done by loading =org-ctags=, but rather that these hook function from =org-ctags= try to do their job when the environment is not really ready for them, i.e. when there is no known tag file around. * Full Story I tried to get this thing running. Some issues and observations I came across: 1. When I execute function `org-ctags-create-tags' in file =org-manual.org= of Org =main=, an empty =TAGS= file gets created. Presumably because the asterisk in the generated command line is quoted and the warning generated by that (=cannot open source file "/home/jschmidt/work/org-mode/doc/*"=) is not shown in Emacs: #+begin_example ctags-exuberant --langdef=orgmode --langmap=orgmode:.org \ --regex-orgmode="/<<([^>]+)>>/\1/d,definition/" \ -f "/home/jschmidt/work/org-mode/doc/TAGS" -e -R \ "/home/jschmidt/work/org-mode/doc/*" ^^^ ^^^ #+end_example If I execute the statement on the command line w/o the quotes on the final parameter, I get a non-empty =TAGS= file. Besides that, I somehow doubt that =-R .../*= (=-R= meaning recursive operation) makes actually sense, this probably should be just =-R ...= instead. Besides *that* the following sexps from the function look fishy: #+begin_src emacs-lisp (expand-file-name (concat dir-name "/TAGS")) (expand-file-name (concat dir-name "/*")) #+end_src Why not =(expand-file-name "TAGS" dir-name)=? 2. When one looks at the =TAGS= file generated thus, one immediately notices that the regular expression from parameter =--regex-orgmode= used to match these <> matches also non-targets, like in the following example section: #+begin_example 1. one item 2. <>another item Here we refer to item [[target]]. #+end_example But that is probably intentional or not avoidable. Probably these are even valid Org targets? Ok, that was more or less cheap criticism. Or a bug report? Anyway, what is more interesting is: 3. When one later visits =org-manual.org=,\\ and there is a =TAGS= file in that directory,\\ and =org-ctags= previously has been loaded, then,\\ by virtue of the following snippet from =org-ctags.el=: #+begin_src emacs-lisp (add-hook 'org-mode-hook (lambda () (when (and org-ctags-enabled-p (buffer-file-name)) ;; Make sure this file's directory is added to default ;; directories in which to search for tags. (let ((tags-filename (expand-file-name (concat (file-name-directory (buffer-file-name)) "/TAGS")))) (when (file-exists-p tags-filename) (visit-tags-table tags-filename)))))) #+end_src that =TAGS= file gets automatically visited, meaning that future tag look-ups with =C-c C-o= do not ask about any tag files to load. (Yes, there is again that funny =(expand-file-name (concat ...))= pattern used above.) 4. From that and also from the header documentation: #+begin_example ;; When you click on a link "[[foo]]" and org cannot find a ;; matching "<>" in the current buffer, the tags ;; facility will take over. The file TAGS in the active ^^^^^^^^^^^^^^^^^^^^^^^ ;; directory is examined to see if the ^^^^^^^^^ ;; tags facility knows about "<>" in any other files. ;; If it does, the matching file will be opened and the ;; cursor will jump to the position of "<>" in that ;; file. #+end_example I conclude that the whole =org-ctags= functionality is based on the assumption that a =TAGS= file lives in the working directory of the currently visited Org mode file. Why not test for that condition in the hook functions: #+begin_src emacs-lisp org-ctags-find-tag org-ctags-ask-rebuild-tags-file-then-find-tag org-ctags-rebuild-tags-file-then-find-tag org-ctags-ask-append-topic org-ctags-append-topic org-ctags-ask-visit-buffer-or-file org-ctags-visit-buffer-or-file org-ctags-fail-silently #+end_src in some way or other, probably also testing variable =tags-file-name=, and just skip their execution returning =nil=, if the environment does not seem to be ready for a tag search. Then regular link operation would kick in. Of course, that is all based on educated guesses and ad-hoc poking in the code, not on long-term usage. Is there a known user of =org-ctags= who one could ask? I think the number of people using =org-ctags= is much smaller than the number of people not using it, in particular because of the issue described in the first item. If above assumption is true and hook functions get wrapped as indicated, we could keep the former happy without affecting the latter with unexpected and inexplicable tag file prompts.