[PATCH] Add support for shortdoc link type

[Bruno Cardoso]

Hi all,

This patch adds support for "shortdoc:" links.

Best,

Bruno.

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 8dbc3292d..cfe894448 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -1357,6 +1357,10 @@ place the entry in the ~Misc~ category if ~TEXINFO_DIR_CATEGORY~ is missing.
 =TEXINFO_DIR_TITLE= is renamed to =TEXINFO_DIR_NAME=.
 The old name is obsolete.
 
+*** =ol.el=: Support for ~shortdoc~ link type
+
+Add support for storing and inserting links to ~shortdoc~ groups.
+
 ** New functions and changes in function arguments
 *** New optional argument =UPDATE-HEADING= for ~org-bibtex-yank~
 
diff --git a/lisp/ol.el b/lisp/ol.el
index f6d656982..f0088ae5f 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -1598,6 +1598,29 @@ PATH is a symbol name, as a string."
  :follow #'org-link--open-help
  :store #'org-link--store-help)
 
+ "shortdoc" link type
+
+(defun org-link--open-shortdoc (group _)
+  "Open a \"shortdoc\" type link.
+GROUP is a symbol name."
+  (if (assoc (intern group) shortdoc--groups)
+  (shortdoc group)
+(user-error "Unknown shortdoc group: %s" group)))
+
+(defun org-link--store-shortdoc ( _interactive?)
+  (when (eq major-mode 'shortdoc-mode)
+(let* ((buffer (buffer-name))
+   (group (when (string-match "*Shortdoc \\(.*\\)\\*" buffer)
+(match-string 1 buffer
+  (when (assoc (intern group) shortdoc--groups)
+(org-link-store-props :type "shortdoc"
+  :link (format "shortdoc:%s" group)
+  :description nil)
+
+(org-link-set-parameters "shortdoc"
+ :follow #'org-link--open-shortdoc
+ :store #'org-link--store-shortdoc)
+
  "http", "https", "mailto", "ftp", and "news" link types
 (dolist (scheme '("ftp" "http" "https" "mailto" "news"))
   (org-link-set-parameters scheme

RE: [External] : Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)

[Drew Adams]

> I've also fixed a bug in EWW and bug-reference-mode 
> where it would return nil for (thing-at-point 'url)
> if point was at the *end* of a URL.

By "at the end" I assume you really mean just
_after_ a URL, i.e., no longer on/at the URL.

FWIW, that's actually _superior_ behavior.

Unfortunately however, Emacs has chosen the
behavior you describe here:

> It's now consistent with how 'thing-at-point'
> works by default.

> (If you have two consecutive URLs and point
> is between them...it'll prefer the second one.)

Which is better!  It's what "at point" means.

(Yes, technically point is between the chars.)

And with a block cursor the cursor is on the
second thing, not the first.

And `C-x =' describes the current "cursor
position" (aka point), and it describes - wait
for it - not the char before point but the char
after point, IOW, colloquially the char at point.

And `forward-sexp', `forward-word', `forward-thing',
etc. advance just _past_ the thing.  The cursor
is then _not_ on the thing, and unless the thing
is immediately followed by another thing, there's
_no_ thing at point.

Unfortunately, Emacs maintainers decided that
thingatpt.el isn't useful for anything except
obtaining something to use as a default value for
user input.  The opinion was that no one ever
wants/needs to get nil, telling them that there's
no thing at point.  Better, they think, to always
try to get a thing at point OR at (1- point).

This awful Emacs behavior defeats the successive
use of functions that do something with the next
thing at point, in precisely the case you cited:
when the next thing butts up against the previous
thing.

In particular, these important use cases are
defeated by the behavior chosen for Emacs:

1. To find out _whether there is_, in fact,
   a THING at point.  AT POINT - not point OR
   (point - 1).

2. IF there really is a THING at point, to
   return it (or its bounds).

See bug #9300, " `bounds-of-thing-at-point'
does not return nil when just after THING".
___

Library thingatpt+.el fixes this, providing
more useful behavior for thing-at-point, and
making more use cases possible.

It also provides functions for picking up a
thing that's _near_ point (where "near" can
be specified).

That's what Emacs _should_ do for the only
use case it even cares about, which is trying
to get a thing for use as a default value for
input.  Getting a thing near point is quite
different from getting a thing _at point_.
___

https://www.emacswiki.org/emacs/download/thingatpt%2b.el

Re: [FR] Support headline as a function for file+headline target for org-capture-templates

[Nafiz Islam]

The problem with my implementation is that it modifies the org file before
prompting the user for item entry. As a result, if I cancel/abort my
org-capture, that modification will still be present. I've made another
attempt which is slightly more successful using advice.

(defun my/diary-capture-advice (oldfun r)
(let ((org-capture-templates `(("d"
   "Diary Template"
   item
   (file+headline (lambda () (expand-file-name
  (concat org-directory "Diary" "/" (format-time-string "%Y-%m-%d.org
"
  ,(format-time-string (org-time-stamp-format t t) (current-time)))
   "- %?"
   :empty-lines 0
  (call-interactively oldfun)))
(advice-add #'org-capture :around #'my/diary-capture-advice)

On Tue, Apr 30, 2024 at 8:31 AM Ihor Radchenko  wrote:

> Nafiz Islam  writes:
>
> >> Upon closer look at the `org-capture`, `org-capture-set-target-location`
> > and `org-capture-place-entry`, I'm starting to realize that
> "file+function"
> > can be used for what I'm looking for. I was just worried about the use of
> > `(org-capture-put :exact-position (point))`
> >
> > My disappointing attempt at using file+function target to replicate my
> idea
>
> What is the problem with it?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)

[Jim Porter]

On 4/30/2024 4:39 AM, Ihor Radchenko wrote:

What happens if you have multiple providers for an URL?
You add the provider to the end, so it will have the lower priority in
this scenario. I guess that you want the opposite - EWW provider to take
precedence. Same for other changes.


That's probably reasonable. I was just keeping things the way they were 
historically here, but we might as well fix this now.



It would make sense to add tests for "first wins" behaviour.


Done.

I've also fixed a bug in EWW and bug-reference-mode where it would 
return nil for (thing-at-point 'url) if point was at the *end* of a URL. 
It's now consistent with how 'thing-at-point' works by default. (If you 
have two consecutive URLs and point is between them - only possible with 
the custom provider function, I think - it'll prefer the second one.)
From da26f0160c955f15e123e5b28cf8a9f514395e21 Mon Sep 17 00:00:00 2001
From: Jim Porter 
Date: Sun, 28 Apr 2024 21:19:53 -0700
Subject: [PATCH] Allow defining custom providers for more "thingatpt"
 functions

This also fixes an issue in EWW and bug-reference-mode where
(thing-at-point 'url) at the end of a URL would return nil.

* lisp/thingatpt.el (forward-thing-provider-alist)
(bounds-of-thing-at-point-provider-alist): New variables...
(forward-thing, bounds-of-thing-at-point): ... use them.
(text-property-search-forward, text-property-search-backward)
(prop-match-beginning, prop-match-end): Declare.
(thing-at-point-for-text-property, forward-thing-for-text-property)
(bounds-of-thing-at-point-for-text-property): New functions.

* lisp/net/eww.el (eww--url-at-point): Use
'thing-at-point-for-text-property'.
(eww--bounds-of-url-at-point, eww--forward-url): New functions...
(eww-mode): ... use them.

* lisp/progmodes/bug-reference.el (bug-reference--url-at-point): Use
'thing-at-point-for-text-property'.
(bug-reference--bounds-of-url-at-point, bug-reference--forward-url): New
functions...
(bug-reference--init): ... use them.

* test/lisp/thingatpt-tests.el (thing-at-point-providers)
(forward-thing-providers, bounds-of-thing-at-point-providers): New
tests.

* etc/NEWS: Announce this change.
---
 etc/NEWS| 25 --
 lisp/net/eww.el | 21 +++--
 lisp/progmodes/bug-reference.el | 26 +--
 lisp/thingatpt.el   | 83 +++--
 test/lisp/thingatpt-tests.el| 59 +++
 5 files changed, 198 insertions(+), 16 deletions(-)

diff --git a/etc/NEWS b/etc/NEWS
index 7efb4110bcd..061161bb2fd 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -1591,19 +1591,34 @@ of the currently existing keyboards macros using the 
new mode
 duplicating them, deleting them, and editing their counters, formats,
 and keys.
 
-** Miscellaneous
+** Thingatpt
 
 ---
-*** Webjump now assumes URIs are HTTPS instead of HTTP.
-For links in 'webjump-sites' without an explicit URI scheme, it was
-previously assumed that they should be prefixed with "http://;.  Such
-URIs are now prefixed with "https://; instead.
+*** New variables for providing custom thingatpt implementations.
+The new variables 'bounds-of-thing-at-point-provider-alist' and
+'forward-thing-provider-alist' now allow defining custom implementations
+of 'bounds-of-thing-at-point' and 'forward-thing', respectively.
+
+---
+*** New helper functions for text property-based thingatpt providers.
+The new helper functions 'thing-at-point-for-text-property',
+'bounds-of-thing-at-point-for-text-property', and
+'forward-thing-for-text-property' can help to help implement custom
+thingatpt providers for "things" that are defined by a text property.
 
 ---
 *** 'bug-reference-mode' now supports 'thing-at-point'.
 Now, calling '(thing-at-point 'url)' when point is on a bug reference
 will return the URL for that bug.
 
+** Miscellaneous
+
+---
+*** Webjump now assumes URIs are HTTPS instead of HTTP.
+For links in 'webjump-sites' without an explicit URI scheme, it was
+previously assumed that they should be prefixed with "http://;.  Such
+URIs are now prefixed with "https://; instead.
+
 +++
 *** New user option 'rcirc-log-time-format'
 This allows for rcirc logs to use a custom timestamp format, than the
diff --git a/lisp/net/eww.el b/lisp/net/eww.el
index 39ea964d47a..b3997786d9e 100644
--- a/lisp/net/eww.el
+++ b/lisp/net/eww.el
@@ -1318,9 +1318,16 @@ eww-mode
   ;; desktop support
   (setq-local desktop-save-buffer #'eww-desktop-misc-data)
   (setq truncate-lines t)
+  ;; thingatpt support
   (setq-local thing-at-point-provider-alist
-  (append thing-at-point-provider-alist
-  '((url . eww--url-at-point
+  (cons '(url . eww--url-at-point)
+thing-at-point-provider-alist))
+  (setq-local forward-thing-provider-alist
+  (cons '(url . eww--forward-url)
+forward-thing-provider-alist))
+  (setq-local bounds-of-thing-at-point-provider-alist
+  (cons '(url . 

Re: [PATCH] org-ctags.el: Do not activate on load

[Ihor Radchenko]

Max Nikulin  writes:

> diff --git a/testing/lisp/test-org-ctags.el b/testing/lisp/test-org-ctags.el
> index 7f5fca948..b8e3e4d22 100644
> --- a/testing/lisp/test-org-ctags.el
> +++ b/testing/lisp/test-org-ctags.el
> @@ -76,17 +76,17 @@ (defmacro test-org-ctags/with-fake-ctags
>   (,dir (concat ,base "/" ,subdir))
>   (,temp-file (concat ,dir "/ctags.txt"))
>   (org-ctags-path-to-ctags
> - (test-org-ctags/mock-command ,temp-file "ctags-mock"))
> + (test-org-ctags/mock-command ,temp-file "ctags_mock"))
> ...

Applied.
Let's see how it goes.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c6bbde4c7

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] org-ctags.el: Do not activate on load

[Max Nikulin]

On 30/04/2024 19:59, Ihor Radchenko wrote:

/bin/sh: 1: Syntax error: Bad function name
(ert-test-failed
  ((should
(test-org-ctags/list-elements-equal-p
(list ...)
(test-org-ctags/with-fake-ctags temp-dir "regexp" ...)
'(2)
"Regexp should be escaped."))
   :form
   (test-org-ctags/list-elements-equal-p
("--regex-orgmode=/<<([^<>]+)>>/\\1/d,definition/")
"Sould be overwritten by org-ctags mock script"
(2)
"Regexp should be escaped.")
   :value nil :explanation "Shell command failed"))
FAILED   630/1311  test-org-ctags/create-tags-escape (0.003107 sec) at 
../lisp/test-org-ctags.el:132


At least error message is not bad. Dash does not like
ctags-mock() { ... }

diff --git a/testing/lisp/test-org-ctags.el b/testing/lisp/test-org-ctags.el
index 7f5fca948..b8e3e4d22 100644
--- a/testing/lisp/test-org-ctags.el
+++ b/testing/lisp/test-org-ctags.el
@@ -76,17 +76,17 @@ (defmacro test-org-ctags/with-fake-ctags
 (,dir (concat ,base "/" ,subdir))
 (,temp-file (concat ,dir "/ctags.txt"))
 (org-ctags-path-to-ctags
- (test-org-ctags/mock-command ,temp-file "ctags-mock"))
+ (test-org-ctags/mock-command ,temp-file "ctags_mock"))
 ,buffer)
(make-directory ,dir)
(unwind-protect
;; `org-ctags' commands call `buffer-file-name'.
(with-current-buffer
(setq ,buffer (find-file-noselect ,temp-file))
- (insert "Sould be overwritten by org-ctags mock script")
+ (insert "Should be overwritten by org-ctags mock script")
  (save-buffer)
  ,@body
- (test-org-ctags/get-args ,temp-file ,base "ctags-mock\n"))
+ (test-org-ctags/get-args ,temp-file ,base "ctags_mock\n"))
  (kill-buffer ,buffer)
  (delete-file ,temp-file)
  (delete-directory ,dir)

Re: [PATCH] org-ctags.el: Do not activate on load

[Ihor Radchenko]

Ihor Radchenko  writes:

> Applied, onto main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=735334445
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=badb09d67
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0f0019e32
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3c01767f7

And we got test failures on CI:
https://builds.sr.ht/~bzg/job/1208474

/bin/sh: 1: Syntax error: Bad function name
(ert-test-failed
 ((should
   (test-org-ctags/list-elements-equal-p
(list ...)
(test-org-ctags/with-fake-ctags temp-dir "regexp" ...)
'(2)
"Regexp should be escaped."))
  :form
  (test-org-ctags/list-elements-equal-p
   ("--regex-orgmode=/<<([^<>]+)>>/\\1/d,definition/")
   "Sould be overwritten by org-ctags mock script"
   (2)
   "Regexp should be escaped.")
  :value nil :explanation "Shell command failed"))
FAILED   630/1311  test-org-ctags/create-tags-escape (0.003107 sec) at 
../lisp/test-org-ctags.el:132

Any ideas?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] With custom results keyword ([9.7-pre (release_9.6.24-1407-ga2514c)])

[Ihor Radchenko]

caro...@free.fr writes:

> With a custom results keyword the function
> org-babel-where-is-src-block-result doesn't find the results block
> when the src block is unnamed.
>
>
>
> #+name: config
> #+begin_src emacs-lisp
>   (setopt org-babel-results-keyword "RÉSULTATS")
> #+end_src

This is not allowed, as per docstring:

(defcustom org-babel-results-keyword "RESULTS"
  "Keyword used to name results generated by code blocks.
It should be \"RESULTS\".  However any capitalization may be
   ^
used."

Not a bug.
Canceled.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

[BUG] With custom results keyword ([9.7-pre (release_9.6.24-1407-ga2514c)])

[caroute]

Hi


With a custom results keyword the function
org-babel-where-is-src-block-result doesn't find the results block
when the src block is unnamed.



#+name: config
#+begin_src emacs-lisp
  (setopt org-babel-results-keyword "RÉSULTATS")
#+end_src

#+RÉSULTATS: config
: RÉSULTATS








#+begin_src emacs-lisp
  (+ 1 6)
#+end_src

#+RÉSULTATS:
: 7

#+RÉSULTATS:
: 7

#+RÉSULTATS:
: 7




A possible fix (in ob-core.el):

#+begin_src elisp

  (defconst org-babel-result-regexp
(rx (seq bol
 (zero-or-more (any "\t "))
 (literal (format "#+%s" org-babel-results-keyword))
 (opt "["
;; Time stamp part.
(opt "("
   (= 4 digit) (= 2 "-" (= 2 digit))
   " "
   (= 2 digit) (= 2 ":" (= 2 digit))
   ") ")
;; SHA1 hash.
(group (one-or-more hex-digit))
"]")
 ":"
 (zero-or-more (any "\t "
"Regular expression used to match result lines.
  If the results are associated with a hash key then the hash will
  be saved in match group 1.")
   org-babel-result-regexp
#+end_src

#+RÉSULTATS:
: ^[ ]*#\+RÉSULTATS\(?:\[\(?:([[:digit:]]\{4\}\(?:-[[:digit:]]\{2\}\)\{2\} 
[[:digit:]]\{2\}\(?::[[:digit:]]\{2\}\)\{2\}) \)?\([[:xdigit:]]+\)]\)?:[  ]*



but it doesn't work a run time.





Best regards 

Vincek



Emacs  : GNU Emacs 29.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, 
cairo version 1.16.0)
 of 2024-03-26
Package: Org mode version 9.7-pre (release_9.6.24-1407-ga2514c @ 
~/.emacs30.d/straight/build/org/)

current state:
==
(setq
 org-link-elisp-confirm-function 'yes-or-no-p
 org-roam-db-gc-threshold 80
 org-hide-emphasis-markers t
 org-bibtex-headline-format-function 'org-bibtex-headline-format-default
 org-babel-exp-inline-code-template "src_%lang[%switches%flags]{%body}"
 org-roam-mode-hook '(org-roam-bibtex-mode)
 org-pretty-table-mode-hook '(org-pretty-table-mode-set-explicitly)
  org-roam-node-display-template #("${title:*} ${tags:20}" 11 21 (face org-tag))
 org-persist-after-read-hook '(org-element--cache-persist-after-read)
 org-format-latex-options '(:foreground default :background default :scale 2.0 
:html-foreground
"Black" :html-background "Transparent" :html-scale 
1.0 :matchers
("begin" "$1" "$" "$$" "\\(" "\\["))
 org-export-before-parsing-hook '(org-attach-expand-links 
org-babel-jupyter-strip-ansi-escapes)
 org-cycle-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)
 org-roam-find-file-hook '(org-roam-buffer--setup-redisplay-h
   org-roam--register-completion-functions-h
   org-roam--replace-roam-links-on-save-h
   org-roam-db-autosync--setup-update-on-save-h)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-modern-list '((42 . "•") (43 . "‣"))
 org-odt-format-inlinetask-function 'org-odt-format-inlinetask-default-function
 org-ascii-format-drawer-function '(closure (t) (_name contents _width) 
contents)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
  org-cycle-optimize-window-after-visibility-change 
org-cycle-display-inline-images)
 org-persist-before-read-hook '(org-element--cache-persist-before-read)
 org-yank-image-file-name-function 'org-yank-image-autogen-filename
 org-mode-hook '((closure
  (org--rds visual-fill-column-width org-clock-history 
org-with-time org-defdecode
   org-def org-read-date-inactive org-ans2 org-ans1 
org-columns-current-fmt-compiled
   org-clock-current-task org-clock-effort 
org-end-time-was-given org-time-was-given
   org-state org-agenda-headline-snapshot-before-repeat 
org-struct-menu
   org-last-state org-clock-start-time remember-data-file 
align-mode-rules-list
   org-inlinetask-min-level t)
  nil (add-hook 'change-major-mode-hook 'org-fold-show-all 
'append 'local))
 #[0 "\301\211\207" [imenu-create-index-function 
org-imenu-get-tree] 2]
 flyspell-mode (lambda nil (flycheck-mode 1)) org-modern-mode
 (lambda nil (org-bullets-mode 1)) jupyter-org-interaction-mode
 (closure
  (org--rds org-attach-method 
org--single-lines-list-is-paragraph
   org-element-greater-elements org-agenda-restrict-end 
org-agenda-restrict-begin
   org-agenda-restrict visual-fill-column-width 
org-clock-history
   org-agenda-current-date org-with-time org-defdecode org-def
   org-read-date-inactive org-ans2 org-ans1 
org-columns-current-fmt-compiled
   org-clock-current-task org-clock-effort 
org-agenda-skip-function
   

Re: [FR] Support headline as a function for file+headline target for org-capture-templates

[Ihor Radchenko]

Nafiz Islam  writes:

> Upon closer look at the `org-capture`, `org-capture-set-target-location`
> and `org-capture-place-entry`, I'm starting to realize that "file+function"
> can be used for what I'm looking for.

So, there is no feature to request.
Canceled.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [FR] Support headline as a function for file+headline target for org-capture-templates

[Ihor Radchenko]

Nafiz Islam  writes:

>> Upon closer look at the `org-capture`, `org-capture-set-target-location`
> and `org-capture-place-entry`, I'm starting to realize that "file+function"
> can be used for what I'm looking for. I was just worried about the use of
> `(org-capture-put :exact-position (point))`
>
> My disappointing attempt at using file+function target to replicate my idea

What is the problem with it?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: keeping subtree heading on export

[Ihor Radchenko]

Matt Price  writes:

> The real problem I have is that, when exporting a subtree, I want to set
> org-md-toplevel-hlevel to "2" and add the title; when exporting a whole
> file, I want to set org-md-toplevel-hlevel to "1" and ignore the title.

You can examine :export-options value in the INFO plist.
The value is a list with up to 3 elements: 'subtree, 'visible-only, and
'body-only.

In your backend :filters-alist, you can define a :filter-options filter
that will set :md-toplevel-hlevel option as needed, before the export
starts.

The :filter-options filter is there to pre-process export options
programatically, just as you describe.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)

[Ihor Radchenko]

Jim Porter  writes:

> +  (setq-local bounds-of-thing-at-point-provider-alist
> +  (append bounds-of-thing-at-point-provider-alist
> +  '((url . eww--bounds-of-url-at-point
> +  (setq-local forward-thing-provider-alist
> +  (append forward-thing-provider-alist
> +  '((url . eww--forward-url
> ...

What happens if you have multiple providers for an URL?
You add the provider to the end, so it will have the lower priority in
this scenario. I guess that you want the opposite - EWW provider to take
precedence. Same for other changes.

> +(ert-deftest thing-at-point-providers ()
> ...
> +(ert-deftest forward-thing-providers ()
> ...
> +(ert-deftest bounds-of-thing-at-point-providers ()
> +  (with-temp-buffer
> +(setq-local bounds-of-thing-at-point-provider-alist
> +`((url . ,(lambda ()
> +(bounds-of-thing-at-point-for-text-property
> + 'my-url)

It would make sense to add tests for "first wins" behaviour.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

[PATCH] org.el: Call EXT-enable for `org-modules' (was Re: [PATCH] org-ctags.el: Do not activate on load)

[Max Nikulin]

On 30/04/2024 17:02, Ihor Radchenko wrote:

Max Nikulin writes:


Isn't it better to modify buggy org-ctags than to add various kludges to
tests?


Applied, onto main.


I was expecting that you would be against it since it is a breaking change.

See a follow-up to
Ihor Radchenko. Re: Autoloading side effects
(was: Re: [BUG] org-mouse is activated without explicit require)
Mon, 12 Dec 2022 10:25:16 +


However now I am in doubts why org-ctags is not a minor mode.From 9cf1ebd0d8a0b1aa059f049aeb0c297b114aa4e2 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Tue, 30 Apr 2024 18:05:11 +0700
Subject: [PATCH] org.el: Call EXT-enable for `org-modules'

* lisp/org.el (org-load-modules-maybe): Activate extensions that
implement EXT-enable functions.
* etc/ORG-NEWS:
* lisp/org-ctags.el: Update docs.

It should simplify configuration for `org-ctags' users after badb09d67.
The idea was discussed in

Ihor Radchenko. Re: Autoloading side effects
(was: Re: [BUG] org-mouse is activated without explicit require)
Mon, 12 Dec 2022 10:25:16 +


An alternative from the same thread is converting org modules
to minor modes.
---
 etc/ORG-NEWS  | 23 +++
 lisp/org-ctags.el |  5 -
 lisp/org.el   | 11 +--
 3 files changed, 32 insertions(+), 7 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 8dbc3292d..708d11f4f 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -651,10 +651,14 @@ just =id:= links.
 
 *** ~org-ctags~ is not activated by default any more
 
-To follow Emacs [[info:elisp#Coding Conventions][coding conventions]] and to avoid confusion of users
+To follow Emacs [[info:elisp#Coding Conventions][coding conventions]]
+and to avoid confusion of users
 who accidentally get ~org-ctags~ autoloaded due to help completion,
-the library does not modify ~org-open-link-functions~ during loading
-any more.  Run ~org-ctags-enable~ to setup hooks and advices:
+the library does not modify ~org-open-link-functions~ any more
+when it is loaded using ~(require 'org-ctags)~ or a similar construct.
+To setup hooks and advices either
+[[*~feature-enable~ functions are called for extensions from ~org-modules~][customize ~org-modules~]]
+and add ~org-ctags~ or run ~org-ctags-enable~ explicitly:
 
 #+begin_src emacs-lisp
 (with-eval-after-load "org-ctags"
@@ -1473,10 +1477,21 @@ buffer it will be added.  If not specified, new headings are created
 at level 1 at the end of the accessible part of the buffer, as before.
 
 ** Miscellaneous
+*** ~feature-enable~ functions are called for extensions from ~org-modules~
+
+Accordingly to Emacs [[info:elisp#Coding Conventions][coding conventions]]
+loading a library must not modify behavior
+since it may be done for the sake of help or command completion.
+To make user configuration more convenient, when an extension ~EXT~ listed
+in ~org-modules~ implements ~EXT-enable~ function, it is executed
+during loading of Org mode or in response to customization of ~org-modules~.
+So instead of ~(require 'EXT)~ in your init file add ~EXT~ to ~org-modules~.
+See also
+[[*~org-ctags~ is not activated by default any more][~org-ctags~ is not activated by default any more]].
+
 *** =org-crypt.el= now applies initial visibility settings to decrypted entries
 
 Previously, all the text was unfolded unconditionally, including property drawers.
-
 *** Blank lines after removed objects are now retained during export
 
 When certain objects in Org document are to be excluded from export,
diff --git a/lisp/org-ctags.el b/lisp/org-ctags.el
index d3af103dd..9313c43cd 100644
--- a/lisp/org-ctags.el
+++ b/lisp/org-ctags.el
@@ -57,10 +57,13 @@ ;;; Commentary:
 ;;(add-hook 'org-mode-hook
 ;;  (lambda ()
 ;;(define-key org-mode-map "\C-co" 'org-ctags-find-tag-interactive)))
+;;
+;; To activate the library, you either need to add it to `org-modules'
+;; or to call `org-ctags-enable' explicitly:
+;;
 ;;(with-eval-after-load "org-ctags"
 ;;  (org-ctags-enable))
 ;;
-;; To activate the library, you need to call `org-ctags-enable' explicitly.
 ;; It used to be invoked during library loading, but it was against Emacs
 ;; policy and caused inconvenience of Org users who do not use `org-ctags'.
 ;;
diff --git a/lisp/org.el b/lisp/org.el
index 2d1a2055f..703ef 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -724,10 +724,17 @@ (defvar org-modules-loaded nil
 
 ;;;###autoload
 (defun org-load-modules-maybe ( force)
-  "Load all extensions listed in `org-modules'."
+  "Load all extensions listed in `org-modules'.
+If an extension defines EXT-enable function then invoke it
+to activate the module."
   (when (or force (not org-modules-loaded))
 (dolist (ext org-modules)
-  (condition-case-unless-debug nil (require ext)
+  (condition-case-unless-debug nil
+  (let* ((feature (require ext))
+ (enable-function (intern (concat 

Re: [PATCH] Rewrite `org-clock-sum'

[Ihor Radchenko]

Morgan Smith  writes:

> I may have rewritten org-clock-sum yet again.  See attached patch.
>
> * things I want you to tell me
> 1. Does this look like something that could be eventually merged upstream or 
> am
>I wasting my time?

Yes, it could be merged upstream. I do not see why not.

> 2. Would you like me to do more performance testing?  I basically only tested
>my use case.  If yes, should I create some test files for benchmarking that
>can be shared?

Your patch clearly provides more caching ability, so I anticipate an
improvement. I will still need to test is on my side though to be sure.

Having benchmarks would be nice, but optional.

> 3. Do you want `org-element-cache-map' fixed before we merge this patch?  If
>yes, please be willing to wait.  I have already spent probably about 8 
> hours
>looking into it and it still makes my head hurt.

A fix would be nice, but it should not be a blocker for your patch.

If necessary, we can discuss that function by screen sharing.

> * todo
> The patch is like 95% done.  I still gotta
>
> 1. Write a decent docstring for `org-clock-ranges'.  Maybe add a news entry 
> for
>it too.

Or make it internal. Then, no news entry will be required.
I am not 100% sure if the return value is useful for generic use outside
org-clock-sum.

> 2. Check `org-clock-hd-marker' for open clock.

You can simply compare it with org-element-begin for current headline.

> 3. Figure out what to do about open clocks that aren't the current
>one. Historically we ignored them so I guess I should just do that.

Yes. Ideally, also document this in the docstring.

> 4. Maybe test clocking in inlinetasks.  I honestly don't even know what these
>are.

** TODO inline
** END

They can appear in parallel with paragraphs.

Inlinetasks are an optional markup feature that is enabled by (require 
'org-inlinetask)

> * Downsides of my rewrite
>
> 1. Does it still perform better with the cache disabled?  idk.  Probably not.

That should not be a problem. We are slowly moving Org code to use cache
API everywhere.

> 2. Radical change.  Likely has bugs

Then, it would be nice to add some test coverage.

> 3. Dances around bugs in `org-element-cache-map' but does it actually dance
>around all of them?

It would be nice if you help with this by fixing known bugs and writing
more tests, but it is generally not a concern _you_ need to worry about
- I will (sooner or later) fix bugs in `org-element-cache-map' if they arise.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] oddity tangling src_blk with :var [9.7-pre (release_9.6.26-1368-g1ae978 @ /home/minshall/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Greg Minshall  writes:

> a dream might be something like ":var none" to allow the dot source code
> block to indicate it wasn't expecting any ":var" anyway.  but, i guess
> then one would want to allow picking and choosing:
> 
> : #+header: :var =common_variable
> 
> or some such to disable *that*?

This can be implemented, but not if the purpose is working around the
tangling issue you are experiencing.

I do not recall many people asking for such a feature.

> maybe, anyway, a warning message *might* be nice -- "failing" (as the
> user may see it) silently can be hard to debug.

It might be. But the real fix should be adding babel API to allow
backends declaring the list of supported features.
Such API is relatively easy to implement.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] ob-lua: Support all types and multiple values in results

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> Rudolf Adamkovič  writes:
>
>> Definitely!  I am on it.

Thanks!

> All right, how about the attached patch?
> ...
> * lisp/ob-lua.el (org-babel-lua-multiple-values-separator): Change the
> default value from ", " to "|" to avoid '\\,' appearing in strings.

May you please elaborate why this breaking change is going to lead to
significant improvement? How is using "," worse than using "|"? Either
way, strings containing the separator will become problematic and need
to be escaped. Moreover, using "|" may lead to interpreting the output
as Org tables, which may be surprising to users.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] lisp/org.el: Obsolete `org-cached-entry-get' in favor of `org-entry-get'

[Ihor Radchenko]

Morgan Smith  writes:

>> We need a real-life justification, not a theoretical one.
> ...
> I agree with all your points and I'm sorry for sending noise.  However, I 
> think
> I actually found a real-life justification.
>
> It turns out that by replacing `org-cached-entry-get' with
> `org-entry-get' the performance of my `org-clock-sum' calls got much
> better for my specific use case.  Due to benchmarking with my local
> changes in place (sorry), I accidentally attributed this performance
> increase to byte-compiling the return of `org-make-tags-matcher'.
>
> These numbers are also with my `org-clock-sum' rewrite patch applied.
> They are in a 3M file of almost exclusivly clocking data.  The filters I
> use are "CATEGORY={blah}" for one clock table and "-ignore-ITEM={foo}"
> for 9 others.  

I got similar results using "-ignore-ITEM={foo}" :match.
The reason behind the slowdown is the fact that `org-cached-entry-get'
forces calculating _all_ the possible properties. In my case, this leads
to 10x slowdowns due to custom blocker function when calculating BLOCKED
property.

I thus conclude that your patch makes sense, and we can obsolete
`org-cached-entry-get', especially since atomic property lookups are
partially cached on the latest Org mode via org-element-cache
mechanisms.

However, please move the obsolete function definition to org-compat
instead of removing it completely. We do it to avoid unexpected breakage
for people and libraries who happen to use this public function.

Also, with the old approach, if you observe slowdowns, you likely have
some property being calculated slowly (like BLOCKED in my case). Do you
happen to know which property is it for your setup?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] org-ctags.el: Do not activate on load

[Ihor Radchenko]

Max Nikulin  writes:

> Isn't it better to modify buggy org-ctags than to add various kludges to 
> tests?

Yes, of course.
Thanks for doing this!

Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=735334445
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=badb09d67
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0f0019e32
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3c01767f7

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

[SUMMARY] #7 [[bbb:OrgMeetup]] on Wed, Apr 24, 19:00 UTC+3

[Ihor Radchenko]

Here is a summary of the discussed topics + comment log:

- Tim reported Org mode hanging (potential infinite loop) when setting
  tags in a new capture near the end of a big Org mode buffer.

  After ~M-x toggle-debug-on-quit~, the potential offender is
  ~org-element-cache-map~:

  : Debugger entered--Lisp error: (quit)
  : org-element-at-point(1935572)
  : org-element-cache-map(#f(compiled-function (el) #))
  : org-get-buffer-tags()
  : org-set-tags-command(nil)
  : funcall-interactively(org-set-tags-command nil)
  : command-execute(org-set-tags-command)

  The bug is intermittent - hard to reproduce on demand (so, not possible
  to debug during the meetup via screen share).

  - This kind of bugs is not easy to debug without a reproducer
  - Since the bug was reported on stable version of Org mode, the
potential things to try (and hope for the best):
1. Try the latest dev version of Org mode
2. Try ~(setq org-element-use-cache nil)~
3. If nothing helps, report to the mailing list where we can try
   harder to fix the problem

- Kathink reported a cache error when expanding =yasnippet= snippets for
  LaTeX fragments.

  - At this point, the cache does not have /obvious/ bugs. The remaining
are pretty peculiar and are often caused by some specific changes
in the cache state.
  - Org mode provides a way to record cache state log, so that we can
diagnose these difficult bugs. One can enable it by adding the
following to Emacs config

: (setq org-element--cache-self-verify 'backtrace)

Then, the cache warning message will be supplied by very, /very/
long cache log. This log is to be submitted to Org developers.

Preferably, if it is possible to trigger the bug simply by
tinkering around the problematic Org file, also do ~M-x
org-element-cache-reset~ before triggering the bug, so that the log
size (which can be a few Mbs easily) is not as overwhelming.

- Karthink also reported lags when he edits an Org mode buffer with
  LaTeX equations.

  ~M-x profiler-start~ / ... / ~M-x profiler-report~ revealed that the cause
  is Org mode's LaTeX fontification.

  This is a known problem happening in /some/ Org files where Emacs
  regexp engine has a particularly bad time matching
  ~org-latex-and-related-regexp~ against the buffer text.

  The fix would be either (1) simplifying
  ~org-latex-and-related-regexp~, although not clear how - someone
  experiencing this particular problem would need to play around with
  it; (2) waiting until we rewrite Org mode fontification to use
  parser: https://orgmode.org/list/87ee7c9quk.fsf@localhost.

- Karthink further asked about his bug report about slowdown when
  killing Org buffers: 
https://list.orgmode.org/orgmode/874jbz9xvl@gmail.com/
  - I already replied on the list
  - I suspect that there is some O((N^2) complexity manifesting itself
when using the new LaTeX preview system (Kathink is the developer
of the new preview)
- The new LaTeX preview generates a large number of cache entries,
  while org-persist library looks up for cache duplicates using a
  simple ~memq~ leading to O(N^2)
- See ~cl-pushnew~ call in ~org-persist-write-all~
- But first need to know the actual number of cache entries to be
  sure that my suspicion is right

- I briefly mentioned the latest status of upstreaming the new LaTeX
  preview system.  Karthink is the co-author of it.

  I am starting a formal review of the preview code, piece by piece
  (the LaTeX preview branch introduces a number of completely new
  sub-features): https://list.orgmode.org/87a5llzmco.fsf@localhost/T/#u
  The first set of comments was regarding changes in the core Org
  export API.
  
  Karthink is not the author of this particular change though. So, we
  are still waiting for Timothy to reply.

- Tim (I think it was Tim) asked if it is possible to execute, say,
  all *bash* src blocks in Org buffer. Or, more generally, all the src
  blocks with a particular language.

  I quickly wrote a modification to the existing
  ~org-babel-execute-buffer~, adding a "DWIM" behavior
  "When point is at src block, only execute src block with the same
  language."

  If such addition is of interest to other Org users, we might
  consider something similar to be upstreamed.

  #+begin_src emacs-lisp
  (defun org-babel-execute-buffer-dwim ( arg)
"Execute source code blocks in a buffer.
  Prefix argument ARG is passed to `org-babel-execute-src-block'.
  Call `org-babel-execute-src-block' on every source block in
  the current buffer.
  When point is at src block, only execute src block with the same language."
(interactive "P")
(org-babel-eval-wipe-error-buffer)
(let* ((current-element (org-element-context))
 (current-src-block-language
(and (memq (org-element-type current-element) '(src-block 
inline-src-block))
   (org-element-property :language current-element
  

Re: [BUG] Attachments not resolved correctly from symlinked Org files

[Ihor Radchenko]

Karthik Chikmagalur  writes:

> Attachment paths are not resolved correctly when the Org file is
> symlinked elsewhere. This may or may not be a bug, but I think it's
> undesired behavior:
> ...
> 3. Symlink test.org from elsewhere, say
>
> /tmp/test.org -> ~/Desktop/test.org
> ...
> - An empty directory is created, like
>   /tmp/data/48/2697ee-913c-4eee-b1fb-636416d3fb6b
>
> - The original attachment can't be found, since it's actually in
>   ~/Desktop/data/48/2697ee-913c-4eee-b1fb-636416d3fb6b

I can see the problem.
But what would you expect to happen if there was no attachment in the
original directory? Should the attachment be created relative to the
original file? To the symlink?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] oddity tangling src_blk with :var [9.7-pre (release_9.6.26-1368-g1ae978 @ /home/minshall/.emacs.d/straight/build/org/)]

[Greg Minshall]

Ihor,

thanks again.

> #+property: header-args :var common_variable = "foo"

ah, hierarchical :var's.  i didn't realize such existed.  of course,
then, you're right.

a dream might be something like ":var none" to allow the dot source code
block to indicate it wasn't expecting any ":var" anyway.  but, i guess
then one would want to allow picking and choosing:

: #+header: :var =common_variable

or some such to disable *that*?

maybe, anyway, a warning message *might* be nice -- "failing" (as the
user may see it) silently can be hard to debug.

cheers, Greg