Re: 9.5: coping with loss of ditaa.jar
> Jarmo Hurri writes: > 3. Copy ditaa.jar from previous version of org. Works in the short > run, but I do not think we want to advocate this: "We took > ditaa.jar out of org, so you will want to download an earlier > version of org to make ditaa work." Not true. I use Org mode version 9.5 (release_9.5-91-gf5faff) with a previous org-mode ditaa.jar and have no issues.
Re: 9.5: coping with loss of ditaa.jar
Greetings. Let me collect the suggested responses with their merits and potential issues. 1. Use ditaa.jar that comes with your operating system. Perfect if this works. Seems to work e.g. in Debian, does not seem to work with Fedora. Perhaps because one is a standalone library and the other one is not. Could also be a version number issue. 2. Use the program "ditaa" (not ditaa.jar) that comes with your operating system. This _may_ work, but I have not been able to misuse the settings in ob-ditaa widely enough yet to create a working solution. 3. Copy ditaa.jar from previous version of org. Works in the short run, but I do not think we want to advocate this: "We took ditaa.jar out of org, so you will want to download an earlier version of org to make ditaa work." 4. Use precompiled binary ditaa.jar from some site. Will probably work, but me and some other paranoids try to avoid using binaries from sources which we do not consider reliable. 5. Compile ditaa.jar yourself. At least for me, does not work at the moment. To summarize: on Fedora, no working long-term solution so far. Have fun and stay safe, Jarmo
Re: how to export to odt with 11 or 10 pt fonts? Default font setting
copropriete27ruemo...@gmail.com writes: > Unless you insist on using Computer Modern with a word processing > programm (yes, it can be done, at least with the OTF versions of these > fonts), or Times New Roman/Cambria with LaTeX (again possible thanks to > their OTF incarnation) and slaving to force LaTeX choices on Word (or > Word choices on LaTeX, much harder and probably abysmally stupid), your > resulting documents will vary for much larger reasons : floats > handling, table structures, layout structure, different ligatures, > different kernings, etc... It is not enough to use the same font nor the same font technology (otf). In my previous post I referred to microtypegraphical processes that influence drastically the formal aspect, regardless of the font and the 'glyph level', layout, and other macro typographycal elements. Word processors do not have the TeX line breaking algorithm, for example, nor the horizontal scaling and optical margin alignment properties that were first implemented in pdfTeX (these properties are based on the theories of Herman Zapf on the Gutenberg Bible and were implemented for the first time in an experimental software older than TeX called hz-program). That is why I always recommend that documents made in a word processor are never fully justified: word processors *do not know how to justify* (HTML also does not know how to do it) and the result is usually bad and full of rivers. And there is the fact also that word processors work on postscript points. As I said in the previous message, there are many more factors, but these merely physical (and 'invisible') factors are important. Even software like Adobe InDesign, which implements the TeX algorithm and the microtype properties of Zapf (in a rather sloppy way, since it does so with generic values applied to the character and not to the glyph) does not achieve the precision of TeX; therefore, there may be variations. In any case, I am talking about processes at the lowest level (microtypographical). Generally speaking, word processors cannot imitate TeX. But TeX can imitate word: just disable TeX algorithm (\sloppypar) and use postscript points values. But, except as an experiment, it doesn't make much sense... > BTW: since most of what is typeset nowadays will be used as PDF, HTML > and/or epub (and paper-printed only for archival purposes), it is high > time to revisit typography funamentals (currently based on more than 5 > centuries of use of the *physics* of the "paper" medium) to adapt them > to the physics of computer display and the physiology of human reading > of this new medium (which is *not* the same as "paper" reading). The PDF format has evolved a lot since the 90s, but it is still, in essence, 'printed paper that you can see on screen', device independent. Paradoxically, it was a revolution in printing, and it was of crucial importance in the extinction of the old photomechanical printing methods, which were complex and extremely expensive. As for the relationship of typography with digital media, or new media, that is a long topic. But, in any possible medium, I think that what Stanley Morison (author of Times Roman) said will always prevail in good typography: #+begin_quote Typography is the efficient means to an essentially utilitarian and only accidentally aesthetic end, for the enjoyment of patterns is rarely the reader’s chief aim. Therefore, any disposition of printing material which, whatever the intention, has the effect of coming between the author and the reader is wrong. #+end_quote Best regards, Juan Manuel
Re: How to retrieve ALL the information of an Org table ?
Emmanuel Charpentier writes: > Passing this table as an argument to source code loses the hlines : > #+begin_src emacs-lisp :exports results :results drawer :var foo=ttest > foo > #+end_src I think you are looking for ":hlines yes" header arg (the default is no) Best, Ihor
Re: test-org-cite/list-citations failure
Hello, Kyle Meyer writes: > It looks like this commit introduced a test failure. Fixed. Thank you. Regards, -- Nicolas Goaziou
How to retrieve ALL the information of an Org table ?
Dear list,
I have problems with exploiting programatically the structure of an Org
table :
I want to write function acting on complex tables, where the original
information is presented along various statistics. My idea is to
isolate the original information in a range delimited (by convention)
by the first and second hlines and by the first and last columns ; the
function should accept the whole table and retrieve the original
data. The point is that the function should accept a variable number of
lines in both the "original data" range and the summary information.
Let ttest such a table with hlines :
#+name: ttest
| ttest | c1 | c2 | rSum |
|---+++--|
| 3 | 3 | 5 | 8 |
| 8 | 8 | 12 | 20 |
|---+++--|
| cSum | 11 | 17 | 28 |
#+TBLFM: @>$2..@>$>=vsum(@I..@II)::@2..@>>$4=vsum($<<..$>>)
ttestc1c2rSum3358881220cSum111728
Passing this table as an argument to source code loses the hlines :
#+begin_src emacs-lisp :exports results :results drawer :var foo=ttest
foo
#+end_src
((ttest c1 c2 rSum) (3 3 5 8) (8 8 12 20) (cSum 11 17 28))
The structure allowing to retrieve the original data is lost.
The point is that the source code can't exploit the hlines to find
relevant information (in the present case, the lines between the
hlines).
Alternatively, one may try and pass the relevant range, using foo=(org-
table-get-remote-range "ttest" "@I$<<..@II$>>") as an argument. This
fails for a different reason :
#+begin_src emacs-lisp :exports results :results drawer :var foo=(org-
table-get-remote-range "ttest" "@I$<<..@II$>>")
foo
#+end_src
(3 5 8 12)
Again, the structure is lost : this time, foo is a "flattened" vector,
whose matricial shape is lost to the processing function.
I am looking for explanations and/or hints.
Attached : the source of the present mail.
Thanks in advance...
--
Emmanuel Charpentier
#+options: author:nil toc:nil
#+property: header-args:python :session
# #+latex_header: \usepackage{minted}
#+begin_src emacs-lisp :exports none
(setq org-odt-preferred-output-format "docx"
org-latex-to-mathml-convert-command
"latexmlmath \"%i\" --presentationmathml=%o"
;; org-latex-listings 'minted
org-latex-listings nil
org-latex-pdf-process
(list "latexmk -pdf -pdflatex='%latex -interaction=nonstopmode
-shell-escape' -bibtex -f %f"))
#+end_src
#+RESULTS:
| latexmk -pdf -pdflatex='%latex -interaction=nonstopmode -shell-escape'
-bibtex -f %f |
Dear list,
I have problems with exploiting /programatically/ the structure of an Org table
:
I want to write function acting on complex tables, where the original
information is presented along various statistics. My idea is to isolate the
original information in a range delimited (by convention) by the first and
second hlines and by the first and last columns ; the function should accept
the whole table and retrieve the original data. /The point is that the function
should accept a variable number of lines in both the "original data" range and
the summary information./
Let =ttest= such a table with =hlines= :
#+begin_src org :eval yes :exports both :results replace
,#+name: ttest
| ttest | c1 | c2 | rSum |
|---+++--|
| 3 | 3 | 5 |8 |
| 8 | 8 | 12 | 20 |
|---+++--|
| cSum | 11 | 17 | 28 |
,#+TBLFM: @>$2..@>$>=vsum(@I..@II)::@2..@>>$4=vsum($<<..$>>)
#+end_src
#+RESULTS:
#+name: ttest
| ttest | c1 | c2 | rSum |
|---+++--|
| 3 | 3 | 5 |8 |
| 8 | 8 | 12 | 20 |
|---+++--|
| cSum | 11 | 17 | 28 |
#+TBLFM: @>$2..@>$>=vsum(@I..@II)::@2..@>>$4=vsum($<<..$>>)
Passing this table as an argument to source code loses the hlines :
#+begin_src org :eval yes :exports both :results replace
,#+begin_src emacs-lisp :exports results :results drawer :var foo=ttest
foo
,#+end_src
#+end_src
The structure allowing to retrieve the original data is lost.
The point is that the source code can't exploit the hlines to find relevant
information (in the present case, the lines between the hlines).
Alternatively, one may try and pass the relevant range, using
=foo=(org-table-get-remote-range "ttest" "@I$<<..@II$>>")= as an argument. This
fails for a different reason :
#+begin_src org :eval yes :exports both :results replace
,#+begin_src emacs-lisp :exports results :results drawer :var
foo=(org-table-get-remote-range "ttest" "@I$<<..@II$>>")
foo
,#+end_src
#+end_src
Again, the structure is lost : this time, =foo= is a "flattened" vector, whose
matricial shape is lost to the processing function.
I am looking for explanations and/or hints.
# Local Variables:
# org-latex_listings: nil
# End:
test-org-cite/list-citations failure (was: Citation not inserted as 1st item in footnote ...)
Hi Nicolas,
Nicolas Goaziou writes:
> Nicolas Goaziou writes:
>
>> This allows one to insert a citation in the middle of the citation
>> number, which is not desirable either. IOW, an additional check is
>> required.
>
> I think this is now fixed. Thank you.
It looks like this commit introduced a test failure. Starting with
7d22dca54 (oc: Fix citations in footnotes when using biblatex back-end,
2021-10-06), test-org-cite/list-citations fails on my end (Emacs 27.2):
--8<---cut here---start->8---
Test test-org-cite/list-citations condition:
(ert-test-failed
((should
(equal '...
(org-test-with-parsed-data "Text[fn:1]
[fn:1] [fn:2][cite:@a]
[fn:2] [cite:@b]" ...)))
:form
(equal
("b" "a")
("a"))
:value nil :explanation
(proper-lists-of-different-length 2 1
("b" "a")
("a")
first-mismatch-at 0)))
FAILED 1/1 test-org-cite/list-citations (0.015186 sec)
--8<---cut here---end--->8---
Re: [BUG] org-save-all-org-buffers reapplies startup visibility [9.5 (release_9.5 @ /usr/local/share/emacs/29.0.50/lisp/org/)]
No Wayman writes: > Subject: [PATCH] lisp/org.el: (org-save-all-org-buffers): Prevent `org-mode' > reload > > * lisp/org.el: (org-save-all-org-buffers): Ensure `save-some-buffers' PRED > returns boolean. > > As of this upstream commit: > > https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a9ad3d477441feefa3bf6107d58281cb64e0e78a > > `save-some-buffers' will call its PRED argument if it returns a function. > Since (derived-mode-p 'org-mode) returns the symbol org-mode, > and org-mode is a function, org-mode is reloaded in modified Org > buffers when calling `org-save-all-org-buffers'. Among other > undesirable behavior, this will cause the buffer's visibility to be > reset to its initial visibility. Thanks for the analysis and fix. To git.savannah.gnu.org:/srv/git/emacs/org-mode.git 11f450da8..b71474ff7 bugfix -> bugfix
Re: [BUG] org-save-all-org-buffers reapplies startup visibility [9.5 (release_9.5 @ /usr/local/share/emacs/29.0.50/lisp/org/)]
It works on my system with native compilation on macOS 11.6. I made the change to org.el that is in my local clone of the emacs master branch and recompiled. Looking at the Help for the function, I see it is native compiled Lisp in my test here. - *Help* - buffer org-save-all-org-buffers is an interactive native compiled Lisp function in ‘org.el’. (org-save-all-org-buffers) — - diff - Save all Org buffers without user confirmation. modified lisp/org/org.el @@ -15362,7 +15362,7 @@ org-save-all-org-buffers "Save all Org buffers without user confirmation." (interactive) (message "Saving all Org buffers...") - (save-some-buffers t (lambda () (derived-mode-p 'org-mode))) + (save-some-buffers t (lambda () (and (derived-mode-p 'org-mode) t))) (when (featurep 'org-id) (org-id-locations-save)) (message "Saving all Org buffers... done")) > On Oct 9, 2021, at 9:38 AM, No Wayman wrote: > > > Your analysis is correct. I looked into this a couple days ago. > See the following message for an explanation and a patch (testing > appreciated): > > https://list.orgmode.org/87zgrmc2rg@gmail.com/T/#m9888bc09d77d7bba70ba99671aca72446c4d41b9 > >
Re: [BUG] org-save-all-org-buffers reapplies startup visibility [9.5 (release_9.5 @ /usr/local/share/emacs/29.0.50/lisp/org/)]
Your analysis is correct. I looked into this a couple days ago. See the following message for an explanation and a patch (testing appreciated): https://list.orgmode.org/87zgrmc2rg@gmail.com/T/#m9888bc09d77d7bba70ba99671aca72446c4d41b9
9.5 not yet on org elpa?
The docs say that the last version that will be on org elpa will be 9.5, but it looks like the September 20th build was the last one, which seems to be 9.4? I've managed to switch to gnu elpa. There are some challenges there because package.el thinks 9.5 is less than 20210920.
Re: Release 9.5
Merçi beaucoup Bastien! One of those who does not contribute to the code but loves Orgmode El jue, 30-09-2021 a las 13:11 +0530, Pankaj Jangid escribió: > Bastien writes: > > > Org 9.5 is out, available from GNU ELPA. > > > > Thanks a lot to every contributor. > > > > Thanks a lot for your work, Bastien. I want to thank all the > contributors. > > One Q: what is the schedule for 9.5 to be included in Emacs-28? > > Regards ~Pankaj > >
Re: [ANN] New `bibtex' citation processor
> Nicolas Goaziou writes: > Hello, I just added the no-thrill "oc-bibtex" citation processor, > which relies on the standard "\cite" and "\nocite" LaTeX > commands. It only supports citation suffixes. > Regards, -- Nicolas Goaziou Great. Thanks Nicolas. Best wishes, Colin Baxter.
Re: Citations: Locale specific adaptions?
Am Freitag, dem 08. Oktober 2021 schrieb Nicolas Goaziou: > Meanwhile, the `csl' processor is copiously documented in the > "Commentary" section of the "oc-csl.el" file. Thanks for the heads-up. Next time I will take a look there as well. -quintus -- Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite Passau, Deutschland | kont...@guelker.eu| O<
