Re: [O] Export tables as matrices (change tbl-export function on the fly)
Rasmus ras...@gmx.us writes:
Sorry; you posted a code first which didn't work at all for me; I
tried to fix it, and I posted a code which I though worked but in the
end it didn't. Thus, I though it would be fair to post another
message stating this, if nothing else than for future viewers.
I meant: what is the exact problem with my code (with examples and
expected output if possible)? It shouldn't be hard to fix.
- PROPOSAL: New option(s)for ATTR_LATEX
- :type :: options a lisp translation function or key words
associated with a lisp list translation function.
Forget the lisp translation function. At this level, the function
operates on parsed data. It doesn't use any orgtbl-to-* function. Also,
even if the ATTR_LATEX keyword applies on the table, it also affects how
`table-row' elements and `table-cell' objects are transcoded.
The usual way to define a new transcoder in the new export API is to
create a derived backed using an alternative translation table. It is
easier than it sounds.
- Default keyword: table; other known keywords: matrix
- table: current exporter
- matrix: exports to LaTeX matrix determined by the variable
org-export-latex-tables-matrix-default-type or :matrix-type.
Default is: bmatrix or pmatrix (probably bmatrix).
- in general array requires more configuration, but for me
array need not be supported.
I suggest to use a :math-mode t. With this mode, all cells are treated
as raw math code (no transformation is made on any cell). A global
variable can also set it `org-export-latex-table-math-mode' (default to
nil).
Then, the :environment keyword can be set to tabular, longtable,
tabularx, tabulary, bmatrix, pmatrix, vmatrix, kbordermatrix
or qbordermatrix. bordermatrix, array... It would default to
`org-e-latex-default-table-environment' (default to tabular).
- Matrix relevant keywords :: are the following
- If the additional variable ALIGN is set to k ∈ {l,r,c} use
the starred version of
org-export-latex-tables-matrix-default-type or :matrix-type
What is the variable ALIGN? You mean :align keyword? Do matrix
environments accept alignment? Also I haven't heard about starred
version of these. What do they do?
- If the additional keyword :bordered is t use the typeset
the matrix as \borderedmatrix{col1
... colN\\row1...\\...\\rowN}. A better example is
here ¹. Also, the default bordermatrix macro is determined
via org-export-latex-tables-matrix-bordered-type s.t. one
can specify kbordermatrix ² or qbordermatrix ³.
From the syntax perspective, I see no difference between bordered
matrices and the others: they just use a different environment, which
can be provided through :environment keyword. Am I missing something?
Perhaps Org automatically add the respective usepackage if this
option is set to something different from bordermatrix (i.e.
org-export-latex-tables-matrix-bordered-type is a list of lists
where the first element of a list is the macro name and the
second is the needed package).
The backend never adds any usepackage automatically. It is a can of
worms (incompatibilities, order of packages...). It's the responsibility
of the user to do so.
- If :matrix-pre string is set string is typeset before
the matrix
- If :matrix-post string is set then string is typeset
after the matrix.
- Alternatively, CAPTION could be used, but it seems weird.
Are they written before or after the matrix? I'd prefer
CAPTIONs to be ignored typeset when matrices are typeset.
- If the table has a name the matrix is typeset using
equation and given an label. If not it may be typeset
using equation* or \[·\].
Good idea.
- Potentially: an :inline exists s.t. if inline is t the
matrix is typeset inline [i.e. with \(\)]. Perhaps, it
should be smart and use the small verison of
org-export-latex-tables-matrix-default-type. I.e. if
bmatrix use bsmallmatrix. This could be set via
org-export-latex-tables-matrix-inline-small.
Do all matrix environments accept a small counterpart?
Regards,
--
Nicolas Goaziou
Re: [O] [org-e-texinfo] generate menu items
t...@tsdye.com (Thomas S. Dye) writes: Nicolas Goaziou n.goaz...@gmail.com writes: That's a bit of work, because, so far, node-property values are not parsed. So it would require to define a new class of node-properties: those with a parsed value. But then, how to decide which properties have their value parsed are parsed and which have not? Thanks for the information and explanation. Back-end-specific properties should work nicely in this case. I'll wait to see what Jonathan thinks about the original query. Assuming :EXPORT_TITLE:, :EXPORT_AUTHOR:, :EXPORT_DATE: and this one, :EXPORT_TOC_ENTRY: (?), will be the only ones being parsed, I can give it a try. I would be consistent with #+caption[short]: long for other elements. Regards, -- Nicolas Goaziou
Re: [O] subtree-export limitations
Nicolas Goaziou n.goaz...@gmail.com writes: Philipp Kroos philipp.kr...@t-online.de writes: That said, I'm fine with the situation, but I'ld suggest a note in the documentation that makes this limitation to subtree-exports clear (and possibly points out the workarounds). What do you think? Sure. What should be written in that note? Where to put it? Or, better, do you want to provide a patch for that? Regards, In general, I'ld want to, yes. But now i've realized that this concerns the users of contrib/* only.. The main documentation is sufficient for the standard, I think. Are there attempts to port the documentation to the new features already? Best regards, Philipp
Re: [O] Export tables as matrices (change tbl-export function on the fly)
Nicolas,
Thanks for your reply.
I meant: what is the exact problem with my code (with examples and
expected output if possible)? It shouldn't be hard to fix.
They are not caught by the regexp. And I wasn't able to find a regexp
which could correctly identify all cases. I have a sample in the footnote ¹
Forget the lisp translation function. At this level, the function
operates on parsed data. It doesn't use any orgtbl-to-* function. Also,
even if the ATTR_LATEX keyword applies on the table, it also affects how
`table-row' elements and `table-cell' objects are transcoded.
OK, thanks for pointing out.
I suggest to use a :math-mode t. With this mode, all cells are
treated as raw math code (no transformation is made on any cell).
Sounds good to me. However, should $'s be stripped? Say I have an
org-table which I'm indecisive about. In one sell I might have a
\frac{·}{·} in a cell; so in a normal table export I'd have to insert
$'s, but in :math-mode I wouldn't. It could thus be expensive to go
from :math mode to nil math mode. Hence, stripping $ might be
appropriate
A global variable can also set it `org-export-latex-table-math-mode'
(default to nil).
Nil by default for sure.
Then, the :environment keyword can be set to tabular, longtable,
tabularx, tabulary, bmatrix, pmatrix, vmatrix, kbordermatrix
or qbordermatrix. bordermatrix, array... It would default to
`org-e-latex-default-table-environment' (default to tabular).
and Bmatrix ({matrix}) and Vmatrix ( ||matrix||) and matrix (no
decoration).
Array needs per column configuration.
What is the variable ALIGN? You mean :align keyword? Do matrix
environments accept alignment? Also I haven't heard about starred
version of these. What do they do?
They allow you to align a matrix to [rlc] (and maybe others?) They
are defined in mathtools.
Here's an example (unrelated to tables):
#+BEGIN_SRC latex
\documentclass{article}
\usepackage{amsmath,mathtools}
\begin{document}
$\max_{x}f(x)\quad\text{s.t. }\left\{\begin{matrix*}[r]g(x)\geq0\\h(x)+h(y)\geq
k\end{matrix*}\right.$
\end{document}
#+END_SRC
From the syntax perspective, I see no difference between bordered
matrices and the others: they just use a different environment, which
can be provided through :environment keyword. Am I missing something?
No. But they are typically macros. Note the use of cr which
sometimes needs to be used in the bordermatrix (from TeX). It's not
the case in kbordermatrix (which I use) and presumably qbordermatrix.
#+BEGIN_SRC latex
\documentclass{article}
\begin{document}
$\bordermatrix{abc\cr a100\cr b010\cr c001}$
\end{document}
#+END_SRC
The backend never adds any usepackage automatically. It is a can of
worms (incompatibilities, order of packages...). It's the responsibility
of the user to do so.
I agree.
- Potentially: an :inline exists s.t. if inline is t the
matrix is typeset inline [i.e. with \(\)]. Perhaps, it
should be smart and use the small verison of
org-export-latex-tables-matrix-default-type. I.e. if
bmatrix use bsmallmatrix. This could be set via
org-export-latex-tables-matrix-inline-small.
Do all matrix environments accept a small counterpart?
amsmath provides:
smallmatrix from which all variants be generated using
appropriated \left bracket \right bracket
mathtools provides:
smallmatrix*
psmallmatrix
psmallmatrix*
bsmallmatrix
bsmallmatrix*
Bsmallmatrix
Bsmallmatrix*
vsmallmatrix
vsmallmatrix*
Vsmallmatrix
Vsmallmatrix*
smallmatrix*
so I think it covers all variants except small bordermatrix and
small arrary.
Thanks,
Rasmus
Footnotes:
¹ Adding the function function in the second post, the following
examples all translates to tables
#+BEGIN_SRC org
#+NAME: t1
| my table | with rows |
|--+---|
| a| 2 |
| 5| 3 |
matrix
| 1 | 2 |
| 3 | 4 |
#+NAME:t2
| 1 | 2 |
| 3 | 4 |
#+END_SRC
and output (note in dirty Emacs [not -q])
#+BEGIN_SRC LaTeX
\begin{table}[htb]
\label{t1}
\begin{center}
\begin{tabular}{lr}
\toprule
my table with rows\\
\midrule
a 2\\
5 3\\
\bottomrule
\end{tabular}
\end{center}
\end{table}
matrix
\begin{center}
\begin{tabular}{rr}
\toprule
1 2\\
3 4\\
\bottomrule
\end{tabular}
\end{center}
\begin{table}[htb]
\label{t2}
\begin{center}
\begin{tabular}{rr}
\toprule
1 2\\
3 4\\
\bottomrule
\end{tabular}
\end{center}
\end{table}
#+END_SRC
--
A page of history is worth a volume of logic
Re: [O] Export tables as matrices (change tbl-export function on the fly)
Rasmus ras...@gmx.us writes:
I meant: what is the exact problem with my code (with examples and
expected output if possible)? It shouldn't be hard to fix.
They are not caught by the regexp. And I wasn't able to find a regexp
which could correctly identify all cases. I have a sample in the
footnote ¹
That's because you use booktabs by default. It creates horizontal
rules, and the filter hence doesn't apply.
Sounds good to me. However, should $'s be stripped? Say I have an
org-table which I'm indecisive about. In one sell I might have a
\frac{·}{·} in a cell; so in a normal table export I'd have to insert
$'s, but in :math-mode I wouldn't. It could thus be expensive to go
from :math mode to nil math mode. Hence, stripping $ might be
appropriate
Since e-latex back-end doesn't strip anything in regular LaTeX snippets
or environments, it should be the same here. Switching to math mode
won't happen automatically, so the user can act appropriately.
Then, the :environment keyword can be set to tabular, longtable,
tabularx, tabulary, bmatrix, pmatrix, vmatrix, kbordermatrix
or qbordermatrix. bordermatrix, array... It would default to
`org-e-latex-default-table-environment' (default to tabular).
and Bmatrix ({matrix}) and Vmatrix ( ||matrix||) and matrix (no
decoration).
:environment value is a string. It can be set to anything.
Array needs per column configuration.
That's not a problem, Org handles alignment per column already:
| c | c |
| a | b |
| c | d |
Also, every math environment but array ignores column separators.
What is the variable ALIGN? You mean :align keyword? Do matrix
environments accept alignment? Also I haven't heard about starred
version of these. What do they do?
They allow you to align a matrix to [rlc] (and maybe others?) They
are defined in mathtools.
Here's an example (unrelated to tables):
#+BEGIN_SRC latex
\documentclass{article}
\usepackage{amsmath,mathtools}
\begin{document}
$\max_{x}f(x)\quad\text{s.t.
}\left\{\begin{matrix*}[r]g(x)\geq0\\h(x)+h(y)\geq
k\end{matrix*}\right.$
\end{document}
#+END_SRC
Then the backend can add the alignment as an optional argument in math
mode only when the name of the environment ends with a star and the
alignment string is one character long.
From the syntax perspective, I see no difference between bordered
matrices and the others: they just use a different environment, which
can be provided through :environment keyword. Am I missing something?
No. But they are typically macros. Note the use of cr which
sometimes needs to be used in the bordermatrix (from TeX). It's not
the case in kbordermatrix (which I use) and presumably qbordermatrix.
#+BEGIN_SRC latex
\documentclass{article}
\begin{document}
$\bordermatrix{abc\cr a100\cr b010\cr c001}$
\end{document}
#+END_SRC
To circumvent the problem, org-e-latex.el can use a defconst to store
table/matrix environments requiring \cr instead of \\ at the end of
each row. It will, as a starter, only contain bordermatrix.
Any name to suggest for it?
- Potentially: an :inline exists s.t. if inline is t the
matrix is typeset inline [i.e. with \(\)]. Perhaps, it
should be smart and use the small verison of
org-export-latex-tables-matrix-default-type. I.e. if
bmatrix use bsmallmatrix. This could be set via
org-export-latex-tables-matrix-inline-small.
Do all matrix environments accept a small counterpart?
amsmath provides:
smallmatrix from which all variants be generated using
appropriated \left bracket \right bracket
mathtools provides:
smallmatrix*
psmallmatrix
psmallmatrix*
bsmallmatrix
bsmallmatrix*
Bsmallmatrix
Bsmallmatrix*
vsmallmatrix
vsmallmatrix*
Vsmallmatrix
Vsmallmatrix*
smallmatrix*
so I think it covers all variants except small bordermatrix and
small arrary.
Ok. Then the sanest approach is to allow :math-mode to be set to nil,
t or `inline'. When `inline', as you suggest, it replaces \[...\] with
\(...\) and ignores any label. But it still uses whatever environment is
provided in :environment, that is, it won't make any guess about which
one to use.
Also, instead of using a single `org-e-latex-default-table-environment',
its value can be a plist like the following:
(:table-mode tabular :math-mode bmatrix :inline-math-mode smallmatrix)
What do you think about it?
Regards,
--
Nicolas Goaziou
Re: [O] Export tables as matrices (change tbl-export function on the fly)
Nicolas,
That's because you use booktabs by default. It creates horizontal
rules, and the filter hence doesn't apply.
Aha. Is this (again) a misunderstanding because I though of org
source? I tried to identify org tables with rules.
Since e-latex back-end doesn't strip anything in regular LaTeX
snippets or environments, it should be the same here. Switching to
math mode won't happen automatically, so the user can act
appropriately.
I guess it's fine for most applications.
:environment value is a string. It can be set to anything.
Probably the best approach.
That's not a problem, Org handles alignment per column already:
| c | c |
| a | b |
| c | d |
I had no idea. That's very cool.
Then the backend can add the alignment as an optional argument in math
mode only when the name of the environment ends with a star and the
alignment string is one character long.
In the LATEX_ATTR or as in the example above? The former I assume.
To circumvent the problem, org-e-latex.el can use a defconst to store
table/matrix environments requiring \cr instead of \\ at the end of
each row. It will, as a starter, only contain bordermatrix.
OK. How about just making a list of strings (with typical member
STRING) which are known to have the format
\STRING{matrix-like-output}? Then one can add whichever crazy
environment that might be needed to this list. And users can easily
add their favorite flavor of e.g. bordermatrix.
A short experiment seems to suggest that \cr works in place of \\.
Any name to suggest for it?
I prefer the approach where the exists a list of macro-matrices, maybe
with delimiter and/or line separator. Then the the value of
:environment can be checked against this list.
E.g. org-e-latex-matrix-macro-environments. By default:
'((bordermatrix \cr))
And I'd personally extend it to
'((bordermatrix \cr) (kbordermatrix \\))
NOTE: probably it's not nice to store line seperator and such here,
and indeed
'(bordermatrix kbordermatix)
seems like a nicer (as in simpler) list.
Ok. Then the sanest approach is to allow :math-mode to be set to nil,
t or `inline'. When `inline', as you suggest, it replaces \[...\] with
\(...\) and ignores any label. But it still uses whatever environment is
provided in :environment, that is, it won't make any guess about which
one to use.
Yeah, you're right. Less guessing is better guessing. 'Display'
might be same t.
Also, instead of using a single `org-e-latex-default-table-environment',
its value can be a plist like the following:
(:table-mode tabular :math-mode bmatrix :inline-math-mode
smallmatrix)
Yeah, that would be nice. Would it extend to the options in
ATTR_LATEX? I.e. would it be nice (?) to be able to specify
- environment
- math-environment
- inline-math-environment
in one option line s.t. I could easily switch from table to matrix to
inline matrix? E.g.
#+ATTR_LATEX: :math-environment Bmatrix :math-mode t
prints a display matrix
but
#+ATTR_LATEX: :math-environment Bmatrix :math-mode nil
prints a table.
I don't know whether this is just making things more confusing or
whether it would be useful. . .
Also, at least a prefix string would be very useful as that's how
matrices are usually named. E.g.
#+ATTR_LATEX: :math-mode t :prefix P=
|1|2|
|3|4|
is translated to
P=\begin{bmatrix}12\\34\end{bmatrix}
Thanks,
Rasmus
--
Dung makes an excellent fertilizer
[O] [new exporter] adhere org-export-date-timestamp-format?
Hi,
Would it be desirable if the new exporter took the variable
org-export-date-timestamp-format into consideration when formatting
dates? Or is there another way of dealing with the formatting of
dates?
┏━━━┫ org-export-date-timestamp-format ~%Y-%m-%d~ ┃
┃ Type: string
┃ Since: Emacs version 24.1
┃ In file: org-exp.el
┃ Time string format for Org timestamps in the #+DATE option.
┗━━━
Here's the relevant snip for org-exp.
((string-equal key DATE)
;; If date is an Org timestamp, convert it to a time
;; string using `org-export-date-timestamp-format'
(when (string-match org-ts-regexp3 val)
(setq val (format-time-string
org-export-date-timestamp-format
(apply 'encode-time (org-parse-time-string
(match-string 0 val))
(setq p (plist-put p :date val)))
Example:
#+BEGIN_SRC org
#+DATE: 2012-11-18 Sun
* test
#+END_SRC
Date is exported as \date{2012-11-18 Sun} with the new exporter and
\date{2012-11-18} with the old exporter (using emacs -q).
Thanks,
Rasmus
--
El Rey ha muerto. ¡Larga vida al Rey!
[O] [PATCH] Small API fix and add test for addlevel inclusion parameter
The following changes since commit c2223c8979c5510e01c0dd6cc2378b71484828fc: still execute code block even if :results none (2012-11-17 17:54:08 -0700) are available in the git repository at: git://git.baby-gnu.net/org-mode tags/fix-and-test-org-exp-inclusion for you to fetch changes up to eec6c6086a2e93e4a8a30081603405a4b7b48634: org-exp: Add tests for addlevel (2012-11-18 15:47:50 +0100) Without any parameter, inclusion should be done as-is, it was always demoted due to a bug of org-get-file-contents call in org-export-handle-include-files. Add test cases for the addlevel option[fn:1] which add one to the current level. Footnotes: [fn:1] http://article.gmane.org/gmane.emacs.orgmode/50030 Daniel Dehennin (2): org-exp: Fix minlevel inclusion org-exp: Add tests for addlevel lisp/org-exp.el |2 +- testing/examples/org-exp.org | 25 + testing/lisp/test-org-exp.el | 24 3 files changed, 50 insertions(+), 1 deletion(-) -- Daniel Dehennin Récupérer ma clef GPG: gpg --keyserver pgp.mit.edu --recv-keys 0x7A6FE2DF pgpkX54srPtP1.pgp Description: PGP signature
Re: [O] Question re. Bernt's agenda setup
On Sat, Nov 17, 2012 at 6:25 PM, Manish wrote: [snip (21 lines)] =F12 SPC= with =V= is so much better at doing project reviews than anything else I have ever seen. My only gripe is that functions called by =V= and =P= do not refresh the agenda. I am trying to understand enough elisp to be able to call org-agenda-redo and beginning-of-buffer in some right places.. My bad. While making the same setup from scratch in home laptop found that everything works as advertised. My work setup must have something interfering with it. Cheers! Manish
Re: [O] [org-e-texinfo] generate menu items
Nicolas Goaziou n.goaz...@gmail.com writes: t...@tsdye.com (Thomas S. Dye) writes: Nicolas Goaziou n.goaz...@gmail.com writes: That's a bit of work, because, so far, node-property values are not parsed. So it would require to define a new class of node-properties: those with a parsed value. But then, how to decide which properties have their value parsed are parsed and which have not? Thanks for the information and explanation. Back-end-specific properties should work nicely in this case. I'll wait to see what Jonathan thinks about the original query. Assuming :EXPORT_TITLE:, :EXPORT_AUTHOR:, :EXPORT_DATE: and this one, :EXPORT_TOC_ENTRY: (?), will be the only ones being parsed, I can give it a try. I would be consistent with #+caption[short]: long for other elements. Regards, I'm biased by LaTeX, which uses the optional argument for the TOC and running heads. Since the back-ends are free to use this optional entry as they please, and not only for the TOC, perhaps :EXPORT_SHORT_ENTRY: (because that is its usual function), or :EXPORT_OPTIONAL_ENTRY: (because the back-end has the option to use it where appropriate). All the best, Tom -- Thomas S. Dye http://www.tsdye.com
[O] [org-e-texinfo] Exporting email address
Aloha all,
I have this in the Org file:
@@info:@email{emacs-orgmode@@gnu.org}@@
I expect to get this in the texi file:
@email{emacs-orgmode@@gnu.org}
Instead, I get this:
@email{emacs-orgmodegnu.org@}
In general, the export snippets work very well. I think this might be a
corner case caused by the '@@' in the argument to the texinfo @email
command. I don't know if this pops up elsewhere in texinfo.
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] [org-e-texinfo] Exporting email address
Hello Tom,
On Nov 18, 2012 1:29 PM, Thomas S. Dye t...@tsdye.com wrote:
Aloha all,
I have this in the Org file:
@@info:@email{emacs-orgmode@@gnu.org}@@
I expect to get this in the texi file:
@email{emacs-orgmode@@gnu.org}
Instead, I get this:
@email{emacs-orgmodegnu.org@}
The issue is that the @@ is viewed as the end of the snippet and not as a
portion of it.
However I believe that the exporter can parse mailto links properly
[[Mailto: emacs-orgmode@gnu.org]] should work. I don't have access to my
computer right now so I can't check but I'll look at this as well as the
other points you've brought up during the week.
In general, the export snippets work very well. I think this might be a
corner case caused by the '@@' in the argument to the texinfo @email
command. I don't know if this pops up elsewhere in texinfo.
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Regard,
Jon
Re: [O] [org-e-texinfo] Exporting email address
Aloha Jon,
Jonathan Leech-Pepin jonathan.leechpe...@gmail.com writes:
Hello Tom,
On Nov 18, 2012 1:29 PM, Thomas S. Dye t...@tsdye.com wrote:
Aloha all,
I have this in the Org file:
@@info:@email{emacs-orgmode@@gnu.org}@@
I expect to get this in the texi file:
@email{emacs-orgmode@@gnu.org}
Instead, I get this:
@email{emacs-orgmodegnu.org@}
The issue is that the @@ is viewed as the end of the snippet and not as a
portion of it.
However I believe that the exporter can parse mailto links properly
[[Mailto: emacs-orgmode@gnu.org]] should work. I don't have access to my
computer right now so I can't check but I'll look at this as well as the
other points you've brought up during the week.
I should have thought of that. The link
[[mailto:emacs-orgmode@gnu.org]] exports perfectly.
Thanks for your help.
All the best,
Tom
In general, the export snippets work very well. I think this might be a
corner case caused by the '@@' in the argument to the texinfo @email
command. I don't know if this pops up elsewhere in texinfo.
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Regard,
Jon
Hello Tom,
On Nov 18, 2012 1:29 PM, Thomas S. Dye t...@tsdye.com wrote:
Aloha all,
I have this in the Org file:
@@info:@email{emacs-orgmode@@gnu.org}@@
I expect to get this in the texi file:
@email{emacs-orgmode@@gnu.org}
Instead, I get this:
@email{emacs-orgmodegnu.org@}
The issue is that the @@ is viewed as the end of the snippet and not
as a portion of it.
However I believe that the exporter can parse mailto links properly
[[Mailto: emacs-orgmode@gnu.org]] should work. I don't have access to
my computer right now so I can't check but I'll look at this as well
as the other points you've brought up during the week.
In general, the export snippets work very well. I think this might
be a
corner case caused by the '@@' in the argument to the texinfo @email
command. I don't know if this pops up elsewhere in texinfo.
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Regard,
Jon
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] Export tables as matrices (change tbl-export function on the fly)
Rasmus ras...@gmx.us writes:
Then the backend can add the alignment as an optional argument in math
mode only when the name of the environment ends with a star and the
alignment string is one character long.
In the LATEX_ATTR or as in the example above? The former I assume.
Correct.
To circumvent the problem, org-e-latex.el can use a defconst to store
table/matrix environments requiring \cr instead of \\ at the end of
each row. It will, as a starter, only contain bordermatrix.
OK. How about just making a list of strings (with typical member
STRING) which are known to have the format
\STRING{matrix-like-output}? Then one can add whichever crazy
environment that might be needed to this list. And users can easily
add their favorite flavor of e.g. bordermatrix.
That's the idea: a list of strings which are used as commands and not as
environments, since environments use \\.
A short experiment seems to suggest that \cr works in place of \\.
\\ is high-level, \cr is not. There are certainly drawbacks to use
replace \\ with \cr.
Also, instead of using a single `org-e-latex-default-table-environment',
its value can be a plist like the following:
(:table-mode tabular :math-mode bmatrix :inline-math-mode
smallmatrix)
Yeah, that would be nice. Would it extend to the options in
ATTR_LATEX? I.e. would it be nice (?) to be able to specify
- environment
- math-environment
- inline-math-environment
in one option line s.t. I could easily switch from table to matrix to
inline matrix? E.g.
#+ATTR_LATEX: :math-environment Bmatrix :math-mode t
prints a display matrix
but
#+ATTR_LATEX: :math-environment Bmatrix :math-mode nil
prints a table.
I don't know whether this is just making things more confusing or
whether it would be useful. . .
That would be too much properties to my liking. There are already many
of them in tables.
Also, at least a prefix string would be very useful as that's how
matrices are usually named. E.g.
#+ATTR_LATEX: :math-mode t :prefix P=
|1|2|
|3|4|
is translated to
P=\begin{bmatrix}12\\34\end{bmatrix}
Sure :math-prefix and :math-suffix seem like a good idea.
Regards,
--
Nicolas Goaziou
Re: [O] Bug? R: Org babel block execution *drastically* slower than in ESS session directly
Aaron Ecay aarone...@gmail.com writes: 2012ko azaroak 17an, Eric Schulte-ek idatzi zuen: Oh!, thanks for catching this, I just pushed up a fix. This is no longer a (complete) fix for the original problem, though. (A large part of) the slowdown comes from reading the results from a temp file and transforming them into an elispy format, which is handled by the backends. Your code only prevents them from being echoed to the minibuffer. You can see this by trying your original “seq” tests. You should see them taking the same (very long) amount of time. If you set debug-on-quit to t (before evaluating the block) and interrupt emacs with C-g when it hangs, you’ll see a backtrace that goes through ‘org-babel-execute:sh’ and then ‘org-babel-import-elisp-from-file’. The presence of the former in the call stack is why I claim that per-backend fixes are ultimately needed. The latter is where my patch addresses the problem in a temporary way. I apologize for rushing through your previous email and missing important portions of the content. I may be outvoted, but I find this approach too be overly complicated. Also, size may frequently not be the best proxy for the time which Emacs will take to ingest the results. I agree that my patch is a stopgap. But until per-backend fixes are available, this allows certain code to run that otherwise wouldn’t (at least not without hacks, such as putting NULL at the end of an R source block so that the “.Last.value” in the block is trivial). I'm attaching a new patch which should serve as a more permanent solution, however, given that it touches almost every backend I want to give the list a chance to try it out before committing it. This patch introduces a new macro (`org-babel-result-cond') which attempts to unify the results processing. Not only does this check for :results none and ignore all results in that case, but it also checks whether the results should be parsed as a scalar or a vector. Hopefully this will serve as useful refactoring and reduce the total amount of code as well as provide for more uniform results processing across languages. Please let me know if this looks like a good permanent solution. I see that I'm now getting 5 test failures with this patch applied locally, but I won't have time to look at this further until early next week at the earliest, so I'm sharing the existing patch now. Thanks, From a2878534832923e42aef49176b87d9993c04af71 Mon Sep 17 00:00:00 2001 From: Eric Schulte eric.schu...@gmx.com Date: Sun, 18 Nov 2012 18:02:09 -0700 Subject: [PATCH] org-babel-result-cond - unified handling of results * lisp/ob.el (org-babel-result-cond): This function should now be used by all language backends to handle the processing of raw code block output into scalar results, table results, or ignored results depending on the value of result-params. * lisp/ob-C.el (org-babel-C-execute): Use org-babel-result-cond. * lisp/ob-R.el (org-babel-R-evaluate-external-process): Use org-babel-result-cond. (org-babel-R-evaluate-session): Use org-babel-result-cond. * lisp/ob-awk.el (org-babel-execute:awk): Use org-babel-result-cond. * lisp/ob-clojure.el (org-babel-execute:clojure): Use org-babel-result-cond. * lisp/ob-emacs-lisp.el (org-babel-execute:emacs-lisp): Use org-babel-result-cond. * lisp/ob-fortran.el (org-babel-execute:fortran): Use org-babel-result-cond. * lisp/ob-io.el (org-babel-io-evaluate): Use org-babel-result-cond. * lisp/ob-java.el (org-babel-execute:java): Use org-babel-result-cond. * lisp/ob-lisp.el (org-babel-execute:lisp): Use org-babel-result-cond. * lisp/ob-maxima.el (org-babel-execute:maxima): Use org-babel-result-cond. * lisp/ob-picolisp.el (org-babel-execute:picolisp): Use org-babel-result-cond. * lisp/ob-python.el (org-babel-python-evaluate-external-process): Use org-babel-result-cond. (org-babel-python-evaluate-session): Use org-babel-result-cond. * lisp/ob-scala.el (org-babel-scala-evaluate): Use org-babel-result-cond. * lisp/ob-sh.el (org-babel-sh-evaluate): Use org-babel-result-cond. * lisp/ob-shen.el (org-babel-execute:shen): Use org-babel-result-cond. * lisp/ob-sql.el (org-babel-execute:sql): Use org-babel-result-cond. * lisp/ob-sqlite.el (org-babel-execute:sqlite): Use org-babel-result-cond. --- lisp/ob-C.el | 10 +- lisp/ob-R.el | 18 -- lisp/ob-awk.el| 6 ++ lisp/ob-clojure.el| 5 ++--- lisp/ob-emacs-lisp.el | 9 - lisp/ob-fortran.el| 10 +- lisp/ob-io.el | 4 ++-- lisp/ob-java.el | 8 lisp/ob-lisp.el | 4 ++-- lisp/ob-maxima.el | 6 ++ lisp/ob-picolisp.el | 9 ++--- lisp/ob-python.el | 14 -- lisp/ob-scala.el | 4 ++-- lisp/ob-sh.el | 6 ++ lisp/ob-shen.el | 5 ++--- lisp/ob-sql.el| 8 ++-- lisp/ob-sqlite.el | 32 +++- lisp/ob.el| 14
[O] confirmed: org-mode works with yasnippets 0.8.0 (beta)
Hi, I just want to let you know that org-mode (org-20121112 from package.el) is working well with yasnippets 0.8.0 (beta) with following configuration: (defun yas-org-very-safe-expand () (let ((yas-fallback-behavior 'return-nil)) (and (fboundp 'yas-expand) (yas-expand (add-hook 'org-mode-hook (lambda () (add-to-list 'org-tab-first-hook 'yas-org-very-safe-expand) )) You may update the documentation with the above settings. (Note that this does not works with the old version of yasnippets) Thanks. -- C FAQs: http://c-faq.com/ Korean: http://www.cinsk.org/cfaqs/
Re: [O] Bug? R: Org babel block execution *drastically* slower than in ESS session directly
Eric Schulte schulte.e...@gmail.com writes: Aaron Ecay aarone...@gmail.com writes: 2012ko azaroak 17an, Eric Schulte-ek idatzi zuen: Oh!, thanks for catching this, I just pushed up a fix. This is no longer a (complete) fix for the original problem, though. (A large part of) the slowdown comes from reading the results from a temp file and transforming them into an elispy format, which is handled by the backends. Your code only prevents them from being echoed to the minibuffer. You can see this by trying your original “seq” tests. You should see them taking the same (very long) amount of time. If you set debug-on-quit to t (before evaluating the block) and interrupt emacs with C-g when it hangs, you’ll see a backtrace that goes through ‘org-babel-execute:sh’ and then ‘org-babel-import-elisp-from-file’. The presence of the former in the call stack is why I claim that per-backend fixes are ultimately needed. The latter is where my patch addresses the problem in a temporary way. I apologize for rushing through your previous email and missing important portions of the content. I may be outvoted, but I find this approach too be overly complicated. Also, size may frequently not be the best proxy for the time which Emacs will take to ingest the results. I agree that my patch is a stopgap. But until per-backend fixes are available, this allows certain code to run that otherwise wouldn’t (at least not without hacks, such as putting NULL at the end of an R source block so that the “.Last.value” in the block is trivial). I'm attaching a new patch which should serve as a more permanent solution, however, given that it touches almost every backend I want to give the list a chance to try it out before committing it. This patch introduces a new macro (`org-babel-result-cond') which attempts to unify the results processing. Not only does this check for :results none and ignore all results in that case, but it also checks whether the results should be parsed as a scalar or a vector. Hopefully this will serve as useful refactoring and reduce the total amount of code as well as provide for more uniform results processing across languages. Please let me know if this looks like a good permanent solution. I see that I'm now getting 5 test failures with this patch applied locally, but I won't have time to look at this further until early next week at the earliest, so I'm sharing the existing patch now. Thanks, Alright, I've now changed the above patch so that as many tests are passing locally as were passing without the patch. Given that, I've applied this patch to the main git repository. Everything which worked previously should still be working, only now the :results none options should have the desired effect. Cheers, -- Eric Schulte http://cs.unm.edu/~eschulte
[O] How to force markup without spaces
Hi, AFAIK, if the markup syntax (=code=, *bold*, ..) is directly followed by non-whitespace characters, then it will not be marked-up: =hello=there /not/italic This may be right decision on English text, but in some languages, the postposition (grammar) will be postfixed without spaces into the previous noun, so it will be the trouble. (Following text contains Korean characters in UTF-8, you may need additional korean font to read properly) =printf=는 =bold=로 =철수=는 I'm sure that some other languages will have same problem (e.g. Japanese or Chinese). Is there any way to force mark-up on this situation? If this pattern cannot be implemented easily, how about to introduce new escaping character to prevent to insert whitespace between marked-up text and the following postfix text? For example: =printf=\is = rendered in HTML: codeprintf/codeis *bold*\asdf = rendered in HTML: bbold/basdf /철수/\는= rendered in HTML: i철수/i는 I can't say the above solution is well-designed, but I'm sure that you'll get the point. Thanks. -- C FAQ: http://www.eskimo.com/~scs/C-faq/top.html Korean Ver: http://www.cinsk.org/cfaqs/
Re: [O] How to force markup without spaces
Hello, ** cin...@gmail.com [2012-11-19 14:32:21 +0900]: Hi, AFAIK, if the markup syntax (=code=, *bold*, ..) is directly followed by non-whitespace characters, then it will not be marked-up: =hello=there /not/italic This may be right decision on English text, but in some languages, the postposition (grammar) will be postfixed without spaces into the previous noun, so it will be the trouble. (Following text contains Korean characters in UTF-8, you may need additional korean font to read properly) =printf=는 =bold=로 =철수=는 I'm sure that some other languages will have same problem (e.g. Japanese or Chinese). Is there any way to force mark-up on this situation? If this pattern cannot be implemented easily, how about to introduce new escaping character to prevent to insert whitespace between marked-up text and the following postfix text? For example: =printf=\is = rendered in HTML: codeprintf/codeis *bold*\asdf = rendered in HTML: bbold/basdf /철수/\는= rendered in HTML: i철수/i는 I can't say the above solution is well-designed, but I'm sure that you'll get the point. May be this will help you: http://article.gmane.org/gmane.emacs.orgmode/46263/match=zero+width+space -- Had he and I but met By some old ancient inn,But ranged as infantry, We should have sat us down to wet And staring face to face, Right many a nipperkin! I shot at him as he at me, And killed him in his place. I shot him dead because -- Because he was my foe, He thought he'd 'list, perhaps, Just so: my foe of course he was; Off-hand-like -- just as I -- That's clear enough; although Was out of work -- had sold his traps No other reason why. Yes; quaint and curious war is! You shoot a fellow down You'd treat, if met where any bar is Or help to half-a-crown. -- Thomas Hardy
[O] [org-e-latex] Coding System
When the new exporter produces a TeX file that contains unicode characters,
Emacs tries to save this file with coding systems `undecided-unix´ and
`iso-latin1-unix´, both of which don't work of course (and the latter would
likely be wrong for some characters). While it should be possible to change the
default coding systems to use, it would certainly be better if the exporter took
note of the
\usepackage[utf8]{inputenc}
and alter the coding system for saving the TeX file accordingly.
Regards,
Achim.
