Re: org-->latex and beamer, avoid blocks

[General discussions about Org-mode.]

>>> "FE" == Fraga, Eric  writes:

> On Thursday, 18 Jan 2024 at 16:40, Uwe Brauer via "General discussions
> about Org-mode." wrote: 
>> Any suggestion how to tell the converter not convert
>> 
>> *** First step
>> 
>> To a block?

> Add the :B_ignoreheading: tag and the following property to the headline:

> :PROPERTIES:
> :BEAMER_env: ignoreheading
> :END:

> which you can do easily if you have

Ah, thanks very much.


> #+startup: beamer

> in your org file which allows you to then use "C-c C-b i" to add that
> information.

Aha also very useful (the allowframebreaks and shrink option that I use
often is unfortunately not among these property templates)

> Although the idea of a single document that exports to both beamer and
> LaTeX is attractive, I've always found it to be more effort than it's
> worth.  Just my 2¢.


Well, right. I just realized that for example 
when I export the document to LatReX article, then cosntructs like


*** Code
 :PROPERTIES:
 :BEAMER_env: ignoreheading
 :END:

Get converted in the sense that the properties are not simply ignored
but transformed to text, which is not what I want.



-- 
I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the EU and NATO membership of Ukraine. 



smime.p7s
Description: S/MIME cryptographic signature

[PATCH] Silently remove lockfiles from org-agenda-files

[Joseph Turner]

My configuration contains the equivalent of

(setopt org-agenda-files
   (directory-files-recursively "~/.local/share/org/todo" ".org$"))

My Emacs setup broke today due to the presence of a lockfile inside
"~/.local/share/org/todo".  I use EXWM, and I show org-agenda on startup:

(add-hook 'after-init-hook
(lambda () (org-agenda nil "t")))
(setq initial-buffer-choice (lambda () (get-buffer "*Org Agenda*")))

org-agenda-files contained a non-existent file, so org-check-agenda-file
attempted to prompt me.  For some reason (maybe EXWM didn't fully load),
Emacs simply hung without prompting, leaving me with a black screen.

The attached patch silently removes lockfiles from org-agenda-files.

Thanks!

Joseph

P.S.

I'm not sure how the lockfile ended up there.  Maybe I killed Emacs with
SIGKILL while one of my agenda files was open and modified in a buffer,
and so the lockfile was not deleted?

>From e69e69a03c215704d83f8388370f0db2bc93891d Mon Sep 17 00:00:00 2001
From: Joseph Turner 
Date: Thu, 18 Jan 2024 22:24:10 -0800
Subject: [PATCH] * lisp/org.el (org-check-agenda-file): Silently exclude
 lockfiles

---
 lisp/org.el | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 8929a7217..f48a8ff46 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -15563,8 +15563,12 @@ (defun org-file-menu-entry (file)
   (vector file (list 'find-file file) t))
 
 (defun org-check-agenda-file (file)
-  "Make sure FILE exists.  If not, ask user what to do."
+  "Make sure FILE exists.  If not, ask user what to do.
+Automatically exclude lockfiles."
   (unless (file-exists-p file)
+(when (string-match-p (rx bos ".#") file) ; Exclude lockfiles
+  (org-remove-file file)
+  (throw 'nextfile t))
 (message "Non-existent agenda file %s.  [R]emove from list or [A]bort?"
 	 (abbreviate-file-name file))
 (let ((r (downcase (read-char-exclusive
-- 
2.41.0

Re: Patch to allow adjusting latex fragment display scale factor

[Matt Huszagh]

Hi,

Bringing this back up. Ihor, I've added you to the thread directly
(hope that's ok).

Any thoughts? I have not yet updated it for the most recent changes to
main, but I can do that.

Matt

On Sun, Oct 10, 2021 at 9:40 PM Matt Huszagh  wrote:
>
> Matt Huszagh  writes:
>
> > I've created a patch to allow adjusting the scale factor used for inline
> > latex image fragments. This involves a customizable variable that can
> > either be set to a scale factor (defaults to 1.0) or a function that
> > evaluates to a scale factor.
> >
> > This feature is in addition to the existing scale factor adjustment
> > capability provided by `org-preview-latex-process-alist' through
> > `:image-size-adjust'. Wherease image-size-adjust performs scaling at the
> > time of image generation, the new change performs it during
> > display. This can lead to significant time saving and suffers no loss of
> > quality for vector graphics.
> >
> > As an example of use, I have several functions for changing frame
> > scaling. I've added
> >
> > (if (eq major-mode 'org-mode)
> >   (progn
> > (org-clear-latex-preview)
> > ;; 16 corresponds to the C-u C-u arg prefix.
> > (org-latex-preview 16)))
> >
> > to these functions so that changing the frame scaling also
> > correspondingly changes the latex preview/fragment scaling to match the
> > new size of the surrounding text. Because of this new feature, this
> > change is effectively instantaneous for reasonably numbers of
> > overlays. Obviously, something similar could be done for
> > `text-scale-adjust' (e.g., through `advice-add').
> >
> > Feedback appreciated.
>
> Apologies, the patch I sent is slightly wrong. The line numbers also
> reflect an earlier patch I made. Here is a corrected version.
>

Re: [Patch] Align baseline of latex fragments and surrounding text

[Matt Huszagh]

Ihor Radchenko  writes:

> Matt Huszagh  writes:
>
>> These are nice ideas, and ones I hadn't considered. Thanks for the
>> suggestions! I'll think about it a bit and may modify the patch
>> accordingly.
>
> May I ask if you further considered changing the patch?

Hey Ihor,

I'm sorry for the late reply. I'm just now looking at several patches I
submitted a few years ago and left hanging...

The answer to this question is yes I did, and IIRC got most of the way
through implementing them but ran into a largely unrelated issue that I
didn't, at the time, find a solution for. It looks like I still have the
branch with those changes and I can take a look back at it and try to
resolve it.

However, I noticed that there appears to be another (large) patch in the
works that also does this (email subject line "Overhaul of the LaTeX
preview system"). That's a long thread and I haven't followed it. Is
there still scope for my change? Is it worth getting this in?

Matt

Re: export to latex (article) but with multicolums

[Ihor Radchenko]

Uwe Brauer via "General discussions about Org-mode."
 writes:

> https://orgmode.org/worg/exporters/beamer/tutorial.html
>
> It is possible to have multicolumns in beamer.
>
> Now I am writing a bilingual text, and would have each language in a column.
>
> Is there any similar configuration possible for exporting to LaTeX (article)?

AFAIK, no. You may have to use special blocks or latex environments instead.

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

Re: org-->latex and beamer, avoid blocks

[Fraga, Eric]

On Thursday, 18 Jan 2024 at 16:40, Uwe Brauer via "General discussions about 
Org-mode." wrote:
> Any suggestion how to tell the converter not convert
>
> *** First step
>
> To a block?

Add the :B_ignoreheading: tag and the following property to the headline:

:PROPERTIES:
:BEAMER_env: ignoreheading
:END:

which you can do easily if you have

#+startup: beamer

in your org file which allows you to then use "C-c C-b i" to add that
information.

Although the idea of a single document that exports to both beamer and
LaTeX is attractive, I've always found it to be more effort than it's
worth.  Just my 2¢.

-- 
: Eric S Fraga, with org release_9.6.13-1003-g872c1b in Emacs 30.0.50

Re: [BUG] defaults make it hard to edit Elisp blocks in org buffers

[Ihor Radchenko]

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

>> I cannot think of any common use where the two approches differ, and
>> it is indeed simpler. The possibility that the block does not have the
>> common indentation still stands.
>
> As far as I understand, the effect also occurs when the block has a
> common indentation. Below are the steps:
> ...
> And with POINT after "?" and typing ENTER (wait more than 1 second
> for automatic indenting of 2 spaces), I can type parentheses with
> some sort of common indentation like below:
> #+begin_src emacs-lisp
>;; common indentation?
>(())
>(())
>(())
> #+end_src
> When I place POINT in the middle of the lowest parentheses and
> type ENTER, then everything moves 2 spaces to the right like below:

This is expected, because we already have a special case for creating an
empty line - it does not contribute to common indentation we calculate.

But the special case for empty line does not cover your original
reproducer.

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

Re: [BUG] defaults make it hard to edit Elisp blocks in org buffers

[gerard . vermeulen]

On 18.01.2024 17:45, Sébastien Miquel wrote:

Ihor Radchenko writes:

If I recall correctly, in order to fix this, in =org-indent-line=,
before calling =TAB= in the native buffer, one should check the
current line indentation and if it is less than =block-content-ind=,
start by adding this much indentation to the current line.

This could be a bit fragile, and in particular it assumes that the
rest of the block has this =block-content-ind=, which might not be 
the

case. One could possibly at least check that the first line of the
block does have this much indentation. If it doesn't, just do
whatever.

What about a simpler approach - indent the line at point to block's
expected indentation (if it is not yet there) and then rely upon the
code block's major mode to do the right thing?


I cannot think of any common use where the two approches differ, and
it is indeed simpler. The possibility that the block does not have the
common indentation still stands.


As far as I understand, the effect also occurs when the block has a
common indentation. Below are the steps:

With this settings:
#+begin_src emacs-lisp -i :results silent
(setopt org-adapt-indentation nil
org-src-preserve-indentation nil
org-edit-src-content-indentation 2)
#+end_src
And with POINT after "?" and typing ENTER (wait more than 1 second
for automatic indenting of 2 spaces), I can type parentheses with
some sort of common indentation like below:
#+begin_src emacs-lisp
  ;; common indentation?
  (())
  (())
  (())
#+end_src
When I place POINT in the middle of the lowest parentheses and
type ENTER, then everything moves 2 spaces to the right like below:
#+begin_src emacs-lisp
;; common indentation?
(())
(())
((
  ))
#+end_src
I think, this is different of what you are saying.

Looking at the code, I inferred that I can kill this behavior
with the `-i' switch, and that works.

Regards -- Gerard

Re: Developing Moodle resources/sites with Org Mode

[Leo Butler]

On Thu, Jan 18 2024, Edward Doolittle  wrote:

> Thank you for your thoughts.
> I have used org-mode to do all my STACK question authoring for a few
> years now [1]. I do all the writing in emacs and then copy/paste into the
> STACK textareas, test, repeat. It is not elegant, but it is easier than
> working in a web-browser. It would be really nice to be able to create
> the entire question in emacs, because defining graders in STACK is
> pretty tedious.
> I had a look at the message you refer to. It is a good summary, and in
> line with what I thought was straightforwardly do-able. I haven't
> uploaded any of my problems to STACK yet but that's how I imagined it
> going: cutting and pasting like you say. In the long run I'd like to
> be able to export to Moodle XML, then automatically upload the XML to
> the Moodle site.

Yes, that would be nice to have. 

>
> I have been making use of tex1 and texput in Maxima to generate
> LaTeX. It is alarming to me that they may not be supported by default
> in Moodle/STACK. I decided to do most of the LaTeX generation in
> Maxima instead of writing the LaTeX and filling in the values of
> variables because of situations like the following: If Maxima has
> a0:-3 and I write LaTeX \(x-{@a@}\) I will get \(x- -3\) which is
> exactly what I asked for but unconventional. If I define Maxima
> output0:tex1(x-a0), Maxima will do the algebra and LaTeX
> \({@output0@}\) will be \(x+3\) as we would normally expect. Lots of
> little things like that made me prefer assembling expressions in
> Maxima and exporting them whole hog instead of one bit at a time.

Yes, I have gone down a similar path. I prefer to ask STACK/Moodle to do
as little as possible. One additional reason for this is that the list
of "disallowed" Maxima functions grows with each release of STACK.

>
> Some more thought will have to be given to how to create the grading
> trees. I'm sure it's documented somewhere but I'll probably just
> create a question with some complicated grading trees and export it
> from Moodle to see what the XML looks like. I think I won't go there
> for now because the Maxima fragments on the grading side run in the
> same session as the Maxima initialization on the question side in
> STACK, but that is rather awkward to fake in Org until there is a
> session capability in the Maxima blocks, I think. So it might be
> possible to write the grading trees in Org but would be difficult to
> test them.
>
> There is no export from Moodle to XML but there are external packages
> that will do it ... with what quality, I don't know. But once the Org
> file is in "Org XML" it should be relatively straightforward to
> transform it to the XML required by Moodle using XSLT or
> whatever. Lots of details, but that's my big picture strategy. I'd
> like eventually to export directly from Org to Moodle XML but that's
> currently beyond my skill set.

> I agree that we need ob-maxima.el to properly handle sessions. Note that
> you can use Maxima to create graphs, too.
> I posted my kludge to work around the lack of sessions to 
> https://github.com/edoolittle/org-moodle.  It's pretty ugly but works for now.

I have attached a different type of work-around. It uses Maxima's `save'
command and the :prologue and :epilogue header arguments.

>
> Again, the work to sessionize Maxima is probably straightforward but
> lots of details that are currently beyond my skill set. I am not
> proficient at Emacs Lisp. For now I'm concentrating on the low-hanging
> fruit that I can do quickly.

I have toyed with putting in session support. It does not seem too
difficult, but I have needed a reason to do it. Good is the enemy of
better.

>
> I have avoided for now using the Maxima "plot" command. Actually, it's
> "plot2d" in Maxima/Org and "plot" in Maxima/STACK. Note they are two
> slightly different things, which means that one must always be
> conscious of the context and not use any of the nicer "plot2d"
> features when writing questions that will eventually find their way
> into Moodle/STACK.
>
> Also "plot" is just too restrictive in some cases. I can graph two
> curves (parametric curves even) and put dots at their intersection
> points but I can't figure out how to label those dots. Which is A and
> which is B?

Oh, I encountered this problem a while ago when I submitted a patch to
the STACK documentation. IIRC, there is some undocumented numbering,
etc. etc.

I believe that `draw' support is a project goal, but I think that
jsxgraph has attracted much more attention.

> So even though I've used it in the past, I think I'd rather put my
> energy into figuring out how to generate diagrams with JSXgraph which
> is modern, sophisticated, and beautiful compared to plot. A difficulty
> is how to get the {#maxima-variable#} out of the maxima results and
> into the JSXgraph block. I /think/​ that's just a minor issue with
> noweb.

Yes, that's right. If you have a small example, please feel free to share.

>
> One 

Re: Developing Moodle resources/sites with Org Mode

[Brett Presnell]

> I have begun thinking about how I might use Org mode to improve the 
> experience of developing resources for the open source Moodle LMS or even 
> developing entire Moodle sites.

Nice idea.  You might find it useful to look into the source code for
the R/Exams package for R (https://www.r-exams.org/).  The format there
is RMarkdown as opposed to org mode, but I imagine a lot of the same
ideas might apply.  I'm pretty sure that Moodle was the original
platform that the developers were using, but they now support most of
the big platforms.

> I have already written a statistics exam with Org Mode and Maxima.  I can 
> generate as many different versions of a question (and associated answer key 
> and solution set) as I wish with almost no additional effort.  In order to 
> facilitate import into Moodle STACK, I have had to restrict my access to 
> Maxima variables using accessors also written in Maxima ... I import the 
> Maxima block into the accessor with noweb.  I end up re-running the same 
> chunk of Maxima code over and over, once for each variable access, because 
> there is no Maxima session.  It is kind of stupid but I tossed it together in 
> three days.  I suppose I could store the results of a Maxima run in a table 
> and just do table lookups but I've got the spare compute cycles to run Maxima 
> over and over until I sort this all out.  I think Maxima session is the right 
> way to go but I'm inexperienced with all this and would appreciate guidance.

I've used R/Exams a good bit by now, and I always generate at least 16
random versions of every quiz or exam.  The process is pretty automatic.

Re: [BUG] defaults make it hard to edit Elisp blocks in org buffers

[Sébastien Miquel]

Ihor Radchenko writes:

If I recall correctly, in order to fix this, in =org-indent-line=,
before calling =TAB= in the native buffer, one should check the
current line indentation and if it is less than =block-content-ind=,
start by adding this much indentation to the current line.

This could be a bit fragile, and in particular it assumes that the
rest of the block has this =block-content-ind=, which might not be the
case. One could possibly at least check that the first line of the
block does have this much indentation. If it doesn't, just do
whatever.

What about a simpler approach - indent the line at point to block's
expected indentation (if it is not yet there) and then rely upon the
code block's major mode to do the right thing?


I cannot think of any common use where the two approches differ, and
it is indeed simpler. The possibility that the block does not have the
common indentation still stands.

--
Sébastien Miquel

export to latex (article) but with multicolums

[General discussions about Org-mode.]

Hello

According to 

https://orgmode.org/worg/exporters/beamer/tutorial.html

It is possible to have multicolumns in beamer.

Now I am writing a bilingual text, and would have each language in a column.

Is there any similar configuration possible for exporting to LaTeX (article)?

Thanks and regards

Uwe Brauer 
-- 
I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the EU and NATO membership of Ukraine. 

Re: Fwd: [BUG] Sparse tree does not work on properties with dashes

[Ihor Radchenko]

Ihor Radchenko  writes:

>> Expected behaviour: produce a sparse tree.
>>
>> Actual result: no sparse tree.
>
> Thanks for reporting!
> Confirmed.
>
> This is because `org-sparse-tree' will produce the following matcher:
>
>  TEST-HELLO="one"
>
> Which is interpreted as: Has tag "TEST" and does not have property
> "HELLO" set to "one".

`org-make-tags-matcher' is now supposed to handle \-escaped dashes in
properties. However, it does not seem to work:

(org-make-tags-matcher "TEST\-HELLO=\"one\"" t) yields

(progn
   (setq org-cached-props nil)
   (or
(and
 (not (string= (or (org-cached-entry-get nil \"HELLO\") \"\") \"one\"))
 (member \"TEST\" tags-list

Jens, do you have any ideas?

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

org-->latex and beamer, avoid blocks

[General discussions about Org-mode.]

Hi

I have a longer documents with a lot of graphics, and the following setting:

#+OPTIONS: H:2

So that 
** Introduction 

Will be converted to a frame, while if converted to LaTeX (article) it
will be converted to a subsection.

Now I also have  subsubsections like 

*** First step

Containing two graphics, 

This subsubsection will be converted to a block and then I cannot use
allowframebreaks and only one graphics is displayed.

Any suggestion how to tell the converter not convert 

*** First step 

To a block?

Thanks and regards

Uwe Brauer 


-- 
I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the EU and NATO membership of Ukraine. 

Re: S-M-{,} on CLOCK timestamp

[Ihor Radchenko]

Jorge P. de Morais Neto  writes:

> A textual description:
>
> ...
> The bug is that M-S- adjusts Task B clock in timestamp by x
> minutes and Task A clock out timestamp by 5 minutes, where x (in our
> case, x is 4) is not 5.  And in my opinion, Task A clock out timestamp
> *should not change at all* because it was already less then the adjusted
> Task B clock in timestamp.

Confirmed.

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

[FR] Transfer export attributes from dynamic block to its first child (was: Bug: clocktable)

[Ihor Radchenko]

 writes:

> J’ai un soucis avec le clocktable  qui semble être un bug car il n’accepte 
> pas les attributs latex avant la ligne BEGIN:

> #+ATTR_LATEX: :align Xll :width \textwidth
> #+BEGIN: clocktable :scope file :maxlevel 2

This is a commonly reported problem - when using dynamic blocks (in
particular, clocktable block), it is impossible to set export attributes
for the generated table. This is because the attributes of the dynamic
block have no effect on the table inside it.

I suggest to provide a standard dynamic block parameter that will make
Org mode prepend certain affiliated keywords to the generated contents:

#+attr_latex: :width \textwidth
#+begin: clocktable :scope file :maxlevel 2 :org-dblock-prepend (:attr_latex )
#+end:

will yield

#+attr_latex: :width \textwidth
#+begin: clocktable :scope file :maxlevel 2 :org-dblock-prepend (:attr_latex)
#+attr_latex: :width \textwidth
#+CAPTION: Clock summary at [2024-01-18 Thu 16:23]
| Headline   | Time|
|+-|
| *Total time* | *0h 0min* |
#+end:

Tentative patch is attached.

>From b6bfe67ed19b2c3a0c3744488f051c29e79a5b3d Mon Sep 17 00:00:00 2001
Message-ID: 
From: Ihor Radchenko 
Date: Thu, 18 Jan 2024 16:24:34 +0100
Subject: [PATCH] Allow transfering dblock affiliated keywords to its contents

* lisp/org.el (org-prepare-dblock): Use :org-dblock-prepend dblock
parameter and append the listed affiliated keywords before the
generated dynamic block contents.
---
 lisp/org.el | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/lisp/org.el b/lisp/org.el
index 8929a7217..585b9aa5b 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -8836,6 +8836,12 @@ (defun org-prepare-dblock ()
 (delete-region begdel (match-beginning 0))
 (goto-char begdel)
 (open-line 1)
+(let ((prepend (plist-get params :org-dblock-prepend))
+  (dblock (org-element-at-point (1- (point
+  (affiliated (org-element-create 'paragraph)))
+  (dolist (prop prepend)
+(org-element-put-property affiliated prop (org-element-property prop dblock))
+(insert (org-element-interpret-data affiliated
 params))
 
 (defun org-map-dblocks ( command)
-- 
2.43.0


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

Re: Developing Moodle resources/sites with Org Mode

[Christian Moe]

Hi, Edward

Edward Doolittle writes:

> 2) Development of Moodle glossaries. Glossaries can be uploaded to a
> Moodle site using an appropriate XML file.  Glossaries could be
> developed in Org mode, including JSXgraph diagrams and graphs, PNG
> images, and so on, and then Org mode converted to XML and the XML
> transformed to Moodle Glossary XML using XSLT.  (I don't really know
> those tools at all, so I don't know if that would be a good way to go
> about the process; exporting directly to Moodle Glossary was my first
> thought, but it is not a general export that is necessary or
> appropriate, rather an export of a specifically designed Org file.
> XSLT seems old fashioned but there are tools around, and there is a
> project for exporting Org mode to XML.)

I'm a Moodle noob and rusty on the tools, but this is interesting to
think about.

You may not need any additional library for the XML export bit. The
builtin Org HTML exporter does XHTML export by default, and XHTML is an
XML, so one could just apply XSLT to that. There may be advantages to
using a library like om-to-xml (cleaner, more semantic XML; access to
more properties than what gets exported). But it looks like Moodle only
uses XML to wrap the glossary entries and their properties; any markup
inside the glossary definitions appears to be in HTML (with the html
tags entity-escaped), not defined by the Moodle glossary XML format. So
if you're going to have some markup in the definitions, you may be
better off leaving the (X)HTML part to Org instead of reimplementing it
in XSLT.

Another option might be to dispense with XSLT entirely and just write
elisp code to map the entries of an Org glossary and generate Moodle XML
from that.

How would you format the glossary on the Org side? Would you use Org
entries (** term) or Org description lists (- term :: definition)?

On the Moodle side, do you want keywords and attachments?

Yours,
Christian

Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export

[Ihor Radchenko]

Juan Manuel Macías  writes:

>> As for {[}{]}, it is a bit difficult to implement. Especially when we
>> also consider user filters and derived backends. If we have several
>> transcoders of consequent elements, there is always a risk that even
>> when a given filter/transcoder is generating a valid LaTeX code,
>> concatenating them may still cause issues like we have with \\.
>
> I see. I think pandoc's solution is what Leslie Lamport recommends
> (naturally, Lamport doesn't say to enclose /all/ brackets in curly
> braces).

This turned out to be a lot easier than I thought.
See the attached patch.

>> \command
>> [unrelated text]
>>
>> If there are, we may actually want to consider pandoc's approach
>> seriously.
>
> In principle, any environment that takes an optional argument in a
> "dangerous" position. Just do a simple test. Something like this:
>
> #+begin_figure
> [lorem] ipsum
> #+end_figure
>
> will throw an error like ''LaTeX Error: Unknown float option...''
>
> Of course, putting an empty line after #+begin... usually solves it. But
> the user may not know it.
>
> There are also a number of commands with an optional argument. For
> example \pagebreak. Something like this will give an error:
>
> lorem @@latex:\pagebreak@@ [ipsum]
>
> \item is another typical example, but in this case org adds \relax.

With the patch, I am getting the following:

* This is test
lorem @@latex:\pagebreak@@ [ipsum]

#+begin_figure
[lorem] figure
#+end_figure

| [foo] | 2 |
| [bar] | 3 |

- [bax]
- [aur]

exports to

lorem \pagebreak {[}ipsum]

\begin{figure}
{[}lorem] figure
\end{figure}

\begin{center}
\begin{tabular}{lr}
{[}foo] & 2\\[0pt]
{[}bar] & 3\\[0pt]
\end{tabular}
\end{center}

\begin{itemize}
\item {[}bax]
\item {[}aur]
\end{itemize}

>From db3fa01d6f15b3d3f499f77e342a608a822029c8 Mon Sep 17 00:00:00 2001
Message-ID: 
From: Ihor Radchenko 
Date: Thu, 18 Jan 2024 14:01:32 +0100
Subject: [PATCH] ox-latex: Make sure that [text] is not misinterpreted as
 LaTeX argument

* lisp/ox-latex.el (org-latex-plain-text): Protect plain text starting
from [.  It might be misinterpreted as optional command argument if
previous exported fragment ends with a command accepting such.
*
testing/lisp/test-ox-latex.el (text-ox-latex/protect-square-brackets):
Add new test.

Link: https://orgmode.org/list/87o7dju9vn@posteo.net
---
 lisp/ox-latex.el  |  9 +
 testing/lisp/test-ox-latex.el | 23 +++
 2 files changed, 32 insertions(+)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 432f09f4e..a3505c25f 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3094,6 +3094,15 @@ (defun org-latex-plain-text (text info)
 		"\\(?:[ \t]*\\)?[ \t]*\n"
 (concat org-latex-line-break-safe "\n")
 output nil t)))
+;; Protect [foo] at the beginning of lines / beginning of the
+;; plain-text object.  This prevents LaTeX from unexpectedly
+;; interpreting @@latex:\pagebreak@@ [foo] as a command with
+;; optional argument.
+(setq output (replace-regexp-in-string
+  (rx bol (0+ space) (group "["))
+  "{[}"
+  output
+  nil nil 1))
 ;; Return value.
 output))
 
diff --git a/testing/lisp/test-ox-latex.el b/testing/lisp/test-ox-latex.el
index 41df1b823..237ad97ec 100644
--- a/testing/lisp/test-ox-latex.el
+++ b/testing/lisp/test-ox-latex.el
@@ -29,6 +29,29 @@ (unless (featurep 'ox-latex)
 
 
 
+(ert-deftest text-ox-latex/protect-square-brackets ()
+  "Test [foo] being interpreted as plain text even after LaTeX commands."
+  (org-test-with-exported-text
+  'latex
+  "* This is test
+lorem @@latex:\\pagebreak@@ [ipsum]
+
+#+begin_figure
+[lorem] figure
+#+end_figure
+
+| [foo] | 2 |
+| [bar] | 3 |
+
+- [bax]
+- [aur]
+"
+(goto-char (point-min))
+(should (search-forward "lorem \\pagebreak {[}ipsum]"))
+(should (search-forward "{[}lorem] figure"))
+(should (search-forward "{[}foo]"))
+(should (search-forward "\\item {[}bax]"
+
 (ert-deftest test-ox-latex/verse ()
   "Test verse blocks."
   (org-test-with-exported-text
-- 
2.43.0


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

Re: Consider removing newlines from org-insert-link help message

[Ihor Radchenko]

Salih Muhammed  writes:

> I see that the text has been updated after updating org at my end,
> however, the issue of the stretch persists (see attachment).
>
> My version of org is at 571186631a09262abb58ca395f75b837bbb2
>
> Org version gives: 9.7-??-5711866

Org does not add any extra newlines there. It is likely something about
window size.

>From the screenshot, it looks like you use some window management
package or customized your `display-buffer-alist'. This customization is
likely overriding Org mode's call to `fit-window-to-buffer', making the
window appear larger than the containing buffer text.

I may be wrong though. It would help if you try to reproduce the problem
starting from emacs without customization. See
https://orgmode.org/manual/Feedback.html#Feedback

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

Re: [BUG] defaults make it hard to edit Elisp blocks in org buffers

[Ihor Radchenko]

Sébastien Miquel  writes:

> The issue is that when you press return, you insert a newline, with no
> indentation, then call =org-indent-line= which edits the block in a
> native buffer. This is supposed to remove any common indentation, but
> there is now none. Then it reinserts the code in the org-buffer,
> adding a new common indentation to the block.

Exactly.
Confirmed.

> If I recall correctly, in order to fix this, in =org-indent-line=,
> before calling =TAB= in the native buffer, one should check the
> current line indentation and if it is less than =block-content-ind=,
> start by adding this much indentation to the current line.
>
> This could be a bit fragile, and in particular it assumes that the
> rest of the block has this =block-content-ind=, which might not be the
> case. One could possibly at least check that the first line of the
> block does have this much indentation. If it doesn't, just do
> whatever.

What about a simpler approach - indent the line at point to block's
expected indentation (if it is not yet there) and then rely upon the
code block's major mode to do the right thing?

Even when we are in a situation when the user did not just press C-j or
, things should still work with the described approach.

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

Re: #+LATEX_HEADER: \usepackage[greek,german]{babel} ??

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

>>ox-latex tries hard to not duplicate babel. I am unable to reproduce
>>duplication with your file (but with #+latex_class: koma-article removed)
>
> Despite this, there is a repetition, and the clash is because ox-latex
> wants ngerman wiith
> #+language: de
> while Horst wants to use germanb. The clash is between what ox-latex
> generates and what Horst tries to add with #+LATEX_HEADER:
>
> Actually, he also needs greek and for that I have recommended to customise
> variables so that fontenc is "LGR,T1" and the parameters for babel are
> "greek,AUTO", instead of trying to add a #+LATEX_HEADER:
> \usepackage[LGR,T1]fontenc, because that also generates a package
> option clash.
>
> That is something we might need to explore more, if/when people need/want
> to use pdflatex instead of luatex or xelatex.

I doubt that we can easily catch option clashes like this.
People can customize things arbitrarily with #+latex_header, and we
cannot catch all the possible problems.

What we might improve is displaying compilation errors in a popup buffer
rather than almost-invisible message in the echo area.

>>> 2. There is an error in my Orgmode code because it exports {babel} once
>>> too many
>>
>>Does the problem persist without #+latex_class: koma-article?
> Once again, yes, because it is mainly a matter of #+language.
> I think we need the following
> 2) more thought on multilingual documents (#+language: gr,de)
> 3) more though on documents with multiple font encodings.

Agree.
For multiple languages, see the discussion in
https://list.orgmode.org/orgmode/878r9t7x7y@posteo.net/

> 1) more docs on #+language

If you have ideas how to improve the manual, feel free to share them.

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

[FR] Tangling code blocks inside encrypted subtrees

[Ihor Radchenko]

Hello,

Currently, Org mode never tangles code blocks when they reside inside
encrypted subtrees. Never means that such code blocks will _not_ be
tangled even if encrypted subtree is temporarily decrypted via
org-decrypt-entry/org-decrypt-entries in the current buffer.

The current approach is indeed safe as it prevents leaking potentially
sensitive information. However, it is sometimes necessary to tangle the
code blocks from inside encrypted trees as well. For example, if the
file is a literate Org config - the whole point of such config is to
tangle it, including encrypted parts.

To allow tangling encrypted code, we may provide a special tag :TANGLE:
or maybe a special heading property, like :TANGLE-ENCRYPTED: yes. If
such property is set in the encrypted heading, Org will decrypt and
tangle the code blocks inside.

WDYT?

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