Re: org-ctags land grab

[Nick Dokos]

Ihor Radchenko  writes:

> Nick Dokos  writes:
>
>> `org-ctags' unilaterally sets the hook `org-open-link-functions' to a
>> bunch of org-ctags functions and enables itself by default. That has
>> the unfortunate consequence of invalidating the documentation for
>> internal CUSTOM_ID links - see
>>
>> https://emacs.stackexchange.com/questions/76351/how-to-follow-an-internal-link-in-recent-org-mode
>
> As documented in the top comment of org-ctags.el, the default behaviour
> of C-c C-o is modified as you observe:
>
> ;; By default, with org-ctags loaded, org will first try and visit the tag
> ;; with the same name as the link; then, if unsuccessful, ask the user if
> ;; he/she wants to rebuild the 'TAGS' database and try again; then ask if
> ;; the user wishes to append 'tag' as a new toplevel heading at the end of
> ;; the buffer; and finally, defer to org's default behavior which is to
> ;; search the entire text of the current buffer for 'tag'.
>
>> I proposed a work-around, but it seems to me that `org-ctags'
>> functionality should be opt-in and there should be a way to turn it
>> off.
>
> It is off by default.

It is off until org-ctags is loaded. *When* it is loaded, it runs
`(org-ctags-enable)' and the behavior changes.

Now I'm not loading it explicitly, but nevertheless, *somebody* does
because it goes ahead and mucks with my `org-open-link-functions'.
One clue was that it does not happen in 28.2 (which is the version
in Fedora 36 and 37) but it *does* happen in a 30.0.50 Emacs built
from upstream sources.

So I ran some tests, all with -Q so my init file is out of the
picture.

It turns out that it is enough to ask for help on an Org variable to
have `org-ctags' loaded!  I put a watch on `org-open-link-functions'
and did `C-h v org-latex-pdf-process': it stopped once on setting it to
nil and it stopped again with this backtrace (I elided long lines but I left
the relevant portion of the one that mentions `org-ctags'):



--8<---cut here---start->8---
Debugger entered--setting org-open-link-functions to (org-ctags-find-tag): 
  debug--implement-debug-watch(org-open-link-functions (org-ctags-find-tag) set 
nil)
  set-default(org-open-link-functions (org-ctags-find-tag))
  add-hook(org-open-link-functions org-ctags-find-tag t)
  org-ctags-enable()
  byte-code("\300 \210\301\302!\207" [org-ctags-enable provide org-ctags] 2)
  load("org-ctags" noerror nomessage)
  help--load-prefixes((("org-" "ox-latex" "ox" "org-src" "org-refile" 
"org-protocol" "org-plot" "org-pcomplete" "org-mouse" "org-macs" "org-list" 
"org-keys" "org-habit" "org-faces" "org-ctags" ...
  help--symbol-completion-table("org-latex-pdf-process" ...
  test-completion("org-latex-pdf-process" help--symbol-completion-table ...
  completion--complete-and-exit(20 41 exit-minibuffer ...
  completion-complete-and-exit(20 41 exit-minibuffer)
  minibuffer-complete-and-exit()
  funcall-interactively(minibuffer-complete-and-exit)
  call-interactively(minibuffer-complete-and-exit nil nil)
  command-execute(minibuffer-complete-and-exit)
  read-from-minibuffer("Describe variable: " nil ...
  completing-read-default("Describe variable: " help--symbol-completion-table 
...
  completing-read("Describe variable: " help--symbol-completion-table ...
  byte-code(...
  call-interactively(describe-variable nil nil)
  command-execute(describe-variable)
--8<---cut here---end--->8---

As you see, `help--load-prefixes' loads `org-ctags'. If you look at
the `help-definition-prefixes' radix tree, `org-ctags' is subsumed
under the `org-' prefix, so any lookup with that prefix will end up
loading it (and therefore enabling it). The reason it does not happen
in 28.2 is that it is only under the `org-ctags` prefix.

It seems to me that `org-ctags' should be registered under the
`org-ctags' prefix only, just like in 28.2 (the registration is in
`org-loaddefs.el' but I don't know how it ends up there. I guess
`org-fixup.el' is doing it, but I didn't chase it any further).

I also think that loading `org-ctags' should not automatically enable
it: it should require the user to explicitly run `org-ctags-enable' to
do that. That way, if there is a mechanism that loads it
surreptitiously, it wouldn't cause the confusion that it causes
now. That would require documentation changes, but it would avoid
unpleasant surprises, and preserve some toes even if users load it
accidentally. Eventually, it might be nice to provide a disabling
function as well, although the workaround in the SE post works well
enough for now. Maybe the thing to do is to turn it into a proper
minor mode.

Thoughts?

-- 
Nick

[PATCH] Make predicates non-interactive

[Aaron L. Zeng]

Predicates like `org-first-sibling-p' are no use when called
interactively, and should not appear in the M-x prompt.

TINYCHANGE
---
 lisp/org.el | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 23cb6012d..20e6ea6d9 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -9876,7 +9876,6 @@ inactive time ranges.
 When this function returns a non-nil value, match data is set
 according to `org-tr-regexp-both' or `org-tr-regexp', depending
 on INACTIVE-OK."
-  (interactive)
   (save-excursion
 (catch 'exit
   (let ((pos (point)))
@@ -15475,7 +15474,6 @@ If Org mode thinks that point is actually inside
 an embedded LaTeX environment, return t when the environment is math
 or let `texmathp' do its job otherwise.
 `\\[org-cdlatex-mode-map]'"
-  (interactive)
   (cond
((not (derived-mode-p 'org-mode)) (apply orig-fun args))
((eq this-command 'cdlatex-math-symbol)
@@ -20525,7 +20523,6 @@ point before the first headline or at point-min."
 
 (defun org-first-sibling-p ()
   "Is this heading the first child of its parents?"
-  (interactive)
   (let ((re org-outline-regexp-bol)
level l)
 (unless (org-at-heading-p t)
--
2.38.4

Re: [SUGGESTION] ob-shell async result output should not contains shell prompt

[Matt]

  On Wed, 22 Mar 2023 23:25:50 -0400  Christopher M. Miles  wrote --- 
 > 
 > The ob-shell async result output contains the shell prompt. I think it
 > should not be captured.
 > 
 > #+begin_src shell :session "test2" :async t
 > sleep 30
 > echo "hello, world"
 > #+end_src
 > 
 > #+RESULTS[(2023-03-23 11:19:22) 461ed5de684f6e619890709175ec73e80b67b2d6]:
 > : bash-5.2$ hello, world

Thanks for reporting this.

Try using for the babel language whatever shell the variable `shell-file-name' 
gives.  For example, if `shell-file-name' is /bin/bash, do this:

#+begin_src bash :session "test2" :async t
sleep 1
echo "hello, world"
#+end_src

Is there a reason you're using "shell" instead of one of the shells listed in 
`org-babel-shell-names'?

[CANCELED] Re: [BUG] org-capture got file userlock error when I capture on second time.

[Christopher M. Miles]

Ihor Radchenko  writes:

> stardiviner  writes:
>
>> When I org-capture from elfeed-entry buffer (I defined custom functions to
>> extract elfeed entry buffer content) in the second time and later, the
>> bellowing error raised up. The first-time capture is fine.
>>
>> Here is the error backtrace:
>> #+begin_example
>> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>>   expand-file-name(nil)
>>   userlock--check-content-unchanged("~/Org/Tasks/Tasks.org")
>
> This looks like some interaction between Org setting `buffer-file-name'
> to nil in *Capture* buffer and Emacs' file locking machinery. Maybe.
> Maybe Emacs bug. I have no better ideas.
>
> I also see nothing wrong we do on Org side.

First, Ihor, I need to thank you. With your hints. I try to figure out
what things might get involved between Org setting `buffer-file-name'
and *Capture* buffer.

1. I try to set `org-capture-mode-hook`, `org-mode-hook' etc to nil.

2. Use bug-hunter to bisect my emacs config, the first start, the
   problem does not occurred, this is weird, even I tried many times.

3. Then I use comment to bisect my init.el, try to figure out the
   reason. Still not found. And the problem not occurred.

4. I start Emacs again with original config. Now the problem gone. I
   restart Emacs many times, problem still not occurred. Weird.

-- 

[ stardiviner ]
I try to make every word tell the meaning that I want to express without 
misunderstanding.

Blog: https://stardiviner.github.io/
IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


signature.asc
Description: PGP signature

[SUGGESTION] ob-shell async result output should not contains shell prompt

[Christopher M. Miles]

The ob-shell async result output contains the shell prompt. I think it
should not be captured.

#+begin_src shell :session "test2" :async t
sleep 30
echo "hello, world"
#+end_src

#+RESULTS[(2023-03-23 11:19:22) 461ed5de684f6e619890709175ec73e80b67b2d6]:
: bash-5.2$ hello, world

-- 

[ stardiviner ]
I try to make every word tell the meaning that I want to express without 
misunderstanding.

Blog: https://stardiviner.github.io/
IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


signature.asc
Description: PGP signature

Re: [BUG] Agenda not sorting by priority THEN todo state (todo state ignored) [9.6.1 (9.6.1-??-fe92a3c @ /Users/polofsson/.emacs.d/.local/straight/build-28.2/org/)]

[Samuel Wales]

perhaps we could have 2 names: one for the priority cookie setting and
one for whatever the agenda does.


On 3/22/23, Ihor Radchenko  wrote:
> Jonas Olofsson  writes:
>
>> I am trying to sort my agenda by a number of variables, but it seems
>> that todo-state-down is not applied if added after priority-down.
>> Instead it seems as if Priority first is applied, then the date the
>> item is scheduled.
>>
>> Repro:
>> 1. Set
>>org-agenda-sorting-strategy
>>'((agenda priority-down todo-state-down)
>>  (todo priority-down todo-state-down effort-up category-keep
>> scheduled-up)
>>  (tags priority-down todo-state-down effort-up category-keep)
>>  (search category-keep))
>> 2. Set
>>org-todo-keywords '(
>>(sequence "TODO(t!)" "NEXT(n!)" "WAIT(w!)" "|"
>> "DONE(d!)" "CANC(c!)" "DUPE(D!)")
>>)
>> 3. Have three todos scheduled:
>>
>> * TODO [#C] Test
>> SCHEDULED: <2023-03-16 Thu>
>> * NEXT [#C] Test
>> SCHEDULED: <2023-03-15 Wed>
>> * WAIT [#C] Test
>> SCHEDULED: <2023-03-17 Fri>
>>
>> 4. Go to agenda.
>>
>> I expect to see items in the following order, since they are the same
>> priority.
>> WAIT C Test
>> NEXT C Test
>> TODO C Test
>>
>> But I see:
>> NEXT C Test
>> TODO C Test
>> WAIT C Test
>
> Confirmed.
>
> Yet another agenda madness I have no clue about.
>
> `org-agenda-get-scheduled' sets the priority as
>
> 'priority (if habitp (org-habit-get-priority habitp)
> (+ 99 diff (org-get-priority item)))
>
> where diff is the number of overdue days for a given entry.
>
> Further,
>
> `org-agenda-get-deadlines' has
>
> 'priority
> ;; Adjust priority to today reminders about deadlines.
> ;; Overdue deadlines get the highest priority
> ;; increase, then imminent deadlines and eventually
> ;; more distant deadlines.
> (let ((adjust (if today? (- diff) 0)))
>   (+ adjust (org-get-priority item)))
>
> `org-agenda-get-todos' has
>
> priority (1+ (org-get-priority txt)))
>
> All these dates back to the initial Org release.
>
> From what I am seeing, these awkward priority adjustments are hard-coded
> for fine-tune agenda sorting in some (unknown) scenarios.
>
> Changing them will likely break existing sorting.
>
> To fix this, we should carefully check what will happen if we set the
> agenda priority to be the actual user-defined priority. And then fix the
> sorting back somehow.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [PATCH] org-user-idle-seconds: Add support for logind

[Nathaniel Nicandro]

Ihor Radchenko  writes:

> Nathaniel Nicandro  writes:
>
>> I would like to submit a patch that adds support for logind to
>> `org-user-idle-seconds`.  This patch has been working for me for a long
>> while now and I thought it time for me to submit it.  I've contributed
>> to Emacs in the past so my paperwork should be on file.
>
> Thanks!
>
> Though I do not see any commits associated with Nathaniel Nicandro or
> your email in Emacs git repo.
> Bastien, may you check FSF records?
>
>> Let me know if any changes should be made.
>>
>> lisp/org-clock.el | 29 +
>>  1 file changed, 29 insertions(+)
>
> Please provide the commit message. See
> https://orgmode.org/worg/org-contribute.html#commit-messages

Done in the attached updated patch.

>
>> +(defvar org-logind-dbus-session-path
>> +  (when (and (boundp 'dbus-runtime-version)
>> + (require 'dbus nil t)
>> + (member "org.freedesktop.login1" 
>> (dbus-list-activatable-names)))
>> +(dbus-call-method
>> + :system "org.freedesktop.login1"
>> + "/org/freedesktop/login1"
>> + "org.freedesktop.login1.Manager"
>> + "GetSessionByPID" (emacs-pid
>
> Please provide a docstring for the new variable.
>
> Also, this new feature is worth documenting in ORG-NEWS.

Done.

>
> Otherwise, the patch looks good.

>From 1cc887d1378839c3322c93ebb5a524499b8d3073 Mon Sep 17 00:00:00 2001
From: Nathaniel Nicandro 
Date: Wed, 22 Mar 2023 14:54:57 -0500
Subject: [PATCH] lisp/org-clock.el: Add support for logind

* lisp/org-timer.el (org-logind-dbus-session-path): New variable.
(org-logind-user-idle-seconds): New function.
(org-user-idle-seconds): Use them.

---
 etc/ORG-NEWS  |  7 +++
 lisp/org-clock.el | 30 ++
 2 files changed, 37 insertions(+)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 87ecd77..ef3a2ab 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -87,6 +87,13 @@ a date range in the agenda.  It inherits from the default face in
 order to remain backward-compatible.
 
 ** New features
+*** Add support for ~logind~ idle time in ~org-user-idle-seconds~
+
+When Emacs is built with =dbus= support and
+the =org.freedesktop.login1= interface is available, fallback to
+checking the =IdleSinceHint= property when
+determining =org-user-idle-seconds= as the penultimate step.
+
 *** ~org-metaup~ and ~org-metadown~ now act on headings in region
 
 When region is active and starts at a heading, ~org-metaup~ and
diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index f869b0b..323efa4 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -51,6 +51,9 @@ (declare-function org-table-goto-line "org-table" (n))
 (declare-function org-dynamic-block-define "org" (type func))
 (declare-function w32-notification-notify "w32fns.c" ( params))
 (declare-function w32-notification-close "w32fns.c" ( params))
+(declare-function dbus-list-activatable-names "dbus" ( bus))
+(declare-function dbus-call-method "dbus" (bus service path interface method  args))
+(declare-function dbus-get-property "dbus" (bus service path interface property))
 
 (defvar org-frame-title-format-backup nil)
 (defvar org-state)
@@ -1214,6 +1217,26 @@ (defun org-x11-idle-seconds ()
   "Return the current X11 idle time in seconds."
   (/ (string-to-number (shell-command-to-string org-clock-x11idle-program-name)) 1000))
 
+(defvar org-logind-dbus-session-path
+  (when (and (boundp 'dbus-runtime-version)
+ (require 'dbus nil t)
+ (member "org.freedesktop.login1" (dbus-list-activatable-names)))
+(dbus-call-method
+ :system "org.freedesktop.login1"
+ "/org/freedesktop/login1"
+ "org.freedesktop.login1.Manager"
+ "GetSessionByPID" (emacs-pid)))
+  "D-Bus session path for the elogind interface.")
+
+(defun org-logind-user-idle-seconds ()
+  "Return the number of idle seconds for the user according to logind."
+  (- (float-time)
+ (/ (dbus-get-property
+ :system "org.freedesktop.login1"
+ org-logind-dbus-session-path
+ "org.freedesktop.login1.Session" "IdleSinceHint")
+1e6)))
+
 (defun org-user-idle-seconds ()
   "Return the number of seconds the user has been idle for.
 This routine returns a floating point number."
@@ -1222,6 +1245,13 @@ (defun org-user-idle-seconds ()
 (org-mac-idle-seconds))
((and (eq window-system 'x) org-x11idle-exists-p)
 (org-x11-idle-seconds))
+   ((and
+ org-logind-dbus-session-path
+ (dbus-get-property
+  :system "org.freedesktop.login1"
+  org-logind-dbus-session-path
+  "org.freedesktop.login1.Session" "IdleHint"))
+(org-logind-user-idle-seconds))
(t
 (org-emacs-idle-seconds
 
-- 
2.39.1


-- 
Nathaniel

Re: Two low-priority questions re: design of org-babel-do-load-languages

[Mandar Mitra]

Ihor Radchenko wrote (Wed, Mar 22, 2023 at 12:55:31PM +):
> The function `org-babel-do-load-languages' is originally not a generic
> function. It is specifically designed to be used as a :set function for
> `org-babel-load-languages' variable:
> 
> (defcustom org-babel-load-languages '((emacs-lisp . t))
> ...
>   :set 'org-babel-do-load-languages
> ...)
> 
> If you alter `org-babel-load-languages' via customize interface or via
> `setopt', the :set function is automatically called.
> 
> Later, AFAIK, it was also used in the manual as Elisp function.
> Against its original design.

Ok, I understand now. I had missed the 

:set 'org-babel-do-load-languages

That itself answered almost all my questions. Thank you very much for the 
detailed explanation! 

Warm regards,
Mandar.

Re: [PATCH] org-user-idle-seconds: Add support for logind

[Bastien Guerry]

Hi,

Ihor Radchenko  writes:

> Though I do not see any commits associated with Nathaniel Nicandro or
> your email in Emacs git repo.
> Bastien, may you check FSF records?

Nathaniel's records are okay.

-- 
 Bastien Guerry

Re: [PATCH v2] org-manual.org: $n$-th is not math

[Rudolf Adamkovič]

Timothy  writes:

> I feel the need to point out that this way lies madness.
>
> The behaviour [...] “weird things are happening”.

Thank you so much for taking the time to explain the problem to me; I
now understand it much better!  That said, if the heuristic is

   $  ...MATH...  $- 

then `$3 or =$5' to `$3-$5' would not cause any troubles, right?  What
common, real-world use-case would trigger problems with this simple
heuristic?

Rudy
-- 
"Thinking is a momentary dismissal of irrelevancies."
-- Richard Buckminster Fuller, 1969

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: [External] : Re: [BUG] updating existing org date with time always sets time to 0:00 [9.6.1 (release_9.6.1-262-gd94f40 @ /home/dortmann/src/git-org-mode/lisp/)]

[Ihor Radchenko]

Daniel Ortmann  writes:

> Ihor,
>
>   * In an org buffer, input: [1960-10-16]
>   * Set point between the brackets.
>   * Press C-c ! and enter.
>   * The result is [19_*7*_0-10-16 Fri]
>   * I expected [1060-10-16-Sun]
>
> Yes, C-c C-c works.
>
> But C-c ! enter is supposed to use [1960-10-16] as the default date and 
> not change that date to 1970.

See https://orgmode.org/list/87v8itnh20.fsf@localhost
You can just set `org-read-date-force-compatible-dates' to nil.

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

Re: [External] : Re: [BUG] updating existing org date with time always sets time to 0:00 [9.6.1 (release_9.6.1-262-gd94f40 @ /home/dortmann/src/git-org-mode/lisp/)]

[Daniel Ortmann]

Ihor,

 * In an org buffer, input: [1960-10-16]
 * Set point between the brackets.
 * Press C-c ! and enter.
 * The result is [19_*7*_0-10-16 Fri]
 * I expected [1060-10-16-Sun]

Yes, C-c C-c works.

But C-c ! enter is supposed to use [1960-10-16] as the default date and 
not change that date to 1970.



(Yes, I am replying to the correct thread which corresponds to the bug 
report submitted.)


On 3/22/23 10:10, Ihor Radchenko wrote:

Daniel Ortmann  writes:


Since that existing timestamp at point is supposed to be used as the
default, we definitely have a bug
==>> ... Since that 'default' time is bumped up to 1970.

Clearly, the expected default behavior is not working as expected.
(Times after 1970 are fine.)

May you elaborate? Are you sure that you are replying to the right thread?

Re: [External] : Re: [BUG] updating existing org date with time always sets time to 0:00 [9.6.1 (release_9.6.1-262-gd94f40 @ /home/dortmann/src/git-org-mode/lisp/)]

[Ihor Radchenko]

Daniel Ortmann  writes:

> Since that existing timestamp at point is supposed to be used as the 
> default, we definitely have a bug
> ==>> ... Since that 'default' time is bumped up to 1970.
>
> Clearly, the expected default behavior is not working as expected. 
> (Times after 1970 are fine.)

May you elaborate? Are you sure that you are replying to the right thread?

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

Re: ox-beamer/latex questions

[Ihor Radchenko]

Ihor Radchenko  writes:

> Leo Butler  writes:
>
>>> This is because
>>>  *** DONE :B_block:
>>> is actually parsed as a heading with DONE todo keyword and title
>>> ":B_block:". Tag is not recognized.
>>>
>>> We probably need to fix it, though I am not sure. It is one of the edge
>>> cases about Org parser.

Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=20b33106c

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

Re: [External] : Re: [BUG] updating existing org date with time always sets time to 0:00 [9.6.1 (release_9.6.1-262-gd94f40 @ /home/dortmann/src/git-org-mode/lisp/)]

[Daniel Ortmann]

Since that existing timestamp at point is supposed to be used as the 
default, we definitely have a bug

==>> ... Since that 'default' time is bumped up to 1970.

Clearly, the expected default behavior is not working as expected. 
(Times after 1970 are fine.)


On 2/22/23 04:57, Ihor Radchenko wrote:

Daniel Ortmann  writes:


file org-plain-date-to-date-time.org has:

* plain date
C-c ! gives:
[2023-02-21 Tue]
* updating plain date
C-c ! followed by C-u C-! gives:
[2023-02-21 Tue 00:00]
* date-time
C-u C-c ! gives:
[2023-02-21 Tue 14:13]

I expected that updating an existing date with C-u C-c ! would produce
the same result as creating a new date-time.

When point is at existing timestamp, C-c ! tries to take the time of
that timestamp as default. To force today's date and time, you can use
C-u C-u C-c !

Re: [PATCH] Fix one remaining emacs-30 byte-compile warning

[Ihor Radchenko]

Bastien Guerry  writes:

> Ihor Radchenko  writes:
>
>> Sure, but we need to confirm with FSF records first.
>> Bastien, may you take a look?
>
> Yes, I confirm Arash records are okay, sorry for the delay.

Updated WORG page.
https://git.sr.ht/~bzg/worg/commit/bf040f8a

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

Re: [PATCH] Fix one remaining emacs-30 byte-compile warning

[Bastien Guerry]

Ihor Radchenko  writes:

> Sure, but we need to confirm with FSF records first.
> Bastien, may you take a look?

Yes, I confirm Arash records are okay, sorry for the delay.

-- 
 Bastien Guerry

Re: [PATCH v2] org-manual.org: $n$-th is not math

[Timothy]

Hi Rudolf,

> Funny, I the exact opposite of you; I would pay many to see $…$th and
> $…$-th special-cased (with tests, so that it would not break again).

I feel the need to point out that this way lies madness.

The behaviour of $ in Org is /inherrently/ confusing. You’re confused by 
`$...$th'
and `$...$-th'. Say those were special-cased, somebody notices the work and then
try `$n$-dimensional' and now are /even more confused/ when it doesn’t work.

Ok, say we make `$...$' just apply in more cases, then we have somebody who
writing about prices who changed `$3 or =$5' to `$3-$5' and now “weird things 
are
happening”.

The root issue is the way that `$' tries to pull double-duty as both a literal 
`$'
and a delimiter. It’s all very well to say that “in LaTeX this is fine”, however
in LaTeX this /simply is not an issue/* as single dollars must be escaped as 
`\$'.

We can fiddle with the heuristics, but there is no perfect solution here …
other than to move away from `$' and prioritise `\( ... \)' in our 
documentation and
examples, even add a linter rule that raises warnings about the tendency of
dollar-math to misbehave when people use it.

All the best,
Timothy

* It’s still a pain/discouraged for other reasons.

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

Re: Hyphen after LaTeX fragments

[Ihor Radchenko]

Dominik Schrempf  writes:

>>> I think this is HIGHLY confusing. I think we should write something
>>> along the lines: "Do not use $...$. Only for reasons of backwards
>>> compatibility, $...$ syntax is partly (!) supported."
>>
>> Feel free to provide a patch.
>
> I think that a change in the documentation alone is insufficient. We
> need to make sure that all current and future maintainers of org-latex
> are aware of the decision to deprecate $...$ (if we make this decision).
> How do we do that?

$...$ is a part of Org markup spec.
We can document the deprecation in
https://orgmode.org/worg/org-syntax.html#LaTeX_Fragments and 
possibly as a comment in source code (org-element.el).

This is still under discussion in 
https://list.orgmode.org/orgmode/87r195nt2g.fsf@localhost/

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

Re: Two low-priority questions re: design of org-babel-do-load-languages

[Ihor Radchenko]

Mandar Mitra  writes:

> Here's the code from my version of org.el (9.5.5, inbuilt in Emacs 28.2).
>
> (defun org-babel-do-load-languages (sym value)
> ...
> 1. Question from purely a programming student's perspective: this seems to be 
> doing two things: (i) a set-default on line 3, and (ii) actually loading the 
> language support libraries. If one were re-designing from scratch, without 
> worrying about backward compatibility, would it be cleaner to separate the 
> above into

The function `org-babel-do-load-languages' is originally not a generic
function. It is specifically designed to be used as a :set function for
`org-babel-load-languages' variable:

(defcustom org-babel-load-languages '((emacs-lisp . t))
...
  :set 'org-babel-do-load-languages
...)

If you alter `org-babel-load-languages' via customize interface or via
`setopt', the :set function is automatically called.

Later, AFAIK, it was also used in the manual as Elisp function.
Against its original design.

>
> (defun org-babel-do-load-languages () ; no arguments

No arguments is not useful. If we look into the manual section "16.9
Languages", it suggests

   By default, only Emacs Lisp is enabled for evaluation.  To enable or
disable other languages, customize the ‘org-babel-load-languages’
variable either through the Emacs customization interface, or by adding
code to the init file as shown next.

   In this example, evaluation is disabled for Emacs Lisp, and enabled
for R.

 (org-babel-do-load-languages
  'org-babel-load-languages
  '((emacs-lisp . nil)
(R . t)))

So, at least, we should leave some way to provide the enabled/disabled
language list (VAL). Otherwise, I do not see much use in the new version
you propose.

>   "Load the languages defined in `org-babel-load-languages'."
>   (interactive) ; why not?   

If this function is interactive, it is useless. The languages listed in
`org-babel-load-languages' will be loaded during Org startup or each
time user is altering the variable value using customize API. No need to
do further manual loading.

> (defun org-babel-update-loaded-languages (value) ; value seems enough, don't 
> need sym
>   "Update the value of `org-babel-load-languages' and call 
> org-babel-do-load-languages"
>   (set-default ...))

This defeats the purpose of :set. The whole idea is to load the required
libraries when the user alters the value of `org-babel-load-languages'.

> 2. This question 
> https://emacs.stackexchange.com/questions/20577/org-babel-load-all-languages-on-demand
>  asks: is there any way for org-babel to load support for languages when I 
> actually try to use a code block with that language? [as opposed to 
> customising org-babel-load-languages or similar]
>
> and the accepted answer suggests the following:
>
> (defadvice org-babel-execute-src-block (around load-language nil activate)
>   "Load language if needed" ...
>
> What would be the downside of making load-on-demand the default for all 
> languages? Then people wouldn't have to customise org-babel-load-languages.

No downside, but load-on-demand is impossible for all the babel
backends. Not every ob-* library has "*" equal to the language name.
For example, ob-emacs-lisp has

(org-babel-make-language-alias "elisp" "emacs-lisp")

allowing

#+begin_src elisp
...
#+end_src

in addition to "#+begin_src emacs-lisp ..."

We cannot know in advance, just looking at the language name, which
library should be loaded.

However, using heuristics as suggested in Emacs StackExchange, could be
a viable addition.

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

Re: Hyphen after LaTeX fragments

[Dominik Schrempf]

Ihor Radchenko  writes:

> Dominik Schrempf  writes:
>
>> Maybe the best thing to do is drop support for $...$ completely?
>
> We cannot do it. Otherwise, existing Org documents may be broken.
>

Well, and as detailed later in my mail, I meant deprecating support for
$...$. But thanks for pointing this out!

>
>> I quote the Org mode manual section about $...$ syntax:
>>
>> Text within the usual LaTeX math delimiters. To avoid conflicts with
>> currency specifications, single ‘$’ characters are only recognized
>> as math delimiters if the enclosed text contains at most two line
>> breaks, is directly attached to the ‘$’ characters with no
>> whitespace in between, and if the closing ‘$’ is followed by
>> whitespace, punctuation or a dash. For the other delimiters, there
>> is no such restriction, so when in doubt, use ‘\(...\)’ as inline
>> math delimiters.
>>
>> I think this is HIGHLY confusing. I think we should write something
>> along the lines: "Do not use $...$. Only for reasons of backwards
>> compatibility, $...$ syntax is partly (!) supported."
>
> Feel free to provide a patch.

I think that a change in the documentation alone is insufficient. We
need to make sure that all current and future maintainers of org-latex
are aware of the decision to deprecate $...$ (if we make this decision).
How do we do that?

Re: Hyphen after LaTeX fragments

[Ihor Radchenko]

Yuchen Guo  writes:

> If it is deprecated in Org mode, maybe we can print a warning message in
> echo area?

Not in echo area, but we can add a linter.

>From 129e3aa03229fd2e5dd6ea9bf627e4d95a061744 Mon Sep 17 00:00:00 2001
Message-Id: <129e3aa03229fd2e5dd6ea9bf627e4d95a061744.1679488572.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Wed, 22 Mar 2023 13:35:22 +0100
Subject: [PATCH] org-lint: Add checker for $...$ LaTeX fragments

* lisp/org-lint.el (org-lint-LaTeX-$): New checker warning about
semi-obsolete $...$ LaTeX fragment syntax.

Link: https://orgmode.org/list/86ileukojk.fsf@lan
---
 lisp/org-lint.el | 13 +
 1 file changed, 13 insertions(+)

diff --git a/lisp/org-lint.el b/lisp/org-lint.el
index 0e2967b6c..8d6d22be7 100644
--- a/lisp/org-lint.el
+++ b/lisp/org-lint.el
@@ -1227,6 +1227,14 @@ (defun org-lint-incomplete-citation (ast)
(org-element-property :parent text))
  "Possibly incomplete citation markup")
 
+(defun org-lint-LaTeX-$ (ast)
+  "Report semi-obsolete $...$ LaTeX fragments."
+  (org-element-map ast 'latex-fragment
+(lambda (fragment)
+  (and (string-match-p "^[$][^$]" (org-element-property :value fragment))
+   (list (org-element-property :begin fragment)
+ "Potentially confusing LaTeX fragment format.  Prefer using more reliable \\(...\\)")
+
 
 ;;; Checkers declaration
 
@@ -1450,6 +1458,11 @@ (org-lint-add-checker 'incomplete-citation
   #'org-lint-incomplete-citation
   :categories '(cite) :trust 'low)
 
+(org-lint-add-checker 'LaTeX-$
+  "Report potentially confusing $...$ LaTeX markup."
+  #'org-lint-LaTeX-$
+  :categories '(markup))
+
 (provide 'org-lint)
 
 ;; Local variables:
-- 
2.39.1


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

Re: Hyphen after LaTeX fragments

[Ihor Radchenko]

Dominik Schrempf  writes:

> Maybe the best thing to do is drop support for $...$ completely?

We cannot do it. Otherwise, existing Org documents may be broken.

> I quote the Org mode manual section about $...$ syntax:
>
> Text within the usual LaTeX math delimiters. To avoid conflicts with
> currency specifications, single ‘$’ characters are only recognized
> as math delimiters if the enclosed text contains at most two line
> breaks, is directly attached to the ‘$’ characters with no
> whitespace in between, and if the closing ‘$’ is followed by
> whitespace, punctuation or a dash. For the other delimiters, there
> is no such restriction, so when in doubt, use ‘\(...\)’ as inline
> math delimiters.
>
> I think this is HIGHLY confusing. I think we should write something
> along the lines: "Do not use $...$. Only for reasons of backwards
> compatibility, $...$ syntax is partly (!) supported."

Feel free to provide a patch.


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

Re: [PATCH] org-user-idle-seconds: Add support for logind

[Ihor Radchenko]

Nathaniel Nicandro  writes:

> I would like to submit a patch that adds support for logind to
> `org-user-idle-seconds`.  This patch has been working for me for a long
> while now and I thought it time for me to submit it.  I've contributed
> to Emacs in the past so my paperwork should be on file.

Thanks!

Though I do not see any commits associated with Nathaniel Nicandro or
your email in Emacs git repo.
Bastien, may you check FSF records?

> Let me know if any changes should be made.
>
> lisp/org-clock.el | 29 +
>  1 file changed, 29 insertions(+)

Please provide the commit message. See
https://orgmode.org/worg/org-contribute.html#commit-messages

> +(defvar org-logind-dbus-session-path
> +  (when (and (boundp 'dbus-runtime-version)
> + (require 'dbus nil t)
> + (member "org.freedesktop.login1" (dbus-list-activatable-names)))
> +(dbus-call-method
> + :system "org.freedesktop.login1"
> + "/org/freedesktop/login1"
> + "org.freedesktop.login1.Manager"
> + "GetSessionByPID" (emacs-pid

Please provide a docstring for the new variable.

Also, this new feature is worth documenting in ORG-NEWS.

Otherwise, the patch looks good.

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

Re: [bug] org-columns-edit-value will capitalize property

[Sławomir Grochowski]

Ok. I will try to send my first patch.
Desired behavior is: by using command 'org-columns-edit-value' do not
change 'property' name, just its value.

On Wed, 22 Mar 2023 at 12:52, Ihor Radchenko  wrote:

> Sławomir Grochowski  writes:
>
> > After updating the value of property using command
> 'org-columns-edit-value'
> > it will capitalize the property name.
> >
> > As I understand, "Org is standardized on lower case"
> > https://list.orgmode.org/87tuuw3n15@nicolasgoaziou.fr/.
> >
> > Is this a bug?
>
> This is for historical reasons.
> Org supports (and will support) both, and we are slowly converting to
> lower case.
>
> Patches welcome to change org-columns-edit-value.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: [PATCH] Async evaluation in ob-shell

[Ihor Radchenko]

Matt  writes:

> Unfortunately, I was mistaken and the second option (removing the space from 
> `org-babel-sh-prompt') doesn't fix the issue.  The TLDR is that the code in 
> `org-babel-comint-async-filter' which grabs the region between the indicators 
> (incorrectly) fails to include the prompt's trailing space.
> --- a/lisp/ob-comint.el
> +++ b/lisp/ob-comint.el
> @@ -273,7 +273,7 @@ STRING contains the output originally inserted into the 
> comint buffer."
>  (res-str-raw
>   (buffer-substring
>;; move point to beginning of indicator
> - (- (match-beginning 0) 1)
> + (match-beginning 0)
>;; find the matching start indicator
>(cl-loop
>do (re-search-backward indicator)

This change looks reasonable.
If it does not break tests, I see not problem with pushing it as a
separate commit (to make things easier in case if that -1 did matter at
the end).

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

Re: [BUG] incorrect result with C-c ! to correct (complete) a date [9.7-pre (release_9.6.1-306-ga645a6 @ /home/d/src/git-org-mode/lisp/)]

[Max Nikulin]

On 22/03/2023 12:34, Daniel Ortmann wrote:

Adjusting [1960-10-16] fails with C-c !

Something to do with the epoch boundary?


It seems you have not noticed the following message that was sent to the 
list only without your address in Cc


Nick Dokos to emacs-orgmode. Re: [BUG] incorrect result with C-c ! to 
correct (complete) a date [9.7-pre (release_9.6.1-306-ga645a6 @ 
/home/d/src/git-org-mode/lisp/)] Mon, 20 Mar 2023 23:24:19 -0400. 
https://list.orgmode.org/87ttyeg524@alphaville.usersys.redhat.com


See `org-read-date-force-compatible-dates'.

P.S. You may try to set the Mail-Followup-To header to your and mailing 
list address to get personal copy. However some mail clients (mu4e?) may 
ignore it.

https://wiki.mozilla.org/Thunderbird:Help_Documentation:Mail-Followup-To_and_Mail-Reply-To

Re: Bugfix release request / agenda* fix

[Ihor Radchenko]

Дмитрий Логвиненко  writes:

> It would be very kind of you if you could make a bugfix release
> including this patch.

If there are no objections, I will tag a minor bugfix release this
weekend.

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

Re: org-ctags land grab

[Ihor Radchenko]

Nick Dokos  writes:

> `org-ctags' unilaterally sets the hook `org-open-link-functions' to a
> bunch of org-ctags functions and enables itself by default. That has
> the unfortunate consequence of invalidating the documentation for
> internal CUSTOM_ID links - see
>
> https://emacs.stackexchange.com/questions/76351/how-to-follow-an-internal-link-in-recent-org-mode

As documented in the top comment of org-ctags.el, the default behaviour
of C-c C-o is modified as you observe:

;; By default, with org-ctags loaded, org will first try and visit the tag
;; with the same name as the link; then, if unsuccessful, ask the user if
;; he/she wants to rebuild the 'TAGS' database and try again; then ask if
;; the user wishes to append 'tag' as a new toplevel heading at the end of
;; the buffer; and finally, defer to org's default behavior which is to
;; search the entire text of the current buffer for 'tag'.

> I proposed a work-around, but it seems to me that `org-ctags'
> functionality should be opt-in and there should be a way to turn it
> off.

It is off by default.

> In addition, it needs a better way to interpolate itself into the
> link ecosystem: breaking internal link functionality is rather
> obnoxious IMO.

It is not breaking the functionality. If you go through the afferent
dialogues, saying "no", it will finally fall back to default Org link
behaviour.

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

Re: [bug] org-columns-edit-value will capitalize property

[Ihor Radchenko]

Sławomir Grochowski  writes:

> After updating the value of property using command 'org-columns-edit-value'
> it will capitalize the property name.
>
> As I understand, "Org is standardized on lower case"
> https://list.orgmode.org/87tuuw3n15@nicolasgoaziou.fr/.
>
> Is this a bug?

This is for historical reasons.
Org supports (and will support) both, and we are slowly converting to
lower case.

Patches welcome to change org-columns-edit-value.

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

Re: [PATCH v2] org-manual.org: $n$-th is not math

[Max Nikulin]

On 21/03/2023 23:38, Rudolf Adamkovič wrote:


Funny, I the exact opposite of you; I would pay many to see $...$th and
$...$-th special-cased (with tests, so that it would not break again).


I do not think it is realistic. It may require models for various 
natural languages and for math expressions. It would be necessary to 
carefully track modifications of text to avoid performance degradation.


Example of false positive:
Topi Mäenpää to emacs-orgmode. Bug report. Wed, 01 Jun 2022 07:53:21 
+. 
https://list.orgmode.org/icEsGOcGni6qhFgjvChMB6qVwr3XpnZv2tcVWApPXwOWkntHtLmKOBeQKB4LPTqeXcMHTeIkyHv9JurAqJzTgjLm4s-HTODJ6h6p4QDMydU=@protonmail.com


Till somebody will demonstrate reliable recognition of "$n$th" you may 
use zero-width space after "$" and an export filter that removes these 
separators.


Personally, I would prefer more strict syntax to avoid zero width spaces 
even if it will require more verbose markup.

Re: [BUG] incorrect result with C-c ! to correct (complete) a date [9.7-pre (release_9.6.1-306-ga645a6 @ /home/d/src/git-org-mode/lisp/)]

[Ihor Radchenko]

Daniel Ortmann  writes:

> Starting with this manually-typed birthday date:
> [1960-10-16]
> Use the arrows to move to the text.
> Now press C-c ! and then ENTER

As documented in 8.2.1 The date/time prompt section of Org manual:

   Not all dates can be represented in a given Emacs implementation.  By
default Org mode forces dates into the compatibility range 1970–2037
which works on all Emacs implementations.  If you want to use dates
outside of this range, read the docstring of the variable
‘org-read-date-force-compatible-dates’.

Emacs implementations that won't be able to handle out-of-range dates
are 32-bit Emacs versions. See
https://yhetil.org/emacs-devel/8735gaqm6i.fsf@localhost

If we can assume that most of Emacs versions are 32-bit, we can flip the
default value of `org-read-date-force-compatible-dates' to nil.
The default `t' value has been set 12 years ago, when 32-bit systems
were much more common.

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

[bug] org-columns-edit-value will capitalize property

[Sławomir Grochowski]

Hello,

After updating the value of property using command 'org-columns-edit-value'
it will capitalize the property name.

As I understand, "Org is standardized on lower case"
https://list.orgmode.org/87tuuw3n15@nicolasgoaziou.fr/.

Is this a bug?

Btw. interesting article about using upper case.
https://www.psychnewsdaily.com/new-study-shows-all-caps-harder-to-read/

GNU Emacs 29.0.60 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24,
cairo version 1.16.0) of 2023-02-26
org release_9.6.1-34

Regards,
Sławomir Grochowski

Re: [BUG] org-capture got file userlock error when I capture on second time.

[Ihor Radchenko]

stardiviner  writes:

> When I org-capture from elfeed-entry buffer (I defined custom functions to
> extract elfeed entry buffer content) in the second time and later, the
> bellowing error raised up. The first-time capture is fine.
>
> Here is the error backtrace:
> #+begin_example
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>   expand-file-name(nil)
>   userlock--check-content-unchanged("~/Org/Tasks/Tasks.org")

This looks like some interaction between Org setting `buffer-file-name'
to nil in *Capture* buffer and Emacs' file locking machinery. Maybe.
Maybe Emacs bug. I have no better ideas.

I also see nothing wrong we do on Org side.

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

Re: [BUG] org-at-timestamp-p not correctly detecting when at a timestamp [9.5.5 (release_9.5.5 @ /usr/share/emacs/28.2/lisp/org/)]

[Ihor Radchenko]

Eddie Drury  writes:

> I've written the following function to test it:
>
>
>   (defun my/test-timestamp ()
> (interactive)
> (if (org-at-timestamp-p)
> (message "Point is at timestamp")
>   (message "Point is not at timestamp")))
>
> When I run this on a timestamp (either active or inactive), it does not
> detect a timestamp.

Works for me on main and bugfix.
Try the latest Org.

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

Re: [BUG] Agenda not sorting by priority THEN todo state (todo state ignored) [9.6.1 (9.6.1-??-fe92a3c @ /Users/polofsson/.emacs.d/.local/straight/build-28.2/org/)]

[Ihor Radchenko]

Jonas Olofsson  writes:

> I am trying to sort my agenda by a number of variables, but it seems
> that todo-state-down is not applied if added after priority-down.
> Instead it seems as if Priority first is applied, then the date the
> item is scheduled.
>
> Repro:
> 1. Set 
>org-agenda-sorting-strategy
>'((agenda priority-down todo-state-down)
>  (todo priority-down todo-state-down effort-up category-keep scheduled-up)
>  (tags priority-down todo-state-down effort-up category-keep)
>  (search category-keep))
> 2. Set 
>org-todo-keywords '(
>(sequence "TODO(t!)" "NEXT(n!)" "WAIT(w!)" "|" 
> "DONE(d!)" "CANC(c!)" "DUPE(D!)")
>)
> 3. Have three todos scheduled:
>
> * TODO [#C] Test
> SCHEDULED: <2023-03-16 Thu>
> * NEXT [#C] Test
> SCHEDULED: <2023-03-15 Wed>
> * WAIT [#C] Test 
> SCHEDULED: <2023-03-17 Fri>
>
> 4. Go to agenda.
>
> I expect to see items in the following order, since they are the same 
> priority.
> WAIT C Test
> NEXT C Test
> TODO C Test
>
> But I see:
> NEXT C Test
> TODO C Test
> WAIT C Test

Confirmed.

Yet another agenda madness I have no clue about.

`org-agenda-get-scheduled' sets the priority as

'priority (if habitp (org-habit-get-priority habitp)
  (+ 99 diff (org-get-priority item)))

where diff is the number of overdue days for a given entry.

Further,

`org-agenda-get-deadlines' has

  'priority
  ;; Adjust priority to today reminders about deadlines.
  ;; Overdue deadlines get the highest priority
  ;; increase, then imminent deadlines and eventually
  ;; more distant deadlines.
  (let ((adjust (if today? (- diff) 0)))
(+ adjust (org-get-priority item)))

`org-agenda-get-todos' has

  priority (1+ (org-get-priority txt)))

All these dates back to the initial Org release.

>From what I am seeing, these awkward priority adjustments are hard-coded
for fine-tune agenda sorting in some (unknown) scenarios.

Changing them will likely break existing sorting.

To fix this, we should carefully check what will happen if we set the
agenda priority to be the actual user-defined priority. And then fix the
sorting back somehow.

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

[BUG] org-at-timestamp-p not correctly detecting when at a timestamp [9.5.5 (release_9.5.5 @ /usr/share/emacs/28.2/lisp/org/)]

[Eddie Drury]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.

org-at-timestamp-p is supposed to test if point is at a timestamp.

I've written the following function to test it:


  (defun my/test-timestamp ()
(interactive)
(if (org-at-timestamp-p)
(message "Point is at timestamp")
  (message "Point is not at timestamp")))

When I run this on a timestamp (either active or inactive), it does not
detect a timestamp.

If I instead test for (org-at-timestamp-p 'inactive), it does correctly
test for inactive timestamps.

Is there something I have overlooked?

I am running: Org Version: 9.5.5 Emacs Version: GNU Emacs 28.2 (build 1,
x86_64-pc-linux-gnu, GTK+ Version 3.24.36, cairo version 1.17.6)

This worked as expected before a recent update.


Emacs  : GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.36, cairo version 1.17.6)
 of 2023-01-03
Package: Org mode version 9.5.5 (release_9.5.5 @
/usr/share/emacs/28.2/lisp/org/)

Re: [patch] ob-clojure: Fix results output

[Ihor Radchenko]

Daniel Kraus  writes:

> Ihor Radchenko  writes:
>
>> I note that we now have a new compiler warning after your changes:
>> ⛔ Warning (comp): ob-clojure.el:268:45: Warning: Unused lexical argument 
>> ‘params’
>>
>> May you please take a look?
>> If the function argument is really unused, replace it with _ in
>> `ob-clojure-eval-with-cider'.
>
> Ups, sorry.
> Before `params` was only used to receive the :target parameter if it's a cljs 
> or clj
> block. But that's now just a regular parameter to the function.
> I fixed it with a _ prefix.

Now, the docstring appears to be a bit confusing:

(defun ob-clojure-eval-with-cider (expanded _params  cljs-p)
  "Evaluate EXPANDED code block with PARAMS using cider.
When CLJS-P is non-nil, use a cljs connection instead of clj."

It would be useful to mention that PARAMS argument is unused.

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

Re: Org Table Header bug?

[Ihor Radchenko]

Ypo  writes:

> The heading and first lines of the table:
>
> |---+---+-|
> | NPS (~\Oslash_int pulg.) | DN (~\Oslash_int mm) | PP/PE (\Oslash_ext mm) |
> |---+---+-|
> | 1/8"  | DN 6  | PE 10 / PP 10   |
> | 1/4"  | DN 8  | PE 12 / PP 12   |
> | 3/8"  | DN 10 | PE 16 / PP 16   |
>
>
> The \Oslash appears as the Unicode character ⊘ normally.
>
>
> The \Oslash is not viewed as the Unicode character ⊘ with 
> "org-table-header-line-mode". And the first line of the table appears in 
> the heading.
>
> https://i.ibb.co/jht3HL0/Captura.png

Confirmed.

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

Re: [PATCH] lisp/ob-scheme.el

[Ihor Radchenko]

Zelphir Kaltstahl  writes:

> I've created a patch, which I will attach to this e-mail.

Thanks!

> Not sure it meets all formalities. For example it is not clear to me, whether 
> I 
> should add the "TINYCHANGE" at the bottom of my commit message.

You should, unless you have FSF copyright assignment.

> Let me know, if this an OK patch or what else needs to be done or what format 
> is 
> wrong, if any.

See my (minor) comments below.

> -- 
> repositories: https://notabug.org/ZelphirKaltstahl
> From 51b299aa18e882681dd681acb51c9cb1b44f3b4e Mon Sep 17 00:00:00 2001
> From: Zelphir Kaltstahl 
> Date: Sat, 18 Mar 2023 16:06:05 +0100
> Subject: [PATCH] lisp/ob-scheme.el:

Please provide a short commit summary, not just the changed file.
See how we do it in https://git.savannah.gnu.org/cgit/emacs/org-mode.git/log/

> Wrapping binding definitions using `let' can lead to issues with GNU
> Guile and potentially other Scheme dialects. GNU Guile will only get
> to the body of the let at evaluation time, not at macro expansion
> time. If the let form wraps any imports of libraries that define
> macros, then those imported macros are seen too late and their
> corresponding forms inside the body of the let are not
> expanded. Using `define' to define bindings avoids this problem, at
> least in GNU Guile.

Please use double space between sentences. Also, it would be helpful to
provide a link to this thread for more context. (The aim of commit
message is a note for future contributors on the reason the change was
made).

> +(defun org-babel-expand-header-arg-vars:scheme (vars)

Please use org-babel-scheme-... function name. It is the usual
Elisp convention to prefix the functions as
library-name-inner-function-name.

The exception in org-babel is a set of special functions that must have
certain name pattern. Expanding header args is not one of those special
functions.

> +  "Expand :var header arguments given as VARS."
> +  (mapconcat
> +   (lambda (var)
> + (format "(define %s %S)" (car var) (cdr var)))

Is there any reason why you use %s for variable name? Previously it was
formatted with escapes (using %S).

Also, previous version quoted the variable value with "'". Why didn't
you do it here?

> +   (concat (org-babel-expand-header-arg-vars:scheme vars) body))

`mapconcat' you used in `org-babel-expand-header-arg-vars:scheme' does
not add trailing newline, unlike done previously.

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

Re: [PATCH] Add tests for ob-haskell (GHCi)

[Ihor Radchenko]

Bruno Barbier  writes:

> Ihor Radchenko  writes:
>
>> From a first look, random failures appear to be related to session
>> initialization.
>
> My function 'test-ob-haskell-ghci' should protect against that; it
> ensures the "*haskell*" buffer is always new.  From what I understand,
> this is an input buffering problem: inputs are not full lines.

I see.

We can try the attached patch. Yet another edge case in comint, it
appears.

>From 2bdcec1e1f9a3ce0314d182a4c50887e8ec80a17 Mon Sep 17 00:00:00 2001
Message-Id: <2bdcec1e1f9a3ce0314d182a4c50887e8ec80a17.1679480064.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Wed, 22 Mar 2023 11:12:30 +0100
Subject: [PATCH] org-babel-comint-with-output: Handle agglomerated prompts
 better

* lisp/ob-comint.el (org-babel-comint-with-output): Consider that
comint can sometimes agglomerate multiple prompts together even within
a single output increment as passed to
`comint-output-filter-functions'.

Example in GHC comint buffer:

GHCi, version 9.0.2: https://www.haskell.org/ghc/  :? for help
ghci> ghci> :{
main :: IO ()
main = putStrLn "Hello World!"
:}

main
"org-babel-haskell-eoe"
ghci| ghci| ghci| ghci> ghci> Hello World!
ghci> "org-babel-haskell-eoe"
ghci>
---
 lisp/ob-comint.el | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-comint.el b/lisp/ob-comint.el
index 54bf5127e..e167d911b 100644
--- a/lisp/ob-comint.el
+++ b/lisp/ob-comint.el
@@ -91,7 +91,16 @@ (defmacro org-babel-comint-with-output (meta  body)
   ;; trailing newline.  Use more reliable
   ;; match to split the output later.
   (replace-regexp-in-string
-   comint-prompt-regexp
+   ;; Sometimes, we get multiple agglomerated
+   ;; prompts together in a single output:
+   ;; "prompt prompt prompt output"
+   ;; Remove them progressively, so that
+   ;; possible "^" in the prompt regexp gets to
+   ;; work as we remove the heading prompt
+   ;; instance.
+   (if (string-prefix-p "^" comint-prompt-regexp)
+   (format "^\\(%s\\)+" (substring comint-prompt-regexp 1))
+ comint-prompt-regexp)
,org-babel-comint-prompt-separator
text
 		 comint-output-filter-functions))
-- 
2.39.1


>> It appears that ob-haskell is re-using sessions even
>> if :session is nil (default). And multiple session not allowed?? (I am
>> looking at `org-babel-haskell-initiate-session', which ignores session
>> parameter completely).
>
> From what I understood, the buffer "*haskell*" is coming from
> haskell-mode. And, to make it work might require some changes there too.

>From my reading of haskell-mode, it seems to be safe if we simply rename
Haskell process buffer upon session initialization.

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

Re: 1 character fix to make ob-haskell compatible with table outputs

[Ihor Radchenko]

ParetoOptimalDev via "General discussions about Org-mode."
 writes:

> Oh, great to hear it's fixed!

Sorry, I was not clear.
I do not know if the bug existed to start with.
I just cannot reproduce on the latest main, which can be for many
reasons, starting from me misunderstanding the bug, or maybe me using
different GHC version.

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