Re: [O] [parser] subscripts and underlines interacting badly
Hello,
Aaron Ecay aarone...@gmail.com writes:
I have encountered two related misbehaviors in the parser/exporter.
The first manifests if you type the following line into an org-mode
buffer and execute M-: (org-element-context) with point on the ‘f’; the
result is a subscript object, whereas I would have expected an
underline:
'_foo_
I think both possibilities are returned by
org-element--get-next-object-candidates, and subscript “wins” because it
precedes the other in the list. I’m not sure how this should be
addressed, but maybe Nicolas knows.
Actually, this is not really a parser problem but a syntax one.
underline and subscript are ambiguous, and therefore ill-defined,
because, in some situations, both can match at the same location.
This is usually not noticeable because, I think, most uses of underline
begin with a space (e.g. some _word_) whereas subscript cannot. This is
not true in your example.
This has been discussed some months ago, but, AFAIR, no answer was
found. Note that I suggested a change to superscript/supscript a couple
of weeks ago, but it won't solve the problem at hand. Perhaps it could
be extended to remove ambiguity for subscript.
I encountered the second issue when trying to hack around the first by
setting org-use-sub-superscripts to '{}. It seems this variable is not
considered by the parser. I think the attached patch fixes this
issue.
Thanks for the patch.
Though, the parser ignores `org-use-sub-superscripts' on purpose. At the
moment `org-use-sub-superscripts' is a display variable only.
This change happened in 8.0. This also explains why
`org-export-with-sub-superscripts' is now a separate value from
`org-use-sub-superscripts'.
The main reason for this change is that I think that customizable
syntax, unlike to customizable behaviour, is not a good idea for Org
(e.g. portability and simplicity issues).
Regards,
--
Nicolas Goaziou
Re: [O] [babel] Can't write accented characters in R graphics
Christian Moe wrote: Sebastien Vauban writes: Fixed with: --8---cut here---start-8--- ;; accented characters on graphics (setq org-babel-R-command (concat org-babel-R-command --encoding=UTF-8))) --8---cut here---end---8--- That looked promising, but when I tried it, I got the following *Org-Babel Error Output*, which shows Babel choking on the first non-ascii character at the start of the xlab string: Error: unexpected '/' in: plot(1:10, 1:10, xlab=dev.off() }}(),transfer.file=/var/folders/JV/JVNxBfnMGkWC9Aw0BZa8Kk+++TI/-Tmp-/ Execution halted Still baffled, Maybe try with variations of the above encoding, such as latin1 or so. Pay attention: - Different installations have different expectations (the Windows R binary does not behave the same as the Cygwin R for the default encoding). - The encoding name is not spelled the same between the Windows R binary and the Cygwin R one: UTF-8 passes both tests, utf8 only for the Windows binary... Best regards, Seb -- Sebastien Vauban
Re: [O] TikZ (circuitikz) and org-preview-latex-fragment don't play nicely together
Mark Edgington edgi...@gmail.com writes: [...] Is there any way that I can make it so that without a lot of hacks I can make the previews appear as white-on-black, and the PDFs print black on white? Would something need to change with how org-mode handles previewing to make this possible? I have the following for when I use org-tree-slide-mode for presentations, where my colour theme is light text on dark background: #+begin_src emacs-lisp :results none (setq org-format-latex-options '(:foreground white :background black :scale 3 :html-foreground Black :html-background Transparent :html-scale 1.0 :matchers (begin $1 $ $$ \\( \\[)) org-latex-create-formula-image-program 'imagemagick org-tree-slide-heading-emphasis t ) #+end_src I think the key is the =org-format-latex-options= variable. I have no idea whether this is used by the exporter or just for previewing LaTeX in org. -- : Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.2.4-322-gece429
Re: [O] publishuing in html5
Nicolas, thanks for your hint. I have a couple of observations. 2013/12/9 Nicolas Goaziou n.goaz...@gmail.com Hello, Catonano caton...@gmail.com writes: I tried to both include the directive in the group in the project definition AND using #+HTML_HTML5_FANCY: t in level-0.org There is no such keyword. Use: #+OPTIONS: html5-fancy:t that key is mentioned at this page http://orgmode.org/worg/org-tutorials/org-publish-html-tutorial.html#sec-5 is that page wrong ? Anyway I tried to substitute that row with your one and it didn't work anyway. I made a temporary repository here https://github.com/humanitiesNerd/exploring-org-mode in case anyone wants to take a look thanks or set `org-html-html5-fancy' to a non-nil value. Regards, -- Nicolas Goaziou
Re: [O] publishuing in html5
Nick, 2013/12/9 Nick Dokos ndo...@gmail.com Catonano caton...@gmail.com writes: Try --8---cut here---start-8--- #+HTML_DOCTYPE: html5 #+OPTIONS: html5-fancy:t #+BEGIN_ASIDE Lorem Ipsum #+END_ASIDE --8---cut here---end---8--- I'm trying to use level-N-org files, I'm not writing the settings in each file The doctype is set to html5 and html5-fancy is set to a not null value Would you mind to take a look at it ? It's here https://github.com/humanitiesNerd/exploring-org-mode
[O] orgmod: R and threeparttable
What is the best solution for the following scenario? In my org file, I use an R source code to generate a table. I would like to additionally specify notes to this table, and use threeparttable in latex export to be able to specify notes below the table. Can somebody point me to an example on how could this be done best? Vikas
Re: [O] publishuing in html5
Scott Randby sran...@gmail.com writes: On 12/09/2013 02:53 PM, Nick Dokos wrote: Catonano caton...@gmail.com writes: I' m trying to follow the examples at this page http://orgmode.org/manual/HTML-doctypes.html#HTML-doctypes to transform #+BEGIN_ASIDE Lorem ipsum #+END_ASIDE in aside pLorem ipsum/p /aside but it doesn't work, I still get div class=aside p Lorem ipsum /p /div I tried to both include the directive in the group in the project definition AND using #+HTML_HTML5_FANCY: t Try --8---cut here---start-8--- #+HTML_DOCTYPE: html5 #+OPTIONS: html5-fancy:t #+BEGIN_ASIDE Lorem Ipsum #+END_ASIDE --8---cut here---end---8--- I cannot get the html5-fancy:t option to work when I set it in a file in the manner described above. It only works when I set org-html-html5-fancy to t in my init file. Did you C-c C-c on the #+OPTIONS line (or otherwise reinitialize the mode of the file)? -- Nick
Re: [O] TikZ (circuitikz) and org-preview-latex-fragment don't play nicely together
On Wed, Dec 11, 2013 at 3:46 AM, Eric S Fraga e.fr...@ucl.ac.uk wrote: Mark Edgington edgi...@gmail.com writes: [...] Is there any way that I can make it so that without a lot of hacks I can make the previews appear as white-on-black, and the PDFs print black on white? Would something need to change with how org-mode handles previewing to make this possible? [...] I think the key is the =org-format-latex-options= variable. I have no idea whether this is used by the exporter or just for previewing LaTeX in org. Hi Eric, I tried modifying org-format-latex-options (and disabling the global 'gray' TikZ setting I had previously had) like you have it, where :foreground and :background are specified explicitly, but the result is the same as when :foreground and :background are set to 'default' -- the electrical components aren't visible. It seems like what is needed is an extra key in org-format-latex-options that allows one to add the equivalent of #+LaTeX_HEADER: options (which only apply when (pre)viewing fragments within emacs. Or is there some other way to make this work? Regards, Mark
Re: [O] publishuing in html5
On 12/11/2013 07:58 AM, Nick Dokos wrote: Scott Randby sran...@gmail.com writes: On 12/09/2013 02:53 PM, Nick Dokos wrote: Catonano caton...@gmail.com writes: I' m trying to follow the examples at this page http://orgmode.org/manual/HTML-doctypes.html#HTML-doctypes to transform #+BEGIN_ASIDE Lorem ipsum #+END_ASIDE in aside pLorem ipsum/p /aside but it doesn't work, I still get div class=aside p Lorem ipsum /p /div I tried to both include the directive in the group in the project definition AND using #+HTML_HTML5_FANCY: t Try --8---cut here---start-8--- #+HTML_DOCTYPE: html5 #+OPTIONS: html5-fancy:t #+BEGIN_ASIDE Lorem Ipsum #+END_ASIDE --8---cut here---end---8--- I cannot get the html5-fancy:t option to work when I set it in a file in the manner described above. It only works when I set org-html-html5-fancy to t in my init file. Did you C-c C-c on the #+OPTIONS line (or otherwise reinitialize the mode of the file)? I tried C-c C-c on the #+OPTIONS line and I tried killing the file and opening it up again---neither works. I looked in the manual (section 12.3) and noticed that html5-fancy: is not on the list of arguments recognized by the #+OPTIONS keyword.
[O] ox-latex: Is \uline really right for underlining?
org-latex-text-markup-alist is a variable defined in `ox-latex.el'.
Its value is ((bold . \\textbf{%s})
(code . verb)
(italic . \\emph{%s})
(strike-through . \\sout{%s})
(underline . \\uline{%s})
(verbatim . protectedtexttt))
underline . \\uline{%s} -- According to [1],
~~
\uline
Underlines text. Requires ulem package. See Formatting.
~~
Is ulem one of the LaTeX export default packages? I don't see that it is.
If not, should org's default underlining command depend on a package that
is not activated by default?
(There is no reference to -markup- anything in my .emacs, so I'm quite sure
I haven't customized this variable.)
hjh
[1] http://en.wikibooks.org/wiki/LaTeX/Command_Glossary#U
Re: [O] ox-latex: Is \uline really right for underlining?
Hello, James Harkins jamshar...@gmail.com writes: Is ulem one of the LaTeX export default packages? Yes, it is. See `org-latex-default-packages-alist'. Regards, -- Nicolas Goaziou
[O] LaTeX export with listings: multicolumn support broken?
A few months ago, I wrote an academic paper with code examples, using the
listings environment like so:
#+ATTR_LaTeX: :starred t :options [htb]
#+BEGIN_figure
#+CAPTION: Simple sequencer, implementing the musical flow from Figure
[[basicseq_graph]].
#+NAME: basicseq
#+BEGIN_SRC {} -i
TLSequenceIterator([
bpCmd: (name: \rumble, dur: 40),
15,
bpCmd: (name: \whine, dur: 20)
]);
#+END_SRC
#+END_figure
Now I need to submit revisions for the same paper, and :starred t is
ignored. I get \begin{figure}, not \begin{figure*} as before.
I have also tried
#+ATTR_LaTeX: :float multicolumn :options [htb]
per documentation at [1]. I still get \begin{figure}, not \begin{figure*}.
What happened?
My paper is due on Sunday (Dec. 15). Need a fix fairly soon. If nothing
else, I will downgrade via git.
hjh
Re: [O] LaTeX export with listings: multicolumn support broken?
Hello,
James Harkins jamshar...@gmail.com writes:
A few months ago, I wrote an academic paper with code examples, using the
listings environment like so:
#+ATTR_LaTeX: :starred t :options [htb]
#+BEGIN_figure
#+CAPTION: Simple sequencer, implementing the musical flow from Figure
[[basicseq_graph]].
#+NAME: basicseq
#+BEGIN_SRC {} -i
TLSequenceIterator([
bpCmd: (name: \rumble, dur: 40),
15,
bpCmd: (name: \whine, dur: 20)
]);
#+END_SRC
#+END_figure
Now I need to submit revisions for the same paper, and :starred t is
ignored. I get \begin{figure}, not \begin{figure*} as before.
I have also tried
#+ATTR_LaTeX: :float multicolumn :options [htb]
per documentation at [1]. I still get \begin{figure}, not \begin{figure*}.
What happened?
I could be a suggested feature that didn't make it into code base.
Anyway, you can use:
#+begin_figure*
...
#+end_figure*
instead.
Regards,
--
Nicolas Goaziou
Re: [O] LaTeX export with listings: multicolumn support broken?
On Wednesday, December 11, 2013 10:54:37 PM HKT, James Harkins wrote:
I have also tried
#+ATTR_LaTeX: :float multicolumn :options [htb]
per documentation at [1]. I still get \begin{figure}, not
\begin{figure*}.
Forgot the footnote: it's
http://orgmode.org/manual/LaTeX-specific-attributes.html#LaTeX-specific-attributes
Anyway, I've tested 8.2, 8.1.2, 8.1.0 and a previous sandbox branch I
used at some point in the past. None of them give me multicolumn figures
for code blocks.
Well, certainly it worked back in August...
hjh
Re: [O] publishuing in html5
Scott Randby sran...@gmail.com writes: I tried C-c C-c on the #+OPTIONS line and I tried killing the file and opening it up again---neither works. I looked in the manual (section 12.3) and noticed that html5-fancy: is not on the list of arguments recognized by the #+OPTIONS keyword. It's documented in section 12.6.2, HTML doctypes. Nick
Re: [O] LaTeX export with listings: multicolumn support broken?
Nicolas Goaziou n.goaziou at gmail.com writes: I could be a suggested feature that didn't make it into code base. Anyway, you can use: #+begin_figure* ... #+end_figure* instead. OK, relief. That did it. Should #+begin_something* be documented under special blocks here? http://orgmode.org/manual/LaTeX-specific-attributes.html#LaTeX-specific-attributes hjh
Re: [O] TikZ (circuitikz) and org-preview-latex-fragment don't play nicely together
Ok, I dug into the problem a little deeper, and it seems that it
really can be considered a bug in the circuitikz code -- in order to
remedy it for the present time, the circuitikz.code.tex file from this
package should be modified, and the line:
\ctikzset{color/.initial=black}
must be removed / commented-out.
Nonetheless, I do think that to make it easier for people to share
org-mode files that use packages that are in some way buggy, having a
way to specify #+LaTeX_HEADER options which only apply when generating
preview images would be useful, so that workarounds for bugginess
could be added on the org-mode side, instead of requiring all
collaborators to patch their buggy libraries / packages.
Regards,
Mark
Re: [O] publishuing in html5
On 12/11/2013 10:04 AM, Nick Dokos wrote: Scott Randby sran...@gmail.com writes: I tried C-c C-c on the #+OPTIONS line and I tried killing the file and opening it up again---neither works. I looked in the manual (section 12.3) and noticed that html5-fancy: is not on the list of arguments recognized by the #+OPTIONS keyword. It's documented in section 12.6.2, HTML doctypes. Yes, I had seen that documentation earlier, but I can't get it to work. I have no idea what the trouble could be. Any suggestions? Nick
Re: [O] LaTeX export with listings: multicolumn support broken?
James Harkins jamshar...@gmail.com writes:
On Wednesday, December 11, 2013 10:54:37 PM HKT, James Harkins wrote:
I have also tried
#+ATTR_LaTeX: :float multicolumn :options [htb]
per documentation at [1]. I still get \begin{figure}, not
\begin{figure*}.
Forgot the footnote: it's
http://orgmode.org/manual/LaTeX-specific-attributes.html#LaTeX-specific-attributes
Anyway, I've tested 8.2, 8.1.2, 8.1.0 and a previous sandbox branch
I used at some point in the past. None of them give me multicolumn
figures for code blocks.
Well, certainly it worked back in August...
Your first attr_latex line applies to the figure special block, not
to the source block.
Regards,
--
Nicolas Goaziou
Re: [O] publishuing in html5
Hello, Scott Randby sran...@gmail.com writes: On 12/11/2013 10:04 AM, Nick Dokos wrote: Scott Randby sran...@gmail.com writes: I tried C-c C-c on the #+OPTIONS line and I tried killing the file and opening it up again---neither works. I looked in the manual (section 12.3) and noticed that html5-fancy: is not on the list of arguments recognized by the #+OPTIONS keyword. It's documented in section 12.6.2, HTML doctypes. Yes, I had seen that documentation earlier, but I can't get it to work. I have no idea what the trouble could be. Any suggestions? You also need to set `org-html-doctype' to html5 or some such in order to make html5-fancy effective. Regards, -- Nicolas Goaziou
Re: [O] TikZ (circuitikz) and org-preview-latex-fragment don't play nicely together
Hello, Mark Edgington edgi...@gmail.com writes: Nonetheless, I do think that to make it easier for people to share org-mode files that use packages that are in some way buggy, having a way to specify #+LaTeX_HEADER options which only apply when generating preview images would be useful, so that workarounds for bugginess could be added on the org-mode side, instead of requiring all collaborators to patch their buggy libraries / packages. You can remove offending packages with `org-export-before-parsing-hook' if you don't want them to be used during the export process. Regards, -- Nicolas Goaziou
Re: [O] TikZ (circuitikz) and org-preview-latex-fragment don't play nicely together
Nicolas Goaziou n.goaziou at gmail.com writes: You can remove offending packages with `org-export-before-parsing-hook' if you don't want them to be used during the export process. Yes, but I need the package which is buggy. If I were to remove it, I couldn't preview latex fragements or export a PDF file.
[O] Leading headline of a subtree tag export
I had a file with the following structure: #+OPTIONS: tags:nil * Grades ** Student :studenttag: :PROPERTIES: :EXPORT_FILE_NAME: Exported-Grades/studenttag :END: *** Totals :totals: Content Whenever I exported the entire file, no tags were exported (what I want). However, whenever I exported the Student subtree, the tag for that subtree was exported (not what I want) but the tag for the Totals subtree was not exported (what I want). Then I tried the following: #+OPTIONS: tags:nil * Grades ** Student :studenttag: :PROPERTIES: :EXPORT_FILE_NAME: Exported-Grades/studenttag :EXPORT_OPTIONS: tags:nil :END: *** Totals :totals: Content The tag for the Student subtree is still exported when I export the Student subtree. How do I prevent this tag from being exported when I export the subtree? Scott Randby
Re: [O] publishuing in html5
On 12/11/2013 10:24 AM, Nicolas Goaziou wrote: Hello, Scott Randby sran...@gmail.com writes: On 12/11/2013 10:04 AM, Nick Dokos wrote: Scott Randby sran...@gmail.com writes: I tried C-c C-c on the #+OPTIONS line and I tried killing the file and opening it up again---neither works. I looked in the manual (section 12.3) and noticed that html5-fancy: is not on the list of arguments recognized by the #+OPTIONS keyword. It's documented in section 12.6.2, HTML doctypes. Yes, I had seen that documentation earlier, but I can't get it to work. I have no idea what the trouble could be. Any suggestions? You also need to set `org-html-doctype' to html5 or some such in order to make html5-fancy effective. I already have the following in my file: #+HTML_DOCTYPE: html5 Scott Regards,
Re: [O] TikZ (circuitikz) and org-preview-latex-fragment don't play nicely together
Mark Edgington edgi...@gmail.com writes: Nicolas Goaziou n.goaziou at gmail.com writes: You can remove offending packages with `org-export-before-parsing-hook' if you don't want them to be used during the export process. Yes, but I need the package which is buggy. If I were to remove it, I couldn't preview latex fragements or export a PDF file. If you need a package only in LaTeX fragments, you can customize `org-format-latex-header'. Regards, -- Nicolas Goaziou
Re: [O] Leading headline of a subtree tag export
Hello, Scott Randby sran...@gmail.com writes: I had a file with the following structure: #+OPTIONS: tags:nil * Grades ** Student :studenttag: :PROPERTIES: :EXPORT_FILE_NAME: Exported-Grades/studenttag :END: *** Totals :totals: Content Whenever I exported the entire file, no tags were exported (what I want). However, whenever I exported the Student subtree, the tag for that subtree was exported (not what I want) but the tag for the Totals subtree was not exported (what I want). Then I tried the following: #+OPTIONS: tags:nil * Grades ** Student :studenttag: :PROPERTIES: :EXPORT_FILE_NAME: Exported-Grades/studenttag :EXPORT_OPTIONS: tags:nil :END: *** Totals :totals: Content The tag for the Student subtree is still exported when I export the Student subtree. How do I prevent this tag from being exported when I export the subtree? During a subtree export, the root headline becomes document's title, so tags:nil no longer applies. By default everything is included, todo keyword and tags. You can specify another title with :EXPORT_TITLE:, e.g. :EXPORT_TITLE: Student Regards, -- Nicolas Goaziou
Re: [O] publishuing in html5
Scott Randby sran...@gmail.com writes: I already have the following in my file: #+HTML_DOCTYPE: html5 You need to upgrade Org then. Regards, -- Nicolas Goaziou
Re: [O] publishuing in html5
On 12/11/2013 11:03 AM, Nicolas Goaziou wrote: Scott Randby sran...@gmail.com writes: I already have the following in my file: #+HTML_DOCTYPE: html5 You need to upgrade Org then. Okay, I will do that. Scott Regards,
Re: [O] Leading headline of a subtree tag export
On 12/11/2013 10:57 AM, Nicolas Goaziou wrote: Hello, Scott Randby sran...@gmail.com writes: I had a file with the following structure: #+OPTIONS: tags:nil * Grades ** Student :studenttag: :PROPERTIES: :EXPORT_FILE_NAME: Exported-Grades/studenttag :END: *** Totals :totals: Content Whenever I exported the entire file, no tags were exported (what I want). However, whenever I exported the Student subtree, the tag for that subtree was exported (not what I want) but the tag for the Totals subtree was not exported (what I want). Then I tried the following: #+OPTIONS: tags:nil * Grades ** Student :studenttag: :PROPERTIES: :EXPORT_FILE_NAME: Exported-Grades/studenttag :EXPORT_OPTIONS: tags:nil :END: *** Totals :totals: Content The tag for the Student subtree is still exported when I export the Student subtree. How do I prevent this tag from being exported when I export the subtree? During a subtree export, the root headline becomes document's title, so tags:nil no longer applies. By default everything is included, todo keyword and tags. You can specify another title with :EXPORT_TITLE:, e.g. :EXPORT_TITLE: Student That worked. Thanks. Scott Regards,
Re: [O] [parser] subscripts and underlines interacting badly
Hi Nicolas, Thanks for your comments. 2013ko abenudak 11an, Nicolas Goaziou-ek idatzi zuen: Actually, this is not really a parser problem but a syntax one. underline and subscript are ambiguous, and therefore ill-defined, because, in some situations, both can match at the same location. I have found one case where both match, but an underline is intended. Are there any reverse cases, i.e. where both match but a subscript is intended? The closest I could come up with would be something like: The quantities X_1 and X_2 are But I think, at least with default values of org-emphasis-regexp-components, this cannot be an underline. So, if there are indeed no such cases, the fix is just to always choose the underline, when both underline and subscript match at the same position. Thanks for the patch. Though, the parser ignores `org-use-sub-superscripts' on purpose. At the moment `org-use-sub-superscripts' is a display variable only. This change happened in 8.0. This also explains why `org-export-with-sub-superscripts' is now a separate value from `org-use-sub-superscripts'. The main reason for this change is that I think that customizable syntax, unlike to customizable behaviour, is not a good idea for Org (e.g. portability and simplicity issues). I understand your point. But I think there is a danger in some cases that the tail of “portability” will wind up wagging the dog of org-mode. The syntax of org is an abstract mathematical object; the parser is just one (currently the only, AFAIK) implementation of it. So, if it proves necessary, some behavioral aspects can be added to the parser, as long as it is understood that they are behavioral and not driven by the abstract syntax (we could add such a comment to my patch, for example). I think it is advantageous to do so in this case. In the example I gave, two core parts of org (display and export) differ in their interpretation of the same string. Putting this behavior in the parser will fix that. It will also free future elisp code which consumes the parser’s output* from having to worry about the value of the variables in question. Finally, it would allow the re-unification of the export and display flavors of the use-subscripts variable. It’s hard to think of a use case that would want subscripts to be interpreted differently for display and export. (Although if someone has such a case, the unification need not be undertaken: it is purely optional.) Thanks again, -- Aaron Ecay
Re: [O] orgmod: R and threeparttable
On Wed, Dec 11, 2013 at 5:12 AM, Vikas Rawal
vikasli...@agrarianresearch.org wrote:
What is the best solution for the following scenario?
In my org file, I use an R source code to generate a table. I would like to
additionally specify notes to this table, and use threeparttable in latex
export to be able to specify notes below the table.
Can somebody point me to an example on how could this be done best?
I fiddled with this a little out of curiosity, and I'm not sure it's
going to work with the current #+attr_latex abilities. Someone more
familiar could correct me, though! I think the issue is that the
structure needs to be something like this:[1]
==
\begin{threeparttable}
\begin{tabular}{c c c c}
\toprule
\textbf{1st Column} \textbf{2nd Colimn} \textbf{3rd Colimn}
\textbf{4th Colimn} \\ \midrule
QWERTY\tnote{1} \\
ASDFGH\tnote{2}
\\ \bottomrule
\end{tabular}
\begin{tablenotes}
\item[1] qwerty; \item[2] asdfgh
\end{tablenotes}
\end{threeparttable}
==
[1] Taken from:
http://tex.stackexchange.com/questions/118743/threeparttable-notes-layout
But Org, I believe, can only wrap stuff in one \begin/end{} pair. So,
naively, I tried:
#+begin_src R :session r :exports results :results output wrap :eval no
library(ascii)
options(asciiType = org)
data - data.frame(a = 1:5, b = 6:10, c = 11:15)
cat(#+attr_latex: :environment threeparttable \n)
ascii(data, include.rownames = F, rownames = F, colnames = names(data))
#+end_src
#+RESULTS:
:RESULTS:
#+attr_latex: :environment threeparttable
| a| b | c |
|--+---+---|
| 1.00 | 6.00 | 11.00 |
| 2.00 | 7.00 | 12.00 |
| 3.00 | 8.00 | 13.00 |
| 4.00 | 9.00 | 14.00 |
| 5.00 | 10.00 | 15.00 |
:END:
It *sort of* works in that I get LaTeX table syntax wrapped with
\begin/end{threeparttable}, but then I caught that threeparttable is
actually a wrapper around tabular. Not sure how you can currently use
Org to specify two layered wrappers like that? Or you might need
someone to write an equivalent of #+begin/end_center for
threeparttable?
#+begin_threeparttable
table-generating-stuff
#+end_threeparttable
Even more complicate is that tabular ends, then a tablenotes
environment begins/ends, and only *then* does threeparttable end.
Sorry I couldn't be of more help. I wanted to post anyway so that
others might better understand how this is supposed to work. In the
future, I'd highly recommend posting some minimal code so others can
understand. At the very least, post some minimal LaTeX of the sort you
want as a result. Even better would be any Org-specific methods tried.
Otherwise, people scan the email, see threeparttable, have no
reference for it (like me) and probably just delete.
I happen to be on vacation with plenty of time for digging, so I dug
for a bit on this.
Best regards,
John
Vikas
Re: [O] Org-mode in windows fires Tramp without any intervention
Hi Michael, Trying to file a minimal init.el for bug reporting I discovered the culprit. In my init file I had: (setq org-agenda-files (concat org-directory /gtd.org)) The missing quote was causing Tramp to be ignited every time I opened a file or tried to open the agenda view. Thanks for the help. 2013/12/3 Michael Albinus michael.albi...@gmx.de Toni Cebrián ance...@gmail.com writes: Hi, Hi Toni, I have my own complex Emacs configuration files developed over time when working in a Linux environment. You can see that https://github.com/tonicebrian/emacsconfig in case you are curious. It works seamlessly in Linux and I tried to use that as-is when working in Windows. Emacs in Windows reads that configuration and fires up also without any warning. The problem comes when I try to open a complex Org file, with some links in it. I don't know why, but Tramp is fired and tries to ssh to the machines in one URL within a link element that has the form http://machine:8080/more/levels;. I don't even have the (require 'tramp) in my init.el file so this is something the Org mode plugging is doing by itself. By the way, the org mode version I have is org-20131202 from elpa and Emacs is 24.3.1 for Windows. Do you know where to look or what to try? This same Org file, the same init.el and the same emacs version work without any problem in Linux. Any clues? I guess something of the decoded URL, like /machine:8080, is treated as remote file name Tramp feels responsible for. Could you please send a short example file which triggers the bug? I would try to debug it then. Please note that I don't use org regularly, so some comments on what to do with that file would be helpful. Best regards, Michael.
Re: [O] [parser] subscripts and underlines interacting badly
Aaron Ecay aarone...@gmail.com writes:
I have found one case where both match, but an underline is intended.
Are there any reverse cases, i.e. where both match but a subscript is
intended?
I don't know. Perhaps something as convoluted as:
A'_{a_-1}
But that's not the real problem: whenever we change underline syntax
(e.g. if we implement escaped characters), we will start over again, as
more ambiguous cases might spawn.
So, if there are indeed no such cases, the fix is just to always choose
the underline, when both underline and subscript match at the same
position.
As a short term solution, it can be implemented (it's probably just
a matter of reordering successors calls). But in the long run, we really
need to define properly both syntax.
I understand your point. But I think there is a danger in some cases
that the tail of “portability” will wind up wagging the dog of org-mode.
The syntax of org is an abstract mathematical object; the parser is just
one (currently the only, AFAIK) implementation of it. So, if it proves
necessary, some behavioral aspects can be added to the parser, as long
as it is understood that they are behavioral and not driven by the
abstract syntax (we could add such a comment to my patch, for
example).
I'm strongly against behavioral parts in Org syntax (even though the
ship probably has sailed long ago). Org mode is bound to Emacs, but Org
format should be platform independent.
I think it is advantageous to do so in this case. In the example I
gave, two core parts of org (display and export) differ in their
interpretation of the same string. Putting this behavior in the parser
will fix that. It will also free future elisp code which consumes the
parser’s output* from having to worry about the value of the variables in
question.
Finally, it would allow the re-unification of the export and display
flavors of the use-subscripts variable. It’s hard to think of a use
case that would want subscripts to be interpreted differently for
display and export. (Although if someone has such a case, the
unification need not be undertaken: it is purely optional.)
Note that in my post, I said at the moment. There are two variables
for historical reasons. AFAIC some `org-export-with-*' variables don't
make much sense anyway (`org-export-with-tables' comes to mind, but also
`org-export-with-sub-superscripts').
The real question is: why would we need to disable superscript/subscript
in an Org document? We probably need it because they can get in the way
sometimes. Then, we'd better provide tools to put them out of that way
instead of completely disabling them. Character escaping is one
solution.
Again, I strongly think we should focus on making Org syntax simpler
(and yet powerful) instead of piling up variables to change it on the
fly for occasional needs.
Regards,
--
Nicolas Goaziou
[O] Old style backquotes in ox-texinfo.el
Incidentally, while I was trying different versions last night (for the LaTeX starred-figure issue), I saw the following warnings during make: In toplevel form: ox-texinfo.el:1683:1:Warning: !! The file uses old-style backquotes !! This functionality has been obsolete for more than 10 years already and will be removed soon. See (elisp)Backquote in the manual. ox-texinfo.el:1717:1:Warning: !! The file uses old-style backquotes !! This functionality has been obsolete for more than 10 years already and will be removed soon. See (elisp)Backquote in the manual. I don't see that this is logged at http://orgmode.org/worg/org-issues.html -- while it's not a critical issue obviously, it seems untidy and I'm at pains to imagine a good reason to retain syntax that has been deprecated for such a long time. hjh
Re: [O] ox-latex: Is \uline really right for underlining?
On Wednesday, December 11, 2013 10:47:42 PM HKT, Nicolas Goaziou wrote: Is ulem one of the LaTeX export default packages? Yes, it is. See `org-latex-default-packages-alist'. Ah... I must have customized that at some point. Drifting off the topic slightly, to a related question. I have a feeling that something is a bit off in my installation. If I do M-x customize-group ret org-export ret, I have two links to Org Export LaTeX: Org Export LaTeX : Options for exporting Org-mode files to LaTeX. Org Export LaTeX : Options for exporting Org-mode files to PDF, via LaTeX. I think this is the source of some of my confusion about these export options. Which one is current? Then I can figure out where the other one is coming from and make sure it doesn't get loaded. Thanks, hjh
Re: [O] [babel] Lisp error: (void-variable params)
Achim Gratz strom...@nexgo.de writes: Eric Schulte writes: I just pushed up a change which fixes this when exporting on my system, if the problem persists please provide an ECM. This test is still failing: Test test-ob/noweb-expansions-in-cache condition: (void-variable foo) FAILED 149/491 test-ob/noweb-expansions-in-cache Apparently foo didn't get expanded before eLisp tries to interpret the code. This should be fixed now. Regards, Achim. -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] Old style backquotes in ox-texinfo.el
James Harkins jamshar...@gmail.com writes: Incidentally, while I was trying different versions last night (for the LaTeX starred-figure issue), I saw the following warnings during make: In toplevel form: ox-texinfo.el:1683:1:Warning: !! The file uses old-style backquotes !! This functionality has been obsolete for more than 10 years already and will be removed soon. See (elisp)Backquote in the manual. ox-texinfo.el:1717:1:Warning: !! The file uses old-style backquotes !! This functionality has been obsolete for more than 10 years already and will be removed soon. See (elisp)Backquote in the manual. I can't reproduce this. The lines that throw warnings for you are both docstrings with the version of ox-texinfo.el I just pulled from git-master. hth, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] ox-latex: Is \uline really right for underlining?
On Thu, Dec 12, 2013 at 10:40 AM, James Harkins
jamshar...@dewdrop-world.net wrote:
On Wednesday, December 11, 2013 10:47:42 PM HKT, Nicolas Goaziou wrote:
Is ulem one of the LaTeX export default packages?
Yes, it is. See `org-latex-default-packages-alist'.
Ah... I must have customized that at some point.
And... I just found why I had customized it. It was because of
hyperref's (idiotic) default behavior of drawing red boxes around
links.
I'm not sure how ulem didn't make it into my customized setting.
Maybe ulem was added to the default packages list after I made the
customization.
What's the best way to handle that? I really want the hidelinks
option for hyperref to be used globally. But, customizing
org-latex-default-packages-alist means that I will miss updates to
that variable in future org versions.
Should I leave org-latex-default-packages-alist alone, and add my own
entry for hyperref into org-latex-packages-alist? (Would there be any
ill effect from having two \usepackage{hyperref} lines in the
preamble, with different options?)
hjh
Re: [O] LaTeX export with listings: multicolumn support broken?
On Wed, Dec 11, 2013 at 11:22 PM, Nicolas Goaziou n.goaz...@gmail.com wrote: Your first attr_latex line applies to the figure special block, not to the source block. I did eventually figure that out. As far as I can see, this is the only reference to figure* environments in the manual: ~~ multicolumn: if you wish to include an image which spans multiple columns in a page. This will export the image wrapped in a figure* environment. ~~ It's a reasonable (though wrong) conclusion from this that multicolumn is /the/ way to get figure*. I think it would be worth noting in the Special blocks in LaTeX export section that * is valid as a character in special block identifiers. hjh
Re: [O] ox-latex: Is \uline really right for underlining?
Hi James,
2013ko abenudak 12an, James Harkins-ek idatzi zuen:
What's the best way to handle that? I really want the hidelinks
option for hyperref to be used globally. But, customizing
org-latex-default-packages-alist means that I will miss updates to
that variable in future org versions.
Should I leave org-latex-default-packages-alist alone, and add my own
entry for hyperref into org-latex-packages-alist? (Would there be any
ill effect from having two \usepackage{hyperref} lines in the
preamble, with different options?)
I don’t know for certain if having two \usepackages would have bad
effects, but my vague feeling is that you will be fussed at by the
LaTeX compiler and/or the options specified in the two instances will
not compose in the desired way.
You probably want the \hypersetup command (q.v. in the hyperref manual).
You can add it to the ‘org-latex-classes’. You probably want something
like the following, slightly modified from the default:
((article
\\documentclass[11pt]{article}
\[DEFAULT-PACKAGES]
\[PACKAGES]
\hypersetup{hidelinks=true} % --- the important bit
\[EXTRA]
(\\section{%s} . \\section*{%s})
(\\subsection{%s} . \\subsection*{%s})
(\\subsubsection{%s} . \\subsubsection*{%s})
(\\paragraph{%s} . \\paragraph*{%s})
(\\subparagraph{%s} . \\subparagraph*{%s})))
HTH,
--
Aaron Ecay
Re: [O] [parser] subscripts and underlines interacting badly
2013ko abenudak 11an, Nicolas Goaziou-ek idatzi zuen:
Aaron Ecay aarone...@gmail.com writes:
I have found one case where both match, but an underline is intended.
Are there any reverse cases, i.e. where both match but a subscript is
intended?
I don't know. Perhaps something as convoluted as:
A'_{a_-1}
Oh, yes. Very clever. Unfortunately, it means that a fix, even a
temporary one, cannot be just to prioritize underline over subscript as
I proposed. =/
As a short term solution, it can be implemented (it's probably just
a matter of reordering successors calls). But in the long run, we really
need to define properly both syntax.
I agree. Do you think it is possible to solve the problem while
preserving the fact that underscore is used for both subscript and
underline? It seems very difficult.
When I think about the question, I think probably what is needed is a
representation where object boundaries are delimited by one well-defined
pair of delimiters, like {} in latex or in html (well, in html they
delimit tags, but the principle is the same: only one pair). Then we
don’t have to worry about escape syntax for many characters, or
characters with multiple possible interpretations (or how many lines
org-emph-re is allowed to match across, or ...).
But that is just one idea I have had. You must have thought about it
more, so maybe you have others.
I'm strongly against behavioral parts in Org syntax (even though the
ship probably has sailed long ago). Org mode is bound to Emacs, but Org
format should be platform independent.
Org syntax can be un-configurable even if org-element.el implements a
(configurable) superset of it. Given that the use-subscript variable
exists (and without taking into account more systemic solutions as
discussed above), I’m arguing that it is cleaner to implement it in
org-element, rather than in two separate places (in the regex-based
old-style parsing code in org.el and in ox.el; there’s also one
reference to the variable in org-table.el(!))
Phrased in other terms, it makes no sense (in the context of Org-Mode,
not platonic Org Syntax) for org-element to insist that a_b is a
subscript, if org-use-sub-superscripts =
org-export-with-sub-superscripts = nil.
Thanks,
--
Aaron Ecay
