[BUG] error that came up that freezes the cycle of opening subtrees [9.6.6 (release_9.6.6 @ /snap/emacs/current/usr/share/emacs/29.1/lisp/org/)]

2023-10-15 Thread Matthew Nelson Hendryx




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.




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

of 2023-09-23
Package: Org mode version 9.6.6 (release_9.6.6 @ 
/snap/emacs/current/usr/share/emacs/29.1/lisp/org/)


current state:
==
(setq
org-archive-location "./x_archive/Activities_archive.org::* Done and 
Canceled"

org-link-elisp-confirm-function 'yes-or-no-p
org-indirect-buffer-display 'new-frame
org-hide-emphasis-markers t
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 
"\n\n(fn ENTRY)"]
org-agenda-files '("~/aawk/admin/actions/Acts_sync.org" 
"/home/mnh/aawk/admin/actions/Activities_sync.org")

org-replace-disputed-keys t
org-persist-after-read-hook '(org-element--cache-persist-after-read)
org-export-before-parsing-hook '(org-attach-expand-links)
org-cycle-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)

org-archive-hook '(org-attach-archive-delete-maybe)
org-odt-format-inlinetask-function 
'org-odt-format-inlinetask-default-function
org-ascii-format-drawer-function #[771 "\207" [] 4 "\n\n(fn NAME 
CONTENTS WIDTH)"]
org-cycle-hook '(org-cycle-hide-archived-subtrees 
org-cycle-show-empty-lines
org-cycle-optimize-window-after-visibility-change 
org-cycle-display-inline-images)

org-persist-before-read-hook '(org-element--cache-persist-before-read)
org-cycle-open-archived-trees t
org-mode-hook '(#[0 "\205\301 \205\302\303\301 
!\304P!\305!\205\306!\262\207"
[org-ctags-enabled-p buffer-file-name expand-file-name 
file-name-directory "/TAGS" file-exists-p

visit-tags-table]
3]
#[0
"\305\306 
>\203\307\n\310\311#\210\307\312\313#\210\307\314\315#\210\306 
>\203,\307\n\316\317#\210\307\n\320\321#\210\322 
>\203>\307\323\324#\210\307\325\324#\210\326 
>\203P\307\n\327\317#\210\307\n\330\321#\210\331 
>\203_\332\311\f\333BC\334#\210\335 >\203k\332\311\336\334#\210\337 
>\203w\332\311\340\334#\210\341\342\343\344#\207"

[org-mouse-context-menu-function

org-mouse-features

org-mouse-map

org-mode-map

org-outline-regexp

org-mouse-context-menu

context-menu

org-defkey

[mouse-3]

nil

[mouse-3]

org-mouse-show-context-menu

[down-mouse-1]

org-mouse-down-mouse

[C-drag-mouse-1]

org-mouse-move-tree

[C-down-mouse-1]

org-mouse-move-tree-start

yank-link

[S-mouse-2]

org-mouse-yank-link

[drag-mouse-3]

move-tree

[drag-mouse-3]

[down-mouse-3]

activate-stars

font-lock-add-keywords

(0





`(face org-link mouse-face highlight keymap ,org-mouse-map)





'prepend)

t

activate-bullets

(("^[ ]*\\([-+*]\\|[0-9]+[.)]\\) +"





(1











`(face org-link keymap ,org-mouse-map mouse-face highlight)











'prepend)





)





)

activate-checkboxes

(("^[ ]*\\(?:[-+*]\\|[0-9]+[.)]\\)[ ]+\\(?:\\[@\\(?:start:\\)?[0-9]+\\][ 
]*\\)?\\(\\[[- X]\\]\\)"




(1







`(face nil keymap ,org-mouse-map mouse-face highlight)







prepend)



)



)

advice-add org-open-at-point :around org--mouse-open-at-point]
4]
#[0 "\300\301\302\303\304$\207" [add-hook change-major-mode-hook 
org-fold-show-all append local] 5]
#[0 "\300\301\302\303\304$\207" [add-hook change-major-mode-hook 
org-babel-show-result-all append local] 5]

org-babel-result-hide-spec org-babel-hide-all-hashes)
org-archive-subtree-add-inherited-tags t
org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
org-ellipsis " ▾"
org-latex-format-headline-function 
'org-latex-format-headline-default-function

org-confirm-shell-link-function 'yes-or-no-p
org-reveal-start-hook '(org-decrypt-entry)
org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
outline-isearch-open-invisible-function 'outline-isearch-open-invisible
org-use-sub-superscripts '{}
org-odt-format-headline-function 'org-odt-format-headline-default-function
org-agenda-mode-hook '(#[0
"\302\303 \304\305#\210\303 \306\307#\210\303 \310\311#\210\303 
\312\313#\210\303 \314\315#\207"

[org-mouse-context-menu-function

org-agenda-mode-map

org-mouse-agenda-context-menu

org-defkey

[mouse-3]

org-mouse-show-context-menu

[down-mouse-3]

org-mouse-move-tree-start

[C-mouse-4]

org-agenda-earlier

[C-mouse-5]

org-agenda-later

[drag-mouse-3]

#[257

"\300!\211\301\267\202\302\303!\207\304\303!\207\305\207"

[org-mouse-get-gesture





#s(hash-table











size











2











test











eq











rehash-size











1.5











rehash-threshold











0.8125











purecopy











t











data











(:left 9 :right 13)











)





org-agenda-earlier 1 org-agenda-later nil]

4 "\n\n(fn EVENT)" "e"]

]
4]
)
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-archive-file-header-format "* Done and 

Re: Should we move constants.el by Carsten Dominik to Org orphanage?

2023-10-15 Thread Bastien Guerry
Ihor Radchenko  writes:

> Maske  writes:
>
>> There are some links, that I am afraid don't work:
>> ...
>> ‘constants.el’ by Carsten Dominik [...] 
>> http://www.astro.uva.nl/~dominik/Tools.
>>
>>
>> # That link is dead. Maybe this would be the correct one: 
>> https://staff.fnwi.uva.nl/c.dominik/#orgf869524
>
> The source code at https://github.com/cdominik/constants-for-Emacs has
> not been changed since the end of 2020, and I have last seen Carsten
> being active on mailing lists at the beginning of 2021.

(My guess is that Carsten still skims through the list from time to
time.)

> So, we may instead consider marking the package at
> https://orgmode.org/worg/org-orphanage.html and maybe inside
> https://sr.ht/~bzg/org/ project.

I see no reason not to use
https://github.com/cdominik/constants-for-Emacs as the source for
constants.el, the package seems stable (as its name suggests...)

I've fixed the link in the manual.

Of course, if Carsten wants to move the package to Org orphanage, 
no problem.

Thanks,

-- 
 Bastien



Current Org-mode does not work with Emacs 27

2023-10-15 Thread Yasushi SHOJI
Hi all,

 It appears that Emacs 27 lacks the optional argument for
`get-buffer-create`, while `org-element-parse-secondary-string`
relies on it. This problem was introduced by the commit 37d6bde27fe2.

Additionally, `org-id-find-id-in-file` also uses `get-buffer-create`
with a second argument, but it checks the function and has a condition
to call it with or without the argument.

Given that `org-compat.el` already contains compatibility functions
for different Emacs versions, should we create one for
`get-buffer-create` to address this issue? Since `org-compat.el`
provides compatibility layers for Emacs 26.1 and later, it's
reasonable to assume that Org mode still supports Emacs 27?

Thanks,
-- 
   yashi



Re: [BUG] FAILED test-ob-python/session-multiline

2023-10-15 Thread Jack Kamm
Ihor Radchenko  writes:

>> 1. In addition to printing `org-babel-python-eoe-indicator' after
>>execution, we could also print out a "beginning of execution"
>>indicator before execution, and then capture the output between the
>>beginning and end indicators. This is how the async session
>>execution works, and should avoid any possibility of capturing
>>prompts.
>
> This idea looks interesting. Although I would not be so sure that it
> will fix things - I have learned that comint has many edge cases we may
> not easily anticipate.
>
> For example, see the discussion in
> https://yhetil.org/emacs-devel/87y1tgqhmc.fsf@localhost/

I think this strategy could work better in ob-python than ob-shell
because ob-python sends code to a temp file and executes the whole file
at once, which should prevent prompts arising between commands.

I will probably try this approach next, if the fix I just sent here
doesn't work out:

https://list.orgmode.org/87h6mrihfg@gmail.com/

>>Alternatively, we could add an argument to
>>`python-shell-send-string-no-output' to avoid suppressing output,
>>submit it upstream to python.el, and then backport to Org to
>>support older emacs versions.
>
> If we can (eventually) remove some custom code from Org and move it to
> Emacs, it will be the best for working towards RMS request
> https://orgmode.org/list/e1kiph1-0001lu...@fencepost.gnu.org

I started down this path here:

https://lists.gnu.org/archive/html/emacs-devel/2023-10/msg4.html

But I haven't followed up because I started to have some doubts. In
particular, `python-shell-send-string-no-output' will terminate once it
detects a prompt, so if some output looks like it ends in a prompt then
it will terminate prematurely. Whereas in our current indicator-based
approach, the user accidentally emitting
`org-babel-python-eoe-indicator' is unlikely.

Another approach I have considered is to redirect sys.stdout from within
Python. In particular, set it to a custom class inheriting from IOBase
during the block's execution, that both prints and saves the output. I
think this approach could ultimately be more robust, and without needing
to print an ugly indicator token, but it could be complicated to do it
right.



Re: [BUG] FAILED test-ob-python/session-multiline

2023-10-15 Thread Jack Kamm
Ihor Radchenko  writes:

> We have fairly regular CI test failures for one of the ob-python tests.
> The test does not fail _every_ time, but I keep seeing the problem in
> various Emacs versions, including Emacs 29.
>
> Example log: https://builds.sr.ht/~bzg/job/1047678#task-build
>
> In the test the result somehow includes prompt:
>
> Test test-ob-python/session-multiline condition:
> (ert-test-failed
>  ((should
>(equal "20"
> (org-test-with-temp-text "#+begin_src python :session :results 
> output\n  foo = 0\n  for _ in range(10):\n  foo += 1\n\n  foo += 
> 1\n\n  print(foo)\n#+end_src" ...)))
>   :form
>   (equal "20" ">>> 20")
>   :value nil :explanation
>
>
> -->   (arrays-of-different-length 2 6 "20" ">>> 20" first-mismatch-at 0)))

Hello, sorry for the long time to address this.

I've just pushed a commit [1] that might address this, based on a new
hypothesis I have for the root cause:

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

Please let me know whether the problem continues, or whether it seems to
improve.

As an aside -- I am having a hard time figuring out how to monitor our
CI for this. When I search in

https://lists.sr.ht/~bzg/org-build-failures

I can only find an example from 11 months ago. The example you sent
(https://builds.sr.ht/~bzg/job/1047678#task-build) is more recent, but
is "Unlisted" and doesn't show up when I search for it.



Re: [FR] org-num-mode inverse defaults

2023-10-15 Thread Ihor Radchenko
Maske  writes:

>  From the first day, I liked org-num-mode, but I think that its default 
> which numbers all headlines could be problematic.
>
> Right now it only has the options to exclude headlines from being 
> numbered, so it could be necessary to modify a big amount of headlines, 
> for numbering just a tree.
>
> I think it would be helpful to have a "positive" way to numbering 
> headlines, for example "NUMBERED" keyword, while all the other headlines 
> stay unnumbered.

You can simply set UNNUMBERED property to t for the whole document via
#+PROPERTY keyword or by customizing `org-global-properties'. Then, the
headings that should be numbered should have their UNNUMBERED set to nil.

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



[FR] org-num-mode inverse defaults

2023-10-15 Thread Maske

Hi

From the first day, I liked org-num-mode, but I think that its default 
which numbers all headlines could be problematic.


Right now it only has the options to exclude headlines from being 
numbered, so it could be necessary to modify a big amount of headlines, 
for numbering just a tree.


I think it would be helpful to have a "positive" way to numbering 
headlines, for example "NUMBERED" keyword, while all the other headlines 
stay unnumbered.



Bests


Re: [BUG] org agenda showing current time - not task time when closing repeatedly-scheduled task [9.7-pre (release_9.6.10-840-g9fcbd1 @ /home/d/src/git-org-mode/lisp/)]

2023-10-15 Thread Daniel Ortmann

No, no, not clock check mode.

- I created a TODO with a scheduled time that repeats.  When completed 
it remains alive to be scheduled the next day.


- I started the clock on that TODO task.

- Then completed the task with 't' in the Agenda view.

- The task's "clock time" shows in the log ... i.e. how much time I 
spent completing that task.



==>> Previously, a day or so ago, the current local time was recorded in 
the Agenda log rather than the "clock time" (i.e. rather than the time 
spent to complete the task).


==>> Now, the current "clock time" again is correctly recorded in the log.


I hope the screen captured images came across in the previous email?  
They should help explain.


On 10/15/23 04:00, Ihor Radchenko wrote:

Daniel Ortmann  writes:


In the last entry below, the "Clocked:" part of the log would have
showed 3:47 (i.e. the current local CDT time) rather than the time to
complete the task which is now correctly shown as 0:01 minutes.

Do you mean that you used agenda clockcheck mode? I tried and I see no
problem there.


The problem no longer appears!  Excellent.  Not sure what fixed it.
...
Problem fixed ... but it would be nice to know it was not an accidental fix.

I am not sure what you mean by fixed. Did you do anything?


Thank you!  You can close it or investigate further at your discretion.

I am not able to reproduce the problem. Since you cannot either, I am
closing this bug.

Canceled.






Re: Patch: hiding org emphasis markers

2023-10-15 Thread Ihor Radchenko
Ihor Radchenko  writes:

> You may instead introduce a new allowed value for
> `org-hide-emphasis-markers' to hide markers for non-nil entries in
> `org-emphasis-alist'. Maybe even allow the value to be an explicit list
> of the markers to be hidden '("*" "_" ...).

One month have passed since the last activity in this thread.
Are you still interested to address the raised comments?
If you encounter any difficulties, feel free to ask us anything.

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



Re: [BUG] org agenda showing current time - not task time when closing repeatedly-scheduled task [9.7-pre (release_9.6.10-840-g9fcbd1 @ /home/d/src/git-org-mode/lisp/)]

2023-10-15 Thread Ihor Radchenko
Daniel Ortmann  writes:

> In the last entry below, the "Clocked:" part of the log would have 
> showed 3:47 (i.e. the current local CDT time) rather than the time to 
> complete the task which is now correctly shown as 0:01 minutes.

Do you mean that you used agenda clockcheck mode? I tried and I see no
problem there.

> The problem no longer appears!  Excellent.  Not sure what fixed it.
> ...
> Problem fixed ... but it would be nice to know it was not an accidental fix.

I am not sure what you mean by fixed. Did you do anything?

> Thank you!  You can close it or investigate further at your discretion.

I am not able to reproduce the problem. Since you cannot either, I am
closing this bug.

Canceled.

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



Re: [BUG] org agenda showing current time - not task time when closing repeatedly-scheduled task [9.7-pre (release_9.6.10-840-g9fcbd1 @ /home/d/src/git-org-mode/lisp/)]

2023-10-15 Thread Daniel Ortmann

Hey,
The problem no longer appears!  Excellent.  Not sure what fixed it.

In the last entry below, the "Clocked:" part of the log would have 
showed 3:47 (i.e. the current local CDT time) rather than the time to 
complete the task which is now correctly shown as 0:01 minutes.


Problem fixed ... but it would be nice to know it was not an accidental fix.

Thank you!  You can close it or investigate further at your discretion.







On 10/15/23 03:39, Ihor Radchenko wrote:

Daniel Ortmann  writes:


I have a repeatedly-scheduled TODO with this entry for the schedule:
SCHEDULED: <2023-10-15 Sun .+1d -0d>

The TODO is marked with 'sometag'.

In the regular agenda view (C-a a) I narrow with /sometag.
Then S-I to start the clock.
Finally, t and C-c C-c to close today's action.

The result is that the agenda shows the current time (in this case
9:41) ...

May you please elaborate about "agenda shows the current time"?



Re: [BUG] org agenda showing current time - not task time when closing repeatedly-scheduled task [9.7-pre (release_9.6.10-840-g9fcbd1 @ /home/d/src/git-org-mode/lisp/)]

2023-10-15 Thread Ihor Radchenko
Daniel Ortmann  writes:

> I have a repeatedly-scheduled TODO with this entry for the schedule:
> SCHEDULED: <2023-10-15 Sun .+1d -0d>
>
> The TODO is marked with 'sometag'.
>
> In the regular agenda view (C-a a) I narrow with /sometag.
> Then S-I to start the clock.
> Finally, t and C-c C-c to close today's action.
>
> The result is that the agenda shows the current time (in this case
> 9:41) ...

May you please elaborate about "agenda shows the current time"?

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



Re: [PATCH] Fix :var parameter for fish shell code blocks

2023-10-15 Thread Ihor Radchenko
Elias Kueny  writes:

> I found an issue with fish shell code blocks, in that the `:var' parameter 
> generates a command that is not syntaxically correct. Fish uses `set variable 
> value' instead of `variable = value'. As a result, org-babel throws an error 
> when executing the code block. This patch fixes this by adding an exception 
> to org-babel-variable-assignments:shell on the model of what it already does 
> for bash.

Thanks for the patch!
Applied, onto bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c42cdcda4

You are now listed as an Org contributor:
https://git.sr.ht/~bzg/worg/commit/fdc3c55f

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



Re: [BUG] org-clock-auto-clockout does not actually use x11idle on X11 [9.6.8 (release_9.6.8-3-g21171d @ /usr/share/emacs/30.0.50/lisp/org/)]

2023-10-15 Thread Ihor Radchenko
Vladimir Nikishkin  writes:

> For some time I have been wondering why auto-clockout does not use
> x11idle on my machine.
> ...
> or, even better:
>
> #+begin_src elisp
> (defun org-clock-auto-clockout-maybe ()
>(if (< org-clock-auto-clockout-timer (if org-x11idle-exists-p
>(org-x11-idle-seconds)
>  (current-idle-time)
> (defun org-clock-auto-clockout-insinuate ()
>   "Set up hook for auto clocking out when Emacs is idle.
> See `org-clock-auto-clockout-timer'.
>
> This function is meant to be added to the user configuration."
>   (require 'org-clock)
>   (add-hook 'org-clock-in-hook #'org-clock-auto-clockout-maybe t)
>   (add-hook 'org-clock-out-hook (lambda ()
>(cancel-function-timers 'org-clock-auto-clockout-maybe
> #+end_src

Makes sense.
Would you be interested to submit a patch?
See https://orgmode.org/worg/org-contribute.html

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



Re: [BUG] No newline at end of exported HTML file [9.6.6 (release_9.6.6 @ /Applications/MacPorts/Emacs.app/Contents/Resources/lisp/org/)]

2023-10-15 Thread Ihor Radchenko
YE  writes:

>> Ihor Radchenko  writes:
>> See the attached tentative patch.
>
> Thanks, LGTM so far.

Applied, onto bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=51937d4b1

Fixed.

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