Link to #ID-id:

[Daniel Clemente]

Hi,
  after updating org-mode and emacs to latest commits, I have seen that
some links to IDs in different files are exported like this:
some link: link

  Shouldn't it be?:   otherfile.html#c5m2je81pue0

  I didn't have time to debug this yet or see if it's from my setup. I may
do it in the next days.

Re: [proof of concept] inline language blocks

[Daniel Clemente]

> I have thought of a syntax that is as least intrusive as possible, so as
> not to make reading uncomfortable. I have tried the following:
>
> :fr{some text in French} :it{some text in Italian} :la{some text in Latin}

Sorry for joining the discussion a bit late. A long time ago I created a
syntax to be able to mix languages in that way, and a program to separate
each version into a different file.

Info: https://www.danielclemente.com/dislines/
Sample: https://www.danielclemente.com/dislines/perl.txt
Syntax: https://www.danielclemente.com/dislines/syntax.en.html
Syntax in practice: https://www.danielclemente.com/dislines/quick.en.txt

It's format-agnostic, and unrelated to org. I have used it in plain HTML
and other file types.
Many times I tried to use it for org-mode, and while it works, the
challenges are more. For instance I'd like to integrate it into the export
process (so that a single command produces many files), I want to use it to
translate headers (but where do you keep the translations of the header
name? in the header itself? in a property?), I want the TOC to use the
translated headers, and I want to keep links working (and making sure each
language only links to files in the same language). More difficult yet:
what if a particular language requires another header structure (more
headers, fewer headers, or headers arranged in another way).
I tried several approaches (inline tasks, SRC blocks, my own syntax, tags
in headers, one sub-header per language, selective export of tags,
properties in headers, post-processing, exporting all and making language
selection in JS, one manual TOC per language, …). But I didn't have time to
think or discover a good system. Multi-language hypertext systems are hard.

Maybe you can get some ideas from this, if you're still working on mixing
human languages in org paragraphs/headers/lines/files. I see the discussion
may have shifted from multilingual texts (i.e. human languages) to
multi-backend texts (e.g. export HTML/LaTeX/… differently); multi-backend
variations might be an easier goal than dealing with multilingual texts and
translations.

Thanks for implementing code for your ideas.

On Tue, 20 Feb 2024 at 20:36, Juan Manuel Macías 
wrote:

> Hi,
>
> I'm dedicating a local branch to developing this proof of concept and
> testing it in my workflow, so far with good results. The basic idea is
> to provide Org with multilingual features and various methods for
> selecting languages.
>
> The inline-language-block is intended for small segments of text in a
> language other than the main language. They can span several lines but
> not more than a paragraph. They can be used for in-line textual quotes,
> glosses, etc. They are constructions equivalent to, for example, LaTeX
> \foreignlanguage{french}{text} or HTML text.
>
> I have thought of a syntax that is as least intrusive as possible, so as
> not to make reading uncomfortable. I have tried the following:
>
> :fr{some text in French} :it{some text in Italian} :la{some text in Latin}
>
> You can also use a literal term instead of a language code:
>
> :klingon!{some text in Klingon}
>
> The blocks can be nested:
>
> :klingon!{Some text in Klingon with :it{some text in Italian}}
>
> And they may include other elements:
>
> :el{Some text in Greek with a {{{macro}}} and a [[link]]}
>
> To this end, I have defined the following element:
>
> #+begin_src emacs-lisp
> (defun org-element-inline-language-block-parser ()
>   "Parse inline language block at point.
>
> When at an inline language block, return a new syntax node of
> `inline-language-block' type containing `:begin', `:end',
> `:type', `:contents-begin', `:contents-end' and `:post-blank' as
> properties.  Otherwise, return nil.
>
> Assume point is at the beginning of the block."
>   (save-excursion
> (when (looking-at ":\\([A-Za-z!]+\\){")
>   (goto-char (match-end 0))
>   (let* ((begin (match-beginning 0))
>  (contents-begin (match-end 0))
>  (type (org-element--get-cached-string
> (match-string-no-properties 1)))
>  (contents-end
>   (progn
> (goto-char (- contents-begin 1))
> (org-element--parse-paired-brackets ?\{)
> (- (point) 1)))
>  (post-blank (skip-chars-forward " \t"))
>  (end (point)))
> (when contents-end
>   (org-element-create
>'inline-language-block
>(list :type type
>  :contents-begin contents-begin
>  :contents-end contents-end
>  :begin begin
>  :end end
>  :post-blank post-blank)))
>
> (defun org-element-inline-language-block-interpreter
> (inline-language-block contents)
>   "Interpret INLINE LANGUAGE BLOCK object as Org syntax."
>   (format ":%s{%s}"
>   (org-element-property :type inline-language-block)
>   contents))
> #+end_src
>
> And, for 

Re: [BUG] repeated warnings about org-element-at-point "cannot be used in non-Org buffer" [9.7 (9.7-??-57b94f3 @ /Users/cstevens/.emacs.d/.local/straight/build-29.2/org/)]

[Daniel Clemente]

Thanks, I replaced org-cycle/org-global-cycle with
outline-cycle/outline-cycle-buffer, and then the outlining works.

On Tue, 6 Feb 2024 at 18:56, Ihor Radchenko  wrote:

> Daniel Clemente  writes:
>
> > I also see the warnings. In my case it's because I'm using outline-minor
> > mode in an elisp file. I'm not sure it's supported, but it worked years
> > ago: ...
>
> It is not supported by Org mode.
> The modern outline mode has `outline-cycle'.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>

Re: [BUG] repeated warnings about org-element-at-point "cannot be used in non-Org buffer" [9.7 (9.7-??-57b94f3 @ /Users/cstevens/.emacs.d/.local/straight/build-29.2/org/)]

[Daniel Clemente]

I also see the warnings. In my case it's because I'm using outline-minor
mode in an elisp file. I'm not sure it's supported, but it worked years
ago: I could fold and unfold sections with usual org-mode keys like C-tab.
I miss that feature. I never managed to learn the real outline-mode
keys/concepts (outline-show-branches, outline-hide-subtree etc.).

To reproduce it, I used test.el with:


;; -*- mode: emacs-lisp; mode:outline-minor; hs-minor-mode: nil;
outline-regexp:"* [^ \n]" -*-

;; a
;;; a1
;; b


Then I went to ;; a and pressed C-tab, expecting to open/close that
section (showing/hiding the a1). And I saw the warning, and an error:
rx--translate-bounded-repetition: rx ‘**’ range error [3 times]

Please excuse if my expectations or my test file are broken. I didn't use
this feature in years.





On Tue, 30 Jan 2024 at 16:17, Ihor Radchenko  wrote:

> Christopher Stevenson  writes:
>
> > I get these warnings about org-element when I am in non-org files; the
> > main ones that come to mind are JavaScript files and in magit when I am
> > doing a commit. They don't seem to break anything but it does get
> > annoying to have to constantly dismiss them.
>
> These warnings indicate that some of your packages or customization
> causes `org-element-at-point' to be executed in non-Org buffer.
> `org-element-at-point' does not have a defined behaviour in non-Org
> buffers and may cause random errors.
>
> If you can narrow down the caller of `org-element-at-point', I suggest
> you to report the observed behaviour as a bug (if that is a third-party
> package).
>
> Otherwise, you may suppress the Org warning.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>
>

Re: An academic journal entirely made in Org-Mode

[Daniel Ortmann]

Yes, please!

--
Daniel Ortmann
https://www.linkedin.com/in/danieldeanortmann/
https://ieee-collabratec.ieee.org/app/p/DanielDeanOrtmann/
612-518-3147 m

On 1/29/24 14:03, Juan Manuel Macías wrote:

Hi,

In last December, issue 23 of the "Revista de Estudios Latinos" (Journal
of Latin Studies) was published, sponsored by the Spanish Society of
Latin Studies. It is designed and produced by me using Org-Mode,
Org-Publish and LuaTeX. If anyone is interested in the code I used for
specific aspects of the publication, I can share it here :-).

Link to the journal in PDF version:

https://recyt.fecyt.es/index.php/rel/issue/view/4327/948

And a screenshot of the making-off:

https://i.imgur.com/lkwIOGA.png

Best regards,

Juan Manuel

Re: [POLL] Any users setting `org-agenda-use-tag-inheritance' to nil or other non-default value?

[Daniel Clemente]

> 1. If you customized it to speed up agendas, are agendas still slow on
the latest main?

I disabled org-agenda-use-tag-inheritance but I can't provide a lot of
feedback because I don't use many tag filters:

1. I disabled it in a batch script that exports my agenda, though it
doesn't actually speed up the agenda (even with org-element-use-cache
disabled); I guess it's because the agenda view I'm exporting doesn't do
any filter (in particular, filter by tag).

2. I disabled it in my .emacs, but I guess it has no effect because I also
disabled org-use-tag-inheritance, because I've never needed tag inheritance.

I temporarily enabled org-use-tag-inheritance
and org-agenda-use-tag-inheritance and opened an agenda that filters by tag
(it combines 4 one-tag filters), it seems to run almost as fast; 25 to 26
seconds with tag inheritance enabled, whereas with tag inheritance disabled
it takes around 24 seconds. These are manual measurements which may be 1 or
2 seconds off, so you may want to measure it more precisely; they may take
the same time. Anyway I don't see slowness due to tag inheritance in agenda.


On Thu, 4 Jan 2024 at 17:28, Ihor Radchenko  wrote:

> Hello,
>
> We have a customization `org-agenda-use-tag-inheritance' that controls
> whether agenda searches should use tag inheritance or not.
>
> One of the main motivations to introduce it was that agenda searches
> could become really slow when resolving inherited tags. However,
> inherited tags can now be retrieved very fast, after org-element-cache
> has been enabled by default. At least, it is the theory.
>
> I'd like to hear from the users who customized
> `org-agenda-use-tag-inheritance':
>
> 1. If you customized it to speed up agendas, are agendas still slow on
>the latest main?
>
> 2. If you customized it for other reasons, may you please explain your
>use case?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>
>

Org site is down

[Daniel Fleischer]

Orgmode.org appears to be down.

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

[Daniel Ortmann]

A bit more clarity ...

 * If the task clock is activated on a TODO in the agenda,
 * and closed quickly enough that the elapsed time is 0:00,
 * then MOMENTARILY the agenda shows the CURRENT WALLCLOCK TIME.
 * The actual logbook entry shows the correct 0:00 elapsed task time.
 * And when the agenda is merely REFRESHED the wallclock time is
   replaced with the 0:00.


So there seems to be NO BUG.  It's just an odd transient behavior which 
I now noticed only because of tracking "time" on some small tasks.


Definitely not worth touching brittle code.  "It's just how it is."

And that's ok!  :-)

Thank you for your attention to this matter which now is clearly smaller 
than expected.


On 10/16/23 02:38, Ihor Radchenko wrote:

Daniel Ortmann  writes:


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.

Ok. Got it.


==>> 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 looked into the code, and I do have a feeling that it is brittle
(agenda is a very old and convoluted code), but without a concrete
reproducer I wouldn't dare to touch it.


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

I indeed did not notice the attachments - they were not indicated in the
plain/text part of the email. They indeed did help to explain things.

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

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

[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"?

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

[Daniel Ortmann]

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.


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)
instead of the correct 6 minutes. Note that the task's LOGBOOK entry
correctly shows 0:06 minutes.

I expected to see the usual 6 minutes for the task in the agenda view.
Today is the first time I noticed this anomaly, but perhaps it has been
happening previously?
Not sure if this is new as of today: [2023-10-14 Sat 09:47] (CDT time)

A sample task:
* TODO sometask with sometag :sometag:
SCHEDULED: <2023-10-15 Sun .+1d -0d>

Emacs : GNU Emacs 30.0.50 (build 40, x86_64-pc-linux-gnu, GTK+ Version 
3.24.37, cairo version 1.16.0)

of 2023-10-14
Package: Org mode version 9.7-pre (release_9.6.10-840-g9fcbd1 @ 
/home/d/src/git-org-mode/lisp/)

--
Daniel Ortmann  612-518-3147 m
key: C9E170E2, fingerprint = 81BB 6CAF F1EC F6C7 690C F4E9 66D7 7AFD 
C9E1 70E2

Re: [BUG] org sub tree sort broken [9.7-pre (release_9.6.10-827-ge15699 @ /home/d/src/git-org-mode/lisp/)]

[Daniel Ortmann]

Fix confirmed.

Thank you!

On 10/12/23 03:21, Ihor Radchenko wrote:

Daniel Ortmann  writes:


org-element--generate-copy-script: Symbol\u2019s function definition is
void: org-export--list-bound-variables

Sorry. Silly mistake in a recent commit.
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f660afc50

[BUG] org sub tree sort broken [9.7-pre (release_9.6.10-827-ge15699 @ /home/d/src/git-org-mode/lisp/)]

[Daniel Ortmann]

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.


Create a test-of-org-sort.org file with the following content:
* top
** one
** two
** three

Click mouse-1 on the top heading.

Press C-c ^ a
... to attempt to sort the sub headings alphabetically.

The result is:
Sort children: [a]lpha [n]umeric [p]riority p[r]operty todo[o]rder [f]unc
[t]ime [s]cheduled [d]eadline [c]reated cloc[k]ing
A/N/P/R/O/F/T/S/D/C/K means reversed:
Sorting entries...
org-element--generate-copy-script: Symbol\u2019s function definition is 
void: org-export--list-bound-variables



Emacs : GNU Emacs 30.0.50 (build 37, x86_64-pc-linux-gnu, GTK+ Version 
3.24.37, cairo version 1.16.0)

of 2023-10-11
Package: Org mode version 9.7-pre (release_9.6.10-827-ge15699 @ 
/home/d/src/git-org-mode/lisp/)

--
Daniel Ortmann  612-518-3147 m
key: C9E170E2, fingerprint = 81BB 6CAF F1EC F6C7 690C F4E9 66D7 7AFD 
C9E1 70E2

Re: [BUG] Failing tests for ob-clojure

[Daniel Kraus]

Ihor Radchenko  writes:

>> Unfortunately you're right and I would even say we can completely
>> remove `test-ob-clojure.el`.
>> There seems to be only tests for session support which currently
>> doesn't exist anymore and another one which tests plain tangle
>> and is not really Clojure specific.
>
> Done.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=fcca76274

Thanks!

Re: [BUG] Failing tests for ob-clojure

[Daniel Kraus]

Hi!

Ihor Radchenko  writes:

> I am now going through all the babel tests that are disabled by default.
>
> ob-clojure tests appear to be completely broken:
>
> 1. (org-test-for-executable "cider") assertion is strange as cider
>package does not have any executable.
>
> 2. All the tests seems to assert that ob-clojure supports sessions,
>while it does not seem to be the case.

Unfortunately you're right and I would even say we can completely
remove `test-ob-clojure.el`.
There seems to be only tests for session support which currently
doesn't exist anymore and another one which tests plain tangle
and is not really Clojure specific.

I would love to write new tests but as I just started a new job
and got a new baby at the same time, I don't think I'll find the
time for it the next 3-4 month :(

Thanks,
  Daniel

[BUG] org-up-heading-safe navigates above top heading [9.5.5 (release_9.5.5 @ /opt/homebrew/Cellar/emacs-plus@28/28.2/share/emacs/28.2/lisp/org/)]

[Daniel Liden]

Summary: I started to encounter some errors while using the org-fc package
after. I traced it back to a change in behaviour from org-up-heading-safe
following some updates to my system. I did not see this change documented.

Old behavior: org-up-heading-safe will not move the point above the top
headline in an org hierarchy (e.g. if there is text above a top-level
headline.)

New behavior: org-up-heading-safe *will* move the point above the top
headline in an org hierarchy (e.g. if there is text above a top-level
headline.)

Unfortunately, I'm not sure what version exactly I updated from. However,
see example, I did look at the diff for org-up-heading-safe and found this—
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=dfd36d1969ce2c33f5899e97c02fa62544735977.
The older version has the expected behavior (well, the behavior I
expected); the newer version will go up above the top headline.

See attached org file with (hopefully) reproducible example.

Emacs  : GNU Emacs 28.2 (build 2, aarch64-apple-darwin22.4.0, NS
appkit-2299.50 Version 13.3.1 (Build 22E261))
 of 2023-05-01
Package: Org mode version 9.5.5 (release_9.5.5 @
/opt/homebrew/Cellar/emacs-plus@28/28.2/share/emacs/28.2/lisp/org/)

current state:
==
(setq
 org-link-elisp-confirm-function 'yes-or-no-p
 org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
"\n\n(fn ENTRY)"]
 org-export-before-parsing-hook '(org-attach-expand-links)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines
 org-optimize-window-after-visibility-change)
 org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-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-confirm-shell-link-function 'yes-or-no-p
 outline-isearch-open-invisible-function 'outline-isearch-open-invisible
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
 org-link-shell-confirm-function 'yes-or-no-p
 org-babel-pre-tangle-hook '(save-buffer)
 org-agenda-loop-over-headlines-in-active-region nil
 org-occur-hook '(org-first-headline-recenter)
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link) ("id" :follow org-id-open)
  ("eww" :follow org-eww-open :store org-eww-store-link)
  ("rmail" :follow org-rmail-open :store org-rmail-store-link)
  ("mhe" :follow org-mhe-open :store org-mhe-store-link)
  ("irc" :follow org-irc-visit :store org-irc-store-link :export
org-irc-export)
  ("info" :follow org-info-open :export org-info-export :store
org-info-store-link)
  ("gnus" :follow org-gnus-open :store org-gnus-store-link)
  ("docview" :follow org-docview-open :export org-docview-export :store
org-docview-store-link)
  ("bibtex" :follow org-bibtex-open :store org-bibtex-store-link)
  ("bbdb" :follow org-bbdb-open :export org-bbdb-export :complete
org-bbdb-complete-link :store
org-bbdb-store-link)
  ("w3m" :store org-w3m-store-link) ("doi" :follow org-link-doi-open
:export org-link-doi-export) ("file+sys")
  ("file+emacs") ("shell" :follow org-link--open-shell)
  ("news" :follow #[514 "\301\300\302 Q \"\207" ["news" browse-url ":"]
6 "\n\n(fn URL ARG)"])
  ("mailto" :follow #[514 "\301\300\302 Q \"\207" ["mailto" browse-url
":"] 6 "\n\n(fn URL ARG)"])
  ("https" :follow #[514 "\301\300\302 Q \"\207" ["https" browse-url
":"] 6 "\n\n(fn URL ARG)"])
  ("http" :follow #[514 "\301\300\302 Q \"\207" ["http" browse-url ":"]
6 "\n\n(fn URL ARG)"])
  ("ftp" :follow #[514 "\301\300\302 Q \"\207" ["ftp" browse-url ":"] 6
"\n\n(fn URL ARG)"])
  ("help" :follow org-link--open-help :store org-link--store-help)
("file" :complete org-link-complete-file)
  ("elisp" :follow org-link--open-elisp))
 org-metaup-hook '(org-babel-load-in-session-maybe)
 )


org-up-heading-safe-example.org
Description: Binary data

Re: [BUG] wrong-type-argument syntax-table-p "Syntax table including \"@\" and \"_\" as word constituents.

[Daniel Clemente]

It works now. Thanks!

On Mon, 29 May 2023 at 08:34, Ihor Radchenko  wrote:

> Daniel Clemente  writes:
>
> >   there was a recent change to how the tags table is initialized. I think
> > that as a side effect, some tag functions like org-tags-expand don't work
> > unless you open an org-mode buffer first. I have a small bash script that
> > exports my agenda; right in the beginning (before opening any org-mode
> > file) it collects some data by calling org-map-entries. org-map-entries
> > needs org-tags-expand, which now fails because the syntax table hasn't
> been
> > initialized yet.
> >
> > Minimal case to reproduce this:
>
> Thanks for reporting!
> Fixed, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=24ed8b204
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>

[BUG] wrong-type-argument syntax-table-p "Syntax table including \"@\" and \"_\" as word constituents.

[Daniel Clemente]

Hi,

  there was a recent change to how the tags table is initialized. I think
that as a side effect, some tag functions like org-tags-expand don't work
unless you open an org-mode buffer first. I have a small bash script that
exports my agenda; right in the beginning (before opening any org-mode
file) it collects some data by calling org-map-entries. org-map-entries
needs org-tags-expand, which now fails because the syntax table hasn't been
initialized yet.

Minimal case to reproduce this:

1. run: emacs -Q

2. load latest org:
(add-to-list 'load-path "/…/org-mode/lisp")
(require 'org)

3. eval:
   (org-tags-expand "+sometag")

You'll see:

Debugger entered--Lisp error: (wrong-type-argument syntax-table-p "Syntax
table including \"@\" and \"_\" as word constit...")
  org-tags-expand("+sometag")
  (progn (org-tags-expand "+sometag"))
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)


If I open any .org file before step 3, then it will work.

I think the related commit is:
commit 6e6354c074a323780f103aabf45be74104ce3ecf
Author: Ihor Radchenko 
Date:   Mon May 8 13:23:15 2023 +0200

org-tags-expand: Do no modify buffer's syntax table by side effect

* lisp/org.el (org-mode-tags-syntax-table): New variable holding
syntax table for tags.
(org-mode): Initialize tag syntax table.
(org-make-tags-matcher): Match tags using appropriate syntax table.
(org-tags-expand): Do no modify syntax table by side effect.

Reported-by: Mattias Engdegård 
Link: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63225#68


Of course I could make sure to open an org file (any file) before calling
org-map-entries but that seems like a workaround to a bug. I would expect
(org-map-entries … 'agenda) to also work before opening any .org file.

[BUG] org-element-cache [9.6.5 (release_9.6.5-3-g2993f4 @ /opt/homebrew/Cellar/emacs-plus@29/29.0.90/share/emacs/29.0.90/lisp/org/)]

[Daniel Popescu]

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.


Warning (org-element-cache): org-element--cache: Unregistered buffer
modifications detected (126308 != 126242). Resetting.
If this warning appears regularly, please report the warning text to Org
mode mailing list (M-x org-submit-bug-report).
The buffer is: data-intro.org
 Current command: nil
 Backtrace:
"  backtrace-to-string(nil)
  org-element--cache-sync(#)
  apply(org-element--cache-sync #)
  timer-event-handler([t 0 0 311452 nil org-element--cache-sync (#) idle 99 nil])
"

Emacs  : GNU Emacs 29.0.90 (build 1, aarch64-apple-darwin22.4.0, NS
appkit-2299.50 Version 13.3.1 (a) (Build 22E772610a))
 of 2023-05-12
Package: Org mode version 9.6.5 (release_9.6.5-3-g2993f4 @
/opt/homebrew/Cellar/emacs-plus@29/29.0.90/share/emacs/29.0.90/lisp/org/)

Re: ob-clojure: results quoted nil

[Daniel Kraus]

Ihor Radchenko  writes:

>> #+RESULTS:
>> : nil is falsey
>
> Even if it is the case, it is still worth checking :results table
> parsing. nils might be slurped when converting output to tables.

Right.
I just double checked the results for value and table results with
different Clojure backends and it worked in all cases (that I tested).

Cheers,
  Daniel

Re: ob-clojure: results quoted nil

[Daniel Kraus]

Hi!

r...@devsphoto.com writes:

> The quoted NIL is not showing on the Result block.
>
> Org mode version 9.6.1 (9.6.1-??-fe92a3ced @
> /Users/rafiks/.emacs.d/.local/straight/build-28.2/org/)
>
>   #+begin_src clojure :results value
>  (nil? 1)
>  (nil? nil)
>  (if "bears eat beets"
>"bears beets Battlestar Galactica")
>  (if nil
>"This won't be the result because nil is falsey"
>"nil is falsey")
> #+end_src
>
> #+RESULTS:
> | false  |
> | true   |
> | "bears beets Battlestar Galactica" |
> | " is falsey"   |

The results you get from a ob-clojure block got re-worked recently.
That `:results value` returned ALL values and not only the last one
was actually a bug.
Can you try again with the latest org (/ob-clojure) version?
You should now only get:

#+RESULTS:
: nil is falsey

Thanks,
  Daniel

Re: [BUG] Tangling of clojure code blocks is broken [9.7 (9.7-??-0807107 @ /Users/ag/.emacs.d/.local/straight/build-30.0.50/org/)]

[Daniel Kraus]

Hi!

Ag  writes:

> Setting :results output header makes it work as expected. Without it -
> it's as I described, wrapped.

I can reproduce the bug.

The problem is that or :results value (/the default) I only want the
result of the last expression and I do that `binding` of stdout to surpress
all other output.
But I guess during tangle this should just be ignored?
Is there a simple way to find out if `org-babel-execute:clojure` is
executed or tangled?

If it should be ignored on tangle, what about the :var defines.
We recently discussed this for ob-scheme where there was a problem with the
`let` wrapper.
Is it ok or expected that a the tangled code is wrapped in a let block?
Should I change it to a global `def`?

Thanks for the bug report.

PS, a minimal repo is

minimal-org-clj.el:
#+BEGIN_SRC emacs-lisp
;;; Minimal setup to load latest `org-mode'.

;; Activate debugging.
(setq debug-on-error t
  debug-on-signal nil
  debug-on-quit nil)

;; Add latest Org mode to load path.
(add-to-list 'load-path (expand-file-name "/home/daniel/.emacs.d/lib/org/lisp"))

(org-babel-do-load-languages
 'org-babel-load-languages
 '((clojure . t)))
#+END_SRC

/usr/bin/emacs -Q -l minimal-org-clj.el

And then tangle something like:

#+begin_src clojure :backend babashka :tangle foo.clj
{:foo :bar}
#+end_src

Cheers,
  Daniel

Re: [PATCH] Add compat.el support to Org (was: [POLL] Use compat.el in Org? (was: Useful package? Compat.el))

[Daniel Mendler]

On 4/1/23 12:31, Ihor Radchenko wrote:
> Ihor Radchenko  writes:
> 
>> I have recently been contacted by the current compat.el maintainer
>> asking if we are willing to adapt compat.el in Org.
> 
> See the attached patch set adding support of compat.el.
> 
> I had to update Org's build system to handle third-party packages.
> Please, give it a close check (first patch).
> 
> The second patch adds the actual Elisp part and replaces some
> compatibility functions with what is provided by compat.el.
> Note that not all the functions are available in compat.el for now.
> Daniel, you might want to take a look.
> 
> The last patch adds the necessary explanation for users who install Org
> from git. Now, they must install compat.el manually to make Org work.

>From my side, the change looks good. The current Compat version 29.1.4.x
is stable with no known issues.

Daniel

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

[Daniel Kraus]

Ihor Radchenko  writes:

>> Or rather something like:
>>
>> (defun ob-clojure-eval-with-cider (expanded _params  cljs-p)
>>   "Evaluate EXPANDED code block using cider.
>> When CLJS-P is non-nil, use a cljs connection instead of clj.
>> The PARAMS from Babel are not used in this function."
>
> I like the second variant better.

Thanks.
I pushed the fix.

Cheers,
  Daniel

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

[Daniel Kraus]

Ihor Radchenko  writes:

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

Should I go with your initial suggestion and just replace it with _?
Like

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

But then someone will maybe wonder why there is unused argument?

Or rather something like:

(defun ob-clojure-eval-with-cider (expanded _params  cljs-p)
  "Evaluate EXPANDED code block using cider.
When CLJS-P is non-nil, use a cljs connection instead of clj.
The PARAMS from Babel are not used in this function."


Writing good docstrings is hard :D

Cheers,
  Daniel

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

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

[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 !.

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

[Daniel Ortmann]

--=-=-=
Content-Type: text/plain



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.


* correct date information
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]

But the following incorrect result occurs:
[1970-10-16 Fri]



--=-=-=
Content-Type: text/plain
Content-Disposition: attachment; filename=date-edit-oops.org
Content-Description: date edit oops org file


* correct date information
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]

But the following incorrect result occurs:
[1970-10-16 Fri]

--=-=-=
Content-Type: text/plain



Emacs : GNU Emacs 30.0.50 (build 50, x86_64-pc-linux-gnu, GTK+ Version 
3.24.34, cairo version 1.16.0)

of 2023-03-19
Package: Org mode version 9.7-pre (release_9.6.1-306-ga645a6 @ 
/home/d/src/git-org-mode/lisp/)

--
Daniel Ortmann  612-518-3147 m
key: C9E170E2, fingerprint = 81BB 6CAF F1EC F6C7 690C F4E9 66D7 7AFD 
C9E1 70E2


--=-=-=--

* correct date information
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]

But the following incorrect result occurs:
[1970-10-16 Fri]

Re: [SUGGESTION] separate ob-clojure.el into Clojure part ob-clojure.el and ClojureScript part ob-clojurescript.el

[Daniel Kraus]

Ihor Radchenko  writes:

> stardiviner  writes:
>
>> For now, ob-clojure.el contains lot of code for ClojureScript. Only some
>> code has same functionality. Like CIDER backend. In the future,
>> ClojureScript part code will increase and different. So I suggest
>> separate them into two source code files.
>>
>> WDYT?

I'm not opposed to it, but I'm also not sure if it's worth it.
Without whitespace and comments, ob-clojure is only 261 LOC and without
having a closer look I would guess we would have to duplicate maybe 150
of those in ob-clojurescript.
It would make the implementation a bit cleaner but at the cost of
code duplication.
I would say we wait until the ClojureScript part really grows bigger
and then do a split if that should ever happen.
I could also see a scenario where we add support for ClojureDart
and/or ClojureCLR to ob-clojure. It would be very simple if they
have a CLI like the JVM Clojure.


> The only downside is that people might need to
> (require 'ob-clojurescript)
> I am thinking if ob-core.el should try to automatically guess the
> correct library to be loaded.

We could just (require 'ob-clojurescript) inside ob-clojure.el ?!

Cheers,
  Daniel

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

[Daniel Kraus]

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.

Cheers,
  Daniel

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

[Daniel Kraus]

Ihor Radchenko  writes:

> What will happen with users who customized `org-babel-clojure-backend'
> to 'nbb in the past?

They would have gotten an error.
I changed it now that 'nbb backend is still allowed in a clojure
source block but it will internally treated as ClojureScript.

>> +(defcustom org-babel-clojurescript-backend
>> +  (cond
>> +   ((or (executable-find "nbb") (executable-find "npx")) 'nbb)
>> +   ((featurep 'cider) 'cider)
>> +   (t nil))
>> +  "Backend used to evaluate Clojure code blocks."
>
> This docstring is exactly the same with `org-babel-clojure-backend'.
> What is the difference?
> I think ""Backend used to evaluate ClojureScript code blocks." will be
> more clear. I feel that other docstrings may also need to be clarified
> depending whether they affect Clojure or ClojureScript blocks.

I changed the docstrings to always mention either Clojure or ClojureScript.
I'm open for more improvements/suggestions.

Attached a new patch.

Thanks,
  Daniel

>From 391bdd403f643fa75cceeb0c81f117996c2374b0 Mon Sep 17 00:00:00 2001
From: Daniel Kraus 
Date: Thu, 9 Mar 2023 16:11:27 +0100
Subject: [PATCH] ob-clojure.el: Fix results output, support clojure-cli

* lisp/ob-clojure.el (org-babel-clojure-backend): Add support for
clojure-cli.
* lisp/ob-clojure.el (org-babel-clojurescript-backend): Move nbb to
clojurescript.
* lisp/ob-clojure.el (org-babel-expand-body:clojure)
* lisp/ob-clojure.el (ob-clojure-eval-with-cider): Return only the
last expression when :results is not set or value, and return only
stdout when :results is set to output.
* lisp/ob-clojure.el (ob-clojure-eval-with-cmd): Rename function as
it is not only for babashka.
* lisp/ob-clojure.el (org-babel-execute:clojure): Differentiate
between Clojure and ClojureScript source blocks.

The problem was that the ob-clojure results where not correctly
taking the results parameter into account.
E.g. with the cider backend, you would get all printed or returned
values for each line in your block:

(def small-map {:a 2 :b 4 :c 8})
{:some :map}
(prn :xx)
(:b small-map)

| #'user/small-map |
| {:some :map} |
| 4|

or for babashka you would only get the printed values but not the
last return value:
(def small-map {:a 2 :b 4 :c 8})
{:some :map}
(prn :xx)
(:b small-map)

: :xx

Now when you specify :results value, the result is only the last
returned value, and with :results output you get all values
printed to stdout.
So the examples above would all result in the same:
(def small-map {:a 2 :b 4 :c 8})
{:some :map}
(prn :xx)
(:b small-map)

: 4
---
 etc/ORG-NEWS   |  23 +++
 lisp/ob-clojure.el | 156 -
 lisp/org-compat.el |   4 ++
 3 files changed, 126 insertions(+), 57 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index b9d7b3459..4ca13af17 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -96,6 +96,21 @@ The face ~org-agenda-calendar-daterange~ is used to show entries with
 a date range in the agenda.  It inherits from the default face in
 order to remain backward-compatible.
 
+*** New ~org-babel-clojurescript-backend~ option to choose ClojureScript backend
+
+Before, a ClojureScript source block used the same backend as Clojure,
+configured in ~org-babel-clojure-backend~ and relied on an undocumented
+~:target~ paramter.
+
+Now, there's ~org-babel-clojurescript-backend~ to determine the
+backend used for evaluation of ClojureScript.
+
+*** Support for Clojure CLI in ~ob-clojure~
+
+~ob-clojure~ now supports executing babel source blocks with the
+official [[https://clojure.org/guides/deps_and_cli][Clojure CLI tools]].
+The command can be customized with ~ob-clojure-cli-command~.
+
 ** New features
 *** ~org-metaup~ and ~org-metadown~ now act on headings in region
 
@@ -116,6 +131,14 @@ selection.
 TODO state, priority, tags, statistics cookies, and COMMENT keywords
 are allowed in the tree structure.
 
+** Miscellaneous
+*** Remove undocumented ~:target~ header parameter in ~ob-clojure~
+
+The ~:target~ header was only used internally to distinguish
+from Clojure and ClojureScript.
+This is now handled with an optional function parameter in
+the respective functions that need this information.
+
 * Version 9.6
 
 ** Important announcements and breaking changes
diff --git a/lisp/ob-clojure.el b/lisp/ob-clojure.el
index 5f589db00..70e032154 100644
--- a/lisp/ob-clojure.el
+++ b/lisp/ob-clojure.el
@@ -25,20 +25,21 @@
 
 ;;; Commentary:
 
-;; Support for evaluating Clojure code
+;; Support for evaluating Clojure / ClojureScript code.
 
 ;; Requirements:
 
 ;; - Clojure (at least 1.2.0)
 ;; - clojure-mode
-;; - inf-clojure, Cider, SLIME, babashka or nbb
+;; - babashka, nbb, Clojure CLI tools, Cider, inf-clojure or SLIME
 
 ;; For clojure-mode, see https://github.com/clojure-emacs/clojure-mode
-;; For inf-clojure, see https://github.com/clojure-emacs/inf-clojur

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

[Daniel Kraus]

Daniel Kraus  writes:

> Attached is the new patch with the changes.
>
> [2. text/x-patch; 0001-lisp-ob-sql.el-Add-support-for-Athena.patch]...

Ups, I attached the wrong one.
Here the correct patch..


>From db0634b5ab0b5c8c996c5dcbbeb266b720c67459 Mon Sep 17 00:00:00 2001
From: Daniel Kraus 
Date: Thu, 9 Mar 2023 16:11:27 +0100
Subject: [PATCH] ob-clojure.el: Fix results output, support clojure-cli

* lisp/ob-clojure.el (org-babel-clojure-backend): Add support for
clojure-cli.
* lisp/ob-clojure.el (org-babel-clojurescript-backend): Move nbb to
clojurescript.
* lisp/ob-clojure.el (org-babel-expand-body:clojure)
* lisp/ob-clojure.el (ob-clojure-eval-with-cider): Return only the
last expression when :results is not set or value, and return only
stdout when :results is set to output.
* lisp/ob-clojure.el (ob-clojure-eval-with-cmd): Rename function as
it is not only for babashka.
* lisp/ob-clojure.el (org-babel-execute:clojure): Differentiate
between Clojure and ClojureScript source blocks.

The problem was that the ob-clojure results where not correctly
taking the results parameter into account.
E.g. with the cider backend, you would get all printed or returned
values for each line in your block:

(def small-map {:a 2 :b 4 :c 8})
{:some :map}
(prn :xx)
(:b small-map)

| #'user/small-map |
| {:some :map} |
| 4|

or for babashka you would only get the printed values but not the
last return value:
(def small-map {:a 2 :b 4 :c 8})
{:some :map}
(prn :xx)
(:b small-map)

: :xx

Now when you specify :results value, the result is only the last
returned value, and with :results output you get all values
printed to stdout.
So the examples above would all result in the same:
(def small-map {:a 2 :b 4 :c 8})
{:some :map}
(prn :xx)
(:b small-map)

: 4
---
 etc/ORG-NEWS   |  23 +++
 lisp/ob-clojure.el | 149 -
 lisp/org-compat.el |   4 ++
 3 files changed, 120 insertions(+), 56 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index b9d7b3459..4ca13af17 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -96,6 +96,21 @@ The face ~org-agenda-calendar-daterange~ is used to show entries with
 a date range in the agenda.  It inherits from the default face in
 order to remain backward-compatible.
 
+*** New ~org-babel-clojurescript-backend~ option to choose ClojureScript backend
+
+Before, a ClojureScript source block used the same backend as Clojure,
+configured in ~org-babel-clojure-backend~ and relied on an undocumented
+~:target~ paramter.
+
+Now, there's ~org-babel-clojurescript-backend~ to determine the
+backend used for evaluation of ClojureScript.
+
+*** Support for Clojure CLI in ~ob-clojure~
+
+~ob-clojure~ now supports executing babel source blocks with the
+official [[https://clojure.org/guides/deps_and_cli][Clojure CLI tools]].
+The command can be customized with ~ob-clojure-cli-command~.
+
 ** New features
 *** ~org-metaup~ and ~org-metadown~ now act on headings in region
 
@@ -116,6 +131,14 @@ selection.
 TODO state, priority, tags, statistics cookies, and COMMENT keywords
 are allowed in the tree structure.
 
+** Miscellaneous
+*** Remove undocumented ~:target~ header parameter in ~ob-clojure~
+
+The ~:target~ header was only used internally to distinguish
+from Clojure and ClojureScript.
+This is now handled with an optional function parameter in
+the respective functions that need this information.
+
 * Version 9.6
 
 ** Important announcements and breaking changes
diff --git a/lisp/ob-clojure.el b/lisp/ob-clojure.el
index 5f589db00..f254fa204 100644
--- a/lisp/ob-clojure.el
+++ b/lisp/ob-clojure.el
@@ -25,20 +25,21 @@
 
 ;;; Commentary:
 
-;; Support for evaluating Clojure code
+;; Support for evaluating Clojure / ClojureScript code.
 
 ;; Requirements:
 
 ;; - Clojure (at least 1.2.0)
 ;; - clojure-mode
-;; - inf-clojure, Cider, SLIME, babashka or nbb
+;; - babashka, nbb, Clojure CLI tools, Cider, inf-clojure or SLIME
 
 ;; For clojure-mode, see https://github.com/clojure-emacs/clojure-mode
-;; For inf-clojure, see https://github.com/clojure-emacs/inf-clojure
-;; For Cider, see https://github.com/clojure-emacs/cider
-;; For SLIME, see https://slime.common-lisp.dev
 ;; For babashka, see https://github.com/babashka/babashka
 ;; For nbb, see https://github.com/babashka/nbb
+;; For Clojure CLI tools, see https://clojure.org/guides/deps_and_cli
+;; For Cider, see https://github.com/clojure-emacs/cider
+;; For inf-clojure, see https://github.com/clojure-emacs/inf-clojure
+;; For SLIME, see https://slime.common-lisp.dev
 
 ;; For SLIME, the best way to install its components is by following
 ;; the directions as set out by Phil Hagelberg (Technomancy) on the
@@ -78,20 +79,33 @@ defvar org-babel-header-args:clojurescript
 
 (defcustom org-babel-clojure-backend (cond
   ((executable-find "bb") 'babashka)
-  ((execu

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

[Daniel Kraus]

Hi!

Ihor Radchenko  writes:

> Daniel Kraus  writes:
>
>> This was apparently a kludge that ob-clojure used to evaluate ClojureScript
>> in the normal clojure:execute function.
>> I simply used the same kludge where I need to check for cljs, but after
>> reviewing it's not really necessary and I removed the :target parameter
>> completely. As this was undocumented I guess it's ok to remove?!
>
> Yes, it is OK to remove what is undocumented. We may still announce the
> change though.

I added an entry to ORG-NEWS under Misc.

>>>> -(defun ob-clojure-eval-with-babashka (bb expanded)
>> I created an obsolete-function-alias.
>
> It should better go to org-compat.el.

Moved the alias to org-compat.
I wasn't sure where to put it exactly.
It's now in the ~Obsolete aliases~ page.

> What about the new customization `ob-clojure-cli-command'?

I added a news entry in ORG-NEWS.

>> +(defcustom ob-clojure-nbb-command (or (executable-find "nbb")
>> +  (when-let (npx (executable-find 
>> "npx"))
>> +(concat npx " nbb")))
>>"Path to the nbb executable."
>
> This is not a path anymore, when the value is "npx nbb".
> Can just use "Command to invoke nbb executable".

Fixed.


Attached is the new patch with the changes.


Thanks for your review and guidance,
  Daniel
>From ddace051205d20b24c047962ca9d1335bdd90284 Mon Sep 17 00:00:00 2001
From: Daniel Kraus 
Date: Mon, 16 Jan 2023 11:35:02 +0100
Subject: [PATCH] lisp/ob-sql.el: Add support for Athena

* lisp/ob-sql.el (org-babel-execute:sql): Add support for Athena
---
 lisp/ob-sql.el | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/lisp/ob-sql.el b/lisp/ob-sql.el
index 39a4573a5..640ecb2c0 100644
--- a/lisp/ob-sql.el
+++ b/lisp/ob-sql.el
@@ -53,14 +53,15 @@
 ;; - rowname-names
 ;;
 ;; Engines supported:
-;; - mysql
+;; - athena
 ;; - dbi
 ;; - mssql
-;; - sqsh
-;; - postgresql (postgres)
+;; - mysql
 ;; - oracle
-;; - vertica
+;; - postgresql (postgres)
 ;; - saphana
+;; - sqsh
+;; - vertica
 ;;
 ;; TODO:
 ;;
@@ -254,6 +255,11 @@ This function is called by `org-babel-execute-src-block'."
(org-babel-temp-file "sql-out-")))
 	 (header-delim "")
  (command (cl-case (intern engine)
+(athena (format "athenacli %s -e %s %s > %s"
+			(or cmdline "")
+			(org-babel-process-file-name in-file)
+database
+			(org-babel-process-file-name out-file)))
 (dbi (format "dbish --batch %s < %s | sed '%s' > %s"
  (or cmdline "")
  (org-babel-process-file-name in-file)
@@ -352,7 +358,7 @@ SET COLSEP '|'
 	(progn (insert-file-contents-literally out-file) (buffer-string)))
   (with-temp-buffer
 	(cond
-	 ((memq (intern engine) '(dbi mysql postgresql postgres saphana sqsh vertica))
+	 ((memq (intern engine) '(athena dbi mysql postgresql postgres saphana sqsh vertica))
 	  ;; Add header row delimiter after column-names header in first line
 	  (cond
 	   (colnames-p
@@ -377,7 +383,7 @@ SET COLSEP '|'
 	  (goto-char (point-max))
 	  (forward-char -1))
 	(write-file out-file
-	(org-table-import out-file (if (string= engine "sqsh") '(4) '(16)))
+	(org-table-import out-file (if (memq (intern engine) '(athena sqsh)) '(4) '(16)))
 	(org-babel-reassemble-table
 	 (mapcar (lambda (x)
 		   (if (string= (car x) header-delim)
-- 
2.39.0

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

[Daniel Kraus]

Hi!

Ihor Radchenko  writes:

> You need to document the changes in ORG-NEWS.

I added an entry about the new ClojureScript change.
I guess the other (main) part of the patch is a bugfix and will not
be documented in ORG-NEWS.

> Also, see inline comments below.
>
>> Subject: [PATCH] ob-clojure.el: Fix results output, support clojure-cli
>
> Does it have to be a single commit? Not a big deal, but two separate
> commits would be cleaner.

I saw that as well but unfortunately I did it all in the same go
and then touch the same code parts, so separating them in individual
working commits, while not a huge task, is still some work with not
much benefit.

>> -;; Support for evaluating Clojure code
>> +;; Support for evaluating Clojure / ClojureScript code.
>
> This is an important new feature that should be announced clearly in ORG-NEWS.

ClojureScript source blocks where supported before, but just no way to set
the backend for it separately. See the ORG-NEWS in the new attached patch.

> Also, make sure that
> https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-clojure.html
> is up-to-date.

Good reminder. I send a PR for this when this patch is installed?!


>>  (defcustom org-babel-clojure-backend (cond
>>((executable-find "bb") 'babashka)
>> -  ((executable-find "nbb") 'nbb)
>> +  ((executable-find "clojure") 
>> 'clojure-cli)
>>((featurep 'cider) 'cider)
>>((featurep 'inf-clojure) 'inf-clojure)
>>((featurep 'slime) 'slime)
>> @@ -87,11 +88,24 @@ defcustom org-babel-clojure-backend
>>:group 'org-babel
>>:package-version '(Org . "9.6")
>
> Org 9.7. This is a new feature to come in the next release.

Fixed.

>> +(defcustom org-babel-clojurescript-backend
>> +  (cond
>> +   ((or (executable-find "nbb") (executable-find "npx")) 'nbb)
>> +   ((featurep 'cider) 'cider)
>> +   (t nil))
>> +  "Backend used to evaluate Clojure code blocks."
>> +  :group 'org-babel
>> +  :package-version '(Org . "9.6")
>
> 9.7
> New customization to be announced in ORG-NEWS.

Fixed.

>> -(defcustom ob-clojure-nbb-command (executable-find "nbb")
>> +(defcustom ob-clojure-nbb-command (or (executable-find "nbb")
>> +  (when-let (npx (executable-find 
>> "npx"))
>> +(concat npx " nbb")))
>>"Path to the nbb executable."
>>:type '(choice file (const nil))
>> +  :group 'org-babel)
>
> It is no longer a path, despite what is claimed in the docstring.
> :type definition is also not accurate.
> Also, update :package-version.

Fixed.

>> +(defcustom ob-clojure-cli-command (when-let (cmd (executable-find 
>> "clojure"))
>> +(concat cmd " -M"))
>> +  "Clojure CLI command used to execute source blocks."
>> +  :type 'file
>>:group 'org-babel
>>:package-version '(Org . "9.6"))
>
> 9.7

Fixed.

>>  (defun org-babel-expand-body:clojure (body params)
>>"Expand BODY according to PARAMS, return the expanded body."
>>(let* ((vars (org-babel--get-vars params))
>> + (cljs-p (string= (cdr (assq :target params)) "cljs"))
>
> Note: I do not see :target header arg being documented in
> https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-clojure.html

This was apparently a kludge that ob-clojure used to evaluate ClojureScript
in the normal clojure:execute function.
I simply used the same kludge where I need to check for cljs, but after
reviewing it's not really necessary and I removed the :target parameter
completely. As this was undocumented I guess it's ok to remove?!

>> -(defun ob-clojure-eval-with-babashka (bb expanded)
>> -  "Evaluate EXPANDED code block using BB (babashka or nbb)."
>> -  (let ((script-file (org-babel-temp-file "clojure-bb-script-" ".clj")))
>
> This will remove a non-private function. May you leave a fallback
> obsolete alias to not break third-party code that calls the old function
> name?

I created an obsolete-function-alias.


Attached is the new patch with the changes.

Thanks,
  Daniel
>From 3ad98fa88f6ebd4ae1b2b41d66cca9e9d6e1875e Mon Sep 17 00:00:00 2001
From: Daniel Kraus 
Date: Thu, 9 Mar 2023 16:11:27 +0100
Subject: [PATCH] ob-clojure.el: Fix results output, support clo

[patch] ob-clojure: Fix results output

[Daniel Kraus]

Hi,

attached is a bigger patch that fixes the result output of ob-clojure.
The commit message contains examples what's currently wrong
and what's fixed.
This is a breaking change though.
So if someone before relied on the fact that, e.g. cider, returns
the result of every expression in every line instead of only the
last one, they get a different result now.

Is it ok to install?
Other feedback?

Cheers,
  Daniel
>From 77783d864d81ef1d962c302523d7c588f248c088 Mon Sep 17 00:00:00 2001
From: Daniel Kraus 
Date: Thu, 9 Mar 2023 16:11:27 +0100
Subject: [PATCH] ob-clojure.el: Fix results output, support clojure-cli

* lisp/ob-clojure.el (org-babel-clojure-backend): Add support for
clojure-cli.
* lisp/ob-clojure.el (org-babel-clojurescript-backend): Move nbb to
clojurescript.
* lisp/ob-clojure.el (org-babel-expand-body:clojure)
* lisp/ob-clojure.el (ob-clojure-eval-with-cider): Return only the
last expression when :results is not set or value, and return only
stdout when :results is set to output.
* lisp/ob-clojure.el (ob-clojure-eval-with-cmd): Rename function as
it is not only for babashka.
* lisp/ob-clojure.el (org-babel-execute:clojure): Differentiate
between Clojure and ClojureScript source blocks.

The problem was that the ob-clojure results where not correctly
taking the results parameter into account.
E.g. with the cider backend, you would get all printed or returned
values for each line in your block:

(def small-map {:a 2 :b 4 :c 8})
{:some :map}
(prn :xx)
(:b small-map)

| #'user/small-map |
| {:some :map} |
| 4|

or for babashka you would only get the printed values but not the
last return value:
(def small-map {:a 2 :b 4 :c 8})
{:some :map}
(prn :xx)
(:b small-map)

: :xx

Now when you specify :results value, the result is only the last
returned value, and with :results output you get all values
printed to stdout.
So the examples above would all result in the same:
(def small-map {:a 2 :b 4 :c 8})
{:some :map}
(prn :xx)
(:b small-map)

: 4
---
 lisp/ob-clojure.el | 120 +
 1 file changed, 77 insertions(+), 43 deletions(-)

diff --git a/lisp/ob-clojure.el b/lisp/ob-clojure.el
index 5f589db00..6345927d6 100644
--- a/lisp/ob-clojure.el
+++ b/lisp/ob-clojure.el
@@ -25,20 +25,21 @@
 
 ;;; Commentary:
 
-;; Support for evaluating Clojure code
+;; Support for evaluating Clojure / ClojureScript code.
 
 ;; Requirements:
 
 ;; - Clojure (at least 1.2.0)
 ;; - clojure-mode
-;; - inf-clojure, Cider, SLIME, babashka or nbb
+;; - babashka, nbb, Clojure CLI tools, Cider, inf-clojure or SLIME
 
 ;; For clojure-mode, see https://github.com/clojure-emacs/clojure-mode
-;; For inf-clojure, see https://github.com/clojure-emacs/inf-clojure
-;; For Cider, see https://github.com/clojure-emacs/cider
-;; For SLIME, see https://slime.common-lisp.dev
 ;; For babashka, see https://github.com/babashka/babashka
 ;; For nbb, see https://github.com/babashka/nbb
+;; For Clojure CLI tools, see https://clojure.org/guides/deps_and_cli
+;; For Cider, see https://github.com/clojure-emacs/cider
+;; For inf-clojure, see https://github.com/clojure-emacs/inf-clojure
+;; For SLIME, see https://slime.common-lisp.dev
 
 ;; For SLIME, the best way to install its components is by following
 ;; the directions as set out by Phil Hagelberg (Technomancy) on the
@@ -78,7 +79,7 @@ defvar org-babel-header-args:clojurescript
 
 (defcustom org-babel-clojure-backend (cond
   ((executable-find "bb") 'babashka)
-  ((executable-find "nbb") 'nbb)
+  ((executable-find "clojure") 'clojure-cli)
   ((featurep 'cider) 'cider)
   ((featurep 'inf-clojure) 'inf-clojure)
   ((featurep 'slime) 'slime)
@@ -87,11 +88,24 @@ defcustom org-babel-clojure-backend
   :group 'org-babel
   :package-version '(Org . "9.6")
   :type '(choice
-	  (const :tag "inf-clojure" inf-clojure)
+	  (const :tag "babashka" babashka)
+  (const :tag "clojure-cli" clojure-cli)
 	  (const :tag "cider" cider)
+	  (const :tag "inf-clojure" inf-clojure)
 	  (const :tag "slime" slime)
-	  (const :tag "babashka" babashka)
+	  (const :tag "Not configured yet" nil)))
+
+(defcustom org-babel-clojurescript-backend
+  (cond
+   ((or (executable-find "nbb") (executable-find "npx")) 'nbb)
+   ((featurep 'cider) 'cider)
+   (t nil))
+  "Backend used to evaluate Clojure code blocks."
+  :group 'org-babel
+  :package-version '(Org . "9.6")
+  :type '(choice
 	  (const :tag "nbb" nbb)
+	  (const :tag "cider" cider)
 	  (const :tag "Not configured yet" nil)))
 
 (defcustom org-babel-clojure-default-ns "user"
@@ -105,1

Re: org-babel guile source block bug in handling multiple values

[Daniel Kraus]

Ihor Radchenko  writes:

> Zelphir Kaltstahl  writes:

>> (q1) What is a rationale, if any, behind the let-wrapping?
>
> It makes sense in ob-emacs-lisp to not litter global Emacs state.
> In other ob-* lisp backends, I am not sure.
> I am CCing Daniel, the maintainer of ob-clojure (we have no active
> maintainer for ob-scheme now). Maybe, Daniel has some useful insight.

No, unfortunately I don't have any more insights than already discussed.

I think wrapping the vars in let just seems natural for lisps.

If I could freely choose if a :var declaration in one source block
should create a global variable for all other blocks in this session,
I would say making it only available in the defining source block
is more natural (i.e. use let instead of def).
But given that apparently almost all other babel languages define
a global var, I'll just make the same change in ob-clojure?!

Cheers,
  Daniel

[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]

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.


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.

Emacs : GNU Emacs 30.0.50 (build 10, x86_64-pc-linux-gnu, GTK+ Version 
3.22.30, cairo version 1.15.12)

of 2023-02-21
Package: Org mode version 9.6.1 (release_9.6.1-262-gd94f40 @ 
/home/dortmann/src/git-org-mode/lisp/)

Re: feature request: easy embedding of images

[Daniel Fleischer]

Jude DaShiell [2023-02-20 Mon 16:24] wrote:

> To help accessibility it would be useful when an image was dragged into
> org-mode if the user got prompted for an image description that gets
> associated with the image in org-mode.  Some images are art work and those
> should get alt="" tags if a user fails to provide a description but only
> after asking if this image is art work or something that needs a
> description.  If a description is provided that should go between the
> quotes in the alt="" tag.

In org-download you can specify html attributes for the attached image,
see link

https://github.com/abo-abo/org-download/blob/master/org-download.el#L178-L184

It's not a prompt, it's a template and you can fill the alt description.

-- 
Daniel Fleischer

Re: feature request: easy embedding of images

[Daniel Fleischer]

Alexis Gallagher [2023-02-18 Sat 16:22] wrote:

> This is a feature request — or failing that, a request for advice on a 
> settings configuration which could produce this
> functionality now. 

Russell mentioned a package and pointed to the image issues related to
Emacs, not Org.

I want to suggest the package https://github.com/abo-abo/org-download
which I use all time, for dragging and dropping images and for taking
screeshots. 

-- 
Daniel Fleischer

Re: [BUG] Incorrect display of folded headings after cycling with subheading with VISIBILITY content/children

[Daniel Hubmann]

Ah, my bad. Got confused. The output above set according to the properties
is correct.

Thanks a lot for the fast fix.

On Wed, Feb 15, 2023 at 11:26 PM Daniel Hubmann  wrote:

> Thanks for the partial fix.
>
> Unfortunately there is still something strange going on as the last
> heading gets hidden. Added some more headings to demonstrate this better:
>
> This is the unfolded file content:
>
> * Heading Lvl 1
> ** Heading Lvl 2 with VISIBILITY content
> :PROPERTIES:
> :VISIBILITY: content
> :END:
> *** Heading Lvl 3
> ** Another Heading Lvl 2
> * Formulas
> ** New Ones
> *** LET
> *** LAMBDA
> :PROPERTIES:
> :VISIBILITY: content
> :END:
> *** XMATCH
> *** XLOOKUP
> * Dynamic Array Formulas
>
> After using org-cycle-content followed by
> org-cycle-set-visibility-according-to-property I get this:
>
> * Heading Lvl 1
> ** Heading Lvl 2 with VISIBILITY content...
> *** Heading Lvl 3...
> * Formulas
> *** LAMBDA
> * Dynamic Array Formulas
>
> Whereas the expected output should look as follows:
>
> * Heading Lvl 1
> ** Heading Lvl 2 with VISIBILITY content
> *** Heading Lvl 3
> *** Another Heading Lvl 2 (missing)*
> * Formulas
>
> *** New Ones (missing)*** LET **(missing)*
> *** LAMBDA
>
>  XMATCH (missing)*** XLOOKUP* *(missing)*
> * Dynamic Array Formulas
>
> Setting org-fold-core-style to overlays doesn't change the outcome.
>
> On Wed, Feb 15, 2023 at 4:30 PM Ihor Radchenko 
> wrote:
>
>> Daniel Hubmann  writes:
>>
>> > * Heading Lvl 1...** Heading Lvl 2 with VISIBILITY content...
>> > *** Heading Lvl 3...
>>
>> Thanks for reporting!
>> Fixed, on bugfix.
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=be9280f68
>>
>> --
>> Ihor Radchenko // yantar92,
>> Org mode contributor,
>> Learn more about Org mode at <https://orgmode.org/>.
>> Support Org development at <https://liberapay.com/org-mode>,
>> or support my work at <https://liberapay.com/yantar92>
>>
>

Re: [BUG] Incorrect display of folded headings after cycling with subheading with VISIBILITY content/children

[Daniel Hubmann]

Thanks for the partial fix.

Unfortunately there is still something strange going on as the last heading
gets hidden. Added some more headings to demonstrate this better:

This is the unfolded file content:

* Heading Lvl 1
** Heading Lvl 2 with VISIBILITY content
:PROPERTIES:
:VISIBILITY: content
:END:
*** Heading Lvl 3
** Another Heading Lvl 2
* Formulas
** New Ones
*** LET
*** LAMBDA
:PROPERTIES:
:VISIBILITY: content
:END:
*** XMATCH
*** XLOOKUP
* Dynamic Array Formulas

After using org-cycle-content followed by
org-cycle-set-visibility-according-to-property I get this:

* Heading Lvl 1
** Heading Lvl 2 with VISIBILITY content...
*** Heading Lvl 3...
* Formulas
*** LAMBDA
* Dynamic Array Formulas

Whereas the expected output should look as follows:

* Heading Lvl 1
** Heading Lvl 2 with VISIBILITY content
*** Heading Lvl 3
*** Another Heading Lvl 2 (missing)*
* Formulas

*** New Ones (missing)*** LET **(missing)*
*** LAMBDA

 XMATCH (missing)*** XLOOKUP* *(missing)*
* Dynamic Array Formulas

Setting org-fold-core-style to overlays doesn't change the outcome.

On Wed, Feb 15, 2023 at 4:30 PM Ihor Radchenko  wrote:

> Daniel Hubmann  writes:
>
> > * Heading Lvl 1...** Heading Lvl 2 with VISIBILITY content...
> > *** Heading Lvl 3...
>
> Thanks for reporting!
> Fixed, on bugfix.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=be9280f68
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>

Re: [BUG] Incorrect display of folded headings after cycling with subheading with VISIBILITY content/children

[Daniel Hubmann]

Tried (setq org-fold-core-style 'overlays) which is mentioned in the link.
Unfortunately the behaviour is still the same.

On Tue, Feb 14, 2023 at 10:15 PM William Denton  wrote:

> On 14 February 2023, Bruno Barbier wrote:
>
> > Daniel Hubmann  writes:
> >
> >> After using org-cycle-overview (or org-cycle-content) and then using
> >> org-cycle-set-visibility-according-to-property I get this:
> >>
> >> * Heading Lvl 1...** Heading Lvl 2 with VISIBILITY content...
> >> *** Heading Lvl 3...
> >
> > I'm observing the same behavior.
>
> Similar things have been happening to me since the middle of last year.
>
> See:
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2022-07/msg00368.html
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2022-05/msg00811.html
> (my screenshots are gone by they looked like what's been described)
>
> Ihor did some work but the problem is still going on now and then, in the
> sort
> of way that seems unreproducible to me.
>
>
> Bill
>
> --
> William Denton
> https://www.miskatonic.org/
> Librarian, artist and licensed private investigator.
> Toronto, Canada
> CO₂: 421.18 ppm (Mauna Loa Observatory, 2023-02-13)

[BUG] Incorrect display of folded headings after cycling with subheading with VISIBILITY content/children

[Daniel Hubmann]

Org mode version 9.6 (9.6-g30314c @
/home/hubisan/.emacs.default/straight/build/org/)
GNU Emacs 29.0.60 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33,
cairo version 1.16.0) of 2023-01-03

Have the following org file contents (using emacs -q):

* Heading Lvl 1
** Heading Lvl 2 with VISIBILITY content
:PROPERTIES:
:VISIBILITY: content
:END:
*** Heading Lvl 3
** Another Heading Lvl 2

After using org-cycle-overview (or org-cycle-content) and then using
org-cycle-set-visibility-according-to-property I get this:

* Heading Lvl 1...** Heading Lvl 2 with VISIBILITY content...
*** Heading Lvl 3...

If I use :VISIBILITY: children I get this ("Another Heading Lvl 2" is
hidden):

* Heading Lvl 1
** Heading Lvl 2 with VISIBILITY content
:PROPERTIES:
:VISIBILITY: content
:END:
*** Heading Lvl 3...

Tried to debug it, but didn't find the cause. Happens after exiting
save-restriction.

Best wishes
Daniel

Re: [External] : [RFC] If you use Org 9.6, please share the output of M-x org-element-cache-hash-show-statistics

[Daniel Ortmann]

11.99% of cache searches hashed, 12.16% non-hashable.

13 hours, 20 minutes, 43 seconds

On 2/9/23 05:51, Ihor Radchenko wrote:

Hi,

I would like to assess the efficiency of one of search optimizations used
in org-element.el [1]

The statistics about efficiency is collected by Org, but obviously not
shared without your consent.

If you are ok with sharing the statistics, and you are running Emacs
session for at least few hours (using Org mode, obviously), please reply
sharing the output of
  M-x org-element-cache-hash-show-statistics 
  M-x emacs-uptime 

[1] Pugh [Information Processing Letters] (1990) Slow optimally balanced
  search strategies vs. cached fast uniformly balanced search strategies.
  
https://urldefense.com/v3/__http://dx.doi.org/10.1016/0020-0190(90)90130-P__;!!ACWV5N9M2RV99hQ!JwEvxu0CggVEXgYmfXdxPXq0nYdBMMbQ3NzQ6pTShxTfCLwft_6uaHlG2rbztwtljiKyvCyPZJDkkaaGDGJo$

Re: [POLL] Use compat.el in Org? (was: Useful package? Compat.el)

[Daniel Mendler]

On 1/30/23 20:40, Greg Minshall wrote:
> i see, yes.  i'm just thinking that, for a given release CUR (like i
> know anything about org-mode release procedures!)  we would use whatever
> has been available in compat.el since release CUR-n (for whatever n we
> use -- 2?), and supplement that, in org-compat.el, with whatever other
> compatibility features *we* (org-mode) need to support releases [CUR-n
> .. CUR].
> 
> (and, presumably, contribute whatever might be appropriate from
> org-compat.el to compat.el, so we can prune it out from org-compat.el at
> some future point in time.)

Sounds good. But note that Compat will at some point have sufficient
coverage of the existing APIs, such that Org may not miss anything. From
then on new additions will only be made at the time of a new Emacs
release. The current Compat already supports many Emacs 29 APIs, which
is in time for the upcoming pretest. Compat won't add any APIs which are
still part of the unstable development master branch (before the branch
cut and feature freeze), which reduces the need for coordination.

If you are missing something right now, and want to introduce and use a
new backported function, e.g., something new from Emacs 29, instead of
going via the org-compat indirection, you could also make an addition
directly to Compat, a Compat release can be prepared a short while
after, and then you start using the new function in the Org development
version.

Daniel

Re: [BUG] ob-sql sql-connection-alist

[Daniel Kraus]

Hi!

Andreas Gerler  writes:

> I added the missing changelog entry.

Thanks.
I installed the patch.

(I'll also answer to your dbconnection engine mail soon.
Just very busy atm)

Thanks,
  Daniel

Re: [POLL] Use compat.el in Org?

[Daniel Mendler]

On 1/27/23 21:38, Tim Cross wrote:
>> As long as we keep our promise in terms of backward compatibility with
>> older Emacs versions, I'm all for it.
> 
> I would agree. I would also add that even with the use of this package,
> I don't think we should use it to increase the number of versions we
> support as support is not as simple as dropping in a compatibility
> library. 

True. The Compat package cannot fix bugs below the Elisp level or
provide APIs which cannot be backported, e.g., big integer support. If
Org relies on behavior of the Emacs display engine or the C core of a
certain Emacs version, Compat cannot help.

The advantage would be that the maintenance burden of org-compat would
be reduced. Many packages can share the backported functions by
depending on Compat, which will increase robustness and reduce the risk
of unexpected bugs. The community only has to maintain a single set of
backported functions in a single package, instead of scattering
compatibility code across many packages.

> These libraries come with a cost. Often, compatibility code
> does not perform as well and/or is much more complicated and more likely
> to have bugs. The more a version of emacs needs to rely on this library
> to run org-mode, the higher the likelihood performance will be degraded
> or unexpected new bugs are found.

To give some context about the stability aspect - many backported
compatibility functions are copied verbatim from newer Emacs versions.
Every compatibility function provided by Compat is covered by tests,
which are executed via CI on all supported Emacs versions (>= 24.4). I
make sure that no functions are backported which perform much worse such
that they would introduce performance bugs.

Daniel

Re: [BUG] ob-sql sql-connection-alist

[Daniel Kraus]

Thanks.

@Ihor, since this is the first patch I install from another contributor,
is there anything I should look out for?

E.g. does this need a TINYCHANGE entry or something?
Or do you have already copyright assignments filled out, Andreas and
then it's not necessary?
Can I see somewhere who I need to ask for copyright assignments or not?

Thanks,
  Daniel

Re: Question about deadline/schedule events date text property

[Daniel Fleischer]

Ihor Radchenko [2023-01-18 Wed 13:23]  wrote:

> Note that `org-fix-agenda-info' converts the 'date property back to some
> other format... (yes, that's kind of crazy)

Thanks, that could be useful. 

--
Daniel Fleischer

Re: [PATCH] ob-sql: Add support for Athena

[Daniel Kraus]

Tim Cross  writes:

> I think you run a high risk of running into GNU policy issues wrt
> licensing and free software support given this is a cleint for an AWS
> only database.

Is it because it's cloud only or because it's proprietary?
Because we already support Orcale, SAP Hana, MSSql and Vertico for example.

Cheers,
  Daniel

Re: org-todo-keywords and task sequence

[Daniel Fleischer]

Daniel Fleischer [2023-01-17 Tue 10:10] wrote:

> Don't let the cyclical switching dictates the meaning, it's just an
> implementation detail, done for simplicity. Hope it helped.

Put another way, if you define A B | C D E

and the UI switching is A->B->C->D->E->A

it doesn't mean the B going into C makes sense or D going into E makes
sense, it's just how the UI is built. You give meaning to the states and
what states transitions are valid (in your world). Like many things, org
gives some structure to work with and we need to give the meaning.

-- 
Daniel Fleischer

Re: org-todo-keywords and task sequence

[Daniel Fleischer]

David Masterson  writes:

> I'm not sure I understand 'sequence' and 'type' in org-todo-keywords.

You're over thinking it. You can define various todo keywords and they
are divided into two groups that can be thought of as "ones that need
your attention" and "ones that don't need your attention" and they are
separated by a literal "|". Example: todo, in progress, on hold,
waiting, phonecall etc are of the 1st type. Done, canceled, postponed are of the
2nd type. In terms of "moving" between them, it's either cyclical or you
can jump to a specific word using shortcuts you define e.g.

#+TODO: TODO(t) | DONE(d)

Don't let the cyclical switching dictates the meaning, it's just an
implementation detail, done for simplicity. Hope it helped.

-- 
Daniel Fleischer

Re: [PATCH] ob-sql: Add support for Athena

[Daniel Kraus]

Ihor Radchenko  writes:

> Daniel Kraus  writes:
>
>> I'm using this patch since a few month that adds support
>> for AWS Athena.
>> The only thing that's maybe against adding it is that
>> `athenacli` (https://github.com/dbcli/athenacli) is not an
>> official AWS tool but just a Python script.
>>
>> What's the opinion on this?
>
> Is this something commonly used?

Athena itself is very widely used. But everyone uses either the
AWS Webinterface or connect with JDBC (DBeaver/Datagrip etc) to it.
The Python tool doesn't seem so popular (only 200 GitHub stars),
that's also my main reason for not adding it.


> I see two main issues with the idea:
> 1. I do not like the idea of adding all the possible CLI tools over
>there in ad-hoc manner. It would be cleaner to provide a
>customization to add various cli tools in a defcustom/defvar without
>manually changing the functions.
>
> 2. I feel like it will be hard to maintain such unpopular clients. If
>(1) is addressed + good automatic tests are implemented, things may
>be acceptable for inclusion though.
>
> In summary, I am not against the idea of including a new sql cli, but we
> should better provide a centralized API to do so and make sure that we
> have test coverage, making sure that things are not broken in future,
> when the original committer is gone and nobody else is left familiar
> with specific obscure SQL client.

Completely agree.
If I look in `org-babel-execute:sql` `command`
( https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/ob-sql.el#n256 
)
I think it would make sense to somehow make all those commands
customizeable and let users add their own commands.
But that's obviously a bit more work. I'll see if I find time for it
in the coming months.

Thanks,
  Daniel

[PATCH] ob-sql: Add support for Athena

[Daniel Kraus]

Hi,

I'm using this patch since a few month that adds support
for AWS Athena.
The only thing that's maybe against adding it is that
`athenacli` (https://github.com/dbcli/athenacli) is not an
official AWS tool but just a Python script.

What's the opinion on this?

Cheers,
  Daniel
>From ddace051205d20b24c047962ca9d1335bdd90284 Mon Sep 17 00:00:00 2001
From: Daniel Kraus 
Date: Mon, 16 Jan 2023 11:35:02 +0100
Subject: [PATCH] lisp/ob-sql.el: Add support for Athena

* lisp/ob-sql.el (org-babel-execute:sql): Add support for Athena
---
 lisp/ob-sql.el | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/lisp/ob-sql.el b/lisp/ob-sql.el
index 39a4573a5..640ecb2c0 100644
--- a/lisp/ob-sql.el
+++ b/lisp/ob-sql.el
@@ -53,14 +53,15 @@
 ;; - rowname-names
 ;;
 ;; Engines supported:
-;; - mysql
+;; - athena
 ;; - dbi
 ;; - mssql
-;; - sqsh
-;; - postgresql (postgres)
+;; - mysql
 ;; - oracle
-;; - vertica
+;; - postgresql (postgres)
 ;; - saphana
+;; - sqsh
+;; - vertica
 ;;
 ;; TODO:
 ;;
@@ -254,6 +255,11 @@ This function is called by `org-babel-execute-src-block'."
(org-babel-temp-file "sql-out-")))
 	 (header-delim "")
  (command (cl-case (intern engine)
+(athena (format "athenacli %s -e %s %s > %s"
+			(or cmdline "")
+			(org-babel-process-file-name in-file)
+database
+			(org-babel-process-file-name out-file)))
 (dbi (format "dbish --batch %s < %s | sed '%s' > %s"
  (or cmdline "")
  (org-babel-process-file-name in-file)
@@ -352,7 +358,7 @@ SET COLSEP '|'
 	(progn (insert-file-contents-literally out-file) (buffer-string)))
   (with-temp-buffer
 	(cond
-	 ((memq (intern engine) '(dbi mysql postgresql postgres saphana sqsh vertica))
+	 ((memq (intern engine) '(athena dbi mysql postgresql postgres saphana sqsh vertica))
 	  ;; Add header row delimiter after column-names header in first line
 	  (cond
 	   (colnames-p
@@ -377,7 +383,7 @@ SET COLSEP '|'
 	  (goto-char (point-max))
 	  (forward-char -1))
 	(write-file out-file
-	(org-table-import out-file (if (string= engine "sqsh") '(4) '(16)))
+	(org-table-import out-file (if (memq (intern engine) '(athena sqsh)) '(4) '(16)))
 	(org-babel-reassemble-table
 	 (mapcar (lambda (x)
 		   (if (string= (car x) header-delim)
-- 
2.39.0

Re: [BUG] ob-sql sql-connection-alist

[Daniel Kraus]

Ihor Radchenko  writes:

> Andreas Gerler  writes:

>> (setq sql-connection-alist
>>   '((testdb (sql-product 'mysql)
>> (sql-server "127.0.0.1")
>> (sql-user "mysql”)
>> (sql-port 3306)
>> (sql-password “foo")
>> (sql-database "mysql"
>
> I am looking at the docstring of `sql-connection-alist':
>
> An alist of connection parameters for interacting with a SQL product.
>  Each element of the alist is as follows:
>
>(CONNECTION \(SQL-VARIABLE VALUE) ...)
>
>  Where CONNECTION is a case-insensitive string identifying the
>  connection, ...
>
> So, your "setq" example is incorrect: must use "testdb" instead of
> `testdb' symbol.

I'm not sure why but I also have the connection as a symbol in my
`sql-connection-alist`.
Looking in `sql.el` `(sql-connect)`, they also use
`assoc-string` to receive the connection:
https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/progmodes/sql.el?h=ac2a6fc83fac6390892b068a830ebe0f22364e05#n4398

So I think that change is good and supports both formats
(same as `sql-connect`).

Cheers,
  Daniel

Re: [BUG] ob-sql sql-connection-alist

[Daniel Kraus]

Hi!

Andreas Gerler  writes:

> Last week I heard about using ob-sql with credentials stored in the variable 
> used by isql.
> However I had to modify ob-sql to get it actually working.
> Can somebody test the pach before I send in a commit?
>
> #+begin_src sql :engine mysql :dbconnection testdb
> show tables;
> #+end_src

I actually use this feature daily.
You have to quote the dbconnection. So this works currently:

> #+begin_src sql :engine mysql :dbconnection 'testdb

but I would agree that not needing the quote makes sense.
And since `assoc-string` works with symbol and string (i.e. it's backwards 
compatible)
I would install the patch if you send it.

> I was considering writing another patch to map the sql-product to engine.
> That way we could get rid of another parameter in the src block.
> Opinions?

I agree. Specifying :engine when it's already in the connection-alist is 
unnecessary.

Thanks,
  Daniel

Question about deadline/schedule events date text property

[Daniel Fleischer]

Hi, I'm working on an unrelated project that collects events from agenda
buffers. I noticed the following: when you have a series of a repeating
events, scheduled events have a date text property of the form
(1 9 2023) date matches the instance date

while deadline events have
738529 which repeats for all instances

Is this intentional? Why don't they have the same format/behavior? 

The setup - events have the form:

* TODO Test
SCHEDULED: <2023-01-09 Mon +1w>

or

* TODO Test
DEADLINE: <2023-01-09 Mon +1w>

Open an org agenda for a month and examine the text properties of the
events.

-- 
Daniel Fleischer

Re: [BUG] issue with texmathp [9.6 (release_9.6-22-g78d283 @ /home/jds6696/.emacs.d/straight/build/org-mode/)]

[Daniel Fleischer]

Ihor Radchenko  writes:

> Can you try to test the attached patch?

Looks good. Now these work again: `cdlatex-dollar`, inserting symbols
using ` outside math environments and inserting cdlatex environments
with completion also outside math environments. Need to make sure the
issue of the OP didn't regress.

BTW, I haven't follow any discussions about org syntax and math
environments inside org (the use of \...[\] instead $...$ etc.) These
usecases I mentioned are what I'm used to and perhaps they are not
consistent with changes made to the org syntax, demanding every math
should be inside a math environment for easier parsing and you still
managed to solve that without all the previous regexps.

Thank you,

-- 
Daniel Fleischer

Re: [BUG] issue with texmathp [9.6 (release_9.6-22-g78d283 @ /home/jds6696/.emacs.d/straight/build/org-mode/)]

[Daniel Fleischer]

I just found this thread after math-related things stopped working. I
have two use cases that don't work now:

1. Inserting a dollar pair $$ using `cdlatex-dollar` (it thinks we're
inside a math environment).

2. Inserting of cdlatex environments using their built-in completions, e.g.
ali
eqn
   stopped working.

Previously org-cdlatex worked perfectly, you could insert \alpha using
`a and it compiled to HTML/latex (without $$), have $...$ compiled into
an inline equation and insert latex environment like
\begin{align}...\end{align} without explicit math environment and was
also compiled perfectly to HTML/latex.

-- 
Daniel Fleischer

Re: Intention of verbatim text?

[Daniel Fleischer]

c.bu...@posteo.jp [2023-01-03 Tue 13:20] wrote:

> in org you can have inline verbatim and code text elements like this.
>
> Example with =verbatim= and ~code~.
>
> The org html export to create both with  tag. So in HTML output
> there is no difference between verbatim and code anymore.
>
> I also read a lot about the HTML tags code, pre, kbd and samp.
>
> The background of my question is that I have my own
> org-to-html-converter [1] and try to decide how to treat =verbatim=.

According to https://stackoverflow.com/questions/32284477 they have
different semantics but are rendered the same (by default); they could
be rendered differently, depending on a website's CSS. Maybe use the
semantics for your own org-html converter.

-- 
Daniel Fleischer

Re: Radio links work only in small numbers

[Daniel Clemente]

Hi,
I also found this limitation, and my solution was to disable radio links
and to replace them by a manual approach:

1. I disabled the call to (org-update-radio-target-regexp) in org.el. Well,
I added a boolean org-inhibit-startup-radio-refresh, that works in a
similar way to org-inhibit-startup-visibility-stuff. After this change, I
still type <<>> to define a title, but org doesn't handle it anymore

2. I created a helm  menu, that offers
me all the radio links. I compute the list of radio links myself, through
grep, by looking for <<<. It's easier than it seems, and very fast. The
code (no explanations) is my configuration
, in these functions:
anythingyhelm-fuente-etiquetas-radio-org,
precarga-etiquetas-radio-de-wiki-para-helm

3. Often, when I want to refer to a title, I write in in cursive, /like
this/. That's my way of telling myself „that's a link, you can manually
search for it through helm“. The target will be tagged <<>>. I
could automate this link-following but I don't mind typing for 1 or 2
seconds to go a header. I still use normal links (C-c C-l, :ID: etc.) if I
want something that is easier to follow.

My system doesn't provide the same features as org's radio links, but I get
an interactive menu with pattern matching and very fast access to all
headers. I would still prefer the real radio links, with no limitations.
However, I understand that org-mode's approach is computationally harder.
Whereas I'm looking for ONE target link through all my 100 files, org-mode
is doing a regexp that looks for ALL target links in the current file. And
I have around 20k radio links!. Grepping for 20k things everywhere is
harder than grepping for 1 thing everywhere. Even GNU grep is slow (>25
seconds) if I use a long regular expression
 with
20k things inside.

In other words: since radio links don't scale well, I have replaced the
real radio links (search for everything everywhere) with a directed
approach (search for 1 thing everywhere).


On Tue, 13 Dec 2022 at 23:11, Rudolf Adamkovič  wrote:

> Greetings smart people!
>
> All [[link]]s in my notes perfectly match LEVEL-1 headings, so I figured
> that I may as well ask Org to make links for me.  So, I replaced all the
> ~4000 headings in my notes with radio <<>>.  However, Org now
> errors out with "Regular expression too big".
>
> Does anyone know how to overcome this limitation?  Or, perhaps someone
> has a patch in works that fixes it?  If so, please let me know!
>
> Thank you.
>
> 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
>
>

Bug? Error in HTML export of links with search options

[Daniel Fleischer]

Org offers the ability to run a search inside a link, see (org) Search
Options. E.g. [[File.c::100]] to get to line 100 in File.c. When
exporting this to HTML I get the following error:

org-export-data: Unable to resolve link: "‘recenter’ing a window that does 
not display current-buffer."

Also when having links of the form [[File.clj::defn]] where `defn' is a
search string.

Main 04d2cc59.

-- 
Daniel Fleischer

Re: [BUG] Shift-up/down move the cursor to end of timestamp

[Daniel Clemente]

It works now, thanks!

On Wed, 7 Dec 2022 at 10:53, Ihor Radchenko  wrote:

> Daniel Clemente  writes:
>
> > Using a file with just one header:
> >
> > * something
> >   :CLOCK:
> >   CLOCK: [2022-12-01 Thu 17:15]--[2022-12-01 Thu 17:30] =>  0:15
> >   :END:
> >
> > If I put the cursor on the end timestamp (on the 3 of 17:30) and press
> > shift+up or shift-down, the timestamp is correctly adjusted by 5 minutes,
> > but the cursor jumps some characters to the right and stays at the right
> of
> > ]
> > It should stay on the same character (the 3), so that I can keep
> adjusting
> > the minutes with shift-up/down
>
> Thanks for reporting!
> Fixed on bugfix.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4dddbc143
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>

[BUG] Not all time/date strings are recognized as time in org-make-tags-matcher [9.6 (9.6-gd500b4 @ /home/hubisan/.emacs.default/straight/build/org/)]

[Daniel Hubmann]

After updating to Org 9.6 this match in the agenda
'SCHEDULED<"<+2d>"+SCHEDULED<>"' shows all scheduled items event if they
are far more in the future than 2 days.

Tracked this down to a commit (e022a0cea11a0e784ba20ac478a033da7fb1bb7f)
that changed the regular expression to recognize timestamps:

-(timep (string-match-p "^\"[[<].*[]>]\"$" pv))
> +(timep (string-match-p "^\"[[<][0-9]+.*[]>]\"$" pv))
>

If I understand it correctly, this new regular expression only matches
strings that start with < and a number. So strings like ,
, <+2d> and so on are not working anymore.

If I change the expression to the one before and evaluate the function, the
match works again.

A big thank you to all the developers behind org-mode!

Best wishes.
Daniel Hubmann

Emacs  : GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
 of 2022-07-18
Package: Org mode version 9.6 (9.6-gd500b4 @
/home/hubisan/.emacs.default/straight/build/org/)

Re: [External] : Re: Clocking in is pretty slow in version 9.6 when the item has a large

[Daniel Ortmann]

Eli,
I also had performance issues after the logbook was switched to true 
parsing instead of regular expressions.  In my case, I had logbook 
entries going back to 2012!


After I cleared out the excess entries the performance jumped back up.

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

On 12/4/22 11:41, Ihor Radchenko wrote:

Eli Qian  writes:


Any idea about speeding up clocking in?

Try reducing `org-element--cache-self-verify-frequency' to a smaller
number.

--- Begin Message ---
Works perfectly after cleaning out old time log entries going back to 
2013.  :-)


On 10/20/22 00:37, Ihor Radchenko wrote:

Daniel Ortmann  writes:


(The performance drop was sudden and steep, by the way.)

It is because clocking now calls Org parser API.
https://urldefense.com/v3/__https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3790bf8ea1d070055a989f0b9587948e07877977__;!!ACWV5N9M2RV99hQ!KgwLbNpmmeNRH40ZJBT24H5ehmytyzRmS_wXhRSXlz7b-jzilorwtWKuAF0iQwTkP4UT779uIe4jNXhYh7W-$



--- End Message ---

[BUG] Shift-up/down move the cursor to end of timestamp

[Daniel Clemente]

Hi.

Using a file with just one header:

* something
  :CLOCK:
  CLOCK: [2022-12-01 Thu 17:15]--[2022-12-01 Thu 17:30] =>  0:15
  :END:

If I put the cursor on the end timestamp (on the 3 of 17:30) and press
shift+up or shift-down, the timestamp is correctly adjusted by 5 minutes,
but the cursor jumps some characters to the right and stays at the right of
]
It should stay on the same character (the 3), so that I can keep adjusting
the minutes with shift-up/down

Tested on: GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit,
cairo version 1.16.0, Xaw scroll bars) of 2022-11-18
No other settings needed in your .emacs

I bisected the tree until I found in which commit this started. Copying
from git bisect:

5bc6741a5abd42e8305bb0fcfe78801813309640 is the first bad commit
commit 5bc6741a5abd42e8305bb0fcfe78801813309640
Author: Ihor Radchenko 
Date:   Tue Nov 1 15:52:25 2022 +0800

org-clock-update-time-maybe: Update the containing timestamps as well

* lisp/org-clock.el (org-clock-update-time-maybe): Update the
containing timestamps inside the clock, not only the clock sum.

Reported-by: Bruce E. Robertson 
Link: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53393

 lisp/org-clock.el | 35 ---
 1 file changed, 24 insertions(+), 11 deletions(-)

Re: [PATCH] Add new :results ignore header argument (was: [External] : Re: [BUG] executing sh source block with ':results none' encounters error region is longer than org-table-convert-region-max-line

[Daniel Ortmann]

Works great!

On 11/22/22 00:02, Daniel Ortmann wrote:

No objections.

On 11/21/22 20:12, Ihor Radchenko wrote:

Daniel Ortmann  writes:


I am happy with whatever you decide. :-)

Then, here is a tentative patch introducing new :results ignore header
argument.

Any objections?

Re: [PATCH] Add new :results ignore header argument (was: [External] : Re: [BUG] executing sh source block with ':results none' encounters error region is longer than org-table-convert-region-max-line

[Daniel Ortmann]

No objections.

On 11/21/22 20:12, Ihor Radchenko wrote:

Daniel Ortmann  writes:


I am happy with whatever you decide.  :-)

Then, here is a tentative patch introducing new :results ignore header
argument.

Any objections?

Re: [External] : Re: [BUG] executing sh source block with ':results none' encounters error region is longer than org-table-convert-region-max-lines [9.6-pre (release_9.5.5-1118-g70cee1 @ /home/dortman

[Daniel Ortmann]

I am happy with whatever you decide.  :-)

On 11/20/22 20:34, Ihor Radchenko wrote:

Daniel Ortmann  writes:


Please see attached which has the following code which reproduces the issue:

#+begin_src sh :shebang #!/bin/bash :results none
for (( i=1500 ; i>0 ; i-=1 ))
do
      head -c 6 /dev/urandom | uuencode -m -
done |
tee /dev/null
#+end_src

Thanks!

I was able to reproduce. However, this particular error appears to be
intentional.

`org-table-convert-region-max-lines' has been introduced explicitly for
such scenarios because table conversion may take significant time when
the output is large.

I think we can do 2 things to address the problem:

1. Tweak the error wording. Probably to something like
Babel result processing: Region is longer than 
`org-table-convert-region-max-lines' (%s) lines; not converting

2. Maybe introduce something like :results ignore to discard the results
completely.

Re: [External] : Re: [BUG] executing sh source block with ':results none' encounters error region is longer than org-table-convert-region-max-lines [9.6-pre (release_9.5.5-1118-g70cee1 @ /home/dortman

[Daniel Ortmann]

Please see attached which has the following code which reproduces the issue:

#+begin_src sh :shebang #!/bin/bash :results none
for (( i=1500 ; i>0 ; i-=1 ))
do
    head -c 6 /dev/urandom | uuencode -m -
done |
tee /dev/null
#+end_src


On 11/18/22 02:45, Ihor Radchenko wrote:

Daniel Ortmann  writes:


I have several small sh source blocks with ':results none'. The source
is executed for effect and the last line of the source is:
... | tee /target/path/to/file.csv

⛔ Error (org-babel): Error reading results: (user-error "Region is
longer than ‘org-table-convert-region-max-lines’ (999) lines; not
converting")

I expected that :results none would simply drop the output rather than
complaining about it.

Even though it says "error", the results seem to be correct.

This is because blocks with :results none may still be used as input for
other source blocks as reference or noweb reference. So, the results are
computed, but not inserted or otherwise indicated.

Could you please provide a reproducer so that we fix the issue with
table conversion?



reproduce.org
Description: Lotus Organizer

[BUG] executing sh source block with ':results none' encounters error region is longer than org-table-convert-region-max-lines [9.6-pre (release_9.5.5-1118-g70cee1 @ /home/dortmann/src/git-org-mode/li

[Daniel Ortmann]

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.


I have several small sh source blocks with ':results none'. The source
is executed for effect and the last line of the source is:
... | tee /target/path/to/file.csv

⛔ Error (org-babel): Error reading results: (user-error "Region is 
longer than ‘org-table-convert-region-max-lines’ (999) lines; not 
converting")


I expected that :results none would simply drop the output rather than
complaining about it.

Even though it says "error", the results seem to be correct.

Emacs : GNU Emacs 29.0.50 (build 8, x86_64-pc-linux-gnu, GTK+ Version 
3.22.30, cairo version 1.15.12)

of 2022-11-17
Package: Org mode version 9.6-pre (release_9.5.5-1118-g70cee1 @ 
/home/dortmann/src/git-org-mode/lisp/)

[PATCH] lisp/ob-tangle.el, lisp/ob-core.el: Add strip-tangle

[Daniel Ziltener]

* lisp/ob-tangle.el (org-babel-tangle-single-block): strip noweb tags
from block if :noweb has been set to strip-tangle.
* lisp/ob-core.el (org-babel-common-header-args-w-values): add
"strip-tangle" as new allowed value.
* lisp/ob-core.el (org-babel-noweb-p): add "strip-tangle" at the
appropriate positions.
* testing/lisp/test-ob-tangle.el (ob-tangle/strip-tangle): add new test
case for "strip-tangle".
* doc/org-manual.org (Noweb Reference Syntax): adjust documentation for
the noweb header argument.
* etc/ORG-NEWS: add entry for new header argument value.

This patch adds the "strip-tangle" option for the :noweb header
argument.  This strips the noweb tags before tangling the block.  This can
be useful for e.g. testing purposes where one wants to use a block as
test case that can be both run inline as well as tangled into a file for
automated testing.
---
 doc/org-manual.org |  6 ++
 etc/ORG-NEWS   |  5 +
 lisp/ob-core.el|  8 
 lisp/ob-tangle.el  |  4 +++-
 testing/lisp/test-ob-tangle.el | 26 ++
 5 files changed, 44 insertions(+), 5 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index b3071ec6d..90fd950dc 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -18998,6 +18998,12 @@ tangled, or exported.
   Expansion of noweb syntax references in the body of the code block
   when tangling.  No expansion when evaluating or exporting.
 
+- =strip-tangle= ::
+
+  Expansion of noweb syntax references in the body of the code block
+  when evaluating or exporting.  Removes noweb syntax references
+  when exporting.
+
 - =no-export= ::
 
   Expansion of noweb syntax references in the body of the code block
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index b542da34b..ca1944614 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -228,6 +228,11 @@ commands.
 =:noweb-prefix= can be set to =no= to prevent the prefix characters
 from being repeated when expanding a multiline noweb reference.
 
+*** New =:noweb= babel header argument value =strip-tangle=
+
+=:noweb= can be set to =strip-tangle= to strip the noweb syntax references
+before tangling.
+
 *** New LaTeX source block backend using =engraved-faces-latex=
 
 When ~org-latex-src-block-backend~ is set to ~engraved~,
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index a1c11e6ca..22d60cfe6 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -415,7 +415,7 @@ then run `org-babel-switch-to-session'."
 (mkdirp. ((yes no)))
 (no-expand)
 (noeval)
-(noweb . ((yes no tangle no-export strip-export)))
+(noweb . ((yes no tangle strip-tangle no-export strip-export)))
 (noweb-ref . :any)
 (noweb-sep  . :any)
 (noweb-prefix . ((no yes)))
@@ -2885,9 +2885,9 @@ parameters when merging lists."
   "Check if PARAMS require expansion in CONTEXT.
 CONTEXT may be one of :tangle, :export or :eval."
   (let ((allowed-values (cl-case context
- (:tangle '("yes" "tangle" "no-export" "strip-export"))
- (:eval   '("yes" "no-export" "strip-export" "eval"))
- (:export '("yes")
+ (:tangle '("yes" "tangle" "no-export" "strip-export" 
"strip-tangle"))
+ (:eval   '("yes" "no-export" "strip-export" "eval" 
"strip-tangle"))
+ (:export '("yes" "strip-tangle")
 (cl-some (lambda (v) (member v allowed-values))
 (split-string (or (cdr (assq :noweb params)) "")
 
diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 2da92efaf..ad027ccd0 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -536,7 +536,9 @@ non-nil, return the full association list to be used by
 (body
  ;; Run the tangle-body-hook.
   (let ((body (if (org-babel-noweb-p params :tangle)
- (org-babel-expand-noweb-references info)
+  (if (string= "strip-tangle" (cdr (assq :noweb (nth 2 
info
+(replace-regexp-in-string (org-babel-noweb-wrap) 
"" (nth 1 info))
+   (org-babel-expand-noweb-references info))
(nth 1 info
(with-temp-buffer
  (insert
diff --git a/testing/lisp/test-ob-tangle.el b/testing/lisp/test-ob-tangle.el
index a0003ee40..2a6e4b1dd 100644
--- a/testing/lisp/test-ob-tangle.el
+++ b/testing/lisp/test-ob-tangle.el
@@ -510,6 +510,32 @@ another block
(org-split-string (buffer-string
  (delete-file file))
 
+(ert-deftest ob-tangle/strip-tangle ()
+  "Test if strip-tangle works correctly when tangling noweb code blocks."
+  (should
+   (equal '("1")
+  (let ((file (make-temp-file "org-tangle-")))
+(unwind-protect
+(progn
+  (org-test-with-temp-text-in-file
+   (format "
+#+name: block1
+#+begin_src elisp
+2
+#+end_src
+

Re: [PATCH] ob-sql: Respect database param when using dbconnection

[Daniel Kraus]

Ihor Radchenko  writes:

>> Otherwise, the patch itself is not much and I use it daily.
>
> Thanks!
> Applied onto main with minor amendments to the commit message (I added
> "." at the end of the sentences).
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=fbbc8b55cf3a39c85f8576321ec560baf4d2331a

Thanks.


> P.S. ob-sql currently have no maintainer. Do you want to volunteer?

Hmm, ob-sql is the the babel module I use most often.
I don't think I'll have enough time to make bigger changes etc,
but from what I know that's not necessary or expected.
I'm certainly willing to look at patches, answer bug reports
and join discussion about ob-sql.

tl;dr you can add me as a maintainer ;)

Cheers,
  Daniel

Re: [External] : RE: org-assert-version considered harmful

[Daniel Ortmann]

Malcolm,
I also ran into troubles which are similar, apparently due to mixed 
org-mode versions; we've got to load org-mode before emacs tries to do 
it for us or we get mixed stuff.


My resolution was to load the org-mode path first in my init.el file and 
then require org:


   (add-to-list 'load-path "/home/dortmann/src/git-org-mode/lisp")
   (require 'org)

And then I build with something like this:

   dortmann@ddo-linux:src$ cd ~/src/git-org-contrib/ && git pull && cd
   ~/src/git-org-mode/ && git pull && make all && make autoloads && cd
   ~/src/git-emacs-master/ && git pull && make all && sudo -H make
   install && cd ..


Then only an occasional 'make bootstrap' is required in the emacs build dir.




On 10/31/22 09:11, Cook, Malcolm wrote:


Hello,

I found this recent thread researching why my strategy for staying 
abreast with org head had started failing with invalid-function 
"org-assert-version"


My strategy had been to build org initially with

` cd ~/.emacs.d && git clone 
https://git.savannah.gnu.org/git/emacs/org-mode.git 
 
& org-mode && make autoloads && make`


and ensure this clone of org was picked up in my 
"~/.emacs.d/org-mode/lisp by including the following in my .init.el 
very early (right after bootstrapping the package system and use-package):


(use-package

:pin manual

:load-path "~/.emacs.d/org-mode/lisp"

)

Then, when I occasionally wished to update org, I would

`cd ~/.emacs.d/org-mode && git pull && make autoloads && make`

Recently I started getting errors invalid-function "org-assert-version".

Upon cursory reading of this thread I guessed that I could fix them by 
adding a `make clean` to my update mantra.


It worked.

Am I advised to do otherwise?Is there a best/better practice?

Thanks,

~Malcolm

Re: [PATCH] ob-sql: Respect database param when using dbconnection

[Daniel Kraus]

Hi,

sorry for replying to a 2 year old thread.
Attached is a new patch with the change from Kyle and
I also added a news entry.
Not sure if the text for the news entry is any good,
or if there should be an example etc.
Feedback welcome.

Otherwise, the patch itself is not much and I use it daily.

Thanks,
  Daniel

>From cd170dd691ba12ec81ef5c71db2868b33cd63ddf Mon Sep 17 00:00:00 2001
From: Daniel Kraus 
Date: Mon, 31 Oct 2022 07:52:09 +0100
Subject: [PATCH] ob-sql.el: Respect all params when using dbconnection

* etc/ORG-NEWS (Miscellaneous): Document change
* lisp/ob-sql.el (org-babel-find-db-connection-param): Make it
possible to overwrite parameters that are set from :dbconnection
---
 etc/ORG-NEWS   | 14 ++
 lisp/ob-sql.el | 24 
 2 files changed, 26 insertions(+), 12 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 6e875deb6..b542da34b 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -457,6 +457,20 @@ The new variable name is =org-plantuml-args=.  It now applies to both
 jar PlantUML file and executable.
 
 ** Miscellaneous
+*** SQL Babel ~:dbconnection~ parameter can be mixed with other SQL Babel parameters
+
+Before you could either specify SQL parameters like ~:dbhost~,
+~:dbuser~, ~:database~, etc or a ~:dbconnection~ parameter which looks
+up all other parameters from the ~sql-connection-alist~ variable.  Now
+it's possible to specify a ~:dbconnection~ and additionally other
+parameters that will add or overwrite the parameters coming from
+~sql-connection-alist~.
+
+E.g. if you have a connection in your ~sql-connection-alist~ to a
+server that has many databases, you don't need an entry for every
+database but instead can just specify ~:database~ next to your
+~:dbconnection~ parameter.
+
 *** Post-processing code blocks can return an empty list
 
 When the result of a regular code block is nil, then that was already
diff --git a/lisp/ob-sql.el b/lisp/ob-sql.el
index d1256bf83..626d595c9 100644
--- a/lisp/ob-sql.el
+++ b/lisp/ob-sql.el
@@ -222,18 +222,18 @@ then look for the parameter into the corresponding connection
 defined in `sql-connection-alist', otherwise look into PARAMS.
 See `sql-connection-alist' (part of SQL mode) for how to define
 database connections."
-  (if (assq :dbconnection params)
-  (let* ((dbconnection (cdr (assq :dbconnection params)))
- (name-mapping '((:dbhost . sql-server)
- (:dbport . sql-port)
- (:dbuser . sql-user)
- (:dbpassword . sql-password)
- (:dbinstance . sql-dbinstance)
- (:database . sql-database)))
- (mapped-name (cdr (assq name name-mapping
-(cadr (assq mapped-name
-(cdr (assoc dbconnection sql-connection-alist)
-(cdr (assq name params
+  (or (cdr (assq name params))
+  (and (assq :dbconnection params)
+   (let* ((dbconnection (cdr (assq :dbconnection params)))
+  (name-mapping '((:dbhost . sql-server)
+  (:dbport . sql-port)
+  (:dbuser . sql-user)
+  (:dbpassword . sql-password)
+  (:dbinstance . sql-dbinstance)
+  (:database . sql-database)))
+  (mapped-name (cdr (assq name name-mapping
+ (cadr (assq mapped-name
+ (cdr (assoc dbconnection sql-connection-alist
 
 (defun org-babel-execute:sql (body params)
   "Execute a block of Sql code with Babel.
-- 
2.38.1


Stefano Rodighiero  writes:

> On Mon, Jun 1, 2020 at 4:16 AM Kyle Meyer  wrote:
>
> Daniel Kraus writes:
>>
>> > I use ob-sql with the :dbconnection param so I don't have my username
>> and password in my org file.
>> > But often I don't want to use the default database from the dbconnection
>> alist but
>> > rather specify it explicitly with :database.
>> > Attached is a patch that fixes this.
>>
>
> Thank you @Daniel
>
>
>> […]
>> From what I can gather from your description, this looks reasonable.
>> I'm not an ob-sql user, so perhaps I missing something, but would it
>> make sense for any connection parameter to take precedence if explicitly
>> given in the source block header (i.e. something like the patch below)?
>> [+cc Stefano, who added the :dbconneciton feature.]
>>
>
> I think it makes sense.
>
> (I personally handle cases like those described by Daniel differently,
> keeping distinct sql-connection-alist entries for each DB
> param combination I might need, but I can imagine why someone
> would want to "override" the database or the host params.
> For port, user and password I have more difficulties imagining a
> case where combinations of those params would need override,
> but I think @Kyle's generic solution is better)
>
> s.

Re: Auto detect ob-clojure backend (was: [PATCH] Fix ob-clojure handling source block variable's value is a org-mode table or list)

[Daniel Kraus]

Tim Cross  writes:

> I think bb is a much better solution from a babel perspective and would
> love to see it as the default, even when you have both bb and cider
> installed.

I just installed the patch. So if you have `bb` in your path, ob-clojure
should use babashka as default and only fall back to cider when it's not.

Currently it looks for bb, and then next `nbb` before cider.
Now I realise that nbb shouldn't even be in that list at all but instead
should be the default for `org-babel-execute:clojurescript`.

> I stopped using clojure in org because it was way too fragile -
> depending heavily on cider features which often changed. However, now we
> have babashka and nbb, I'm thinking about using org again with
> clojure.

Happy to hear feedback if you have any :)

> I recall looking at the babel code for clojure some time back to see if
> it could be made simpler and more reliable. However, there wasn't much
> that could be improved on given the design of cider and its focus on
> interactive clojure development.

I agree, cider is a pretty heavy library.
And I feel that if you have already "jacked in" in cider, you simply
eval straight from you clj(s) code instead of using org babel.
(Maybe in combination with clerk or something if you want it more literal)

> I then thought using something like the
> Clojure CLI tools might be the way to go.

I think I'll add a backend for the Clojure CLI tools.
Should be similar simple as bb and nbb with slower startup time,
but you would get a JVM Clojure for it.

> Now I feel that babashka for clojure and nbb for clojurescript
> might be the right answer.

Agree. bb default for Clojure and nbb for ClojureScript.

Thanks,
  Daniel

Re: Auto detect ob-clojure backend (was: [PATCH] Fix ob-clojure handling source block variable's value is a org-mode table or list)

[Daniel Kraus]

Ihor Radchenko  writes:

> Daniel Kraus  writes:
>
>> +(defcustom org-babel-clojure-backend (cond
>> +  ((executable-find "bb") 'babashka)
>> +  ((executable-find "nbb") 'nbb)
>> +  ((featurep 'cider) 'cider)
>> +  ((featurep 'inf-clojure) 'inf-clojure)
>> +  ((featurep 'slime) 'slime)
>> +  (t nil))
>
> What if users have, say, cider installed and also babashka executable?
> Will it be expected to use babashka?

Yes. The only thing that makes me slightly hesitant is that e.g.
someone doesn't have `bb` installed. Executes clojure source blocks
which are then evaluated in, let's say cider.
Then they install `bb` and the next time they start Emacs, the same
source block on re-evaluation would be executed with babashka.

I think this is still the best out of the box experience as it
"just works" for most users without having to customise something
and if they want it fixed, they can pin it to a certain backend.

What's your opinion?

Cheers,
  Daniel

Re: ob-clojure session support (was: ob-clojure eval error when has comment at end of code line)

[Daniel Kraus]

Ihor Radchenko  writes:
>
> If Bastien removed session support, and you do not see any justification,
> it was most likely an oversight. We generally avoid feature regressions:
> https://bzg.fr/en/the-software-maintainers-pledge/
>
> So, if sessions are currently not supported, it should be considered a
> bug and fixed. Let me know if you need any help with the fix.

I agree that session support would be nice.
The cider backend (and maybe slime and inf-clojure, which I haven't 
installed/tried)
opens a connection and then all source blocks are evaled in this one session,
but you can't specify multiple.
For babashka, nbb, it's simply running the cli with the code from the source
block.

> Let me know if you need any help with the fix.

I feel adding session support for babashka and nbb (and maybe a future 
clojure-cli backend)
makes most sense.
Relying on `inf-clojure` would make this task simpler but this is also the
package the least amount of people will have installed, as cider is much more 
popular.

Is there a good (and simple) example of another babel package that implements
session support but doesn't depend on an external inf-xxx package?
Then I could use code from there.

Thanks,
  Daniel

Auto detect ob-clojure backend (was: [PATCH] Fix ob-clojure handling source block variable's value is a org-mode table or list)

[Daniel Kraus]

Bastien  writes:

> Daniel Kraus  writes:
>
>> I think I'll go with the big `cond` above to auto-detect what's
>> installed. That's probably the best out-of-the-box experience.
> Indeed, thank you!

I would push the attached patch.
I'm not sure about the `:package-version` keyword in defcustom.
I want to say that the default value changed.
Should I do it this way? Is `(Org . "9.6")` correct as it's unreleased?

Thanks,
  Daniel
>From bd68ece99ce411439db87cd19e44ffbc49677ae3 Mon Sep 17 00:00:00 2001
From: Daniel Kraus 
Date: Sat, 29 Oct 2022 23:20:06 +0200
Subject: [PATCH] ob-clojure.el: Auto detect backend

* lisp/ob-clojure.el (org-babel-clojure-backend): Set the backend
to an available cli program or elisp package.
---
 lisp/ob-clojure.el | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-clojure.el b/lisp/ob-clojure.el
index 5654d5208..25f1c78a6 100644
--- a/lisp/ob-clojure.el
+++ b/lisp/ob-clojure.el
@@ -76,9 +76,16 @@
 (defvar org-babel-default-header-args:clojurescript '())
 (defvar org-babel-header-args:clojurescript '((package . :any)))
 
-(defcustom org-babel-clojure-backend nil
+(defcustom org-babel-clojure-backend (cond
+  ((executable-find "bb") 'babashka)
+  ((executable-find "nbb") 'nbb)
+  ((featurep 'cider) 'cider)
+  ((featurep 'inf-clojure) 'inf-clojure)
+  ((featurep 'slime) 'slime)
+  (t nil))
   "Backend used to evaluate Clojure code blocks."
   :group 'org-babel
+  :package-version '(Org . "9.6")
   :type '(choice
 	  (const :tag "inf-clojure" inf-clojure)
 	  (const :tag "cider" cider)
-- 
2.38.1

Re: [PATCH] lisp/ob-tangle.el, lisp/ob-core.el: Add strip-tangle noweb option

[Daniel Ziltener]

Am 30.10.22 um 05:12 schrieb Ihor Radchenko:

Daniel Ziltener  writes:


From: Daniel Ziltener 

* lisp/ob-tangle.el (org-babel-tangle-single-block): strip noweb tags
from block if :noweb has been set to strip-tangle.
* lisp/ob-core.el (org-babel-common-header-args-w-values): add
"strip-tangle" as new allowed value.
* testing/lisp/test-ob-tangle.el (ob-tangle/strip-tangle): add new test
case for strip-tangle.
* doc/org-manual.org (Noweb Reference Syntax): adjust documentation for
the noweb header argument.
* etc/ORG-NEWS: add entry for new header argument value.

This patch adds the "strip-tangle" option for the :noweb header
argument. This strips the noweb tags before tangling the block. This can
be useful for e.g. testing purposes where one wants to use a block as
test case that can be both run inline as well as tangled into a file for
automated testing.

Thanks, but it looks like your PGP signature corrupted the email patch.
Could you please create a separate patch file and attach it in the
reply?
Sure, here's the patch attached, as generated by "git format-patch 
origin/main".
From 0133162ef78e007fe4918016a4aabf8bc3734488 Mon Sep 17 00:00:00 2001
From: Daniel Ziltener 
Date: Sun, 30 Oct 2022 01:20:53 +0200
Subject: [PATCH] lisp/ob-tangle.el, lisp/ob-core.el: Add strip-tangle

* lisp/ob-tangle.el (org-babel-tangle-single-block): strip noweb tags
from block if :noweb has been set to strip-tangle.
* lisp/ob-core.el (org-babel-common-header-args-w-values): add
"strip-tangle" as new allowed value.
* testing/lisp/test-ob-tangle.el (ob-tangle/strip-tangle): add new test
case for strip-tangle.
* doc/org-manual.org (Noweb Reference Syntax): adjust documentation for
the noweb header argument.
* etc/ORG-NEWS: add entry for new header argument value.

This patch adds the "strip-tangle" option for the :noweb header
argument. This strips the noweb tags before tangling the block. This can
be useful for e.g. testing purposes where one wants to use a block as
test case that can be both run inline as well as tangled into a file for
automated testing.
---
 doc/org-manual.org |  6 ++
 etc/ORG-NEWS   |  5 +
 lisp/ob-core.el|  2 +-
 lisp/ob-tangle.el  |  4 +++-
 testing/lisp/test-ob-tangle.el | 26 ++
 5 files changed, 41 insertions(+), 2 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 18a050069..064d51bcd 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -18993,6 +18993,12 @@ tangled, or exported.
   Expansion of noweb syntax references in the body of the code block
   when tangling.  No expansion when evaluating or exporting.
 
+- =strip-tangle= ::
+
+  Expansion of noweb syntax references in the body of the code block
+  when evaluating or exporting.  Removes noweb syntax references
+  when exporting.
+
 - =no-export= ::
 
   Expansion of noweb syntax references in the body of the code block
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 6e875deb6..2c66d2e45 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -228,6 +228,11 @@ commands.
 =:noweb-prefix= can be set to =no= to prevent the prefix characters
 from being repeated when expanding a multiline noweb reference.
 
+*** New =:noweb= babel header argument value =strip-tangle=
+
+=:noweb= can be set to =strip-tangle= to strip the noweb syntax references
+before tangling.
+
 *** New LaTeX source block backend using =engraved-faces-latex=
 
 When ~org-latex-src-block-backend~ is set to ~engraved~,
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 518831ec6..c52f113b4 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -414,7 +414,7 @@ then run `org-babel-switch-to-session'."
 (mkdirp	. ((yes no)))
 (no-expand)
 (noeval)
-(noweb	. ((yes no tangle no-export strip-export)))
+(noweb	. ((yes no tangle strip-tangle no-export strip-export)))
 (noweb-ref	. :any)
 (noweb-sep  . :any)
 (noweb-prefix . ((no yes)))
diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 2da92efaf..d9d847195 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -536,7 +536,9 @@ non-nil, return the full association list to be used by
 	 (body
 	  ;; Run the tangle-body-hook.
   (let ((body (if (org-babel-noweb-p params :tangle)
-			  (org-babel-expand-noweb-references info)
+  (if (string= "strip-tangle" (cdr (assq :noweb (nth 2 info
+  (replace-regexp-in-string (org-babel-noweb-wrap) "" (nth 1 info))
+			(org-babel-expand-noweb-references info))
 			(nth 1 info
 	(with-temp-buffer
 	  (insert
diff --git a/testing/lisp/test-ob-tangle.el b/testing/lisp/test-ob-tangle.el
index a0003ee40..af2a72682 100644
--- a/testing/lisp/test-ob-tangle.el
+++ b/testing/lisp/test-ob-tangle.el
@@ -510,6 +510,32 @@ another block
 		(org-split-string (buffer-string
 	  (delete-file file

Re: [PATCH] lisp/ob-tangle.el, lisp/ob-core.el: Add strip-tangle noweb option

[Daniel Ziltener]

From: Daniel Ziltener 

* lisp/ob-tangle.el (org-babel-tangle-single-block): strip noweb tags
from block if :noweb has been set to strip-tangle.
* lisp/ob-core.el (org-babel-common-header-args-w-values): add
"strip-tangle" as new allowed value.
* testing/lisp/test-ob-tangle.el (ob-tangle/strip-tangle): add new test
case for strip-tangle.
* doc/org-manual.org (Noweb Reference Syntax): adjust documentation for
the noweb header argument.
* etc/ORG-NEWS: add entry for new header argument value.

This patch adds the "strip-tangle" option for the :noweb header
argument. This strips the noweb tags before tangling the block. This can
be useful for e.g. testing purposes where one wants to use a block as
test case that can be both run inline as well as tangled into a file for
automated testing.
---
 doc/org-manual.org |  6 ++
 etc/ORG-NEWS   |  5 +
 lisp/ob-core.el    |  2 +-
 lisp/ob-tangle.el  |  4 +++-
 testing/lisp/test-ob-tangle.el | 26 ++
 5 files changed, 41 insertions(+), 2 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 18a050069..064d51bcd 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -18993,6 +18993,12 @@ tangled, or exported.
   Expansion of noweb syntax references in the body of the code block
   when tangling.  No expansion when evaluating or exporting.

+- =strip-tangle= ::
+
+  Expansion of noweb syntax references in the body of the code block
+  when evaluating or exporting.  Removes noweb syntax references
+  when exporting.
+
 - =no-export= ::

   Expansion of noweb syntax references in the body of the code block
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 6e875deb6..2c66d2e45 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -228,6 +228,11 @@ commands.
 =:noweb-prefix= can be set to =no= to prevent the prefix characters
 from being repeated when expanding a multiline noweb reference.

+*** New =:noweb= babel header argument value =strip-tangle=
+
+=:noweb= can be set to =strip-tangle= to strip the noweb syntax references
+before tangling.
+
 *** New LaTeX source block backend using =engraved-faces-latex=

 When ~org-latex-src-block-backend~ is set to ~engraved~,
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 518831ec6..c52f113b4 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -414,7 +414,7 @@ then run `org-babel-switch-to-session'."
 (mkdirp    . ((yes no)))
 (no-expand)
 (noeval)
-    (noweb    . ((yes no tangle no-export strip-export)))
+    (noweb    . ((yes no tangle strip-tangle no-export strip-export)))
 (noweb-ref    . :any)
 (noweb-sep  . :any)
 (noweb-prefix . ((no yes)))
diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 2da92efaf..d9d847195 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -536,7 +536,9 @@ non-nil, return the full association list to be used by
  (body
   ;; Run the tangle-body-hook.
   (let ((body (if (org-babel-noweb-p params :tangle)
-              (org-babel-expand-noweb-references info)
+  (if (string= "strip-tangle" (cdr (assq :noweb 
(nth 2 info
+  (replace-regexp-in-string 
(org-babel-noweb-wrap) "" (nth 1 info))

+                (org-babel-expand-noweb-references info))
         (nth 1 info
     (with-temp-buffer
   (insert
diff --git a/testing/lisp/test-ob-tangle.el b/testing/lisp/test-ob-tangle.el
index a0003ee40..af2a72682 100644
--- a/testing/lisp/test-ob-tangle.el
+++ b/testing/lisp/test-ob-tangle.el
@@ -510,6 +510,32 @@ another block
         (org-split-string (buffer-string
   (delete-file file))

+(ert-deftest ob-tangle/strip-tangle ()
+  "Test if strip-tangle works correctly when tangling noweb code blocks."
+  (should
+   (equal '("1")
+  (let ((file (make-temp-file "org-tangle-")))
+    (unwind-protect
+    (progn
+  (org-test-with-temp-text-in-file
+   (format "
+#+name: block1
+#+begin_src elisp
+2
+#+end_src
+
+#+begin_src elisp :noweb strip-tangle :tangle %s
++1<>
+#+end_src
+" file)
+   (let ((org-babel-noweb-error-all-langs nil)
+ (org-babel-noweb-error-langs nil))
+ (org-babel-tangle)))
+  (with-temp-buffer
+    (insert-file-contents file)
+    (org-split-string (buffer-string
+  (delete-file file))
+
 (ert-deftest ob-tangle/detangle-false-positive ()
   "Test handling of false positive link during detangle."
   (let (buffer)
--
2.35.3




OpenPGP_0x752C7F031AADF16F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

indent-tabs-mode in org (was: ob-clojure eval error when has comment at end of code line)

[Daniel Kraus]

Ihor Radchenko  writes:
> Daniel Kraus  writes:
>
>> - What should I use for indention? Looking in ob-clojure and org.el
>>   it seems that using tabs with tab-width 8 is standard but there's
>>   quite a few lines where it's spaces only.
> That is a good question. I guess, just Emacs default.
> Our code is not consistent here...
> Maybe Bastien can clarify better.

jFYI, because I was just wondering why the org
.dir-locals.el sets indent-tabs-mode to nil.
Luckily Kyle wrote a good commit message:

--cut--
.dir-locals.el: Set indent-tabs-mode to nil in Elisp sources

Despite .dir-locals.el having a catchall value of t for
indent-tabs-mode, Org's Elisp files are a mix of tabs and spaces.
Emacs has used a value of nil for indent-tabs-mode since 93d4412046
(Set indent-tabs-mode to nil in (most) Elisp sources, 2015-04-15).  Do
the same.

Ref: https://orgmode.org/list/87eejsg9vw@gnu.org
--cut--

So that clarifies it for me and I do NOT indent with tabs in the future :)

Cheers,
  Daniel

Re: [PATCH] Fix ob-clojure handling source block variable's value is a org-mode table or list

[Daniel Kraus]

Hi

Ihor Radchenko  writes:
> "Christopher M. Miles"  writes:
>> Any review comments about this patch?
> I have sent the following comment shortly after your followup:

I even made another post after that, suggesting that the if condition
is not even needed. Simply always quoting seems to work and is also the
way it's done in `ob-lisp.el`.
See https://list.orgmode.org/orgmode/874jvp9wsg@kraus.my/

This simple patch is also already installed. Can you test if that works for you?

And in case you missed it, I made another reply for you bug report
about inline comments.
Check https://list.orgmode.org/orgmode/878rl1a1e0@kraus.my/

Thanks,
  Daniel

Re: [PATCH] Fix ob-clojure handling source block variable's value is a org-mode table or list

[Daniel Kraus]

Bastien  writes:

> Daniel Kraus  writes:
>> I would set it to (and (executable-find "bb") 'babashka) so it's still nil
>> when babashka is installed?
> (You mean "not installed", right?)

Of course.

>> Or we could even test more available backends like
>>
>> (cond
>>  ((executable-find "bb") 'babashka)
>>  ((executable-find "nbb") 'nbb)
>>  ((featurep 'cider) 'cider)
>>  ((featurep 'inf-clojure) 'inf-clojure)
>>  ((featurep 'slime) 'slime))
>>
>> Or is that too much "magic" in that on some systems the default is bb
>> and in others it's cider etc?
>
> I think this is acceptable magic: perhaps we should first check what
> is done in other Babel languages and align with their level of magic
> for guessing the correct executable -- but I suspect Clojure is a bit
> special here, in that it has a lot of different options.

I looked around a bit but couldn't find another babel package with a
similar problems, i.e. that some backends are completely different
and not just changing the name of the executable.

I think I'll go with the big `cond` above to auto-detect what's
installed. That's probably the best out-of-the-box experience.

Cheers,
  Daniel

Re: [PATCH] Fix ob-clojure handling source block variable's value is a org-mode table or list

[Daniel Kraus]

Hi!

Bastien Guerry  writes:
> For now `org-babel-clojure-backend' is nil.
>
> I suggest to set it to babashka by default: babashka is stable and
> well established now, it is by far the most efficient way to run
> Clojure code.  Also, it is particularily suitable for Babel use.
>
> What do you think?

Sounds good.
I would set it to (and (executable-find "bb") 'babashka) so it's still nil
when babashka is installed?

Or we could even test more available backends like

(cond
 ((executable-find "bb") 'babashka)
 ((executable-find "nbb") 'nbb)
 ((featurep 'cider) 'cider)
 ((featurep 'inf-clojure) 'inf-clojure)
 ((featurep 'slime) 'slime))

Or is that too much "magic" in that on some systems the default is bb
and in others it's cider etc?

Cheers,
  Daniel

ob-clojure session support (was: ob-clojure eval error when has comment at end of code line)

[Daniel Kraus]

Ihor Radchenko  writes:

> make test BTEST_POST="-L /path/to/cider.el" BTEST_OB_LANGUAGES="clojure" 
> BTEST_RE="ob-clojure"
>
> Note that our tests demand cider executable and library.
> Testing with external libraries is a bit manual.

Thanks. I think cider is falsely required in the test.
It tests session support which I don't think ob-clojure has.

Looking in the history, Christopher added session support 5 years ago,
then (3 years ago) I see Bastien also adding something with initiate-session but
then removing all session support the following commit.
I guess something was broken and got removed but stayed in the test?

Does anyone remember what's the status of ob-clojure session support?

Cheers,
  Daniel

Re: [PATCH] lisp/ob-tangle.el, lisp/ob-core.el: Add strip-tangle noweb option

[Daniel Ziltener]

Am 28.10.22 um 04:19 schrieb Ihor Radchenko:

dzilte...@lyrion.ch writes:


From: Daniel Ziltener 

* ob-tangle.el, ob-core.el, test-ob-tangle.el, org-manual.org: Add a
"strip-tangle" noweb option to strip the noweb tags when tangling, but
keep and expand them otherwise.

Thanks for the patch!

If I understand correctly, you are suggesting

Could you please follow
https://orgmode.org/worg/org-contribute.html#commit-messages for the
commit log entries?
I tried to follow that. To follow it "more" I guess I have to make one 
commit per file I changed? There isn't an example for multiple files, so 
I was not sure how exactly to follow it.

Also, do you have FSF copyright assignment? If no, you also need to add
TINYCHANGE cookie to the commit message. See
https://orgmode.org/worg/org-contribute.html#first-patch

I do, yes, I sent in the signed form on Wednesday as requested by the FSF.

+- =strip-tangle= ::
+
+  Expansion of noweb syntax references in the body of the code block
+  when evaluating or exporting. Removes noweb syntax references
+  when tangling.

This is a new feature and thus should also be mentioned in etc/NEWS.

Also, please use double space between sentences. See
doc/Documentation_Standards.org.

Noted, I'll do both of these.

(let ((allowed-values (cl-case context
- (:tangle '("yes" "tangle" "no-export" "strip-export"))
- (:eval   '("yes" "no-export" "strip-export" "eval"))
- (:export '("yes")
+ (:tangle '("yes" "tangle" "no-export" "strip-export" 
"strip-tangle"))
+ (:eval   '("yes" "no-export" "strip-export" "eval" 
"strip-tangle"))
+ (:export '("yes" "strip-tangle")

AFAIU, you are suggesting a new value for :noweb header argument.
But this function has nothing to do with :noweb. This change will check
for :tangle strip-tangle, :eval strip-tangle, and :export strip-tangle.
What is the purpose?
I suppose then I made a mistake there. My intention was what you mention 
next:

Also, the allowed values of standard header args are defined in
org-babel-common-header-args-w-values, which you did not change.

I will adjust that one instead.


OpenPGP_0x752C7F031AADF16F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH] Fix ob-clojure handling source block variable's value is a org-mode table or list

[Daniel Kraus]

Hi!

Ihor Radchenko  writes:

> "Christopher M. Miles"  writes:
>> Without this patch, it will report error "class 
>> java.lang.ClassCastException" from CIDER.
>
> Bastien, could you please take a look? I was unable to setup clojure dev
> environment on my machine for testing. So, I am not able to confirm if
> the issue exists.

Just in case you want to play around with Clojure, installing babashka
(https://github.com/babashka/babashka) is a single binary and very simple to 
install.

>>   ;; Variables binding.
>>   (if (null vars) (org-trim body)
>> -   (format "(let [%s]\n%s)"
>> -   (mapconcat
>> -(lambda (var)
>> -  (format "%S %S" (car var) (cdr var)))
>> -vars
>> -"\n  ")
>> -   body))
>> +   ;; variable's value is a list from org-mode passed table 
>> or list.
>> +   (if (listp (cdr (car vars)))
>
> This test is fishy. It only tests for the first variable assignment.
> What if you have multiple vars some being tables and some not?

I looked at `ob-lisp.el` and simply always quoting seems to be working.
See attached patch and here's my test (based from Chrisophers example):

--cut--

#+NAME: ob-clojure-table-test
| a | b | c |
|---+---+---|
| 1 | 2 | 3 |

#+NAME: ob-clojure-table-test-2
| a | b | c |
|---+---+---|
| 1 | 2 | 3 |
| 4 | 5 | 6 |

#+begin_src clojure :var v1=42 :var v2="foobar" :var v3=ob-clojure-table-test 
:var v4=ob-clojure-table-test-2 :results output
(prn (+ v1 5))
(prn v2)
(prn v3)
(prn v4)
#+end_src

#+RESULTS:
: 47
: "foobar"
: ((1 2 3))
: ((1 2 3) (4 5 6))

--cut--

Cheers,
  Daniel
>From 1a2fa382e7a5925d4b85d90f1fe4ac7c012f81a4 Mon Sep 17 00:00:00 2001
From: Daniel Kraus 
Date: Thu, 27 Oct 2022 16:04:02 +0200
Subject: [PATCH] lisp/ob-clojure.el: Fix header argument :var binding

* lisp/ob-clojure.el (org-babel-expand-body:clojure): Always quote
the variables passed from org-mode in clojure let binding.
When a variable is a table or list, it's value is is "(..data..)"
and without quotes, clojure would try to execute the first
value as a function.
---
 lisp/ob-clojure.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/ob-clojure.el b/lisp/ob-clojure.el
index 0649469b3..c76a3f013 100644
--- a/lisp/ob-clojure.el
+++ b/lisp/ob-clojure.el
@@ -132,7 +132,7 @@ or set the `:backend' header argument"
 		   (format "(let [%s]\n%s)"
 			   (mapconcat
 			(lambda (var)
-			  (format "%S %S" (car var) (cdr var)))
+			  (format "%S '%S" (car var) (cdr var)))
 			vars
 			"\n  ")
 			   body))
-- 
2.38.1

Re: ob-clojure eval error when has comment at end of code line

[Daniel Kraus]

Hi!

I had a look and apparently cider-eval returns nil when the expression
is a comment, vs the string "nil" when the Clojure expression returns nil.
Simply filtering nil values out seems to have fixed the issue
for me.
@Christopher, can you check the attached patch if this works for you?

@Ihor, a few developer related questions:
- I wanted to add a test, how can I run only test-ob-clojure?
  I don't think the tests work currently and I would fix them and add more.
- What should I use for indention? Looking in ob-clojure and org.el
  it seems that using tabs with tab-width 8 is standard but there's
  quite a few lines where it's spaces only.
- If this simple patch for example or fixing tests is good,
  should I just install it?
  Can I "freely" install minor changes to ob-clojure or should
  everything go over the mailinglist?

Thanks. I hope I can work a bit more on ob-clojure the next few days,
I think I missed a few emails, sorry. Now I have a filter rule where
mails with Clojure in the subject go to my inbox.

Cheers,
  Daniel
>From 87054023df0876d17771ee3885e7b1091ccdeab1 Mon Sep 17 00:00:00 2001
From: Daniel Kraus 
Date: Thu, 27 Oct 2022 14:16:33 +0200
Subject: [PATCH] lisp/ob-clojure.el: Fix bug with inline comments

* lisp/ob-clojure.el (ob-clojure-eval-with-cider): Filter out
  nil values from cider evaluation.
---
 lisp/ob-clojure.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/ob-clojure.el b/lisp/ob-clojure.el
index 0649469b3..eff8d04e4 100644
--- a/lisp/ob-clojure.el
+++ b/lisp/ob-clojure.el
@@ -239,7 +239,7 @@ or set the `:backend' header argument"
 		result0)))
   (ob-clojure-string-or-list
(reverse (delete "" (mapcar (lambda (r)
- (replace-regexp-in-string "nil" "" r))
+ (replace-regexp-in-string "nil" "" (or r "")))
    result0)))
 
 (defun ob-clojure-eval-with-slime (expanded params)
-- 
2.38.1


Ihor Radchenko  writes:

> "Christopher M. Miles"  writes:
>
>> I have following Clojure source block:
>>
>> #+begin_src clojure
>> (re-find #"\d+" "I've just finished reading Fahrenheit 451");; => "451"
>> (re-find #"Bees" "Beads aren't cheap.");; => nil
>> #+end_src
>>
>> When I press =[C-c C-c]= to evaluate source block, got error:
>>
>> When there is no comments behind code lines. No this error.
>>
>> #+begin_example
>> Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
>>   replace-regexp-in-string("nil" "" nil)
>
> Daniel, could you please take a look?

Re: [External] : Re: [BUG] recent slow down in agenda's clock table report (and with first clock-in) [9.6-pre (release_9.5.5-995-g4b9aef @ /home/dortmann/src/git-org-mode/lisp/)]

[Daniel Ortmann]

Thank you!  I will take one or more of those steps.

(The performance drop was sudden and steep, by the way.)

On 10/19/22 23:56, Ihor Radchenko wrote:

Daniel Ortmann  writes:


Here you go.

Thanks!
It looks like you have some task with giant years-worth logbook drawer.

You can try to reduce org-element--cache-self-verify-frequency or even
set org-element--cache-self-verify to nil. The latter should be safe if
you haven't seen any Org mode warnings recently.

[BUG] recent slow down in agenda's clock table report (and with first clock-in) [9.6-pre (release_9.5.5-995-g4b9aef @ /home/dortmann/src/git-org-mode/lisp/)]

[Daniel Ortmann]

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.


Sometime during the past week I have been surprised by a sudden jump in
load time when clocking into the first task in the agenda. Today, while
tracking down that performance change, the problem "disappeared"! The
first clockin behaved normally.

But! Pressing 'R' in the daily agenda took a long time.

I ran profile-start and then pressed R.
Here are the cpu and memory reports.
The memory report seems odd to me.
Thoughts?

19250 58% + ...
13660 41% + command-execute
35 0% + timer-event-handler

3,754,109,912 99% + command-execute
168,717 0% + timer-event-handler
19,138 0% + redisplay_internal (C function)
0 0% ...


Emacs : GNU Emacs 29.0.50 (build 66, x86_64-pc-linux-gnu, GTK+ Version 
3.22.30, cairo version 1.15.12)

of 2022-10-18
Package: Org mode version 9.6-pre (release_9.5.5-995-g4b9aef @ 
/home/dortmann/src/git-org-mode/lisp/)

[BUG] ob-scheme: geiser command has changed [9.6 (9.6-??-86c4635 @ /home/zilti/.emacs.d/.local/straight/build-27.2/org/)]

[Daniel Ziltener]

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.


The latest Geiser release 0.26 got rid of the "run-geiser" function. It
is sufficient to just replace the call to "run-geiser" with "geiser"
instead to make ob-scheme work again.

Emacs : GNU Emacs 27.2 (build 1, x86_64-suse-linux-gnu, GTK+ Version 
3.24.31, cairo version 1.16.0)
Package: Org mode version 9.6 (9.6-??-86c4635 @ 
/home/zilti/.emacs.d/.local/straight/build-27.2/org/)


current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)

org-fontify-whole-heading-line t
org-capture-prepare-finalize-hook '(org-roam-capture--install-finalize-h)
org-link-shell-confirm-function 'yes-or-no-p
org-mode-local-vars-hook '(+indent-guides-disable-maybe-h +org-init-gifs-h)
org-babel-after-execute-hook 
'(+org-redisplay-inline-images-in-babel-result-h)

org-insert-heading-respect-content t
org-after-refile-insert-hook '(save-buffer)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-roam-log-setup-hook '(org-roam--register-completion-functions-h)
org-follow-link-hook '(+nav-flash-delayed-blink-cursor-h)
org-roam-db-node-include-function '(closure (t) nil t)
org-persist-directory "/home/zilti/.emacs.d/.local/cacheorg/persist/"
org-refile-targets '((nil :maxlevel . 3) (org-agenda-files :maxlevel . 3))
org-html-format-inlinetask-function 
'org-html-format-inlinetask-default-function

org-enforce-todo-dependencies t
org-odt-format-headline-function 'org-odt-format-headline-default-function
org-special-ctrl-a/e t
org-imenu-depth 6
org-persist-before-write-hook '(org-element--cache-persist-before-write)
org-agenda-files '("~/org/")
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-reveal-start-hook '(org-decrypt-entry)
org-modules '(ol-bibtex)
org-startup-folded nil
org-blocker-hook '(org-block-todo-from-children-or-siblings-or-parent)
org-log-buffer-setup-hook '(org-roam-log--setup)
org-mode-hook '(er/add-org-mode-expansions 
+lookup--init-org-mode-handlers-h

(closure ((hook . org-mode-hook) (--dolist-tail--) t) ( _)
(add-hook 'before-save-hook 'org-encrypt-entries nil t))
(closure
(org--rds reftex-docstruct-symbol org--single-lines-list-is-paragraph 
org-element-greater-elements
visual-fill-column-width org-clock-history org-agenda-current-date 
org-with-time org-defdecode org-def
org-read-date-inactive org-ans2 org-ans1 
org-columns-current-fmt-compiled org-clock-current-task org-clock-effort
org-agenda-skip-function org-agenda-skip-comment-trees 
org-agenda-archives-mode org-end-time-was-given
org-time-was-given org-log-note-extra org-log-note-purpose 
org-log-post-message org-last-inserted-timestamp
org-last-changed-timestamp org-entry-property-inherited-from 
org-blocked-by-checkboxes org-state
org-agenda-headline-snapshot-before-repeat org-agenda-buffer-name 
org-agenda-start-on-weekday
org-agenda-buffer-tmp-name org-priority-regexp org-mode-abbrev-table 
org-mode-syntax-table org-element-use-cache
org-element-cache-persistent buffer-face-mode-face org-tbl-menu 
org-org-menu org-struct-menu org-entities
org-last-state org-id-track-globally org-clock-start-time texmathp-why 
remember-data-file
org-agenda-tags-todo-honor-ignore-options iswitchb-temp-buflist 
align-mode-rules-list org-emphasis-alist
org-emphasis-regexp-components org-export-registered-backends 
crm-separator org-babel-load-languages
org-id-overriding-file-name org-indent-indentation-per-level 
org-element--timestamp-regexp
org-element-cache-map-continue-from org-element-paragraph-separate 
org-agenda-buffer-name

org-inlinetask-min-level t)
nil (add-hook 'change-major-mode-hook 'org-fold-show-all 'append 'local))
(closure
(org-src-window-setup *this* org-babel-confirm-evaluate-answer-no 
org-babel-tangle-uncomment-comments
org-src-preserve-indentation org-src-lang-modes 
org-edit-src-content-indentation org-babel-library-of-babel t)
nil (add-hook 'change-major-mode-hook #'org-babel-show-result-all 
'append 'local))

org-babel-result-hide-spec org-babel-hide-all-hashes
(closure
(org-agenda-skip-regexp org-fold-core-style org-table1-hline-regexp 
org-table-tab-recognizes-table\.el
org-table-dataline-regexp org-table-any-border-regexp 
org-agenda-restriction-lock-overlay
org-agenda-overriding-restriction org-agenda-diary-file 
org-complex-heading-regexp calendar-mode-map t)

nil (setq imenu-create-index-function 'org-imenu-get-tree))
doom-disable-show-paren-mode-h doom-disable-show-trailing-whitespace-h 
+org-enable-auto-reformat-tables-h
+org-enable-auto-update-cookies-h +org-make-last-point-visible-h 
evil-org-mode toc-org-enable writegood-mode

flyspell-mode embrace-org-mode-hook org-eldoc-load)
org-clock-persist 'history

Re: [BUG] beamer export

[Daniel Fleischer]

Hi, I'm on vacation for the next month. I can look at it when I'm back.

On Thu, Sep 29, 2022, 03:44 Ihor Radchenko  wrote:

> Leo Butler  writes:
>
> > The following Org document shows a bug in the beamer exporter.
>
> Confirmed on main.
>
> There are two bugs reported here:
> 1. ox-latex export bug for src blocks containing direct LaTeX when
>org-latex-src-block-backend is set to its default 'verbatim value
> 2. ox-beamer export bug as described in the attached org file
>
> Daniel, can you please take a look at the first bug?
> I suspect that \commands should be additionally escaped in verbatim
> environment, similar to
>
> https://stackoverflow.com/questions/3019774/how-write-this-in-verbatim-latex
>
> --
> Ihor Radchenko,
> Org mode contributor,
> Learn more about Org mode at https://orgmode.org/.
> Support Org development at https://liberapay.com/org-mode,
> or support my work at https://liberapay.com/yantar92
>

Re: [PATCH] ob-clojure.el: Add support for babashka and nbb backend

[Daniel Kraus]

Hi!

Bastien  writes:

> Applied in main as 764642f5, thanks a lot and sorry for the delay.
>
> I also added you to https://orgmode.org/worg/contributors.html.

Thank you very much :)

> Would you consider taking over the maintainance of ob-clojure.el?

I think I would. What does this exactly entail?
Should I subscribe to https://updates.orgmode.org/ or something?
Is there a backlog if issues to go through and try to resolve?

Cheers,
  Daniel

Re: [External] : Re: strange errors with org-element-cache-reset and jit-lock-function void-variable org-element-citation-prefix-re

[Daniel Ortmann]

Was Eli Z's observation the key?  Of code not autoloading when 
eval-buffer is running?


On 9/21/22 03:37, Ihor Radchenko wrote:

Daniel Ortmann  writes:


These two lines are in my *Messages* buffer:
File mode specification error: (void-function org-element-cache-reset)
Error during redisplay: (jit-lock-function 1) signaled (void-variable
org-element-citation-prefix-re)

Confirmed.
I know how to "fix" this (can just add require 'org-element into
`org-mode'), but I do not fully understand what is going on on Emacs
side.

Let's see what Emacs devs say.
See 
https://urldefense.com/v3/__https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57972__;!!ACWV5N9M2RV99hQ!I8yBQdVtvdB9WZzgR3JRtDsvGImyGOhqd8fkT_pXuN02wF5lk8ftp-3v1HiF-T3Rn-eyiQIr2BhjbxqK_bo$

Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section

[Daniel Fleischer]

Ihor Radchenko [2022-09-21 Wed 16:55] wrote:

> More concretely, I mean something like
>
> * Section
>   :PROPERTIES:
>   :attr_latex: :prepend "section" \setcounter{secnumdepth}{0}
>   :attr_latex+: :prepend "section" 
> \addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}
>   :attr_latex+: :append "section" \setcounter{secnumdepth}{2}
>   :attr_latex+: :append "section" 
> \addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
>   :END:
>
> I suggest to use more canonical attr_latex that explicitly limits the
> export backend.

I don't understand the usecase, that's why I wasn't really following. If
you write \vspace{10cm} before some headline, it's going to do the right
thing even if it "belongs" to a previous headline.

If org-latex-classes is not a good enough solution I also think it should
be a general export feature, not specific to latex. In that case you
need a general syntax, e.g. properties like "export_prefix",
"export_postfix" and the code should be as simple as possible, i.e.
copying the text one line before/after the headline. 

-- 
Daniel Fleischer

strange errors with org-element-cache-reset and jit-lock-function void-variable org-element-citation-prefix-re

[Daniel Ortmann]

Hmmm ...
While trying to investigate one bug I have run into another odd one:

 * emacs version: GNU Emacs 29.0.50 (build 23, x86_64-pc-linux-gnu,
   GTK+ Version 3.22.30, cairo version 1.15.12) of 2022-09-20
 * org version: Org mode version 9.5.5 (release_9.5.5-804-gf1a197 @
   /home/dortmann/src/git-org-mode/lisp/)


These two lines are in my *Messages* buffer:
File mode specification error: (void-function org-element-cache-reset)
Error during redisplay: (jit-lock-function 1) signaled (void-variable 
org-element-citation-prefix-re)



I ran this:
dortmann@ddo-linux:.emacs.d$ emacs -Q --debug-init asdf.el
... and then ran eval-buffer.

Where asdf.el has this content:
(add-to-list 'load-path "/home/dortmann/src/git-org-mode/lisp")
(require 'org)

(setq org-capture-templates
  `(("c" "Item to current clocked task" checkitem
   (clock)
   "%i%?" :prepend t :empty-lines 1)))



Then I loaded asdf.org which has this:
* TODO start clock on this test item


The result is the failure message above.  :-/

'make autoloads' works but 'make ; make autoloads' fails with a version mismatch?

[Daniel Ortmann]

What's up with this behavior?  It began a couple of weeks ago.  I have 
the load-path set immediately in my init.el followed by require org.


Versions are:

 * GNU Emacs 29.0.50 (build 9, x86_64-pc-linux-gnu, GTK+ Version
   3.22.30, cairo version 1.15.12) of 2022-09-14
 * Org mode version 9.5.5 (release_9.5.5-785-g86c463 @
   /home/dortmann/src/git-org-mode/lisp/)

'make clean' followed by 'make autoloads' works fine:

dortmann@ddo-linux:git-org-mode$ make autoloads
make -C lisp autoloads
make[1]: Entering directory '/home/dortmann/src/git-org-mode/lisp'
rm -f org-version.el org-loaddefs.el org-version.elc org-loaddefs.elc 
org-install.elc

org-version: 9.5.5 (release_9.5.5-785-g86c463)
Loading /home/dortmann/src/git-org-mode/lisp/org-compat.el (source)...
Loading /home/dortmann/src/git-org-mode/mk/org-fixup.el (source)...
Package autoload is deprecated
org-loaddefs: 9.5.5 (release_9.5.5-785-g86c463)
Loading /home/dortmann/src/git-org-mode/lisp/org-compat.el (source)...
Loading /home/dortmann/src/git-org-mode/mk/org-fixup.el (source)...
Package autoload is deprecated
make[1]: Leaving directory '/home/dortmann/src/git-org-mode/lisp'
dortmann@ddo-linux:git-org-mode$

*==>> *But 'make clean' and then 'make' followed by 'make autoloads' 
fails.  I could not get around it by manipulating load-path further:


dortmann@ddo-linux:git-org-mode$ make autoloads
make -C lisp autoloads
make[1]: Entering directory '/home/dortmann/src/git-org-mode/lisp'
rm -f org-version.el org-loaddefs.el org-version.elc org-loaddefs.elc 
org-install.elc

org-version: 9.5.5 (release_9.5.5-785-g86c463)
Loading /home/dortmann/src/git-org-mode/lisp/org-compat.el (source)...
Warning (emacs): Org version mismatch.  Make sure that correct 
‘load-path’ is set early in init.el

This warning usually appears when a built-in Org version is loaded
prior to the more recent Org version.

Version mismatch is commonly encountered in the following situations:
1. Emacs is loaded using literate Org config and more recent Org
   version is loaded inside the file loaded by ‘org-babel-load-file’.
   ‘org-babel-load-file’ triggers the built-in Org version clashing
   the newer Org version attempted to be loaded later.

   It is recommended to move the Org loading code before the
   ‘org-babel-load-file’ call.

2. New Org version is loaded manually by setting ‘load-path’, but some
   other package depending on Org is loaded before the ‘load-path’ is
   configured.
   This "other package" is triggering built-in Org version, again
   causing the version mismatch.

   It is recommended to set ‘load-path’ as early in the config as
   possible.

3. New Org version is loaded using straight.el package manager and
   other package depending on Org is loaded before straight triggers
   loading of the newer Org version.

   It is recommended to put
    (straight-use-package ’org)
   early in the config.  Ideally, right after the straight.el
   bootstrap.  Moving ‘use-package’ :straight declaration may not be
   sufficient if the corresponding ‘use-package’ statement is
   deferring the loading.

Error: error ("Org version mismatch.  Make sure that correct ‘load-path’ 
is set early in init.el")
  mapbacktrace(#f(compiled-function (evald func args flags) #0xa578661cbaef144>))

  debug-early-backtrace()
  debug-early(error (error "Org version mismatch.  Make sure that 
correct ‘load-path’ is set early in init.el"))
  signal(error ("Org version mismatch.  Make sure that correct 
‘load-path’ is set early in init.el"))
  error("Org version mismatch.  Make sure that correct `load-path' is 
set early in init.el")
  byte-code("\300 \301\232\204\17\0\302\303!\210\304\305!\210\300\207" 
[org-git-version "release_9.5.5-785-g86c463" warn "Org version 
mismatch.  Make sure that correct `load-path' is set early in 
init.el\nThis warning usually appears when a built-in Org version is 
loaded\nprior to the more recent Org version.\n\nVersion mismatch is 
commonly encountered in the following situations:\n1. Emacs is loaded 
using literate Org config and more recent Org\n   version is loaded 
inside the file loaded by `org-babel-load-file'.\n   
`org-babel-load-file' triggers the built-in Org version clashing\n   the 
newer Org version attempted to be loaded later.\n\n   It is recommended 
to move the Org loading code before the\n   `org-babel-load-file' 
call.\n\n2. New Org version is loaded manually by setting `load-path', 
but some\n   other package depending on Org is loaded before the 
`load-path' is\n   configured.\n   This \"other package\" is triggering 
built-in Org version, again\n causing the version mismatch.\n\n   It is 
recommended to set `load-path' as early in the config as\n   
possible.\n\n3. New Org version is loaded using straight.el package 
manager and\n other package depending on Org is loaded before straight 
triggers\n   loading of the newer Org version.\n\n   It is recommended 
to put\n    (straight-use-package 'org)\n   early in the config.  
Ideally, right 

Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency

[Daniel Fleischer]

Karl Voit [2022-09-13 Tue 10:07] wrote:

> Is it only me who is thinking that a non-blocking cancelled checkbox
> state would be a good idea?

At first it makes sense, but we do have headlines and TODO keywords to
express different states, colors and even sets of states. This is just a
checklist construct. I think if I wanted to mark something as canceled
or not relevant I would do something like this:

- [ ] this is important.
- [X] +canceled+ this is not important.

or even strike through everything. I think it's consistent in terms of
statistics; you want the total number to represent what you wrote down
and what's left does not include the "canceled" tasks. 

-- 
Daniel Fleischer