[BUG] after execute +org-realign-table-maybe-h may move point [9.6 (9.6-??-bed47b4 @ c:/Users/yhht/.emacs.d/.local/straight/build-28.2/org/)]

[赵一宇]

+org-realign-table-maybe-h function definition is at the end. 

Instead of using save-excursion macro, it saves current point to a var,
and restore the point after execute org-table-align.
That would cause point move visually. Although the (point) value not changed, 
org-table-align function shall insert  spaces in front of the point. 
Don't know if it has already fixed, or there are some other concerns.
(defun +org-realign-table-maybe-h ()
  "Auto-align table under cursor."
  (when (and org-table-automatic-realign (org-at-table-p) 
org-table-may-need-update)
(let ((pt (point))
  (inhibit-message t))
  (if org-table-may-need-update (org-table-align))
  (goto-char pt
Emacs : GNU Emacs 28.2 (build 2, x86_64-w64-mingw32)
 of 2022-09-13
Package: Org mode version 9.6 (9.6-??-bed47b4 )

Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Jean Louis]

* Ihor Radchenko  [2023-03-08 16:29]:
> > The UTC offset is property of the time zone. The future time zone
> > definition will know what is it's UTC offset.
> 
> UTC offset is indeed a property of the time zone.
> However, UTC offset may be a subject of change in some time zones.

Yes, and that is what I was stating. What we were arguing about is
rather notation.

> I am referring to "fixed" offsets to be specified by users and will
> never change. 

"Fixed" offset is IMHO wrong designation. What you want to say is "UTC
time". Don't use any offsets with UTC time as not to confuse
people. Use local time representation of UTC timestamps. For UTC
timestamp there is no problem to be in future or in past.

> These offsets are convenient to protect timestamp from regulatory
> changes in time zones.

UTC time is convenient.

But if you intend to represent time with time stamps, fixing some "UTC
offsets" to get "UTC time" representation, I do not see how it is
convenient for anybody.

> Effectively, they are simply another, sometimes convenient, way to
> represent UTC time.

Just use UTC time to tell what "fixed" time, and do not use "UTC
offsets" as they are by convention changeable.

> Consider that you need to put a timestamp exactly 1 year from now, even
> if time zone rules change. You are in +04 time zone at
> [2023-03-08 14:00 @Asia/Istanbul].

No matter in which time zone I am, one year from now depends on how
year is calculated

If current timestamp at UTC time is:
2023-03-10 01:08:07
then one year from now is:
2024-03-10 01:08:07

> You can write [2024-03-08 11:00 @Z] or you can write
> [2024-03-08 14:00 @+03]. The latter is nothing but former, written
> without a need to mentally convert back to UTC from your current wall
> clock.

I understand and I do not agree to that notation for reason that it is
confusing, but you please do how you wish.

UTC offset is shown to user in many applications depending on user's
time zone, while time that is fixed is static designation.

I would agree to such notation only if UTC time is written in Org
file, but you provide representation of UTC time showing the UTC
offset.

I see now use of providing "UTC time" with "UTC offset" as that is
beyond conventions.

Then we are speaking out of the reality of what people agreed on this
planet, and people agreed not to use any offsets with UTC time. It is
either UTC time without offset or offset zero, or no offset at all.

But of course Org can be the playground to do what one wish and want.

> > You can introduce something new in Org and say "This is fixed UTC
> > offset in time zone @ABC" but that way you are confusing yourself and
> > future programmer and users, as it does not comply to already accepted
> > international standards.
> >
> > iCalendar proposes different way of representation of time in future,haw
> > that is, it could be UTC time in future, or it could be date, time and
> > time zone. Using UTC offset for future is redundant, as in present
> > time when you are writing future time stamp, you cannot know the
> > future UTC offset.
> 
> iCalendar provides just two options: time zone name and UTC. It is ok
> when the timestamps are written programmatically, but not ok when the
> format should be writable by humans manually. I do not see why we should
> force the users to convert to UTC manually in the above scenario.

While I cannot see the context of the above statement, I have never
had any idea of letting user convert some timestamps manually, that is
why computers are there to provide timestamps. I don't do that manually.

> >> icalendar is _not_ the only time spec around. We can take it into
> >> account, but I do not see any reason to follow it blindly.
> >
> > How about finding reasons why iCalendar specifies it that way?
> >
> > And then deciding if those reasons, not specification literally,
> > should be followed?
> 
> Feel free to share the underlying logic if you are aware about it.

Which indicates you did not do the homework.

> >> > 4. Hypothetical example of clear timestamp for future:
> >> >[2024-02-04 12:00! @-08,America/Vancouver]
> >> >where the time would be stamped with "!" and that would mean that in 
> >> > the time zone, meeting is at 12 o'clock.
> >> >It would assume that UTC offset can change in future, but 12:00 clock 
> >> > would be authoritative time for future.
> >> 
> >> This is ambiguous. 12:00 which time zone? GTM+08? America/Vancouver?
> >
> > The sign "!" is telling "use time, not offset as authoritative". I do
> > not say you should implement it this way, but I am saying it is wrong
> > putting both the time and offset for future time, while you will not
> > know the future offset with certainty.
> 
> Ok. I see the problem you referred to. We should then better stick to
> the TEC's proposal here:
> 
> ┌
> │ [2022-11-12 12:00 @+07,Asia/Singapore]  # warn when mismatch
> │ [2022-11-12 12:00 @+07,!Asia/Singapore] # use Asia/Singapore over +07
> │ [2022-11-12 

Mention outli, and h speed-key

[JD Smith]

Outli  is a small mode I wrote which very 
closely follows org in style and uses the same speed-keys on 
comments-as-headlines.  Basically if you know org, outli will be usable “out of 
the box”.  It might be good to mention outli in the Worg page 
 on org 
capabilities outside of org.

To quote from the README:

> • How does this relate to outline-minor-mode?
> 
> outli is mostly a convenient wrapper around functionality that is already 
> built-in to outline, adding a few things like narrow-to-subtree and 
> insert-heading-respect-content (ala org). And of course the speed-key 
> bindings, automatic comments-as-header patterns, and styling.

One speed key I added to outli I really miss in org, so I added it:

(if-let ((pos (cl-position '("Outline Visibility") org-speed-commands :test 
#'equal)))
  (cl-pushnew '("h" . outline-hide-sublevels) (nthcdr (1+ pos) 
org-speed-commands)))

Basically h=outline-hide-sublevels.  This allows you to quickly collapse the 
entire tree to the level [h]ere.  It’s a wonderful, fast compromise between the 
ease of Shift-Tab and org’s more targeted folding capabilities.

Thanks for your work on org!

Re: [PATCH] Async evaluation in ob-shell

[Max Nikulin]

On 10/03/2023 00:36, Matt wrote:

(concat "^" (regexp-quote org-babel-sh-prompt) " *") -> "^org_babel_sh_prompt>  
*"

Currently, the two combine via the concat to give*two*  spaces in the regexp.


"*" means zero or more, so "  *" with two spaces acts like " +" one or 
more space characters. It is unsafe to append just "*" or "+" to another 
regexp since you can not ensure what is the trailing pattern of the 
preceding regexp.

Re: [BUG] Date prompt suggests yesterday when changing timestamp with org-extend-today-until set [9.6]

[Tim Ruffing]

Sorry for the late reply. The patch solves the problem for me, thanks!
Would be great to have this fixed.

On Sun, 2023-01-22 at 11:44 +, Ihor Radchenko wrote:
> * This is test
> SCHEDULED: <2023-01-28 Sat>
> 
> Then, M-: (setq org-extend-today-until 20)
> Then, C-c C-s on the heading above
> 
> What will happen if one tries to do "." or +1 or ++1. I find the
> current
> behavior rather disorienting. Could someone check what we promise in
> the
> Org manual, `org-read-date' docstring, `org-extend-today-until'
> docstring, and what actually happens in practice?
> 

Unless you see a bug that I'm not seeing, the behavior looks correct to
me (with the patch applied): The default date (when the user hasn't
entered anything) is the existing timestamp.  Then "." selects today
explicitly, "+" is relative to today, and "++" is relative to the
default date. That's exactly what's promised
in https://orgmode.org/manual/The-date_002ftime-prompt.html and also in
the `org-read-date` doctring. (And I think it makes sense.)

Best,
Tim

Re: [PATCH] Async evaluation in ob-shell

[Matt]

Hi Jack and Jeremie!  I'm curious your thoughts about what Ihor and I are 
discussing at the end of this message about `md5'.

  On Tue, 07 Mar 2023 07:45:02 -0500  Ihor Radchenko  wrote --- 
 > Matt m...@excalamus.com> writes:
 > 
 > >  > The actual prompt is "org_babel_sh_prompt> ".
 > >
 > > Agreed.
 > >
 > >  > And we want to skip leading spaces in addition.
 > >  
 > > What do you mean by this?
 > 
 > I was following the pattern described in the docstring of
 > `comint-prompt-regexp', where it is suggested that prompts should follow
 > the pattern "^ *".
 > 
 > In the case of ob-shell.el, `org-babel-sh-prompt' is a string to be used
 > as a prompt and the corresponding regexp patter will be
 > "^ *". Hence
 > 
 >   (concat "^" (regexp-quote org-babel-sh-prompt) " *")
 > 
 > >  > Adding " *" does not make the prompt match 2 spaces, but 1+.
 > >  
 > > Agreed.  
 > >
 > > It's not clear to me what pattern you're looking to match.
 > 
 > I hope the above clarified things.

I'm confused because when I run the Org from HEAD, I get:

(concat "^" (regexp-quote org-babel-sh-prompt) " *") -> "^org_babel_sh_prompt>  
*"

That's *two* spaces between '>' and '*', not one.  The second space comes from 
either 1) the definition of `org-babel-sh-prompt', which is 
"org_babel_sh_prompt> " (with a single space) or 2) the " *" in the  (concat 
"^" (regexp-quote org-babel-sh-prompt) " *") expression.   Currently, the two 
combine via the concat to give *two* spaces in the regexp.

If I understand you correctly, you're trying to match the pattern given in the 
`comint-prompt-regexp' which is *one* space.   That's what I'm trying to do, 
too.

Way back in https://list.orgmode.org/87sfeyc7qr.fsf@localhost/, we had this 
exchange:

  On Mon, 20 Feb 2023 11:24:52 +  Ihor Radchenko  wrote --- 
> Matt  writes:
>
> > +(defun ob-shell-async-chunk-callback (string)
> > +  "Filter applied to results before insertion.
> > +See `org-babel-comint-async-chunk-callback'."
> > +  (replace-regexp-in-string (concat org-babel-sh-prompt "*") "" string))
>
 > Why not using `comint-prompt-regexp'?

I switched out `org-babel-sh-prompt'  with `comint-prompt-regexp' so that the 
expression looks like:

+(defun ob-shell-async-chunk-callback (string)
+  "Filter applied to results before insertion.
+See `org-babel-comint-async-chunk-callback'."
+  (replace-regexp-in-string comint-prompt-regexp "" string))

This causes the new test `test-ob-shell/session-async-evaluation' to fail, as 
you pointed out: https://list.orgmode.org/87bkl96g6e.fsf@localhost/

The test fails when we switch out the prompt in the callback because 
`comint-prompt-regexp' has two spaces in it.  The second space causes a prompt 
to not be filtered (by the callback).  The output becomes ": 1\n: 2\n: 
org_babel_sh_prompt>\n" instead of  ": 1\n: 2\n" .  This looks like a bug in 
the `comint-prompt-regexp''.

It could be that `test-ob-shell/session-async-evaluation' doesn't test 
correctly, but it looks right to me (I could certainly be mistaken).  
Therefore, I see only two options to fix it: remove a space from the concat 
expression (which I did in my latest patch) or remove a space from 
`org-babel-sh-prompt'.

Am I missing something?

 > >  > `md5' will be slightly faster compared to `org-id-uuid'. But it should
 > >  > not matter.
 > >  > 
 > >  > If we want use `org-id-uuid', lets move it to org-macs.el. Requiring the
 > >  > whole org-id.el must not be done. It has side effects of defining id:
 > >  > links.
 > >
 > > In the next revision (once we figure out the regex), I can create a 
 > > separate commit moving `org-id-uuid' to org-macs.el and updating ob-R and 
 > > ob-python from `md5' to `org-id-uuid' (assuming that's not an issue for 
 > > the maintainers of those).  If you think speed is a concern, however, I 
 > > can switch ob-shell.el to use plain `md5'.
 > 
 > I am in favour of using `org-id-uuid'. It might also be a useful generic
 > function for other purposes.
 > 
 > A slight concern is that some third-party code might depend on the
 > current pattern used for UUID string in ob-python. But we made no
 > promises here.
 > 
 > To be a bit safer, we can also refactor `org-uuidgen-p' exposing the
 > regexp used to match UUID. Also, it will make sense to move
 > `org-uuidgen-p' to org-macs.el.

I'm okay with all that.  I wonder, do Jack Kamm (of ob-python fame) and Jeremie 
Juste (of ob-R fame) have any thoughts on the matter.  I ask out of courtesy 
since they're the maintainers of those packages and I don't want to cross any 
boundaries by changing their implementations beneath them.  

Re: [PATCH] Fix ob-latex.el command injection vulnerability.

[Max Nikulin]

On 09/03/2023 19:22, Ihor Radchenko wrote:

lux writes:

Hi, this is a new patch, let me briefly explain this patch:


Thank you for scratching my itch related to unsafe shell commands in Org 
Mode.



2. `org-babel-latex-convert-pdf' is not safe, simple test:

...

I am not sure if blindly adding `shell-quote-argument' is safe here.


I believe, first hunk still can be committed.


  (shell-command cmd)))


im-in-options and im-out-options, according to
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html,
are options passed to ImageMagick.


ImageMagick is disaster per se.

Ideally `call-process' or `process-file' should be here instead of 
`shell-command' making `shell-quote-argument' unnecessary. Sorry, it is 
not clear for me if remote files (e.g. /ssh:...) are supported here. 
Unfortunately options as a string, not as a list, means compatibility 
issue. `split-string-and-unquote' may cause new bugs.


I have not evaluated it yet, but from discussions on this list I have an 
impression that some LaTeX packages need to run external commands. I am 
unsure to which degree it is safe or it may be easily exploited.

[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,15 +119,24 @@ defcustom ob-clojure-babashka-command
   :group 'org-babel
   :package-version '(Org . "9.6"))
 
-(defcustom ob-clojure-nbb-command (executable-find "nbb")
+(defcustom ob-clojure-nbb-command (or 

Re: [BUG] No space after footnote with org-export-with-footnotes set to nil [9.6.1 ( @ /Users/test/.emacs.d/elpa/28.0/develop/org-9.6.1/)]

[Max Nikulin]

On 09/03/2023 19:43, Ihor Radchenko wrote:

Max Nikulin writes:

Both "Heading" and "[0/1]" have the same :post-blank " ", so when
stripping the statistics cookie use " " :post-blank for "Heading"
(retain current value).


Sorry, but we are mis-communicating here.


No, it just means that I am not familiar enough with org-element structures.


:post-blank can be either nil or a number of spaces/tabs after object.

Plain strings always have :post-blank nil.
So do line breaks.


If preceding object is string than trailing spaces should be taken into 
account instead of :post-blank. If footnote reference or similar object 
has more :post-blank spaces than replace it by string with space 
characters to have footnote's :post-blank in total. Alternatively append 
these spaces to the preceding string.




Text with newline \\
  [fn:1]  more text.

#("Text with newline " 0 18
  (:parent #2))
(line-break
 (:begin 19 :end 22 :post-blank 0 :parent #2))
#(" " 0 1

1 space--^

(footnote-reference
 (:label "1" ... :post-blank 2 :parent #2))

2 spaces---^

#("more text.\n" 0 11


So stripping the footnote use 2 spaces "  " instead of preceding " " or 
add another " " (unsure if 2 adjacent strings may be a problem for 
export backends).


I was imprecise, but I do not see any contradictions.

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

Re: How to exclude colum titles from calculations

[Uwe Brauer]

>>> "FE" == Fraga, Eric  writes:

> I make extensive use of the advanced features of the spreadsheet in org
> tables, specifically having a first column that indicates which rows
> should be calculated or not.  Check out the org info manual

> (org) Advanced features


Aha, thanks 
meanwhile I tried

|   |   |  What |   |  This |   |
|---+---+---+---+---+---|
| ! |   | Account 1 | Account 1 | Account 2 | Account 2 |
|---+---+---+---+---+---|
|   | Item1 |224999 |  56249.75 |224999 |  56249.75 |
|   | Item2 |269403 |  67350.75 |269403 |  67350.75 |
|   | Item3 |   |   |   |   |
|   | Item4 |   |   |   |   |
|   | Item5 | 10300 |   2575.00 |   |   |
#+TBLFM: $4=if(typeof(0.25*$3) == 12, string(""),0.25*$3); E 
f-2::$6=if(typeof(0.25*$5) == 12, string(""),0.25*$5); E f-2

Or / instead of !, the problem is then this row is not exported.


So you propose

|   |   |  What |   |  This |   |
|---+---+---+---+---+---|
|   |   | Account 1 | Account 1 | Account 2 | Account 2 |
| # | Item1 |224999 |  56249.75 |224999 |  56249.75 |
| # | Item2 |269403 |  67350.75 |269403 |  67350.75 |
| # | Item3 |   |   |   |   |
| # | Item4 |   |   |   |   |
| # | Item5 | 10300 |   2575.00 |   |   |
#+TBLFM: $4=if(typeof(0.25*$3) == 12, string(""),0.25*$3); E 
f-2::$6=if(typeof(0.25*$5) == 12, string(""),0.25*$5); E f-2

Which works nicely, thanks







-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/


smime.p7s
Description: S/MIME cryptographic signature

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

[Ihor Radchenko]

Zelphir Kaltstahl  writes:

> OK, to wrap up (ha!), I want to ask:
>
> (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.

> (q2) Any chances of that changing to (define ...)?

This sounds reasonable.

> (q3) How could I change my org-mode's code to not  let-wrap, and instead use 
> (define ...)?

See `org-babel-expand-body:scheme'. You can re-define it for a quick
temporary fix.

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

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

[Ihor Radchenko]

Zelphir Kaltstahl  writes:

> START
> #+name: python-imports
> #+begin_src python :python /usr/bin/python3 :results output replace drawer 
> :var x=4
> import math
>
> y = math.sqrt(x)
> # print(y)
> #+end_src
>
> #+name: python-usage
> #+begin_src python :python /usr/bin/python3 :return :noweb strip-export 
> :results value replace drawer
> <>
>
> print("y: {}".format(y))
> #+end_src
> ~END~
>
> Unfortunately, this example does not seem to work at all, but for a different 
> reason:
>
> It seems that using any Python source block with :var header args via :noweb 
> does not work, as it then behaves in the way, that it merely pasted the 
> included 
> source block, without first putting in the :var values into the variables. I 
> get 
> errors about those :var variables being undefined, of course, since they are 
> on 
> the included source block, not on the including one:
>
> START: *Org-Babel Error Output*
> Traceback (most recent call last):
>File "", line 10, in 
>File "", line 5, in main
> NameError: name 'x' is not defined
> [ Babel evaluation exited with code 1 ]
> ~END~

This is expected. Noweb includes the src block code without altering it.
See 16.11 Noweb Reference Syntax

We may probably clarify this in the manual. Would it be helpful?

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

[BUG] Inconsistent global/local :var assignments in ob-* for lisps and non-lisps (was: org-babel guile source block bug in handling multiple values)

[Ihor Radchenko]

Zelphir Kaltstahl  writes:

> I am not sure (let ...) is a correct wrapper for noweb included source 
> blocks. 
> What, if I write a (define ...) in my source block and want to use that 
> source 
> block via noweb in another source block? Expected behavior I think would be 
> to 
> be able to access those variables in other source blocks, since they are 
> defined 
> on a top level in an earlier source block, but if they are wrapped in a (let 
> ...), that would make them only available in the (let ...)? It seems to me, 
> that 
> the simple wrapping with a (let ...) might not be the right thing to do. 
> Testing 
> that:
>
> START
> #+name: scheme-defs
> #+begin_src scheme :eval query-export :noweb strip-export :session myguile 
> :results output replace drawer :var x=1 :var y=2
> (define a x)
> (define b y)
> #+end_src
>
> #+name: scheme-time
> #+begin_src scheme :eval query-export :noweb strip-export :session myguile 
> :results output replace drawer
> <>
> (simple-format #t "~a ~a\n" a b)
> #+end_src
> ~END~
>
> Indeed, that also does not work.

I just checked ob-C, ob-shell, ob-emacs-lisp, and ob-clojure.
Non-lisps appear to assign the values globally.
In contrast, all the lisp babel backends are using let-bindings.

Considering the existing inconsistency, and the raised bug I'd be in
favor of making variable assignments global in all the lisp babel
backends.

The only possible exception is ob-emacs-lisp. Executing elisp code is
done in current Elisp session and thus using global variable assignments
may be tricky. Unless we juggle with multiple obarrays.

> I guess I did never hit this problem earlier, because I "oursourced" my 
> imports 
> and in imports I do not need any :var header arguments.
>
> I've asked on the Guile IRC channel and something interesting is the case 
> here 
> (thanks for clearing it up flatwhatson!) and I understand it as follows:
>
> Imports inside (let ...) work. It is just that let-values is a macro and 
> macros 
> are expanded before execution time. However, Guile gets to the body of the 
> wrapping (let ...) at execution time. That means, that when Guile gets to 
> evaluate the body of the let, it does not expand the let-values, because it 
> is 
> already at execution time and no longer at macro expansion time. The import 
> might import the let-values form, or might not, but it is already too late to 
> expand the (let-values ...).

So, apparently using `let' is not universally safe in Guile.

> OK, the question is though, whether org should wrap anything in a (let ...) 
> at 
> all. During discussion on the Guile IRC, some points against let-wrapping 
> were 
> brought up:
>
> (1) The presence of a :var header argument currently determines, whether the 
> code in the source block is wrapped with a (let ...). One argument for that 
> was, 
> that this way the variables do not leak. But this also decides, whether other 
> things leak. For example (import ...) or (define ...). Should :var decide, 
> whether bindings created with (define ...) are visible in other source blocks 
> including the source block with the :var header arguments? It seems like a 
> responsibility :var should not have and definitely is unexpected for the user.

This is something Guile-specific. In Elisp, let-binding still allows
`defun' or `defvar'.

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

[PATCH] Don't reset `org-todo-keywords-for-agenda' when org-agenda-multi

[Tim Ruffing]

* org-agenda.el (org-prepare-agenda): Don't reset
`org-todo-keywords-for-agenda' when org-agenda-multi.

Fixes a bug with TODO keywords that came to light in org-modern,
see https://github.com/minad/org-modern/issues/26.

This is very similar to cd2d138883a55cad48394a3f473da8b973a99a5e,
which fixed the same for `org-done-keywords-for-agenda` (to fix
a similar styling issue).
---
 lisp/org-agenda.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 7e54121dc..8e3cc693a 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -3956,7 +3956,6 @@ FILTER-ALIST is an alist of filters we need to
apply when
  (message "Sticky Agenda buffer, use `r' to refresh")
  (or org-agenda-multi (org-agenda-fit-window-to-buffer))
  (throw 'exit "Sticky Agenda buffer, use `r' to refresh"))
-  (setq org-todo-keywords-for-agenda nil)
   (if org-agenda-multi
  (progn
(setq buffer-read-only nil)
@@ -3969,6 +3968,7 @@ FILTER-ALIST is an alist of filters we need to
apply when
(make-string (window-max-chars-per-line) org-agenda-block-
separator))
  "\n"))
(narrow-to-region (point) (point-max)))
+(setq org-todo-keywords-for-agenda nil)
(setq org-done-keywords-for-agenda nil)
;; Setting any org variables that are in org-agenda-local-vars
;; list need to be done after the prepare call
-- 
2.39.2

Re: [BUG] No space after footnote with org-export-with-footnotes set to nil [9.6.1 ( @ /Users/test/.emacs.d/elpa/28.0/develop/org-9.6.1/)]

[Ihor Radchenko]

Max Nikulin  writes:

> On 07/03/2023 20:59, Ihor Radchenko wrote:
>> I agree about the last example, but what about "Heading [0/1] text"?
>
> Both "Heading" and "[0/1]" have the same :post-blank " ", so when 
> stripping the statistics cookie use " " :post-blank for "Heading" 
> (retain current value).

Sorry, but we are mis-communicating here.
:post-blank can be either nil or a number of spaces/tabs after object.

Plain strings always have :post-blank nil.
So do line breaks.

>> May you elaborate about "newline > tab, tab = 8 spaces"?
>
> Consider your earlier example:
>
 Text with newline\\
 [footnote]  more text.

Try M-: (pp (org-element-parse-buffer))


Text with newline \\
 [fn:1]  more text.


You will get

(org-data
 (:begin 1 :contents-begin 1 :contents-end 42 :end 42 :robust-begin 3 
:robust-end 40 :post-blank 0 :post-affiliated 1 :path "/tmp/bug.org" :mode 
org-data :CATEGORY "bug" :granularity nil)
 (section
  (:begin 1 :end 42 :contents-begin 1 :contents-end 42 :robust-begin 1 
:robust-end 40 :post-blank 0 :post-affiliated 1 :mode first-section 
:granularity nil :parent #0)
  (paragraph
   (:begin 1 :end 42 :contents-begin 1 :contents-end 42 :post-blank 0 
:post-affiliated 1 :mode top-comment :granularity nil :parent #1)
   #("Text with newline " 0 18
 (:parent #2))
   (line-break
(:begin 19 :end 22 :post-blank 0 :parent #2))
   #(" " 0 1
 (:parent #2))
   (footnote-reference
(:label "1" :type standard :begin 23 :end 31 :contents-begin nil 
:contents-end nil :post-blank 2 :parent #2))
   #("more text.\n" 0 11
 (:parent #2)

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

Re: How to exclude colum titles from calculations

[Fraga, Eric]

I make extensive use of the advanced features of the spreadsheet in org
tables, specifically having a first column that indicates which rows
should be calculated or not.  Check out the org info manual

(org) Advanced features

and the token you want in the first column would be '#' for those rows
that should be calculated.

this will allow you to exclude the second row from any updates.

-- 
: Eric S Fraga, with org release_9.6.1-278-ge52c53 in Emacs 30.0.50

Re: [PATCH] Fix ob-latex.el command injection vulnerability.

[Ihor Radchenko]

lux  writes:

> Hi, this is a new patch, let me briefly explain this patch:

Thanks!

> 2. `org-babel-latex-convert-pdf' is not safe, simple test:
>
>   (org-babel-latex-convert-pdf ";id;.tex" ";uname;.pdf" "" "")
>
> So, add `shell-quote-argument' to each external parameter.

I am not sure if blindly adding `shell-quote-argument' is safe here.

>  (defun org-babel-latex-convert-pdf (pdffile out-file im-in-options 
> im-out-options)
>"Generate a file from a pdf file using imagemagick."
> -  (let ((cmd (concat "convert " im-in-options " " pdffile " "
> -  im-out-options " " out-file)))
> +  (let ((cmd (concat "convert " (shell-quote-argument im-in-options) " "
> + (shell-quote-argument pdffile) " "
> +  (shell-quote-argument im-out-options) " "
> + (shell-quote-argument out-file
>  (message "Converting pdffile file %s..." cmd)
>  (shell-command cmd)))

im-in-options and im-out-options, according to
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html,
are options passed to ImageMagick.

However, for example, (shell-quote-argument "-enhance -strip") will
return "-enhance\\ -strip", which is not what we want.

Similar problem with other instances of `shell-command' in Org where
header args supply command line arguments. Like in :cmdline.

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

How to exclude colum titles from calculations

[Uwe Brauer]

Hi 

Please take this example: 

|---+---+-+---+--|
|   | Account 1 | 1/4 part of | Account 2 |  1/4 |
|---+---+-+---+--|
| Item1 |224999 | |224999 |  |
| Item2 |269403 | |269403 |  |
| Item3 |   | |   |  |
| Item4 |   | |   |  |
| Item5 | 10300 | 2575.00 |   |  |
#+TBLFM: $3=if(typeof(0.25*$2) == 12, string(""),0.25*$2); E 
f-2::$5=if(typeof(0.25*$4) == 12, string(""),0.25*$4); E f-2

C-c C-c 

Leads to the expected 


|---+---+-+---+--|
|   | Account 1 | 1/4 part of | Account 2 |  1/4 |
|---+---+-+---+--|
| Item1 |224999 |56249.75 |224999 | 56249.75 |
| Item2 |269403 |67350.75 |269403 | 67350.75 |
| Item3 |   | |   |  |
| Item4 |   | |   |  |
| Item5 | 10300 | 2575.00 |   |  |
#+TBLFM: $3=if(typeof(0.25*$2) == 12, string(""),0.25*$2); E 
f-2::$5=if(typeof(0.25*$4) == 12, string(""),0.25*$4); E f-2


However when I have one line on top of the table 


|   |  What | | This  | |
|---+---+-+---+-|
|   | Account 1 | 1/4 part of | Account 2 | 1/4 |
|---+---+-+---+-|
| Item1 |224999 | |224999 | |
| Item2 |269403 | |269403 | |
| Item3 |   | |   | |
| Item4 |   | |   | |
| Item5 | 10300 | 2575.00 |   | |
#+TBLFM: $3=if(typeof(0.25*$2) == 12, string(""),0.25*$2); E 
f-2::$5=if(typeof(0.25*$4) == 12, string(""),0.25*$4); E f-2

Then C-u C-u C-c C-c leads to 


|   |  What |  |  This |
  |
|---+---+--+---+--|
|   | Account 1 | mul = 12 ?  : 0.25 Account 1 | Account 2 | mul = 12 ?  : 
0.25 Account 2 |
|---+---+--+---+--|
| Item1 |224999 | 56249.75 |224999 |
 56249.75 |
| Item2 |269403 | 67350.75 |269403 |
 67350.75 |
| Item3 |   |  |   |
  |
| Item4 |   |  |   |
  |
| Item5 | 10300 |  2575.00 |   |
  |
#+TBLFM: $3=if(typeof(0.25*$2) == 12, string(""),0.25*$2); E 
f-2::$5=if(typeof(0.25*$4) == 12, string(""),0.25*$4); E f-2

Which is terrible.

Any idea how to avoid this?

Thanks and regards

Uwe Brauer 


-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/