Re: org code and error catching

[Michael Heerdegen]

Michael Heerdegen  writes:

> I reviewed it shortly - looks appropriate.

Though, I think you didn't change the occurrence that this thread
started with - `org-eval'.  Does changing this one cause problems?

Michael.

Re: org code and error catching

[Michael Heerdegen]

Ihor Radchenko  writes:

> I changed instances that appear to be safe.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5b4eebfab

I reviewed it shortly - looks appropriate.

Thank you very much!

Michael.

[PATCH] org-manual: Mark up nil as ~nil~ [9.6.6 (release_9.6.6 @ /home/blc/.local/share/emacs/30.0.50/lisp/org/)]

[General discussions about Org-mode.]

In emacs.git I noticed some occurrences of 'nil' in the generated
doc/misc/org.texi were not marked up as @code.

Is this TRT?  (I already have an Emacs CA on file.)

>From 69ee9636fb2cd52efe8c11ca5877c83fb984a9ea Mon Sep 17 00:00:00 2001
From: "Basil L. Contovounesios" 
Date: Thu, 1 Jun 2023 22:19:28 +0100
Subject: [PATCH] doc/org-manual.org: Mark up nil as ~nil~

* doc/org-manual.org (Images, Plain lists in Texinfo export)
(Results of Evaluation): Mark up plain nil as ~nil~.
(Org Crypt): Ditto.  Clarify wording.
---
 doc/org-manual.org | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index ab5c10c1d..537cd046f 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -11597,8 +11597,8 @@ command:
   =ORG-IMAGE-ACTUAL-WIDTH= property (subtree-level)[fn:: The width can
   be customized in Emacs >= 24.1, built with imagemagick support.].
   Their value can be the following:
-  - (default) Non-nil, use the actual width of images when inlining them.
-If the actual width is too wide, limit it according to
+  - (default) Non-~nil~, use the actual width of images when inlining
+them.  If the actual width is too wide, limit it according to
 ~org-image-max-width~.
   - When set to a number, use imagemagick (when available) to set the
 image's width to this value.
@@ -11608,7 +11608,7 @@ command:
 ,#+ATTR_HTML: :width 300px
 #+end_example
 and fall back on that number if none is found.
-  - When set to nil, try to get the width from an =#+ATTR.*= keyword
+  - When set to ~nil~, try to get the width from an =#+ATTR.*= keyword
 and fall back on the original width or ~org-image-max-width~ if
 none is found.
 
@@ -11618,8 +11618,8 @@ command:
   - (default) ~fill-column~, limit width to ~fill-column~ number of
 characters.
   - ~window~, limit width to current window width.
-  - integer number, limit width that specified number of pixels.
-  - nil, do not limit the width.
+  - integer number, limit width to that specified number of pixels.
+  - ~nil~, do not limit the width.
 
 #+vindex: org-cycle-inline-images-display
 Inline images can also be displayed when cycling the folding state.
@@ -15756,9 +15756,9 @@ This is the common text for variables foo and bar.
 
 The =:compact= attribute is an alternative to the =:sep= attribute,
 which allows writing each entry on its own line.  If this attribute is
-non-nil and an item in a description list has no body but is followed
-by another item, then the second item is transcoded to =@itemx=.  This
-example is transcoded to the same output as above.
+non-~nil~ and an item in a description list has no body but is
+followed by another item, then the second item is transcoded to
+=@itemx=.  This example is transcoded to the same output as above.
 
 #+begin_example
 ,#+ATTR_TEXINFO: :table-type vtable :indic asis :compact t
@@ -18666,7 +18666,7 @@ options; they are mutually exclusive.
   but no processing is performed on the return value.  Calling the
   code block programmatically (see [[*How to evaluate source code]]) or by
   reference (see [[*Passing arguments]] and [[*Noweb Reference Syntax]]) will
-  always yield nil.
+  always yield ~nil~.
 
 - =append= ::
 
@@ -20932,8 +20932,8 @@ specifying the respective key as property =CRYPTKEY=, e.g.:
   :END:
 #+end_example
 
-Note that =CRYPTKEY= property is only effective when ~org-crypt-key~
-is set to non-nil.  ~nil~ value of ~org-crypt-key~ makes Org use
+Note that the =CRYPTKEY= property is only effective when
+~org-crypt-key~ is non-~nil~.  If ~org-crypt-key~ is ~nil~, Org uses
 symmetric encryption unconditionally.
 
 Excluding the =crypt= tag from inheritance prevents already encrypted
-- 
2.34.1


This is one of my first times posting here, and I am not subscribed to
the mailing list, so please keep me CCed and let me know if anything is
amiss.

Thanks,

-- 
Basil

Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo 
version 1.16.0, Xaw3d scroll bars)
 of 2023-05-30
Package: Org mode version 9.6.6 (release_9.6.6 @ 
/home/blc/.local/share/emacs/30.0.50/lisp/org/)

current state:
==
(setq
 org-archive-location "/home/blc/.emacs.d/org/archive.org::"
 org-list-use-circular-motion t
 org-checkbox-hierarchical-statistics nil
 org-link-elisp-confirm-function 'yes-or-no-p
 org-hierarchical-todo-statistics nil
 org-agenda-category-icon-alist '(("" (space :width (16
 org-directory "/home/blc/.emacs.d/org/"
 org-global-properties '(("Effort_ALL" . "0 0:15 0:30 0:45 1:00 2:00 3:00"))
 org-agenda-scheduled-leaders '("" "%3dd -")
 org-log-done 'note
 org-log-into-drawer t
 org-agenda-timerange-leaders '("" "(%d/%d)")
 org-agenda-files "/home/blc/.emacs.d/org/agenda-index"
 org-persist-after-read-hook '(org-element--cache-persist-after-read)
 org-refile-targets '((org-agenda-files :maxlevel . 10))
 org-export-before-parsing-hook '(org-attach-expand-links)
 

[PATCH] org.el: inline display of attached images in link descriptions

[Steven Allen]

* lisp/org.el (org-display-inline-images): inline display of attached
images in link descriptions.

Previously, `org-display-inline-images' only inlined images in link
descriptions when they were explicit "file:" links. This change adds
support for "attachment:" links. E.g.:

[[https://orgmode.org][attachment:emacs-screenshot.png]]
---
 lisp/org.el | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 0e5740412..3e1b757c4 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -16301,7 +16301,8 @@ defun org-create-formula-image
 
   2. Its description consists in a single link of the previous
  type.  In this case, that link must be a well-formed plain
- or angle link, i.e., it must have an explicit \"file\" type.
+ or angle link, i.e., it must have an explicit \"file\" or
+ \"attachment\" type.
 
 Equip each image with the key-map `image-map'.
 
@@ -16332,7 +16333,7 @@ defun org-create-formula-image
   ;; "file:" links.  Also check link abbreviations since
   ;; some might expand to "file" links.
   (file-types-re
-   (format 
"\\[\\[\\(?:file%s:\\|attachment:\\|[./~]\\)\\|\\]\\[\\(

Re: [PATCH] float format specifier in ob-C.el

[Leo Butler]

On Thu, Jun 01 2023, Ihor Radchenko  wrote:

> Leo Butler  writes:
>
>> In ob-C.el, line 339 has the format specifier
>>
>>  (`floatp '("double" "%f"))
>>
>> to print literal floats. However, that format specifier rounds, which
>> can result in errors. I think the correct approach is to print the
>> float without rounding or padding or trying to guess at the desired
>> accuracy (and let the compiler do whatever is needed):
>>
>>(`floatp '("double" "%s"))
>
> Makes sense. Thanks!
>
>> -(`floatp '("double" "%f"))
>> +(`floatp '("double" "%s"))
>
> Please add comment explaining why not %f. Otherwise, it is not fully
> clear why "%s" is used.

Done.

>
>> --- a/testing/examples/ob-C-test.org
>> +++ b/testing/examples/ob-C-test.org
>> @@ -60,6 +60,12 @@
>>return 0;
>>  #+end_src
>>  
>> +#+source: float_var
>> +#+begin_src cpp :var x=1.123456789012345678 :includes "" :results 
>> silent
>> +double y = 1.123456789012345678;
>> +std::cout << (x == y);
>> +#+end_src
>
> Please move the source block directly into the test using
> `org-test-with-temp-text'. The test will be more readable then.
>
> `org-test-at-id' should better be used only when necessary in order to
> not jump back and forth when debugging tests.

Ok, I have made the changes requested. Please see the attached patch.

Leo

From 65bddc861c1f439e98d5764f0587e97d4d99a190 Mon Sep 17 00:00:00 2001
From: Leo Butler 
Date: Thu, 1 Jun 2023 13:39:13 -0500
Subject: [PATCH] lisp/ob-C.el: replace %f with %s to prevent unneeded rounding

* lisp/ob-C.el (org-babel-C-val-to-C-type): Floats should be printed
as string literals to prevent rounding introduced by %f format.

* testing/lisp/test-ob-C.el (ob-C/float-var): Test that floats are not
rounded when passed as an org :var.
---
 lisp/ob-C.el  |  2 +-
 testing/lisp/test-ob-C.el | 11 +++
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-C.el b/lisp/ob-C.el
index 3a6e99623..7763c4c07 100644
--- a/lisp/ob-C.el
+++ b/lisp/ob-C.el
@@ -339,7 +339,7 @@ FORMAT can be either a format string or a function which is called with VAL."
 	 (type
 	  (pcase basetype
 	(`integerp '("int" "%d"))
-	(`floatp '("double" "%f"))
+	(`floatp '("double" "%s")) ;; %f rounds, use %s to print the float literally
 	(`stringp
 	 (list
 	  (if (eq org-babel-c-variant 'd) "string" "const char*")
diff --git a/testing/lisp/test-ob-C.el b/testing/lisp/test-ob-C.el
index b6dbed8e3..8546a48dd 100644
--- a/testing/lisp/test-ob-C.el
+++ b/testing/lisp/test-ob-C.el
@@ -95,6 +95,17 @@
 		  (org-babel-next-src-block 10)
 		  (should (= 42 (org-babel-execute-src-block))
 
+(ert-deftest ob-C/float-var ()
+  "Test that floats are passed without unnecessary rounding."
+  (if (executable-find org-babel-C++-compiler)
+  (org-test-with-temp-text 
+"#+source: float_var
+#+begin_src cpp :var x=1.123456789012345678 :includes \"\" :results silent
+double y = 1.123456789012345678;
+std::cout << (x == y);
+#+end_src"
+(should (= 1 (org-babel-execute-src-block))
+
 (ert-deftest ob-C/table ()
   "Test of a table output"
   (if (executable-find org-babel-C++-compiler)

base-commit: 5b4eebfabdc6a9b4ed223025161a342cb312c1d0
-- 
2.39.2

Re: emphases in Org Agenda View

[Ihor Radchenko]

Dieter Faulbaum  writes:

> I have some emphases in my org files.
> Is it possible to see these emphases in the Org Agenda view too?
> I see only the "raw" characters of the emphases in the view.

Agenda currently does not preserve fontification.
See https://list.orgmode.org/orgmode/m2wnz6fvcz@gmail.com/

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

emphases in Org Agenda View

[Dieter Faulbaum]

I have some emphases in my org files.
Is it possible to see these emphases in the Org Agenda view too?
I see only the "raw" characters of the emphases in the view.

Re: org code and error catching

[Ihor Radchenko]

Michael Heerdegen  writes:

>> As for condition-case-unless-debug, may you create a patch?
>> But please do not replace everything blindly - I know for sure that at
>> least some `condition-case' clauses are there on purpose.
>
> I nearly never had a closer look at the org-mode code (other than
> blindly).  I would prefer to help differently (like reviewing a patch),
> honestly, unless there is really no one more appropriate to find.

I changed instances that appear to be safe.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5b4eebfab

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

Re: BUG: org-cycle does not unfold some subtrees

[Ihor Radchenko]

Michael Dauer  writes:

> I think I found a way to consistently reproduce the issue:
> ...

Thanks!
I now came up with another, more reliable, workaround.
Since `query-replace', evil, and swiper all arrange the call of
`isearch-clean-overlays', I can advice it to make sure that we clean
everything at the end.

Fixed, hopefully, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=7dee2c07f

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

Re: [FR] Should we resolve environment variables in the file link path when exporting? (was: [FR] Please add environment variable substitution in `org-display-inline-images')

[Ihor Radchenko]

Pan Xie  writes:

> Oh, that path will be horrible! Variable substitution is really 
> important since it is an abstraction to make the same org file works on 
> different hosts with different path hierarchies. I believe there are 
> lots of users already rely on it, even without being documented. The 
> reasonable thinking would be supporting more substitutions, rather than 
> remove any.

Do not worry. https://bzg.fr/en/the-software-maintainers-pledge/:

I won't break your user experience.
I won't remove features.
...

I just wanted to point out that a discussion may be needed wrt export.
Maybe some other export backends also support env variables in file
paths? We should be a bit more careful if we want to support the
substitution everywhere, not just when opening file links from Emacs.

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

Re: [PATCH] lisp/org-id.el: Add new relative timestamp feature for `ts' `org-id-method'

[Ihor Radchenko]

Kierin Bell  writes:

> It might also be a good idea to refactor `org-id-new' so that the
> different ID methods are more composable.
>
> One nice way to do this would be to create a new option that supersedes
> (but does not override) `org-id-method' and takes a list of functions
> that are tried in order, so that:
>
> (setopt org-id-method 'ts
> org-id-ts-relative t
> org-id-ts-relative-function
>   #'org-id-ts-relative-from-keyword-or-property)
> 
> ... would be equivalent to:
>
> (setopt org-id-function-list '(org-id-relative-ts-keyword
>  org-id-relative-ts-property
>  org-id-ts))

This will be breaking.
We can do it slightly differently:

1. Allow `org-id-method' to be a list of methods/functions to try in
   addition to being a symbol.
2. Add new customization `org-id-methods' that will link method names to
   functions: '((ts . org-id-ts) (uuid . ...) (uuidgen . ...) (org . ...)).

That way, old configurations will continue working.

> I do understand that ID methods may be intentionally difficult to
> extend, because IDs should be stable and consistent.

Just by default. We do not constrain users from using arbitrary IDs,
including manually typed.

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

Re: [FR] Should we resolve environment variables in the file link path when exporting? (was: [FR] Please add environment variable substitution in `org-display-inline-images')

[Pan Xie]

Oh, that path will be horrible! Variable substitution is really 
important since it is an abstraction to make the same org file works on 
different hosts with different path hierarchies. I believe there are 
lots of users already rely on it, even without being documented. The 
reasonable thinking would be supporting more substitutions, rather than 
remove any.


On 6/1/23 16:35, Ihor Radchenko wrote:

Pan Xie  writes:


I think we need keep consistent with the file link. Since file link will
substitute the environment variables in its file path, I guess it will
do the same thing when export to html files. It may keep the variables
when export to Org (ox-org). Since both image link and file link are
links, from user's perspective they should be consistent.

This feature is not even documented. We may as well go other way and
remove variable substitution from the file links and keep the rest
unchanged. Not that we have to. But I think that the topic is worth
discussing first.

Re: [FR] Should we resolve environment variables in the file link path when exporting? (was: [FR] Please add environment variable substitution in `org-display-inline-images')

[Ihor Radchenko]

Pan Xie  writes:

> I think we need keep consistent with the file link. Since file link will 
> substitute the environment variables in its file path, I guess it will 
> do the same thing when export to html files. It may keep the variables 
> when export to Org (ox-org). Since both image link and file link are 
> links, from user's perspective they should be consistent.

This feature is not even documented. We may as well go other way and
remove variable substitution from the file links and keep the rest
unchanged. Not that we have to. But I think that the topic is worth
discussing first.

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

Re: [FR] Should we resolve environment variables in the file link path when exporting? (was: [FR] Please add environment variable substitution in `org-display-inline-images')

[Pan Xie]

I think we need keep consistent with the file link. Since file link will 
substitute the environment variables in its file path, I guess it will 
do the same thing when export to html files. It may keep the variables 
when export to Org (ox-org). Since both image link and file link are 
links, from user's perspective they should be consistent.


On 6/1/23 16:20, Ihor Radchenko wrote:

Pan Xie  writes:


Fantastic!! Thanks for your help. I can remove my ugly override codes.

BTW, Please keep in mind that the org export codes also need to
substitute the environment variables. My proposal only works for the org
file itself, When exports the org file to html, the image file path will
still include the environment variable, which is of course not correct.

It may or may not be correct.
For example, when exporting to Org (ox-org), one may want to keep the
environment variables.

If we add this feature for export, it should be an export option.
It will also be a breaking change.

I generally feel that it should be reasonable to go ahead with this
breaking change, possibly disabling variable resolution for ox-org only.

Re: [PATCH] float format specifier in ob-C.el

[Ihor Radchenko]

Leo Butler  writes:

> In ob-C.el, line 339 has the format specifier
>
>   (`floatp '("double" "%f"))
>
> to print literal floats. However, that format specifier rounds, which
> can result in errors. I think the correct approach is to print the
> float without rounding or padding or trying to guess at the desired
> accuracy (and let the compiler do whatever is needed):
>
>(`floatp '("double" "%s"))

Makes sense. Thanks!

> - (`floatp '("double" "%f"))
> + (`floatp '("double" "%s"))

Please add comment explaining why not %f. Otherwise, it is not fully
clear why "%s" is used.

> --- a/testing/examples/ob-C-test.org
> +++ b/testing/examples/ob-C-test.org
> @@ -60,6 +60,12 @@
>return 0;
>  #+end_src
>  
> +#+source: float_var
> +#+begin_src cpp :var x=1.123456789012345678 :includes "" :results 
> silent
> +double y = 1.123456789012345678;
> +std::cout << (x == y);
> +#+end_src

Please move the source block directly into the test using
`org-test-with-temp-text'. The test will be more readable then.

`org-test-at-id' should better be used only when necessary in order to
not jump back and forth when debugging tests.

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

[FR] Should we resolve environment variables in the file link path when exporting? (was: [FR] Please add environment variable substitution in `org-display-inline-images')

[Ihor Radchenko]

Pan Xie  writes:

> Fantastic!! Thanks for your help. I can remove my ugly override codes.
>
> BTW, Please keep in mind that the org export codes also need to 
> substitute the environment variables. My proposal only works for the org 
> file itself, When exports the org file to html, the image file path will 
> still include the environment variable, which is of course not correct.

It may or may not be correct.
For example, when exporting to Org (ox-org), one may want to keep the
environment variables.

If we add this feature for export, it should be an export option.
It will also be a breaking change.

I generally feel that it should be reasonable to go ahead with this
breaking change, possibly disabling variable resolution for ox-org only.

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