Re: how to document/comment a complex org table formula
>>> "GdaO" == General discussions about Org-mode writes: > Limbic answer : > - create an emacs-lisp function doing what you want > - comment /ad libitum/ > - call this function in your spreadsheet. I hoped such a function already existed and somebody would point it out to me (I searched the package-list-package list but nothing came up) smime.p7s Description: S/MIME cryptographic signature
Re: export org table to other formats (gnumeric or scalc or xlsx)
>>> "TC" == Tim Cross writes: > Uwe Brauer writes: >> Hi >> >> A couple of days ago I asked about importing excel formula into org >> tables, and they only ways seems to do it manually. >> >> I just realised that I need it also the other way around, exporting to >> some spreadsheet format, like gnumerica or scalc or xlsx. >> >> But that look equally difficult, isn't. >> >> Some hints would be welcome. >> > The big problem here is that there is no single format understood by all > these different programs which you can use. While CSV works OK for data, > it does not support formulas and other meta data. In particular, > translating formulas is a real challenge. > I went down this rabbit hole some years back i.e. having a workflow > which allowed me to interact with others who used Excel and allowing me > to use org mode. > It took hours and hours of additional work and never worked reliably > because > - I never found a way of 'exporting' to a format which could be imported > by Excel and included formulas > - None of the Excel export formats support full export of Excel - > especially at the meta data level i.e. Visual Basic macros and other > 'objects'. Workbooks were a real pain. > - Constantly having to do 'hand tweaking' to fix formulas and other > 'meta' information (both directions). When exporting to Excel, I would > have to open the spreadsheet in another program to 'clean it up' > before sending it to colleagues. > - Too many different Excel versions. This issue may not be as bad now, >but back then, there were multiple xlsx versions and you would get >different results depending on the version. Thanks very much for this detailed answer. Actually only two solutions crossed my mind, one is the database approach you mentioned. The other, though much more restricted to relatively simple formulas, would require a more human readable spreadsheet formula, like SKL, or stencila https://stenci.la/blog/humane-sheets/ So the idea would be to export/import from org to SKL or stencila and then, hopefully let, excel or scalc, do the rest. By the way, although scalc is open/free software its native format is also somehow difficult to read and I presume, your description would also apply to scalc's format as well. The same might be true for gnumerics... Regards Uwe smime.p7s Description: S/MIME cryptographic signature
Re: [kisara.moe] Re: [kisara.moe] Re: Bug: async latex export fails due to post-process lambda [9.4.4 (release_9.4.4-188-ga8df76 @ /home/mohkale/.config/emacs/lisp/straight/build/org/)]
Hello, Mohsin Kaleem writes: > Hi just following up. Thanks for the heads up, but you haven't answered my question yet. Regards, -- Nicolas Goaziou
how to document/comment a complex org table formula
Limbic answer : - create an emacs-lisp function doing what you want - comment /ad libitum/ - call this function in your spreadsheet. HTH,
[kisara.moe] Re: [kisara.moe] Re: Bug: async latex export fails due to post-process lambda [9.4.4 (release_9.4.4-188-ga8df76 @ /home/mohkale/.config/emacs/lisp/straight/build/org/)]
Mohsin Kaleem writes: > Greg Minshall writes: > >> Mohsin, >> >>> Hmmm... that's strange. Running: >>> 1. `emacs -nw` >>> ... >> >> you might want to start off with >> : emacs -nw -Q >> to eliminate any dependency on your personal .emacs file, etc. > > Oh, sorry, that was supposed to be `emacs -Q` (I actually uses `emacs > -nw -Q --load quick-init.el` which uses a barebones config file that > just sets up some basic defaults (package manager, path vars, etc.)). > > I can reproduce without my main personal emacs file. > >> >> cheers, Greg Hi just following up. --- Mohsin
Re: [PATCH] make org-notify support for macOS desktop notification
I updated the patch, I found the package `osx-lib` contains solution. So I removed the directly osascript process invocation. 0001-org-clock.el-Make-org-notify-support-macOS-notificat.patch Description: Binary data > On Jul 4, 2021, at 1:48 PM, Maxim Nikulin wrote: > > On 04/07/2021 07:23, stardiviner wrote: >> I found `org-notify` does not support macOS desktop notification. So I write >> a small patch for this. > > I am surprised that there is no OS-agnostic function in Emacs that sends > simple notification, suitable when no advanced feature are necessary. Only > OS-dependent variants are implemented for Linux and Windows. > >> +(format "'display notification \"%s\" with title >> \"title\"'" notification "Org mode message"))) > > Unsafe substitution of the argument. There is no guarantee that notification > has no quote characters. I do not know, which link you would prefer: > - old https://xkcd.com/327/ "Robert'); DROP TABLE" > - recent > https://arstechnica.com/gadgets/2021/06/mass-data-wipe-in-my-book-devices-prompts-warning-from-western-digital/ > Wipe data from NAS (accordingly to some sources, device can be protected by > firewall, it is enough to open in a browser a page with a malicious src="..."> element, e.g. in a comment of an earlier visitor) > > The preferred way is to pass such parameters as separate arguments of > `start-process'. I am not familiar with osascript, I hope, it does not > additionally interpret strings passed to "display notification" to do > something fancy things. Example with sh: > > Current unsafe variant: > >> sh -c "`printf 'echo "%s: %s - %s"' 'some-command' '"; echo another action >> ; echo "' 'second arg' > With parameters passed as separate arguments to avoid interpretation of > special characters: > >> sh -c 'echo "$0: $1 - $2"' 'some-command' '"; echo another action ; echo >> "' 'second arg' > >
Re: [External] : Re: export org table to other formats (gnumeric or scalc or xlsx)
I highly recommend a recent LibreOffice. Nearly everything I do is through LibreOffice and CSV files. MS Excel has problems when using inter-field-separators such as semicolons. When I receive Excel (or other) spreadsheets from people, I must first convert them into CSV files to clear out the crazy manual formatting in order to process them content. Often a flow such as this helps: *.xlsx => *.csv => Emacs (to cleanup text, newlines, whitespace) => LibreOffice (to sort, reorder, analyze with better use of graphical realestate) => *.org tables with Emacs macros to process further => *.csv => LibreOffice to generate fresh *.xlsx Sometimes cleanup with *nix 'cut' and 'paste' tools helps greatly: - *.csv => cut -d\; -f1-3 >file1 - *.csv => cut -d\; -f4- >file2 - Edit content or add a new set of data - paste -d';' file1 file2 etc. Very powerful. On 7/4/21 5:00 PM, Tim Cross wrote: Uwe Brauer writes: Hi A couple of days ago I asked about importing excel formula into org tables, and they only ways seems to do it manually. I just realised that I need it also the other way around, exporting to some spreadsheet format, like gnumerica or scalc or xlsx. But that look equally difficult, isn't. Some hints would be welcome. The big problem here is that there is no single format understood by all these different programs which you can use. While CSV works OK for data, it does not support formulas and other meta data. In particular, translating formulas is a real challenge. I went down this rabbit hole some years back i.e. having a workflow which allowed me to interact with others who used Excel and allowing me to use org mode. It took hours and hours of additional work and never worked reliably because - I never found a way of 'exporting' to a format which could be imported by Excel and included formulas - None of the Excel export formats support full export of Excel - especially at the meta data level i.e. Visual Basic macros and other 'objects'. Workbooks were a real pain. - Constantly having to do 'hand tweaking' to fix formulas and other 'meta' information (both directions). When exporting to Excel, I would have to open the spreadsheet in another program to 'clean it up' before sending it to colleagues. - Too many different Excel versions. This issue may not be as bad now, but back then, there were multiple xlsx versions and you would get different results depending on the version. In the end, I gave up and either just used LibreOffice (Linux) or an OSX program (I think it was called numerics, but too long ago to recall accurately - it was not an Apple program). In the end, my decision was to only use org if either I only needed the data (possibly adding formulas manually), would not need to export back to Excel (no collaboration) and only need export to org once. Otherwise, use LibreOffice or another program able to understand xlsx natively. One thing which we did use for a time was to connect the excel spreadsheets with a database. The excel spreadsheet would pull the data from the database and apply formulas/macros to that data. I was then able to pull data from the database into org and then export it back into the database. It took a bit to setup - used Visual Basic to manage data import/export into database and needed an Excel based UI to do some CRUD operations and then some scripts on the Linux side to extract/update the data from org. This sort of worked, but had issues with synchronisation of data. It really needed a much more sophisticated database API to make it work well which could handle versioning or resolve data conflicts and dependencies etc. To some extent, I guess Excel is a good example of what RMS was concerned about and the problem with closed proprietary standards. While someone can reverse engineer the formats and spend the time to develop converters, they remain at the mercy of MS who can simply change the formatting at their whim. Most efforts I've seen seem to run out of puff because of the efforts needed to maintain things. Of course, life would probably be better if so many project managers stopped using Excel for EVERYTHING! I've noticed over the last 10+ years a growing use of Excel in the 'enterprise' as the default 'tool' to collect and manage information. To many, it seems like a simple solution, but in reality, you end up with all sorts of valuable information floating around in multiple spreadsheets and spend far too much time entering/updating data using a crappy interface and tweaking format commands. I've seen more than one project almost hit the rocks because someone was working off an old excel spreadsheet with the wrong data. If you raise this concern, the likely outcome is a decision to use MS Project, then your really stuffed!
Re: export org table to other formats (gnumeric or scalc or xlsx)
Uwe Brauer writes: > Hi > > A couple of days ago I asked about importing excel formula into org > tables, and they only ways seems to do it manually. > > I just realised that I need it also the other way around, exporting to > some spreadsheet format, like gnumerica or scalc or xlsx. > > But that look equally difficult, isn't. > > Some hints would be welcome. > The big problem here is that there is no single format understood by all these different programs which you can use. While CSV works OK for data, it does not support formulas and other meta data. In particular, translating formulas is a real challenge. I went down this rabbit hole some years back i.e. having a workflow which allowed me to interact with others who used Excel and allowing me to use org mode. It took hours and hours of additional work and never worked reliably because - I never found a way of 'exporting' to a format which could be imported by Excel and included formulas - None of the Excel export formats support full export of Excel - especially at the meta data level i.e. Visual Basic macros and other 'objects'. Workbooks were a real pain. - Constantly having to do 'hand tweaking' to fix formulas and other 'meta' information (both directions). When exporting to Excel, I would have to open the spreadsheet in another program to 'clean it up' before sending it to colleagues. - Too many different Excel versions. This issue may not be as bad now, but back then, there were multiple xlsx versions and you would get different results depending on the version. In the end, I gave up and either just used LibreOffice (Linux) or an OSX program (I think it was called numerics, but too long ago to recall accurately - it was not an Apple program). In the end, my decision was to only use org if either I only needed the data (possibly adding formulas manually), would not need to export back to Excel (no collaboration) and only need export to org once. Otherwise, use LibreOffice or another program able to understand xlsx natively. One thing which we did use for a time was to connect the excel spreadsheets with a database. The excel spreadsheet would pull the data from the database and apply formulas/macros to that data. I was then able to pull data from the database into org and then export it back into the database. It took a bit to setup - used Visual Basic to manage data import/export into database and needed an Excel based UI to do some CRUD operations and then some scripts on the Linux side to extract/update the data from org. This sort of worked, but had issues with synchronisation of data. It really needed a much more sophisticated database API to make it work well which could handle versioning or resolve data conflicts and dependencies etc. To some extent, I guess Excel is a good example of what RMS was concerned about and the problem with closed proprietary standards. While someone can reverse engineer the formats and spend the time to develop converters, they remain at the mercy of MS who can simply change the formatting at their whim. Most efforts I've seen seem to run out of puff because of the efforts needed to maintain things. Of course, life would probably be better if so many project managers stopped using Excel for EVERYTHING! I've noticed over the last 10+ years a growing use of Excel in the 'enterprise' as the default 'tool' to collect and manage information. To many, it seems like a simple solution, but in reality, you end up with all sorts of valuable information floating around in multiple spreadsheets and spend far too much time entering/updating data using a crappy interface and tweaking format commands. I've seen more than one project almost hit the rocks because someone was working off an old excel spreadsheet with the wrong data. If you raise this concern, the likely outcome is a decision to use MS Project, then your really stuffed! -- Tim Cross
Re: LaTeX-producing code : how to export results to HTML/ODT ?
Yes, this works, indeed.
If I could just figure why
... and how to use it with captions, labels and cross-references.
But I still don't "get" drawers, I thonk.
Thanks a lot ! You gave me somethong to think about.
Le dimanche 04 juillet 2021 à 15:04 -0400, John Kitchin a écrit :
> This incantation worked for me:
> #+name: foo
> #+begin_src emacs-lisp :exports both :results drawer
> "Pseudo-function returning a LaTeX pseudo-result."
> "\\[\\displaystyle{\\sin\\left(\\frac{a}{b}\\right)}\\]"
> #+end_src
>
> #+RESULTS: foo
> :results:
> \[\displaystyle{\sin\left(\frac{a}{b}\right)}\]
> :end:
>
> the key is the drawer I think.
> John
>
> ---
> Professor John Kitchin (he/him/his)
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
>
>
> On Sun, Jul 4, 2021 at 2:51 PM Emmanuel Charpentier
> wrote:
> > I tried this :
> >
> > #+property: header-args:sage :session
> > #+options: tex:t toc:nil author:nil
> > #+begin_src emacs-lisp :exports none
> > ;; (customize-set-variable
> > ;; 'org-latex-to-mathml-convert-command
> > ;; "latexmlmath \"%i\" --presentationmathml=%o")
> > (custom-set-variables
> > '(org-latex-to-mathml-convert-command
> > "java -jar %j -unicode -force -df %o %I")
> > '(org-latex-to-mathml-jar-file
> > "/usr/local/bin/mathtoweb.jar"))
> > #+end_src
> >
> > A "normal" function call with org result...
> >
> > #+name: foo
> > #+begin_src emacs-lisp :exports both :results org
> > "Pseudo-function returning a LaTeX pseudo-result."
> > "\\[\\displaystyle{\\sin\\left(\\frac{a}{b}\\right)}\\]"
> > #+end_src
> >
> > #+RESULTS: foo
> > #+begin_src org
> > \[\displaystyle{\sin\left(\frac{a}{b}\right)}\]
> > #+end_src
> >
> > Which exports the LaTeX *source* (uncompiled) in PDF, HTML and ODT.
> >
> > I'm currently lookin into a =:post= workaround. But an option to
> > export =latex= blocks to selected exporters (ODT, HTML, possibly
> > Morkdown via pandoc).
> >
> > I'll keep you posted.
> >
> > Le dimanche 04 juillet 2021 à 14:10 -0400, John Kitchin a écrit :
> > Can you declare the output as org so they will just be latex
> > snippets?
> >
> > On Sun, Jul 4, 2021 at 3:46 AM Emmanuel Charpentier
> > wrote:
> > > Dear list,
> > >
> > > Org-mode offers the ability to create functions returning LaTeX
> > > results : such occurrences are frequent with Sagemath, Maxima,
> > > Mathematica, R, and even emacs's Calc...
> > >
> > > Such functions can be declared has having LaTeX output, and the
> > > resulting =#+begin_export latex ... #+end_export latex= block
> > > is exported as LaTeX and end up in the PDF versin.
> > >
> > > But such blocks seem to export *only* to LaTeX/PDF ; more
> > > specically, they do not export to HTML nor ODT. In order to
> > > insert those results at export, one *has* to print them *raw*.
> > > See the attached examples, and compare PDF, HTML and ODT outputs
> > > of the enclosed zip archive (necessary to avoid the wrath of the
> > > spam filter of my provider ;-)...)..
> > >
> > > Unless I am mistaken, this is the *only* way to export LaTeX
> > > exports to HTML/ODT ; I am not aware of any option allowing to
> > > force such exports. So a couple questions :
> > > * Am I mistaken ?
> > > * Are there more steamlined ways to get LaTeX in
> > > HTML/ODF/whatever-
> > > but-not-LaTeX ?
> > > * Wouldn't an option to allow these exports be a welcome addition
> > > to
> > > the export structure (or possibly to the various exporters) ?
> > >
> > > Thanks in advance,
> >
Re: LaTeX-producing code : how to export results to HTML/ODT ?
The following does what I want : export ln a LaTeX block to latex and
beamer, export as a raw LaTeX snippet in HTML and ODT, no export
otherwise :
#+property: header-args:sage :session
#+options: tex:t toc:nil author:nil
#+begin_src emacs-lisp :exports none
;; (customize-set-variable
;; 'org-latex-to-mathml-convert-command
;; "latexmlmath \"%i\" --presentationmathml=%o")
(custom-set-variables
'(org-latex-to-mathml-convert-command
"java -jar %j -unicode -force -df %o %I")
'(org-latex-to-mathml-jar-file
"/usr/local/bin/mathtoweb.jar"))
#+end_src
#+RESULTS:
Current exporter src_emacs-lisp[:results raw]{org-export-current-backend}.
A printing auxilliary :
#+name: printme
#+begin_src emacs-lisp :exports both :var data=()
(if data
(cond ((memq org-export-current-backend '(latex beamer))
(format "#+begin_export latex\n%s\n#+end_export" data))
((memq org-export-current-backend '(odt html))
data)
(t data))
"")
#+end_src
A "normal" function call with filtered result...
#+name: foo
#+begin_src emacs-lisp :exports both :results value raw :post
printme(data=*this*)
"Pseudo-function returning a LaTeX pseudo-result."
"\\[\\displaystyle{\\sin\\left(\\frac{a}{b}\\right)}\\]"
#+end_src
Real-life test :
#+name: gee
#+begin_src sage :exports both :results raw :post printme(data=*this*)
a, b = var("a, b")
R = str(LatexExpr("\\[\\displaystyle{%s}\\]"%latex(tan(a+b) ==
tan(a+b).trig_expand(
R += "\n\n"
R += str(LatexExpr("\\[\\displaystyle{%s}\\]"%latex(tan(a-b) ==
tan(a-b).trig_expand(
LatexExpr(R)
#+end_src
But this still has snags : you must not have evaluated results in the
buffer. Which is problematic if you want to use caching... Exporting
LaTeX blocks to ODT/HTML would be a better solution...
Ideas ?
Le dimanche 04 juillet 2021 à 14:10 -0400, John Kitchin a écrit :
> Can you declare the output as org so they will just be latex
> snippets?
>
> On Sun, Jul 4, 2021 at 3:46 AM Emmanuel Charpentier
> wrote:
> > Dear list,
> >
> > Org-mode offers the ability to create functions returning LaTeX
> > results : such occurrences are frequent with Sagemath, Maxima,
> > Mathematica, R, and even emacs's Calc...
> >
> > Such functions can be declared has having LaTeX output, and the
> > resulting =#+begin_export latex ... #+end_export latex= block is
> > exported as LaTeX and end up in the PDF versin.
> >
> > But such blocks seem to export *only* to LaTeX/PDF ; more
> > specically, they do not export to HTML nor ODT. In order to insert
> > those results at export, one *has* to print them *raw*. See the
> > attached examples, and compare PDF, HTML and ODT outputs of the
> > enclosed zip archive (necessary to avoid the wrath of the spam
> > filter of my provider ;-)...)..
> >
> > Unless I am mistaken, this is the *only* way to export LaTeX
> > exports to HTML/ODT ; I am not aware of any option allowing to
> > force such exports. So a couple questions :
> > * Am I mistaken ?
> > * Are there more steamlined ways to get LaTeX in HTML/ODF/whatever-
> > but-not-LaTeX ?
> > * Wouldn't an option to allow these exports be a welcome addition
> > to
> > the export structure (or possibly to the various exporters) ?
> >
> > Thanks in advance,
how to document/comment a complex org table formula
Hi It turns out that I have to deal with a bit more complex table formula of the form #+begin_src elisp #+TBLFM: $6=if($2>10,($2-10)*@2$7,0)+ min(10,$2)*@2$2+ min(10,$3)*@2$3 + if($4>10,($4-10)*@2$7,$4)+min(10,$4)*@2$4 +@2$5*$5;f1 #+end_src Is there any way to document or comment such a formula, since I am sure that within days I don't remember why I chose that formula? Regards Uwe Brauer
Re: LaTeX-producing code : how to export results to HTML/ODT ?
This incantation worked for me:
#+name: foo
#+begin_src emacs-lisp :exports both :results drawer
"Pseudo-function returning a LaTeX pseudo-result."
"\\[\\displaystyle{\\sin\\left(\\frac{a}{b}\\right)}\\]"
#+end_src
#+RESULTS: foo
:results:
\[\displaystyle{\sin\left(\frac{a}{b}\right)}\]
:end:
the key is the drawer I think.
John
---
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
On Sun, Jul 4, 2021 at 2:51 PM Emmanuel Charpentier
wrote:
> I tried this :
>
> #+property: header-args:sage :session
>
> #+options: tex:t toc:nil author:nil
>
> #+begin_src emacs-lisp :exports none
>
> ;; (customize-set-variable
>
> ;; 'org-latex-to-mathml-convert-command
>
> ;; "latexmlmath \"%i\" --presentationmathml=%o")
>
> (custom-set-variables
>
>'(org-latex-to-mathml-convert-command
>
> "java -jar %j -unicode -force -df %o %I")
>
>'(org-latex-to-mathml-jar-file
>
> "/usr/local/bin/mathtoweb.jar"))
>
> #+end_src
>
>
> A "normal" function call with org result...
>
>
> #+name: foo
>
> #+begin_src emacs-lisp :exports both :results org
>
> "Pseudo-function returning a LaTeX pseudo-result."
>
> "\\[\\displaystyle{\\sin\\left(\\frac{a}{b}\\right)}\\]"
>
> #+end_src
>
>
> #+RESULTS: foo
>
> #+begin_src org
>
> \[\displaystyle{\sin\left(\frac{a}{b}\right)}\]
>
> #+end_src
>
>
> Which exports the LaTeX *source* (uncompiled) in PDF, HTML and ODT.
>
> I'm currently lookin into a =:post= workaround. But an option to export
> =latex= blocks to selected exporters (ODT, HTML, possibly Morkdown via
> pandoc).
>
> I'll keep you posted.
>
> Le dimanche 04 juillet 2021 à 14:10 -0400, John Kitchin a écrit :
> Can you declare the output as org so they will just be latex snippets?
>
> On Sun, Jul 4, 2021 at 3:46 AM Emmanuel Charpentier <
> emm.charpent...@free.fr> wrote:
>
> Dear list,
>
> Org-mode offers the ability to create functions returning LaTeX results :
> such occurrences are frequent with Sagemath, Maxima, Mathematica, R, and
> even emacs's Calc...
>
> Such functions can be declared has having LaTeX output, and the resulting
> =#+begin_export latex ... #+end_export latex= block is exported as LaTeX
> and end up in the PDF versin.
>
> But such blocks seem to export **only** to LaTeX/PDF ; more specically,
> they do not export to HTML nor ODT. In order to insert those results at
> export, one **has** to print them **raw**. See the attached examples, and
> compare PDF, HTML and ODT outputs of the enclosed zip archive (necessary to
> avoid the wrath of the spam filter of my provider ;-)...)..
>
> Unless I am mistaken, this is the *only* way to export LaTeX exports to
> HTML/ODT ; I am not aware of any option allowing to force such exports. So
> a couple questions :
>
>- Am I mistaken ?
>- Are there more steamlined ways to get LaTeX in
>HTML/ODF/whatever-but-not-LaTeX ?
>- Wouldn't an option to allow these exports be a welcome addition to
>the export structure (or possibly to the various exporters) ?
>
>
> Thanks in advance,
>
>
>
Re: LaTeX-producing code : how to export results to HTML/ODT ?
I tried this :
#+property: header-args:sage :session
#+options: tex:t toc:nil author:nil
#+begin_src emacs-lisp :exports none
;; (customize-set-variable
;; 'org-latex-to-mathml-convert-command
;; "latexmlmath \"%i\" --presentationmathml=%o")
(custom-set-variables
'(org-latex-to-mathml-convert-command
"java -jar %j -unicode -force -df %o %I")
'(org-latex-to-mathml-jar-file
"/usr/local/bin/mathtoweb.jar"))
#+end_src
A "normal" function call with org result...
#+name: foo
#+begin_src emacs-lisp :exports both :results org
"Pseudo-function returning a LaTeX pseudo-result."
"\\[\\displaystyle{\\sin\\left(\\frac{a}{b}\\right)}\\]"
#+end_src
#+RESULTS: foo
#+begin_src org
\[\displaystyle{\sin\left(\frac{a}{b}\right)}\]
#+end_src
Which exports the LaTeX *source* (uncompiled) in PDF, HTML and ODT.
I'm currently lookin into a =:post= workaround. But an option to export
=latex= blocks to selected exporters (ODT, HTML, possibly Morkdown via
pandoc).
I'll keep you posted.
Le dimanche 04 juillet 2021 à 14:10 -0400, John Kitchin a écrit :
Can you declare the output as org so they will just be latex snippets?
On Sun, Jul 4, 2021 at 3:46 AM Emmanuel Charpentier
wrote:
> Dear list,
>
> Org-mode offers the ability to create functions returning LaTeX
> results : such occurrences are frequent with Sagemath, Maxima,
> Mathematica, R, and even emacs's Calc...
>
> Such functions can be declared has having LaTeX output, and the
> resulting =#+begin_export latex ... #+end_export latex= block is
> exported as LaTeX and end up in the PDF versin.
>
> But such blocks seem to export *only* to LaTeX/PDF ; more specically,
> they do not export to HTML nor ODT. In order to insert those results
> at export, one *has* to print them *raw*. See the attached examples,
> and compare PDF, HTML and ODT outputs of the enclosed zip archive
> (necessary to avoid the wrath of the spam filter of my provider ;-
> )...)..
>
> Unless I am mistaken, this is the *only* way to export LaTeX exports
> to HTML/ODT ; I am not aware of any option allowing to force such
> exports. So a couple questions :
> * Am I mistaken ?
> * Are there more steamlined ways to get LaTeX in HTML/ODF/whatever-
> but-not-LaTeX ?
> * Wouldn't an option to allow these exports be a welcome addition to
> the export structure (or possibly to the various exporters) ?
>
> Thanks in advance,
Re: LaTeX-producing code : how to export results to HTML/ODT ?
Can you declare the output as org so they will just be latex snippets? On Sun, Jul 4, 2021 at 3:46 AM Emmanuel Charpentier wrote: > Dear list, > > Org-mode offers the ability to create functions returning LaTeX results : > such occurrences are frequent with Sagemath, Maxima, Mathematica, R, and > even emacs's Calc... > > Such functions can be declared has having LaTeX output, and the resulting > =#+begin_export latex ... #+end_export latex= block is exported as LaTeX > and end up in the PDF versin. > > But such blocks seem to export **only** to LaTeX/PDF ; more specically, > they do not export to HTML nor ODT. In order to insert those results at > export, one **has** to print them **raw**. See the attached examples, and > compare PDF, HTML and ODT outputs of the enclosed zip archive (necessary to > avoid the wrath of the spam filter of my provider ;-)...).. > > Unless I am mistaken, this is the *only* way to export LaTeX exports to > HTML/ODT ; I am not aware of any option allowing to force such exports. So > a couple questions : > >- Am I mistaken ? >- Are there more steamlined ways to get LaTeX in >HTML/ODF/whatever-but-not-LaTeX ? >- Wouldn't an option to allow these exports be a welcome addition to >the export structure (or possibly to the various exporters) ? > > > Thanks in advance, > -- John --- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: using previous =#+results= when =:eval never=
> On Jul 3, 2021, at 10:19 PM, Greg Minshall wrote: > > Chuck, > > thanks. (i'm not surprised at an e-lisp suggestion from you! :) > > i worry about accidental modification of the base case results during > the chaos of development. it occurs to me (reading through > (org-babel-ref-resolve)) to keep my base case source blocks marked with > [:results silent], which should prevent accidental modification. (*) > This seems unnecessary. Be warned that the behavior of `org-babel-update-intermediate` is not intuitive - at least to me. My reading of the doctstring is that the result of a named src block can be changed when it is non-nil. AFAICS, this never happens. Instead, the return value from `org-babel-ref-resolve` is copied from the named result. For your ECM, after deleting the `:eval never`, if I append `+ 1` to the `mtcars[1:3,]` and execute then next src block, I get #+begin_src emacs-lisp (compare-old-to-new "testcountsdecompose") #+end_src #+RESULTS: : Comparison failed for block testcountsdecompose and the original in-buffer value did not change. I can remove the `+ 1` and rerun the above block and the result is `t` HTH, Chuck > then, i would change [:results silent] to, e.g., [:results silentx], in > the base case source blocks whenever i wanted to re-create those > results. > > for, e.g., inspecting the results when things differ, it would be nice > to stay in the language of the rest of the code. but i suspect i'll be > able to do some e-lisp magic on the RHS of a :var, e.g., crudely > > : #+begin_src R :var basecaseresults=(org-babel-read-named-result > "testcountsdecompose") > > i'll play around with it. (i suspect i'll be motivated to use an e-lisp > macro, to eliminate the quotes, for example.) > > again, thanks. > > cheers, Greg > > (*) this relies on current org-mode behavior, where > (org-babel-read-result) will return results from a result block from a > source block marked [:results silent]. i have no idea how likely this > behavior is to change in the long run.
Re: modify citation links in a derived HTML backend
On Sun, Jul 4, 2021 at 8:56 AM Jens Lechtenboerger < lech...@wi.uni-muenster.de> wrote: > On 2021-07-03, Matt Price wrote: > > > I've added some comments in the issue you linked to, but in the meantime > > I've also come up with what seems to be at least a semi-viable hack for > > adding native CSL citation support to org-re-reveal. It involves creating > > two new variables and then let-setting `citeproc-fmt--formatters-alist` > in > > `org-re-reveal-export-to-html`. Something similar could presumably be > done > > in other derived backends. > > > > I find it quite hackish and I don't know whether perhaps some more > general > > solution could be found, but in any case here is the code, which I have > > inserted into org-re-reveal.el locally: > > Thank you for sharing your code, Matt! > > What is the general state of this new citation handling with respect > to export backends? Did you create the settings for HTML from > scratch or did you take inspiration from HTML export functionality? > I guess that basic support should go into ox-html, while small > modifications could than take care of specifics for reveal.js > presentations... > > Best wishes > Jens > Thanks Jens! So, there is a rather complicated chain of dependencies and I'm not sure how best to procee in the specific case of org-re-reveal. Here is how I understand the current state of affairs (and I think Bruce, Nicolas, and Andras are all likely to have corrections to my explanation): - the new syntax and processors are available in the wip-cite-new branch of hte org git repo, and will likely be merged into the master branch pretty soon. - at present, and likely for some time, the best citation processor for html export is defined in `oc-csl.el` and relies on the citeproc-el library. My code will only have an effect if the org file contains lines like -- #+bibliography: food-studies.bib #+cite_export: csl "/home/matt/src/styles/chicago-author-date-mod.csl" - oc-csl.el relies on citeproc-el to actually process the citations. - citeproc-el is a fairly complex package with many moving parts. It supports processing of citations in html and latex backends, but not in any others (I think this is right!) - citation formatting is handled in the file citation-formatters. el ( https://github.com/andras-simonyi/citeproc-el/blob/master/citeproc-formatters.el), which, importantly, uses lexical binding. That file defines: - a *structure* citeproc-formatter ( https://github.com/andras-simonyi/citeproc-el/blob/0857973409e3ef2ef0238714f2ef7ff724230d1c/citeproc-formatters.el#L35 ), - a *function* citeproc-formatter-fun-create ( https://github.com/andras-simonyi/citeproc-el/blob/0857973409e3ef2ef0238714f2ef7ff724230d1c/citeproc-formatters.el#L51 ) - a *constant* citeproc-fmt--html-alist ( https://github.com/andras-simonyi/citeproc-el/blob/0857973409e3ef2ef0238714f2ef7ff724230d1c/citeproc-formatters.el#L142 ) - and a *variable* citeproc-fmt--formatters-alist ( https://github.com/andras-simonyi/citeproc-el/blob/0857973409e3ef2ef0238714f2ef7ff724230d1c/citeproc-formatters.el#L232) that creates a set of formatters using citeproc-formmater-fun-create, bassing it the value of citeproc-fmt--html-alist as raw material for the html formatter. The latter is what we need to change for our export -- we want to change just one of the lambda functions used by the formatter for the duration of export, without updating the global value of citeproc-fmt--formatters-alist. Because all these variables are lexically bound -- making the resultant closure values pretty confusing for me to inspect -- and because the process of creating a formatter is a bit complex, I was a little confused about how best to modify the code, and I'm still not quite sure how to go about it. It's pretty easy to do this using the dash library: - (let ((org-re-reveal-citeproc-fmt-alist (--map-when (eq (car it) 'cited-item-no) `(cited-item-no . ,(lambda (x y) (concat "" x ""))) citeproc-fmt--html-alist))) [do some exporting stuff]) --- or just - (defcustom org-re-reveal-citeproc-fmt-alist (--map-when (eq (car it) 'cited-item-no) `(cited-item-no . ,(lambda (x y) (concat "" x ""))) citeproc-fmt--html-alist) :group org-re-reveal :type alist) -- But I'm not sure how best to do it without that. In any case, the code I have provided here and in gitlab ( https://gitlab.com/oer/org-re-reveal/-/merge_requests/33) is quite hackish and doubtless likely to error out in many circumstances. Probably I should, in org-re-reveal-export-to-html, at least test if the function citeproc-formatter-fun-create is bound, so: -- (let ((citeproc-fmt--formatters-alist (and (functionp 'citeproc-formatter-create) `((html . ,(citeproc-formatter-create :rt (citeproc-formatter-fun-create org-re-reveal-citeproc-fmt-alist) :bib #'citeproc-fmt--htm
bug#12972: [PATCH] Avoid regression in mailcap-view-file similar to Bug#44824
> From: Maxim Nikulin > Date: Sun, 4 Jul 2021 20:37:24 +0700 > > I admit that I wrongly added ":noquery t", for some reason I believed > that it allows to choose whether processes are allowed to exist longer > than emacs or it is preferred to kill them with emacs. Actually > asynchronous processes are killed always and the option manages the > query only. This option should be dropped to restore compatibility with > previous variant. > > I have not found a way to detach asynchronous process from emacs. > Surprisingly it is possible for synchronous processes but it is > impossible to detect failure (thus to allow a user to figure out what > has happened) > > (process-file-shell-command command nil 0 nil) > > So process API in emacs is a kind of a short blanket. > > Accidentally I have created an example of program that is incompatible > with 'pipe asynchronous processes in emacs > > #!/bin/sh > exec 1>&- > exec 2>&- > sleep 30 > > (let ((command "cpu-stress-test") >(process-connection-type nil)) >(start-process-shell-command command nil command)) > > And emacs (at least 26.3) consumes 100% CPU for the specified amount of > time. I do not see any reason to do so since the program does not do > anything ugly. I have not found a way to explicitly force emacs to close > pipes. That is why I consider it as an outstanding bug. Emacs must > properly handle closed pipes. > > So `process-file-shell-command' ... 0 is better than current > `start-process-shell-command' but it does not allow to add error handling. > > So besides that I still have no guess what problem you suspect, now I > know that emacs may become mad in response to purely innocent action of > a child process. Sorry, I'm not sure I understand what this is all about. Are you still talking about the patch you proposed?
bug#12972: [PATCH] Avoid regression in mailcap-view-file similar to Bug#44824
On 03/07/2021 18:56, Eli Zaretskii wrote: From: Maxim Nikulin Date: Sat, 3 Jul 2021 18:29:30 +0700 I am giving up with this issue. That's too bad. I see no reason to give up, and I urge you to reconsider, please. Sorry, but the space of your assumptions and maybe confusions has too high number of dimension to realize what you actually mean and what you consider as a problem that should be fixed. So any further steps are impossible. Your patch unconditionally assumes that every handler will immediately exit, and that it doesn't care about the connection type with the parent Emacs process, but that is not guaranteed to be true. There is no intention of such assumption and it *works* even for handlers that does not exit immediately. I admit that I wrongly added ":noquery t", for some reason I believed that it allows to choose whether processes are allowed to exist longer than emacs or it is preferred to kill them with emacs. Actually asynchronous processes are killed always and the option manages the query only. This option should be dropped to restore compatibility with previous variant. I have not found a way to detach asynchronous process from emacs. Surprisingly it is possible for synchronous processes but it is impossible to detect failure (thus to allow a user to figure out what has happened) (process-file-shell-command command nil 0 nil) So process API in emacs is a kind of a short blanket. Accidentally I have created an example of program that is incompatible with 'pipe asynchronous processes in emacs #!/bin/sh exec 1>&- exec 2>&- sleep 30 (let ((command "cpu-stress-test") (process-connection-type nil)) (start-process-shell-command command nil command)) And emacs (at least 26.3) consumes 100% CPU for the specified amount of time. I do not see any reason to do so since the program does not do anything ugly. I have not found a way to explicitly force emacs to close pipes. That is why I consider it as an outstanding bug. Emacs must properly handle closed pipes. So `process-file-shell-command' ... 0 is better than current `start-process-shell-command' but it does not allow to add error handling. So besides that I still have no guess what problem you suspect, now I know that emacs may become mad in response to purely innocent action of a child process.
Re: modify citation links in a derived HTML backend
On 2021-07-03, Matt Price wrote: > I've added some comments in the issue you linked to, but in the meantime > I've also come up with what seems to be at least a semi-viable hack for > adding native CSL citation support to org-re-reveal. It involves creating > two new variables and then let-setting `citeproc-fmt--formatters-alist` in > `org-re-reveal-export-to-html`. Something similar could presumably be done > in other derived backends. > > I find it quite hackish and I don't know whether perhaps some more general > solution could be found, but in any case here is the code, which I have > inserted into org-re-reveal.el locally: Thank you for sharing your code, Matt! What is the general state of this new citation handling with respect to export backends? Did you create the settings for HTML from scratch or did you take inspiration from HTML export functionality? I guess that basic support should go into ox-html, while small modifications could than take care of specifics for reveal.js presentations... Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
export org table to other formats (gnumeric or scalc or xlsx)
Hi A couple of days ago I asked about importing excel formula into org tables, and they only ways seems to do it manually. I just realised that I need it also the other way around, exporting to some spreadsheet format, like gnumerica or scalc or xlsx. But that look equally difficult, isn't. Some hints would be welcome. Regards Uwe Brauer
Re: how to add a range of columns
>>> "ESF" == Eric S Fraga writes: > On Friday, 2 Jul 2021 at 20:56, Uwe Brauer wrote: >> Now I want to add also result and new, but only the first two rows, the >> only way to do it seems to be your original approach. > At this point, you need to start using more advanced formulas, > e.g. involving conditionals, maybe. You could do arithmetic on the > column and row indices ($# and @# respectively) and apply a specific > formula if the right conditions are met. Right, I just realised that I can have recursion in conditionals, which is a great help. I did not realise that before. smime.p7s Description: S/MIME cryptographic signature
LaTeX-producing code : how to export results to HTML/ODT ?
Dear list, Org-mode offers the ability to create functions returning LaTeX results : such occurrences are frequent with Sagemath, Maxima, Mathematica, R, and even emacs's Calc... Such functions can be declared has having LaTeX output, and the resulting =#+begin_export latex ... #+end_export latex= block is exported as LaTeX and end up in the PDF versin. But such blocks seem to export *only* to LaTeX/PDF ; more specically, they do not export to HTML nor ODT. In order to insert those results at export, one *has* to print them *raw*. See the attached examples, and compare PDF, HTML and ODT outputs of the enclosed zip archive (necessary to avoid the wrath of the spam filter of my provider ;- )...).. Unless I am mistaken, this is the *only* way to export LaTeX exports to HTML/ODT ; I am not aware of any option allowing to force such exports. So a couple questions : * Am I mistaken ? * Are there more steamlined ways to get LaTeX in HTML/ODF/whatever- but-not-LaTeX ? * Wouldn't an option to allow these exports be a welcome addition to the export structure (or possibly to the various exporters) ? Thanks in advance, <>
