Re: Depreciating TeX-style LaTeX fragments

[Anthony Cowley]

> On Jan 16, 2022, at 7:13 AM, Eric S Fraga  wrote:
> 
> On Sunday, 16 Jan 2022 at 00:36, Timothy wrote:
>>Hmm. Not sure about this. Keystroke wise we’re comparing $$
>>to \(. The latter can be completed by smartparens, but since
>>single dollars are reasonable Org content the former can’t.
>>At this point the only argument is muscle memory, and if
> 
> As an aside, I will suggest including the following code in your Emacs
> customization:
> 
> #+begin_src emacs-lisp :tangle "esf-org.el"
>  ;; from Nicolas Richard 
>  ;; Date: Fri, 8 Mar 2013 16:23:02 +0100
>  ;; Message-ID: <87vc913oh5@yahoo.fr>
>  (defun yf/org-electric-dollar nil
>"When called once, insert \\(\\) and leave point in between.
>  When called twice, replace the previously inserted \\(\\) by one $."
> (interactive)
> (if (and (looking-at ")") (looking-back "("))
> (progn (delete-char 2)
>(delete-char -2)
>(insert "$"))
>   (insert "\\(\\)")
>   (backward-char 2)))
>  (define-key org-mode-map (kbd "$") 'yf/org-electric-dollar)
> #+end_src
> 
> I've been using this for years now and it works very well: I also had
> $...$ in my muscle memory.

This is a really helpful snippet, but I tried it out for a while a previous 
time this issue came up and found the readability of equations took too much of 
a hit. The “backslash city” really is tough to visually parse. Backslash 
density is already an unfortunate bit of the LaTeX experience, and I didn’t get 
used to the extra slashed characters as bookends over a two week trial.

I still wanted to express my appreciation for you sharing this!

Anthony

Re: trivial software engineering'ish question: switching org's

[Anthony Cowley]

> On Mar 21, 2021, at 1:46 PM, Greg Minshall  wrote:
> 
> hi.  i occasionally want to switch from the org package to a git
> version, then back again.  and, i want to avoid the dread "mixed
> installation".
> 
> i'm wondering is there a way people do this other than simply
> installing/deleting the package version?
> 
> cheers, Greg
> 

The nix package manager is outstanding for these uses. You can have two 
versions of emacs — each with a different version of org — side by side, or 
switch between them without needing to re-byte compile anything.

Anthony

Re: Short captions

[Anthony Cowley]

Fraga, Eric writes:

> On Monday, 10 Feb 2020 at 23:20, Anthony Cowley wrote:
>> I am having trouble understanding how short captions are supposed to
>> work. Consider this org document:
>
> [...]
>
>> The first matches my expectations. The second is an example of taking
>> the last bit of markup as the short caption. The third seems to lose
>> the short caption altogether.
>
> I can confirm (with a slightly out of date org) this behaviour which
> does seem to be inconsistent and/or wrong.  However, I wasn't able to
> find any discussion of short captions in the org manual so I'm not sure
> if there are caveats on their use.

They are described in section 12.8 Captions 
<https://orgmode.org/manual/Captions.html#Captions>

I think this patch fixes the issue:

diff -ruN A/org-element.el B/org-element.el
--- A/org-element.el2019-12-03 10:28:06.0 -0500
+++ B/org-element.el2020-02-11 14:47:45.564452900 -0500
@@ -4018,14 +4018,15 @@
   (parsed? (member kwd org-element-parsed-keywords))
   ;; Find main value for any keyword.
   (value
-   (let ((beg (match-end 0))
- (end (save-excursion
-(end-of-line)
-(skip-chars-backward " \t")
-(point
- (if parsed?
- (org-element--parse-objects beg end nil restrict)
-   (org-trim (buffer-substring-no-properties beg end)
+(save-match-data 
+ (let ((beg (match-end 0))
+   (end (save-excursion
+  (end-of-line)
+  (skip-chars-backward " \t")
+  (point
+   (if parsed?
+   (org-element--parse-objects beg end nil restrict)
+ (org-trim (buffer-substring-no-properties beg end))
   ;; If KWD is a dual keyword, find its secondary value.
   ;; Maybe parse it.
   (dual? (member kwd org-element-dual-keywords))


Anthony

Short captions

[Anthony Cowley]

I am having trouble understanding how short captions are supposed to work. 
Consider this org document:

#+begin_src org
,#+title: Short Caption Test
,#+author: Org User

,#+label: table1
,#+caption[This is table1]: And here go on at length in a longer caption.
| Name | Favorite Number |
|--+-|
| Sue  | 42  |
| Tom  | 99  |

,#+label: table2
,#+caption[This is table2]: But *with* /this/ table, the /short/ caption is 
*lost*.
| Name  | Favorite Color |
|---+|
| Alice | Red|
| Bob   | Also Red   |

,#+label: table3
,#+caption[This is table3]: No org markup is used in this long caption, but 
some $\LaTeX$ is!
| Number | Favorite Person |
|+-|
| 0  | Zed |
| 1  | Solo|
#+end_src

When I export it as a LaTeX file, the captions are:

#+begin_src latex
\caption[This is table1]{\label{table1}And here go on at length in a longer 
caption.}
#+end_src

#+begin_src latex
\caption[\textbf{lost}]{\label{table2}But \textbf{with} \emph{this} table, the 
\emph{short} caption is \textbf{lost}.}
#+end_src

and

#+begin_src latex
\caption{\label{table3}No org markup is used in this long caption, but some 
\(\LaTeX\) is!}
#+end_src

The first matches my expectations. The second is an example of taking the last 
bit of markup as the short caption. The third seems to lose the short caption 
altogether.

When I look at 

#+begin_src emacs-lisp
(org-element-map 
(org-element-parse-buffer) 
'table 
  (lambda (x) (org-element-property :caption x)))
#+end_src

Only the first caption seems to have the short caption in the parse results at 
all. Is this a bug, or should I avoid using markup in captions?

Thank you,
Anthony

#+begin_src emacs-lisp
(org-version)
#+end_src

#+RESULTS:
: 9.3

Re: [O] latex src block file output

[Anthony Cowley]

Nicolas Goaziou writes:

> Hello,
>
> Anthony Cowley <acow...@gmail.com> writes:
>
>> When I hit C-c C-c on a latex src block with a :file header,
>> I ultimately get an error from org-compile-file that the expected
>> output file in a temp directory was not produced. However, the file is
>> produced in the current directory.
>>
>> For instance, evaluating the src block in the following Org document,
>>
>> * A Little Diagram
>>
>> #+BEGIN_SRC latex :file diagram.pdf :packages '(("" "tikz")) :border 1em
>> \usetikzlibrary{shapes,arrows}
>> \begin{tikzpicture}[->, auto, node distance=3cm]
>>   \node [draw] (A) {A};
>>   \node [ellipse, draw, right of=A] (B) {B};
>>   \path (A) edge node {message} (B);
>> \end{tikzpicture}
>> #+END_SRC
>>
>>
>> Gives me the error,
>>
>> Debugger entered--Lisp error: (error "File 
>> \"/var/folders/n6/0j2z684n2pq_0d5kphzzvjs8gn/T/babel-7327204x/latex-73272sec.pdf\"
>>  wasn’t produced.  See \"*Org PDF LaTeX Output*\" for details")
>
> I cannot reproduce it. What Org version are you using? What is the value
> of `org-latex-pdf-process'?

Hi Nicolas, the org version I included in that original email was:
Org mode version 9.0.1 (9.0.1-elpaplus @ 
/Users/acowley/.emacs.d/elpa/org-plus-contrib-20161118/)

However I have since fixed the issue I was having. The problem was three-fold:

- My `org-latex-pdf-process` was a call to latexmk that did /not/ set 
`-outdir`. This was fine for exporting a document as LaTeX as all the work 
happened in the one directory, but evaluating a LaTeX src block involves a 
temporary directory.

- The value substituted for the `%o` placeholder in `org-latex-pdf-process` 
included a trailing slash which prevented it from working due to a double slash 
appearing in constructed paths (looking at my notes, I seem to have removed 
this parameter because of this problem). I now set `-outdir` to the output of a 
sub-shell that pipes `%o` through sed to remove the trailing slash.

- I still encountered an error when evaluating the src block even though the 
PDF was being produced. The error was during cleanup of temporary files, 
specifically a .log file. The failure to delete a nonexistent file was stopping 
the Org machinery that would next insert the result in my document. I addressed 
this by changing the second parameter of the call to `directory-files` in the 
`org-latex-compile` function from `nil` to `t` so that it would return absolute 
paths.

Since making those three changes, I am able to evaluate LaTeX src blocks and 
have the resulting figures appear in my Org document.

Thanks for all the hard work, and sorry I didn't follow up on my own report 
more promptly.

Anthony

[O] latex src block file output

[Anthony Cowley]

Hello,

When I hit C-c C-c on a latex src block with a :file header, I ultimately get 
an error from org-compile-file that the expected output file in a temp 
directory was not produced. However, the file is produced in the current 
directory.

For instance, evaluating the src block in the following Org document,

* A Little Diagram

#+BEGIN_SRC latex :file diagram.pdf :packages '(("" "tikz")) :border 1em
\usetikzlibrary{shapes,arrows}
\begin{tikzpicture}[->, auto, node distance=3cm]
  \node [draw] (A) {A};
  \node [ellipse, draw, right of=A] (B) {B};
  \path (A) edge node {message} (B);
\end{tikzpicture}
#+END_SRC


Gives me the error,

Debugger entered--Lisp error: (error "File 
\"/var/folders/n6/0j2z684n2pq_0d5kphzzvjs8gn/T/babel-7327204x/latex-73272sec.pdf\"
 wasn’t produced.  See \"*Org PDF LaTeX Output*\" for details")

While the *Org PDF LaTeX Output* buffer says,

...
Output written on latex-73272sec.pdf (1 page, 12285 bytes).
...

and sure enough the file is there in the same directory as the .org file I am 
editing.

I understand that the .tex file is in that temp directory, but pdflatex is 
dumping its output into the current directory. Is this a known (or even 
already-fixed) issue?

Org mode version 9.0.1 (9.0.1-elpaplus @ 
/Users/acowley/.emacs.d/elpa/org-plus-contrib-20161118/)

Anthony

Re: [O] Haskell source blocks?

[Anthony Cowley]

Lawrence Bottorff writes:

> I'm guessing Haskell and org-mode Babel aren't really a great match? After
> installing haskell-mode, I've tried
>
> #+begin_src haskell
> doubleMe x = x + x
> #+end_src
>
> which isn't working . . . because it isn't allowed in the ghci?
>
> #+begin_src haskell
> let doubleMe x = x + x
> #+end_src
>
> works. However,
>
> #+begin_src haskell
> let doubleSmallNumber4 x = if x > 0
> then x
>  else x*2
> #+end_src
>
> complains of a parsing error on else. How does Haskell work in org mode?
>
> LB

I use IHaskell with ob-ipython. It does what you want from babel and even makes 
in-line figure generation relatively painless.

Anthony

Re: [O] interesting dilemma with ob-ipython

[Anthony Cowley]

John Kitchin writes:

> I was looking into ob-ipython as a replacement for regular
> org-babel-python because it seems to be better at sessions. Also, you
> can use other kernels with it!
>
> For example:
>
> #+BEGIN_SRC ipython :session hy :results output :kernel hy
> (print "hello world")
> (import time)
> (print (time.asctime))
> #+END_SRC
>
> #+RESULTS:
> : hello world
> : Thu Jun  9 17:26:56 2016
>
> Here is the dilemma:
> If I special edit this, it is in python-mode, not hy-mode. And similarly
> on export, it is highlighted as ipython, not hy-lang.
>
> Any thoughts on how to address these?

I've had success using something like this,

(add-to-list 'org-src-lang-modes '("ipython" . haskell))

in a :noexport: setup section.

Anthony

Re: [O] exporting documents w/ babel results w/o evaluating babel blocks

[Anthony Cowley]

On Tuesday, May 24, 2016, Ista Zahn  wrote:

> On Tue, May 24, 2016 at 6:17 AM, Andreas Kiermeier
> > wrote:
>
> It this change is not going to be reversed than the doc string for
> org-export-babel-evaluate needs to be updated, and something should go
> in the NEWS file warning people (like me) who have been relying on the
> old behavior.
>
> Best,
> Ista


I, too, used the workflow of toggling oebe. Having a default header
argument to control evaluation is fine as an alternative, but I don’t see
the point in the change either. In any case, it seems like this is a common
issue and deserving of fairly prominent documentation.

Anthony

Re: [O] org-export-babel-evaluate and header arguments

[Anthony Cowley]

Charles C. Berry writes:

> On Wed, 9 Mar 2016, Anthony Cowley wrote:
>
>>
>> If I have org-export-babel-evaluate set to nil, source blocks are not 
>> evaluated on export. However, if a source block has a :var header 
>> argument that calls another source block, I am prompted if the callee 
>> should be evaluated.
>>
>> Given that the caller is not to be evaluated, I'm not sure I see a 
>> reason for the :var to be evaluated.
>
> What gives here is that `org-babel-get-src-block-info' needs to develop 
> all the header arguments regardless of evaluation of the code block, so 
> :var gets handled.
>
>> Is there a way I can disable this argument evaluation?
>
> Something like:
>
>   :var a=(and org-export-babel-evaluate (org-sbe "abc"))
>
>
> See C-h f org-sbe RET
>
> HTH,
>
> Chuck

Thanks for the tip, Chuck!

This works out very well with one minor caveat:

Setting org-export-babel-evaluate to nil means that C-c C-c no longer properly 
evaluates a block with such a header. This means that exporting must be enabled 
during development.

Other than that little quibble, I've gotten this to work in both tiny tests and 
with complicated, slow to evaluate documents, so I'm pleased.

A minor note about org-sbe documentation is that header arguments need not be 
in a table, but should simply be passed as a single string as the first 
argument to org-sbe. This is inferable from the documentation, but a bit 
oblique.

Anthony

[O] org-export-babel-evaluate and header arguments

[Anthony Cowley]

If I have org-export-babel-evaluate set to nil, source blocks are not evaluated 
on export. However, if a source block has a :var header argument that calls 
another source block, I am prompted if the callee should be evaluated.

Given that the caller is not to be evaluated, I'm not sure I see a reason for 
the :var to be evaluated. Is there a way I can disable this argument evaluation?

My goal is quick exports, but in this case it actually seems like a bug since 
all of my code blocks are :session. If I give permission to evaluate the :var 
argument, it will result in an error since the session hasn't been updated with 
the evaluations of other source blocks.

Thanks,
Anthony

Re: [O] [PATCH] org-latex-compile timestamp checks

[Anthony Cowley]

Rasmus writes:

> Nicolas Goaziou  writes:
>
>> Hello,
>>
>> Rasmus  writes:
>>
>>> Thanks!  I have added a TODO to my agenda regarding checking other
>>> backends, but I'd not hold grudges against anyone who beats me to it.
>>
>> I took care of ox-groff, ox-man and ox-texinfo.
>
> Thanks.
>
>> I let you improve zip handling in ox-odt, if you want to.
>
> OK.  I'll be traveling this weekend so I won't have time then.  Though it
> should be quick now that I can look at yours and Anthony’s code.
>
> Rasmus

Thank you both for following up on this! I had grep'ed the tree for other time 
comparisons and not seen any, but didn't read closely enough to see the 
reliance on file existence checks in the other back-ends.

Anthony

Re: [O] [PATCH] org-latex-compile timestamp checks

[Anthony Cowley]

Rasmus writes:

> Nicolas Goaziou  writes:
>
 Eventually, I think at least ox-texinfo.el, ox-man.el and ox-groff.el
 need a similar trick.
>>>
>>> Perhaps there should be an error check in ox-odt as well?  I guess the
>>> only thing that could happen is that the zip/odt can’t be written, which
>>> could happen if it’s open in windows, which is extremely picky with locked
>>> files.  [I have had to use a windows machine at work].
>>
>> This makes sense, indeed.
>>
>> Would you want to take care of applying the patches and updating the
>> various export back-ends accordingly, or should I?
>
> My life is a bit stressful at the moment (deadlines).  I'm happy to do it,
> and maybe I can do it in the weekend, but if you feel like taking doing it
> I won’t stand in your way.
>
> Rasmus

Just a friendly bump to make sure this doesn't get lost. I think the LaTeX 
patches should still apply; let me know if there's an issue tracker I could use 
to record the need for adjustments to other back-ends.

Anthony

Re: [O] [PATCH] org-latex-compile timestamp checks

[Anthony Cowley]

> On Jan 16, 2016, at 10:17 AM, Rasmus <ras...@gmx.us> wrote:
> 
> Hi Anthony and Nicolas,
> 
> Anthony Cowley <acow...@gmail.com> writes:
> 
>> Thanks for taking a look, Rasmus! The bug is in Org, not Emacs. One
>> may perhaps assume the invariant that successive calls to
>> `current-time` will return non-decreasing values. One might also
>> assume the invariant that successive touches of different files will
>> result in file attributes with non-decreasing timestamps. It is mixing
>> the two that is the bug, and Emacs itself shouldn’t try to fix
>> that. To be clear, the limiting factor in this comparison is the
>> filesystem whose timestamp granularity is much coarser than the system
>> clock.
> 
> Thanks for carefully explaining exactly what is going on here.
> 
>> We could do something like generate an entirely separate temporary
>> file before compilation, and use its timestamp as the reference by
>> which compilation output is evaluated. However, the approach of
>> checking file freshness with a one-second granularity seems like a
>> pretty good compromise.
> 
> I think the approach is fine now.  See below.
> 
>>> Maybe you could just check the log directly for failures rather than
>>> checking the file attributes, if these are not reliable.
>>> 
>>> Also, what is the ‘take‘?  I don’t seem to have it in my Emacs…
>> 
>> Sorry about that. Believe it or not I had already rewritten those two
>> lines — as simple as they are — trying to not include extra
>> dependencies. I’ve attached an updated patch that uses subseq from
>> cl.el. I hope that is okay.
> 
> Actually, it's part of cl-lib now (in the broadest understanding of
> cl-lib).
> 
> Since this is a bugfix I guess you should use org-sublist (*shiver*) in
> maint and cl-subseq in master.  We can’t use cl-lib in maint, right
> Nicolas?
> 
> Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:
> 
>> Anthony Cowley <acow...@gmail.com> writes:
>> 
>>> * lisp/ox-latex.el (org-latex-compile): Improve timestamp check on HFS+
>>>  filesystem by only considering 1-second clock resolution.
>>> 
>>> Previously, the call to (current-time) could return a timestamp with
>>> a non-zero microsecond or picosecond fields, while the file attribute
>>> always has zeros for these fields. The check that the generated file is
>>> newer than the reference timestamp only succeeded when the time to
>>> generate the file crossed a 1-second clock interval.
>>> 
>>> TINYCHANGE
>>> ---
>>> lisp/ox-latex.el | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
>>> index a57677b..f803b7e 100644
>>> --- a/lisp/ox-latex.el
>>> +++ b/lisp/ox-latex.el
>>> @@ -3576,7 +3576,8 @@ Return PDF file name or an error if it couldn't be 
>>> produced."
>>> ;; Check for process failure.  Provide collected errors if
>>> ;; possible.
>>> (if (or (not (file-exists-p pdffile))
>>> -   (time-less-p (nth 5 (file-attributes pdffile)) time))
>>> +   (time-less-p (subseq (nth 5 (file-attributes pdffile)) 0 2)
>>> +(subseq time 0 2)))
>> 
>> This sounds good. Thank you.
>> 
>> Although, I suggest to use `cl-subseq' instead of its alias. Also, it
>> may be worth commenting that trick right into the source.
> 
> Yes, it should.

I’ve attached two remixes of the original patch: the first uses cl-subseq, the 
second uses org-sublist.

Anthony



ox-latex-timestamp.patch
Description: Binary data


ox-latex-timestamp-maint.patch
Description: Binary data

Re: [O] [PATCH] org-latex-compile timestamp checks

[Anthony Cowley]

> On Jan 15, 2016, at 7:13 AM, Rasmus <ras...@gmx.us> wrote:
> 
> Hi Anthony,
> 
> Thanks for raising this issue.
> 
> Anthony Cowley <acow...@gmail.com> writes:
> 
>> I’ve had some trouble with toggling latex fragment previews in a
>> document on OS X. It would sometimes work, sometimes not, so I could
>> just try a few times until it worked and get on with things. Looking
>> into it more, the problem seems to be with the HFS+ filesystem’s
>> second granularity on file timestamps. The Org code checks that the
>> generated file is not older than a (current-time) obtained before
>> starting latex compilation, but the truncated time of the generated
>> file can indeed be older in the sub-second fields of the timestamp.
>> 
>> The attached patch simply compares timestamps truncated to 1-second
>> precision.
> 
> Isn't this a bug in Emacs file-attributes rather than Org?  If so, it
> should be fixed in Emacs rather than worked around in Org IMO.


Thanks for taking a look, Rasmus! The bug is in Org, not Emacs. One may perhaps 
assume the invariant that successive calls to `current-time` will return 
non-decreasing values. One might also assume the invariant that successive 
touches of different files will result in file attributes with non-decreasing 
timestamps. It is mixing the two that is the bug, and Emacs itself shouldn’t 
try to fix that. To be clear, the limiting factor in this comparison is the 
filesystem whose timestamp granularity is much coarser than the system clock.

We could do something like generate an entirely separate temporary file before 
compilation, and use its timestamp as the reference by which compilation output 
is evaluated. However, the approach of checking file freshness with a 
one-second granularity seems like a pretty good compromise.

> 
> Maybe you could just check the log directly for failures rather than
> checking the file attributes, if these are not reliable.
> 
> Also, what is the ‘take‘?  I don’t seem to have it in my Emacs…

Sorry about that. Believe it or not I had already rewritten those two lines — 
as simple as they are — trying to not include extra dependencies. I’ve attached 
an updated patch that uses subseq from cl.el. I hope that is okay.

Anthony


0001-lisp-ox-latex.el-PDF-generation-timestamp-check.patch
Description: Binary data

[O] [PATCH] org-latex-compile timestamp checks

[Anthony Cowley]

I’ve had some trouble with toggling latex fragment previews in a document on OS 
X. It would sometimes work, sometimes not, so I could just try a few times 
until it worked and get on with things. Looking into it more, the problem seems 
to be with the HFS+ filesystem’s second granularity on file timestamps. The Org 
code checks that the generated file is not older than a (current-time) obtained 
before starting latex compilation, but the truncated time of the generated file 
can indeed be older in the sub-second fields of the timestamp.

The attached patch simply compares timestamps truncated to 1-second precision. 
This does mean that there is the possibility of a false positive in the 
compilation test if a successful compilation is followed up by an unsuccessful 
compilation in less than one second. I do not know if anyone encounters such a 
scenario.

Anthony



0001-lisp-ox-latex.el-PDF-generation-timestamp-check.patch
Description: Binary data