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

[Pedro Andres Aranda Gutierrez]

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

BR,/PA


On Tue, 13 Dec 2022 at 12:51, Ihor Radchenko  wrote:

> Pedro Andres Aranda Gutierrez  writes:
>
> > thanks for the patience. I hope to have implemented all suggestions by
> now.
>
> No. You missed several.
>
> 1. :version is not necessary. See 15.1 Common Item Keywords section of
> Elisp manual:
>
> 2. Please also provide changelog entries. See
> https://orgmode.org/worg/org-contribute.html#commit-messages
>
> More comments below.
>
> > +*** New =org-latex-listings-src-omit-language= variable for LaTeX export
> > +
> > +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= backend
> > +forwards the actual listing generation to another package like
> > +=fancyvrb= using the following setup in the document header:
>
> Please use ~code~ for Elisp symbols and double space between sentences.
> You may refer to etc/Documentation_Standards.org file for details.
>
> > +#+BEGIN_example
> > +#+LATEX_HEADER: \\RequirePackage{fancyvrb}
> > +#+LATEX_HEADER:
> \\DefineVerbatimEnvironment{verbatim}{Verbatim}{...whatever...}
> > +#+LATEX_HEADER:
> \\DefineVerbatimEnvironment{lstlisting}{Verbatim}{...whatever...}
> > +#+END_example
>
> Please quote #+LATEX_HEADER in the example block with commas. (Org will
> do it automatically for you if you edit the example block with C-c ')
>
> > +*** The LaTeX export backend only emits =label= and =caption= when they
> are not empty
> > +
> > +When exporting a SRC block and using the listings backend , =label==
> > +and =caption== parameters for the =lstlisting= environment will be
> > +only generated when they are not empty. Things like
> > +
> > +#+BEGIN_src latex
> > +\begin{lstlisting}[label= ,caption= ,captionpos=b]
> > +\end{lstlisting}
> > +#+END_src
> > +
> > +will no more appear.
>
> This is probably not something people need to take note of. Not necessary.
>
> > Subject: [PATCH 2/4] Allow to suppress language= in SRC blocks
> > Subject: [PATCH 3/4] Refine DOCSTRING for
> org-latex-listings-src-omit-language
>
> 2nd and 3rd patches can be merged into one.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet
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

* etc/ORG-NEWS: Add information for `org-latex-listings-src-omit-language'
---
 etc/ORG-NEWS | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 5d5e726e0..bd78ed9a7 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -432,6 +432,21 @@ following properties: ~:hook~, ~:prepare-finalize~,
 ~:before-finalize~, ~:after-finalize~.  These nullary functions run
 prior to their global counterparts for the selected template.
 
+
+*** New =org-latex-listings-src-omit-language= variable for LaTeX export
+
+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=
+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
+
 ** New options
 *** A new option for custom setting ~org-refile-use-outline-path~ to show document title in refile targets
 
@@ -747,7 +762,6 @@ following snippet to allow multiple different ID formats in Org files.
 org-attach-id-uuid-folder-format
 org-attach-id-ts-folder-format))
 #+end_src
-
 * Version 9.5
 
 ** Important announcements and breaking changes
-- 
2.25.1

From 2038bddb662f393d99ceb88c9bf9d2a6898919dc Mon Sep 17 00:00:00 2001
From: "Pedro A. Aranda Gutierrez" 
Date: Wed, 14 Dec 2022 07:12:55 +0100
Subject: [PATCH 1/3] lisp/ox-latex.el: don't emit empyt label=, caption=

* 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 | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index a2d60d5db..f03903605 100644
--- 

Re: 9.6 - hide-drawer-startup option(s?) [9.5.5 (release_9.5.5 @ /usr/local/share/emacs/29.0.50/lisp/org/)]

[Kévin Le Gouguec]

Ihor Radchenko  writes:

> Kévin Le Gouguec  writes:
>
>> Just to make sure I understand this new setting correctly: by default,
>> despite org-cycle-hide-drawer-startup being t, it's ineffectual, because
>> org-startup-folded defaults to 'showeverything, right?
>
> Yes

Gotcha 

>> (Asking because when reading the ORG-NEWS entry for the new option in
>> isolation…
>
> You can try to play around with
>
> #+startup: nofold hidedrawers hideblocks

Yup, all makes sense now.  I think customizing org-startup-folded to
'nofold ≡ 'showall is the way to go for me; that will take care of
automatically hiding humongous LOGBOOKs.

Thanks again for the help!

Completely hide properties drawer in 9.6

[Sterling Hooten]

First of all, thanks to everyone for working on 9.6!

I'm trying to clone Lotus notes in Org mode. This requires certain
properties to be generated for every heading (e.g., ID, creation time,
modification time, etc.). But these are mainly used for searching and
sorting, and rarely of interest to me during editing. For this reason
I would like to /completely/ hide the properties box (not just the
individual properties).

This has been discussed multiple times before in this list. The
general sentiment has been to reject adding it to Org as hiding things
ompletely from the user might be confusing, but it's also been
brought up enough times independently to demonstrate a latent demand
for this behavior, and a working example would be very useful for
those of us who wish to have a cleaner interface and editing
experience.

Alternative suggestions have been to change the face to make the
properties box appear smaller, but this interferes with movement from
the heading to the body, and the ability to toggle the visibility of a
property box would make this is redundant.

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.

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.

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

The constant updating of a modification timestamp system puts some
constraints on the property hiding system. From working in 9.5 I
believe the relevant requirements are:

• Ability to add or modify properties with `org-entry-put' and
  maintain the state of being hidden or visible
  • E.g., Updating the ":MODIFIED:" property to a hidden property
drawer should keep the drawer hidden.
• Toggle on and off hiding globally (perhaps in a minor mode)
• Moving headings around with `org-metaup' etc preserves the
  visibility state
  • A hidden property drawer should stay hidden when the outline is
rearranged
• Resistant to changes with undo etc
  • Undoing a change should cause the contet to revert to the same
visibility state it had at time of change.
• Don't overwrite when editing normally
  • With the point at the end of a heading and immediately before an
ellipsis, typing "j" should result in the character being inserted
with the face of the heading, and not overwrite or otherwise
disturb the invisible text. `org-fold-catch-invisible-edits' might
be relevant here.
• Reveal or hide just the property drawer of the heading at point and
  not the whole buffer
  • This is partially for speed reasons (to handle modified timestamp
updates), but also because revealing all property drawers is
extremely annoying when the surrounding headings in the buffer
have headings with >10 properties.
• Fast enough to use with `after-change-functions'
  • The modification timestamp setup I'm using is triggered by buffer
changes, and thus when typing runs after every keystroke. To keep
this smooth and not be a bottleneck it would need `(benchmark 100
'org-hide-properties)' to be less than .1s on an Org file with
>20,000 lines and >1,000 headings.
• Ability to reveal just a subset of property lines
  • e.g., `org-bibtex' creates many properties to store bibliographic
data. It would be useful to have enough control over hiding of
properties such that if only ":BIB_FIELD:" properties of.
• Hide ellipsis unless body text is present
  • If all the headings have properties then the default folding
behavior will place ellipses at the end of each heading, thus
destroying the informational value of the ellipsis as an
indication of folded but displayable content. It would be useful
if instead the ellipsis would only be present when there's body
text.

Any help would be greatly appreciated as things have changed in 9.6
and I'm not sure where the opportunities are to leverage the
improvements (e.g., are text properties now the way? Or should I still
implement it with faces?).

Thanks!

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

[Kyle Meyer]

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.


diff --git a/mk/org-fixup.el b/mk/org-fixup.el
index 5989875a8..60c39c684 100644
--- a/mk/org-fixup.el
+++ b/mk/org-fixup.el
@@ -24,7 +24,6 @@
 ;;
 ;;; Commentary:
 
-(require 'autoload)
 (require 'org-compat "org-compat.el")
 
 (defun org-make-manual ()
@@ -86,18 +85,22 @@ (defun org-make-org-loaddefs ()
 be used by foreign build systems or installers to produce this
 file in the installation directory of Org mode.  Org will not
 work correctly if this file is not up-to-date."
-  (with-temp-buffer
-(set-visited-file-name "org-loaddefs.el")
-(insert ";;; org-loaddefs.el --- autogenerated file, do not edit\n;;\n;;; 
Code:\n")
-(let ((files (directory-files default-directory
- nil 
"^\\(org\\|ob\\|ox\\|ol\\|oc\\)\\(-.*\\)?\\.el$")))
-  (mapc (lambda (f) (generate-file-autoloads f)) files))
-(insert "\f\n(provide 'org-loaddefs)\n")
-(insert "\f\n;; Local Variables:\n;; version-control: never\n")
-(insert ";; no-byte-compile: t\n;; no-update-autoloads: t\n")
-(insert ";; coding: utf-8\n;; End:\n;;; org-loaddefs.el ends here\n")
-(let ((inhibit-read-only t))
-  (save-buffer
+  (let ((outfile "org-loaddefs.el"))
+(if (fboundp 'loaddefs-generate); Emacs >= 29
+(loaddefs-generate default-directory (expand-file-name outfile))
+  (require 'autoload)
+  (with-temp-buffer
+(set-visited-file-name outfile)
+(insert ";;; org-loaddefs.el --- autogenerated file, do not 
edit\n;;\n;;; Code:\n")
+(let ((files (directory-files default-directory
+  nil 
"^\\(org\\|ob\\|ox\\|ol\\|oc\\)\\(-.*\\)?\\.el$")))
+  (mapc (lambda (f) (generate-file-autoloads f)) files))
+(insert "\f\n(provide 'org-loaddefs)\n")
+(insert "\f\n;; Local Variables:\n;; version-control: never\n")
+(insert ";; no-byte-compile: t\n;; no-update-autoloads: t\n")
+(insert ";; coding: utf-8\n;; End:\n;;; org-loaddefs.el ends here\n")
+(let ((inhibit-read-only t))
+  (save-buffer))
 
 (defun org-make-autoloads ( compile force)
   "Make the files org-loaddefs.el and org-version.el in the install directory.

Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]

[Greg Minshall]

hi, Johan,

> "Proper list" in the context of this discussion and pertaining to R
> would be a =list()=, not a vector which is what is usually returned by
> =c()=. A =data.frame()= is a special case of a =list()= where every
> column has to have the same length.

well, it's a language mapping problem.  what one considers a "list" in
org-mode is
- well
- something like
- this
  - maybe with
  - this

whereas in e-lisp, '("well" "something like" '("this" '("maybe with"
"this"))).

then, the question arises of how to translate something like that to
whatever data structures a given programming language offers.  it
*might* be to something that programming language calls a "list".

if we are ignoring "sub lists", then for R, one could argue either
vectors or lists.  (someone -- possibly you? -- pointed out that going
from an R list to a vector is as simple as an unlist() call.)

if we ever want to provide support for sub lists, then passing lists as
R lists seems like the way to go.

cheers, Greg


> list("well", "something like", list("this", list("maybe with")))
[[1]]
[1] "well"

[[2]]
[1] "something like"

[[3]]
[[3]][[1]]
[1] "this"

[[3]][[2]]
[[3]][[2]][[1]]
[1] "maybe with"



> unlist(list("well", "something like", list("this", list("maybe with"
[1] "well"   "something like" "this"   "maybe with"

Timestamps being changed in exporting to HTML ?

[David Masterson]

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?

-- 
David Masterson

Radio links work only in small numbers

[Rudolf Adamkovič]

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!

Thank you.

Rudy
-- 
"The introduction of suitable abstractions is our only mental aid to
organize and master complexity."
-- Edsger Wybe Dijkstra, 1930-2002

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

Re: [HELP] Translate/extend `org-clock-clocktable-language-setup' for Spanish/Dutch/more languages

[Rudolf Adamkovič]

Ihor Radchenko  writes:

> A patch would make it easier for me to apply the change with a proper
> attribution ;)

Ihor patches code faster than others poll their e-mail.  Thanks!  :)

Rudy
-- 
"Thinking is a momentary dismissal of irrelevancies."
-- Richard Buckminster Fuller, 1969

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

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

[Tom Gillespie]

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

> Am I wrong that, roughly speaking, the effective value is (and
> org-confirm-babel-evaluate-cell org-confirm-babel-evaluate)?

You are correct. Only in the case that
org-confirm-babel-evaluate-cell is or evaluates to t will
the yes-or-no-p be displayed _IF_ org-confirm-babel-evaluate
is or evaluates to t. org-babel-confirm-evaluate (NOT
org-confirm-babel-evaluate) is the function that issues
the yes-or-no-p.

> Should it be described in the docstring?

Maybe? In the current implementation the value of
org-confirm-babel-evaluate takes precedence, which
I think is the correct behavior. If someone has told
us that they blindly want to execute all code, but
not cells, we should not change the default behavior,
and thus we should execute all cells and blocks

> It seems e.g. :eval query affects the latter, but not the former.

:eval has no impact on cells. In fact in some files I use
:eval (and this-file-done-loading "never") on some blocks that
(setq this-file-done-loading) at the end to achieve only-once
behavior.

> If it is so then it is too complicated for me to feel firm ground
> while reasoning on security.

:eval has never, and cannot impact evaluation of cells, because
it is specifically used to control evaluation of blocks. Similarly
:eval has no interaction with any of the confirm-babel-evaluate
machinery.

I see one possible point of confusion which is that he :eval that
you see in the code of org-babel-read is a hack to create fake
info for a cell.

Are you maybe looking for a file level :eval-cell option/property
that would allow you to declare that you should NEVER run
cells at all and also never prompt? Basically this is an option
that says "treat all cells as if they and their header property
are the default value".

I'm fairly certain that implementing such a thing is a bad
idea, for example if someone sets :dir using a cell and
it is overwritten they could execute code in the wrong
environment, which can lead to nasty security issues.
Thus the only global option for cells that we could safely
implement would have the semantics of "treat all cells
as if they are (error)".

> I have not decided if it is feasible to add some property to the INFO
> argument passed to `org-babel-confirm-evaluate' and to put there
> condition which variable should determine result.

Having done so before, I would rather not touch
org-babel-confirm-evaluate if at all possible. The only
disadvantage is that for now when users are prompted
they will not be informed that it is a cell, however from
the short nature of cells the will hopefully be able to
figure it out.

The fact that org already jumps to the location of
the cell in the file helps a lot with this. Obviously
this doesn't help in a batch context, but if a user
is hitting this in batch mode they are in trouble
anyway.

Re: Incorrect numbering of tables (and other elements like figures) [Org 9.6]

[Kaushal Modi]

On Tue, Dec 13, 2022 at 3:52 AM Ihor Radchenko  wrote:

> Kaushal Modi  writes:
>
> > Since Org 9.6, I am seeing that the numbering of tables (and other
> elements
> > like figures) resets to 1 and stays so, thought I cannot see a pattern of
> > why that happens.
> >
> > Org version: Org mode version 9.6 (release_9.6-40-g49cf3e ..)
> >
> > Here's a small reproducible example that shows the problem in any
> exporter
> > (ox-ascii, ox-html, ..)
> > ...
>
> Thanks for reporting!
> Fixed on bugfix. With a test now.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=bdb4c4c66
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=02909fe37
>
>
Thank you!

I confirm the fix. Also thanks for adding the test.

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

[Justin Silverman]

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.

Justin 

Ihor Radchenko  writes:

> Justin Silverman  writes:
>
>> texmathp when used in org-mode seems to have problems with multiline align* 
>> environments.
>>
>> Consider the following math environment: 
>>
>>
>> \begin{align*}
>> y_{i} &~ f(mu_{i}) 
>> |
>> \end{align*}
>>
>> where cursor is at `|'. With cursor at this point try `(texmathp)'. I get 
>> `nil'. It seems to only
>> be a problem on the start of a blank line.
>
> Thanks for reporting!
> Fixed on main.
> 

Re: [PATCH] oc-csl: Improve LaTeX bibliography formatting

[András Simonyi]

Dear All,

On Tue, 13 Dec 2022 at 17:07, Timothy  wrote:

> Perhaps an ASCII approximation in an example block could work? Even if it’s
> exaggerated to give the idea.

yes, I'm also thinking of first trying to produce something in ASCII
as the docstring will probably need it anyway,
and we can think about the image version afterwards -- it might turn
out that the text version is already sufficient for the news (and
maybe later on for the manual).

best wishes,
András

> 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] 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:
>
 2. If #1 depends on some org variable settings, can you mention what
 variables control the answer to #1?
>>>
>>> If you mean "can open", then see the next section.
>>
>> Ahh, maybe I am in the wrong section.  I think, what I want is
>> org-open-at-point (which could be mentioned in 4.4), but it's
>> documentation string just says the linked file will be opened by "an
>> appropriate application".  I assume that that means some Elisp function
>> is called that cross-references the file type with appropriate
>> application.  And that I could add to or adjust the cross-reference list
>> for new/modified file types.  It would be nice to mention that list
>> variable so that I could trace the process further and determine what to
>> do (like install the appropriate application).
>>
>> Does this help for what I'm looking for?
>
> 4.5 Handling Links
> ...
> ‘C-c C-o’ (‘org-open-at-point’)
> ...
>  ... Furthermore, it visits text and
>  remote files in ‘file’ links with Emacs and select a suitable
>  application for local non-text files.  Classification of files is
>  based on file extension only.  See option ‘org-file-apps’.  If you
>  want to override the default application and visit the file with
>  Emacs, use a ‘C-u’ prefix.  If you want to avoid opening in Emacs,
>  use a ‘C-u C-u’ prefix.

D***, I'm getting old!  These things used to pop out at me in the old
days.  Apologies for the dumb question...  :(

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,

-- 
David Masterson

Re: 9.6 - hide-drawer-startup option(s?) [9.5.5 (release_9.5.5 @ /usr/local/share/emacs/29.0.50/lisp/org/)]

[Ihor Radchenko]

Kévin Le Gouguec  writes:

> Just to make sure I understand this new setting correctly: by default,
> despite org-cycle-hide-drawer-startup being t, it's ineffectual, because
> org-startup-folded defaults to 'showeverything, right?

Yes

> (Asking because when reading the ORG-NEWS entry for the new option in
> isolation…

You can try to play around with

#+startup: nofold hidedrawers hideblocks

:drawer:
asd
:end:

#+begin_src emacs-lisp
  (message "heelo")
#+end_src

* This is test

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

Re: 9.6 - hide-drawer-startup option(s?) [9.5.5 (release_9.5.5 @ /usr/local/share/emacs/29.0.50/lisp/org/)]

[Kévin Le Gouguec]

Ihor Radchenko  writes:

> Thanks for the heads-up!
> Fixed on bugfix.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4323a19b1
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=47bcdce19

Fixes duly noted, thanks 

Just to make sure I understand this new setting correctly: by default,
despite org-cycle-hide-drawer-startup being t, it's ineffectual, because
org-startup-folded defaults to 'showeverything, right?

(Asking because when reading the ORG-NEWS entry for the new option in
isolation…

> The new custom setting gives more control over initial folding state
> of the drawers.  When set to =nil= (default is =t=), the drawers are
> not folded on startup.

… my initial reaction was "oh neat so LOGBOOKs will be folded on startup
by default", until I tried, got surprised they remained open, frowned
for a moment, then remembered this other bit…

>  Folding state of the drawers is now preserved when cycling headline 
> visibility
> 
> In the past drawers were folded every time a headline is unfolded.
> 
> Now, it is not the case anymore.  The drawer folding state is
> preserved.  The initial folding state of all the drawers in buffer is
> set according to the startup visibility settings.

… then it clicked)

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

[David O'Toole]

Here are my suggested changes to the manual and change log.

On Tue, Dec 13, 2022 at 11:32 AM David O'Toole 
wrote:

> Sure, I would be happy to help out with the news and manual.
> I will draft some changes and get back to you.
>
>
>> This addition does sound useful.
>> However, in addition to changes in the code, it would be helpful to
>> provide appropriate news entry and manual changes.
>>
>
> On Tue, Dec 13, 2022 at 5:00 AM Ihor Radchenko 
> wrote:
>
>> "David O'Toole"  writes:
>>
>> > After some discussion with Yantar on IRC, I humbly submit the attached
>> diff
>> > for your consideration.
>> >
>> > It adds new hooks to org-info-js to allow the following: 1. inserting
>> > page-specific HTML into each OrgInfo header, and 2. calling a custom
>> > JavaScript function to run after any page navigation button/link is
>> > clicked. I have used these hooks to implement Org-fleuron, a custom
>> config
>> > with nice navigation buttons, a greeting balloon, and embedded
>> theme/fonts.
>> > You can find out more about org-fleuron here:
>> > https://davidotoole.info/fleuron.html?#org5dc18bc and the page was made
>> > with the setup.
>> >
>> > I also corrected some of the English messages displayed by org-info-js.
>>
>> This addition does sound useful.
>> However, in addition to changes in the code, it would be helpful to
>> provide appropriate news entry and manual changes.
>>
>> See
>> https://git.sr.ht/~bzg/worg/tree/master/item/code/org-info-js/changes.org
>> and
>> https://git.sr.ht/~bzg/worg/tree/master/item/code/org-info-js/index.org
>>
>> Bastien, since the activity around org-info-js revived after a long
>> delay, should we move the code out of worg into a separate repo?
>>
>> --
>> Ihor Radchenko // yantar92,
>> Org mode contributor,
>> Learn more about Org mode at .
>> Support Org development at ,
>> or support my work at 
>>
>
diff -u /home/dto/Downloads/changes.org /home/dto/orginfo/changes.org
--- /home/dto/Downloads/changes.org	2022-12-13 11:41:29.005889535 -0500
+++ /home/dto/orginfo/changes.org	2022-12-13 11:48:20.807362246 -0500
@@ -8,7 +8,13 @@
 #+INFOJS_OPT: up:https://orgmode.org/worg/
 #+INFOJS_OPT: home:https://orgmode.org buttons:nil
 
+* 2022-12-13 David O'Toole
 
+  * Create additional hooks so that the end-user can insert
+per-section custom HTML (OrgInfoPageInsertFunction) and handle
+navigation events (OrgInfoAfterNavigateFunction).
+
+  * Correct English error/status messages displayed in minibuffer.
 
 * 2010-11-24 Benny Simonsen Part 1
 

Diff finished.  Tue Dec 13 12:18:39 2022
diff -u /home/dto/Downloads/index.org /home/dto/orginfo/index.org
--- /home/dto/Downloads/index.org	2022-12-13 11:41:43.022078142 -0500
+++ /home/dto/orginfo/index.org	2022-12-13 12:17:18.460761688 -0500
@@ -192,8 +192,8 @@
  version 0.0.7.3a (fixed in current Org-mode versions). If you export with
  =skip:nil=, you may add this to your stylesheet:
  : #text-before-first-headline {color:red;font-weight:bold;}
-+ Hooks :: The OrgHtmlManager object provides hooks (two currently) to add
- custom actions.
++ Hooks :: There are several hooks to add custom actions. See the
+  section "Hooks" for more information.
 
 * Shortcuts
 :PROPERTIES:
@@ -703,8 +703,15 @@
 :CUSTOM_ID: hooks
 :END:
 
-Currently two hooks are provided.  Each hook function is called with one or
-more parameters the first of which is the OrgHtmlManager object.
+Two styles of hooks are supported: Standard hooks (which use
+OrgHtmlManager and require a bit of bookkeeping) and simple hooks,
+which are JavaScript variables that hold a function.
+
+** Standard hooks
+
+Currently two standard hooks are provided.  Each hook function is
+called with one or more parameters the first of which is the
+OrgHtmlManager object.
 
 - '~onReady~' :: This hook is run once the document is loaded, the view is
  setup and the startup section is shown.  The second parameter
@@ -714,7 +721,6 @@
  first section.  The second parameter is an object with to OrgNodes: the
  previously shown section and the current section.
 
-
 To add functions to the hooks, fill a global object ~orgInfoHooks~ with the
 function objects you need.  This is necessary, because code added via the
 ~#+STYLE:~ option lines is executed before org-info.js is loaded.
@@ -748,6 +754,50 @@
 could happen otherwise (the hook loop will overlook a member. While the hook
 loop runs in first hook first, the remove loop removes the last hook first).
 
+** Simple hooks
+
+Simple hooks are just JavaScript variables that point to particular
+functions that OrgInfo will call. There are two simple hooks thus far:
+=OrgInfoPageInsertFunction= and =OrgInfoAfterNavigateFunction=.
+
+If you assign your own functions to these variables, be sure to do so
+after OrgInfo has loaded, or they will not work. You can do so from an
+org file like this:
+
+#+begin_src org
+ #+begin_export HTML
+ 
+ 

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:

>>> 2. If #1 depends on some org variable settings, can you mention what
>>> variables control the answer to #1?
>>
>> If you mean "can open", then see the next section.
>
> Ahh, maybe I am in the wrong section.  I think, what I want is
> org-open-at-point (which could be mentioned in 4.4), but it's
> documentation string just says the linked file will be opened by "an
> appropriate application".  I assume that that means some Elisp function
> is called that cross-references the file type with appropriate
> application.  And that I could add to or adjust the cross-reference list
> for new/modified file types.  It would be nice to mention that list
> variable so that I could trace the process further and determine what to
> do (like install the appropriate application).
>
> Does this help for what I'm looking for?

4.5 Handling Links
...
‘C-c C-o’ (‘org-open-at-point’)
...
 ... Furthermore, it visits text and
 remote files in ‘file’ links with Emacs and select a suitable
 application for local non-text files.  Classification of files is
 based on file extension only.  See option ‘org-file-apps’.  If you
 want to override the default application and visit the file with
 Emacs, use a ‘C-u’ prefix.  If you want to avoid opening in Emacs,
 use a ‘C-u C-u’ prefix.


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

[David Masterson]

Ihor Radchenko  writes:

> David Masterson  writes:
>
>> The documentation page for "4.4 External Links" could provide the
>> answers to following questions:
>>
>> 1. What "file types" are supported by link type "file"?
>
> All. Though I am not sure what you mean by "supported".

As in, if you follow (open?) a file link, how is the file handled
(particularly, for me, JPG, PNG, MP4, etc.)?  What's the process by
which an image gets inlined?  Do I have to install some image processor
to do that?  If so, which?  Or can I adjust a variable to use my chosen
image processor? 

>> 2. If #1 depends on some org variable settings, can you mention what
>> variables control the answer to #1?
>
> If you mean "can open", then see the next section.

Ahh, maybe I am in the wrong section.  I think, what I want is
org-open-at-point (which could be mentioned in 4.4), but it's
documentation string just says the linked file will be opened by "an
appropriate application".  I assume that that means some Elisp function
is called that cross-references the file type with appropriate
application.  And that I could add to or adjust the cross-reference list
for new/modified file types.  It would be nice to mention that list
variable so that I could trace the process further and determine what to
do (like install the appropriate application).

Does this help for what I'm looking for?

-- 
David Masterson

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

[Max Nikulin]

On 13/12/2022 08:53, Tom Gillespie wrote:

+(defcustom org-confirm-babel-evaluate-cell t
+  "Confirm before evaluating a cell.
+This follows the same conventions as `org-confirm-babel-evaluate'."


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

Am I wrong that, roughly speaking, the effective value is (and 
org-confirm-babel-evaluate-cell org-confirm-babel-evaluate)? Should it 
be described in the docstring? It seems e.g. :eval query affects the 
latter, but not the former. If it is so then it is too complicated for 
me to feel firm ground while reasoning on security.


I have not decided if it is feasible to add some property to the INFO 
argument passed to `org-babel-confirm-evaluate' and to put there 
condition which variable should determine result.

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

[David O'Toole]

Sure, I would be happy to help out with the news and manual.
I will draft some changes and get back to you.


> This addition does sound useful.
> However, in addition to changes in the code, it would be helpful to
> provide appropriate news entry and manual changes.
>

On Tue, Dec 13, 2022 at 5:00 AM Ihor Radchenko  wrote:

> "David O'Toole"  writes:
>
> > After some discussion with Yantar on IRC, I humbly submit the attached
> diff
> > for your consideration.
> >
> > It adds new hooks to org-info-js to allow the following: 1. inserting
> > page-specific HTML into each OrgInfo header, and 2. calling a custom
> > JavaScript function to run after any page navigation button/link is
> > clicked. I have used these hooks to implement Org-fleuron, a custom
> config
> > with nice navigation buttons, a greeting balloon, and embedded
> theme/fonts.
> > You can find out more about org-fleuron here:
> > https://davidotoole.info/fleuron.html?#org5dc18bc and the page was made
> > with the setup.
> >
> > I also corrected some of the English messages displayed by org-info-js.
>
> This addition does sound useful.
> However, in addition to changes in the code, it would be helpful to
> provide appropriate news entry and manual changes.
>
> See
> https://git.sr.ht/~bzg/worg/tree/master/item/code/org-info-js/changes.org
> and
> https://git.sr.ht/~bzg/worg/tree/master/item/code/org-info-js/index.org
>
> Bastien, since the activity around org-info-js revived after a long
> delay, should we move the code out of worg into a separate repo?
>
> --
> 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

[Max Nikulin]

On 12/12/2022 03:27, Tom Gillespie wrote:


#+begin_src elisp :results none
(setq-local
  org-confirm-babel-evaluate-cell
  (lambda (lang body)
(ignore lang)
(let ((rb (read body)))
  (not ; aka (unless condition t)
   (or
(member rb
'((or)
  (and)
  ;; add more forms that are known safe here
  ))


Thank you, Tom. At first I thought you managed to define a function that 
treats particular directories as safe (to discriminate own files and 
files having non-trusted origins). However in such case you would not 
need additional user option and `org-confirm-babel-evaluate' would be 
enough.


Walking through the passed expression to prove that it has no side 
effects is an interesting and challenging problem.


And frankly speaking, I was confused and believed that it is 
responsibility of the new function to issue e.g. `yes-or-no-p' prompt. 
Now I see that it is `org-babel-confirm-evaluate' that shows such prompt.

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

[Matt Lundin]

Ihor Radchenko  writes:

> Matt Lundin  writes:

>> - What currently happens if org-mouse has been loaded:
>>
>>   - calling "C-c C-o" with the keyboard cycles the visibility of the
>> entry

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

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.

Matt

Re: [PATCH] oc-csl: Improve LaTeX bibliography formatting

[Timothy]

Hi Ihor and András,

> In the news, it could be example image indicating the distances, while
> in the docstrings you can schematically indicate the spacings using text
> example.

Perhaps an ASCII approximation in an example block could work? Even if it’s
exaggerated to give the idea.

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: Org functions in source blocks

[Max Nikulin]

On 12/12/2022 10:23, William Denton wrote:

On 10 December 2022, Max Nikulin wrote:

@I$A and the "remote" function are available in table formulas only. 

...

I'll be back with more questions eventually,


Using source blocks you may define new functions that you may call from 
table formulas.


You may create an intermediate table to evaluate expressions heavily 
relied on cell ranges and feed this table to another source block as a 
variable.


By the way, a range may be specified when passing a table as a source 
block variable, but it uses another syntax, see


(info "(org)Environment of a Code Block")
https://orgmode.org/manual/Environment-of-a-Code-Block.html

So it is possible to mix table formulas and source code blocks.

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

[Max Nikulin]

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

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

[Max Nikulin]

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.



The original issue reported in this thread is actually strange - we have
no single autoload cookie in org-mouse.el. May it be something to do
with the new Emacs autoload generation?


I do not think it is something new. Even in Emacs-26 
`generate-file-autoloads' adds


   (if (fboundp 'register-definition-prefixes) 
(register-definition-prefixes "org-mouse" '("org-")))


to org-loaddefs.el. The function is called for all sources by 
`org-make-org-loaddefs' (defined in mk/org-fixup.el).

Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]

[Johan Tolö]

Greg Minshall  writes:

list(1,2,3)

[[1]]
[1] 1

[[2]]
[1] 2

[[3]]
[1] 3


c(1,2,3)

[1] 1 2 3

(where =c= is the "concatenation operator".)

so, to me, at least, "proper list" is not a well-defined term in 
R.


cheers, Greg


=c= is "a generic function which combines its arguments" according 
to the R documentation. It could do different things depending on 
the input.


=list()= will create an actual R list which are "Generic Vectors" 
according to the R documentation. Each element of a list can be 
any other R data structure including other lists, expressions and 
symbols.


"Proper list" in the context of this discussion and pertaining to 
R would be a =list()=, not a vector which is what is usually 
returned by =c()=. A =data.frame()= is a special case of a 
=list()= where every column has to have the same length.



Johan

--
Johan Tolö

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

[Ihor Radchenko]

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

> I have a practical question, though: in order to see the effect of
> your patch in context, I applied it in my git repository and did
>
>make && make doc
>
> I then can see the change in the org.pdf file, but not in the Info
> manual, although I used
>
>emacs -Q -l .emacs.git
>
> with .emacs.git containing
>
>(add-to-list 'load-path "~/Org/Coch-git/org-mode/lisp")
>
>(setq Info-default-directory-list 
>(append '("/home/cochard/Org/Coch-git/org-mode/doc")
>Info-default-directory-list))
>
> What am I doing wrong?  Thank you.

Check out [[info:info#Emacs Info Variables]]

Basically, INFOPATH environment variable takes precedence.
You may also take a look at `Info-directory-list' docstring.

straight.el uses the following, slightly awkward approach:

(require 'info)
(info-initialize)
(add-to-list 'Info-directory-list "~/Git/org-mode/doc/")

Emacs info page suggests to set environment variable.

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

Re: How to disable completely org-persist

[Ihor Radchenko]

Ihor Radchenko  writes:

> Colin Baxter  writes:
>
>> I too would like a means to disable org-persist. I don't doubt it may be
>> useful for those users with "large" org files with multiply src-blocks,
>> etc., etc., but, for me, I have not found any improvement in
>> performance. As remarked by the OP, the feature should not be
>> default-enabled.
>
> Note that org-persist is not only used to cache parser data for large
> files. For example, exported online images are also cached instead of
> being downloaded on every export. Other things may also be cached in
> future.

Upon further investigation, it looks like we need Org persist all the
time. As temporary storage, at least. In particular, downloading remote
images requires org-persist to store files somewhere. All the times.

> That being said, it should not be a big deal to allow disabling
> org-persist when desired. In fact, org-persist is already auto-disabled
> when using emacs -Q. I can add a user switch on top.

So, we cannot disable org-persist and should not even do it with Emacs
-Q. Instead, we may redirect org-persist-directory to /tmp in some
scenarios. I will look into doing this soon.

-- 
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 Tue 13 Dec 2022 11:43:

 > Does the attached patch help with understanding?

Yes, for me this is perfectly clear.

I have a practical question, though: in order to see the effect of
your patch in context, I applied it in my git repository and did

   make && make doc

I then can see the change in the org.pdf file, but not in the Info
manual, although I used

   emacs -Q -l .emacs.git

with .emacs.git containing

   (add-to-list 'load-path "~/Org/Coch-git/org-mode/lisp")

   (setq Info-default-directory-list 
 (append '("/home/cochard/Org/Coch-git/org-mode/doc")
 Info-default-directory-list))

What am I doing wrong?  Thank you.

-- 
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: Keys to Category Filter Agenda

[Ihor Radchenko]

Colin Baxter  writes:

> > Initial prompt buffer only describes bindings for that buffer.
> > They are totally different from agenda-mode buffer.
>
> That is not correct for the '<' key. You are told "Restriction is only
> possible in Org buffers". In my opinion the distinction of the '<' key
> should be more positively indicated. The wording and arrangement of the
> prompt buffer is confusing at best. It is disheartening when the
> difficulties experienced by a non-specialist seem to be dismissed
> out-of-hand.

I feel like we are misunderstanding each other here.

Could you please try to describe what you are confused about with more
examples or in other words?

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

Re: Keys to Category Filter Agenda

[Colin Baxter]

> Ihor Radchenko  writes:

> Colin Baxter  writes:
>> Indeed. I understand that, but the question was about '>' not
>> '<'. The initial agenda buffer has
>> 
>> < Buffer, subtree/region restriction > Remove restriction
>> 
>> If I remove the restriction with >, as suggested by the initial
>> buffer, I get the date prompt. I have to enter either '<' again
>> or '|' to clear the restrictions. This information is given only
>> in org-mode info not in the initial agenda buffer.

> Initial prompt buffer only describes bindings for that buffer.
> They are totally different from agenda-mode buffer.

That is not correct for the '<' key. You are told "Restriction is only
possible in Org buffers". In my opinion the distinction of the '<' key
should be more positively indicated. The wording and arrangement of the
prompt buffer is confusing at best. It is disheartening when the
difficulties experienced by a non-specialist seem to be dismissed
out-of-hand.

Best wishes,

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

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

> thanks for the patience. I hope to have implemented all suggestions by now.

No. You missed several.

1. :version is not necessary. See 15.1 Common Item Keywords section of
Elisp manual:

2. Please also provide changelog entries. See
https://orgmode.org/worg/org-contribute.html#commit-messages

More comments below.
 
> +*** New =org-latex-listings-src-omit-language= variable for LaTeX export
> +
> +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= backend
> +forwards the actual listing generation to another package like
> +=fancyvrb= using the following setup in the document header:

Please use ~code~ for Elisp symbols and double space between sentences.
You may refer to etc/Documentation_Standards.org file for details.

> +#+BEGIN_example
> +#+LATEX_HEADER: \\RequirePackage{fancyvrb}
> +#+LATEX_HEADER: 
> \\DefineVerbatimEnvironment{verbatim}{Verbatim}{...whatever...}
> +#+LATEX_HEADER: 
> \\DefineVerbatimEnvironment{lstlisting}{Verbatim}{...whatever...}
> +#+END_example

Please quote #+LATEX_HEADER in the example block with commas. (Org will
do it automatically for you if you edit the example block with C-c ')

> +*** The LaTeX export backend only emits =label= and =caption= when they are 
> not empty
> +
> +When exporting a SRC block and using the listings backend , =label==
> +and =caption== parameters for the =lstlisting= environment will be
> +only generated when they are not empty. Things like
> +
> +#+BEGIN_src latex
> +\begin{lstlisting}[label= ,caption= ,captionpos=b]
> +\end{lstlisting}
> +#+END_src
> +
> +will no more appear.

This is probably not something people need to take note of. Not necessary.
  
> Subject: [PATCH 2/4] Allow to suppress language= in SRC blocks
> Subject: [PATCH 3/4] Refine DOCSTRING for org-latex-listings-src-omit-language

2nd and 3rd patches can be merged into one.

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

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

>  > It does, but you need to load org-goto library first.
>  > (It is also auto-loaded when you call org-goto via key binding)
>
> I see.  Thank you.  (I guess it wouldn't hurt to mention this in the
> manual.)

Does the attached patch help with understanding?
>From ee19ca2493861947c9ef08acee74d5efc13449b8 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Tue, 13 Dec 2022 14:41:44 +0300
Subject: [PATCH] doc/org-manual.org: Document that org-goto.el is not loaded
 by default

* doc/org-manual.org (Motion): Mention that `org-goto-*' customization
are only available upon explicit `require' or auto-loading of
org-goto.el.

Reported-by: alain.coch...@unistra.fr
Link: https://orgmode.org/list/25496.19258.682537.503...@gargle.gargle.howl
---
 doc/org-manual.org | 4 
 1 file changed, 4 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 4fb017db8..e7f32d1da 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -693,6 +693,10 @@ ** Motion
   #+texinfo: @noindent
   See also the variable ~org-goto-interface~.
 
+  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.
+
 ** Structure Editing
 :PROPERTIES:
 :DESCRIPTION: Changing sequence and level of headlines.
-- 
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] Documentation fix needed in "4.4 External Links" [9.6 ( @ /home/dsmasterson/.emacs.d/elpa/org-9.6/)]

[Ihor Radchenko]

David Masterson  writes:

> The documentation page for "4.4 External Links" could provide the
> answers to following questions:
>
> 1. What "file types" are supported by link type "file"?

All. Though I am not sure what you mean by "supported".

> 2. If #1 depends on some org variable settings, can you mention what
> variables control the answer to #1?

If you mean "can open", then see the next section.

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

Re: 9.6 - hide-drawer-startup option(s?) [9.5.5 (release_9.5.5 @ /usr/local/share/emacs/29.0.50/lisp/org/)]

[Ihor Radchenko]

Kévin Le Gouguec  writes:

> Trying out Emacs 29 and going over ORG-NEWS, this item stands out to me:
>
>> *** A new custom setting =org-hide-drawer-startup= to control initial 
>> folding state of drawers
>
> A quick grep for org(-cycle)?-hide-drawer-startup turns this up:
>
> File: etc/ORG-NEWS
>  459  27 *** A new custom setting =org-hide-drawer-startup= to control 
> initial folding state of drawers
>
> File: lisp/org-cycle.el
>  128  12 (defcustom org-cycle-hide-drawer-startup t
>  630  11 (when org-cycle-hide-drawer-startup (org-cycle-hide-drawers 
> 'all))
>
> File: lisp/org.el
> 4074  20 ("hidedrawers" org-hide-drawer-startup t)
> 4075  22 ("nohidedrawers" org-hide-drawer-startup nil)

Thanks for the heads-up!
Fixed on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4323a19b1
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=47bcdce19

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

[Pedro Andres Aranda Gutierrez]

Hi,

thanks for the patience. I hope to have implemented all suggestions by now.

BR,/PA

On Tue, 13 Dec 2022 at 10:24, Ihor Radchenko  wrote:

> Pedro Andres Aranda Gutierrez  writes:
>
> > I've (finally) followed the procedure and broken up the patch in two. One
> > for the labels= ,caption=  and one for the language= control.
>
> Thanks!
> You also need to provide etc/ORG-NEWS entry since we are adding a new
> feature here.
>
> > FYI, I have already cleared the FSF paperwork for an emacs patch.
>
> Bastien, could you kindly confirm?
>
> > Subject: [PATCH 2/2] Allow to suppress language= in SRC blocks
>
> Please also provide changelog entries. See
> https://orgmode.org/worg/org-contribute.html#commit-messages
>
> > +(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"
>
> Please describe in the docstring when this kind of setting is needed.
>
> > +  :group 'org-export-latex
> > +  :version "30.0"
>
> :version is not necessary. See 15.1 Common Item Keywords section of
> Elisp manual:
>
> ‘:version VERSION’
>  This keyword specifies that the item was first introduced in Emacs
>  version VERSION, or that its default value was changed in that
>  version.  The value VERSION must be a string.
>
> ‘:package-version '(PACKAGE . VERSION)’
>  This keyword specifies that the item was first introduced in
>  PACKAGE version VERSION, or that its meaning or default value was
>  changed in that version.  This keyword takes priority over
>
>  ‘:version’.
>  ^^^
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet
From 3bc08d0ccabb2d3f4a0ea09bec5bc6a896c351ac Mon Sep 17 00:00:00 2001
From: "Pedro A. Aranda Gutierrez" 
Date: Mon, 12 Dec 2022 13:49:35 +0100
Subject: [PATCH 1/4] Don't emit empty labels and captions in SRC blocks

---
 lisp/ox-latex.el | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index a2d60d5db..f03903605 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3594,11 +3594,14 @@ and FLOAT are extracted from SRC-BLOCK and INFO in `org-latex-src-block'."
   ((and float (not (assoc "float" lst-opt)))
`(("float" ,(plist-get info :latex-default-figure-position)
  `(("language" ,lst-lang))
- (if label
- `(("label" ,(org-latex--label src-block info)))
-   '(("label" " ")))
- (if caption-str `(("caption" ,caption-str)) '(("caption" " ")))
- `(("captionpos" ,(if caption-above-p "t" "b")))
+ (when label
+ `(("label" ,(org-latex--label src-block info
+ (when caption-str
+   `(("caption" ,caption-str)))
+ (when caption-str
+   ;; caption-above-p means captionpos is t(op)
+   ;; else b(ottom)
+   `(("captionpos" ,(if caption-above-p "t" "b"
  (cond ((assoc "numbers" lst-opt) nil)
((not num-start) '(("numbers" "none")))
(t `(("firstnumber" ,(number-to-string (1+ num-start)))
-- 
2.25.1

From 33d2ca63e749da8f1faacb66ece636df66464416 Mon Sep 17 00:00:00 2001
From: "Pedro A. Aranda Gutierrez" 
Date: Tue, 13 Dec 2022 12:07:09 +0100
Subject: [PATCH 4/4] Add entries to ORG-NEWS for changes and
 org-latex-listings-src-omit-language

---
 etc/ORG-NEWS | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 5d5e726e0..7fa9122ee 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -432,6 +432,20 @@ following properties: ~:hook~, ~:prepare-finalize~,
 ~:before-finalize~, ~:after-finalize~.  These nullary functions run
 prior to their global counterparts for the selected template.
 
+
+*** New =org-latex-listings-src-omit-language= variable for LaTeX export
+
+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= backend
+forwards the actual listing generation to another package like
+=fancyvrb= using the following setup in the document header:
+#+BEGIN_example
+#+LATEX_HEADER: \\RequirePackage{fancyvrb}
+#+LATEX_HEADER: \\DefineVerbatimEnvironment{verbatim}{Verbatim}{...whatever...}
+#+LATEX_HEADER: \\DefineVerbatimEnvironment{lstlisting}{Verbatim}{...whatever...}

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

[Ihor Radchenko]

"David O'Toole"  writes:

> After some discussion with Yantar on IRC, I humbly submit the attached diff
> for your consideration.
>
> It adds new hooks to org-info-js to allow the following: 1. inserting
> page-specific HTML into each OrgInfo header, and 2. calling a custom
> JavaScript function to run after any page navigation button/link is
> clicked. I have used these hooks to implement Org-fleuron, a custom config
> with nice navigation buttons, a greeting balloon, and embedded theme/fonts.
> You can find out more about org-fleuron here:
> https://davidotoole.info/fleuron.html?#org5dc18bc and the page was made
> with the setup.
>
> I also corrected some of the English messages displayed by org-info-js.

This addition does sound useful.
However, in addition to changes in the code, it would be helpful to
provide appropriate news entry and manual changes.

See
https://git.sr.ht/~bzg/worg/tree/master/item/code/org-info-js/changes.org
and
https://git.sr.ht/~bzg/worg/tree/master/item/code/org-info-js/index.org

Bastien, since the activity around org-info-js revived after a long
delay, should we move the code out of worg into a separate repo?

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

Re: Two problems with export to Google calendar

[Ihor Radchenko]

Max Nikulin  writes:

> The TZ environment variable is not set and that is the issue. Otherwise 
> the .ics file would have
>
> X-WR-TIMEZONE:Europe/London
>
> The problem is that there is no API to get time zone identifier in elisp 
> because such function is missed in libc. It is possible to get only 
> BST/GMT (depending on current season).
>
> Identifiers like Europe/London allows to get history of time 
> transitions. (format-time-string "%z %Z") and (current-time-zone) may 
> only report time offset and ambiguous abbreviation at particular moment. 
> Return values of these functions may vary for different timestamps in 
> the calendar file. If list of time zones were available then it would be 
> possible to iterate over it and to match particular time zone by 
> abbreviation and offset for most of zones (perhaps some ambiguity would 
> remain).
>
> Actually `current-time-zone' is an example of fragile API for *current* 
> time. Offset is valid for particular moment. There is no guarantee that 
> offset would not change between obtaining it and applying to a 
> timestamp. So the only safe way of using this function is with the 
> SPECIFIED-TIME argument. In such case *current* in the function name is 
> confusing.
>
> So in my previous message I was considering feasibility of some 
> platform-dependent code to determine time zone when neither TIMEZONE Org 
> file property nor TZ environment are specified.

Thanks for the explanation.

I do not think that it is a problem Org has to solve. Rather Emacs. Or
even libc.

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

Re: Autoloading side effects (was: Re: [BUG] org-mouse is activated without explicit require)

[Ihor Radchenko]

Max Nikulin  writes:

>> We have `org-modules' that can handle calling `org-link-set-parameters'.
>
> Sorry, but I have not got your idea. Currently `org-modules' is just a 
> list of packages that should be loaded with org.el.
>
> It is possible to introduce some convention either in Org or in Emacs to 
> add default action for a package. Then in addition to just loading a 
> package (with no side effects) a set of functions should be implemented 
> that loads and *activates* the package.

We can simply process 'ol-* in `org-modules' specially.
Although, I am not having second thoughts about behaviour of require.

The original issue reported in this thread is actually strange - we have
no single autoload cookie in org-mouse.el. May it be something to do
with the new Emacs autoload generation?

-- 
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 Tue 13 Dec 2022 09:33:
 > alain.coch...@unistra.fr writes:
 > 
 > > 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.
 > 
 > It does, but you need to load org-goto library first.
 > (It is also auto-loaded when you call org-goto via key binding)

I see.  Thank you.  (I guess it wouldn't hurt to mention this in the
manual.)



-- 
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: org-insert-structure-template

[Ihor Radchenko]

Anthony Carrico  writes:

>> The general pattern is C-c C-x . Maybe we can add "C-c C-x ,"?
>
> Thanks, that is probably a good pattern to use. I'll look into 
> org-use-extra-keys. This is the only keybinding that regularly bites me 
> on the TTY.

C-c C-x , is actually not available (it is bound to timer).
I went with C-c C-x s.

See the attached patch.

>From 2646a3279689cd9afdf4b5b0e44d29c1fca38d84 Mon Sep 17 00:00:00 2001
Message-Id: <2646a3279689cd9afdf4b5b0e44d29c1fca38d84.1670924473.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Tue, 13 Dec 2022 12:30:36 +0300
Subject: [PATCH] lisp/org-keys.el: Provide terminal binding for
 `org-insert-structure-template'

* lisp/org-keys.el (or): Add alternative terminal binding for
`org-insert-structure-template'.  The default binding may not be
available in some terminals.

* doc/org-manual.org (Using Org on a TTY): List the new binding in the
manual.

Reported-by: Anthony Carrico 
Link: https://orgmode.org/list/d9222967-5747-bf54-8041-4a8453fe8...@memebeam.org
---
 doc/org-manual.org | 1 +
 lisp/org-keys.el   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 0680fb593..1431f8546 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -20481,6 +20481,7 @@ ** Using Org on a TTY
 | {{{kbd(S-DOWN)}}}| {{{kbd(C-c DOWN)}}}  |  |  |
 | {{{kbd(C-S-LEFT)}}}  | {{{kbd(C-c C-x LEFT)}}}  |  |  |
 | {{{kbd(C-S-RIGHT)}}} | {{{kbd(C-c C-x RIGHT)}}} |  |  |
+| {{{kbd(C-c C-\,)}}}  | {{{kbd(C-c C-x s)}}} |  |  |
 
 ** Protocols for External Access
 :PROPERTIES:
diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index 95f64a3f9..7c6e38e64 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -503,6 +503,7 @@ (when (or org-use-extra-keys (not (display-graphic-p)))
   (org-defkey org-mode-map (kbd "C-c C-x c") #'org-table-copy-down)
   (org-defkey org-mode-map (kbd "C-c C-x m") #'org-meta-return)
   (org-defkey org-mode-map (kbd "C-c C-x M") #'org-insert-todo-heading)
+  (org-defkey org-mode-map (kbd "C-c C-x s") #'org-insert-structure-template)
   (org-defkey org-mode-map (kbd "C-c C-x RET") #'org-meta-return)
   (org-defkey org-mode-map (kbd "ESC RET") #'org-meta-return)
   (org-defkey org-mode-map (kbd "ESC ") #'org-metaleft)
-- 
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: Does variable 'org-goto-interface' exist?

[Ihor Radchenko]

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

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

It does, but you need to load org-goto library first.
(It is also auto-loaded when you call org-goto via key binding)

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

> I've (finally) followed the procedure and broken up the patch in two. One
> for the labels= ,caption=  and one for the language= control.

Thanks!
You also need to provide etc/ORG-NEWS entry since we are adding a new
feature here.

> FYI, I have already cleared the FSF paperwork for an emacs patch.

Bastien, could you kindly confirm?

> Subject: [PATCH 2/2] Allow to suppress language= in SRC blocks

Please also provide changelog entries. See
https://orgmode.org/worg/org-contribute.html#commit-messages

> +(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"

Please describe in the docstring when this kind of setting is needed.

> +  :group 'org-export-latex
> +  :version "30.0"

:version is not necessary. See 15.1 Common Item Keywords section of
Elisp manual:

‘:version VERSION’
 This keyword specifies that the item was first introduced in Emacs
 version VERSION, or that its default value was changed in that
 version.  The value VERSION must be a string.

‘:package-version '(PACKAGE . VERSION)’
 This keyword specifies that the item was first introduced in
 PACKAGE version VERSION, or that its meaning or default value was
 changed in that version.  This keyword takes priority over
   
 ‘:version’.
 ^^^

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

Re: [PATCH 1] lisp/org-fold.el: Fold header lines in blocks (was: Proposal: folding stacked `#+header:' lines in src blocks)

[Ihor Radchenko]

h...@heagren.com writes:

> Great! I've worked up a patch (well, two patches), attached.
>
> Some details of the implementation:
> - folding blocks now cycles:
>- everything folded (only top header line visible if present,
>  otherwise only `#+begin' line visible).
>- all content visible, (header stack folded, top header visible,
>  `#+begin' and `#+end' lines visible).
>- everything visible
>- (the second and third are treated as equivalent unless there is
>  more than one header line.)

This logic does not really belong to org-fold.el. Rather to
org-cycle.el(org-cycle). Ideally, we need to split `org-cycle' into
smaller functions.

Also, changing default toggle behaviour may break third-party usage.
People now expect flipping between folded/unfolded. Your patch will
change that.

> - renames `org-fold--hide-wrapper-toggle' to
>`org-fold--hide-wrapper-cycle', which seemed more appropriate under
>the circumstances.

Please, no. As I said above, we need to move the cycling logic to
org-cycle. `org-fold--hide-wrapper-toggle' may only be modified to
accept a new value of FORCE other than 'off.

> Some less-than-perfections:
> - I'm not sure what to do about default block folding (as in, how
>blocks are folded when a file is first visited). First, I don't have
>a complete list of things (variables, startup options, etc.) which
>affect it. Secondly, I'm not sure what the behaviour should be now
>that blocks can be in up to three folding states. Advice would be
>appreciated.

We may define default folding state at startup via defcustom.

> - I'm not sure what other documentation I should add. Once this patch
>is stable and people approve of it, I can add a news entry. Should I
>update the manual at all?

Yes. For example, 2.8 Blocks section of the manual. But let's decide
about implementation first. Manual if the last thing to do.

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

Does variable 'org-goto-interface' exist?

[Alain . Cochard]

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.

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

Hi,

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?

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

Re: [PATCH] lisp/org-expiry.el: Account for org-time-stamp-formats

[Ihor Radchenko]

Tom Gillespie  writes:

> Here's the rebased patch. It should apply without issue. Best!

Applied.
https://git.sr.ht/~bzg/org-contrib/commit/b6712e688b3a54c54b80ab34525d4672ff2a8d7a

Marcel, note that your recent patch has been overwritten. Let me know if
you have any objections.

Also, if you see no urgent issues with org-contrib, I plan to tag the
current master as requested in
https://orgmode.org/list/m28rjerx1t@purvis.id.au

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

Tom Gillespie  writes:

> Hi Ihor,
>Here's the updated patch using :safe, and an additional
> patch for the news entry to make it easier to apply the
> core change to bugfix if needed. Best!

LGTM.

I will wait a few more days in case if other contributors have something
to say and then apply onto bugfix.

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

Re: Incorrect numbering of tables (and other elements like figures) [Org 9.6]

[Ihor Radchenko]

Kaushal Modi  writes:

> Since Org 9.6, I am seeing that the numbering of tables (and other elements
> like figures) resets to 1 and stays so, thought I cannot see a pattern of
> why that happens.
>
> Org version: Org mode version 9.6 (release_9.6-40-g49cf3e ..)
>
> Here's a small reproducible example that shows the problem in any exporter
> (ox-ascii, ox-html, ..)
> ...

Thanks for reporting!
Fixed on bugfix. With a test now.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=bdb4c4c66
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=02909fe37

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

Re: [BUG] org-cycle-max-level is broken, especially when using org-element-cache (was: Problem in org-inlinetask-min-level's docstring?)

[Alain . Cochard]

Ihor Radchenko writes on Tue 13 Dec 2022 07:36:
 > alain.coch...@unistra.fr writes:
 > 
 > > NB: While experimenting, I noticed that, if I customize
 > > org-cycle-max-level to 0, then a  on a headline generates the
 > > cryptic "org-match-line: Invalid regexp: "Invalid content of
 > > \\{\\}"".  
 > 
 > Well. It does not really make much sense to set this variable to 0
 > or negative values.  I guess we can add a guard against such
 > scenarios.

Indeed, it does not make sense, but I realized it only when I fully
understood the behavior.

If one experiments, customizing several variables in row, it will take
time to identify the origin of the message.  Specifying in the
documentation of the Customize buffer (=customize docstring?) that the
value of this variables has to be greater than or equal to 1 will
certainly help; also having as the error message, instead of the
current one, would be even better (perhaps that is what you call a
"guard").


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