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/)]

2023-03-21 Thread Daniel Ortmann

Excellent.  C-c C-c does work.  I will use that in the future. Thank you.

The 'incorrect' behavior with C-c ! remains.

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

But adjusting [1971-10-16] with C-c ! works fine.

Something to do with the epoch boundary?

On 3/21/23 09:00, Max Nikulin wrote:

On 20/03/2023 08:56, Daniel Ortmann wrote:

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

I expected this result, i.e. I expected the day of the week to be added:
[1960-10-16 Sun]


If all what you need is to add day of week you may try C-c C-c instead 
of C-c !.




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

2023-03-21 Thread General discussions about Org-mode.


Oh, great to hear it's fixed!




Re: [PATCH] Async evaluation in ob-shell

2023-03-21 Thread Matt

 > Matt m...@excalamus.com> writes:
 >
 > I see only two options to fix it: remove a space from the concat expression 
 > (which I did in my latest patch) or remove a space from 
 > `org-babel-sh-prompt'.

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.

#+begin_longwinded_explanation
I'll first explain why removing the space from `org-babel-sh-prompt' doesn't 
fix the issue because it well also highlight the underlying problem.

If we remove the space from the `org-babel-sh-prompt', then 
`comint-prompt-regexp' becomes "^org_babel_sh_prompt> *" (with one space).   
This would work if the string passed to the `ob-shell-async-chunk-callback' 
stayed the same.  It doesn't (this is where my reasoning and testing failed).  
Changing the `org-babel-sh-prompt' to "org_babel_sh_prompt>" (without a space) 
causes the following string to be passed to the callback:

"org_babel_sh_prompt>1
org_babel_sh_prompt>2
org_babel_sh_prompt"

Note that the final prompt doesn't have a ">" and therefore the 
`comint-prompt-regexp' (which becomes "^org_babel_sh_prompt> * (with one 
space)) used in the callback fails to match it.  When we remove the space from 
the `org-babel-sh-prompt', the session buffer looks like this:

"sh-5.1$ PROMPT_COMMAND=;PS1="org_babel_sh_prompt>";PS2=
org_babel_sh_prompt>echo 
'ob_comint_async_shell_start_39610981-1020-4baf-9dfb-f96d10af1cf8'
echo 1
echo 2
echo 'ob_comint_async_shell_end_39610981-1020-4baf-9dfb-f96d10af1cf8'
ob_comint_async_shell_start_39610981-1020-4baf-9dfb-f96d10af1cf8
org_babel_sh_prompt>1
org_babel_sh_prompt>2
org_babel_sh_prompt>ob_comint_async_shell_end_39610981-1020-4baf-9dfb-f96d10af1cf8
org_babel_sh_prompt>"

The `org-babel-comint-async-filter' is what calls the 
`ob-shell-async-chunk-callback' (ob-comint.el:284).  It monitors for the end 
indicator.  When that appears, it passes the region between the beginning of 
the end indicator **less 1** and the character after the end of the start 
indicator to the callback.  For a clean run of 
`test-ob-shell/session-async-evaluation', the beginning of the end indicator is 
at 361 and the character after the end of the start indicator is at 298.  This 
is the string I gave above which is missing the ">".  

In order to make the second option work, we'd need to change the "less 1" part 
of `org-babel-comint-async-filter' from (- (match-beginning 0) 1) to 
(match-beginning 0).   It turns out that's actually all we need to do.

When `org-babel-sh-prompt' is "org_babel_sh_prompt> " (with one space), then 
the session buffer looks like:

"sh-5.1$ PROMPT_COMMAND=;PS1="org_babel_sh_prompt> ";PS2=
org_babel_sh_prompt> echo 
'ob_comint_async_shell_start_3270ed43-a99b-423f-a5fa-b15fb2e4ae26'
echo 1
echo 2
echo 'ob_comint_async_shell_end_3270ed43-a99b-423f-a5fa-b15fb2e4ae26'
ob_comint_async_shell_start_3270ed43-a99b-423f-a5fa-b15fb2e4ae26
org_babel_sh_prompt> 1
org_babel_sh_prompt> 2
org_babel_sh_prompt> 
ob_comint_async_shell_end_3270ed43-a99b-423f-a5fa-b15fb2e4ae26
org_babel_sh_prompt> "

The region passed to the callback is then defined as 366 to 300, or

"org_babel_sh_prompt> 1
org_babel_sh_prompt> 2
org_babel_sh_prompt>"  (<-- no space)

This looks okay at first glance.  However, **the last line is not a valid 
prompt**.  A prompt must end in a space!  When the `org-babel-sh-prompt' is set 
to  "org_babel_sh_prompt> " (with one space), the `comint-prompt-regexp' is 
"^org_babel_sh_prompt>  *" (with two spaces).  This means that the 
`comint-prompt-regexp' matches on a trailing space which the **region passed to 
the callback doesn't have**.  Therefore, the match fails.

Instead, if we modify the `org-babel-comint-async-filter' like

modified   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)

then the region passed to the callback will be from 367 to 300, or

"org_babel_sh_prompt> 1
org_babel_sh_prompt> 2
org_babel_sh_prompt> " (<-- with one space)

The `comint-prompt-regexp' will now match the last prompt in the region.

With this change, the `org-babel-sh-prompt' keeps the trailing space (like it 
should), the `comint-prompt-regexp' becomes "^org_babel_sh_prompt>  *" (with 
two spaces, requiring a prompt to have a trailing space like it should), the 
`ob-shell-async-chunk-callback' can use `comint-prompt-regexp' without 
modification, and the tests all pass.

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

2023-03-21 Thread Mandar Mitra
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)
  "Load the languages defined in `org-babel-load-languages'."
  (set-default sym value)
  (dolist (pair org-babel-load-languages)
(let ((active (cdr pair)) (lang (symbol-name (car pair
  (if active
  (require (intern (concat "ob-" lang)))
(fmakunbound
 (intern (concat "org-babel-execute:" lang)))
(fmakunbound
 (intern (concat "org-babel-expand-body:" lang)))

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

(defun org-babel-do-load-languages () ; no arguments
  "Load the languages defined in `org-babel-load-languages'."
  (interactive) ; why not?   
  (dolist (pair org-babel-load-languages) ... ))

and

(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 ...))


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.


Apologies if this is not the right list for such "idle curiosity" type 
questions, and thanks for any insights!

-mandar



Re: Hyphen after LaTeX fragments

2023-03-21 Thread Yuchen Guo
If it is deprecated in Org mode, maybe we can print a warning message in
echo area?

> but this question will keep coming over and
> over and over until the end of times.

Yet I tried searching Org manual, and also here the mailing list
archive, before posting my latest lame message here.  Maybe I did not
use the correct keyword, maybe something else.

> Clearly, there is a need for the dash, and given the quality and
> syntactic stability of TeX, the problem is not going anywhere
> ... ever.

Absolutely.


signature.asc
Description: PGP signature


Re: Hyphen after LaTeX fragments

2023-03-21 Thread Dominik Schrempf


I like the $...$ syntax, but since it is not fully supported, I rather
use \(...\) consistently; I do not really care.

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

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."

Dominik

Rudolf Adamkovič  writes:

> iem...@gmail.com writes:
>
>> You can write \(n\)-dimensional space.
>
> ROFL.
>
> My apologies for the laugh, but this question will keep coming over and
> over and over until the end of times.  Clearly, there is a need for the
> dash, and given the quality and syntactic stability of TeX, the problem
> is not going anywhere ... ever.
>
> Rudy



Re: org-ctags land grab

2023-03-21 Thread Rudolf Adamkovič
Nick Dokos  writes:

> It is also confusing. To quote the unfortunate victim:
>
>   Now, when I click on the link, or C-c C-o, I get a dialog to "visit
>   tags table"... ???

I have had this happen to me many times too, so +1.

Rudy
-- 
"'Contrariwise,' continued Tweedledee, 'if it was so, it might be; and
if it were so, it would be; but as it isn't, it ain't.  That's logic.'"
-- Lewis Carroll, Through the Looking Glass, 1871/1872

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



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

2023-03-21 Thread Rudolf Adamkovič
Max Nikulin  writes:

> I do not have strong opinion if support of $n$th is tightly bound to
> recognizing $n$-th. On the other hand I would not object deprecation
> of "$...$".

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).

Rudy
-- 
"The introduction of suitable abstractions is our only mental aid to
organize and master complexity."
-- Edsger Wybe Dijkstra, 1930-2002

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



Re: Hyphen after LaTeX fragments

2023-03-21 Thread Rudolf Adamkovič
iem...@gmail.com writes:

> You can write \(n\)-dimensional space.

ROFL.

My apologies for the laugh, but this question will keep coming over and
over and over until the end of times.  Clearly, there is a need for the
dash, and given the quality and syntactic stability of TeX, the problem
is not going anywhere ... ever.

Rudy
-- 
"'Contrariwise,' continued Tweedledee, 'if it was so, it might be; and
if it were so, it would be; but as it isn't, it ain't.  That's logic.'"
-- Lewis Carroll, Through the Looking Glass, 1871/1872

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



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

2023-03-21 Thread Nathaniel Nicandro

Hello,

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.

Let me know if any changes should be made.

lisp/org-clock.el | 29 +
 1 file changed, 29 insertions(+)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index f869b0b..9d34a72 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,25 @@ (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
+
+(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 +1244,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: [PATCH v4] lisp/ob-screen.el: Support ~:var~ header args for babel blocks

2023-03-21 Thread Max Nikulin

On 19/03/2023 21:42, Ken Mankoff wrote:

Here is the other patch. Respect custom screen command.


Thanks, Ken.


+++ b/lisp/ob-screen.el
@@ -98,7 +98,7 @@ In case you want to use a different screen than one selected by 
your $PATH")
  
  (defun org-babel-screen-session-socketname (session)

"Check if SESSION exists by parsing output of \"screen -ls\"."
-  (let* ((screen-ls (shell-command-to-string "screen -ls"))
+  (let* ((screen-ls (shell-command-to-string (concat org-babel-screen-location " 
-ls")))


Currently `org-babel-screen-location' is used as an argument of 
`start-process', so if the value contains spaces or other shell special 
characters they are not interpreted by shell. Since there is no 
convenience function like process-to-string that accepts command as list 
instead of string with a shell command, it is better to pass screen 
location through `shell-quote-argument'.


You may try to create a directory with a space in its name, create a 
symlink from this directory to /usr/bin/srceen, and set 
`org-babel-screen-location' to the full path (with space).





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/)]

2023-03-21 Thread Max Nikulin

On 20/03/2023 08:56, Daniel Ortmann wrote:

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

I expected this result, i.e. I expected the day of the week to be added:
[1960-10-16 Sun]


If all what you need is to add day of week you may try C-c C-c instead 
of C-c !.




Bugfix release request / agenda* fix

2023-03-21 Thread Дмитрий Логвиненко
Hi all,

Here I described my problems with the agenda* as part of a custom block agenda:


https://www.reddit.com/r/orgmode/comments/11nmmgs/agenda_causes_wrong_type_argument_in_custom_block/

Later Ihor answered me that the bug was fixed by him:


https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=92471e53031c4de36ecd65a37e28a48fd139ff4a

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


Regards,
Dmitry Logvinenko