Re: Requesting a new release of org-contrib.

[Ihor Radchenko]

Malcolm Purvis  writes:

> Emacs 29 and the new main branch (emacs-30) require the 't' 
> condition in a cl-case to be the last entry.  This breaks 
> org-checklist in version 0.4 of org-contrib.
>
> The fix has already been applied 
> (https://git.sr.ht/~bzg/org-contrib/commit/6422b265f1150204f024e33d54f2dcfd8323005c)
>  
> but it is not available in NonGNU ELPA.
>
> Could a new release of org-contrib be made to make the fix widely 
> available?

We had some recent additional fix pending.
Now, done.
https://git.sr.ht/~bzg/org-contrib/commit/d0cebebb301b5de93e9c5228a91e3e4f5d41902b

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

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

[Ihor Radchenko]

Stefan Monnier  writes:

>> Though I believe that org mixed version issue happens due to transitional
>> dependency of some third party package on org or something like (require
>> 'org-protocol) that can not be loaded on demand.
>
> Hmm... indeed the "Subject:" talks about mixed versions, yet I was
> discussing something not directly related.  Looks like I got off-topic
> somewhere along the way without noticing, sorry.

And the off-topic is what has been CCed to Org mailing list :)

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

Re: [BUG] Documentation fix needed in "4.4 External Links" [9.6 ( @ /home/dsmasterson/.emacs.d/elpa/org-9.6/)]

[Ihor Radchenko]

David Masterson  writes:

>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=edd000f3b
>
> Possibly good, but should the docstrings for org-open-at-point,
> org-open-at-mouse and org-open-file be unified in way so that they track
> each other for changes in one of them?

`org-open-at-mouse' simply refers to `org-open-file'.

`org-open-at-point' is a different beast.
This function needs to be refactored into smaller chunks.
Docstring is not the biggest issue there.

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

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

[Stefan Monnier]

Max Nikulin [2022-12-14 23:02:53] wrote:
> On 14/12/2022 21:35, Stefan Monnier wrote:
>>>  Like I said in another message that I sent just before receiving yours
>>>  my conclusion came from the fact that hitting 'C-h v' with the cursor
>>>  on 'org-goto-interface' provided nothing.  It was the first time this
>>>  ever happened to me.  I did try to explicitly enter the variable's
>>>  name by entering 'org-goto', which (like 'org-go') is not
>>>  enough: it is completed to 'org--goto'.
>> AFAICT this is a missing feature: we obey `help-enable-autoload` in
>> `describe-function` but we fail to do the same autoloading dance in
>> `describe-variable`.
>
> I think, the difference is interactive vs. non-interactive calls rather than
> `describe-function' vs. `describe-variable'. What misses this feature is
> `customize-variable'.
>
> Completion failure for "org-to" happened because result of
> `register-definition-prefixes' calls is not considered as options. I am
> aware that it may give false positives, but I still believe they should
> be added.

I'm sorry, but I don't understand what you're saying.

> Though I believe that org mixed version issue happens due to transitional
> dependency of some third party package on org or something like (require
> 'org-protocol) that can not be loaded on demand.

Hmm... indeed the "Subject:" talks about mixed versions, yet I was
discussing something not directly related.  Looks like I got off-topic
somewhere along the way without noticing, sorry.


Stefan

Re: [BUG] Documentation fix needed in "4.4 External Links" [9.6 ( @ /home/dsmasterson/.emacs.d/elpa/org-9.6/)]

[David Masterson]

Ihor Radchenko  writes:

> David Masterson  writes:
>
>> Do you think (some part of) this (semi-)paragraph should be mentioned in
>> the docstring for 'org-open-at-point' (and 'org-open-at-mouse')? I'm of
>> the opinion that, if you walk-thru the docstring links, you would get
>> all the info you'd get in the manual (and more), but not necessarily
>> explained in a user-friendly form,
>
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=edd000f3b

Possibly good, but should the docstrings for org-open-at-point,
org-open-at-mouse and org-open-file be unified in way so that they track
each other for changes in one of them?

-- 
David Masterson

Re: [BUG] ox-html does not export captions of source blocks without language

[Johan Bolmsjö]

On Wed, Dec 14, 2022, at 22:51, Kaushal Modi wrote:
> On Wed, Dec 14, 2022, 4:44 PM Johan Bolmsjö  
> wrote:
>> The caption "Caption 1" is not exported by ox-html in the following
>> source block.
>> 
>> #+caption: Caption 1
>> #+begin_src
>> foo bar baz
>> #+end_src
> 
> The begin_src block always requires a "language" as far as I know. If you 
> don't want to specify a language, you can use #+begin_example instead. 
> 
> You can even do "#+begin_src text".
> 
> It's a different issue as to why you are seeing a different behavior between 
> the two exporters. 

Okay, the manual confirms that the language is mandatory.
https://orgmode.org/manual/Structure-of-Code-Blocks.html

"#+begin_src text" exports the caption with both ox-html and ox-ascii.
"#+begin_example" export the caption with neither ox-html nor ox-ascii.

So the only discrepancy is how the two exporters handles this non-conforming 
source block.

Re: [BUG] ox-html does not export captions of source blocks without language

[Kaushal Modi]

On Wed, Dec 14, 2022, 4:44 PM Johan Bolmsjö 
wrote:

> ** Description
>
> The caption "Caption 1" is not exported by ox-html in the following
> source block.
>
> #+caption: Caption 1
> #+begin_src
> foo bar baz
> #+end_src
>

The begin_src block always requires a "language" as far as I know. If you
don't want to specify a language, you can use #+begin_example instead.

You can even do "#+begin_src text".

It's a different issue as to why you are seeing a different behavior
between the two exporters.

>

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

[Cook, Malcolm]

>On a related note, is it normal that package like org-mouse.el gets
>loaded upon calling C-h f org-mouse-  completion prompt?
>org-mouse.el does not contain a single autoload cookie.

There need not be which is apparently by design:

The autoload happens as a consequence of emacs' documented feature to [Autoload 
by 
Prefix](https://www.gnu.org/software/emacs/manual/html_node/elisp/Autoload-by-Prefix.html)
 

Given that:

(equal (gethash "org-mouse-"  definition-prefixes) '("org-mouse"))

[BUG] ox-html does not export captions of source blocks without language

[Johan Bolmsjö]

** Description

The caption "Caption 1" is not exported by ox-html in the following
source block.

#+caption: Caption 1
#+begin_src
foo bar baz
#+end_src

The caption "Caption 2" is exported by ox-html in the following source
block.

#+caption: Caption 2
#+begin_src sh
  echo foo bar baz
#+end_src

** Expectation

The caption "Caption 1" is exported just as "Caption 2" is. The plain
text exporter ox-ascii exports both "Caption 1" and "Caption 2".

** Version Info

- GNU Emacs 28.2 (build 3, x86_64-pc-linux-gnu, X toolkit, cairo version 
1.16.0, Xaw scroll bars) of 2022-11-19
- Org mode version 9.6 (9.6-gf49ee9 @ /home/johan/.emacs.d/straight/build/org/)

[BUG] org-element--cache: (org-agenda) Cached element is incorrect [9.6 (release_9.6-90-gf49ee9 @ /home/stefan/.emacs.d/contrib/org-mode/lisp/)]

[Stefan]

While trying to reproduce the "Org parser error" error issue (see other 
thread), I got multiple "Cached element is incorrect" warnings (backtrace 
excerpt below).

Here is one that appeared when trying to loading the =t= agenda:

-- quote --

Warning (org-element-cache): org-element--cache: (org-agenda) Cached element is 
incorrect in Media.org. (Cache tic up to date: "yes") Resetting.
If this warning appears regularly, please report the warning text to Org mode 
mailing list (M-x org-submit-bug-report).
The element is: "(headline (:raw-value \"Podcasts\" :begin 684093 :end 741628 
:pre-blank 0 :contents-begin 684104 :contents-end 741627 :robust-begin 684148 
:robust-end 741625 :level 1 :priority nil :tags nil :todo-keyword nil 
:todo-type nil :post-blank 1 :footnote-section-p nil :archivedp nil :commentedp 
nil :post-affiliated 684093 :ID \"podcasts\" :title \"Podcasts\" :mode nil 
:granularity element :cached t :parent (org-data (:begin 1 :contents-begin 1 
:contents-end 746346 :end 746346 :robust-begin 3 :robust-end 746344 :post-blank 
0 :post-affiliated 1 :path \"/home/stefan/PRIVATE/journal/org/Media.org\" :mode 
org-data :CATEGORY \"Media\" :cached t"
 The real element is: "(headline (:raw-value \"Podcasts\" :begin 684093 :end 
740615 :pre-blank 0 :contents-begin 684104 :contents-end 740614 :robust-begin 
684148 :robust-end 740612 :level 1 :priority nil :tags nil :todo-keyword nil 
:todo-type nil :post-blank 1 :footnote-section-p nil :archivedp nil :commentedp 
nil :post-affiliated 684093 :ID \"podcasts\" :title \"Podcasts\" :mode nil 
:granularity element :parent nil))"
 Cache around :begin:
nil
nil
nil Disable showing Disable logging

Warning (org-element-cache): org-element--cache: (org-agenda) Cached element is 
incorrect in Media.org. (Cache tic up to date: "yes") Resetting.
If this warning appears regularly, please report the warning text to Org mode 
mailing list (M-x org-submit-bug-report).
The element is: "(headline (:raw-value \"My Podcast Recommendations\" :begin 
684150 :end 692232 :pre-blank 1 :contents-begin 684181 :contents-end 692231 
:robust-begin 684183 :robust-end 692229 :level 2 :priority nil :tags nil 
:todo-keyword nil :todo-type nil :post-blank 1 :footnote-section-p nil 
:archivedp nil :commentedp nil :post-affiliated 684150 :title \"My Podcast 
Recommendations\" :mode nil :granularity element :cached t :parent (headline 
(:raw-value \"Podcasts\" :begin 684093 :end 741628 :pre-blank 0 :contents-begin 
684104 :contents-end 741627 :robust-begin 684148 :robust-end 741625 :level 1 
:priority nil :tags nil :todo-keyword nil :todo-type nil :post-blank 1 
:footnote-section-p nil :archivedp nil :commentedp nil :post-affiliated 684093 
:ID \"podcasts\" :title \"Podcasts\" :mode nil :granularity element :cached t 
:parent (org-data ...)"
 The real element is: "(headline (:raw-value \"My Podcast Recommendations\" 
:begin 684150 :end 691219 :pre-blank 1 :contents-begin 684181 :contents-end 
691218 :robust-begin 684183 :robust-end 691216 :level 2 :priority nil :tags nil 
:todo-keyword nil :todo-type nil :post-blank 1 :footnote-section-p nil 
:archivedp nil :commentedp nil :post-affiliated 684150 :title \"My Podcast 
Recommendations\" :mode nil :granularity element :parent (headline (:raw-value 
\"Podcasts\" :begin 684093 :end 740615 :pre-blank 0 :contents-begin 684104 
:contents-end 740614 :robust-begin 684148 :robust-end 740612 :level 1 :priority 
nil :tags nil :todo-keyword nil :todo-type nil :post-blank 1 
:footnote-section-p nil :archivedp nil :commentedp nil :post-affiliated 684093 
:ID \"podcasts\" :title \"Podcasts\""
 Cache around :begin:
nil
nil
nil Disable showing Disable logging

Warning (org-element-cache): org-element--cache: (org-agenda) Cached element is 
incorrect in Media.org. (Cache tic up to date: "yes") Resetting.
If this warning appears regularly, please report the warning text to Org mode 
mailing list (M-x org-submit-bug-report).
The element is: "(headline (:raw-value \"Stefan's Podcast List 1\" :begin 
684191 :end 692232 :pre-blank 1 :contents-begin 684220 :contents-end 692231 
:robust-begin 684222 :robust-end 692229 :level 3 :priority nil :tags nil 
:todo-keyword nil :todo-type nil :post-blank 1 :footnote-section-p nil 
:archivedp nil :commentedp nil :post-affiliated 684191 :title \"Stefan's 
Podcast List 1\" :mode nil :granularity element :cached t :parent (headline 
(:raw-value \"My Podcast Recommendations\" :begin 684150 :end 692232 :pre-blank 
1 :contents-begin 684181 :contents-end 692231 :robust-begin 684183 :robust-end 
692229 :level 2 :priority nil :tags nil :todo-keyword nil :todo-type nil 
:post-blank 1 :footnote-section-p nil :archivedp nil :commentedp nil 
:post-affiliated 684150 :title \"My Podcast Recommendations\" :mode nil 
:granularity element :cached t :parent (headline ...)"
 The real element is: "(headline (:raw-value \"Stefan's Podcast List 1\" :begin 
684191 :end 691219 :pre-blank 1 :contents-begin 684220 :contents-end 691218 

Re: org-agenda-dim-blocked-tasks don't use org-todo face

[Mark Kerr]

On Tue, Dec 13, 2022 at 2:51 AM Ihor Radchenko  wrote:
>
> Mark Kerr  writes:
>
> > Thank you. I may have been unclear but the result seems to be the
> > opposite of what I was hoping for.
> >
> > I was hoping to be able to gain the ability to use the org-todo face
> > with blocked tasks, while retaining the org-priority face which was
> > previously working..
> >
> > Now blocked tasks are entirely rendered with
> > org-agenda-dimmed-todo-face, including the priority.
>
> What you observe is what I intended to do.
>
> What you want is an opposite of "dimming" (IMHO).
>
> To achieve what you want, you may consider customizing
> `org-agenda-dimmed-todo-face' face. This face is applied on top of all
> other faces. If you, say, set only a background, the todo keywords will
> retain their foreground colour.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

I understand your viewpoint,  Ihor. Actually, it was mainly the font
size of the TODO keyword that I wanted to retain, not the colour.

The org-agenda-dimmed-todo-face overlay overrides the size set in
org-todo face, which breaks my layout.

I would like to retain the org-todo face colour as well, but it is
mainly the face size that causes me issues.

I have been fiddling with the face and overlay rules, but my knowledge
is not up to the task. From what I can tell, overlays always overwrite
faces.

I was thinking that a version of org-font-lock-add-priority-faces
could perhaps be adapted to work with todo keywords.

Re: Is org-show-all obsolete?

[Ihor Radchenko]

Ypo  writes:

> Has org-show-all changed in the version 9.6?
>
> Now, org-show-all doesn't appear in the "vertico 
> " 
> completion candidates.
>
> Is org-show-all obsolete? Is there an alternative?

org-show-all is a function alias and interactive for
org-fold-show-all, defined in org-fold.el.

This command is obsolete since 9.6; use org-fold-show-all instead.

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

Is org-show-all obsolete?

[Ypo]

Has org-show-all changed in the version 9.6?

Now, org-show-all doesn't appear in the "vertico 
" 
completion candidates.


Is org-show-all obsolete? Is there an alternative?

Best regards

Re: [BUG] org-element--cache: Org parser error [9.6 (release_9.6-90-gf49ee9 @ /home/stefan/.emacs.d/contrib/org-mode/lisp/)]

[Ihor Radchenko]

Stefan  writes:

> (plain-list (:type unordered :begin 712169 :end 712176 :contents-begin 712169 
> :contents-end 712175 :structure ((712169 0 "- " nil "[ ]" nil 712175)) ...))

Curious. What about (org-element-at-point 712029)? (like in your backtrace)

If no error is thrown in this way as well, try to set debug-on-error to
t and trigger the backtrace again. It should be slightly more
informative then.

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

Re: Completely hide properties drawer in 9.6

[Ihor Radchenko]

Sterling Hooten  writes:

> (let* ((block (org-get-property-block))
>  ;; Extremely hacky way to get the whole property drawer
>  (beg (- (car block) 14))
>  (end (+ (cdr block) 5)))
>   (with-silent-modifications
>   (org-fold-region beg end t 'org-hide-property-drawer
> #+end_src
>
> Is there a better way to get the beginning and end 
> of the property drawer more robustly?

org-element-at-point

> This is a step in the right direction, but it seems too sensitive to 
> accidental editing.

See :fragile in org-fold-core--specs.

> This should be impervious to most types of user interaction,
> and prevent accidentally deleting or abutting anything
> up against either the start or end of the properties box.

which is part of the reason why the proposal was rejected.
Though Org tries hard in org-catch-invisible-edits.

> I tried setting `org-fold-catch-invisible-edits' to different values, but even
> with set to nil I can backward delete and erase some invisible
> text. Is this dependent on their being an ellipsis? Or is there
> another way to make this impervious to most edits?

It's just because only a fixed set of folds is caught in the invisible
edits check now.

> When adding a property with `org-property-put’ this would need
> to be called again, is there a way to do that robustly?

I should not need to be called again once you set
:front-sticky/:rear-sticky folding spec property.

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

Re: [BUG] org-element--cache: Org parser error [9.6 (release_9.6-90-gf49ee9 @ /home/stefan/.emacs.d/contrib/org-mode/lisp/)]

[Stefan]

(plain-list (:type unordered :begin 712169 :end 712176 :contents-begin 712169 
:contents-end 712175 :structure ((712169 0 "- " nil "[ ]" nil 712175)) ...))

For the record, the last heading in Stefan.org looks like this:

-- quote --

** DONE [#A] Set alarm clock for presentation
CLOSED: [2022-12-11 Sun 13:38] SCHEDULED: <2022-12-09 Fri 19:00>
:PROPERTIES:
:CREATED:  [2022-12-07 Wed 18:01]
:ID:   efe672fa-9607-4cd2-858e-0ca89838bd56
:END:
:LOGBOOK:
- Refiled on [2022-12-07 Wed 18:01]
:END:

- [ ]


-- endquote--

That's a heading created based on a capture template, where I did not set that 
checklist item.

Best,
 Stefan

On Wed, Dec 14, 2022, at 19:32, Ihor Radchenko wrote:
> Thanks!
>
> What happens if you run M-: (org-element-at-point (point-max))
> from Stefan.org?

Re: [BUG] org-element--cache: Org parser error [9.6 (release_9.6-90-gf49ee9 @ /home/stefan/.emacs.d/contrib/org-mode/lisp/)]

[Ihor Radchenko]

Stefan  writes:

> thanks for the fast reaction.
>
> Here is the backtrace, again from the =a= agenda:
>
> https://gist.githubusercontent.com/stefan2904/0bb5d9db84664a4f4225cd809c294964/raw/e0ac2ec53d4b1d2fed57e440b8fb23157ecbab3d/redacted-backtrace.log

Thanks!

What happens if you run M-: (org-element-at-point (point-max))
from Stefan.org?

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

Re: Completely hide properties drawer in 9.6

[Sterling Hooten]

I was able to get a very rough version working to fold and hide 
the properties drawer completely at point.

#+begin_src emacs-lisp
  (defun swh-org-hide-properties-drawer ()
"Completely hide the property drawer in heading at point."
(org-fold-add-folding-spec 'org-hide-property-drawer
   '((:ellipsis . nil)
 (:isearch-open . t))
   nil
   'append)
(let* ((block (org-get-property-block))
   ;; Extremely hacky way to get the whole property drawer
   (beg (- (car block) 14))
   (end (+ (cdr block) 5)))
  (with-silent-modifications
(org-fold-region beg end t 'org-hide-property-drawer
#+end_src

Is there a better way to get the beginning and end 
of the property drawer more robustly?

This is a step in the right direction, but it seems too sensitive to accidental 
editing.

This should be impervious to most types of user interaction,
and prevent accidentally deleting or abutting anything
up against either the start or end of the properties box.

I tried setting `org-fold-catch-invisible-edits' to different values, but even
with set to nil I can backward delete and erase some invisible
text. Is this dependent on their being an ellipsis? Or is there
another way to make this impervious to most edits?

When adding a property with `org-property-put’ this would need
to be called again, is there a way to do that robustly?

> On 2022-12-14, at 12:14, Ihor Radchenko  wrote:
> 
> I tried my best to explain the design in the top comment. You may also
> look into `org-fold-initialize'.

Re: [BUG] org-element--cache: Org parser error [9.6 (release_9.6-90-gf49ee9 @ /home/stefan/.emacs.d/contrib/org-mode/lisp/)]

[Stefan]

Hi Ihor, all,

thanks for the fast reaction.

Here is the backtrace, again from the =a= agenda:

https://gist.githubusercontent.com/stefan2904/0bb5d9db84664a4f4225cd809c294964/raw/e0ac2ec53d4b1d2fed57e440b8fb23157ecbab3d/redacted-backtrace.log

Best,
 Stefan

On Wed, Dec 14, 2022, at 16:17, Ihor Radchenko wrote:
> Thanks for reporting!
>
> Could you please set org-element--cache-self-verify to 'backtrace and
> org-element--cache-self-verify-frequency to 1.0? Then, try to reproduce
> the error and post the full (huge) backtrace.
>
> Note that the backtrace will contain parts of your file, so you may
> consider stripping the sensitive parts of sharing it privately.

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

[Tom Gillespie]

Interestingly, as I was looking through my notes in
orgstrap, I see my past self had found a macro
org-babel-one-header-arg-safe-p which pointed to
defconst org-babel-safe-header-args, but that is
a const and not really user configurable. Of course
the user could cl-setf on it, but it also only checks
strings and has no ability to e.g. see if the value of
(symbol-function #'identity) has changed since the
check function was defined. Two examples.

(let ((old-identity (symbol-function #'identity)))
  (cl-letf* (((symbol-function #'identity)
  (lambda (x) (message "there") x)))
(identity 'hello)
(equal (symbol-function #'identity) old-identity)))

(let ((old-and (symbol-function #'and)))
  (cl-letf* (((symbol-function #'old-andf) old-and)
 ((symbol-function #'and)
  (lambda ( args)
(message "oops %s" args)
(old-andf args
(list
 (and)
 (and 1 2 3)
 (equal (symbol-function #'and) old-and

> Tom, does not the following allow to achieve the same without your patch?

It works if I have a closed set of things I want to allow but not if I
want to set it to nil to e.g. restore the old behavior (worse for
security but not as bad as setting ocbe to nil), e.g. if I'm
under duress and need to get something that used to work to
work again without the risk of automatically running dangerous
code, (e.g. blocks that might rm something).

> I know, it does not work, but I think it is due to (format "%S" cell)
> instead of passing cell directly in
>
> -'((:eval . yes)) nil (format "%S" cell)
>
> My point is that if some expression is safe for a variable value then it
> is safe for the source block body.

There is another use case here, which I alluded to in the previous
comment, which is that sometimes ocbe is the last line of defense
against running dangerous code. Ideally users would have set
:eval never on blocks like that to be sure, but if they don't you
don't want someone already trying to get something to work
to get too much to work.

Again, this is focused on the ocbec -> nil case.

> Have you ever seen the prompt for a table?

Err ... maybe? So the answer is probably no.

> I suppose, tables are the most prominent security issue related to
> unsolicited code execution:

For me it would be arbitrary expressions in the headers
of source blocks. Hard to know which one is more prevalent
across the population of org users.

> Max Nikulin to emacs-orgmode. Re: [BUG][Security] begin_src :var
> evaluated before the prompt to confirm execution. Fri, 28 Oct 2022
> 11:11:18 +0700. https://list.orgmode.org/tjfkp7$ggm$1...@ciao.gmane.io
>
> I am still in doubts if
>
> 10e857d42 2022-10-28 11:09:50 +0800 Ihor Radchenko: org-babel-read: Obey
> `org-confirm-babel-evaluate'
>
> was an unambiguous improvement. Perhaps it just forces more users to set
> `org-confirm-babel-evaluate' to nil compromising their security to more
> severe degree.

Heh. It is always a hard balance to strike. In the context of that
thread having a variable that would find-file-literally for untrusted
org files by default might be useful.

Again, it is a pain. I can tell you from experience having written
the system that does something similar for orgstrap. There is
no safe way other than a user-maintained whitelist based on
file hashes, everything else can be spoofed in one way or another.

I suspect that once we have the machinery in this patch in
place we can look for some sane defaults. Note that the example
function we keep passing around isn't quite good enough because
someone could probably figure out how to rewrite the identity
function so we would need to make sure that it had not changed
since emacs was loaded (unlikely, but if I can image it someone
could surely do it).

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

[Max Nikulin]

Tom, does not the following allow to achieve the same without your patch?

#+begin_src elisp :results none
  (setq-local
   org-confirm-babel-evaluate
   (lambda (lang body)
 (not
  (and
   (member lang '("elisp" "emacs-lisp"))
   (let ((rb (read body)))
 (or
  (member rb
  '((or)
(and)
;; add more forms that are known safe here
))
  (and
   (eq (car rb) 'identity)
   (let ((v (cadr rb)))
 (or
  (symbolp v)
  (stringp v)
  (numberp v)
  )
#+end_src

I know, it does not work, but I think it is due to (format "%S" cell) 
instead of passing cell directly in


-'((:eval . yes)) nil (format "%S" cell)

My point is that if some expression is safe for a variable value then it 
is safe for the source block body.


On 14/12/2022 04:16, Tom Gillespie wrote:

Will it be clear to users what "cell" means in this context?


I assume the language was originally chosen
with tables in mind, but I think it is clear? The
one issue is that using org-babel-confirm-evaluate
doesn't use the word "cell" in the yes-or-no-p prompt.


Have you ever seen the prompt for a table?

I suppose, tables are the most prominent security issue related to 
unsolicited code execution:


Max Nikulin to emacs-orgmode. Re: [BUG][Security] begin_src :var 
evaluated before the prompt to confirm execution. Fri, 28 Oct 2022 
11:11:18 +0700. https://list.orgmode.org/tjfkp7$ggm$1...@ciao.gmane.io


I am still in doubts if

10e857d42 2022-10-28 11:09:50 +0800 Ihor Radchenko: org-babel-read: Obey 
`org-confirm-babel-evaluate'


was an unambiguous improvement. Perhaps it just forces more users to set 
`org-confirm-babel-evaluate' to nil compromising their security to more 
severe degree.

Re: Radio links work only in small numbers

[Ihor Radchenko]

Max Nikulin  writes:

> On 14/12/2022 06:10, Rudolf Adamkovič wrote:
>> 
>> All [[link]]s in my notes perfectly match LEVEL-1 headings, so I figured
>> that I may as well ask Org to make links for me.  So, I replaced all the
>> ~4000 headings in my notes with radio <<>>.  However, Org now
>> errors out with "Regular expression too big".
>
> I think, you are abusing the feature. Too light markup requires too 
> heavy processing. What about <> and explicit [[target]]?

But why not?

It's not like we cannot fix this by splitting the regexp manually into
prefix tree.

The question is performance though.

Maybe Emacs people can offer some more ideas.

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

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

[Max Nikulin]

On 14/12/2022 21:35, Stefan Monnier wrote:



 Like I said in another message that I sent just before receiving yours
 my conclusion came from the fact that hitting 'C-h v' with the cursor
 on 'org-goto-interface' provided nothing.  It was the first time this
 ever happened to me.  I did try to explicitly enter the variable's
 name by entering 'org-goto', which (like 'org-go') is not
 enough: it is completed to 'org--goto'.


AFAICT this is a missing feature: we obey `help-enable-autoload` in
`describe-function` but we fail to do the same autoloading dance in
`describe-variable`.


I think, the difference is interactive vs. non-interactive calls rather 
than `describe-function' vs. `describe-variable'. What misses this 
feature is `customize-variable'.


Completion failure for "org-to" happened because result of 
`register-definition-prefixes' calls is not considered as options. I am 
aware that it may give false positives, but I still believe they should 
be added.


Though I believe that org mixed version issue happens due to 
transitional dependency of some third party package on org or something 
like (require 'org-protocol) that can not be loaded on demand.

Re: Radio links work only in small numbers

[Max Nikulin]

On 14/12/2022 06:10, Rudolf Adamkovič wrote:


All [[link]]s in my notes perfectly match LEVEL-1 headings, so I figured
that I may as well ask Org to make links for me.  So, I replaced all the
~4000 headings in my notes with radio <<>>.  However, Org now
errors out with "Regular expression too big".


I think, you are abusing the feature. Too light markup requires too 
heavy processing. What about <> and explicit [[target]]?

Re: For your consideration: Extending org-info-js with additional hooks

[David O'Toole]

At Ihor's invitation, I'd like to mention that I can help maintain
org-info-js going forward. I'm not a JavaScript expert but I seem to be
doing fine with adding my hooks and figuring out how the code works. Please
let me know what I can do to help out with maintenance. I already have
copyright assignment papers on file with the FSF so that's all set.

Re: Radio links work only in small numbers

[Rudolf Adamkovič]

Ihor Radchenko  writes:

> Can you try the attached patch?

No luck:

  "Regular expression too big"

Still too large:

  (length org-target-link-regexp) => 33219

:-(

Rudy
-- 
"Programming reliably -- must be an activity of an undeniably
mathematical nature […] You see, mathematics is about thinking, and
doing mathematics is always trying to think as well as possible."
-- Edsger W. Dijkstra, 1981

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: [PATCH] Merge loaded org-persist index with index file contents

[Timothy]

Hi All,

Since there have been no further comments, I’ve just pushed a tweaked version of
this patch (with Max’s comments addressed and with a minor oversight fixed) as
555dacfa8.

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] org-element--cache: Org parser error [9.6 (release_9.6-90-gf49ee9 @ /home/stefan/.emacs.d/contrib/org-mode/lisp/)]

[Ihor Radchenko]

Stefan  writes:

> I recently upgraded to Org 9.6 via Git (and to Emacs 28 with nativecomp), and 
> since then I get this kind of warnings all the time. They appear at different 
> spots in my org files and there is nothing special with the headings in 
> question.
>
> This specific warning appears when I load the standard =a= agenda:
>
> ---quote---
>
> Warning (org-element-cache): org-element--cache: Org parser error in 
> Stefan.org::#. Resetting.
>  The error was: (error "Invalid search bound (wrong side of point)")
>  Backtrace:
> "  backtrace-to-string(nil)
>   org-element-at-point(#)
>   org-element-cache-map(#f(compiled-function (el) # -0xe265922b01e7370>) :next-re \"]+)>\" :fail-re 
> \"]+)>\" :narrow t)
>   org-agenda-get-deadlines()

Thanks for reporting!

Could you please set org-element--cache-self-verify to 'backtrace and
org-element--cache-self-verify-frequency to 1.0? Then, try to reproduce
the error and post the full (huge) backtrace.

Note that the backtrace will contain parts of your file, so you may
consider stripping the sensitive parts of sharing it privately.

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

Re: Does variable 'org-goto-interface' exist?

[Max Nikulin]

On 14/12/2022 17:20, Alain.Cochard wrote:


my conclusion came from the fact that hitting 'C-h v' with the cursor
on 'org-goto-interface' provided nothing.  It was the first time this
ever happened to me.  I did try to explicitly enter the variable's
name by entering 'org-goto', which (like 'org-go') is not
enough: it is completed to 'org--goto'.


I was confused by similar behavior as well, see
Maxim Nikulin to emacs-orgmode. Bug? C-h v in src block since org-9.4. 
Wed, 28 Apr 2021 19:19:13 +0700. 
https://list.orgmode.org/s6bjs2$b0$1...@ciao.gmane.io


I think, help completion should include arguments of 
`register-definition-prefixes' from loaddefs files (till the related 
package is loaded), even if it may give some variants that has no 
functions or variables defined in a library. `customize-variable' should 
be consistent with describe-variable in respect to autoloading and 
completion option.


Alain, are you motivated enough to search in emacs bug tracker and in 
emacs-devel mailing list archives if such options were considered? From 
my point of view it is better to improve completion than to modify the 
Org Manual just for org-goto. Feel free to add me as X-Debbugs-CC if you 
decide to create a feature request or a bug.

Re: Completely hide properties drawer in 9.6

[Ihor Radchenko]

Sterling Hooten  writes:

>> On 2022-12-14, at 06:15, Ihor Radchenko  wrote:
>> 
>> I do have this implemented in local branch. Just did not push it
>> upstream as it was rejected.
>
> Could you share that here so I could test it?

https://github.com/yantar92/org/tree/feature/org-font-lock-element

>> This is handled by org-fold-core.el library.
>> Note that you can use the library to introduce new fold types.
>> Editing inside folds is optimized. All other concerns are also handled
>> within org-fold-core.
>
> I will read through this and try it out.

I tried my best to explain the design in the top comment. You may also
look into `org-fold-initialize'.

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

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

[Stefan Monnier]

> similar issues with several important Org components (ol-* and ob-*). In
> particular, ob-*.el packages affect Org simply by defining function
> symbols with specific name patters (by ob-core.el design).
> Achieving no side effects is difficult in practice.

That's true.  It can be a balancing act.

> Also, note that side effects are not uncommon in Elisp packages.
> Including, built-ins, like rect.el.
> dired+ comes to mind among popular third-party packages.

Most of them are plain bugs, tho (typically fixed by introducing an
autoloaded minor-mode, so the package is activated by enabling the
minor mode rather than by `require`ing the package).

> Like I said in another message that I sent just before receiving yours
> my conclusion came from the fact that hitting 'C-h v' with the cursor
> on 'org-goto-interface' provided nothing.  It was the first time this
> ever happened to me.  I did try to explicitly enter the variable's
> name by entering 'org-goto', which (like 'org-go') is not
> enough: it is completed to 'org--goto'.

AFAICT this is a missing feature: we obey `help-enable-autoload` in
`describe-function` but we fail to do the same autoloading dance in
`describe-variable`.


Stefan

[BUG] org-element--cache: Org parser error [9.6 (release_9.6-90-gf49ee9 @ /home/stefan/.emacs.d/contrib/org-mode/lisp/)]

[Stefan]

Hello everyone,

I recently upgraded to Org 9.6 via Git (and to Emacs 28 with nativecomp), and 
since then I get this kind of warnings all the time. They appear at different 
spots in my org files and there is nothing special with the headings in 
question.

This specific warning appears when I load the standard =a= agenda:

---quote---

Warning (org-element-cache): org-element--cache: Org parser error in 
Stefan.org::#. Resetting.
 The error was: (error "Invalid search bound (wrong side of point)")
 Backtrace:
"  backtrace-to-string(nil)
  org-element-at-point(#)
  org-element-cache-map(#f(compiled-function (el) #) :next-re \"]+)>\" :fail-re 
\"]+)>\" :narrow t)
  org-agenda-get-deadlines()
  org-agenda-get-day-entries(\"/home/stefan/PRIVATE/journal/org/Stefan.org\" 
(12 12 2022) :deadline :scheduled :timestamp :sexp)
  apply(org-agenda-get-day-entries 
\"/home/stefan/PRIVATE/journal/org/Stefan.org\" (12 12 2022) (:deadline 
:scheduled :timestamp :sexp))
  org-agenda-list(nil)
  funcall-interactively(org-agenda-list nil)
  call-interactively(org-agenda-list)
  org-agenda(nil)
  funcall-interactively(org-agenda nil)
  call-interactively(org-agenda nil nil)
  command-execute(org-agenda)
"

---endquote---

Emacs  : GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, 
cairo version 1.16.0)
 of 2022-05-31
Package: Org mode version 9.6 (release_9.6-90-gf49ee9 @ 
/home/stefan/.emacs.d/contrib/org-mode/lisp/)


Best,
 Stefan

Re: Completely hide properties drawer in 9.6

[Sterling Hooten]

> On 2022-12-14, at 06:15, Ihor Radchenko  wrote:
> 
> I do have this implemented in local branch. Just did not push it
> upstream as it was rejected.

Could you share that here so I could test it?

> Note that Emacs 29 does not have issues with large numbers of overlays.

I’m using the MacOS version and not building Emacs myself so I can’t try this 
out at the moment.

> This is handled by org-fold-core.el library.
> Note that you can use the library to introduce new fold types.
> Editing inside folds is optimized. All other concerns are also handled
> within org-fold-core.

I will read through this and try it out.

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

[Stefan Monnier]

>> On a related note, is it normal that package like org-mouse.el gets
>> loaded upon calling C-h f org-mouse-  completion prompt?

Yes.  See `help-enable-completion-autoload`.

>> I am asking because org-mouse.el advises some functions and its loading
>> may cause unexpected consequences. See
>> https://orgmode.org/list/87r0x6sju1@fastmail.fm
> I think org-mouse.el should be fixed not to cause such effects just by
> loading it.  It should do that only when it is actually used.

Exactly.  Merely loading a file should not affect Emacs's behavior in
any significant way.


Stefan

Re: Does variable 'org-goto-interface' exist?

[Max Nikulin]

On 14/12/2022 14:55, Ihor Radchenko wrote:

Max Nikulin writes:

Perhaps it is better to introduce some more concise notation to specify
the package where a custom option or variable is defined like
~org-goto-interface~ (=org-goto.el=).


...


Note, however, that org-goto is probably not the only place where we
refer to a customization that is not loaded by default.


This the exact reason why I decided to consider some general convention.


So, maintaining the proposed convention might not work well.


I agree. In addition, I do not see a way to make such convention 
semi-active to help users to access docs easier.


So I suggest to leave the Org manual as is and perhaps to improve C-h 
completion instead. Actually I am surprised that symbols are not 
transformed to help links in info buffers.

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

[Ihor Radchenko]

Eli Zaretskii  writes:

>> I am asking because org-mouse.el advises some functions and its loading
>> may cause unexpected consequences. See
>> https://orgmode.org/list/87r0x6sju1@fastmail.fm
>
> I think org-mouse.el should be fixed not to cause such effects just by
> loading it.  It should do that only when it is actually used.

Yes, we plan to do exactly this 
https://orgmode.org/list/87zgbqqukg.fsf@localhost
However, it will be a breaking backward-incompatible change. And we have
similar issues with several important Org components (ol-* and ob-*). In
particular, ob-*.el packages affect Org simply by defining function
symbols with specific name patters (by ob-core.el design).

Achieving no side effects is difficult in practice.

Also, note that side effects are not uncommon in Elisp packages.
Including, built-ins, like rect.el.
dired+ comes to mind among popular third-party packages.

>> At the same time, we have users complaining about some defcustoms not
>> being available without loading.
>> https://orgmode.org/list/25496.19258.682537.503...@gargle.gargle.howl
>
> That's too vague: it talks about "whether a variable exists", which is
> ambiguous.  That a variable is not boundp until its definition is
> loaded is perfectly expected, and I don't think defcustom changes that
> in any way (unless you autoload the defcustom, which is considered not
> the best style around here).
>
> So I guess some clarification is in order: what exactly was the
> problem with that variable being "nonexistent"?

Agree. See the quote below:
https://list.orgmode.org/orgmode/25497.41832.663858.836...@gargle.gargle.howl/

Like I said in another message that I sent just before receiving yours
my conclusion came from the fact that hitting 'C-h v' with the cursor
on 'org-goto-interface' provided nothing.  It was the first time this
ever happened to me.  I did try to explicitly enter the variable's
name by entering 'org-goto', which (like 'org-go') is not
enough: it is completed to 'org--goto'.

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

[HELP] Things to help Org that do not involve programming

[Ihor Radchenko]

Esteban Ordóñez  writes:

>> More things also require translation in `org-export-dictionary'.
>
> That sounds long  Is there something concrete which is important to
> help with?  I can destinate about 2 hours per week.  Maybe a little
> more.

`org-export-dictionary' is not really that long. It has 22 phrases to be
translated or checked in the language you speak. The list itself looks
rather long only because it is already translated to a number of
languages.

Other important area where we can use help is WORG. Pages in
https://orgmode.org/worg/ are often outdated or even have dead links.
Checking WORG for inconsistencies and proposing new blog article links
would be very helpful. This can be done one article at a time and does
not really require a one-time effort. Rather a persistence reading
things one by one (TODO list can help ;))

Yet another thing that is coming to my mind is checking command
descriptions in the manual. We currently have a number of commands with
docstrings diverged from what we have in the manual. It would help to
identify inconsistencies and amend the manual. (Ideally, the manual
should contain more than a docstring; tips for usage, for example).

Further, there is a number of ideas I noted wrt documentation/articles:

- It would be useful to have a set of suggested configuration tricks +
  third-party packages for people interested in different aspects of
  Org: writing fiction; writing non-fiction/science; publishing; babel
  and code evaluation; interactive notebooks; GTD and task management;
  knowledge management/note-taking; spreadsheets; cooking; tracking
  habits; etc

  We partially have this by linking to separate articles, like in
  https://orgmode.org/worg/org-tutorials/index.html, but having a common
  "intro" pages for different Org aspect would help a lot to get
  started for newbies.

- We may accumulate a series of short videos/screencasts illustrating
  distinct workflows/features, similar to
  https://orgmode.org/features.html or https://emacsrocks.com/

- We might have interviews with people who use Org mode in really unusual
  ways; people who really think that their life has changed after they
  started using Org, or just people with interesting and well-rounded
  workflows.

- We may have interactive tutorials in a form of Org files with src
  blocks to make it easy getting started with common use patterns.
  Similar to Emacs tutorial or good old interactive books.

If there is interest, we can split the above into smaller tasks and
assign small chunks (like one article/manual section) to different
people.

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

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

[Eli Zaretskii]

> From: Ihor Radchenko 
> Cc: David Masterson , emacs-orgmode@gnu.org,
>  mic...@schi.nz, 59...@debbugs.gnu.org
> Date: Wed, 14 Dec 2022 09:51:01 +
> 
> On a related note, is it normal that package like org-mouse.el gets
> loaded upon calling C-h f org-mouse-  completion prompt?
> org-mouse.el does not contain a single autoload cookie.

I think it's expected, because the doc strings need to be loaded.
Stefan, am I right?

> I am asking because org-mouse.el advises some functions and its loading
> may cause unexpected consequences. See
> https://orgmode.org/list/87r0x6sju1@fastmail.fm

I think org-mouse.el should be fixed not to cause such effects just by
loading it.  It should do that only when it is actually used.

> At the same time, we have users complaining about some defcustoms not
> being available without loading.
> https://orgmode.org/list/25496.19258.682537.503...@gargle.gargle.howl

That's too vague: it talks about "whether a variable exists", which is
ambiguous.  That a variable is not boundp until its definition is
loaded is perfectly expected, and I don't think defcustom changes that
in any way (unless you autoload the defcustom, which is considered not
the best style around here).

So I guess some clarification is in order: what exactly was the
problem with that variable being "nonexistent"?

Re: Does variable 'org-goto-interface' exist?

[Ihor Radchenko]

alain.coch...@unistra.fr writes:

>  > Note, however, that org-goto is probably not the only place where we
>  > refer to a customization that is not loaded by default. I am unsure how
>  > many places like this exist
>  
> I am not taking any side regarding the point Max brought up, but your
> comment about new users surprises me.  I am a long time Emacs user,
> but it is the 1st time (Org mode or otherwise) that 'C-h v' with the
> cursor on a variable's name fails.  Reading again section 2.3, I
> really don't see that I could have guessed about loading org-goto.

Well. I guess my perception of "new user" is a bit biased :)
In any case, whatever we write in the manual should be understandable by
proper new users as well.

> So if it is not the "only place", I bet it is relatively rare, and I
> fear that I will have forgotten about it if the same thing happens
> again to me in 3 years.

There was at least one more bug report, similar to yours in the past.
Also, the majority of ob-*.el files and ol-*.el files are not loaded by
default. And I hope that even less files will be loaded by Org in future
to address "loading time" complaints.

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

Re: Does variable 'org-goto-interface' exist?

[Alain . Cochard]

Ihor Radchenko writes on Wed 14 Dec 2022 07:55:

 > This particular note is largely aiming at new users not too
 > familiar with Emacs system.

 > [...]
 
 > Note, however, that org-goto is probably not the only place where we
 > refer to a customization that is not loaded by default. I am unsure how
 > many places like this exist
 
I am not taking any side regarding the point Max brought up, but your
comment about new users surprises me.  I am a long time Emacs user,
but it is the 1st time (Org mode or otherwise) that 'C-h v' with the
cursor on a variable's name fails.  Reading again section 2.3, I
really don't see that I could have guessed about loading org-goto.

So if it is not the "only place", I bet it is relatively rare, and I
fear that I will have forgotten about it if the same thing happens
again to me in 3 years.

-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France | [ slot available for rent ]

Re: Does variable 'org-goto-interface' exist?

[Alain . Cochard]

Max Nikulin writes on Wed 14 Dec 2022 17:01:
 > On 13/12/2022 15:54, Alain.Cochard wrote:
 > > At the end of section 2.3 (Motion) of the manual:
 > > 
 > >   See also the variable ‘org-goto-interface’.
 > > 
 > > But this variable does not seem to exist.
 > 
 > Alain, could you, please, clarify, what you was trying to do when you 
 > came to conclusion that `org-goto-interface' did not exist?
 > 
 > Interactive C-h v (`describe-variable') autoloads org-goto if TAB is 
 > pressed when "org-goto-" is typed into the prompt, so 
 > `org-goto-interface' becomes available for completion. However e.g. 
 > "org-go" is not enough for completion. A kind of pitfall is that 
 > non-interactive call
 >  M-: (describe-variable "org-goto-interface") RET
 > does not autoloads org-goto as well.

Like I said in another message that I sent just before receiving yours
my conclusion came from the fact that hitting 'C-h v' with the cursor
on 'org-goto-interface' provided nothing.  It was the first time this
ever happened to me.  I did try to explicitly enter the variable's
name by entering 'org-goto', which (like 'org-go') is not
enough: it is completed to 'org--goto'.

-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France | [ slot available for rent ]

Re: 2a529ee57 org-element: Autoload org-element-use-cache

[Ihor Radchenko]

Kyle Meyer  writes:

> Ihor Radchenko writes:
>
>> You wrote in the commit message that autoload.el is deprecated in Emacs
>> 29. Do we need to do anything about it in Org make system?
>
> Yes, though I don't consider it urgent given the deprecation hasn't even
> made it into a release.  I was planning on doing something like below
> (only lightly tested at this point).  And then way down the road we can
> drop the compatibility kludge.

Thanks! Looks reasonable and straightforward.

That comment could better be a FIXME though.
For easier future reference
(I recently added a reminder to review FIXME comments before releases 
https://orgmode.org/worg/org-maintenance.html#minor-major-releases).

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

Re: Does variable 'org-goto-interface' exist?

[Max Nikulin]

On 13/12/2022 15:54, Alain.Cochard wrote:

At the end of section 2.3 (Motion) of the manual:

  See also the variable ‘org-goto-interface’.

But this variable does not seem to exist.


Alain, could you, please, clarify, what you was trying to do when you 
came to conclusion that `org-goto-interface' did not exist?


Interactive C-h v (`describe-variable') autoloads org-goto if TAB is 
pressed when "org-goto-" is typed into the prompt, so 
`org-goto-interface' becomes available for completion. However e.g. 
"org-go" is not enough for completion. A kind of pitfall is that 
non-interactive call

M-: (describe-variable "org-goto-interface") RET
does not autoloads org-goto as well.

M-x customize-variable RET is not so clever (at least in Emacs-26) and 
it does not try autoloads.


If org-goto has not loaded yet and cursor is over `org-goto-interface' 
mention in the Info node "(org) Motion" then C-h v (`describe-variable') 
does not prefill the prompt. It is easier to jump to the help for this 
variable when org-goto is loaded.


My point is that maybe it is better to adjust Emacs behavior, not Org 
manual.


P.S. Sometimes I do not mind to have hyperlinks from HTML manuals to 
docstrings exported to HTML as well, but it is another story.

Re: [BUG] org-mouse is activated without explicit require

[Ihor Radchenko]

Max Nikulin  writes:

> On 13/12/2022 16:52, Ihor Radchenko wrote:
>> Max Nikulin writes:
>> 
 We have `org-modules' that can handle calling `org-link-set-parameters'.
> ...> We can simply process 'ol-* in `org-modules' specially.
>
> I do not consider it is a good idea. Third party packages may call 
> `org-link-set-parameters' as well. That is why I would prefer a more 
> general approach of package activation.

In this particular case, manual loading might actually be an advantage:
each call to `org-link-set-parameters' updates Org syntax, causing a
bunch of regexp re-calculations. The end result is slower Org loading.

If we could load multiple ol-* modules together, things could be made
faster.

I am not concerned about loading third-party packages here.
We cannot do more general approach anyway as long as we support older
Emacs.

However, we might suggest the general loading mechanism to Emacs devel.
Do you think it would be worth it?

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

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

[Ihor Radchenko]

Eli Zaretskii  writes:

>> So, 'describe-variable' on org-version causes Org to be loaded?!?
>
> Why is it so surprising?  Is this the first time you see that a Help
> command loads something to do its job?

On a related note, is it normal that package like org-mouse.el gets
loaded upon calling C-h f org-mouse-  completion prompt?
org-mouse.el does not contain a single autoload cookie.

I am asking because org-mouse.el advises some functions and its loading
may cause unexpected consequences. See
https://orgmode.org/list/87r0x6sju1@fastmail.fm

At the same time, we have users complaining about some defcustoms not
being available without loading.
https://orgmode.org/list/25496.19258.682537.503...@gargle.gargle.howl

I feel confused about the situation.

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

Pedro Andres Aranda Gutierrez  writes:

> Next try... I'm learning a lot :-)

Then, next set of comments.

(Note that I can hand-fix the patches at this point for you. Let me know
if you want to keep going)

> From dabdc3026e32ec674e22698de6257d724f60c4af Mon Sep 17 00:00:00 2001
> From: "Pedro A. Aranda Gutierrez" 
> Date: Wed, 14 Dec 2022 07:32:31 +0100
> Subject: [PATCH 3/3] etc/ORG-NEWS: add org-latex-listings-src-omit-language

^Add `...'

Also, it would make sense to merge this commit with the one introducing
the variable.  There is really not much reason to have two separate
commits here.

> * etc/ORG-NEWS: Add information for `org-latex-listings-src-omit-language'

Add "." at the end of the sentence ;)
Also, your Changelog entry does not include the parent heading.
I recommend following
https://orgmode.org/worg/org-contribute.html#org421ccec to produce
changelog automatically without much thinking.

> +*** New =org-latex-listings-src-omit-language= variable for LaTeX export

~org-latex...~

also, it is new _customization_, more precisely

> +The ~org-latex-listings-src-omit-language~ customization variable
> +allows you to omit the =language= parameter in the exported
> +=lstlisting= environment. This is necessary when the =listings=

By convention, we keep double space "  " between sentences.

> +backend delegates listing generation to another package like
> +=fancyvrb= using the following setup in the document header:
> +
> +#+BEGIN_src org
> +,#+LATEX_HEADER: \RequirePackage{fancyvrb}
> +,#+LATEX_HEADER: 
> \DefineVerbatimEnvironment{verbatim}{Verbatim}{...whatever...}
> +,#+LATEX_HEADER: 
> \DefineVerbatimEnvironment{lstlisting}{Verbatim}{...whatever...}
> +#+END_src

Is there any kind of blog/article demonstrating the usefulness. Not
strictly necessary, but may be helpful for others.

> Subject: [PATCH 1/3] lisp/ox-latex.el: don't emit empyt label=, caption=

_D_on't; empyt -> empty

> * lisp/ox-latex.el: (org-latex-src-block--listings):
>   Don't emit label= if label is empty.
>   DOn't emit caption= or captionpos= is caption is empty.

* lisp/ox-latex.el: (org-latex-src-block--listings): ->
* lisp/ox-latex.el (org-latex-src-block--listings):

DOn't -> Don't
is -> if

> Subject: [PATCH 2/3] lisp/ox-latex.el: Add
>  org-latex-listings-src-omit-language

`org-latex-listings-src-omit-language'

> * lisp/ox-latex.el: Add org-latex-listings-src-omit-language variable

`org-latex-listings-src-omit-language'

> +(defcustom org-latex-listings-src-omit-language nil
> +  "Set this option to t to omit the
> +\"language=\"
> +in the parameters to \\begin{lstlisting} when exporting a src block.

By convention, the first line of the docstring should be no wider than
67 chars and briefly describe the purpose of the variable. See
D.6 Tips for Documentation Strings section of Elisp manual:

   • The first line of the documentation string should consist of one or
 two complete sentences that stand on their own as a summary.  ‘M-x
 apropos’ displays just the first line, and if that line’s contents
 don’t stand on their own, the result looks bad.  In particular,
 start the first line with a capital letter and end it with a
 period.

 For a function, the first line should briefly answer the question,
 “What does this function do?” For a variable, the first line should
 briefly answer the question, “What does this value mean?”

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

Re: Completely hide properties drawer in 9.6

[Ihor Radchenko]

Sterling Hooten  writes:

> In  Ihor suggested
> adding `org-custom-properties-hide-emptied-drawers', this was
> rejected, but is pretty close to the desired behavior, except it's
> still global. I was unable to get this working in release 9.6.

I do have this implemented in local branch. Just did not push it
upstream as it was rejected.

> Prior to 9.6 I overwrote org-cycle-heading to hide the properties box
> using overlays. This worked alright but had slowdowns on larger files
> and affected typing cadence noticeably. Org 9.6 is now relying on text
> properties instead of overlays, and I would like help replicating (and
> improving) that behavior.

Note that Emacs 29 does not have issues with large numbers of overlays.

> Part of the complication comes from updating modified timestamps in
> the properties of each heading. This drives the need for hiding to be
> fast so as not to bog down the editing experience when triggered by
> `after-change-functions'.

This is handled by org-fold-core.el library.
Note that you can use the library to introduce new fold types.
Editing inside folds is optimized. All other concerns are also handled
within org-fold-core.

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

Re: Timestamps being changed in exporting to HTML ?

[Ihor Radchenko]

David Masterson  writes:

> I just noticed that Org timestamps of the following form:
>
>   <2006-11-02 Thu 20:00-22:00>
>
> are being changed to this form in HTML export:
>
>   <2006-11-02 Thu 20:00>-<2006-11-02 Thu 22:00>  # note single '-'
>
> Is this proper?

Transformation from 20:00-22:00 to 2 timestamps is done by
`org-timestamp-translate'.

The single "-" is not a true dash (-), but en-dash (–) 

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

Re: [BUG] Documentation fix needed in "4.4 External Links" [9.6 ( @ /home/dsmasterson/.emacs.d/elpa/org-9.6/)]

[Ihor Radchenko]

David Masterson  writes:

> Do you think (some part of) this (semi-)paragraph should be mentioned in
> the docstring for 'org-open-at-point' (and 'org-open-at-mouse')? I'm of
> the opinion that, if you walk-thru the docstring links, you would get
> all the info you'd get in the manual (and more), but not necessarily
> explained in a user-friendly form,

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=edd000f3b

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

Re: Radio links work only in small numbers

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> Greetings smart people!
>
> All [[link]]s in my notes perfectly match LEVEL-1 headings, so I figured
> that I may as well ask Org to make links for me.  So, I replaced all the
> ~4000 headings in my notes with radio <<>>.  However, Org now
> errors out with "Regular expression too big".
>
> Does anyone know how to overcome this limitation?  Or, perhaps someone
> has a patch in works that fixes it?  If so, please let me know!

This is C-level error emitted by Emacs' regexp engine.

Can you try the attached patch?
>From 53e6c067e4897c5b6c1ac8201e2dbc49baa9e6e8 Mon Sep 17 00:00:00 2001
Message-Id: <53e6c067e4897c5b6c1ac8201e2dbc49baa9e6e8.1671006575.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Wed, 14 Dec 2022 11:28:03 +0300
Subject: [PATCH] org-update-radio-target-regexp: Try to get a shorter regexp
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/ol.el (org-update-radio-target-regexp): Use `regexp-opt' to
compact the resulting regexp as much as possible.  Otherwise, some
users hit regexp length limits when the number of radio targets
approaches thousands.

Reported-by: Rudolf Adamkovič 
Link: https://orgmode.org/list/m2lenax5m6@me.com
---
 lisp/ol.el | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/lisp/ol.el b/lisp/ol.el
index 3ae8f8875..51ee028e4 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -2065,13 +2065,11 @@ (defun org-update-radio-target-regexp ()
 (setq org-target-link-regexp
 	  (and targets
 	   (concat before-re
-		   (mapconcat
-			(lambda (x)
-			  (replace-regexp-in-string
-			   " +" "\\s-+" (regexp-quote x) t t))
-			targets
-			"\\|")
-		   after-re)))
+   (replace-regexp-in-string
+" +" "\\s-+"
+(regexp-opt targets)
+nil t)
+   after-re)))
 (unless (equal old-regexp org-target-link-regexp)
   ;; Clean-up cache.
   (let ((regexp (cond ((not old-regexp) org-target-link-regexp)
-- 
2.38.1


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

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

[Ihor Radchenko]

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.

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

Re: [BUG] org-mouse.el breaks org-open-at-point

[Ihor Radchenko]

Matt Lundin  writes:

>> Patches welcome!
>>
>> I think we need to modify `org-open-at-mouse' directly instead of
>> using advice.
>
> I can give this a try.
>
> The advice in org-mouse.el currently does the following:
>
>  - cycles when on headline
>  - toggles checkbox when on checkbox
>  - cycles plain lists when on a list item
>
> Would it make any sense to make this part of the default behavior or
> org-open-at-mouse? 

Not really. These advised extras do not really belong to "opening"
links. We usually use "action" (C-c C-c) for toggling staff and
"cycling" (TAB) to cycle staff. It's just that "clicking" falls into
"open" paradigm in Emacs, but users also expect "toggle" and "switch
state" as in other applications.

> If not, I think I can make it dependent on the value of
> org-mouse-features, thus giving user the option of turning off the extra
> mouse click behavior via that variable (as a workaround to avoid
> undesired side effects of calling interactive help). This would be a
> temporary workaround until the org-mouse is converted to a global minor
> mode.

I think we can do the following:

1. Introduce new `org-open-at-mouse-first-hook' hook that will be run by
   `org-open-at-mouse' before calling `org-open-at-point'.

2. Introduce `org-mouse-features' as you suggested.

3. Make org-mouse.el add appropriate hooks into
   `org-open-at-mouse-first-hook' according to the value of
   `org-mouse-features'.  The default should keep the current behaviour
   for `org-open-at-mouse'.

4. The new variables are to be documented in etc/ORG-NEWS

5. Ideally, we can convert org-mouse.el to global minor mode immediately
   and turn it on when org-mouse.el is loaded. Then, moving to
   side effect-free loading will be simply a question of removing a
   single statement from org-mouse.el.

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

Re: Does variable 'org-goto-interface' exist?

[Ihor Radchenko]

Max Nikulin  writes:

> On 13/12/2022 18:43, Ihor Radchenko wrote:
>> +  Note: ~org-goto-*~ variables are only accessible when =org-goto=
>> +  library is loaded using ~require~ statement in the config or
>> +  auto-loaded by calling ~org-goto~ interactively.
>
> Perhaps it is better to introduce some more concise notation to specify 
> the package where a custom option or variable is defined like 
> ~org-goto-interface~ (=org-goto.el=).

I am not sure. This particular note is largely aiming at new users not
too familiar with Emacs system. Won't your suggestion be confusing?

For me ~org-goto-*~ should be naturally inside org-goto.el.

On the other hand, we may extend 1.5 Typesetting Conventions Used in
this Manual section of the manual describing what the proposed notation
refers to and then use it as needed.

Note, however, that org-goto is probably not the only place where we
refer to a customization that is not loaded by default. I am unsure how
many places like this exist and whether some presently auto-loaded
libraries will be still loaded in future as we try to make Org more
modular (and thus reduce the initial load time, many Emacs devs are
complaining about).

So, maintaining the proposed convention might not work well.

Or we may indicate the library with every variable we introduce from
that library for the first time + indicate that all the variables with
the same prefix will be from the same library.

WDYT?

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