emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Or probably just fix the org-ctags hook functions?


From: Jens Schmidt
Subject: Re: Or probably just fix the org-ctags hook functions?
Date: Fri, 11 Aug 2023 23:40:37 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0

On 2023-08-11  19:01, Nick Dokos wrote:

Sure, but we should not reject Jens' proposal just because of this
argument. We can use the suggestions to improve org-ctags itself, after
it is explicitly loaded.

Absolutely.

My disagreement was only with the part that I quoted, in particular
the "Probably the problem is not the side-effects done by loading
=org-ctags= ..."  part: from my POV, that is *exactly* the problem
which I would like to see addressed.

I was trying to provide some facts that could help deciding on this.
And to find some compromise here that would fit all users and sizes.
More notes and another compromise:

- The general discussion in that other branch about all Org libraries,
  ever, is IMO of general interest but doesn't help users that run into
  this issue in short term.  I'd focus on this single library instead to
  get a fix soon, and not only in main.

- I understand both "no-breaking-changes" and "no-side-effects"
  positions.  Personally, I'd even tend to the "no-side-effects"
  position.

- If you run into this issue, the real pain is to understand what's
  going on, since org-ctags might get loaded in surprising ways.  So
  probably we should make that easier.

How about *not* using the current functions

  `org-ctags-find-tag'
  `org-ctags-ask-rebuild-tags-file-then-find-tag'
  `org-ctags-ask-append-topic'

as default value for `org-ctags-open-link-functions', but rather only
function

  `org-ctags-warn-about-enabling-ctags'

defined as follows:

  (defun org-ctags-warn-about-enabling-ctags (&rest _)
    (warn "You enabled (on purpose or by accident) org-ctags.

  If that was not your intention, or if you really only want to open links
  as you always have been used to, use customize to disable function
  `org-ctags-warn-about-enabling-ctags' in variable
  `org-ctags-open-link-functions'.

  Otherwise, you might want to use customize to disable function
  `org-ctags-warn-about-enabling-ctags' in `org-ctags-open-link-functions'
  and instead enable the previous default functions `org-ctags-find-tag',
  `org-ctags-ask-rebuild-tags-file-then-find-tag', and
  `org-ctags-ask-append-topic'.

  Note that in a future Org version automatic enabling of org-ctags might
  be obsoleted, so consider explicitly enabling it by adding

    (require 'org-ctags)
    (org-ctags-enable)

  to your Emacs initialization file if you actually want to use it.")
    (remove-hook 'org-open-link-functions
                 #'org-ctags-warn-about-enabling-ctags))

The last line would take care about getting this warning at most once
per Emacs session.

In addition redefine function `org-ctags-enable' to add a test on
`org-ctags-open-link-functions' as follows:

  (defun org-ctags-enable ()
    (when org-ctags-open-link-functions
(put 'org-mode 'find-tag-default-function 'org-ctags-find-tag-at-point)
      (setq org-ctags-enabled-p t)
      (dolist (fn org-ctags-open-link-functions)
        (add-hook 'org-open-link-functions fn t))))

which makes library loading free of side-effect if variable
org-ctags-open-link-functions equals nil.

That way:

- Users who previously have customized the variable are not affected at
  all by the change.

- All others understand better what's going on and can decide either
  way.  If they decide against org-ctags, and customize the variable
  accordingly, they will have no side-effects from org-ctags in the
  future.

- Any future general solution could resolve this in a more beautiful
  and, um, general way.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]