[BUG] clocktable match doesn't seem to support matching items based on parent property [9.6.15 (release_9.6.15 @ /snap/emacs/current/usr/share/emacs/29.3/lisp/org/)]

[Felix H. Dahlke]

I want to create a clocktable report for all items under a specific
heading, using the match keyword and the ITEM property. It appears
that matching items this way won't include any subheadings, therefore
not showing their times in the clocktable.

My guess would be that agenda and clocktable share the same matching
logic, and matching subheadings by the property of their parent does
probably not make sense for the agenda. I'd argue that for
clocktables, it would.

Example:

* Level 1   :level_1:
** Level 2
:PROPERTIES:
:LEVEL:  1
:END:

*** Level 3
:LOGBOOK:
CLOCK: [2024-05-07 Tue 11:00]--[2024-05-07 Tue 12:00] =>  1:00
:END:

* Report matching the ITEM property doesn't work
#+BEGIN: clocktable :scope file :match "ITEM=\"Level 1\""
#+CAPTION: Clock summary at [2024-05-07 Tue 13:00]
| Headline | Time   |
|--+|
| *Total time* | *0:00* |
#+END:

* Report matching an arbitrary property doesn't work
#+BEGIN: clocktable :scope file :match "LEVEL=\"1\""
#+CAPTION: Clock summary at [2024-05-07 Tue 13:00]
| Headline | Time   |
|--+|
| *Total time* | *0:00* |
#+END:

Note that this _does_ work if ~org-use-property-inheritance~ is not
~nil~.

* Report matching a tag works
#+BEGIN: clocktable :scope file :maxlevel 2 :match "level_1"
#+CAPTION: Clock summary at [2024-05-07 Tue 13:00]
| Headline | Time   |  |
|--++--|
| *Total time* | *1:00* |  |
|--++--|
| Level 1  | 1:00   |  |
| \_  Level 2  || 1:00 |
#+END:

Workaround:

As shown above, using either a tag or a custom property on the
top-level heading I want to generate the clocktable for works. For the
custom property to work, org-use-property-inheritance needs to be
non-nil.

Emacs  : GNU Emacs 29.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 
3.24.20, cairo version 1.16.0)

 of 2024-03-25
Package: Org mode version 9.6.15 (release_9.6.15 @ 
/snap/emacs/current/usr/share/emacs/29.3/lisp/org/)

Re: [PATCH] Add support for shortdoc link type

[Bruno Cardoso]

On 2024-05-06, 17:55 +0700, Max Nikulin  wrote:

> It seems my comments have led mostly to confusion rather than 
> improvements. I am sorry for that. I have in mind 2 kind of links:
> -  that may be handled solely by 
> `shortdoc-display-group' with second argument.
> -  that should cause
>(shortdoc-display-group group)
>(search-forward fn nil t) ; or (word-search-forward fn nil t)

I'm sure the confusion is mostly my fault :)

The following now work as expected:

- [[shortdoc:string]]
- [[shortdoc:string::#try-completion]]
- [[shortdoc:string::identical contents]]

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 1feb5ed60..8894f4231 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -3382,6 +3382,15 @@ Here is the full set of built-in link types:
 
   Execute a shell command upon activation.
 
+- =shortdoc= ::
+
+  Link to short documentation summary for an Emacs Lisp function group.
+  Since Emacs 28, user command ~shortdoc-display-group~ lists all known
+  documentation groups.
+
+  For more information, see [[info:emacs#Name Help][Name Help]]
+  and [[info:elisp#Documentation Groups][Documentation Groups]].
+
 
 For =file:= and =id:= links, you can additionally specify a line
 number, or a text search string, separated by =::=.  In Org files, you
@@ -3423,6 +3432,8 @@ options:
 | irc| =irc:/irc.com/#emacs/bob=  |
 | help   | =help:org-store-link=  |
 | info   | =info:org#External links=  |
+| shortdoc   | =shortdoc:text-properties= |
+|| =shortdoc:text-properties::#get-pos-property=  |
 | shell  | =shell:ls *.org=   |
 | elisp  | =elisp:(find-file "Elisp.org")= (Elisp form to evaluate)   |
 || =elisp:org-agenda= (interactive Elisp command) |
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 99dd8839c..1623873c0 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -1405,6 +1405,11 @@ 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= documentation
+groups for Emacs Lisp functions.
+
 ** 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 bc9682e4a..ab6cb497a 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -1582,6 +1582,46 @@ PATH is a symbol name, as a string."
  :follow #'org-link--open-help
  :store #'org-link--store-help)
 
+ "shortdoc" link type
+(when (version<= "28.0.90" emacs-version)
+  (defun org-link--open-shortdoc (path _)
+"Open a \"shortdoc\" type link.
+PATH is a group name, \"group::#function\" or \"group::search string\"."
+(string-match "\\`\\([^:]*\\)\\(?:::\\(.*\\).*\\'\\)?" path)
+(let* ((group (match-string 1 path))
+   (str (match-string 2 path))
+   (fn (when (and str (string-match "^#" str))
+ (intern-soft (string-remove-prefix "#" str)
+  (condition-case nil
+  (progn
+(shortdoc-display-group group fn)
+(when (and str (not fn))
+  (search-forward str nil t)))
+(user-error "Unknown shortdoc group: %s" group
+
+  (defun org-link--store-shortdoc ( _interactive?)
+"Store \"shortdoc\" type link."
+(when (eq major-mode 'shortdoc-mode)
+  (let* ((buffer (buffer-name))
+ (group (when (string-match "*Shortdoc \\(.*\\)\\*" buffer)
+  (match-string 1 buffer
+(if (and group (assoc (intern-soft group) shortdoc--groups))
+(org-link-store-props :type "shortdoc"
+  :link (format "shortdoc:%s" group)
+  :description nil)
+  (user-error "Unknown shortdoc group: %s" group)
+
+  (defun org-link--complete-shortdoc ()
+"Create a \"shortdoc\" link using completion."
+(concat "shortdoc:"
+(completing-read "Shortdoc summary for functions in: "
+ (mapcar #'car shortdoc--groups
+
+  (org-link-set-parameters "shortdoc"
+   :follow #'org-link--open-shortdoc
+   :store #'org-link--store-shortdoc
+   :complete #'org-link--complete-shortdoc))
+
  "http", "https", "mailto", "ftp", and "news" link types
 (dolist (scheme '("ftp" "http" "https" "mailto" "news"))
   (org-link-set-parameters scheme

Re: Q: org-publish-project-alist and :exclude

[David Masterson]

Ihor Radchenko  writes:

> David Masterson  writes:
>
>> Hmm.  Couldn't get rx (or rx-to-string) to work for me.  Kept getting an
>> error that a stringp was expected for the argument to :exclude. I tried
>> variations on:
>>
>>   :exclude (rx-to-string (seq (or "init" "calendar-beorg") ".org"))
>
> When you have '(:foo bar :baz eet), nothing inside is evaluated because
> of the quote. To evaluate expressions selectively, use backquote:
>
> `(:foo bar:baz ,(concat "foo" "bar"))

I always had trouble with '"` in hacking Elisp.  I should've studied the
language more 40 years ago... :(

>> Reverted to using a simple regex as above with proper escapes.  Can I
>> suggest making the complex example in 14.3.2 of the Org Manual use a
>> better example regex (in rx form?) as a hint to what :exclude can do?
>
> Sure.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=773bba92a

Perfect.
-- 
David Masterson

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

[Eli Zaretskii]

> Date: Tue, 7 May 2024 09:10:59 -0700
> Cc: yanta...@posteo.net, emacs-de...@gnu.org, emacs-orgmode@gnu.org
> From: Jim Porter 
> 
> On 5/7/2024 5:20 AM, Eli Zaretskii wrote:
> > I disagree.  These functions are nowadays the basis of many
> > interactive features, and users are usually mightily confused by the
> > fine print of what "at point" means technically in Emacs.  The current
> > operation is much easier for users to grasp mentally by observing the
> > position of the cursor, whether it's on or just after the "thing".
> 
> At the risk of veering off-topic (I mainly care about adding 
> 'bounds-of-thing-at-point-provider-alist' and 
> 'forward-thing-provider-alist'), would adding a new optional STRICT 
> argument to 'thing-at-point' and friends be an ok resolution for 
> everyone? This argument would enable Drew's proposed behavior. That way, 
> users get all the nice behavior by default just like today, and 
> programmers who require strict correctness in their code also have an 
> option.

If enough people want the other behavior, I won't object to supporting
that as well as an option.

Re: [DISCUSSION] Sorting strings in Org mode vs. system locale

[Max Nikulin]

On 07/05/2024 20:09, Ihor Radchenko wrote:

Max Nikulin writes:


I consider the following as a kind of graceful degradation

(defun org-sort-function-fallback-downcase
 (a b  LOCALE IGNORE-CASE)
   (if ignore-case
  (string-collate-lessp (downcase a) (downcase b) locale ignore-case)
(string-collate-lessp a b locale ignore-case)))


It is indeed better than `org-sort-function-downcase'.


`compare-strings' with upcase conversion under the hood may be an 
alternative.



I would consider a setter function for `org-sort-function' to avoid
branches based of `func-arity' in `org-string<'.


Setter is not reliable when setq is used, so I prefer arity check.


I bothers me as well. Another idea is to require 2 optional argument and 
thus wrappers for 2 argument functions. My expectation that extra 
function call still may be cheaper.

Re: Bug: Final zero after decimal point is stripped when inline code evaluated

[Max Nikulin]

On 07/05/2024 21:25, Charles Millar wrote:

On 5/7/24 7:49 AM, Max Nikulin wrote:

On 07/05/2024 03:05, Charles Millar wrote:


(setq toconvert 5.000)
(number-to-string toconvert)

evaluates to "5".


I get "5.0" (Linux), so I suspect some mistake.


I am using Debian Testing, full upgrade as of last Saturday.


Debian bookworm stable and Emacs-28.2.

LANG, LC_NUMERIC, LC_ALL environment variable should not affect 
formatting in numbers in Emacs since the "C" locale is forced for numbers.


The only guess I have is non-default value of `float-output-format'.

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

[Jim Porter]

On 5/7/2024 5:20 AM, Eli Zaretskii wrote:

I disagree.  These functions are nowadays the basis of many
interactive features, and users are usually mightily confused by the
fine print of what "at point" means technically in Emacs.  The current
operation is much easier for users to grasp mentally by observing the
position of the cursor, whether it's on or just after the "thing".


At the risk of veering off-topic (I mainly care about adding 
'bounds-of-thing-at-point-provider-alist' and 
'forward-thing-provider-alist'), would adding a new optional STRICT 
argument to 'thing-at-point' and friends be an ok resolution for 
everyone? This argument would enable Drew's proposed behavior. That way, 
users get all the nice behavior by default just like today, and 
programmers who require strict correctness in their code also have an 
option.

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 hear you.  The behavior should be changed so
> > that, in general, bounds-of-thing-at-point etc.
> > return nil when there is _no thing at point_,
> > including when point is after, including just
> > after, a thing but not on such a thing.
> >
> > There can be commands (and noncommand fns) that
> > return things _near_ point, not only at point.
> > And "near" can be configurable with an argument.
> >
> > In particular, they can do what the vanilla fns
> > currently do: return a thing at OR just before
> > point.  But the "-at-point" functions shouldn't
> > do that.  They should do what their names say.
> 
> I disagree.  These functions are nowadays the basis of many
> interactive features, and users are usually mightily confused by the
> fine print of what "at point" means technically in Emacs.  The current
> operation is much easier for users to grasp mentally by observing the
> position of the cursor, whether it's on or just after the "thing".

Of course.  IF the only use case is (as it's limited
to now) trying to get something near point, to use
as a _default value for interactive prompt and input_,
THEN there's no need for an actual at-point semantics.
No need and no advantage.

The point (sic) is that there are important, useful
_additional_ use cases, not supported by the current
ad-hoc semantics.  The idea behind Thing At Point is
much more general than the single use case that the
"many interactive features" you tout boil down to.

And no, legitimate at-point semantics doesn't require
any complex mental grasping.  It's in fact the current
behavior that leads to mental gyrations & puzzling,
because of the inconsistency that Jim pointed out.

The proper semantics is in fact far simpler to "grasp".  
You're just _used_ to grabbing things that aren't at
point, such as a list immediately before point.  Habit
can make you think things are straightforward & simple.
 
> > It's not hard for Emacs to still DTRT.  It just
> > takes a decision and admission that the behavior
> > was misguided and unnecessarily limiting (BIG
> > time).
> 
> We made the decision.

We know.  It's not too late to fix things, and it's
not hard to do.  What's lacking is the volition.

> It just is not what you think it should be, because
> our considerations are different from yours.

Exactly.  Your considerations are limited to maximizing
the possibility of returning a thing near point - more
precisely just before point OR AT point (aka just after
it).  (And as Jim pointed out, even that's not supported
consistently.)

With those blinders on, your decision makes some sense.
Take off the blinders and see there's a whole world
surrounding the narrow slice you saw looking only
straight ahead.

Fwd: Bug: Final zero after decimal point is stripped when inline code evaluated

[Charles Millar]

 Forwarded Message 
Subject: Re: Bug: Final zero after decimal point is stripped when inline 
code evaluated

Date: Tue, 7 May 2024 10:25:05 -0400
From: Charles Millar 
To: Max Nikulin 

On 5/7/24 7:49 AM, Max Nikulin wrote:

On 07/05/2024 03:05, Charles Millar wrote:
I appreciate that mathematically a trailing zero or zeros may be 
non-significant; however, in my use case, i.e. correct format in a 
text, they are necessary. Another example, in addition to my Dollars 
and cents scenario, may be a table that that has been created by using 
append, and the table appears as follows because trailing zeros were 
disregarded.


This 1.222
that 3.444
it   5.6
last 7.691

Question arises - is the correct number reported on line "it" 5.600 or 
has some editing omitted the last two decimal places?


I am unsure what do you mean by "using append".


Nor sure myself! What I meant was each number in the second column was a 
result of a :var evaluation that called a table and that there was a 
different table for each number.



 From my point of view there are 2 cases:
- When output format is fixed
   | 2 | 1.41 |
   | 3 | 1.73 |
   #+TBLFM: $2=(sqrt $1);%.2f
- When calculations should be performed with fixed point,
   usual floating point representation gives unexpected results
   src_elisp{(- 0.3 (+ 0.1 0.1 0.1))}
   {{{results(=-5.551115123125783e-17=)}}}

Some programming languages have decimal type for numbers:
https://docs.python.org/3/library/decimal.html

As to finances, I was surprised that ledger, hledger, and beancount have 
different internal representations for amounts and there are various 
issues with rounding.


Org just should avoid unnecessary conversions between strings an 
numbers, but Ihor is right and implementation would require enough efforts.



(setq toconvert 5.000)
(number-to-string toconvert)

evaluates to "5".


I get "5.0" (Linux), so I suspect some mistake.




I am using Debian Testing, full upgrade as of last Saturday.

Re: [DISCUSSION] Sorting strings in Org mode vs. system locale

[Ihor Radchenko]

Max Nikulin  writes:

> I consider the following as a kind of graceful degradation
>
> (defun org-sort-function-fallback-downcase
> (a b  LOCALE IGNORE-CASE)
>   (if ignore-case
>  (string-collate-lessp (downcase a) (downcase b) locale ignore-case)
>(string-collate-lessp a b locale ignore-case)))

It is indeed better than `org-sort-function-downcase'.

> (defcustom org-sort-function
>   (if (string-collate-lessp "a" "B" "C" t)
>  #'string-collate-lessp
>#'org-sort-function-fallback-downcase))

No. Let's be consistent with Emacs here.

> I would consider a setter function for `org-sort-function' to avoid 
> branches based of `func-arity' in `org-string<'.

Setter is not reliable when setq is used, so I prefer arity check.

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

[BUG] Test - please ignore

[Bastien Guerry]

Does Woof catch this?

-- 
 Bastien Guerry

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

[Eli Zaretskii]

> From: Drew Adams 
> CC: "e...@gnu.org" ,
> "emacs-de...@gnu.org"
>   ,
> "emacs-orgmode@gnu.org" 
> Date: Tue, 7 May 2024 01:52:13 +
> 
> I hear you.  The behavior should be changed so
> that, in general, bounds-of-thing-at-point etc.
> return nil when there is _no thing at point_,
> including when point is after, including just
> after, a thing but not on such a thing.
> 
> There can be commands (and noncommand fns) that
> return things _near_ point, not only at point.
> And "near" can be configurable with an argument.
> 
> In particular, they can do what the vanilla fns
> currently do: return a thing at OR just before
> point.  But the "-at-point" functions shouldn't
> do that.  They should do what their names say.

I disagree.  These functions are nowadays the basis of many
interactive features, and users are usually mightily confused by the
fine print of what "at point" means technically in Emacs.  The current
operation is much easier for users to grasp mentally by observing the
position of the cursor, whether it's on or just after the "thing".

> It's not hard for Emacs to still DTRT.  It just
> takes a decision and admission that the behavior
> was misguided and unnecessarily limiting (BIG
> time).

We made the decision.  It just is not what you think it should be,
because our considerations are different from yours.

Re: Bug: Final zero after decimal point is stripped when inline code evaluated

[Max Nikulin]

On 07/05/2024 03:05, Charles Millar wrote:
I appreciate that mathematically a trailing zero or zeros may be 
non-significant; however, in my use case, i.e. correct format in a text, 
they are necessary. Another example, in addition to my Dollars and cents 
scenario, may be a table that that has been created by using append, and 
the table appears as follows because trailing zeros were disregarded.


This 1.222
that 3.444
it   5.6
last 7.691

Question arises - is the correct number reported on line "it" 5.600 or 
has some editing omitted the last two decimal places?


I am unsure what do you mean by "using append".

From my point of view there are 2 cases:
- When output format is fixed
  | 2 | 1.41 |
  | 3 | 1.73 |
  #+TBLFM: $2=(sqrt $1);%.2f
- When calculations should be performed with fixed point,
  usual floating point representation gives unexpected results
  src_elisp{(- 0.3 (+ 0.1 0.1 0.1))}
  {{{results(=-5.551115123125783e-17=)}}}

Some programming languages have decimal type for numbers:
https://docs.python.org/3/library/decimal.html

As to finances, I was surprised that ledger, hledger, and beancount have 
different internal representations for amounts and there are various 
issues with rounding.


Org just should avoid unnecessary conversions between strings an 
numbers, but Ihor is right and implementation would require enough efforts.



(setq toconvert 5.000)
(number-to-string toconvert)

evaluates to "5".


I get "5.0" (Linux), so I suspect some mistake.

Re: [PATCH] Remove warning about org-clock-save.el lacking lexical-binding directive

[Bastien Guerry]

Ihor Radchenko  writes:

> And they reverted the warning at the end.
> https://git.savannah.gnu.org/cgit/emacs.git/commit?id=d51de0c5d90117bc1dc4bc5bc700253d71cd4579

Yes, it makes sense.

-- 
 Bastien Guerry

Re: [DISCUSSION] Sorting strings in Org mode vs. system locale

[Max Nikulin]

On 05/05/2024 18:59, Ihor Radchenko wrote:

Ihor Radchenko writes:


If a user access same files from Linux and macOS then it
may be really annoying to get different order of entries in agenda. For
most of Linux users it is better to use more smart
`string-collate-lessp'. Some care is required to sort entries obtained
from multiple buffers in predictable environment (locale, case
conversion table).


I agree. We can introduce a new customization -
`org-string-sort-function' that will be used across Org mode to sort
user text.


See the attached tentative patch.
I added a customization, made everything in Org obey it, and provided
some default options for MacOS users.


Contrary to Eli, I still think that there are enough locales where 
completely disregarding IGNORE-CASE is worse than fallback to `downcase' 
when IGNORE-CASE is t. Perhaps some kind of normalization (NFD?) may 
improve results further.


I consider the following as a kind of graceful degradation

(defun org-sort-function-fallback-downcase
   (a b  LOCALE IGNORE-CASE)
 (if ignore-case
(string-collate-lessp (downcase a) (downcase b) locale ignore-case)
  (string-collate-lessp a b locale ignore-case)))

(defcustom org-sort-function
 (if (string-collate-lessp "a" "B" "C" t)
#'string-collate-lessp
  #'org-sort-function-fallback-downcase))

I would consider a setter function for `org-sort-function' to avoid 
branches based of `func-arity' in `org-string<'.


I see a little point in purely downcase comparator 
`org-sort-function-downcase'.

Re: [PATCH] Remove warning about org-clock-save.el lacking lexical-binding directive

[Ihor Radchenko]

Ihor Radchenko  writes:

>>   ⛔ Warning (lexical-binding): File
>>   /home/bzg/.emacs.d/org-clock-save.el lacks `lexical-binding'
>>   directive on its first line
>>
>> The attached patch should fix this.  Is it okay to add it to bugfix?
>
> I think that it is premature.
> This is a warning recently introduced on Emacs master, and it is still
> being debated upon. See
> https://yhetil.org/emacs-devel/50e29988-d354-4d10-990f-31828dbe6...@gmail.com/t/#u

And they reverted the warning at the end.
https://git.savannah.gnu.org/cgit/emacs.git/commit?id=d51de0c5d90117bc1dc4bc5bc700253d71cd4579

Canceled.

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

Re: Q: org-publish-project-alist and :exclude

[Ihor Radchenko]

David Masterson  writes:

> Hmm.  Couldn't get rx (or rx-to-string) to work for me.  Kept getting an
> error that a stringp was expected for the argument to :exclude. I tried
> variations on:
>
>   :exclude (rx-to-string (seq (or "init" "calendar-beorg") ".org"))

When you have '(:foo bar :baz eet), nothing inside is evaluated because
of the quote. To evaluate expressions selectively, use backquote:

`(:foo bar:baz ,(concat "foo" "bar"))

> Reverted to using a simple regex as above with proper escapes.  Can I
> suggest making the complex example in 14.3.2 of the Org Manual use a
> better example regex (in rx form?) as a hint to what :exclude can do?

Sure.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=773bba92a

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