Hello,
When exporting a document containing calls to code blocks located in my LOB
(here: `vc-indicator'), I have -- with latest Org version -- a new problem (I
mean, it wasn't there a couple of days ago):
Debugger entered--Lisp error: (void-function
org-babel-named-data-regexp-for-name)
It s
#+TITLE: ECM for code blocks not being ingested anymore
#+DATE: 2011-12-02
#+PROPERTY: eval yes
* Overview
Ingesting a LOB file does not load its code blocks anymore -- as if the file
was empty, or if there were no code blocks at all in it!
* Test case
** How many blocks?
There is 1
Jonathan Leech-Pepin writes:
> I'm not sure as to the reason why it does so, but based on your
> example, the formula is referencing the specific cell itself, rather
> than the relative position of the cell. If you change your formula to
> use a relative reference, it will continue to work even
Hi Christophe,
Could you provide us with a minimal example of how this new functionality
can be used?
I am trying to test it and see if there are any conflicts with my patch of
late to supports the booktabs package @
http://patchwork.newartisans.com/patch/1016/ (aside from one of the two
patches
Niels Giesen writes:
> Could you provide us with a minimal example of how this new functionality
> can be used?
Sure, sorry. Here we go:
--- start here ---
#+TITLE: Example of using hfmt
#+AUTHOR: Christophe Rhodes
* Introduction
This document shows the use of the =hfmt= tag in =#+LaTeX_ATT
Hi, Rajat --
-Original Message-
> > From: John Rakestraw [mailto:li...@johnrakestraw.com]
> > Sent: mercredi 30 novembre 2011 21:48
> > To: Mukherjee,Rajat,LAUSANNE,Clinical Operations
> > Cc: emacs-orgmode@gnu.org
> > Subject: Re: [O] Editing using emacs-lisp after export
> > Hi, Rajat
Hi all
Now that I use M-RET more often when editing lists I was about trying
to make a patch to remove what seems to me an inconsistency between
headings and list items. But after I have read the docstrings of
org-insert-item and org-list-insert-item the current behavior seems so
intentional that
According to this discussion on the mailing list,
http://comments.gmane.org/gmane.emacs.orgmode/48571 , this is a known
bug.
I fixed this by loading "org-compat" after requiring org-mode from
git, just like Sebastian said.
--
Kenny Meyer
On Thu, Dec 1, 2011 at 12:05 PM, Nick Dokos wrote:
> Ni
Hi everyone,
I'd love to use orgmode as my publishing framework for ebooks (mainly PDF).
I'd like some flexibility on defining the output. The thought of having to
use OpenOffice / Office or even Adobe Indesign to write text is daunting to
me. It might work for small reports, but for longer works,
Kenny Meyer wrote:
> According to this discussion on the mailing list,
> http://comments.gmane.org/gmane.emacs.orgmode/48571 , this is a known
> bug.
>
> I fixed this by loading "org-compat" after requiring org-mode from
> git, just like Sebastian said.
>
I don't think it's a bug in org: if yo
Hi Nick,
Nick Dokos wrote:
> Kenny Meyer wrote:
>> According to this discussion on the mailing list,
>> http://comments.gmane.org/gmane.emacs.orgmode/48571 , this is a known
>> bug.
>>
>> I fixed this by loading "org-compat" after requiring org-mode from
>> git, just like Sebastian said.
>
> I d
On Fri, Dec 02, 2011 at 02:09:22PM -0600, Marcelo de Moraes Serpa wrote:
> Hi everyone,
>
> I'd love to use orgmode as my publishing framework for ebooks (mainly PDF).
> I'd like some flexibility on defining the output. The thought of having to
> use OpenOffice / Office or even Adobe Indesign to wr
Aloha Marcelo,
Marcelo de Moraes Serpa writes:
> Hi everyone,
>
> I'd love to use orgmode as my publishing framework for ebooks (mainly PDF).
> I'd like some flexibility on defining the output. The thought of having to
> use OpenOffice / Office or even Adobe Indesign to write text is daunting t
If I export the following code to LaTeX:
--
#+begin_src R
CV.t.hat <- rowMeans(loss)[m]
CV.t.hat
#+end_src
#+results:
: [1] 1.135857
--
, then it looks like this in the *.tex file:
--
\begin{verbatim}
CV.t.hat <- rowMeans(l
Sebastien Vauban wrote:
> > I don't think it's a bug in org: if you start with a clean copy of the
> > repo (make clean; make) and have your load-path pointing there, you
> > should not see any problems.
> >
> > IIUC, Michael Bach's problem (a fairly common one, btw) was that he was
> > mixing di
Ken Williams writes:
[...]
> Would it be possible for the export process to define various classes
> that default to being exactly like 'verbatim', but could be
> customized? After that, a next step might be to provide nice defaults
> that do things like syntax-highlighting (through the 'minted
Niels Giesen wrote:
> Ken Williams writes:
>
>
> [...]
>
> > Would it be possible for the export process to define various classes
> > that default to being exactly like 'verbatim', but could be
> > customized? After that, a next step might be to provide nice defaults
> > that do things like
Is anybody here using Bozhidar Batsov's Emacs Prelude?
(https://github.com/bbatsov/emacs-prelude)
The reason I as is: by default it disables the Up, Down, Left, right
keys (in order to try to for users to learn the C-N, C-P, C-F, C-B, etc.
keys). This, of course, messes with the structure edi
At Fri, 02 Dec 2011 12:01:05 -0500,
emacs-orgmode-requ...@gnu.org wrote:
> Date: Fri, 2 Dec 2011 03:01:36 + (UTC)
> From: Herbert Sitz
> To: emacs-orgmode@gnu.org
> Subject: Re: [O] how to show deadlines in global to-do list?
>
> James Harkins gmail.com> writes:
>
> > I like the out-of-the-
Hello,
I've created a new export plugin for org-mode files for the ikiwiki wiki
compiler. It's in a very preliminary state at
https://github.com/chrismgray/ikiwiki-org-plugin
Just to prove that it is working to some extent, I am currently using it
to generate my blog at http://chrismgray.github.
20 matches
Mail list logo
