[BUG] commit 7048876f broke Figure link with caption [9.6 (release_9.6 @ /Users/powellb/src/org-mode/lisp/)]

[Brian Powell]

It seems that the following commit broke the ability to link to a figure
with a caption.

  commit 7048876f6fa519513763c83bc5baa791420cddab
  Author: Ihor Radchenko 
  Date:   Tue Dec 13 11:44:22 2022 +0300

  org-export-get-ordinal: Do not ignore ELEMENT type when TYPES is given

  * lisp/ox.el (org-export-get-ordinal): Append ELEMENT type to TYPES,
  when TYPES is non-nil.

I have a simple file with a figure and image link. The figure has a
#+name and #+caption. If I add a link to the figure name in the
document, then exporting to HTML fails. Prior commits did not have any issue.

Using `emacs -Q` with the following:

(add-to-list 'load-path "/Users/powellb/src/org-mode/lisp")
(require 'org)

With the following sample file:

#+TITLE:   test
#+AUTHOR:  Me
#+EMAIL:   email
#+DATE:


#+name: fig:parcel
#+caption: Illustration of joy
#+attr_html: :width 600px
#+attr_org: :width 50px
#+attr_latex: :width 3.5in
[[file:./test.png]]

Done!

So, Figure [[fig:parcel]] is an illustration of the stuff.

Executing C-c C-e h o : to export to html and open, results in the
attached trace dump.

Cheers,
Brian

Emacs  : GNU Emacs 29.0.60 (build 1, aarch64-apple-darwin22.2.0, NS 
appkit-2299.30 Version 13.1 (Build 22C65))
 of 2022-12-16
Package: Org mode version 9.6 (release_9.6 @ /Users/powellb/src/org-mode/lisp/)


Debugger entered--Lisp error: (wrong-type-argument listp (link . link))
  memq(section (link . link))
  (if (memq --type types) (progn (let ((result (funcall fun --data))) (cond 
((not result)) (first-match (throw :--map-first-match result)) (t (setq --acc 
(cons result --acc)))
  (cond ((not --data)) ((and info (memq --data --ignore-list))) ((not --type) 
(mapc --walk-tree --data)) ((eq --type 'org-data) (mapc --walk-tree 
(org-element-contents --data))) (t (if (memq --type types) (progn (let ((result 
(funcall fun --data))) (cond ((not result)) (first-match (throw 
:--map-first-match result)) (t (setq --acc ...)) (if (and (eq --category 
'objects) (not (stringp --data))) (progn (let ((tail (cdr ...))) (while tail 
(let (...) (funcall --walk-tree ...) (setq tail ...)) (if (and 
with-affiliated (eq --category 'objects) (eq (org-element-class --data) 
'element)) (progn (let ((tail org-element--parsed-properties-alist)) (while 
tail (let (...) (let ... ...) (setq tail ...)) (cond ((memq --type 
no-recursion)) ((not (org-element-contents --data))) ((and (eq --category 
'greater-elements) (not (memq --type org-element-greater-elements ((and (eq 
--category 'elements) (eq (org-element-class --data) 'object))) (t (mapc 
--walk-tree (org-element-contents --data))
  (let ((--type (org-element-type --data))) (cond ((not --data)) ((and info 
(memq --data --ignore-list))) ((not --type) (mapc --walk-tree --data)) ((eq 
--type 'org-data) (mapc --walk-tree (org-element-contents --data))) (t (if 
(memq --type types) (progn (let ((result ...)) (cond (...) (first-match ...) (t 
...) (if (and (eq --category 'objects) (not (stringp --data))) (progn (let 
((tail ...)) (while tail (let ... ... ...) (if (and with-affiliated (eq 
--category 'objects) (eq (org-element-class --data) 'element)) (progn (let 
((tail org-element--parsed-properties-alist)) (while tail (let ... ... ...) 
(cond ((memq --type no-recursion)) ((not (org-element-contents --data))) ((and 
(eq --category 'greater-elements) (not (memq --type 
org-element-greater-elements ((and (eq --category 'elements) (eq 
(org-element-class --data) 'object))) (t (mapc --walk-tree 
(org-element-contents --data)))
  (closure ((--walk-tree . #0) (--acc) (--ignore-list) (--category . objects) 
(no-recursion) (types link . link) (with-affiliated) (first-match . 
first-match) (info :export-options nil :back-end ... :translate-alist ... 
:exported-data # :input-buffer "newtest.org" 
:input-file "/Users/powellb/tmp/new..." :html-doctype "xhtml-strict" 
:html-container "div" :html-content-class "content" :description nil :keywords 
...) (fun closure ... ... ...)) (--data) (let (...) (cond ... ... ... ... 
...)))((section (:begin 1 :end 307 :contents-begin 1 :contents-end 307 
:robust-begin 1 :robust-end 305 :post-blank 0 :post-affiliated 1 :mode 
first-section :granularity nil :parent (org-data (:begin 1 :contents-begin 1 
:contents-end 307 :end 307 :robust-begin 3 :robust-end 305 :post-blank 0 
:post-affiliated 1 :path "/Users/powellb/tmp/newtest.org" :mode org-data 
:CATEGORY "newtest" :granularity nil) #1)) (keyword (:key "TITLE" :value "test" 
:begin 1 :end 21 :post-blank 0 :post-affiliated 1 :mode top-comment 
:granularity nil :parent #1)) (keyword (:key "AUTHOR" :value "Brian Powell" 
:begin 21 :end 49 :post-blank 0 :post-affiliated 21 :mode nil :granularity nil 
:parent #1)) (keyword (:key "EMAIL" :value "powe...@hawaii.edu" :begin 49 :end 
83 :post-blank 0 :post-affiliated 49 :mode nil :granularity nil :parent #1)) 
(keyword (:key 

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

[Tim Cross]

Ihor Radchenko  writes:

> Tim Cross  writes:
>
>> Based on the information in section 17.13, how do I configure my Emacs
>> so that
>>
>> 1. All the code in the files I wrote just runs and doesn't bother me with
>> annoying execute questions.
>>
>> 2. Code in files from colleagues is shown to me and I'm asked if it
>> should be executed. Once I say yes, I don't want to be bothered about it
>> again i.e. next time I open that file, I want org mode to know I trust
>> it.
>>
>> 3. Absolutely no code in files which are not from the two preceding
>> sources is to be executed unless I explicitly approve it. 
>
> Not yet, but I hope that we can integrate the approach we use in
> `org-safe-remote-resources' and `org--confirm-resource-safe'.
>
>> It feels like what we currently have is a selection of disconnect knobs
>> which the user can tweak, but with no over-arching mechanism to help
>> manage these settings for various scenarios.
>
> Agree. I hope that we can slowly work towards connecting these knobs.
>
>> Finally, are we 100% certain that these different code evaluation
>> circumstances are the only ones? Can we be certain there isn't areas
>> where options or variables are set which couldn't be used to evaluate
>> code (similar to be previously identified execution of code in block
>> headers which occurred before the checks on code evaluation?)?  
>
> No, we can't. But it is true for any software that allows third-party
> code, not just for Org or even Emacs.
>

Yes, you are right there are no guarantees. However, I do feel that if
we are going to add this security layer, we also need to perform some
form of audit and documentation of the specific points where org
constructs will/can trigger evaluation of included code. As the bug with
rich text demonstrated, there will likely be corner cases we
miss. However, we should at least try to identify as many as possible
and document them (and include automated tests when possible).

One of the downsides regarding improved security controls is that it
raises the level of expectations. We need to try and ensure we meet
those expectations. What we really need are some good ethical hackers to
help us identify potential 'hot spots'. The ability to do this
effectively does involve a particular type of mind set and skills not
necessarily common amongst most users. 

> And we cannot use the more universal sandbox approach either. Not in
> Emacs.
>
>> It also feels like the approach we have taken here is almost a throwback
>> to a past era where he had a lot more trust. What we seem to have is
>> protection against accidental execution of code rather than protection
>> against code with malicious intent which has been crafted to be
>> difficult to spot and deliberately takes advantages of small 'holes' or
>> over-sight in the controls supplied.
>
> I do not think that we can do anything about crafted code in Emacs other
> than displaying that code and letting the user decide.
>

Agreed. What we need next is the ability to track those decisions so
that the user isn't nagged about the same things every time and the
ability to set different defaults based on some preference (such as
source/origin, location, etc. 

> And I haven't seen any better solution, except anti-virus scanners that
> are constantly fighting new malicious code.
>
> At least, we do show the code. It is already better than "yes/no"
> dialogue you get when running random executable on Windows.

Agree. The question is whether we actually do provide that y-n and
display in sufficient situations. 

Given the additional information you provided, I'm somewhat less
concerned.

These 'knobs' definitely do need some form of additional abstraction
which will more easily allow end users to set a basic policy regarding
the treatment of different org files or org files from different
sources. I suspect, in the long-term, we are likely to need some type of
file 'cookie' i.e. a local-variable setting which will either set the
policy for that file or set the origin/source/trust level etc so that whatever
security policy the user has defined can be applied. IN some ways,
similar to the 'cookie' placed into your custom variables when you say
you trust some new theme.

Re: [BUG] exporting links with underscores

[Leo Butler]

On Sat, Dec 17 2022, Mike Gauland  wrote:

> On 17/12/22 11:32, Leo Butler wrote:
>> Org version is 9.5.2; emacs version is 27.1.
>>
>> The manual does not indicate that underscores need to be escaped in
>> links (and they can't be, as far as I can tell). The latex and html
>> exporters interpret them as the start of a subscript.
>>
>> Leo
>>
> By default underscore is treated that way--see the "Subscripts and 
> Superscripts" section of the manual 
> (https://orgmode.org/manual/Subscripts-and-Superscripts.html).

Thanks, I was looking at the section on links.

>
> Set the '^' option to 'nil' to get the behaviour you're after:
>
> #+OPTIONS: toc:nil num:nil ^:nil
>
> If you want a subscript anywhere, you can get that by using curly braces 
> (e.g., ex_{ample}).

Thanks for the tip and my apologies for the noise.

Best,
Leo

Re: bug#59882: Multiple versions of Org in load-path problem

[Stefan Monnier]

> - "emacs -l org" to simulate a regular user session with some opened files.
> - Update to Org-9.6 from ELPA.
> - Close emacs and start it again "emacs -l org"
>
> Result:
> byte-code: Invalid function: org-assert-version

Hmm... there's code in `package.el` intended to avoid that problem, but
clearly it's failing here.  Could Someone™ investigate why that code
doesn't do its job.

The code in question is in `package--reload-previously-loaded` and
my understanding is that it should cause `org-macs` to be reloaded from
the Org-9.6 version of the code before the new code gets compiled, and
that new version does define the `org-assert-version` version, so those
macro calls should then be compiled correctly.

[ The approach used in `package--reload-previously-loaded` has its
  weaknesses, but AFAIK it *should* be able to avoid the above error.  ]


Stefan

Re: bug#59882: Multiple versions of Org in load-path problem

[Max Nikulin]

On 16/12/2022 21:47, Ihor Radchenko wrote:

Can it happen that already loaded version affects compilation of a new
version by package-install.


Yes. It is what appears to be happening:

https://irreal.org/blog/?p=10996
https://irreal.org/blog/?p=10999


I would not call it steps to reproduce.

From my point of view, there is a number of issues with updating of 
packages from emacs session.


1. If compilation of a package failed then it is not withdrawn from the 
load path.


2. There is no reliable way to determine if package compilation failed. 
(byte-recompile-directory DIR 0 t) returns human readable string, not 
signalling an error or returning a value convenient to check in the 
code. It is the cause of the previous issue.


3. Emacs package system is not ready for complex multifile packages 
containing macro definitions. It does not push user to update packages 
just after emacs restart in a clean state. As a result, files may be 
compiled with old or missed macro definitions.


4. Because of the item 2 a package has no chance to implement reliable 
internal sanity check that prevents updating to a broken state.


I have tried the following in Emacs-27. For Emacs >= 29 add -L to Org <= 
9.5.


- "emacs -l org" to simulate a regular user session with some opened files.
- Update to Org-9.6 from ELPA.
- Close emacs and start it again "emacs -l org"

Result:
byte-code: Invalid function: org-assert-version

Notice attempt to load Org-9.6 despite warnings and even error during 
update:



Compiling file /home/emcs/.emacs.d/elpa/org-9.6/ob-C.el at Sun Dec 18 04:30:49 
2022
Entering directory ‘/home/emcs/.emacs.d/elpa/org-9.6/’

In end of data:
ob-C.el:509:1:Warning: the function ‘org-assert-version’ is not known to be
defined. 

...

Compiling file /home/emcs/.emacs.d/elpa/org-9.6/ob-matlab.el at Sun Dec 18 
04:30:50 2022
ob-matlab.el:43:1:Error: Symbol’s function definition is void: 
org-assert-version


So emacs can not handle update of a package with changed macro 
definitions when they reside in another package file.

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

[Justin Silverman]

That makes sense. Yes it breaks some of my snippets which have a condition 
texmathp (I don't write latex without enclosing in latex math environment in 
org).
Its an easy enough fix for me though:

(add-hook 'org-cdlatex-mode-hook
  (lambda () (advice-remove 'texmathp 'org--math-always-on)))

does the trick.

Justin 

Ihor Radchenko  writes:

> Justin Silverman  writes:
>
>> Thanks for the quick response. I just had a chance to check it out. 
>> Unfortunately (unless I am mistaken), with the change, `texmathp' is now 
>> always returning t... which is not very helpful.
>
> Not exactly. I just tried to follow the docstring
>
> (defun org--math-always-on (orig-fun  args)
>   "Always return t in Org buffers.
> This is because we want to insert math symbols without dollars even outside
> the LaTeX math segments.  If Org mode thinks that point is actually inside
> an embedded LaTeX fragment, let `texmathp' do its job.
> `\\[org-cdlatex-mode-map]'"
>
> So, `texmathp' will return t outside latex, inside inline latex, and
> _maybe_ inside latex environments. Only inside latex environments, Org
> delegates the job to `textmathp'.
>
> Let me know if this change broke any real workflows.

Re: Problems with C-c C-e file.org

[Ihor Radchenko]

andre duarte bueno  writes:

> When I try to export file.org  using C-c C-e the window with the list of
> possibilities appears. But it appears incomplete(visualization), so I try
> to use the mouse to view the other export options and the system is
> completely blocked. Every mouse click is captured and displayed in the
> command window. And it doesn't allow you to do anything else. I am forced
> to cancel the command without completing it.
> Apparently C-c C-e is capturing all events and not just keyboard events!

This is because we use `read-char-exclusive'.
Another option could be `read-char', but that would make clicking work
as C-g.

Alternative menu designs have been discussed in
https://list.orgmode.org/orgmode/am9pr09mb497743d21fa1c908392413f496...@am9pr09mb4977.eurprd09.prod.outlook.com/

... but they are not easy to implement.

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

Re: Minor rendering issues in the Org Mode Compact Guide

[Ihor Radchenko]

Cauim de Souza Lima  writes:

> Hi, Org mode maintainers,
>
> While reading the compact guide, I found a couple of minor rendering issues:

Thanks for reporting!

Fixed on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=12e10eb0d

> These issues seem to be present in the HTML and in the PDF versions of the
> manual.
>
> I'd be happy to fix the issues myself but I'd need pointers.

Mmm.. I was too quick to fix these as I was reading your email.
Org documentation is mostly written using Org itself.
To fix these issues, I edited doc/org-guide.org, which is exported to
html/pdf/info output.

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

Re: [PATCH][WORG] Fixes broken link to worg sources

[Ihor Radchenko]

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

> Hello,
>
> the attached patch fixes a broken link to the worg sources.
>
> Best regards -- Gerard
> diff --git a/index.org b/index.org
> index 84f69eea..8c6de883 100644
> --- a/index.org
> +++ b/index.org
> @@ -138,7 +138,7 @@ You can help us dedicate more of our time by making a 
> donation or by
>  - [[file:worg-editing.org][Conventions and tools for editing Worg]]
>  - [[file:worg-git-ssh-key.org][How to create your own SSH key?]]
>  - [[https://git.sr.ht/~bzg/worg/log][Recent changes to Worg]]
> -- [[https://orgmode.org/worg/sources/][Org-mode source documents of all Worg 
> pages]]
> +- [[https://git.sr.ht/~bzg/worg/tree][Org-mode source documents of all Worg 
> pages]]
>  - [[file:archive/index.org][The archive]] (obsolete content)

Thanks!
Applied onto master.
https://git.sr.ht/~bzg/worg/commit/9346ccc4

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

Re: Bug? org-assert-version does not prevent mixed install

[Ihor Radchenko]

Max Nikulin  writes:

>> We might do something like
>> 
>> (eval-and-compile (org-assert-version))
>
> This will give obscure error during compiling since `org-assert-version' 
> is not defined.
>
> Unsure what will happen during load of the org.el file since org.elc is 
> not produced. Perhaps the same cryptic error, but I can not explain it.

Yes, but we will at least abort the compilation this way.

> My idea (unchecked)
>
> ;; Remove when support of Emacs-29 is dropped.
> (unless (fboundp 'org-assert-version)
>(error "Org is compiled or loaded while older version loaded already. 
>   Please, ensure that no other org versions are loaded and recompile."))

I guess we can use the same error with what `org-assert-version' itself
throws:

(error "Org version mismatch.  Make sure that correct `load-path' is set early 
in init.el")

If you can, please check it. (AFAIU, you do have a setup where you can
reproduce the installation problem)

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

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

[Ihor Radchenko]

Tim Cross  writes:

> Based on the information in section 17.13, how do I configure my Emacs
> so that
>
> 1. All the code in the files I wrote just runs and doesn't bother me with
> annoying execute questions.
>
> 2. Code in files from colleagues is shown to me and I'm asked if it
> should be executed. Once I say yes, I don't want to be bothered about it
> again i.e. next time I open that file, I want org mode to know I trust
> it.
>
> 3. Absolutely no code in files which are not from the two preceding
> sources is to be executed unless I explicitly approve it. 

Not yet, but I hope that we can integrate the approach we use in
`org-safe-remote-resources' and `org--confirm-resource-safe'.

> It feels like what we currently have is a selection of disconnect knobs
> which the user can tweak, but with no over-arching mechanism to help
> manage these settings for various scenarios.

Agree. I hope that we can slowly work towards connecting these knobs.

> Finally, are we 100% certain that these different code evaluation
> circumstances are the only ones? Can we be certain there isn't areas
> where options or variables are set which couldn't be used to evaluate
> code (similar to be previously identified execution of code in block
> headers which occurred before the checks on code evaluation?)?  

No, we can't. But it is true for any software that allows third-party
code, not just for Org or even Emacs.

And we cannot use the more universal sandbox approach either. Not in
Emacs.

> It also feels like the approach we have taken here is almost a throwback
> to a past era where he had a lot more trust. What we seem to have is
> protection against accidental execution of code rather than protection
> against code with malicious intent which has been crafted to be
> difficult to spot and deliberately takes advantages of small 'holes' or
> over-sight in the controls supplied.

I do not think that we can do anything about crafted code in Emacs other
than displaying that code and letting the user decide.

And I haven't seen any better solution, except anti-virus scanners that
are constantly fighting new malicious code.

At least, we do show the code. It is already better than "yes/no"
dialogue you get when running random executable on Windows.

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

Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

[Ihor Radchenko]

Max Nikulin  writes:

>> I disagree. If anything, we can set the default value of
>> `org-confirm-babel-evaluate-cell' to nil and apply this patch.
>> 
>> Then, we can get the old behaviour back yet allowing concerned users to
>> have more security.
>
> I am leaving it up to you. Form my point of view it will be dead code 
> that increases complexity with no practical outcome. Unfortunately 
> setting `org-confirm-babel-evaluate-cell' to anything other than nil 
> results in annoyance rather than security.

To clarify, I do not consider this patch to be the end state of security
handling. I do plan to extend the code evaluation query in a way that it
can be used to allow "All" in current command call, session, + mark
files as safe, similar to `org--confirm-resource-safe'.

Just not yet in this release.

So, I don't think that the code is going to be dead.

The new variable is also in line with the existing
`org-link-elisp-confirm-function', `org-link-shell-confirm-function',
and `org-confirm-babel-evaluate'.

> Perhaps advising `org-babel-execute-src-block' with `y-or-n-p' is a 
> better treatment for my paranoia.

Emm. No? The main issue with `y-or-n-p' is that it treats  as
"yes". I have pressed  painstakingly in prompts too many times to
consider y-or-n-p safe.

>> This patch does not only affect src blocks. It affects all the users of
>> `org-babel-read'.
>
> Mostly it is called with INHIBIT-LISP-EVAL set to t.

No, not really. From skimming through grep buffer, most of the calls are
not inhibiting `eval'.

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

Re: Bug? org-assert-version does not prevent mixed install

[Max Nikulin]

On 18/12/2022 20:04, Ihor Radchenko wrote:

Max Nikulin writes:


It is possible to convert the error to a better one by checking if
`org-assert-version' is bound in org.el.


We might do something like

(eval-and-compile (org-assert-version))


This will give obscure error during compiling since `org-assert-version' 
is not defined.


Unsure what will happen during load of the org.el file since org.elc is 
not produced. Perhaps the same cryptic error, but I can not explain it.


My idea (unchecked)

;; Remove when support of Emacs-29 is dropped.
(unless (fboundp 'org-assert-version)
  (error "Org is compiled or loaded while older version loaded already. 
 Please, ensure that no other org versions are loaded and recompile."))

Re: Failing to load, showing this 'Symbol's function definition is void: defvar-1'

[Sharon Kimble]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Tim Cross  writes:

> Sharon Kimble  writes:
>
>> I unfortunately upgraded this morning to emacs-30.0.50, and since then I 
>> can't get into my usual emacs of 29.0.50. 
>>
>> When I'm loading emacs-29.0.50 from /usr/local/bin/ it is consistently 
>> failing to load
>> saying "Symbol's function definition is void: defvar-1".
>>
>> My init.el is this -
>> 
>> ;;; init.el --- sharon's config -*- eval: (read-only-mode 1) -*-
>> ;; Make sure that Git version of Org mode is being loaded instead of the 
>> built-in version.
>> (add-to-list 'load-path (expand-file-name 
>> "/home/boudiccas/.emacs.d/elpa/org-9.5.5"))
>> ;;;(add-to-list 'load-path (expand-file-name 
>> "/home/boudiccas/.emacs.d/elpa/org-9.6"))
>> (add-to-list 'load-path (expand-file-name 
>> "/home/boudiccas/git/org-contrib/lisp"))
>>
>> (require 'package)
>> (setq package-enable-at-startup nil)
>> (package-initialize)
>>
>>
>> (require 'ob-tangle)
>> (org-babel-load-file "/home/boudiccas/.emacs.d/config22-2.org")
>> 
>>
>> It seems to be baulking at the last 2 lines, can somebody help please?
>>
>> Thanks
>>Sharon.
>
> Emacs 30.0.50 is the bleeding edge of the development tree. It will be
> unstable by definition. The error you are getting looks like an internal
> Emacs error unrelated to org mode.
>
> I would wait a day or so and pull new sources and re-build to see if the
> issue is fixed. If not, log a bug report.
>
> If a working Emacs is critical to your activities, I would revert back
> to 28.2 or maybe 29, which is in pre-release state, so a little more
> stable than the bleeding edge dev code. Note that there is an Emacs 29
> branch, so you can checkout emacs-29 to get the most recent release
> candidate for Emacs 29.
>
> In general, org mode won't attempt to fix issues introduced in the HEAD
> soruces of Emacs as these sources tend to be in flux and issues will
> often be resolved by other non-org specific changes. Issues at this
> level tend to be a 'wait and see'. 

Thanks for replying Tim, and as you can see I'm back in emacs.

I know that building emacs isn't part of org-modes mailing list setup, but it 
looked like '(require 'ob-tangle)' was causing the problem, hence I asked the 
org-mode mailing list.
  
For the benefit of the archives these are the steps I took -
  
  
make clean
make distclean
sudo make clean
sudo make distclean
delete /home/foo/git/emacs
git clone -b master git://git.sv.gnu.org/emacs.git
cd git/emacs
git checkout origin
git checkout emacs-29
/autogen.sh
configure
make
src/emacs -Q ;;; if this works, then try loading emacs, and if that works, then 
bobs your uncle!
sudo make install
  

This is because I'd got a failed build and install, so it all needed clearing 
out before I could delete the failed emacs git download, so it needed a fresh 
download.

Anyway, I've learnt from my mistake and have documented it all just in case I 
do it again.

Thanks
  Sharon.
- -- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk
Debian 11.5, fluxbox 1.3.7, emacs 29.0.60, org 9.5.5 
-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAmOfHKMdHGJvdWRpY2Nh
c0Bza2ltYmxlMDkucGx1cy5jb20ACgkQNoGAGQr4g1ttMg//YqH3l+FBRjrZySmW
OEE4YPEqCh4vDCoRhXd9iiybpvMHCDlqk1lWlR6cEqL9Fd0487N9VCFqRNHSvbtt
2La7rsVhholHVCYGuu9EIl20ogpty8O1IQgMMySm+v7pKu1Wch1djAzLcT1bxdAX
v2BC8M6aNRimA67/cGO+xav8m7fhrtRXPXCjMTXzCp5Bb9qzvrMnt6sIU+r88+QW
W1znPB2NOHxexHoXDxJZXWXqVVlXIUOlYAFmK0hQ079z2w7tveuDlBVcLFXOYbbR
2J9a0dRbE/bSJVFDUDs7BLRZdEXOLyjy9ijdK2KBH5RfbDoO3zfqpZfbLXZlcy5R
ONhqRQvxQzV6Chkc5cYq3HLQlrmzbIU2SGZeZ4lQxPCBlCuWagtr94QTVScFNudj
ufyqtmm4zcOuFBKrQ5MSiqXfNv3XGAnNj2cgQ8M1XaPiVUl6oMQtWNWtkJ0kurZD
5UDAliqWMoefjl0T+p23VIKvwwiPdc4YCAxCi0PgvoTQGx/FxBSgecDh9a/6fZjm
XCzn7TQr90GGYA7VkNy0tUiW/8shqQBQaRmhNLQ03/ZIBxBB10IgX63xc9HK32ev
CBfRZubfjUWKJ4vRxvha149bCcg9FQy9rsCSN4OCYxXh95nUhJJlr6PD30jnnHY1
E4zflSI+cLcpB9p6l3d7Z86uvOk=
=5Wpq
-END PGP SIGNATURE-

Re: [BUG] org-latex-src-block-backend is directly used as variable instead of querying export option (was: [Syntax discussion] Should we treat src blocks without LANG as paragraphs?)

[Timothy]

Hi Ihor and Max,

>> P.S. I have accidentally noticed a suspicious line. I have not tried if
>> it is real bug, but in `org-latex-make-preamble’ I expect a property
>> obtained from the INFO argument, not global variable:
>>
>> lisp/ox-latex.el:2014: (when (and (eq org-latex-src-block-backend
>> ’engraved)
>
> Confirmed.
> Timothy?

I can’t find this in my personal dev branch, but I can see it at
.
It seems I resolved this in
.

Hmmm, the generated preamble commits seem fairly solid now from my usage, so I’m
not sure if it’s worth fixing this separately or presenting the generated
preamble patch for review on this ML.

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

Re: Bug: Function org-heading-components is not resilient [9.4.3 (9.4.3-elpa @ /home/data1/protected/.emacs.d/elpa/org-20201216/)]

[Ihor Radchenko]

Jean Louis  writes:

> Org commands could get slowly or speedy adopted not to be shown in
> other modes by using the recent development of the command
> `interactive'
>
> interactive is a special form in ‘C source code’.
>
> (interactive  ARG-DESCRIPTOR  MODES)
>
> If MODES is present, it should be a list of mode names (symbols) that
> this command is applicable for.  The main effect of this is that
> ‘M-x TAB’ (by default) won’t list this command if the current buffer’s
> mode doesn’t match the list.  That is, if either the major mode isn’t
> derived from them, or (when it’s a minor mode) the mode isn’t in effect.

We can only do it once we stop supporting Emacs 27, where MODES argument
is not yet available.

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

[BUG] org-latex-src-block-backend is directly used as variable instead of querying export option (was: [Syntax discussion] Should we treat src blocks without LANG as paragraphs?)

[Ihor Radchenko]

Max Nikulin  writes:

> P.S. I have accidentally noticed a suspicious line. I have not tried if 
> it is real bug, but in `org-latex-make-preamble' I expect a property 
> obtained from the INFO argument, not global variable:
>
> lisp/ox-latex.el:2014: (when (and (eq org-latex-src-block-backend 
> 'engraved)

Confirmed.
Timothy?

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

Re: Agenda View Export with Clocking Gaps

[Ihor Radchenko]

Yifan Zhu  writes:

> In agenda view, all clocking gaps can be found by turning on 
> [c]lockcheck. However, if we export the agenda view (C-x C-w 
> (|org-agenda-write|) to a html file, the clocking gaps don't show up in 
> the resultant file. Is there anyway to include the clocking gaps in the 
> exported file?

AFAIK, org-agenda relies on htmlize to save the agenda buffer into html.
I do not recall if htmlize supports overlays or not.
If htmlize does, please provide a reproducer (see
https://orgmode.org/manual/Feedback.html#Feedback), so that we can check
if the problem is on org-agenda side.

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

[Feature] Store heading properties remotely, outside the Org file (was: Completely hide properties drawer in 9.6)

[Ihor Radchenko]

Below is the idea how one can store heading properties in a separate
file or even database.

I think it might be of interest for users who hate property drawer
clutter yet needed to store some metadata associated with Org headings.

To be consistent with Org internal logic, we may, instead of using ID,
use a separate :INCLUDE-PROPERTIES: heading property to define where the
additional heading properties are stored.

If a heading has :INCLUDE-PROPERTIES:, the properties will be calculated
according to: (1) heading property drawer; (2) INCLUDE-PROPERTIES value;
(3) parent headings, if property inheritance is enabled.

The value of INCLUDE-PROPERTIES might be a file:/id: link that may point to
another Org heading, or, potentially (maybe via third-party packages),
to SQL database.

Jean Louis  writes:

> To me it is very practical to have this simple heading with a drawer
> that is completely hidden, which references by using UUID to a complex
> set of properties. To somebody else, that may not be useful or is
> abstract to understand.
>
> In my work I would not like having more properties for Org heading but
> one, like this one:
>
> * My heading
>   :PROPERTIES:
>   :ID: 944334aa-acab-4e6a-8dd6-ebfd144eac6b
>   :END:
>
> And that alone would be a reference to any other property that I
> personally may need. It is a link from heading to relations to many
> different pieces of information. 
> ...
> Emacs 29 has SQLite built-in, there is PostgreSQL module and also
> rcd-hash-edit package that works in similar way as shown on
> video. Hashes may easily be stored in text files and read from text files. 
> ...
> And by thinking that, it is also possible to make Org functions that save 
> properties in separate Org file automatically. 
>
> In case of the heading like this:
>
> * My heading
>   :PROPERTIES:
>   :ID: 944334aa-acab-4e6a-8dd6-ebfd144eac6b
>   :END:
>
> One could have a separate Org file that is used only to write properties, and 
> which could contain something like following:
>
> * 944334aa-acab-4e6a-8dd6-ebfd144eac6b
>   :PROPERTIES:
>   :DATE-CREATED: 2022-12-18
>   :PERSON-RELATED: Ihor Radchenko
>   :END:
>
> There are many reasons why properties should be hidden or separate
> from Org file, apart from aesthetics and readability. I have been
> sharing Org files and headings too many times to staff members
> (without export), and then why should other person see clocked or
> scheduled properties if such are not meant for that person?
>
> The above eloboration demonstrates that properties could not only be
> hidden from main view, but become structural and organized collection
> of data. Storage is possible into PostgreSQL by using emacs-libpq
> module or PostgreSQL packages, in Emacs 29 by using the built-in
> SQLite or SQLite packages, or cdb database or key/value databases, or
> by storing hashes into files, or by storing properties into separate
> Org files.
>
> Implementation is close to fingertips.
>
> Generally, using properties and UUIDs as references to properties,
> also liberates properties from Org mode and gives the power of
> referencing to any kind of text or mode.
>
> That means, having Markdown file with commented UUID, could allow the
> user to have the same properties as in Org mode, one could freely tag,
> clock-in, clock-out, schedule, deadline, etc. any kind of Markdown
> heading, whatabout Asciidoc, truly plain text, HTML pieces, Wiki, and
> other formats and files.
>
> In normal text files, I would then make UUIDs invisible inside of
> Emacs, when necessary:
>
> (defun rcd-uuid-reference-make-invisible ()
>   "Make all UUIDs in buffer invisible."
>   (interactive)
>   (save-excursion
> (goto-char (point-min))
> (while (search-forward-regexp thing-at-point-uuid-regexp nil t)
>   (when (thing-at-point 'uuid)
>   (facemenu-set-invisible (match-beginning 0) (match-end 0))
>
> ;; df2c9f4d-77ab-4697-842e-d7aa31ffeee3
>
> If UUIDs are disturbing in the output, then I would have a filter to
> export the file without UUIDs, when necessary.


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

Re: PATCH: include controlling language= in my previous patch

[Ihor Radchenko]

Ihor Radchenko  writes:

> Pedro Andres Aranda Gutierrez  writes:
>
>> Next try... I'm learning a lot :-)
>
> Then, next set of comments.

As discussed privately, I have addressed the comments myself.
Now applied onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0c467b6b8
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=322b2fd22
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a58ab9039

You are also now listed as an Org contributor.
https://git.sr.ht/~bzg/worg/commit/37b511a9

Thanks for your contribution!

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

Re: [BUG] Org-9.6 declares compatibility with Emacs-25.1

[Ihor Radchenko]

Max Nikulin  writes:

> lisp/org.el:10:;; Package-Requires: ((emacs "25.1"))

We should indeed bump the minimal required Emacs version.
Should we use Emacs 26.3 as the minimal version?

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

Re: Bug? org-assert-version does not prevent mixed install

[Ihor Radchenko]

Max Nikulin  writes:

> Is it possible to signal a fatal error during installing using emacs 
> machinery to prevent broken user configuration? My expectation that 
> result of failed compilation is ignored by emacs.
>
> It is possible to convert the error to a better one by checking if 
> `org-assert-version' is bound in org.el.

We might do something like

(eval-and-compile (org-assert-version))

> I think, the following topics are more suitable for emacs bug tracker or 
> devel mail list:
> - how to compile packages to avoid issues with already loaded older 
> packages,
> - what changes are required in package management to roll back failed 
> attempt of installing.

Since you have a recipe to reproduce, could you please post it to Emacs
debbugs? If we can clearly demonstrate the problem to Emacs devs, there
is more chance that they can fix it. Ideally, in the coming Emacs 29
release.

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

Re: [MAINTENANCE] Do we have any backwards-compatibility policy for third-party packages?

[Ihor Radchenko]

Ihor Radchenko  writes:

> Ok. Here are the tentative patches for Org manual and WORG maintenance
> page.

Applied.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=dd4e06ddc
https://git.sr.ht/~bzg/worg/commit/432828ce

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

Re: Babel (scheme): Evaluation errors are not shown

[Ihor Radchenko]

Marc Nieper-Wißkirchen  writes:

> When I evaluate erroneous code of an Elisp code block like
>
> #+BEGIN_SRC elisp
> (x)
> #+END_SRC
>
> I see the error message ("Symbol's function definition is void: x") in
> the minibuffer (and in the *Messages* buffer).
>
> This is not the case with Scheme code blocks; evaluating the code block
>
> #+BEGIN_SRC scheme
> (x)
> #+END_SRC
>
> just gives "Code block evaluation complete (took 0.2s)." in the
> minibuffer (and in the *Messages* buffer).
>
> Is this a known error? Or is there a way to enable error messages?

ob-scheme.el relies on geiser library to handle code execution.
I do not know if it is possible to retrieve error messages using geiser
functions. You may check out `org-babel-scheme-execute-with-geiser' and
see if something can be done.

Note that we currently have no maintainer for ob-scheme and hence can
only provide very limited support. New features are hard for us without
experience with scheme and geiser.

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

Re: [FR] Add support for racket images in org-babel

[Ihor Radchenko]

dalanicolai  writes:

> I have not asked anywhere yet, but I do not know a 'standard org-mode' way
> to make org-mode show the plot images. Racket creates a temp image file and
> returns a string that includes the path to the file. The actual format of
> the string is:
>
> "\"#\""
>
> I could create a patch for it, but I am not sure how to best implement it
> (in a clean way).

You likely need to extend `org-babel-scheme--table-or-string' to
understand Image: type.

> however, it would be great if support could be added to ob-scheme itself.
> I would be happy to do it, but as mentioned before I don't think I know how
> to do it in the proper way. I would probably just add a condition around the
> 'result' in 'org-babel-execute:scheme' as follows:

I do not know much about scheme.

Generally, ob-* libraries try their best to convert native language
types to Elisp. If # is something that is unambiguously
identified as image file, I do not see why we cannot support it,
converting the # representation to file link. Especially,
when users request :results file.

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

Re: Bash results broken?

[Ihor Radchenko]

Ihor Radchenko  writes:

> Confirmed.

Fixed on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=224799875

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

[PATCH][WORG] replaces broken javascript with link

[gerard . vermeulen]

Hello,

the attached patch replaces a snippet of broken javascript code with an 
org-mode link.


Best regards -- Gerard

worg-org-issues-replace-broken-javascript-with-link.patch
Description: Binary data

[PATCH][WORG] Fixes broken link to worg sources

[gerard . vermeulen]

Hello,

the attached patch fixes a broken link to the worg sources.

Best regards -- Gerard


worg-broken-link-to-worg-sources.patch
Description: Binary data

Re: PATCH: include controlling language= in my previous patch

[Bastien Guerry]

Sorry for the delay.

Ihor Radchenko  writes:

>> FYI, I have already cleared the FSF paperwork for an emacs patch.
>
> Bastien, could you kindly confirm?

Yes, I do confirm Pedro's FSF paperwork is in order.

Thanks!

-- 
 Bastien

Problems with C-c C-e file.org

[andre duarte bueno]

When I try to export file.org  using C-c C-e the window with the list of
possibilities appears. But it appears incomplete(visualization), so I try
to use the mouse to view the other export options and the system is
completely blocked. Every mouse click is captured and displayed in the
command window. And it doesn't allow you to do anything else. I am forced
to cancel the command without completing it.
Apparently C-c C-e is capturing all events and not just keyboard events!

*André Duarte Bueno*
*Professor Associado LENEP/CCT/UENF*
*Chefe Setor Modelagem Matemática e Computacional*

*UENF* - Universidade Estadual do Norte Fluminense - Darcy Ribeiro
*CCT* - Centro de Ciências e Tecnologias
*LENEP* - Laboratório de Engenharia e Exploração de Petróleo
Rodovia Amaral Peixoto, km 163, Avenida Brenand S/N
CEP:   27925-310 - Imboassica - Macaé - RJ - Brasil
Fone:   +55 (22)  2765-6500 geral / *(22) 2765-6563 *sala / (22)
99954-2635 cel
Fax: +55 (22) 2765-6565
e-mail:  
e-mail institucional: 
Site do Professor:  https://sites.google.com/view/professorandreduartebueno/

Minor rendering issues in the Org Mode Compact Guide

[Cauim de Souza Lima]

Hi, Org mode maintainers,

While reading the compact guide, I found a couple of minor rendering issues:

   - Section 2.2 Visibility Cycling
   : "Org uses just two
   commands, bound to TAB and *{{{kbd{S-TAB)}}}* to change the visibility
   in the buffer."
   - Section 5.2 Multi-state Workflow
   : "You can use
   TODO keywords to indicate *@emph{sequential}* working progress states"
   - Section 8.1 Timestamps :
   "Its presence causes entries to be shown on specific dates in the agenda
   (see *[BROKEN LINK: *The Weekly/daily Agenda]*)."
   - Section 8.4 Clocking Work Time
   : "The l key may be
   used in the agenda (see *[BROKEN LINK: *The Weekly/daily Agenda])* to
   show..."
   - Section 10.2 The Agenda Dispatcher
   : "Create the
   calendar-like agenda (see *[BROKEN LINK: *The Weekly/daily Agenda]*)."

These issues seem to be present in the HTML and in the PDF versions of the
manual.

I'd be happy to fix the issues myself but I'd need pointers.

Thanks,
Cauim

Re: [BUG] Org-9.6 declares compatibility with Emacs-25.1

[Tim Cross]

Timothy  writes:

> Hi Max,
>
>> Notice emacs-25.1 in the elpa package description:
>
> Yea, I’m pretty sure this is just an oversight. This should be bumped to 26.
>

Yep, that would be my assumption as well. Support is for the two
previous releases i.e. 27.x and 26.x.