From: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: Max Nikulin <manikulin@gmail.com>, Bastien Guerry <bzg@gnu.org>,
emacs-orgmode@gnu.org
Subject: Re: Or probably just fix the org-ctags hook functions? (was: Should we accept breaking changes ...)
Date: Thu, 10 Aug 2023 00:30:57 +0200 [thread overview]
Message-ID: <528a8a8c-14a4-4d16-6aa0-1a9d76d45d15@vodafonemail.de> (raw)
In-Reply-To: <87r0odrkbp.fsf@localhost>
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 <<targets>> matches also
non-targets, like in the following example section:
#+begin_example
1. one item
2. <<target>>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 "<<foo>>" 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 "<<foo>>" in any other files.
;; If it does, the matching file will be opened and the
;; cursor will jump to the position of "<<foo>>" 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.
next prev parent reply other threads:[~2023-08-09 22:32 UTC|newest]
Thread overview: 112+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-21 3:36 org-ctags land grab Nick Dokos
2023-03-21 16:40 ` Rudolf Adamkovič
2023-03-22 12:03 ` Ihor Radchenko
2023-03-23 5:14 ` Nick Dokos
2023-03-23 10:49 ` Ihor Radchenko
2023-03-23 14:50 ` Max Nikulin
2023-03-25 17:45 ` [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? (was: org-ctags land grab) Ihor Radchenko
2023-03-27 15:14 ` [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? Max Nikulin
2023-03-28 10:02 ` Ihor Radchenko
2023-03-27 16:10 ` [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? (was: org-ctags land grab) Dr. Arne Babenhauserheide
2023-03-28 9:55 ` Ihor Radchenko
2023-08-08 4:19 ` [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? Bastien Guerry
2023-08-08 8:48 ` Ihor Radchenko
2023-08-08 13:29 ` Bastien Guerry
2023-08-09 7:48 ` Max Nikulin
2023-08-10 19:50 ` Nick Dokos
2023-08-11 7:36 ` Ihor Radchenko
2023-08-11 9:44 ` Ihor Radchenko
2023-08-12 12:46 ` Bastien Guerry
2023-08-12 22:18 ` Samuel Wales
2023-08-13 8:59 ` Ihor Radchenko
2023-08-14 0:57 ` Samuel Wales
2023-08-14 10:34 ` Ihor Radchenko
2023-08-14 13:19 ` Fraga, Eric
2023-08-22 15:15 ` Bastien Guerry
2023-08-23 9:33 ` Ihor Radchenko
2023-08-24 11:39 ` Bastien Guerry
2023-08-24 11:44 ` Ihor Radchenko
2023-08-24 12:08 ` Bastien Guerry
2023-08-24 12:15 ` Ihor Radchenko
2023-08-24 12:36 ` Bastien Guerry
2023-08-24 12:40 ` Ihor Radchenko
2023-08-24 12:48 ` Bastien Guerry
2023-08-24 12:56 ` Ihor Radchenko
2023-08-24 13:01 ` Russell Adams
2023-08-24 13:33 ` Ihor Radchenko
2023-08-24 13:41 ` Russell Adams
2023-08-24 13:47 ` Ihor Radchenko
2023-08-24 13:02 ` Bastien Guerry
2023-08-24 13:36 ` Ihor Radchenko
2023-08-24 13:43 ` Russell Adams
2023-08-25 9:16 ` Ihor Radchenko
2023-08-24 14:08 ` Bastien Guerry
2023-08-25 2:59 ` spookygostee
2023-08-25 9:53 ` Ihor Radchenko
2023-08-25 9:44 ` [DISCUSSION] Re-design of inlinetasks (was: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?) Ihor Radchenko
2023-08-25 17:58 ` [DISCUSSION] Re-design of inlinetasks Juan Manuel Macías
2023-08-26 10:58 ` Ihor Radchenko
2023-08-26 11:42 ` Juan Manuel Macías
2023-08-26 12:33 ` Ihor Radchenko
2023-08-26 14:21 ` Juan Manuel Macías
2023-08-26 16:33 ` Ihor Radchenko
2023-08-26 17:31 ` Juan Manuel Macías
2023-08-26 17:43 ` Ihor Radchenko
2023-08-26 19:19 ` Juan Manuel Macías
2023-08-27 9:21 ` Ihor Radchenko
2023-08-27 17:25 ` Juan Manuel Macías
2023-08-31 9:15 ` Ihor Radchenko
2023-08-26 18:01 ` Russell Adams
2023-08-29 13:00 ` Russell Adams
2023-08-30 11:49 ` Alain.Cochard
2023-08-30 12:36 ` Russell Adams
2023-08-30 14:06 ` Alain.Cochard
2023-08-30 14:31 ` Russell Adams
2023-08-30 14:39 ` Alain.Cochard
2023-08-30 15:08 ` Russell Adams
2023-08-30 15:13 ` Russell Adams
2023-08-30 18:32 ` Ihor Radchenko
2023-08-24 12:53 ` [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? Russell Adams
2023-08-24 13:04 ` Ihor Radchenko
2023-08-24 13:11 ` Russell Adams
2023-08-24 13:41 ` Ihor Radchenko
2023-08-24 13:49 ` Russell Adams
2023-08-25 9:18 ` Ihor Radchenko
2023-08-24 14:20 ` Russell Adams
2023-08-24 13:23 ` tomas
2023-08-24 13:29 ` Ihor Radchenko
2023-08-24 13:36 ` Russell Adams
2023-08-24 13:44 ` Ihor Radchenko
2023-08-24 14:00 ` Russell Adams
2023-08-25 2:48 ` spookygostee
2023-08-25 9:52 ` Ihor Radchenko
2023-08-24 13:50 ` tomas
2023-08-25 9:49 ` Ihor Radchenko
2023-08-24 12:11 ` Russell Adams
2023-08-24 12:21 ` Ihor Radchenko
2023-08-24 14:43 ` Max Nikulin
2023-08-24 23:07 ` Samuel Wales
2023-08-24 23:23 ` Samuel Wales
2023-08-24 23:24 ` Samuel Wales
2023-08-25 9:56 ` Ihor Radchenko
2023-08-25 9:56 ` Ihor Radchenko
2023-08-26 8:59 ` Fraga, Eric
2023-08-26 12:30 ` Ihor Radchenko
2023-08-27 13:16 ` Fraga, Eric
2023-08-22 15:40 ` Russell Adams
2023-08-13 8:53 ` [DISCUSSION] The future of org-mouse.el and org-inlinetask.el (was: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?) Ihor Radchenko
2023-08-13 9:33 ` [DISCUSSION] The future of org-mouse.el and org-inlinetask.el Bastien Guerry
2023-08-13 10:29 ` Ihor Radchenko
2023-08-14 7:48 ` [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading? Tom Gillespie
2023-08-15 14:10 ` Timothy
2023-08-15 14:38 ` Russell Adams
2023-08-15 15:21 ` Ihor Radchenko
2023-08-15 18:58 ` Tom Gillespie
2023-08-16 10:24 ` Ihor Radchenko
2023-08-09 22:30 ` Jens Schmidt [this message]
2023-08-10 19:56 ` Or probably just fix the org-ctags hook functions? Nick Dokos
2023-08-11 7:37 ` Ihor Radchenko
2023-08-11 17:01 ` Nick Dokos
2023-08-11 21:40 ` Jens Schmidt
2023-08-11 21:48 ` Ihor Radchenko
2023-08-11 22:43 ` Jens Schmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=528a8a8c-14a4-4d16-6aa0-1a9d76d45d15@vodafonemail.de \
--to=jschmidt4gnu@vodafonemail.de \
--cc=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=manikulin@gmail.com \
--cc=yantar92@posteo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.