Luis writes:
> Still get the build error: org-html-table-cell: Args out of range:
> [left left left], 3
It would be easier to help if you provided the code you're trying to
export, e.g:
#+BEGIN_SRC org
* A heading
Some text
#+BEGIN_VERBATIM
| this is cool ---> org-mode |
#+END_VERBATIM
#+END
Still get the build error: org-html-table-cell: Args out of range: [left
left left], 3
On Thu, Apr 21, 2016 at 10:33 AM, Adam Porter wrote:
> I think you're looking for #+BEGIN_VERBATIM. :)
>
>
>
--
Best Regards,
Zhengchao Xu
I think you're looking for #+BEGIN_VERBATIM. :)
Hi everyone,
I am using some "ascii drawings" in my post, but I have some problems
while exporting to html.
this is my ascii drawing in my org file.
(1) When i use* #+BEGIN_HTML,* the ascii exported as plain text. as this:
- |parent | screen | | |view | -
nljlistb...@gmail.com (N. Jackson) writes:
> For several months now I have been getting the error "File mode
> specification error: (error Before first heading)" when I open some of
> my Org files. [After the error message, the file opens just fine and Org
> works normally.]
I'm not able to repro
For several months now I have been getting the error "File mode
specification error: (error Before first heading)" when I open some of
my Org files. [After the error message, the file opens just fine and Org
works normally.]
What distinguishes the Org files that do not suffer from this problem
fr
fm4d writes:
> Yes, well, I did not dig deeper into the 'maint' branch to find the
> exact commit that caused it and since I managed to fix it and nobody
> else is able to reproduce the issue I dont think I will.
I understand. OTOH, if you find the energy to dig deeper, it may help us
understand
Hello,
Frederick Giasson writes:
> Any news regarding these latest fixes to that patch?
They look good. Thank you for the heads-up.
Could you merge patches 1 2 and 5 (Org series) into a single one for
inclusion?
As for 3 and 4, I think a more general mechanism for asynchrnous
eval'ing would b
Nicolas Goaziou writes:
> Hello,
>
> fm4d writes:
>
>> I believe that this diff is part of that commit -
>> http://repo.or.cz/org-mode.git/blobdiff/1045e9e9c0e6438f5ee9dc4f0e5c720a8b670cdd..a311a856514e9245074b02c89d51a9f339784d1c:/lisp/org.el
>
> The commit you point to is a branch merge. It
Hello,
John Kitchin writes:
> I think it would be fine to make :lexical "no" be the default, since
> that should preserve what we are used to. Users can alway set a
> different default of their own, or make it "yes" when they know it is
> needed.
Fair enough. Done. Thank you.
Regards,
--
Nic
Hello,
fm4d writes:
> I believe that this diff is part of that commit -
> http://repo.or.cz/org-mode.git/blobdiff/1045e9e9c0e6438f5ee9dc4f0e5c720a8b670cdd..a311a856514e9245074b02c89d51a9f339784d1c:/lisp/org.el
The commit you point to is a branch merge. It is a kind of "meta commit"
that incorpo
Hello,
bh...@despammed.com (Berthold Höllmann) writes:
> Even so there seem to be two different routines for writing the column
> header for the first and the subsequent pages (in the first one the \\
> follows directly to the '}', whereas the second time a space is added),
> it seems, the string
Hello,
timor writes:
>> If that's the case, we could indeed remove the duplicate '(123 . 125).
> Very nice.
Done, in master branch.
There are actually no tests for org-bibtex.el. Anyone using this library
(or not!) is more than welcome to write some, BTW.
Regards,
--
Nicolas Goaziou
On Wed, Apr 20 2016, Nick Dokos wrote:
> Colin Baxter writes:
>
>> The file /lisp/ox-html.el of org-mode release_8.3.4-743-g516bbf has
>> binary content at line 1952, whereas the same file of org-mode
>> release_8.3.4-721-g16ad80 has not. Perhaps this is significant.
>>
>
> Perhaps I'm missing so
Michael Welle writes:
> Hello,
>
> Sharon Kimble writes:
>
>> How can I have a task which when I change its state from TODO or NEXT to
>> IN-PROGRESS starts clocking it until its state is changed back from
>> IN-PROGRESS to some other state, when the clocking will cease?
>
> you can utilise the
I believe that this diff is part of that commit -
http://repo.or.cz/org-mode.git/blobdiff/1045e9e9c0e6438f5ee9dc4f0e5c720a8b670cdd..a311a856514e9245074b02c89d51a9f339784d1c:/lisp/org.el
Nicolas Goaziou writes:
> Hello,
>
> fm4d writes:
>
>> Well, the behaviour is IMO different because something
Colin Baxter writes:
> The file /lisp/ox-html.el of org-mode release_8.3.4-743-g516bbf has
> binary content at line 1952, whereas the same file of org-mode
> release_8.3.4-721-g16ad80 has not. Perhaps this is significant.
>
Perhaps I'm missing something but I don't see anything like that.I also
I think it would be fine to make :lexical "no" be the default, since
that should preserve what we are used to. Users can alway set a
different default of their own, or make it "yes" when they know it is
needed.
Nicolas Goaziou writes:
> Hello,
>
> John Kitchin writes:
>
>> Set default in `org-ba
Hi Nicolas,
Any news regarding these latest fixes to that patch?
Thanks,
Fred
Here is my proposal to create a new :async feature for
Org-babel-clojure. This is discussed at length in this blog post:
http://fgiasson.com/blog/index.php/2016/04/05/using-clojure-in-org-mode-and-implementing-a
On Wed, Apr 20 2016, Alan Schmitt wrote:
> On 2016-04-20 07:59, Colin Baxter writes:
>
>> On Tue, Apr 19 2016, Nicolas Goaziou wrote:
>>
>>> Hello,
>>>
>>> Colin Baxter writes:
>>>
With the latest org-mode release_8.3.4-739-g7894129, I'm getting an lisp
error
(invalid-read-syntax
2016-04-20 9:45 GMT+02:00 Eric S Fraga :
> So it's not just the title that needs to be
> treated carefully but other entries (author, editor, booktitle).
You are correct. The piece of code in question is actually called for
all fields, not only title. I was using the title as an example. So
if
On Tuesday, 19 Apr 2016 at 20:43, timor wrote:
> Yes. Looking at the BibTeX Files I am dealing with, the use of inner
> braces is usually justified (except for the example I gave, but it is
> not org-mode's job to correct poor BibTeX, I think). Therefore they
> should be kept intact when reading t
On Tuesday, 19 Apr 2016 at 19:54, Uwe Brauer wrote:
> Cool, thanks very much I tried out
>
> | name | result | @@html:@@
> | Smith | 10 | @@html:@@
>
> Which does almost all I want, it inserts an empty third column, but I
> presume this cannot be changed?
Without real hackery, not unless
Hello,
John Kitchin writes:
> Set default in `org-babel-default-header-args:emacs-lisp'. Add an
> optional argument to the eval function.
Applied. Thank you.
However, it seems that some tests are now failing. I guess this is
related to Babel calls, which are eval'ed as emacs-lisp source blocks
How can I have a task which when I change its state from TODO or NEXT to
IN-PROGRESS starts clocking it until its state is changed back from
IN-PROGRESS to some other state, when the clocking will cease?
Any ideas please?
Thanks
Sharon.
--
A taste of linux = http://www.sharons.org.uk
TGmeds = ht
On Tue, Apr 19 2016, Nicolas Goaziou wrote:
> Hello,
>
> Colin Baxter writes:
>
>> With the latest org-mode release_8.3.4-739-g7894129, I'm getting an lisp
>> error
>> (invalid-read-syntax "#"). This ocurs with emacs-25.1.50.1 and
>> emacs-24.5.1.
>
> Could you provide an ECM? What command trigg
On Tue, Apr 19 2016, Nicolas Goaziou wrote:
> Hello,
>
> Colin Baxter writes:
>
>> The line
>>
>> (expand-file-name "../../etc/styles/" org-odt-lib-dir) ; git
>>
>> in the defconst org-odt-styles-dir-list at line 181 of ox-odt.el points to
>> "git/org-mode/lisp/etc/styles/". Should it not point
Thanks for reporting the problem. As Eli suggested, it was a typo in org.el that
was exposed by recent changes to encode-time. I installed into master the
attached patch, which I think fixes the bug.
From 313e98ceb078468498998305749b2790b7ba Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: W
28 matches
Mail list logo
