Re: org code and error catching

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

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

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

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

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

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

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

Re: emphases in Org Agenda View

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

emphases in Org Agenda View

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

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 >

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

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

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

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

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

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')

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

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

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')

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,

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

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

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