[tip] Insert arbitrary LaTeX code at the beginning of any float environment

[Juan Manuel Macías]

Hi all,

If we want to introduce arbitrary LaTeX code at the very beginning of a
float environment, apart from the usual tricks of putting the code in
:caption or :placement, this solution I describe here is more from the
LaTeX side. I thik its advantages are more control and consistency from
the point of view of LaTeX, and the possibility of introducing code of a
certain complexity.

Well, you have to write some LaTeX code for the preamble, but it's
really not much :)

We have to define a global command \myenvcode{} (if we
want to add the code to all document floats environments), and also a
'Myenvcode' environment, with the same argument. The etoolbox LaTeX
package provides a number of hooks: \AtBeginEnvironment,
\AtEndEnvironment, etc., but if we want our arbitrary code to be at the
very beginning of the environment, it's safer to use the \@floatboxreset
hook. So, the code that we would have to add to our preamble would be (I
prefer to define the command and environment using the xparse syntax):

#+NAME: preamble
#+begin_src latex :exports none
  \usepackage{xparse}

  \makeatletter
  \def\my@envcode{}
  \NewDocumentCommand{\myenvcode}{+m}{%
\def\my@envcode{#1}}
  \g@addto@macro\@floatboxreset{\my@envcode}
  \makeatother

  \NewDocumentEnvironment{Myenvcode}{+m}{%
\IfNoValueF{#1}{\myenvcode{#1}}}
  {\par}
#+end_src

#+begin_src latex :noweb yes :results raw
,#+LaTeX_HEADER: <>
#+end_src

And here a few examples:

#+ATTR_LaTeX: :options {\centering\fbox{Code before a image}\par\vspace{1ex}}
#+begin_Myenvcode
#+CAPTION: This is a image
#+ATTR_LaTeX: :width .5\linewidth :placement [h]
[[file:example-image-a.jpg]]
#+end_Myenvcode

#+ATTR_LaTeX: :options {\captionsetup{font={color=red}}}
#+begin_Myenvcode
#+CAPTION: This is a image
#+ATTR_LaTeX: :width .5\linewidth :placement [h]
[[file:example-image-b.jpg]]
#+end_Myenvcode

#+latex: \myenvcode{{\centering\fbox{Code before a table}\par\vspace{1ex}}}
#+CAPTION: This is a table
#+ATTR_LaTeX: :placement [h] :booktabs t
| a | b | c | d | f |
|---+---+---+---+---|
| 1 | 2 | 3 | 4 | 5 |

#+latex: \myenvcode{}

Best regards,

Juan Manuel 

Re: [PATCH] org-attach: Attach current Gnus article parts

[Juan Manuel Macías]

Ihor Radchenko writes:

> I think that a good example implementation is from notmuch.el. It does
> not use anything specific to notmuch, just built-in mm-*.el from gnus:

Thanks for the tip, Ihor. I'll take a look at it, and see if I can
sketch something usable...

Best regards,

Juan Manuel 

org-agenda-clock-report-header

[Colin Baxter]

Hello,

Could more information perhaps be added to the doc string of
"org-agenda-clock-report-header"? And an example would be very
useful. As it stands at present, I haven't a clue as to what the
variable does and why it might be useful.

Thank you.

Colin Baxter.

how to best correct exams (code matlab) using org mode (and tables)

[Uwe Brauer]

Hi 

I came around 
https://kitchingroup.cheme.cmu.edu/blog/2013/10/23/Writing-exams-in-org-mode/

Which is a bit outdated.

My use case are to correct of matlab files, so usually I have a single org file 
with a table and insert the results. 

However what I missing is that my comments, and observations are difficult to 
track.

I am now  experimenting with org-remark putting the remarks and marks in the 
property sections of headers and use than

columnview 
like
#+begin_src 
#+BEGIN: columnview :maxlevel 2  :skip-empty-rows t :indent nil :hlines 2  
:format "%5TODO(Status) %5Ap(Name) %5com(Comment) %5Ej1(Ej1/20) %5Ej2(Ej2/25) 
%5Ej3(Ej3/55) %5Res(Result)" 
#+END:
#+end_src

What do others use?

Regards

Uwe Brauer 

-- 
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 

Re: Export LaTeX command inside figure environment

[Max Nikulin]

On 08/05/2022 13:06, Thomas S. Dye wrote:


It would be better to have a LaTeX attribute, say :commands, that places 
commands within \begin{figure} ... \end{figure}.


Look at the code of `org-latex--inline-image' and variants of markup it 
may generate. There are too may places where :commands may be inserted 
to add an attribute for each place, e.g. before or after 
\includegraphics. It may be better to allow users to define a function 
that either generates markup or delegates it to the default function. I 
am unsure concerning convenient API that should be provided to generate 
a label, to get caption that may be specified as an attribute or as 
#+caption:, etc. There is a quite similar problem with source blocks 
(another thread). 10 arguments functions emerged during attempt split 
into maintainable pieces a huge function handling all cases.

Re: Bug: Percentage in caption (even escaped) does not work in LaTeX export

[Timothy]

Hi All,

This should be finally fixed in
 when it’s merged.

All the best,
Timothy

Re: Export LaTeX command inside figure environment

[Juan Manuel Macías]

Thomas S. Dye writes:

> It would be better to have a LaTeX attribute, say :commands, that
> places commands within \begin{figure} ... \end{figure}.

This is a possible solution from the LaTeX side, which would avoid
having to modify the Org code and can also be used to introduce more
complex arbitrary code into the figure environment. It consists of
defining a variable (for arbitrary code) and redefining the figure
environment to include that variable. Something like this:

#+NAME: preamble
#+begin_src latex :exports none
\usepackage{graphicx,xparse}

\def\myfigcode#1{#1}

\let\svfigure\figure
\let\endsvfigure\endfigure

\DeclareDocumentEnvironment{figure}{o}{%
\IfNoValueTF{#1}{%
  \begin{svfigure}}
  {\begin{svfigure}[#1]}
\myfigcode%
}
{\end{svfigure}}
#+end_src

#+begin_src latex :noweb yes :results raw
,#+LaTeX_HEADER: <>
#+end_src

Here I use the dummy images from the graphicx package. Of course, then
it is necessary to apply a zero value to the variable again, or enclose
all in a \begingroup...\endgroup. It's a bit tricky and I haven't tried
it too much:

@@latex:\begingroup\def\myfigcode{{\centering\fbox{\textbf{Hello 
world!!!}}\par\vspace{5ex}}}@@

#+caption: This is a caption
#+ATTR_LaTeX: :placement [h] :width .5\linewidth
[[file:example-image-a.jpg]]

@@latex:\endgroup@@

#+caption: This is a caption
#+ATTR_LaTeX: :placement [h] :width .5\linewidth
[[file:example-image-b.jpg]]

A screenshot:

https://i.imgur.com/8JIU6nX.png

Best regards,

Juan Manuel 

Re: [PATCH] (v2) New LaTeX code export option: engraved

[Timothy]

Hi Daniel & co.,

I have a new set of patches (attached), which make use of a major new feature in
engrave-faces v0.3: engraved themes.

Now, the theme used for source blocks can be set by the document keyword
`#+latex_engraved_theme: THEME-NAME'. Furthermore, the theme can be customised 
on
a per-code-block basis with `#+attr_latex: :engraved-theme THEME-NAME'.

If you try this out, make sure you have the most recent commit of engrave-faces
(531ea687e, soon to be released in v0.3.1).

I’ve also fixed the “Bug: Percentage in caption (even escaped) does not work in
LaTeX export” that Max raised
().

Daniel Fleischer  writes:

> Very nice set of patches, it looks good.

Glad to hear you’ve been able to have a look over the patches. With the feedback
I’ve received here so far, if no issues come up in the next few days I’m
inclined to merge this, add documentation, and see what feedback pops up.

> I must admit it’s not clear how to customize faces since engrave is a bridge
> between major modes choices and latex but maybe show one or two examples (say
> elisp and python) of how to change/override some face.

Sure. The result should be visually identical to what you’d see in elisp/python
buffer, but possibly with a different theme.

Say you wanted to use a tweaked version of the default theme, this could be
accomplished like so:
┌
│ (setq default2 (alist-get 'default engrave-faces-themes))
│ ;; Make comments hot pink
│ (plist-put (alist-get 'font-lock-comment-face default2) :foreground "#ff69b4")
│ ;; Any other customisations...
│ (add-to-list 'engrave-faces-themes (cons 'default2 default2))
└

Then in the Org file you can use the “default2” engraved theme with
`#+latex_engraved_theme: default2'.

Let me know if there are any other examples you’d like to see.

> I think next we should apply these patches and be open to feedback
> about source code latex export using these new changes. I also wish
> there was a bit more documentation, but we can add more with time.
> Maybe some feedback from Nicolas G.?

 see my earlier comment on merging.

All the best,
Timothy
>From 18adbd0e1226cf3307090861e09e92bfa9cdfbf1 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Sun, 21 Nov 2021 14:35:34 +0800
Subject: [PATCH 01/10] ox-latex: Refactor `org-latex-src-block'

* lisp/ox-latex.el (org-latex-src-block): Extract the per-format logic
from `org-latex-src-block' into new dedicated functions:
+ `org-latex-src-block--verbatim'
+ `org-latex-src-block--custom'
+ `org-latex-src-block--minted'
+ `org-latex-src-block--listings'
This makes `org-latex-src-block' much less monolithic, taking it from
175 lines to 30, and I find also makes it easier to understand.
---
 lisp/ox-latex.el | 339 ++-
 1 file changed, 185 insertions(+), 154 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 841ad48bc..c2f728a1c 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -2997,164 +2997,195 @@ (defun org-latex-src-block (src-block _contents info)
 	   (float (plist-get attributes :float))
 	   (listings (plist-get info :latex-listings)))
   (cond
-   ;; Case 1.  No source fontification.
((or (not lang) (not listings))
-	(let ((caption-str (org-latex--caption/label-string src-block info))
-  (verbatim (format "\\begin{verbatim}\n%s\\end{verbatim}"
-(org-export-format-code-default src-block info
-  (cond ((string= "multicolumn" float)
- (format "\\begin{figure*}[%s]\n%s%s\n%s\\end{figure*}"
- (plist-get info :latex-default-figure-position)
- (if caption-above-p caption-str "")
- verbatim
- (if caption-above-p "" caption-str)))
-(caption (concat
-  (if caption-above-p caption-str "")
-  verbatim
-  (if caption-above-p "" (concat "\n" caption-str
-(t verbatim
-   ;; Case 2.  Custom environment.
+(org-latex-src-block--verbatim src-block info lang caption caption-above-p label
+   num-start retain-labels attributes float))
(custom-env
-	(let ((caption-str (org-latex--caption/label-string src-block info))
-  (formatted-src (org-export-format-code-default src-block info)))
-  (if (string-match-p "\\`[a-zA-Z0-9]+\\'" custom-env)
-	  (format "\\begin{%s}\n%s\\end{%s}\n"
-		  custom-env
-		  (concat (and caption-above-p caption-str)
-			  formatted-src
-			  (and (not caption-above-p) caption-str))
-		  custom-env)
-	(format-spec custom-env
-			 `((?s . ,formatted-src)
-			   (?c . ,caption)
-			   (?f . ,float)
-			   (?l . ,(org-latex--label src-block info))
-			   (?o . ,(or (plist-get attributes 

Re: Concatenate properties

[Ihor Radchenko]

Tyler Grinn  writes:

>
> Could you provide an example of what the value of that variable would be
> if, for instance, I wanted PROP_A and PROP_B to be joined with a single
> space and PROP_C and PROP_D to be concatenated? Or better yet, have the
> default be to join with a single space for any property and have only
> PROP_C and PROP_D concatenated?

Say,

'(("PROP_[CD]" . ""))

or

'(("PROP_[AB]" . "/") ("PROP_[CD]" . "") (".+" . "∿"))

Best,
Ihor

Re: Recent changes in org-fold regarding emphasize visibility

[Daniel Fleischer]

Ihor Radchenko  writes:

> I have made changes in invisible edit handling.
> Now, when using 'text-properties style,
> org-fold-check-before-invisible-edits ignores folded links just like it
> does with overlays style.
>
> The commit is 2e4ed52b1.

Looks good; thank you Ihor!


-- 

Daniel Fleischer

Re: [PATCH] org-attach: Attach current Gnus article parts

[Ihor Radchenko]

Juan Manuel Macías  writes:

> What I don't quite understand is why it wouldn't be appropriate to add a
> new entry with the new feature to the org-attach menu.

Thinking about it more, new feature in org-attach menu should actually
be ok.

My initial logic was that we cannot easily select attach method for
entries in the attach menu. However, anything other than 'cp method is
meaningless when saving article attachments.

> Well, as I said, I have chosen Gnus because it is part of GNU Emacs. In
> any case, if anyone wants to write a patch with a more general solution,
> I'd encourage them. I think that would be an interesting feature for
> org-attach. I only use Gnus and unfortunately I'm not familiar with
> other mail reader libraries (I could try to do something more "agnostic"
> from message-mode, when I have some more time...).

I think that a good example implementation is from notmuch.el. It does
not use anything specific to notmuch, just built-in mm-*.el from gnus:

(defun notmuch-save-attachments (mm-handle  queryp)
  (notmuch-foreach-mime-part
   (lambda (p)
 (let ((disposition (mm-handle-disposition p)))
   (and (listp disposition)
(or (equal (car disposition) "attachment")
(and (equal (car disposition) "inline")
 (assq 'filename disposition)))
(or (not queryp)
(y-or-n-p
 (concat "Save '" (cdr (assq 'filename disposition)) "' ")))
(mm-save-part p
   mm-handle))

(defun notmuch-foreach-mime-part (function mm-handle)
  (cond ((stringp (car mm-handle))
 (dolist (part (cdr mm-handle))
   (notmuch-foreach-mime-part function part)))
((bufferp (car mm-handle))
 (funcall function mm-handle))
(t (dolist (part mm-handle)
 (notmuch-foreach-mime-part function part)

Best,
Ihor

Re: Concatenate properties

[Tyler Grinn]

Ihor Radchenko  writes:

> Tyler Grinn  writes:
>
>> John Kitchin  writes:
>>
>>> I like the variable idea. I would make it a concatenation string for
>>> joining. That way “” would concatenate the way Tyler wants, “ “ would
>>> preserve current behavior, and “,” could lead to a comma separated
>>> list for example. Other things like “\n” might lead to a column, etc. 
>>
>> I'm not a huge fan of the variable idea because it would make it
>> impossible to include both behaviors in a single file, whereas extending
>> the syntax maintains any existing properties that used '+'.
>
> I think I need to elaborate what I meant by "similar to
> org-use-property-inheritance".
>
> org-use-property-inheritance docstring:
>
 When nil, only the properties directly given in the current entry
 count. When t, every property is inherited. The value may also be a
 list of properties that should have inheritance, or a regular
 expression matching properties that should be inherited.
>
> Similarly, concatenation of PROPERTY+ can be controlled on per-property
> basis.
>
> Best,
> Ihor

Could you provide an example of what the value of that variable would be
if, for instance, I wanted PROP_A and PROP_B to be joined with a single
space and PROP_C and PROP_D to be concatenated? Or better yet, have the
default be to join with a single space for any property and have only
PROP_C and PROP_D concatenated?

Re: Problem with org-babel and geiser

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> P.S.
>
> We should add 'testing/lisp/test-ob-scheme.el' or it will break again
> sooner or later.  Can we make the Org test suite depend on Geiser and
> Guile?  Given that Org uses Geiser out of the box, I think we should.
> What do you think?

Sounds reasonable. Patches are welcome!

Best,
Ihor

Re: org-agenda-filter-by-tag doco

[Phil Hudson]

Fair enough. I follow your reasoning and it seems sound. Please close.

On Sun, 8 May 2022 at 14:07, Ihor Radchenko  wrote:
>
> Phil Hudson  writes:
>
> > I'd like to expand the docstring of command `org-agenda-filter-by-tag`
> > to document the Elisp equivalent of interactive prefix arguments. By
> > trial and error and guesswork I determined that I could emulate `C-u
> > C-u` by passing `'(16)` as the second argument
> > (`strip-or-accumulate`). I'd like to add text explaining this,
> > generalized to all prefix combinations.
>
> I do not think that it is a good idea. There is not much point
> explaining basic Emacs concepts discussed in Emacs/Elisp manual in every
> docstring of functions making use of universal arguments.
>
> Note that C-u gets automatically highlighted when you view the function
> docstring. Clicking on it brings you to the docstring for universal
> argument, which, in turn, also contains a link to the manual page.
>
> I think it is good enough.
>
> Best,
> Ihor

Re: [PATCH] org-attach: Attach current Gnus article parts

[Juan Manuel Macías]

Ihor Radchenko writes:

> I think that supporting only Gnus is too specific. Not all the people
> use Gnus as mail reader. And the extra menu option you propose will only
> eat up space for people not using Gnus.
>
> I'd prefer a more generic approach working in any kind of email reader,
> be it rmail, gnus, mu4e, notmuch, or wunderlust. The approach can
> probably making use of message-mode or MML libraries from Emacs core.

Well, as I said, I have chosen Gnus because it is part of GNU Emacs. In
any case, if anyone wants to write a patch with a more general solution,
I'd encourage them. I think that would be an interesting feature for
org-attach. I only use Gnus and unfortunately I'm not familiar with
other mail reader libraries (I could try to do something more "agnostic"
from message-mode, when I have some more time...).

What I don't quite understand is why it wouldn't be appropriate to add a
new entry with the new feature to the org-attach menu.

Best regards,

Juan Manuel 

Re: org-agenda-filter-by-tag doco

[Ihor Radchenko]

Phil Hudson  writes:

> I'd like to expand the docstring of command `org-agenda-filter-by-tag`
> to document the Elisp equivalent of interactive prefix arguments. By
> trial and error and guesswork I determined that I could emulate `C-u
> C-u` by passing `'(16)` as the second argument
> (`strip-or-accumulate`). I'd like to add text explaining this,
> generalized to all prefix combinations.

I do not think that it is a good idea. There is not much point
explaining basic Emacs concepts discussed in Emacs/Elisp manual in every
docstring of functions making use of universal arguments.

Note that C-u gets automatically highlighted when you view the function
docstring. Clicking on it brings you to the docstring for universal
argument, which, in turn, also contains a link to the manual page.

I think it is good enough.

Best,
Ihor

Re: [PATCH] org-attach: Attach current Gnus article parts

[Ihor Radchenko]

Juan Manuel Macías  writes:

> In the attached patch I add a new command for org-attach: save *all*
> attachments from the current Gnus article to the current org-attach-dir.
>
> (Sorry for repeating the word "attach" so much :-))
>
> NB:
>
> 1. If no Gnus article is open, it returns an error message.
>
> 2. I've only tested it on Emacs 28. I don't know if it can cause any
> problems on earlier Emacs/Gnus versions.
>
> 3. Although there are several alternatives to Gnus, I have chosen Gnus
> specifically because it is part of GNU Emacs.
>
> 4. I think an option could be added to save only certain types of files
> (pdf, png, jpg, docx, etc.).

I think that supporting only Gnus is too specific. Not all the people
use Gnus as mail reader. And the extra menu option you propose will only
eat up space for people not using Gnus.

I'd prefer a more generic approach working in any kind of email reader,
be it rmail, gnus, mu4e, notmuch, or wunderlust. The approach can
probably making use of message-mode or MML libraries from Emacs core.

Also, I do not like adding yet another menu option even if it is working
for other mail readers. Instead, it would be more consistent to follow
what we do for dired. See interactive spec in org-attach-attach.

Best,
Ihor

Re: Concatenate properties

[Ihor Radchenko]

Tyler Grinn  writes:

> John Kitchin  writes:
>
>> I like the variable idea. I would make it a concatenation string for
>> joining. That way “” would concatenate the way Tyler wants, “ “ would
>> preserve current behavior, and “,” could lead to a comma separated
>> list for example. Other things like “\n” might lead to a column, etc. 
>
> I'm not a huge fan of the variable idea because it would make it
> impossible to include both behaviors in a single file, whereas extending
> the syntax maintains any existing properties that used '+'.

I think I need to elaborate what I meant by "similar to
org-use-property-inheritance".

org-use-property-inheritance docstring:

>>> When nil, only the properties directly given in the current entry
>>> count. When t, every property is inherited. The value may also be a
>>> list of properties that should have inheritance, or a regular
>>> expression matching properties that should be inherited.

Similarly, concatenation of PROPERTY+ can be controlled on per-property
basis.

Best,
Ihor

Re: [BUG] org-complex-heading-regexp should consider COMMENT keywords [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]

[Ihor Radchenko]

Ignacio Casso  writes:

>> I have added TINYCHANGE cookie as you don't appear to have FSF copyright
>
> I should have it, I did the paperwork for commit 2b564f504b in
> Emacs. Maybe I used a different email? Or maybe the problem is that now
> that I see it I don't have my full name configured in git. It's Ignacio
> Casso, and I appear in the commit author field as just Ignacio. I have
> fixed it now for future commits.

I see. The problem is that I do not have access to the up-to-date
contributor list. And you are not listed in
https://orgmode.org/worg/contributors.html

Bastien, could you kindly check if Ignacio Casso
 has FSF assignment and update contributors
page accordingly?

Best,
Ihor

Re: [BUG] org-complex-heading-regexp should consider COMMENT keywords [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]

[Ignacio Casso]

> Thanks!

Thank you too!

> I have added TINYCHANGE cookie as you don't appear to have FSF copyright

I should have it, I did the paperwork for commit 2b564f504b in
Emacs. Maybe I used a different email? Or maybe the problem is that now
that I see it I don't have my full name configured in git. It's Ignacio
Casso, and I appear in the commit author field as just Ignacio. I have
fixed it now for future commits.

Re: [BUG] org-complex-heading-regexp should consider COMMENT keywords [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]

[Ihor Radchenko]

Ignacio Casso  writes:

> Done. I attach the patch:

Thanks!

Applied onto main as a3dd2 with minor amendments.
I have added TINYCHANGE cookie as you don't appear to have FSF copyright
assignment and capitalised "match" in the commit summary.

Best,
Ihor

> From 646f2a792dc5c6e6fa3933eb1d06420c86cd53c3 Mon Sep 17 00:00:00 2001
> From: Ignacio 
> Date: Fri, 6 May 2022 13:51:14 +0200
> Subject: [PATCH] lisp/org.el: match COMMENT in
>  `org-complex-heading-regexp-format'
>
> * lisp/org.el (org-set-regexps-and-options): Change
> `org-complex-heading-regexp-format' initialization so that the regexp
> it produces also matches a headline if it is commented.
> ---
>  lisp/org.el | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/lisp/org.el b/lisp/org.el
> index 1d5fc3903..cab59b87c 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -3846,7 +3846,8 @@ expected to be bound to nil when matching against this 
> regexp.")
>"Printf format to make regexp to match an exact headline.
>  This regexp will match the headline of any node which has the
>  exact headline text that is put into the format, but may have any
> -TODO state, priority and tags.")
> +TODO state, priority, tags, statistics cookies (at the beginning
> +or end of the headline title), or COMMENT keyword.")
>  
>  (defvar-local org-todo-line-tags-regexp nil
>"Matches a headline and puts TODO state into group 2 if present.
> @@ -4213,6 +4214,8 @@ related expressions."
> "\\(?: +" org-todo-regexp "\\)?"
> "\\(?: +\\(\\[#.\\]\\)\\)?"
> "\\(?: +"
> +  ;; Headline might be commented
> +  "\\(?:" org-comment-string " +\\)?"
> ;; Stats cookies can be stuck to body.
> "\\(?:\\[[0-9%%/]+\\] *\\)*"
> "\\(%s\\)"
> -- 
> 2.25.1
>

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong 
University, Xi'an, China
Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg

Re: [PATCH] update ob-scheme to latest changes in geiser package

[Ihor Radchenko]

Tim Van den Langenbergh  writes:

> I have updated the patch and enclosed it, feel free to drop a line if you
> notice anything else obviously missing.

Thanks!
Applied onto main as 06d08e6f3.

Best,
Ihor

Re: Recent changes in org-fold regarding emphasize visibility

[Ihor Radchenko]

Daniel Fleischer  writes:

>> The question is what should be the logical behaviour of Org when editing
>> text inside or at the border of these hidden text types? How should we
>> interpret the values of org-catch-invisible-edits (nil error show
>> show-and-error smart)?
>
> Not sure we need to reinterpret the settings; roughly they cover the
> different options of what to do when you edit a hidden text: edit
> anyways, throw an error, unfold but do nothing, unfold and do what you
> wanted to do and the only thing I don't have an intuition about is the
> smart option.
>
> BTW, there are no issues when the folding core style is "overlays". So
> why not follow what happens in that case, even formalize it into tests?

Reasonable.
I have made changes in invisible edit handling.
Now, when using 'text-properties style,
org-fold-check-before-invisible-edits ignores folded links just like it
does with overlays style.

The commit is 2e4ed52b1.

Let me know if you are getting the expected behaviour now.

Best,
Ihor

Re: org-fold problems

[Ihor Radchenko]

Eric S Fraga  writes:

> On a related matter, I typically use vc-ediff for comparing the current
> working copy of a file and the last committed version.  This used to
> expand the file completely (assuming I'm remembering correctly) but now
> (some?) drawers are not opened so if there are differences inside a
> drawer, I cannot see them via ediff.  Does this make sense?  If so, is
> there something I should customise to have *everything* opened when
> using ediff?

I suspect the same issue. If you try
M-: (setq org-fold-core-first-unfold-functions nil)
before doing ediff and it helps, then I will know the culprit.

Note that I tried to run ediff-buffers on Org buffers and everything
remains folded with stable Org 9.5 as well.

Best,
Ihor

Re: org-fold documentation

[Ihor Radchenko]

Max Nikulin  writes:

> Will it help to create files like org-fwd.el with function declarations 
> to allow other packages (even from org-mode) to use "(require 
> 'org-fwd.el)" instead of adding a lot of `declare-function' forms that 
> must be kept in sync with function definitions?

It is an interesting idea, though I would not put a priority on such a
change. Also, properly fixing circular dependencies will be even better.
The current situation highlights the inconsistencies of our current code
design.

Best,
Ihor

Re: [org-contrib] Take over maintaining of org-contacts.el

[Ihor Radchenko]

"Christopher M. Miles"  writes:

> Yes, please update to new place: https://repo.or.cz/org-contacts.git.
> Thanks for checking this up, I have not realized missed migration of 
> org-contacts repo.

Done in 15b03d5.

Best,
Ihor

Re: [PATCH] style/worg.css: Display TOC on top

[Ihor Radchenko]

Ihor Radchenko  writes:

>
> The attached patch fixes the issue.

Applied as 8d7d0c77

Re: [PATCH] Add unmaintained warnings for applicable blogging tools

[Ihor Radchenko]

thecashewtrader  writes:

> ---
>  org-blog-wiki.org | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)

Thanks!
Applied as ab6ab6d9.

Best,
Ihor

Re: [PATCH] ob-plantuml: Allow setting PlantUML args for jar file

[Ihor Radchenko]

Max Nikulin  writes:

> To wrap up, I suggest (and I do not insist) to drop 
> "-Djava.awt.headless=true" since "-headless" is anyway added in jar 
> mode. Those who desperately need namely "-Djava.awt.headless=true" (for 
> some unknown to me reason) may customize :java header argument. I do not 
> see any real problem with the change, just a minor improvement.

After further consideration, I decided to follow your suggestion.
If we insist of -Djava.awt.headless=true in org-plantuml-exec-mode='jar
but not in 'plantuml, we may run into inconsistency between users using
the two alternatives.

Applied onto main as b5f0efc04.

Best,
Ihor

Re: How to export to markdown programmatically without the table of contents?

[Marcin Borkowski]

On 2022-05-07, at 10:16, Max Nikulin  wrote:

> On 02/05/2022 23:52, Marcin Borkowski wrote:
>> On 2022-05-01, at 22:01, Berry, Charles wrote:
 On May 1, 2022, at 2:20 AM, Marcin Borkowski wrote:

 I'd like to export a Org-mode formatted string to markdown, but without
 the table of contents.

 (org-export-string-as my-string 'md t '(toc nil))

 didn't work (the ToC was still there).  What am I missing?
>>>
>>> It does seem odd that BODY-ONLY as `t' gives a toc. With latex it does not 
>>> regardless of `:with-toc'.
>>>
>>> : (org-export-string-as my-string 'md t '(:with-toc nil))
>> Thanks!
>> http://mbork.pl/2021-05-02_Org-mode_to_Markdown_via_the_clipboard
>
> The following links posted earlier to this mail list might be
> interesting for you since they are related to "exporting" of org text
> to other applications:
>
> https://github.com/tecosaur/emacs-everywhere
> System-wide popup Emacs windows for quick edits
>
> https://github.com/jkitchin/ox-clip/
> Copy formatted content from org-mode
>
> The latter copies HTML, not markdown though.

Thanks, both look really interesting!

-- 
Marcin Borkowski
http://mbork.pl

Re: #4 Org mode profiling meetup on Sat, May 7

[Ihor Radchenko]

Ihor Radchenko  writes:

> Ihor Radchenko  writes:
>
>> The time will be the same: 9pm SG time (4pm Kyiv; 2pm London; 9am New
>> York). Sat, May 7
>>
>> I will post the link to the meeting one hour before the meeting start.
>
> Meeting link: https://teamjoin.de/Org-dev-profiling-20220507-d708k

Attaching the meeting notes.

Best,
Ihor



2022-05-07-summary.org
Description: Lotus Organizer

Re: Export LaTeX command inside figure environment

[Thomas S. Dye]

Aloha Max,

Max Nikulin  writes:


On 08/05/2022 07:30, Juan Manuel Macías wrote:

Thomas S. Dye writes:


Is there a way to add an arbitrary LaTeX command between
\begin{figure} ... \end{figure} during LaTeX export?  I want 
to end up
with the following snippet, but can't figure out how to slip 
in

\setfloatalignment{b}.  \begin{figure}[htb]
\centering
\includegraphics[width=.9\linewidth]{hilbertcurves.pdf}
\caption[Hilbert curves]{\label{fig:orgparagraph1} Hilbert 
curves of

various degrees \emph{n}.}
\setfloatalignment{b}
\end{figure}
I think the :caption attribute could do the trick (of course 
everything

must be on one line):
#+ATTR_LaTeX: :caption \caption[Hilbert
  curves]{\label{fig:orgparagraph1} Hilbert curves of various 
  degrees

  \emph{n}.}\setfloatalignment{b}


Would it work if \setfloatalignment{b} is added before 
\includegraphics?  From
my point of view, it is still a hack due to abusing the 
:placement attribute,
but it is backend agnostic, so reuses caption for HTML and 
relieves requirement

of single long line:

#+caption[Hilbert curves]: Hilbert curves of various degrees 
\(n\)

#+name: orgparagraph1
#+attr_latex: :placement [b]\setfloatalignment{b}
[[file:hilbertcurves.pdf]]

# Local Variables:
# org-latex-prefer-user-labels: t
# End:

P.S. Math and absence of period are intentional. I never used 
tufte, so unsure
if something besides b is meaningful with \setfloatalignment{b}. 
I dropped "ht"
to make inconsistency apparent and expecting that when figures 
are moved to the

end of document, "ht" should be used instead with removing of
\setfloatalignment.


Yes, this works, too.  It is a convenient hack. Thanks!

It would be better to have a LaTeX attribute, say :commands, that 
places commands within \begin{figure} ... \end{figure}.


I'm circling back to Tufte handouts for a course I'm offering in 
the Fall.  It is great that ox-latex has the flexibility to export 
to tufte-latex now.  I haven't prepared any handouts yet, but all 
the pieces seem to work in a straightforward way.  Org-cite is 
performing like a champ, too!


All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye