LaTeX export ignores caption if table is in a drawer

[Richard H. Stanton]

I often create tables programatically from within an org code block. To make 
sure I don’t produce multiple copies of the output, I like to enclose the 
results in a drawer. However, the exporter seems to ignore any caption I might 
assign if the table itself is inside a drawer. For example, if you export the 
sample org file below to LaTeX, the first table gets exported with caption, the 
second without. Would it be possible for the exporter to keep the caption in 
the second case as well? 

[By the way, this would be particularly helpful at the moment, as for some 
reason emacs-jupyter currently seems to put all results in a drawer regardless 
of whether you ask it to or not…).

Thanks.

Richard Stanton




———

#+caption: Small table
| C1 | C2 |
|+|

#+caption: Small table
:results:
| C1 | C2 |
|+|
:end:


———

Re: How to send patch for org-contrib?

[dalanicolai]

Ah great, good to know... thanks again!

On Thu, 25 May 2023 at 12:57, Ihor Radchenko  wrote:

> dalanicolai  writes:
>
> > I have just created a patch for org-eldoc.el in org-contrib.
> > I tried to send it using the 'Prepare a patchset' functionality on
> > sourcehut which
> > requires me to enter some email-address for where to send it to.
> > As I have no idea where to send it, I simply filled in the address of
> this
> > mailing list.
> > However, I do not see the message appear in my inbox.
> >
> > So, I am wondering, how should I send a patch for org-contrib?
>
> You patch did reach the Org ML:
>
> https://list.orgmode.org/168500905821.7612.716094690080728324...@git.sr.ht/T/#t
>
> It is also likely listed somewhere in your sr.ht account, like in
> activity feed (mine is https://sr.ht/~yantar92/). In future, you can add
> your personal email to CC when sending a patchset.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: Unable to install from elpa

[Max Nikulin]

On 13/11/2021 12:39, Carlos Pita wrote:

in a clean emacs-28 install I do:

 M-x package-install  org

I get:

 Possible completions are:
 org-contrib org-edna org-real org-translate orgalist


I have realized that the command is specified in the README.org file, so 
it is mentioned twice on https://elpa.gnu.org/packages/org.html


However prior to Emacs-29.1 built-in packages are filtered-out from 
completion list and ignored by non-interactive command


https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=580d8278
2023-04-13 20:13:59 +0200 Allow upgrading built-in packages with 
'package-install'


Should `list-packages' recipe be used in the README.org file instead?

Re: [PATCH org-contrib 0/1] Fix org-eldoc functionality

[dalanicolai]

Thanks, for the quick merge. And noted... :)


On Thu, 25 May 2023 at 13:03, Ihor Radchenko  wrote:

> ~dalanicolai  writes:
>
> > Eldoc functionality only works after a restricted set of commands (see
> > the variable 'eldoc-message-commands'). Because `org-self-insert-
> > command', by default, is not in that list, eldoc functionality works
> > poorly in org-mode (it does not work when typing, only when navigating).
> > This patch fixes it for when using org-eldoc.el.
>
> Applied, onto master.
>
> https://git.sr.ht/~bzg/org-contrib/commit/aed67d095de23bc45446777f7b8fb30b8e5c0c51
>
> Do note that we only provide minimal maintenance for org-contrib.
> Packages from org-contrib are looking for new proper maintainers.
> See https://orgmode.org/worg/org-orphanage.html
>
> --
> 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.el: allow org-return to call org-open-at-point on citations

[Ihor Radchenko]

Bruno Cardoso  writes:

> On 2023-05-22, 10:49 +, Ihor Radchenko  wrote:
>
>> Thanks!
>> May you also update the docstring of `org-return-follows-link' and add
>> etc/ORG-NEWS entry?
>
> Hi Ihor, here's the updated patch as suggested.

Thanks!
I modified the patch, adding the necessary non-nil WITH-SELF argument
and changing the wording of `org-return-follows-link' docstring.
I also added tests.

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

By accident, I forgot to adjust author field in the amended commit.
Hope, you don't mind. (Or we can add an extra commit with necessary
attributions).

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

Re: [BUG] org-texinfo-export-to-info docstring describes a non-existing optional argument

[Ihor Radchenko]

Niall Dooley  writes:

>> It would help if you provided more details. Ideally, steps to reproduce
>> the problem. See https://orgmode.org/manual/Feedback.html#Feedback
>
> I dug a little deeper. `org-tex-info-export-to-info' calls
> `org-texinfo-compile' which in turn calls `org-compile-file'.  In this
> function, there is a comment stating "Check for process failure.  Output file
> is expected to be located in the same directory as SOURCE." which seems to
> confirm my suspicions that the output .info file is expected to be in the same
> directory as the source .texinfo file.  Doing that however, I still get the
> same process "error" as before and the .info file produced in the parent
> directory.

Which does not help to diagnose the problem, unfortunately.
May you try to reproduce starting from emacs -Q or make repro? See
https://orgmode.org/manual/Feedback.html#Feedback

Essentially, we need to know enough information to see the problem on
our side and understand what the problem is.

> Whilst reading `org-compile-file' I noted the following formatted string
> explains an error I noted in the process error I reported earlier.
>
> "File %S wasn't produced%s"
>
> That is this formatted string should be:
>
> "File %S wasn't produced.  %s"
>
> to avoid the two strings being concatenated together and no punctuation
> separating them.

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

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

Re: Modifying the parse tree

[Ihor Radchenko]

bvchg...@mail.com writes:

>> But be aware
>> that interpreted tree and the original text do not have exact 1-to-1
>> equivalence. Some whitespace might be lost.
>
> Only whitespace? I can live with that.

I know for sure about whitespace. We have some tests for interpreter,
but this has never been tested thoughtfully for the use cases like yours.
Should be mostly fine though, except some edge cases that you can report
as bugs. The original aim of `org-element-interpret-data' is creating
equivalence between the parse tree and the buffer text.

>> > "org-element-headline-interpreter: Wrong type argument: wholenump, nil"
>>
>> Which implies that you added invalid headline element to the tree.
>
> Hmm. Does
> headline (:title hello :todo-keyword TODO :todo-type todo)
> look valid to you as a minimal TODO-type headline? Created via:
>
>   (let ((todo (org-element-create 'headline)))
> (org-element-put-property todo :title todo-title)
> (org-element-put-property todo :todo-keyword "TODO")
> (org-element-put-property todo :todo-type "todo"))

Yes, it is invalid.  You must always have :level.
You might try https://github.com/ndwarshuis/org-ml, though I plan some
breaking changes affecting org-ml soon.

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

Re: Modifying the parse tree

[bvchgvbt]

"Ihor Radchenko" wrote:
> bvchg...@mail.com writes:

> Parse tree is not kept in sync with the original buffer when you
> retrieve it by `org-element-parse-buffer'.

Okay, thanks. I thought that might be the case, but couldn't be sure.

> We generally do not currently
> have a way to modify Org buffer text from AST.
>
> The only way to write the parse tree back is
> replacing it with the output `org-element-interpret-data'.

Okay, fair enough. Thanks for the info.

> But be aware
> that interpreted tree and the original text do not have exact 1-to-1
> equivalence. Some whitespace might be lost.

Only whitespace? I can live with that.

> > "org-element-headline-interpreter: Wrong type argument: wholenump, nil"
>
> Which implies that you added invalid headline element to the tree.

Hmm. Does
headline (:title hello :todo-keyword TODO :todo-type todo)
look valid to you as a minimal TODO-type headline? Created via:

  (let ((todo (org-element-create 'headline)))
(org-element-put-property todo :title todo-title)
(org-element-put-property todo :todo-keyword "TODO")
(org-element-put-property todo :todo-type "todo"))

Re: [PATCH org-contrib 0/1] Fix org-eldoc functionality

[Ihor Radchenko]

~dalanicolai  writes:

> Eldoc functionality only works after a restricted set of commands (see
> the variable 'eldoc-message-commands'). Because `org-self-insert-
> command', by default, is not in that list, eldoc functionality works
> poorly in org-mode (it does not work when typing, only when navigating).
> This patch fixes it for when using org-eldoc.el.

Applied, onto master.
https://git.sr.ht/~bzg/org-contrib/commit/aed67d095de23bc45446777f7b8fb30b8e5c0c51

Do note that we only provide minimal maintenance for org-contrib.
Packages from org-contrib are looking for new proper maintainers.
See https://orgmode.org/worg/org-orphanage.html

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

Re: How to send patch for org-contrib?

[Ihor Radchenko]

dalanicolai  writes:

> I have just created a patch for org-eldoc.el in org-contrib.
> I tried to send it using the 'Prepare a patchset' functionality on
> sourcehut which
> requires me to enter some email-address for where to send it to.
> As I have no idea where to send it, I simply filled in the address of this
> mailing list.
> However, I do not see the message appear in my inbox.
>
> So, I am wondering, how should I send a patch for org-contrib?

You patch did reach the Org ML:
https://list.orgmode.org/168500905821.7612.716094690080728324...@git.sr.ht/T/#t

It is also likely listed somewhere in your sr.ht account, like in
activity feed (mine is https://sr.ht/~yantar92/). In future, you can add
your personal email to CC when sending a patchset.

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

Re: Modifying the parse tree

[Ihor Radchenko]

bvchg...@mail.com writes:

> After calling, say, org-element-adopt-elements, do I (or rather my code)
> have to do anything to make the modified tree apply to the Org document/
> buffer that the tree came from?

Yes. Parse tree is not kept in sync with the original buffer when you
retrieve it by `org-element-parse-buffer'. We generally do not currently
have a way to modify Org buffer text from AST.

The only way to write the parse tree back is
replacing it with the output `org-element-interpret-data'. But be aware
that interpreted tree and the original text do not have exact 1-to-1
equivalence. Some whitespace might be lost.

> I can see that the tree is modified but it isn't reflected in the buffer
> it came from, and furthermore calling org-element-interpret-data on the
> modified tree at that stage results in an error:
>
> "org-element-headline-interpreter: Wrong type argument: wholenump, nil"

Which implies that you added invalid headline element to the tree.

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

Re: How to convert an HTML export bloc to a normal Org Babel output ?

[Ihor Radchenko]

copropriete27ruemo...@gmail.com writes:

> [ For some reason, an answer posted yesterday seems to have been lost. 
> Rewriting/reposting... ]

You did not CC Org mailing list.

> Nice answer ! I suppose that this is more a misdesign than a bug (limited 
> goals of Dyalog,that emacs-jupyter cannot alleviate).
>
> Your suggestion worked. But now, I have to pass to my `:post` function 
> various arguments that a "normal" source block handler should have done. Is 
> there a way for the `post` function to access the (say..) `:results`, 
> `:file`, etc... arguments of the source block ?

`org-babel-current-src-block-location' holds the location of the current
src block being executed. You can use it to determine header arguments
of your src block.

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

Modifying the parse tree

[bvchgvbt]

After calling, say, org-element-adopt-elements, do I (or rather my code)
have to do anything to make the modified tree apply to the Org document/
buffer that the tree came from?

I can see that the tree is modified but it isn't reflected in the buffer
it came from, and furthermore calling org-element-interpret-data on the
modified tree at that stage results in an error:

"org-element-headline-interpreter: Wrong type argument: wholenump, nil"

so I'm guessing that, actually, something is wrong with the tree at that
point, which may explain why no changes are available in the buffer if
they should just show up automagically.

How to send patch for org-contrib?

[dalanicolai]

Hello,

I have just created a patch for org-eldoc.el in org-contrib.
I tried to send it using the 'Prepare a patchset' functionality on
sourcehut which
requires me to enter some email-address for where to send it to.
As I have no idea where to send it, I simply filled in the address of this
mailing list.
However, I do not see the message appear in my inbox.

So, I am wondering, how should I send a patch for org-contrib?

Thank you

[PATCH org-contrib 0/1] Fix org-eldoc functionality

[~dalanicolai]

Eldoc functionality only works after a restricted set of commands (see
the variable 'eldoc-message-commands'). Because `org-self-insert-
command', by default, is not in that list, eldoc functionality works
poorly in org-mode (it does not work when typing, only when navigating).
This patch fixes it for when using org-eldoc.el.

Daniel Nicolai (1):
  Fix org-eldoc: add 'org-self-insert-command' to
'eldoc-message-commands'

 lisp/org-eldoc.el | 2 ++
 1 file changed, 2 insertions(+)

-- 
2.38.4

[PATCH org-contrib 1/1] Fix org-eldoc: add 'org-self-insert-command' to 'eldoc-message-commands'

[~dalanicolai]

From: Daniel Nicolai 

---
 lisp/org-eldoc.el | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lisp/org-eldoc.el b/lisp/org-eldoc.el
index 5b4f66d..7137c46 100644
--- a/lisp/org-eldoc.el
+++ b/lisp/org-eldoc.el
@@ -54,6 +54,8 @@
   :group 'org-eldoc
   :type 'string)
 
+(eldoc-add-command 'org-self-insert-command)
+
 (defun org-eldoc-get-breadcrumb ()
   "Return breadcrumb if on a headline or nil."
   (let ((case-fold-search t) cur)
-- 
2.38.4

Re: How to convert an HTML export bloc to a normal Org Babel output ?

[copropriete27ruemoret]

[ For some reason, an answer posted yesterday seems to have been lost. 
Rewriting/reposting... ]

Nice answer ! I suppose that this is more a misdesign than a bug (limited goals 
of Dyalog,that emacs-jupyter cannot alleviate).

Your suggestion worked. But now, I have to pass to my `:post` function various 
arguments that a "normal" source block handler should have done. Is there a way 
for the `post` function to access the (say..) `:results`, `:file`, etc... 
arguments of the source block ?

Sincerely,

--
Emmanuel Charpentier

[SOLVED] Re: [QUESTION] Hope to improve the `org-set-font-lock-defaults` performance by lazy and limit to current visible area

[Christopher M. Miles]

Ihor Radchenko  writes:

> "Christopher M. Miles"  writes:
>
>> I'm the developer of Org mode package "org-link-beautify"
>> https://repo.or.cz/org-link-beautify.git . The package main theory
>> is to use org-link-parameters `:activate-func` to do link file preview
>> with generating thumbnail images or file content etc.
>>
>> But I found it's slow one some big Org file and slow on small Org file
>> when previewing has a lot.
>> ...
>> I can see the `org-mode` invoked `org-set-font-lock-defaults` soon when
>> `org-mode` enabled. I hope the link `:activate-func` function can be
>> called only on link elements which is VISIBLE (means unfolded subtrees
>> or similar). So org-mode don't need to render all buffer links at
>> beginning soon. Instead render them as needed as unfolded. (Maybe I read
>> source code without fully understand the code. If so, correct me,
>> thanks.)
>
> Emacs fontification, by default, only requests fontification of the text
> visible on screen. That's what LIMIT argument to `font-lock-keywords'
> MATCHER function is for. Org mode obeys LIMIT.
>
> If you are seeing fontification being requested for invisible part of
> buffer or parts of buffer outside screen, it is likely caused by some
> third-party package forcing the fontification.
>
> As usual, try emacs -Q + minimal set of loaded packages and see if you
> can reproduce the problem.

Ihor, Thanks for answering. Learned new stuff.

-- 

[ stardiviner ]
I try to make every word tell the meaning that I want to express without 
misunderstanding.

Blog: https://stardiviner.github.io/
IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3


signature.asc
Description: PGP signature

Re: [QUESTION] Hope to improve the `org-set-font-lock-defaults` performance by lazy and limit to current visible area

[Ihor Radchenko]

"Christopher M. Miles"  writes:

> I'm the developer of Org mode package "org-link-beautify"
> https://repo.or.cz/org-link-beautify.git . The package main theory
> is to use org-link-parameters `:activate-func` to do link file preview
> with generating thumbnail images or file content etc.
>
> But I found it's slow one some big Org file and slow on small Org file
> when previewing has a lot.
> ...
> I can see the `org-mode` invoked `org-set-font-lock-defaults` soon when
> `org-mode` enabled. I hope the link `:activate-func` function can be
> called only on link elements which is VISIBLE (means unfolded subtrees
> or similar). So org-mode don't need to render all buffer links at
> beginning soon. Instead render them as needed as unfolded. (Maybe I read
> source code without fully understand the code. If so, correct me,
> thanks.)

Emacs fontification, by default, only requests fontification of the text
visible on screen. That's what LIMIT argument to `font-lock-keywords'
MATCHER function is for. Org mode obeys LIMIT.

If you are seeing fontification being requested for invisible part of
buffer or parts of buffer outside screen, it is likely caused by some
third-party package forcing the fontification.

As usual, try emacs -Q + minimal set of loaded packages and see if you
can reproduce the problem.

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