Re: [O] Citation syntax: a revised proposal
On Monday 16 February 2015 09:49 PM, Nicolas Goaziou wrote: [cite:subtype: whatever] Nicolas, if you could circulate a one-off patch that handles the above syntax I will bump it against the ODT backend and JabRef engine. I am waiting for the FSF representative to counter-sign my assignment papers (which is in transit). I would very much like to see Citation support in the ODT exporter and work with you see the feature all the way through to the main-line.
Re: [O] Citation syntax and ODT
More importantly I see Nicolas willing to make the necessary modifications to export engine. Let us JUST ACCEPT what Nicolas is saying and work from there. Otherwise, the current momentum will peter out (much like earlier initiatives). For now, if each of us could just step back a little and focus on getting just the nose inside the tent, it will be not long before the camel is inside the tent. If we are trying to get the whole camel head-body-and-tail, it is going to be a non-starter. I am seeing that Nicolas has strong ideas on how the syntax should look. He is dithering only because he wants someone to step forward and puncture his ideas. Instead of making fresh proposals, it would be efficacious if each of us could: 1. Orient ourselves in to puncturing the seat that Nicolas is sitting on. 2. Focus on the bare minimal functionality agreeable -- agreeable but MAY NOT be satisfactory -- to whole spectrum of users right from a kindergarterner to a post-doctoral fellow. Meanwhile, I am opened up a fresh channel with Nicolas as a self-appointed representative of ODT users...
Re: [O] Citation syntax and ODT
On Monday 23 February 2015 09:41 AM, Richard Lawrence wrote: Hi Vaidheeswaran, Thanks for your input about citations! Vaidheeswaran writes: Those working on the citation syntax should make it clear that the "lowest common" cite syntax does NOT also IMPOSE (or GUARANTEE) a specific style on the produced document. When I say this, I specifically mean: 1. I want my citation and references to be carried over FAITHFULLY to the exported document. 2. I DON'T CARE how (1) is styled. I'm afraid I don't quite understand your concern here. What does it mean to export a citation faithfully, but without imposing a particular style (or without giving it any specific formatting properties)? My understanding (based on the LaTeX world) is that a `style' defines a broad set of conventions for formatting citations and bibliographies in the output document. For example, a style might define citations to be author-year, or numerical. Within a style, individual citations can still have different formatting properties, such as whether it appears inside parentheses or not. User: I want 'Style Newyork'. ODT/Jabref: I don't have 'Style Newyork'. I can give you 'Style Chicago'. It is all that I have. We haven't really discussed how styles should be specified (yet), or the formatting of bibliographies. But we have been discussing a syntax that lets you specify those formatting properties which commonly differ between individual citations. IMO, it is better to roll out the citation feature WITHOUT any formatting properties. The specific formatting chosen is at the mercy of capabilities of the export backend or citation engine it works with. The above observations would translate to: The Cite object in it's SIMPLEST form specifies just a citekey (or a set of citekeys). The Cite-object is qualified with a footnote saying that any key-value pair -- including "type" -- that is specified with Cite object MAY BE IGNORED by a backend. If I understand what you're saying here correctly, I think this is too little to expect. If *all* the formatting information in a citation can be ignored by any backend, there isn't very much to be gained by having a citation syntax in Org. In Network protocols, the client and server can negotiate the parameters of a service. The actual service is at the intersection of client and server capabilities. The RFC itself states what every compliant client and server implementation should provide at the minimum. i.e., There is a basic service which is guaranteed. In our specific case, a backend like ODT will guarantee a readable and well-styled document limited from among the choice of styles that the citation engine -- for eg., Jabref -- itself supports. The document so produced may not be acceptable to a publishing house (Focus here is on a specific style). Neverthless, document will be respectable enough to be circulated among peers (for a review) or distributable to wider public (Focus here is on content rather than SPECIFIC style). Note that I am not speaking against Bells and Whistles. I am only saying that Bells and Whistles MUST NOT be imposed upon a backend like ODT where the available tools are NOT AS RICH OR AS MATURE AS that available with other backends like HTML or LaTeX. I don't really know anything about ODT. In particular, I don't know if ODT makes room for a distinction between the overall citation style and the formatting properties of individual citations. Can you say a bit more about what you think its limitations are? Obviously, we can't impose anything on the formatting of citations which the output document format is incapable of expressing. But I can't think of anything we've discussed for the main syntax that seems likely to be inexpressible in ODT. The question is not about expressibility. The question is about what is expressible using the current set of tools that are available off-the-shelf. Do you think of a scenario where: 1. Org acts like a citation engine. (A self-contained Org-ecosystem) 2. Org-backends interfaces with a 3rd-party engine (like pandoc, zotero, JabRef) If the current effort is to build (1), ODT backend will have no reason to complain. If the effort is geared more towards (2), the ground reality is that JabRef's style catalog is not as extensive or mature as, say Zotero's or LaTeXs. The implication is that the PDF document produced via the LaTeX document WILL DIFFER IN STYLE from the PDF document produced via the ODT backend. I am imagining something along a mix of (1) and (2), with more initial thrust in favor of (2). Have you had a chance to read the proposal that I sent around last weekend? Are there specific features of the main syntax described there (ignoring the `%%(...)' part, which it now appears will be dropped) that you don't t
Re: [O] Citation syntax and ODT
Hi Vaidheeswaran, Thanks for your input about citations! Vaidheeswaran writes: > Those working on the citation syntax should make it clear that the > "lowest common" cite syntax does NOT also IMPOSE (or GUARANTEE) a > specific style on the produced document. > > When I say this, I specifically mean: > > 1. I want my citation and references to be carried over FAITHFULLY to >the exported document. > > 2. I DON'T CARE how (1) is styled. I'm afraid I don't quite understand your concern here. What does it mean to export a citation faithfully, but without imposing a particular style (or without giving it any specific formatting properties)? My understanding (based on the LaTeX world) is that a `style' defines a broad set of conventions for formatting citations and bibliographies in the output document. For example, a style might define citations to be author-year, or numerical. Within a style, individual citations can still have different formatting properties, such as whether it appears inside parentheses or not. We haven't really discussed how styles should be specified (yet), or the formatting of bibliographies. But we have been discussing a syntax that lets you specify those formatting properties which commonly differ between individual citations. > > > The above observations would translate to: > > The Cite object in it's SIMPLEST form specifies just a citekey (or a > set of citekeys). The Cite-object is qualified with a footnote saying > that any key-value pair -- including "type" -- that is specified with > Cite object MAY BE IGNORED by a backend. > If I understand what you're saying here correctly, I think this is too little to expect. If *all* the formatting information in a citation can be ignored by any backend, there isn't very much to be gained by having a citation syntax in Org. > > Note that I am not speaking against Bells and Whistles. I am only > saying that Bells and Whistles MUST NOT be imposed upon a backend like > ODT where the available tools are NOT AS RICH OR AS MATURE AS that > available with other backends like HTML or LaTeX. I don't really know anything about ODT. In particular, I don't know if ODT makes room for a distinction between the overall citation style and the formatting properties of individual citations. Can you say a bit more about what you think its limitations are? Obviously, we can't impose anything on the formatting of citations which the output document format is incapable of expressing. But I can't think of anything we've discussed for the main syntax that seems likely to be inexpressible in ODT. Have you had a chance to read the proposal that I sent around last weekend? Are there specific features of the main syntax described there (ignoring the `%%(...)' part, which it now appears will be dropped) that you don't think ODT or other backends can support? If so, I think that is a concern, and should be discussed. Best, Richard
Re: [O] mdframed blocks for latex export
Aloha Vikas,
Vikas Rawal writes:
> In a document I am preparing using Org-mode, I need to create some
> “boxes” containing text, tables and figures. In LaTeX, mdframed seems
> to be the way to go. Is there a way to do it in Org-mode? How do I
> define something like
>
> #+begin_mdframed
> Contents of the box go here
> #+end_mdframed
I think you've found the answer.
This Org mode code:
,-
| #+attr_latex: :options [foo]
| #+begin_mdframed
| Contents of box go here.
| #+end_mdframed
`-
exports this valid mdframed code to LaTeX:
\begin{mdframed}[foo]
Contents of box go here.
\end{mdframed}
hth,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] mdframed blocks for latex export
This is a place where I would resort to raw latex, probably in
#+begin_latex
\begin{mdframed}
...
\end{mdframed}
#+end_latex
Vikas Rawal writes:
> In a document I am preparing using Org-mode, I need to create some “boxes”
> containing text, tables and figures. In LaTeX, mdframed seems to be the way
> to go. Is there a way to do it in Org-mode? How do I define something like
>
> #+begin_mdframed
> Contents of the box go here
> #+end_mdframed
>
> Would appreciate a pointer to the right method.
>
> Thanks,
>
> Vikas
--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
[O] mdframed blocks for latex export
In a document I am preparing using Org-mode, I need to create some “boxes” containing text, tables and figures. In LaTeX, mdframed seems to be the way to go. Is there a way to do it in Org-mode? How do I define something like #+begin_mdframed Contents of the box go here #+end_mdframed Would appreciate a pointer to the right method. Thanks, Vikas
[O] Table notes (below table) in LaTeX?
Hi,
I have a document with over 50 tables and I need to indicate data
sources right below every table. Looking through the list I've found the
workaround below, but it's rather syntax heavy, and places the table
notes a little too far from the actual table.
#+CAPTION: Tanzania Segmentation (Scheme #1, 23 Segments)
#+NAME: tab:tza-seg1
#+ATTR_LATEX: :environment tabu :align lrrr
#+begin_threeparttable
| Segment | Area | Population | Population |
| | || Density |
| | /sq. km./ || /pp/sq. km./ |
|---+---++--|
||| | |
| BC, CM| 4,178 |983,305 | 235 |
| BC, CM, RS-WR | 9,057 |672,557 | 74 |
| BC, ML| 7,618 |358,121 | 47 |
| SM, CM|11,836 | 2,288,607 | 193 |
| TM|23,958 | 1,287,792 | 54 |
#+begin_tablenotes
_Source_: authors and other notes and data sources.
#+end_tablenotes
#+end_threeparttable
Instead I'd like to simply place all data sources and notes in a bottom
row (as in the LaTeX fragment below).
\begin{table}[htb]
\caption{\label{tab:tza-seg1}Tanzania Segmentation (Scheme \#1, 23
Segments)}
\centering
\begin{tabu}{lrrr}
\toprule
Segment & Area & Population & Population\\
& & & Density\\
& \emph{sq. km.} & & \emph{pp/sq. km.}\\
\midrule
BC, CM & 4,178 & 983,305 & 235\\
BC, CM, RS-WR & 9,057 & 672,557 & 74\\
BC, ML & 7,618 & 358,121 & 47\\
RS-WR & 13,729 & 412,623 & 30\\
RS, CM & 10,959 & 1,059,554 & 97\\
SM & 5,592 & 514,030 & 92\\
SM, CM & 11,836 & 2,288,607 & 193\\
TM & 23,958 & 1,287,792 & 54\\
\bottomrule
Source: authors and other notes and data sources.\\
\end{tabu}
\end{table}
Any tip to achieve this without using threeparttable?
Thanks, --Mel.
--
Melanie BACOU
International Food Policy Research Institute
Snr. Program Manager, HarvestChoice
E-mail m.ba...@cgiar.org
Visit www.harvestchoice.org
Re: [O] Publishing orgmode files
Hi, Xavier Maillard writes: > I am trying to publish my org project but I am lost in the way I can > tweak my projects. > > Is there some good tutorial I can follow step by step in order to > publish several files at once ? I am still stuck :( I read a lot of thing but I am lost with that specific task. Any help really appreciated here :) -- Xavier, signature.asc Description: PGP signature
[O] duplicate PROPERTIES drawers
I have found many task with duplicate PROPERTIES drawers. I saw mention on the list that, "...it will be invalid for a LOGBOOK to appear before PROPERTIES in Org 8.3." It seems that tasks don't have properties by default, and if I LOG an item, I get a LOGBOOK drawer. If properties are added later (by touching the item with MobileOrg, or adding a property with "C-c C-x p", then PROPERTIES go below the LOGBOOK. I'm not sure what is going on to create the second PROPERTIES drawer. Has anyone else seen this? Any ideas what I am doing wrong. I've found many of these tasks manually. I haven't been able to search and list them progragmatically (I've been trying using grep and other shell tools on my Org files). Is there a way to list all tasks with duplicate properties, or all tasks where :PROPERTIES: is not the first item listed, if that is a requirement? Thanks, -k.
Re: [O] [bug?, ox] smartquotes and lines
Hello, Rasmus writes: > Consider this example: > > #+OPTIONS: ':t > "foo"---"bar" > > Expected output is (IMO) something like “foo”—“bar”. Actual output is > something like “foo"—"bar”, i.e. the quotes very close to the em-dash are > not replaced. Note you can get the desired output by adding spaces around > the em-dash but that's undesirable in this case. > > Is this a feature? This is a limitation due to the regexps used by smart quotes. You can always defeat them. Regards, -- Nicolas Goaziou
[O] Manual patch: noweb header argument
Aloha all,
The attached patch recognizes all six possible :noweb header arguments.
All the best,
Tom
>From 3106e37ba1cfd7fa8e7c1a792a7c69cf76aa5343 Mon Sep 17 00:00:00 2001
From: tsdye
Date: Sun, 22 Feb 2015 07:20:34 -1000
Subject: [PATCH] Revise noweb header argument
---
doc/org.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index 5b4862b..99c6819 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -15618,8 +15618,8 @@ the same session. Using different session names enables concurrent sessions
The @code{:noweb} header argument controls expansion of ``noweb'' syntax
references (see @ref{Noweb reference syntax}) when the code block is
evaluated, tangled, or exported. The @code{:noweb} header argument can have
-one of the five values: @code{no}, @code{yes}, @code{tangle}, or
-@code{no-export} @code{strip-export}.
+one of six values: @code{no}, @code{yes}, @code{tangle}, @code{no-export},
+@code{strip-export}, or @code{eval}.
@itemize @bullet
@item @code{no}
--
2.3.0
--
T.S. Dye & Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com
Re: [O] how to get images support in Emacs on Windows?
Ben gmail.com> writes: > Actually, I use few inline images. Most of my images are large. They should be resized to look pretty on emacs. But to resize them I need to build emacs with ImageMagick. And I haven't tried that yet. > Are you sure you need to rebuild Emacs? On my Linux machine I run a standard version of Emacs 24.3 binaries that I got from the Linux Mint repository. It supports using (a separately installed) Imagemagick to reduce size of inline images. I can't get it to work automatically in Org-mode, but I think that's because I need a more recent version of Org-mode. I'm running v.7.9.3f of Org-mode. To test Imagemagick support I'm running the test code made available in this post: http://article.gmane.org/gmane.emacs.orgmode/90278 I think the original poster in that thread said he couldn't get it to work in Org-mode until he had updated his Org-mode version. -- Herb
[O] [bug?, ox] smartquotes and lines
Hi, Consider this example: #+OPTIONS: ':t "foo"---"bar" Expected output is (IMO) something like “foo”—“bar”. Actual output is something like “foo"—"bar”, i.e. the quotes very close to the em-dash are not replaced. Note you can get the desired output by adding spaces around the em-dash but that's undesirable in this case. Is this a feature? Thanks, Rasmus -- Er du tosset for noge' lårt!
Re: [O] Babel: Call A when executing B
Aloha Ken,
I'm not sure what you mean by "anything else of that type", but
executing a named code block in other code blocks can be achieved with
the noweb syntax.
#+name: packages-that-make-iPython-great
#+begin_src python
import numpy as np
import foo as bar
...
#+end_src
#+header: :noweb yes
#+begin_src python
<>
...
#+end_src
hth,
Tom
Ken Mankoff writes:
> I'd like to have some language specific code (either a code block in the
> Library of Babel, in the current file, embedded in elisp in my startup
> file, wherever) run each time I execute any code block. Is there a way
> to specify this via header arguments, or :prologue, or anything else of
> that type?
>
> Reason: Org python Babel configured to work with IPython works great,
> but has some limitations, such as src_python{} calls not working. I
> think one way to fix this is to have babel run with python, not IPython,
> but then pre-load all the packages that make IPython great.
>
> To be specific, how can I executed "import numpy as np" each time I "C-c
> C-c" on a "+#BEGIN_SRC python" code block?
>
> Thanks,
>
> -k.
>
>
>
--
Thomas S. Dye
http://www.tsdye.com
[O] Babel: Call A when executing B
I'd like to have some language specific code (either a code block in the
Library of Babel, in the current file, embedded in elisp in my startup
file, wherever) run each time I execute any code block. Is there a way
to specify this via header arguments, or :prologue, or anything else of
that type?
Reason: Org python Babel configured to work with IPython works great,
but has some limitations, such as src_python{} calls not working. I
think one way to fix this is to have babel run with python, not IPython,
but then pre-load all the packages that make IPython great.
To be specific, how can I executed "import numpy as np" each time I "C-c
C-c" on a "+#BEGIN_SRC python" code block?
Thanks,
-k.
Re: [O] control tangling from section header
Hello Ken, Ken Mankoff writes: > I'm working with my literate init file (emacs.org), and would like to > have certain sections not tangle. I currently do this with ":tangle no" > at the SRC block level. Is it possible to control tangling with tags at > the header level? Not with tag but with PROPERTIES: * outline header :PROPERTIES: :header-args: :tangle no :END: More at http://orgmode.org/manual/Header-arguments-in-Org-mode-properties.html > It would make it much easier to disable/enable sections, and see what > sections are enabled/disabled, if the tangling state were more clearly > visible like tags are. I do not think that this is currently possible. Best, Daniele
[O] control tangling from section header
I'm working with my literate init file (emacs.org), and would like to have certain sections not tangle. I currently do this with ":tangle no" at the SRC block level. Is it possible to control tangling with tags at the header level? It would make it much easier to disable/enable sections, and see what sections are enabled/disabled, if the tangling state were more clearly visible like tags are. -k.
Re: [O] [RFC] Simplify `org-show-context' configuration
Samuel Wales writes: > looks good. > > thanks for your effort on making a single variable. Pushed with tests and documentation, in 4eb4f47141a1ac582330b903bd779dccbcb1c154. Thank you. Regards,
[O] Advice on handling translations in export
Just wondering if anyone has any experience with texts written in org, which then need to be translated. The simplest thing, of course, would be an org file for the original language, and then separate files for other languages. Markup and export are simpler this way, but future edits would be harder to sync. For the edit/sync problem (and also because hey, we're org users, meaning born tinkerers), I'm wondering if it's worth interleaving the languages in the same file, with some kind of tagging to select one or more languages for export. I'm struggling to imagine how that would look. Regular org tags wouldn't work because they're hierarchical, and there's no point in considering any sort of scheme for this if you can't keep original text and translation close together. Maybe language prefixes, which an export filter could process? Perhaps: * en: Hello fr: Bonjour To be honest, I'm a bit skeptical of doing this at all because it would be a chunk of work and it would clutter the org files visually. But if someone has figured out a clever way, I'd be curious to hear about it. Thanks in advance -- hjh Sent with AquaMail for Android http://www.aqua-mail.com
Re: [O] how to get images support in Emacs on Windows?
I haven't tried other types except jpeg and png. Actually, I use few inline images. Most of my images are large. They should be resized to look pretty on emacs. But to resize them I need to build emacs with ImageMagick. And I haven't tried that yet. On Sat, Feb 21, 2015 at 3:18 AM, Herbert Sitz wrote: > Ben gmail.com> writes: > > > > You can download the corresponding dlls from ezwinports [fn:1] and > put them into emacs's `bin` directory. > > > > There are some instructions in the "Image support" part on page [fn:2]. > > > > [fn:2] https://ftp.gnu.org/gnu/emacs/windows/ > > > > Strangely, the instructions and files work only for a couple formats I > tried. > > jpeg,png -- work perfectly > > svg -- works, but so far not inline. I.e., I can click on link and image > will show up in another Emacs buffer, but can't get it to show up inline. > > tiff -- can't get this to work at all. When clicking on it, it shows > character-mode garbage in separate buffer, along with error message. This > is despite fact that dynamic-library-alist shows the same files as I copied > to the bin folder. > > Not a huge deal for me, since jpeg and png are what I wanted most. But > still seems a little odd; I have no idea what problems are with svg and > tiff. >
[O] [BUG] babel hangs executing some shell commands in session
Hello, I am going to give an interactive presentation of git using org-mode and babel. But I am stuck with random hangs when executing the code with =C-c C-c= and during export. I am using Org-mode version 8.2.4 (8.2.4-dist @ /home/vagrant/.emacs.d/el-get/org-mode/lisp/) The hangs does not always happen, but if you execute the following code blocks a couple of times you should ran into the problem. Assumption: the file =/etc/sudoers= contains something like "vagrant ALL=(ALL) NOPASSWD:ALL" to not ask password with an interactive prompt. #+PROPERTY: header-args:shell :session *git-shell* :dir /vagrant #+PROPERTY: header-args:shell+ :exports both :results output verbatim replace #+PROPERTY: header-args:shell+ :tangle git_demo.sh :shebang "#!/bin/bash" :comments org #+BEGIN_SRC shell sudo apt-get remove --purge --yes git && sudo apt-get autoremove --yes #+END_SRC #+BEGIN_SRC shell sudo apt-get install --yes git #+END_SRC My guess, by looking at the *git-shell* buffer after waiting a minute and hitting C-g, is that the output of echo 'org_babel_sh_eoe' sometimes is eaten by some ansi sequence of the interactive command. See for example the following cut and paste from the *git-shell* buffer. Do babel do something nasty with the shell/term emulator? #+begin_example vagrant@git-pratical:/vagrant$ sudo apt-get remove --purge --yes git && sudo apt-get autoremove --yes Reading package lists... 0%echo 'org_babel_sh_eoe' Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: git-man liberror-perl Use 'apt-get autoremove' to remove them. The following packages will be REMOVED: git* 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. After this operation, 22.2 MB disk space will be freed. (Reading database ... 122644 files and directories currently installed.) Removing git (1:2.3.0-0ppa1~ubuntu12.04.1) ... Purging configuration files for git (1:2.3.0-0ppa1~ubuntu12.04.1) ... Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: git-man liberror-perl 0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded. After this operation, 1,477 kB disk space will be freed. (Reading database ... 122040 files and directories currently installed.) Removing git-man (1:2.3.0-0ppa1~ubuntu12.04.1) ... Removing liberror-perl (0.17-1.1) ... Processing triggers for man-db (2.6.7.1-1ubuntu1) ... vagrant@git-pratical:/vagrant$ #+end_example An indirect confirmation of my guess comes from a test: redirecting the output of the command and then printing it. Using this workaround babel never hangs: #+BEGIN_SRC shell (any_strange_command) 1>/tmp/1 2>/tmp/2; cat /tmp/1 /tmp/2 #+END_SRC Do you think that is easy to fix babel or can you suggest a less invasive and more comprehensive workaround? Wrapping loops and pipes is going to clutter the code to the point that is better to use a script with inline comments rather that using the org-mode buffer. Thanks in advance, Daniele
