org-goto bug

[Pan Xie]

Hello

Just found a minor issue about the org-goto interface. When I set 
`org-goto-auto-isearch' as `t', the number keys should also be part of 
isearch, not treated as "digit argument". However, the current version 
(9.7-pre) of OrgMode I am using treat the number keys as digit argument 
in auto isearch mode.


I also find the solution: just pass `t' as second argument to 
`suppress-keymap', to make all number keys unbound in the keymap:


#+begin_src elisp
;; org-goto.el
(defun org-goto--set-map ()
  "Set the keymap `org-goto'."
  (setq org-goto-map
    (let ((map (make-sparse-keymap)))
      (let ((cmds '(isearch-forward isearch-backward kill-ring-save 
set-mark-command

                mouse-drag-region universal-argument org-occur)))
    (dolist (cmd cmds)
      (substitute-key-definition cmd cmd map global-map)))
      (suppress-keymap map t) ;; < 
pass t as second argument to fix the issue

      (org-defkey map "\C-m" 'org-goto-ret)
      (org-defkey map [(return)] 'org-goto-ret)

#+end_src

The version of org-mode with the issue:

#+begin_src elisp
  (org-version nil t)
  ;;=> "Org mode version 9.7-pre (release_9.6.19-1208-g7360c6 @ 
/home/git/org-mode/lisp/)"

#+end_src

Re: [proof of concept] inline language blocks

[Suhail Singh]

Juan Manuel Macías  writes:

> As I already said, in my local branch I have both elements created,
> based on the same syntax:
>
> - language block: :lang{text}
>
> - special block {text}

Why not &:lang{text} (and/or &:lang[options]{text}) instead?  In fact,
it might help (in that it may reduce the need for escaping within the
"text") if the syntax was &:type{text} with "lang" being one of the
possible type (as opposed to the type being ":lang").

-- 
Suhail

Re: [proof of concept] inline-special-block

[Juan Manuel Macías]

Juan Manuel Macías writes:

> Syntax:
>
> &[optional parameters]{contents}

Correction:

[optional parameters]{contents}

Re: [proof of concept] inline language blocks

[Juan Manuel Macías]

Samuel Wales writes:

> for language feature, there are various options here which range from e.g.

> :fr{some text in French}
>
> being expressed as
>
> $[lang :fr "bonjour"]
>

To expand a little more... Another problem I see in your example is
nesting. In my proposal, the blocks can be nested:

:fr{text in French and :it{text in Italian}}

But I would find this difficult to read:

$[lang :fr "text in French and $[lang :it "text in italian"]"]

On the other hand, the structure that I have chosen is in part inspired
by the inline code block, which is the only case of "inline block" that
we have in Org.

Best regards,

Juan Manuel 

Re: [proof of concept] inline language blocks

[Samuel Wales]

yes as i said emphasis is convenient.

On 2/21/24, Juan Manuel Macías  wrote:
> Samuel Wales writes:
>
>> for language feature, there are various options here which range from
>> e.g.
>>
>> :fr{some text in French}
>>
>> being expressed as
>>
>> $[lang :fr "bonjour"]
>
> Thanks for your interesting comment. However, your example still seems
> too verbose to me. There are two elements that, in my opinion, get in
> the way: 'lang' and "bonjour" quotes. Imagine something like this for
> emphasis (mutatis mutandis):
>
> $[emphasis :italic "text in italic"]
>
> instead of
>
> /text in italic/.
>
> That simplicity is what I intend to look for with this type of elements
> inside the paragraph.
>
> Best regards,
>
> Juan Manuel
>
> --
> Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
> editorial y ortotipografía
>
>
>


-- 
The Kafka Pandemic

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

Re: [proof of concept] inline language blocks

[Juan Manuel Macías]

Samuel Wales writes:

> for language feature, there are various options here which range from e.g.
>
> :fr{some text in French}
>
> being expressed as
>
> $[lang :fr "bonjour"]

Thanks for your interesting comment. However, your example still seems
too verbose to me. There are two elements that, in my opinion, get in
the way: 'lang' and "bonjour" quotes. Imagine something like this for
emphasis (mutatis mutandis):

$[emphasis :italic "text in italic"]

instead of

/text in italic/.

That simplicity is what I intend to look for with this type of elements
inside the paragraph.

Best regards,

Juan Manuel 

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño 
editorial y ortotipografía

Re: [proof of concept] inline language blocks

[Samuel Wales]

at risk of being like a broken record [over many years]: i still like
cl lambda lists e.g. $[thing arg :kw value :kw value] or %(thing ...)
for allowing generality to basically all new syntax of most types,
extensibility, user-defined major ["thing"] and minor [":kw"] features
if desired to support, reduced parsing risk, ability to control
display and export and visibility and folding and other stuff like
locale or whatever, nestability, escaping/quoting, and familiar
defined syntax, all applicable to new features without having to
change anything.  also, you won't have to look up how to use it much
when you use a new feature.

i'm not expressing this as well as i have in unpublished posts or
previous posts.

i might be in the minority, and it was once said that it is too
verbose.  if so, i value desiderata like the above higher.

i feel org has proliferated different syntaxes and special cases a bit
too much.  it's hard to have to look up what's needed, detect errors
manually etc.  some of the more basic  things are good with special
syntax, such as emphasis and \\.  but we contend with invisible space,
variant quoting, 

there is a school of thought that more types of syntax are usually
good; in most cases, i do not agree with that school of thought.

it's a bit like the old conflict between lisp vs. the original perl.
i never agreed with larry wall on arguments like [paraphrased,
possibly not correctly] "english is not orthogonal; lisp is, which is
bad; perl is not orthogonal; it shouldn't be because english isn't [or
perhaps for the [unspecified] reasons english isn't]".  plenty of
human languages are orthogonal in places where english isn't, and i
believe they work well in those places because of, not in spite of,
that convenient orthogonality.  you can know how to get the transitive
if you have the intransitve, for example.  i say this despite being a
huge fan of english.


for language feature, there are various options here which range from e.g.

:fr{some text in French}

being expressed as

$[lang :fr "bonjour"]

which i think is pretty straightforward and not much more verbose,

to a more block style like this

$[lang :fr :start]
bonjour
$[lang :fr end]

and of course that "lang" can be replaced with any other new feature
we dream up, having nothing to do with languages.  all the
meta-features like parsing, quoting, invisibility, folding,
nestability, extensibility will already have been worked out, and will
apply to new features and sub-features.


On 2/21/24, Juan Manuel Macías  wrote:
> Ihor Radchenko writes:
>
>> Juan Manuel Macías  writes:
>>
 We need to finalize inline special block syntax first, and then talk
 about special cases like inline language markup you propose.
>>>
>>> As I already said, in my local branch I have both elements created,
>>> based on the same syntax:
>>>
>>> - language block: :lang{text}
>>>
>>> - special block {text}
>>>
>>> the latter would be exported, for example, to html as >> class="type">text or to LaTeX as \type{text}
>>>
>>> I like the syntax because it is minimalist and not verbose at all. That
>>> could serve as a basis (at least it is good to have a starting point,
>>> because otherwise everything will be diluted in discussions). Then we
>>> can start thinking about whether to add options and how to add them.
>>
>> We do not need to design the inline special block markup fully to
>> introduce it. However, we do need to make sure that whatever simple
>> version of inline markup we introduce does not prevent further planned
>> extensions.
>
> My proposed syntax could be:
>
> [options]{content}
>
>> My main concern is the possibility to introduce multi-argument markup.
>> Like @abbrev{EA}{example abbreviation}. This will be necessary to
>> achieve parity with Texinfo markup.
>> However, it is not yet clear about the best syntax to pass multiple
>> arguments.
>
> I imagine multiple arguments would depend on each backend, right?
> Because I don't quite see much sense in html, for example. However, it
> occurs to me to reuse content, and add some separator character:
>
> [options]{arg1::arg2::etc}
>
> or better:
>
> [options and aditional args]{content}
>
> to maintain a certain parallelism with the large blocks.
>
> --
> Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
> editorial y ortotipografía
>
>
>


-- 
The Kafka Pandemic

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

[proof of concept] inline-special-block (was: [proof of concept] inline language blocks)

[Juan Manuel Macías]

I am attaching a patch in case anyone wants to try this proposal. A
function for ox-latex is included.

Syntax:

&[optional parameters]{contents}

With this patch, something like {lorem ipsum dolor} is exported to
LaTeX as \foo{lorem ipsum dolor}.

Blocks can be nested, e.g.: {lorem ipsum {dolor}}.

Regarding the "optional parameters", there is nothing defined, although
I think they should be adapted to each backend. A possible use that
occurs to me:

[prelatex: [lorem] postlatex: {ipsum} html: style="color:red;"]{blah blah}

This should produce in LaTeX:

\foo[lorem]{blah blah}{ipsum}

and in HTML:

blah blah

Best regards,

Juan Manuel 

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño 
editorial y ortotipografía

>From 587e77feb1c4e6881d527d1fd3a6e541efb596d4 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Wed, 21 Feb 2024 20:44:58 +0100
Subject: [PATCH] org-element.el: New element: Inline Special Block (proof of
 concept).

* lisp/ox-latex.el (org-latex-inline-special-block): A possible
function for the LaTeX backend.
---
 lisp/org-element.el | 55 -
 lisp/ox-latex.el| 10 +
 2 files changed, 64 insertions(+), 1 deletion(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index 6691ea44e..2f9436df2 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -272,6 +272,8 @@ specially in `org-element--object-lex'.")
 			   "\\|"))
 		  ;; Objects starting with "@": export snippets.
 		  "@@"
+  ;; Objects starting with "&": inline-special-blocks.
+  "&"
 		  ;; Objects starting with "{": macro.
 		  "{{{"
 		  ;; Objects starting with "<" : timestamp
@@ -313,7 +315,7 @@ specially in `org-element--object-lex'.")
   "List of recursive element types aka Greater Elements.")
 
 (defconst org-element-all-objects
-  '(bold citation citation-reference code entity export-snippet
+  '(bold citation citation-reference code entity export-snippet inline-special-block
 	 footnote-reference inline-babel-call inline-src-block italic line-break
 	 latex-fragment link macro radio-target statistics-cookie strike-through
 	 subscript superscript table-cell target timestamp underline verbatim)
@@ -440,6 +442,7 @@ Don't modify it, set `org-element-affiliated-keywords' instead.")
   ;; Ignore inline babel call and inline source block as formulas
   ;; are possible.  Also ignore line breaks and statistics
   ;; cookies.
+  (inline-special-block ,@standard-set)
   (table-cell citation export-snippet footnote-reference link macro
   radio-target target timestamp ,@minimal-set)
   (table-row table-cell)
@@ -3535,6 +3538,54 @@ Assume point is at the beginning of the entity."
 	  (org-element-property :name entity)
 	  (when (org-element-property :use-brackets-p entity) "{}")))
 
+ inline special block
+
+(defun org-element-inline-special-block-parser ()
+  "Parse inline special block at point.
+
+When at an inline special block, return a new syntax node of
+`inline-special-block' type containing `:begin', `:end', `:type',
+`:parameters', `: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) 1))
+  (let* ((begin (match-beginning 0))
+ (parameters
+  (let ((p (org-element--parse-paired-brackets ?\[)))
+(and (org-string-nw-p p)
+ (replace-regexp-in-string "\n[ \t]*" " " (org-trim p)
+ (contents-begin (when (looking-at-p "{") (+ (point) 1)))
+ (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-special-block
+   (list :type type
+ :parameters parameters
+ :contents-begin contents-begin
+ :contents-end contents-end
+ :begin begin
+ :end end
+ :post-blank post-blank)))
+
+(defun org-element-inline-special-block-interpreter (inline-special-block contents)
+  "Interpret INLINE SPECIAL BLOCK object as Org syntax."
+  (let ((type (org-element-property :type inline-special-block))
+(opts (org-element-property :parameters inline-special-block)))
+(format "&%s%s{%s}"
+type
+(if opts (format "[%s]" opts) "")
+contents)))
 
  Export Snippet
 
@@ -5260,6 +5311,8 @@ to an appropriate container (e.g., a paragraph)."
 			 

Re: [PATCH] org-babel-demarcate-block: split using element API

[gerard . vermeulen]

On 21.02.2024 10:40, Ihor Radchenko wrote:

gerard.vermeu...@posteo.net writes:


Still failing on my side (when running tests non-interactively from
command line). To fix the problem, please use the approach from
`test-org-list/indent-item':

(transient-mark-mode 1)
(push-mark (point) t t)

Instead of (set-mark-command nil)


Gerard, may I know if you had a chance to look into my comments?


I think that I have addressed this particular comment.


Not really.
In any case, see the attached updated patch with my suggestion
incorporated.

Indeed, I did not address it.  I also tried out your suggestion out this 
morning

and saw that it makes "make test" pass.



[...]



Secondly, I see (saw) sometimes Org emitting warnings with backtraces
starting from my patch.  I think the warning may be due either to a
mistake
on my side or a bug in Org, but I am not sure.


May you please provide more details?


I fail to reproduce the warnings, but I think that I have seen (rx ... )
type warnings in the  Emacs warnings buffer with the patched
org-babel-demarcate-block as backtrace entry point.  I did not capture
those at the time, because I thought I could trigger those warnings 
easily

which is not the case.  This is Emacs-30.0.50.
I am sorry I cannot give more details.

How to proceed? Of course, I agree with your version of the patch
although I had started to remove some of the superfluous scaffolding
to know where point and mark are.

Regards -- Gerard

Change in Org Capture target parsing

[Derek Chen-Becker]

Hi,

I started getting an error after updating to the latest commit on main:

Invalid capture target specification: (file+headline org-default-notes-file
"Tasks")

I bisected it down to 0a58a53edac955381266e49bd68d1140fbece33e, but I can't
tell from the commit what's wrong with my definition or how to fix it. I
found this thread in the mailing list, but it doesn't help me shed light on
what I'm doing wrong:

https://lists.gnu.org/archive/html/emacs-orgmode/2024-02/msg00153.html

Is it because I'm using the variable "org-default-notes-file" and not a
string? If that's the case then it's probably easy for me to fix in my
config, but I wanted to check first.

Thanks,

Derek

-- 
+---+
| Derek Chen-Becker |
| GPG Key available at https://keybase.io/dchenbecker and   |
| https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
+---+

Re: Asynchronous blocks for everything (was Re: [BUG] Unexpected result when evaluating python src block asynchronously [9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ /home/yantar92/.emacs.d/straight/b

[Bruno Barbier]

Hi Ihor,

Ihor Radchenko  writes:

>
> Thanks for the code!
> It is a lot more that I expected.

Note that only the first 5 patchs are real patchs.  The remaining things
are just a demo how it could be used.  The current async (ob-comint)
depends on writing UUIDs in org files, and, that's why I couldn't use it
as a demo.  I'm thinking about dropping the patch:

   'ob-core async: Add org-babel--async tools [2/5]'

and just provide an other new keyword (feedbacks-with) so that anybody
may plug its own feedback process.

> I have many questions ;)

Thanks! They are welcome :-)


>> The new API itself is more about how to wait for and display one block
>> result.  So, it's not really aware of sessions.
>
> I think that it is important to think about sessions. For non-sessions,
> we may execute the code in parallel, disregarding already running
> execution. In contrast, for sessions, we need to maintain some queue and
> wait until previous execution finishes before running next (if multiple
> session blocks are executed in quick succession).

I agree.  My proposed patch leaves this open to further work.

My proposed patch allows to have one way, in ob-core, to display
progress of asynchronous executions: like not started, 10%, success,
failed; and a way to plug in asynchronous executions in ob-core.

I've included some demo code just to show how that API could be used.


> It may also be necessary to provide an UI listing the queued and running
> execution. Users should be able to stop "stale" processes if they are
> defunc (consider infinite loop).

That looks nice but that may be too limiting.  Like it will probably forbid
to execute something asynchronously using elisp threads.  Anyway, that
outside the intended scope of my set of patchs.


> What is more important is when users, for example, remove the whole
> subtree containing the place where the execution result is to be
> inserted. Or when users perform edits at or around that place where the
> result is to be inserted. Or consider subtree with pending result
> refiled elsewhere (different file or different place in the same file);
> or archived.

My patch definitely needs to address those, even if only by raising an
error.

> Or consider user running an src block, quickly editing it, and then
> running again. What should we do then? Should we stop the first running
> process?

To keep things simple and generic, I would just forbid the user to
reschedule the task until the previous outcome is available.


> I have several general questions:
>
> - what if append/prepend to result asynchronously?

You mean if org is executing several times the same code concurrently?
I think we should forbid it.

> - what if we replace the result, call async evaluation two times, and they 
> arrive in opposite order (first called is calculated after the second)?

"One execution at a given time" will solve this too :-)

> - on failure, Org babel sometimes uses ~org-babel-eval-error-notify~. How 
> will it interact with asynchronous evaluation? What if we have multiple 
> simultaneously arriving error notifications?

In the asynchronous case, I've decided to leave the overlay in place
in case of errors, with the error description.  Clicking on that error
pops up the same kind of popups as in the synchronous case.  You can
give it a try using examples of errors my demo file:

   scratch/bba-ob-core-async/my-async-tests.org

(Please use the updated set of patchs that I've sent today, else, you
will have to fix the required libraries).


> Note that we already have a WIP an asynchronous API in the works.
> Check out `org-async-call' in
> https://code.tecosaur.net/tec/org-mode/src/branch/dev/lisp/org-macs.el#L377
> If possible, we should reuse it.

Thanks. I will have a look at it.


Bruno

Re: interaction of fontified calendar entries and org-read-date

[John Kitchin]

Awesome work! Thanks for tracking that down!

On Wed, Feb 21, 2024 at 6:17 AM Ihor Radchenko  wrote:

> John Kitchin  writes:
>
> > However, if I edebug `calendar-make-temp-face' and step through each
> line,
> > then it works the same as using a face. And, after that it seems to work
> > most of the time.
>
> It turned out that the problem is caused by interaction between Org
> mode's overlay and calendar.el's overlay. They have the same priority,
> so the order they are applied depends on subtle details of the code and
> on when redisplay occurs.
> That's why edebug yielded different results.
>
> See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=69271
>
> I fixed this subtle issue on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=67d937248
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


-- 
John

---
Professor John Kitchin (he/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
https://kitchingroup.cheme.cmu.edu
https://pointbreezepubs.gumroad.com/ pycse bookstore

Re: Asynchronous blocks for everything (was Re: [BUG] Unexpected result when evaluating python src block asynchronously [9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ /home/yantar92/.emacs.d/straight/b

[Bruno Barbier]

Hi Jack,

Jack Kamm  writes:

> Bruno Barbier  writes:
>
>> I'm not using it with official org backends (yet).  I'm using it with
>> several custom backends that I'm working on.  One of the backend
>> delegate the block executions to emacs subprocesses: so I have a kind of
>> asynchronous executions for free for any language, including elisp
>> itself.
>
> For sessions, wouldn't running in a subprocess prevent the user from
> directly interacting with the REPL outside of Org?

Good point. The REPL should be created in the same subprocess; the
REPL display and interaction must happen in the user main emacs.  If
the REPL is based on comint, it should be relatively easy to
implement.


> If so, that's a problem. Org-babel sessions need to play nicely with
> inferior Python, inferior ESS, and other interactive comint modes.

With this solution, the user and the REPL/execution will be in
separate processes; so there will be disavantages.  For basic
interactions, mostly based on text input/output, it should work well.


>> So, here we go.  You'll find attach a set of patchs.  It works for me with
>> Emacsc 30.50 and 9.7-pre (from today).
>
> I suggest to keep these patches on a public branch somewhere, see:
> https://orgmode.org/worg/org-contribute.html#patches
>
>   "When discussing important changes, it is sometimes not so useful to
>   send long and/or numerous patches.
>   
>   In this case, you can maintain your changes on a public branch of a
>   public clone of Org and send a link to the diff between your changes
>   and the latest Org commit that sits in your clone."

Good point.  I'll switch to such a solution as soon as possible.


> I tried running your example on emacs29 using
>
>   emacs -q -L  /path/to/org-mode/lisp my-async-tests.org
>
> but it fails with the error below. Also "make" gives a bunch of
> compilation warnings (which I've put at the bottom).
> ...

My bad: I should have compiled the demo code in a standalone emacs.
I forgot to require some libraries: cl-lib and org-id.

I've now tested with your command line (thanks).  It should now
work. Sorry about that.


> Finally here are the warnings when running "make":
I should have fixed everything; no more (new) warnings.
Thanks!


Please find attached the new set of patchs.  I'll switch to using a
clone and a branch soon, in case if you prefer to wait.

Thanks again!


Bruno



>From f67829454ac0d3cd142da1bd0006efa37acce588 Mon Sep 17 00:00:00 2001
From: Bruno BARBIER 
Date: Fri, 16 Feb 2024 14:31:36 +0100
Subject: [PATCH 1/8] ob-core async: Add faces [1/5]

lisp/org-faces.el (org-async-scheduled, org-async-pending,
org-async-failure): new faces
---
 lisp/org-faces.el | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/lisp/org-faces.el b/lisp/org-faces.el
index 0e20de51a..5a8a8fd51 100644
--- a/lisp/org-faces.el
+++ b/lisp/org-faces.el
@@ -736,6 +736,24 @@ (defface org-mode-line-clock-overrun
   "Face used for clock display for overrun tasks in mode line."
   :group 'org-faces)
 
+(defface org-async-scheduled '((t :inherit org-tag :background "gray"))
+  "Face for babel results for code blocks that are scheduled for execution."
+  :group 'org-faces
+  :version "27.2"
+  :package-version '(Org . "9.5"))
+
+(defface org-async-pending '((t :inherit org-checkbox :background "dark orange"))
+  "Face for babel results for code blocks that are running."
+  :group 'org-faces
+  :version "27.2"
+  :package-version '(Org . "9.5"))
+
+(defface org-async-failure '((t :inherit org-warning))
+  "Face for babel results for code blocks that have failed."
+  :group 'org-faces
+  :version "27.2"
+  :package-version '(Org . "9.5"))
+
 (provide 'org-faces)
 
 ;;; org-faces.el ends here
-- 
2.43.0

>From 9f135bd5e8e153323bed5a3274851fa78f246b83 Mon Sep 17 00:00:00 2001
From: Bruno BARBIER 
Date: Fri, 16 Feb 2024 14:32:00 +0100
Subject: [PATCH 2/8] ob-core async: Add org-babel--async tools [2/5]

---
 lisp/ob-core.el | 213 
 1 file changed, 213 insertions(+)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index bfeac257b..d98626fe8 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -792,6 +792,219 @@ (defun org-babel-session-buffer ( info)
 (when (org-babel-comint-buffer-livep buffer-name)
   buffer-name)))
 
+(defun org-babel--async-status-face (status)
+  (pcase status
+(:scheduled 'org-async-scheduled)
+(:pending   'org-async-pending)
+(:failure   'org-async-failure)
+(:success   nil)
+(_ (error "Not a status"))
+))
+
+(defun org-babel--async-make-overlay (beg end)
+  "Create an overlay between positions BEG and END and return it."
+  (let ((overlay (make-overlay beg end))
+(read-only
+	 (list
+	  (lambda ( _)
+	(user-error
+	 "Cannot modify an area being updated"
+)
+(cl-flet ((make-read-only
+   (ovl)
+   (overlay-put ovl 'modification-hooks read-only)
+   (overlay-put ovl 

Re: interaction of fontified calendar entries and org-read-date

[Ihor Radchenko]

John Kitchin  writes:

> However, if I edebug `calendar-make-temp-face' and step through each line,
> then it works the same as using a face. And, after that it seems to work
> most of the time.

It turned out that the problem is caused by interaction between Org
mode's overlay and calendar.el's overlay. They have the same priority,
so the order they are applied depends on subtle details of the code and
on when redisplay occurs.
That's why edebug yielded different results.

See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=69271

I fixed this subtle issue on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=67d937248

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

Re: [proof of concept] inline language blocks

[Ihor Radchenko]

Juan Manuel Macías  writes:

> Ihor Radchenko writes:
>> This is a good idea, although it would be better to make this new markup
>> element within the framework of more general inline special block we
>> discussed in the past: 
>> https://list.orgmode.org/orgmode/87a6b8pbhg@posteo.net/
>
> Fun fact: the local branch is called inline-special-block, because I
> originally had that idea in mind when I created it. Then, halfway
> through, I doubted whether it wouldn't be better to have a specific
> inline language selector, whose use would be as direct as an emphasis
> mark. So in the branch there is also a "proto"-inline-special-block with
> similar syntax: {}.
>
> I opted for the -language-block version because, as I said, its use is
> very 'direct' and covers a common need to segment multilingual text
> within the paragraph.

My main point is that we should use the same syntax with inline special
blocks. Similar to how #+begin_verse uses the same syntax as special
blocks.

We need to finalize inline special block syntax first, and then talk
about special cases like inline language markup you propose.

> I think at the time we also discussed whether or not it would be a good
> idea to provide the inline special blocks with options and attributes,
> like their older brothers. And how to do it. My biggest concern here is
> the (let's say) latexification of the paragraph. I mean, one of the
> great things about Org versus heavier markup like LaTeX is that when org
> wants to be verbose it uses dedicated lines, but usually keeps the
> paragraphs clean and readable. I think that any element inside the
> paragraph should tend to be as "transparent" as simple emphasis marks.
>
> I remember that there was also discussion about puting the options
> outside the paragraph, using some type of identifier. It doesn't seem
> like a bad idea to me, but I think it adds an extra complication for the
> user. It would be very tedious for me to write like this (even more
> tedious than writing in LaTeX).

I still believe that we should /allow/ options inside inline block-type
markup. This is often necessary in practice. For example, I recommend
studying
https://en.wikipedia.org/wiki/Help:Wikitext#Templates_and_transcluding_pages
and how they had to use ugly |... extensions to provide options.

But it does not mean that users /have to/ use these options. In fact, we
might design the inline language blocks to ignore options.

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

Re: [BUG] beamer export

[Ihor Radchenko]

Leo Butler  writes:

> Thanks for your comments.
>
> I think the attached patch addresses each of your points. It's not clear
> to me what you mean by "link(ing) this org-lint warning to the
> `org-beamer-frame-environment' docstring", but I have expanded the
> warning include mention of this variable.

Thanks!
Applied, onto main; with amendments:
- adjusted the commit message, removing the mention of
  `org-beamer--frame-environments'.
- fixed typos using incorrect variable name
  `org-beamer--frame-environment'.
- added etc/ORG-NEWS entry
- fixed compiler warnings
- re-worded org-lint warning, suggesting customizing
  `org-beamer-frame-environment'
- added :package-description and :safe keywords to defcustom

Fixed.

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

Re: [proof of concept] inline language blocks

[Ihor Radchenko]

Juan Manuel Macías  writes:

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

This is a good idea, although it would be better to make this new markup
element within the framework of more general inline special block we
discussed in the past: 
https://list.orgmode.org/orgmode/87a6b8pbhg@posteo.net/

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

Re: Warn about shell-expansion in the docstring of org-latex-to-html-convert-command

[Max Nikulin]

On 19/02/2024 02:36, Martin Edström wrote:

+Since this is a shell-command, remember to use single-quotes
+around \\='%i\\=', not double-quotes!  Else a math fragment such
+as \"$y = 200$\" gets butchered into only \" = 200\"."


I am afraid, the code, not the docstring must be fixed. I have not tried 
it, but I expect an issue with


Test \(f' = df/dx\)

So `shell-quote-argument' is necessary and quotes around %i must be 
stripped similar to %s in mailcap entries in `org-open-file'.


Notice that dollar-math $x = y$ is not recommended and considered as 
obsolete syntax. Use \(x = y\) or \[x = y\] (the latter for display math).

Re: [proof of concept] inline language blocks

[Juan Manuel Macías]

Ihor Radchenko writes:

> Juan Manuel Macías  writes:
>
>> Ihor Radchenko writes:
>>> This is a good idea, although it would be better to make this new markup
>>> element within the framework of more general inline special block we
>>> discussed in the past: 
>>> https://list.orgmode.org/orgmode/87a6b8pbhg@posteo.net/
>>
>> Fun fact: the local branch is called inline-special-block, because I
>> originally had that idea in mind when I created it. Then, halfway
>> through, I doubted whether it wouldn't be better to have a specific
>> inline language selector, whose use would be as direct as an emphasis
>> mark. So in the branch there is also a "proto"-inline-special-block with
>> similar syntax: {}.
>>
>> I opted for the -language-block version because, as I said, its use is
>> very 'direct' and covers a common need to segment multilingual text
>> within the paragraph.
>
> My main point is that we should use the same syntax with inline special
> blocks. Similar to how #+begin_verse uses the same syntax as special
> blocks.
>
> We need to finalize inline special block syntax first, and then talk
> about special cases like inline language markup you propose.

As I already said, in my local branch I have both elements created,
based on the same syntax:

- language block: :lang{text}

- special block {text}

the latter would be exported, for example, to html as text or to LaTeX as \type{text}

I like the syntax because it is minimalist and not verbose at all. That
could serve as a basis (at least it is good to have a starting point,
because otherwise everything will be diluted in discussions). Then we
can start thinking about whether to add options and how to add them.

>> I think at the time we also discussed whether or not it would be a good
>> idea to provide the inline special blocks with options and attributes,
>> like their older brothers. And how to do it. My biggest concern here is
>> the (let's say) latexification of the paragraph. I mean, one of the
>> great things about Org versus heavier markup like LaTeX is that when org
>> wants to be verbose it uses dedicated lines, but usually keeps the
>> paragraphs clean and readable. I think that any element inside the
>> paragraph should tend to be as "transparent" as simple emphasis marks.
>>
>> I remember that there was also discussion about puting the options
>> outside the paragraph, using some type of identifier. It doesn't seem
>> like a bad idea to me, but I think it adds an extra complication for the
>> user. It would be very tedious for me to write like this (even more
>> tedious than writing in LaTeX).
>
> I still believe that we should /allow/ options inside inline block-type
> markup. This is often necessary in practice. For example, I recommend
> studying
> https://en.wikipedia.org/wiki/Help:Wikitext#Templates_and_transcluding_pages
> and how they had to use ugly |... extensions to provide options.
>
> But it does not mean that users /have to/ use these options. In fact, we
> might design the inline language blocks to ignore options.

The wiki language is for a specific purpose, and I wouldn't consider it
a lightweight markup language, although it is certainly less thick than
html.

Actually I'm just expressing my concerns and doubts, I'm not objecting
to anything. I remember reading in the pandoc issues, a long time ago,
similar discussions every time they talked about extending the markup. I
don't know if it's a good idea to stick to a certain point to preserve
the nature of a lightweight markup language and accept certain intrinsic
limitations instead of providing options that probably have very little
use or can be resolved by some export filter. I don't have a definite
opinion, I'm just raising my doubts. Although I really value simplicity
and minimalism.


-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño 
editorial y ortotipografía

Re: [proof of concept] inline language blocks

[Juan Manuel Macías]

Ihor Radchenko writes:

> Juan Manuel Macías  writes:
>
>> 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]]}
>
> This is a good idea, although it would be better to make this new markup
> element within the framework of more general inline special block we
> discussed in the past: 
> https://list.orgmode.org/orgmode/87a6b8pbhg@posteo.net/

Fun fact: the local branch is called inline-special-block, because I
originally had that idea in mind when I created it. Then, halfway
through, I doubted whether it wouldn't be better to have a specific
inline language selector, whose use would be as direct as an emphasis
mark. So in the branch there is also a "proto"-inline-special-block with
similar syntax: {}.

I opted for the -language-block version because, as I said, its use is
very 'direct' and covers a common need to segment multilingual text
within the paragraph.

I think at the time we also discussed whether or not it would be a good
idea to provide the inline special blocks with options and attributes,
like their older brothers. And how to do it. My biggest concern here is
the (let's say) latexification of the paragraph. I mean, one of the
great things about Org versus heavier markup like LaTeX is that when org
wants to be verbose it uses dedicated lines, but usually keeps the
paragraphs clean and readable. I think that any element inside the
paragraph should tend to be as "transparent" as simple emphasis marks.

I remember that there was also discussion about puting the options
outside the paragraph, using some type of identifier. It doesn't seem
like a bad idea to me, but I think it adds an extra complication for the
user. It would be very tedious for me to write like this (even more
tedious than writing in LaTeX).

Best regards,

-- 
Juan Manuel Macías 

Re: [proof of concept] inline language blocks

[Ihor Radchenko]

Juan Manuel Macías  writes:

>> We need to finalize inline special block syntax first, and then talk
>> about special cases like inline language markup you propose.
>
> As I already said, in my local branch I have both elements created,
> based on the same syntax:
>
> - language block: :lang{text}
>
> - special block {text}
>
> the latter would be exported, for example, to html as  class="type">text or to LaTeX as \type{text}
>
> I like the syntax because it is minimalist and not verbose at all. That
> could serve as a basis (at least it is good to have a starting point,
> because otherwise everything will be diluted in discussions). Then we
> can start thinking about whether to add options and how to add them.

We do not need to design the inline special block markup fully to
introduce it. However, we do need to make sure that whatever simple
version of inline markup we introduce does not prevent further planned
extensions.

My main concern is the possibility to introduce multi-argument markup.
Like @abbrev{EA}{example abbreviation}. This will be necessary to
achieve parity with Texinfo markup.
However, it is not yet clear about the best syntax to pass multiple
arguments.

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

Re: Asynchronous blocks for everything (was Re: [BUG] Unexpected result when evaluating python src block asynchronously [9.7-pre (release_9.6.17-1131-gc9ed03.dirty @ /home/yantar92/.emacs.d/straight/b

[Bruno Barbier]

Hi Matt,

Thanks for your answer.

Matt  writes:

> ...
> If I understand correctly, there are several independent topics the code 
> addresses:
>
> | topic| manner addressed   |
> |--+|
> | execution status | using overlays to communicate execution status |
> | locating results | using overlays to locate results   |
> | blocking | making all execution asynchronous  |
> |--+|
>
> I suggest these be discussed in separate threads.

Actually my patch is only about reporting execution status and
inserting results, in a generic way, in ob-core.  I provided some demo
code on top of them, just to show how it could be used.

Sorry about the confusion.  

> ...
>
> Since this thread is dedicated to blocking, let me share my thoughts on that 
> subject.

I guess I should start a new thread then :)


> ...
>
>
> Executing a shell block requires starting a 
> [[https://www.gnu.org/software/emacs/manual/html_node/elisp/Processes.html][process]].
>
> Processes are synchronous or asynchronous.
>
> Three primitives exist in Emacs for making processes:
>
> 1. make-process (asynchronous)
> 2. call-process (synchronous)
> 3. call-process-region (synchronous)
>
> There exist several convenience wrappers for these.  AFAIK, everything 
> reduces to these three primitives.  For example, =async-shell-command= runs 
> =call-process= and prevents blocking by appending a "&" to the command which 
> tells the shell to run the command in the background and return control to 
> the terminal.  This background-foreground distinction is called "job control".
>

> Output from a process typically goes to a buffer.  This may be changed and 
> instead handle output with a filter function.  =call-process= has an option 
> to directly send output to a file.
>

I've reached the same conclusion. As I wanted one simple
implementation, I was thinking about using 'make-process', but, as we
have to deal with the output manually and use a process sentinel, and,
as offering a REPL to the user is nice, my personal pick is to use a
plain shell with comint.

> Subprocesses inherent the =default-directory= and the environment from Emacs. 
>  The environment may be changed using =process-environment=.
>

One wonderful thing about using =default-directory= is that, if done
right, tramp will automatically handle executions on one or more remote
computers.

> There are two types of asynchronous connections: "pty" ("pseudoterminal") and 
> "pipe".  The main difference is that "pty" provides a terminal-like 
> connection which allows for things like job control (=C-c=, =C-z=, etc.).

I'm personally ignoring the difference between pty and pipe: as I
don't use the terminal features, it doesn't really matter to me.


> ...
> I'm not sure how we could make a persistent, synchronous process.  
> Persistence is achieved, currently, by a process buffer.  Is there another 
> way persistence may be achieved?

If I understand correcly, "persistent" here means to preserve some
state between executions.  They are definitely other way to preserve
and provide a state.

If you focus on processes only, it's probably OK. But, if you use
threads or some other kinds of asynchronicity, that might be too
limiting to require a buffer and a process.


> Of course, this ignores whether a persistent, synchronous process is even 
> desirable.  Given reliable asynchronous execution with persistence, I can't 
> think of reason why someone would prefer a blocking operation.
>

I'm not so sure.  If the success of an execution is really important,
and, intrinsically unreliable (like a network connection), and, it
only takes a few seconds, I'll probably choose synchronous execution,
just to see that everything is OK, before moving to my next task.



> ...
> Attached are two files, ob-blub.el and ob-blub-test.org.  Download both to 
> the same directory.  Run the first block in ob-blub-test.org.  This imports 
> ob-blub, loads it into Babel, and sets up blub to be whatever 
> =shell-file-name= is (for example, bash).  If you want to try Python or Ruby, 
> comment out the shell configuration, uncomment the Python or Ruby 
> implementations, and evaluate the block again.  Hopefully ob-blub.el is 
> documented sufficiently for you to experiment.

Thanks for sharing.  I didn't have time to try it yet.  But it looks
like you could use the 'execute-with' keyword that my patchs provide.
That way, you may redirect evaluation to use your "blub"
implementation, and still use the real language name for your code
blocks (that way, org knows how to fontify them, edit them, etc).  And, you
will not have to manually modify and reevaluate your elisp when
switching languages.

> The blub implementation has the same shortcomings, at least for shells, as 
> the current shell implementation.  It has a few ideas, 

Re: [proof of concept] inline language blocks

[Juan Manuel Macías]

Ihor Radchenko writes:

> Juan Manuel Macías  writes:
>
>>> We need to finalize inline special block syntax first, and then talk
>>> about special cases like inline language markup you propose.
>>
>> As I already said, in my local branch I have both elements created,
>> based on the same syntax:
>>
>> - language block: :lang{text}
>>
>> - special block {text}
>>
>> the latter would be exported, for example, to html as > class="type">text or to LaTeX as \type{text}
>>
>> I like the syntax because it is minimalist and not verbose at all. That
>> could serve as a basis (at least it is good to have a starting point,
>> because otherwise everything will be diluted in discussions). Then we
>> can start thinking about whether to add options and how to add them.
>
> We do not need to design the inline special block markup fully to
> introduce it. However, we do need to make sure that whatever simple
> version of inline markup we introduce does not prevent further planned
> extensions.

My proposed syntax could be:

[options]{content}

> My main concern is the possibility to introduce multi-argument markup.
> Like @abbrev{EA}{example abbreviation}. This will be necessary to
> achieve parity with Texinfo markup.
> However, it is not yet clear about the best syntax to pass multiple
> arguments.

I imagine multiple arguments would depend on each backend, right?
Because I don't quite see much sense in html, for example. However, it
occurs to me to reuse content, and add some separator character:

[options]{arg1::arg2::etc}

or better:

[options and aditional args]{content}

to maintain a certain parallelism with the large blocks.

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño 
editorial y ortotipografía

Re: [PATCH] org-babel-demarcate-block: split using element API

[Ihor Radchenko]

gerard.vermeu...@posteo.net writes:

>>> Still failing on my side (when running tests non-interactively from
>>> command line). To fix the problem, please use the approach from
>>> `test-org-list/indent-item':
>>> 
>>> (transient-mark-mode 1)
>>> (push-mark (point) t t)
>>> 
>>> Instead of (set-mark-command nil)
>> 
>> Gerard, may I know if you had a chance to look into my comments?
>
> I think that I have addressed this particular comment.

Not really.
In any case, see the attached updated patch with my suggestion
incorporated.

> However, I am confused by your comments concerning this example
> #+begin_src emacs-lisp
>'(1 2 3)
>'(1 2 3)
> #+end_src
> since it breaks my patch as well as main in the sense that such examples
> can generate three blocks with invalid code.
> I think there is in general no way to protect a user against bad 
> selections
> for splitting by demarcation.

Fair.

> Secondly, I see (saw) sometimes Org emitting warnings with backtraces
> starting from my patch.  I think the warning may be due either to a 
> mistake
> on my side or a bug in Org, but I am not sure.

May you please provide more details?

>From dc71a916c829e979c0728f95bfefe54b1cfa3887 Mon Sep 17 00:00:00 2001
Message-ID: 
From: Gerard Vermeulen 
Date: Thu, 11 Jan 2024 20:20:01 +0100
Subject: [PATCH] org-babel-demarcate-block: split using element API

* lisp/ob-babel.el (org-babel-demarcate-block): Modify a copy
of (org-element-at-point) to replace the old source block with 2 or 3
new modified copies by means of `org-element-interpret-data'.  The 1st
source block contains the text from the body of the old block before
point or region, the 2nd block contains the body text after point or
body text within region, and in case of region, the 3rd block contains
the text after region.  The caption and the name are deleted from the
1 or 2 blocks below the upper source block.  Indent all blocks
immediately after insertion (pitfall, see link).  Use :post-blank to
control white lines between inserted blocks.  Leave point at the last
inserted block.  Take care to preserve (current-column) of text
after point (and mark) in the 2nd (and 3rd) block.  Trying to split
when point or region is not within the body of the old source block
raises an user-error.
* lisp/ob-babel (org-get-src-block-info): add the "within blank lines
after a source block" condition to the doc-string to match it with the
doc-string of and a comment in `org-babel-demarcate-block'.
* testing/lisp/test-ob.el (test-ob/demarcate-block-split-duplication)
(test-ob/demarcate-block-split-prefix-point)
(test-ob/demarcate-block-split-prefix-region)
(test-ob/demarcate-block-split-user-errors)
(test-ob/demarcate-block-wrap-point)
(test-ob/demarcate-block-wrap-region): New tests to check test cases
that broke earlier versions of this patch.

Link: https://list.orgmode.org/87ply6nyue.fsf@localhost/
---
 lisp/ob-core.el |  94 +++-
 testing/lisp/test-ob.el | 241 
 2 files changed, 307 insertions(+), 28 deletions(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index bfeac257b..e3110a3f1 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -73,10 +73,12 @@ (declare-function org-element-contents-end "org-element" (node))
 (declare-function org-element-parent "org-element-ast" (node))
 (declare-function org-element-type "org-element-ast" (node  anonymous))
 (declare-function org-element-type-p "org-element-ast" (node  types))
+(declare-function org-element-interpret-data "org-element" (data))
 (declare-function org-entry-get "org" (pom property  inherit literal-nil))
 (declare-function org-escape-code-in-region "org-src" (beg end))
 (declare-function org-forward-heading-same-level "org" (arg  invisible-ok))
 (declare-function org-in-commented-heading-p "org" ( no-inheritance))
+(declare-function org-indent-block "org" ())
 (declare-function org-indent-line "org" ())
 (declare-function org-list-get-list-end "org-list" (item struct prevs))
 (declare-function org-list-prevs-alist "org-list" (struct))
@@ -700,8 +702,9 @@ (defun org-babel-get-src-block-info ( no-eval datum)
 argument DATUM is provided, extract information from that parsed
 object instead.
 
-Return nil if point is not on a source block.  Otherwise, return
-a list with the following pattern:
+Return nil if point is not on a source block (blank lines after a
+source block are considered a part of that source block).
+Otherwise, return a list with the following pattern:
 
   (language body arguments switches name start coderef)"
   (let* ((datum (or datum (org-element-context)))
@@ -2075,7 +2078,7 @@ (defun org-babel-mark-block ()
   (goto-char (match-beginning 5)
 
 (defun org-babel-demarcate-block ( arg)
-  "Wrap or split the code in the region or on the point.
+  "Wrap or split the code in an active region or at point.
 
 With prefix argument ARG, also create a new heading at point.
 
@@ -2085,41 +2088,76 @@ (defun