[O] BUG org-bibtex error for importing bibtex conference entries

[Torsten Wagner]

Hi,
I was going to convert my bibtex file into an org-mode file.
I receive an error message for conference entries.
E.g.
I can read in by org-bibtex-read

@CONFERENCE{foo11,
  author = {foo, A. and faa, B},
  title = {This is the title},
  booktitle = {Proceeding of the 5th Org-mode conference},
  year = {2011},
  month = Jul,
  day = {4--5},
  conference_name = {org-mode V},
  keywords = {published},
  location = {Somewhere, org-land},
  presentation = {Oral}
}

However, org-bibtex-write results in the following output

*
and a debug error-log [1]:

By changing the bibtex type to e.g., INPROCEEDINGS  the import works correct.
I tried to debug this but I can't see why it works for inproceedings
and not for conference.

As a side note, I noticed that the importer is rather quite about
errors. If I try to import an mal-formated BibTeX entry I often
receive an result for which some keyword-entries are simply missing.
E.g. try

@INPROCEEDINGS{foo11,
  author = {foo, A. and faa, B},
  title = {This is the title},
  booktitle = {Proceeding of the 5th Org-mode conference},
  year = {2011},
  month = Jul,
  day = (4--5),
  conference_name = {org-mode V},
  keywords = {published},
  location = {Somewhere, org-land},
  presentation = {Oral}
}
note the round instead of curl brackets around day. An import will
skip silently everything behind the month line.
Wouldn't it make more sens to issue a warning whenever the parser has
trouble to read something? I noticed that the beamer.el from
beamer-mode is involved in parsing. Thus, I have no idea whether
org-mode is capable to notice such a problem. You might argue that
BibTeX is specifies the correct syntax very well, but many other tools
export and import to BibTeX too and an error in these programs might
still allow them to import nd export entries with wrong syntax, a
import in org-mode however, could result finally in fatal data loose.
Thus, I vote for an error or warning message whenever there is
something which requires human attentions.
As for now, I have to carefully check, that all entries moved into the
org-mode file, which is a bit tiring and error prone.

All the best

Torsten



[1] Debug log:

Debugger entered--Lisp error: (wrong-type-argument char-or-string-p nil)
  insert(nil)
  (progn (fset (quote togtag) (function* (lambda (tag) (block togtag
(org-toggle-tag tag (quote on)) (org-insert-heading) (insert (val
:title)) (org-bibtex-put "TITLE" (val :title)) (org-bibtex-put
org-bibtex-type-property-name (downcase (val :type))) (dolist (pair
entry) (case (car pair) (:title nil) (:type nil) (:key (org-bibtex-put
org-bibtex-key-property (cdr pair))) (:keywords (if
org-bibtex-tags-are-keywords (mapc (lambda (kw) (togtag ...))
(split-string (cdr pair) ", *")) (org-bibtex-put (car pair) (cdr
pair (otherwise (org-bibtex-put (car pair) (cdr pair) (mapc
(function togtag) org-bibtex-tags))
  (unwind-protect (progn (fset (quote togtag) (function* (lambda (tag)
(block togtag (org-toggle-tag tag (quote on)) (org-insert-heading)
(insert (val :title)) (org-bibtex-put "TITLE" (val :title))
(org-bibtex-put org-bibtex-type-property-name (downcase (val :type)))
(dolist (pair entry) (case (car pair) (:title nil) (:type nil) (:key
(org-bibtex-put org-bibtex-key-property (cdr pair))) (:keywords (if
org-bibtex-tags-are-keywords (mapc (lambda ... ...) (split-string ...
", *")) (org-bibtex-put (car pair) (cdr pair (otherwise
(org-bibtex-put (car pair) (cdr pair) (mapc (function togtag)
org-bibtex-tags)) (if --cl-letf-bound-- (fset (quote togtag)
--cl-letf-save--) (fmakunbound (quote togtag
  (let* ((--cl-letf-bound-- (fboundp (quote togtag)))
(--cl-letf-save-- (and --cl-letf-bound-- (symbol-function (quote
togtag) (unwind-protect (progn (fset (quote togtag) (function*
(lambda (tag) (block togtag (org-toggle-tag tag ...)
(org-insert-heading) (insert (val :title)) (org-bibtex-put "TITLE"
(val :title)) (org-bibtex-put org-bibtex-type-property-name (downcase
(val :type))) (dolist (pair entry) (case (car pair) (:title nil)
(:type nil) (:key (org-bibtex-put org-bibtex-key-property (cdr pair)))
(:keywords (if org-bibtex-tags-are-keywords (mapc ... ...)
(org-bibtex-put ... ...))) (otherwise (org-bibtex-put (car pair) (cdr
pair) (mapc (function togtag) org-bibtex-tags)) (if
--cl-letf-bound-- (fset (quote togtag) --cl-letf-save--) (fmakunbound
(quote togtag)
  (letf (((symbol-function (quote togtag)) (function* (lambda (tag)
(block togtag (org-toggle-tag tag (quote on)))
(org-insert-heading) (insert (val :title)) (org-bibtex-put "TITLE"
(val :title)) (org-bibtex-put org-bibtex-type-property-name (downcase
(val :type))) (dolist (pair entry) (case (car pair) (:title nil)
(:type nil) (:key (org-bibtex-put org-bibtex-key-property (cdr pair)))
(:keywords (if org-bibtex-tags-are-keywords (mapc (lambda (kw) (togtag
...)) (split-string (cdr pair) ", *")) (org-bibtex-put (car pair) (cdr
pair (otherwise (org-bibtex-put (car pair) (cdr pair) (mapc
(

Re: [O] Bug: org-todo-yesterday doesn't work from agenda buffer [7.7 (release_7.7.548.g9a442.dirty)]

[Bernt Hansen]

Dave Abrahams  writes:

>
> Debugger entered--Lisp error: (error "Before first headline at position 1142 
> in buffer *Org Agenda*")
>   signal(error ("Before first headline at position 1142 in buffer *Org 
> Agenda*"))
>   error("Before first headline at position %d in buffer %s" 1142 # *Org Agenda*>)

There's another function to use from the agenda:
org-agenda-todo-yesterday

-Bernt

PS. I posted a patch for your clocking error 3 days ago but forgot to CC
you on it so I guess you missed it.

Re: [O] [PATCH] Avoid lisp error with (org-deadline nil "+1d")

[Nick Dokos]

Peter Münster  wrote:

> On Wed, Nov 23 2011, Nick Dokos wrote:
> 
> > Generally speaking, defvars like this tell the compiler to shut up about
> > the "free" variable. You can see if it is needed, by commenting out the
> > defvar and then trying to compile the file.
> 
> Indeed, now there are 30 warnings instead of only 29 ... ;)
> Thanks for the explanation!
> 

Are they free variable warnings? If so, you now know how to fix them:
go wild :-)

Nick

Re: [O] [PATCH] Avoid lisp error with (org-deadline nil "+1d")

[Peter Münster]

On Wed, Nov 23 2011, Nick Dokos wrote:

> Generally speaking, defvars like this tell the compiler to shut up about
> the "free" variable. You can see if it is needed, by commenting out the
> defvar and then trying to compile the file.

Indeed, now there are 30 warnings instead of only 29 ... ;)
Thanks for the explanation!

-- 
   Peter

Re: [O] [PATCH] Avoid lisp error with (org-deadline nil "+1d")

[Nick Dokos]

Peter Münster  wrote:

> On Wed, Nov 23 2011, Carsten Dominik wrote:
> 
> > Fixed, thanks, please verify.
> 
> Verified: ok, thanks.
> 
> Is `(defvar parse-time-weekdays)' still needed then? And if yes, why?
> 

Generally speaking, defvars like this tell the compiler to shut up about
the "free" variable. You can see if it is needed, by commenting out the
defvar and then trying to compile the file.

Nick

[O] DONE displayed with org-todo face in custom agenda views

[Alexey Kopytov]

Hello,

This has been discussed here a number of times before, but I still see
this bug.

Test case:

emacs -q /tmp/test.org

--- test.org contents ---
* DONE test
  SCHEDULED: <2011-11-23 Wed>
--- test.org contents ---

C-c [
M-x org-agenda a

"DONE" is correctly displayed with the org-done face as seen from C-u C-x =

M-: (setq org-agenda-custom-commands '(("p" "Agenda" ((agenda ""
M-x org-agenda p

Now DONE is displayed with the org-todo face.

emacs-version: GNU Emacs 24.0.90.1 (x86_64-apple-darwin, NS
apple-appkit-1038.35) of 2011-09-26 on virtualmac.porkrind.org
org-version: Org-mode version 7.7

Are there any plans to fix this?

Thanks and regards,
Alexey.

Re: [O] [PATCH] Avoid lisp error with (org-deadline nil "+1d")

[Peter Münster]

On Wed, Nov 23 2011, Carsten Dominik wrote:

> Fixed, thanks, please verify.

Verified: ok, thanks.

Is `(defvar parse-time-weekdays)' still needed then? And if yes, why?

-- 
   Peter

Re: [O] Bug: Cloning tasks deletes clock time in the original [7.7 (release_7.7-571-gf558105)]

[David Maus]

At Sat, 19 Nov 2011 21:37:08 -0500,
Bernt Hansen wrote:
>
> I have the entries I want but my original clock lines have been deleted.
> I would expect this behaviour for the newly created clones only - not
> the original entry.

Pushed a fix for this problem. Could you check it works out for you?

>
> I'm also not sure exactly why I get 3 entries when I ask for two --
> maybe that's a special case of the repeater in the original task but it
> feels weird.

Yes, it's the repeater: You get one for clone for free (C-h f
org-clone-subtree-with-time-shift). I agree it's not that intuitive.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpjAiCYQTt0j.pgp
Description: PGP signature

Re: [O] [ANN] Org Elements in contrib

[Wes Hardaker]

> On Tue, 22 Nov 2011 06:00:49 -1000, t...@tsdye.com (Thomas S. Dye) said:

TSD> This looks brilliant.  The interactive functions seem to know their way
TSD> around my various org-mode files.  Looking forward to the generic
TSD> exporter and the LaTeX back-end.

Most specifically, the hardest part of writing the org-export-generic
functionality was the parser.  When I started on it, it very quickly
showed that a generic parser with an API was needed (but I didn't have
the time to do that).  This sounds like a perfect replacement for the
guts of the org-export-generic parser.
-- 
Wes Hardaker 
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/

Re: [O] TABLES: Remove/add cell

[Michael Brand]

Hi Gustav and Daniel

2011/9/30 Gustav Wikström :
> How do I add or remove a single cell in a table?
> Example:
> I have the following table:
> |1 |1 |
> |2 |3 |
> |3 |4 |
> |4 |  |
> Now I want to add an empty cell in @2$2 (below the heading) and thus move
> the following cells in column 2 down one step.
> After:
> |1 |1 |
> |2 |  |
> |3 |3 |
> |4 |4 |

2011/9/30 Michael Brand :
> [...] transpose [...]
> and split it into two (or three) tables:
>
> | a | b | c | d |
>
> | 1 | 3 | 4 |   |
>
> (| e | f | g | h |)
>
> Then you can use the very convenient editing functions of Org table on
> the second part of the table,

to move the empty field in front of "3"

| a | b | c | d |

| 1 |  | 3 | 4 |

| e | f | g | h |

> join the parts together

| a | b | c | d |
| 1 |   | 3 | 4 |
| e | f | g | h |

> and transpose again.

By coincidence just today I had the same need to move or rotate
columns left/right, without affecting the other rows above and below.
Because I need this repeatedly I wrote two in-row functions derived
from org-table-move-column, without the need anymore of splitting and
joining the table like above.

It supports only the direction left/right. The direction up/down
Gustav asked for would be harder to implement but as a workaround you
can still transpose
http://orgmode.org/worg/org-hacks.html#transpose-table
and use the in-row left/right.

from another thread:
On Mon, Nov 21, 2011 at 14:31, Daniel Martins  wrote:
> The feature of remove/add cell is quite important. Should be a feature
> request.

If I understand right and only for left/right, the in-row functions
cover that too:
- remove: first blank the field with "C-c Space"
  (org-table-blank-field) and then rotate in-row left
- add: rotate in-row right and replace the field content, before this
  step append new columns if required

For more see
"Change the column sequence in one row only" on Worg hacks:
http://orgmode.org/worg/org-hacks.html#column-sequence-in-row

Michael

Re: [O] [bug] problem with odt export with latex \ref

[Eric S Fraga]

Jambunathan K  writes:

> This should be fixed now.
>
> The problem was triggered because of inter-mixing label references and
> the italics style in the same line.

Brilliant, thanks!  Works now.

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1
: using Org-mode version 7.7 (release_7.7.591.gc52c2)

Re: [O] HTML export and Zotero-friendly headers

[Christian Moe]

On 11/23/11 5:45 PM, Erik L. Arneson wrote:

Thanks, that looks like a good start!


Let me know how it went.

Christian

[O] least recently clocked open task in a file

[Daniel Clemente]

  I have many open tasks in a file, and I want to work a bit on each, one after 
another, without neglecting any. That would be a round-robin approach.

  But how can I find the oldest clocked-out open task in a file?
  Can I order the agenda by recentness?

  I found org-clock-history but it can't be limited by subtree/file/region, 
must be turned on work manually and would not work for tasks clocked before it 
was turned in.


Daniel

Re: [O] Dynamically generating todo entries

[Daniel Schoepe]

On Wed, 23 Nov 2011 17:41:49 +0100, suvayu ali  
wrote:
> You can take pointers from here:
> 

Yeah, I figured out a solution that works for me:

(defadvice org-todo-list (before org-todo-gen-notmuch activate)
  (let ((buf (get-file-buffer "~/org/notmuch_todo.org")))
(when buf
  (kill-buffer buf)))
  (call-process "notmuch-org"))

(Together with a not very interesting python script that generates
notmuch_todo.org).

Thanks anyway.

Cheers,
Daniel


pgpqslxiISjjf.pgp
Description: PGP signature

Re: [O] A quick way to empty contents of entries?

[Memnon Anon]

Carsten Dominik  writes:
> On Nov 4, 2011, at 7:56 AM, gylns wrote:
>> Hi, all
>> I want to empty all my contents but leave only with the headlines and the
>> properties, is there a fast way?
[...]
> For one file:
>
>   perl -ne 'print if /^\*+ / or /^\s*:PROPERTIES:\s*$/../^\s*:END:\s*$/' 
> old.org > stripped.org

Hmm... perl.

Within emacs, that would be something like

C-<
M-x keep-lines RET
^\*\|:PROPERTIES:\(.\|\n\)+?:END:
(\n via "C-q C-j")

...

right?

Memnon

Re: [O] HTML export and Zotero-friendly headers

[Erik L. Arneson]

On Wed, 23 Nov 2011, Christian Moe wrote:
> Does Org document header data include more than author, title, date, 
> description and keywords. So I'd be inclined to go with Dublin Core 
> for this, and just twin the ordinary META tags (which Zotero doesn't 
> bother with, probably wisely) with DC equivalents.

I haven't played around with the Dublin Core tags yet, but I'll give
this a try and see how it works.

> Doing it as below, with a hook at the end of html export, is more than 
> a little clumsy, but it will do for testing purposes. If people think 
> it's a good idea to do this in HTML exports on a permanent basis, a 
> non-clumsy version could be patched into org-export-as-html.

Thanks, that looks like a good start!

-- 
Erik L. Arneson 
  GPG Key ID : 1024D/62DA1D25   BitCoin : 1LqvuGUqJ4ZUSoE7YE9ngETjwp4yZ2uSdP
  Office : +1.541.291.9776Skype : callto://pymander
   http://www.leisurenouveau.com/ http://www.transformason.org/

Re: [O] Dynamically generating todo entries

[suvayu ali]

On Thu, Nov 3, 2011 at 00:35, Daniel Schoepe  wrote:
>> Diary sexps is probably the wrong thing to use for what you want: I
>> don't know how far you want to take it, but iiuc, the easiest thing to
>> do is write a script (in your favorite language) that generates a file
>> of entries, say foo.org:
>>
>> ,
>> |
>> | * notmuch threads
>> |
>> | ** TODO check out this thread [[some link][thread title]]
>> | ** TODO check out that thread [[some other link][other thread title]]
>> | ...
>> `
>>
>> Then open it in emacs and include it in your agenda with C-c [
>
> Now that you mention it, this is a perfectly obvious solution. :)

You can take pointers from here:


-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] TABLES: aesthetics on columns

[Jonas Hörsch]

On Wed, Nov 23 2011, Daniel Martins wrote:

> 2) Can I locally define a table as completely in math mode?
>
> So I could type e.g.
>
>
> A)
> |---+---+---+---|
> |   | M | l | k |
> |---+---+---+---|
> | M | - |   |   |
> | l |   | - |   |
> | k |   |   | - |
> |---+---+---+---|
>
> Instead of
>
> B)
> |-+-+-+-|
> |     | $M$ | $l$ | $k$ |
> |-+-+-+-|
> | $M$ | -   |     |     |
> | $l$ |     | -   |     |
> | $k$ |     |     | -   |
> |-+-+-+-|
>
> and when I export a table like A) to Latex I have the aspect of B) instead?

with a header of
#+LATEX_HEADER: \newcolumntype{m}{>{$}l<{$}}
(where you define a new type of column, which always puts a $ to the
beginning and to the end of a cell)

and
#+ATTR_LATEX: align=   ( <- one m for each column )
directly above your table (this sets the mandatory argument for the
tabular environment, so that the new column type is used for every
column)

should probably do it, if i understand everything correctly.

cheers,
jonas

Re: [O] Dynamically generating todo entries

[Jonas Hörsch]

[fn:1]

Footnotes:

[fn:1] Mail

Re: [O] Updating Worg re standard source block syntax

[Sebastien Vauban]

Hi Nick,

Nick Dokos wrote:
> Sebastien Vauban  wrote:
>>> Is there any way to find out what the org version is at the worg site?
>>
>> BTW, sorry, yes, the answer is yes: see section "What software is available 
>> on
>> Worg for Babel code execution?" on http://orgmode.org/worg/worg-setup.html.
>> But one can wonder if it's up-to-date. That's why adding it as proposed 
>> should
>> be done anyway.
>
> Actually, that tells various versions, but not the org version

Indeed, I was too enthusiast too quickly.

> - so here's another vote for including the current versions in the
> publishing output.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [BUG] Inconsistency in src block hiding

[Nicolas Goaziou]

Eric Schulte  writes:

>> Consider the following cases:
>>
>> #+name: one-more
>> #+header: :var k=2
>> #+begin_src emacs-lisp
>> (1+ k)
>> #+end_src
>>
>> #+header: :var k=2
>> #+name: one-more
>> #+begin_src emacs-lisp
>> (1+ k)
>> #+end_src
>>
>> #+attr_html: :textarea t :height 10 :width 40
>> #+name: unique-name
>> #+begin_example
>> Edit me!
>> #+end_example
>>
>> Note that the second case doesn't appear to be legal, as executing the
>> block errors out with "Symbol's value as variable is void: k". I don't
>> think that there should be any imposed order in affiliated keywords.
>>
>
> I would say that the first and third should be valid constructions, but
> the second should not.  This is for two reasons.
>
> 1. As you point out the second is not currently supported, and generally
>changing the code should be avoided.

I'm just thinking about a super-set of what's currently supported, that
is to allow any order instead of a static one. So that's not really
a problem.

> 2. More importantly, unlike the #+attr_html line in the third example,
>the #+header line *only* applies to code blocks and not to any other
>Org-mode element.

For now, you may be right. But I consider "#+header" as a continuation
of the information specified at the block beginning line. With that in
mind, there is at least one other block type that allows information
there: example-block. So an "#+header" keyword could be as appropriate
for it. I'm also thinking about Jambunathan's "#+begin_annotation".

> I suppose I would yield to you on this point as you actually have
> a systematic way of defining Org-mode objects and keywords
> (org-elements), where as all I have is intuition and the vague notion
> that option two above "looks ugly" to me.

> Although, that said I don't really look forward to the task of
> changing the code to allow any arbitrary sequence of #+name
> and #+header arguments prefixing a code block as it will complicate
> the current code significantly.

Not necessarily (see below).

>> In the second case, block can be hidden when TAB is pressed on both
>> the "#+name:" and the "#+begin_" line, with two different
>> results. That's confusing.

> I did work out a version of this patch in which when tab was pressed on
> the #+name line, only the code block was hidden, however in my
> conception where names can be applied to any Org-mode object, and
> intervening #+header lines are part of the code block it seemed more
> consistent to hide the whole object following the name, so e.g., hiding
> this with TAB on #+name
>
>
> #+name: one-more
> #+header: :var k=2
> #+begin_src emacs-lisp
> (1+ k)
> #+end_src
>
> should result in this (as it does now)
>
>
> #+name: one-more...
>
>
> rather than this
>
>
> #+name: one-more
> #+header: :var k=2
> #+begin_src emacs-lisp...

Well, if we lived in a perfect world where anyone could smartly name
things the first time they encounter them, I'll be on your side. But,
the names I choose are often rather vague, so I'd always prefer to both
see the name and a have a glimpse of the named object. Thus, when the
wind is southerly, I can know a src-block from an example-block.

That also explains why I dislike the "#+name:" hiding idea: lists,
paragraphs, tables will all look the same. Also, it could potentially
increase a lot the number of overlays used in a buffer, which isn't good
performance-wise.

>> Only lines below "#+begin_" should be hidden, with TAB pressed on any
>> keyword. Affiliated keywords should always be visible.
>>
>
> I see your view, and it is consistent, it is just different from mine.
>

I agree. I try nonetheless to make you see mine as more consistent than
yours ;)

 If you have, from top to bottom, "name", "results" "header", nothing
 will fold.  In all those cases, I think a consistent behaviour could
 be to hide the block, with any number of keywords above, and TAB
 pressed at any of them.

>>>
>>> Yes, I would agree, the hiding should be smart enough to find the whole
>>> unit and hide it.  I'll take a look at the code.
>>
>> Or rely on Org Elements... *coughs*
>>
>
> :) I agree, Ideally I would love to only manipulate the list provided by
> org-element.el, however now I am more concerned with changes before the
> upcoming Emacs merge before the release of Emacs24.  So relying on
> org-elements is not currently an option.

But borrowing parts of it is allowed in the game.

More specifically, you need to copy and rename a single function
`org-element-collect-affiliated-keywords', and four variables
(`org-element--affiliated-re', `org-element-keyword-translation-alist',
`org-element-parsed-keywords' and `org-element-dual-keywords'.)

Now, in the following example, which will hurt your eyes, 

#+header: :var k=3 :exports code
#+headers: :var k=2
#+caption: One more time.
#+name: one-more-time
#+begin_src emacs-lisp
(1+ k)
#+end_src

calling (org-element-collect-affiliated-keywords) on the "#+begin_src"
line will result in:

(1 (:na

Re: [O] Updating Worg re standard source block syntax

[Nick Dokos]

Sebastien Vauban  wrote:

> >
> > Is there any way to find out what the org version is at the worg site?
> 
> BTW, sorry, yes, the answer is yes: see section "What software is available on
> Worg for Babel code execution?" on http://orgmode.org/worg/worg-setup.html.
> But one can wonder if it's up-to-date. That's why adding it as proposed should
> be done anyway.
> 

Actually, that tells various versions, but not the org version - so here's
another vote for including the current versions in the publishing output.

Thanks,
Nick

Re: [O] Add publishing with utf8

[sindikat]

Now i have 


(set-language-environment "UTF-8")
(prefer-coding-system 'utf-8-unix)
(setq org-export-html-coding-system 'utf-8-unix) 

and publishing works perfectly. Funny, that i have every locale set to 
"en_US.UTF-8", but LANGUAGE and LC_ALL set to empty. But when i set them to 
"en_US.UTF-8", Emacs still opens non-utf8 files as "undecided-unix". In 
file-coding-system-alist i found expression ("" undecided) and when i 
changed it to utf-8-unix, every file started opening with this encoding. 

I've solved my problem, thanks to you all. 


I only not sure why opening everything as utf8 wasn't made default in Emacs.

Re: [O] org-mode version 7.7 and very slow rendering of columns

[Leonidas Tsampros]

Leonidas Tsampros  writes:
> Hello,
>
> I recently started playing with the following setup for an Org file of
> mine:
>
> * Movies
> :PROPERTIES:
> :COLUMNS:  %35ITEM %5LIST_ORDER(List) %25Director %19Genre %7Year 
> %6IMDB_Rating(Rating) %8Watched{X/} %4My_Rating(Me)
> :WATCHED_All: "[ ]" "[X]"
> :END:
> ** List 1
> ** List 2
>
>
> Each of List 1 and 2 have around 200-300 children entries each. In plain
> Org-mode with no columns mode activated, the tree renders just fine with
> noticable delays.
>
> However, as soon as I turn on columns mode I have to wait around 15secs
> to get it activated. In the meantime emacs' CPU usage skyrockets to
> 100%.
>
> After that, moving the cursor between the children entries of List 1 and
> List 2 is also extremely cumbersome as each move seems to send emacs to
> 100% CPU for a little bit.
>
> With debugging on, and during initialization of org-columns, I got this
> backtrace each and every time:
>
>   org-up-heading-safe()
>   byte-code("bytecode\204T^@\326\314!$
>   byte-code("\300\301\302\217\207" [nil (byte-code  "bytecode!$
>   org-get-tags-at()
>   org-entry-properties()
>   org-columns()
>
> Do you have any idea of what's might be causing this hiccup?
>
> Best Regards,
> Leonidas Tsampros

I forgot to mention that this happens with

GNU Emacs 24.0.91.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.6) of 2011-11-23

and the bundled org-mode which is 7.7

Also, I did a quick test with:

GNU Emacs 23.3.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.6) of 2011-10-26
Org-mode version 6.33x

and I confirm that I can see the same behavior on that version to.

Best Regards,
Leonidas Tsampros

Re: [O] TABLES: aesthetics on columns

[Daniel Martins]

Worked perfectly.

Question 2 is a (minor) pity.

Thank you very much.

Daniel

2011/11/23 Suvayu Ali :
> #+LATEX_HEADER: \def\ll{$\lambda$}

Re: [O] TABLES: aesthetics on columns

[Suvayu Ali]

On Wed, 23 Nov 2011 09:13:18 -0200
Daniel Martins  wrote:

> 1) Can I do the same in org-mode i.e. a previous (and possibly local)
> definition or long variable befopre putting them in a table?
> 

Try this in the header of the org file:

#+LATEX_HEADER: \def\ll{$\lambda$}

> 
> The other (maybe superfluous) question is
> 
> 2) Can I locally define a table as completely in math mode?

Sorry, I don't think this is possible.

-- 
Suvayu

Open source is the future. It sets us free.

[O] org-mode version 7.7 and very slow rendering of columns

[Leonidas Tsampros]

Hello,

I recently started playing with the following setup for an Org file of
mine:

* Movies
:PROPERTIES:
:COLUMNS:  %35ITEM %5LIST_ORDER(List) %25Director %19Genre %7Year 
%6IMDB_Rating(Rating) %8Watched{X/} %4My_Rating(Me)
:WATCHED_All: "[ ]" "[X]"
:END:
** List 1
** List 2


Each of List 1 and 2 have around 200-300 children entries each. In plain
Org-mode with no columns mode activated, the tree renders just fine with
noticable delays.

However, as soon as I turn on columns mode I have to wait around 15secs
to get it activated. In the meantime emacs' CPU usage skyrockets to
100%.

After that, moving the cursor between the children entries of List 1 and
List 2 is also extremely cumbersome as each move seems to send emacs to
100% CPU for a little bit.

With debugging on, and during initialization of org-columns, I got this
backtrace each and every time:

  org-up-heading-safe()
  byte-code("bytecode\204T^@\326\314!$
  byte-code("\300\301\302\217\207" [nil (byte-code  "bytecode!$
  org-get-tags-at()
  org-entry-properties()
  org-columns()

Do you have any idea of what's might be causing this hiccup?

Best Regards,
Leonidas Tsampros

Re: [O] [BUG] org-table: time difference delivers wrong results

[Daniel Bausch]

What may be a leading hint is that even

| -28799 | -08:00:01 |
#+TBLFM: $2=$1;T

does not deliver correct results.  It should deliver -07:59:59.

Daniel

Am Mittwoch 23. November 2011, 11:23:49 schrieb Nick Dokos:
> Martyn Jago  wrote:
> > Martyn Jago  writes:
> > 
> > Apologies I had a typo - please ignore the previous mail. So this looks 
more sensible:
> > > Daniel Bausch  writes:
> > >> Anyone?  It might be a duplicate of what Gustav Wiktrom reported on
> > >> 1st of September, but his problem was not resolved, either.
> > >> 
> > >> Daniel
> > >> 
> > >> Am Dienstag 15. November 2011, 22:12:45 schrieb Daniel Bausch:
> > >>> Hello list,
> > >>> 
> > >>> consider the following example:
> > >>> |A | B | C |
> > >>> |
> > >>> |--+---+---|
> > >>> |
> > >>> | 07:11:00 | -08:00:00 | -01:11:00 |
> > >>> 
> > >>> #+TBLFM: $3=$1+$2;T
> > > 
> > > [...]
> > > 
> > |   Data 1 |   Data 2 | Total |
> > |
> > |--+--+---|
> > |
> > | 00:00:00 | 00:00:00 |  00:00:00 |
> > | 00:00:00 | 00:00:01 | -01:59:59 |
> > | 00:00:00 | 00:00:02 | -01:59:58 |
> > | 00:00:00 | 00:00:03 | -01:59:57 |
> > | 00:00:00 | 00:00:04 | -01:59:56 |
> > | 00:00:00 | 00:00:05 | -01:59:55 |
> > | 00:00:00 | 00:00:06 | -01:59:54 |
> > | 00:00:00 | 00:00:07 | -01:59:53 |
> > | 00:00:00 | 00:00:08 | -01:59:52 |
> > | 00:00:00 | 00:00:09 | -01:59:51 |
> > | 00:00:00 | 00:00:10 | -01:59:50 |
> > | 00:00:00 | 00:00:11 | -01:59:49 |
> > | 00:00:00 | 00:00:12 | -01:59:48 |
> > | 00:00:00 | 00:00:13 | -01:59:47 |
> > | 00:00:00 | 00:00:14 | -01:59:46 |
> > | 00:00:00 | 00:00:15 | -01:59:45 |
> > 
> > #+TBLFM:
> > @2$3=$1-$2;T::@3$3=$1-$2;T::@4$3=$1-$2;T::@5$3=$1-$2;T::@6$3=$1-$2;T::@7
> > $3=$1-$2;T::@8$3=$1-$2;T::@9$3=$1-$2;T::@10$3=$1-$2;T::@11$3=$1-$2;T::@12
> > $3=$1-$2;T::@13$3=$1-$2;T::@14$3=$1-$2;T::@15$3=$1-$2;T::@16$3=$1-$2;T::@
> > 17$3=$1-$2;T
> > 
> > |   Data 1 |   Data 2 | Total |
> > |
> > |--+--+---|
> > |
> > | 00:00:00 | 00:00:16 | -01:59:44 |
> > | 00:00:00 | 00:00:17 | -01:59:43 |
> > | 00:00:00 | 00:00:18 | -01:59:42 |
> > | 00:00:00 | 00:00:19 | -01:59:41 |
> > | 00:00:00 | 00:00:20 | -01:59:40 |
> > | 00:00:00 | 00:00:21 | -01:59:39 |
> > | 00:00:00 | 00:00:22 | -01:59:38 |
> > | 00:00:00 | 00:00:23 | -01:59:37 |
> > | 00:00:00 | 00:00:24 | -01:59:36 |
> > | 00:00:00 | 00:00:25 | -01:59:35 |
> > | 00:00:00 | 00:00:26 | -01:59:34 |
> > | 00:00:00 | 00:00:27 | -01:59:33 |
> > | 00:00:00 | 00:00:28 | -01:59:32 |
> > | 00:00:00 | 00:00:29 | -01:59:31 |
> > | 00:00:00 | 00:00:30 | -01:59:30 |
> > | 00:00:00 | 00:00:31 | -01:59:29 |
> > 
> > #+TBLFM:
> > @2$3=$1-$2;T::@3$3=$1-$2;T::@4$3=$1-$2;T::@5$3=$1-$2;T::@6$3=$1-$2;T::@7
> > $3=$1-$2;T::@8$3=$1-$2;T::@9$3=$1-$2;T::@10$3=$1-$2;T::@11$3=$1-$2;T::@12
> > $3=$1-$2;T::@13$3=$1-$2;T::@14$3=$1-$2;T::@15$3=$1-$2;T::@16$3=$1-$2;T::@
> > 17$3=$1-$2;T
> > 
> > |   Data 1 |   Data 2 | Total |
> > |
> > |--+--+---|
> > |
> > | 00:00:00 | 00:00:59 | -01:59:01 |
> > | 00:00:00 | 00:01:00 | -01:59:00 |
> > | 00:00:00 | 00:01:01 | -01:58:59 |
> > | 00:00:00 | 00:01:02 | -01:58:58 |
> > | 00:00:00 | 00:01:03 | -01:58:57 |
> > | 00:00:00 | 00:01:04 | -01:58:56 |
> > | 00:00:00 | 00:01:05 | -01:58:55 |
> > | 00:00:00 | 00:01:06 | -01:58:54 |
> > | 00:00:00 | 00:01:07 | -01:58:53 |
> > | 00:00:00 | 00:01:08 | -01:58:52 |
> > | 00:00:00 | 00:01:09 | -01:58:51 |
> > | 00:00:00 | 00:01:10 | -01:58:50 |
> > | 00:00:00 | 00:01:11 | -01:58:49 |
> > | 00:00:00 | 00:01:12 | -01:58:48 |
> > | 00:00:00 | 00:01:13 | -01:58:47 |
> > | 00:00:00 | 00:01:14 | -01:58:46 |
> > 
> > #+TBLFM:
> > @2$3=$1-$2;T::@3$3=$1-$2;T::@4$3=$1-$2;T::@5$3=$1-$2;T::@6$3=$1-$2;T::@7
> > $3=$1-$2;T::@8$3=$1-$2;T::@9$3=$1-$2;T::@10$3=$1-$2;T::@11$3=$1-$2;T::@12
> > $3=$1-$2;T::@13$3=$1-$2;T::@14$3=$1-$2;T::@15$3=$1-$2;T::@16$3=$1-$2;T::@
> > 17$3=$1-$2;T
> > 
> > Best, Martyn
> > 
> > --
> > 
> > I _will_ engage brain before posting to the ML :(
> 
> I can't see straight at this time of the night, but aren't all these
> formulas equivalent to a column formula?
> 
> #+TBLFM: $3 = $1 - $2;T
> 
> Assuming that's the case, the problem is that org-table-time-to-string
> assumes that it is given a positive number and mishandles negative
> numbers, eg. the first row in the last table invokes:
> 
> ,
> 
> | (org-table-time-seconds-to-string -59 nil)
> | "-01:59:01"
> 
> `
> 
> 
> I didn't check carefully, but it looks as if the other-way function,
> org-table-time-string-to-seconds, deals correctly with "negative" time
> strings.
> 
> Nick

[O] TABLES: aesthetics on columns

[Daniel Martins]

I have two questions on (possibly) improving aesthetics on columns
when editing org tables.

Following the thread on table editing, I have a minor issue with
editing org-mode for Latex generation (which I do most of the time!).
I have a table with several columns which are e.g. integer numbers and
the headings are single variables such as
a,b,c, M,k etc
it is OK but I want to include sometimes Greek terms and subscripts such as
\lambda or
$\delta_\kappa$
and the columns are not so nice to see and edit due to the different spacings


In Latex I could use \def

\def\ll{$\lambda$}
\def\dk{$\delta_\kappa$}


and the use \ll and \dk on the headings is quite nice (despite the
generally horrendous aspect of Latex tables when compared with the
clean, neat, simple and effective counterpart in org-mode).

So I have the first question:

1) Can I do the same in org-mode i.e. a previous (and possibly local)
definition or long variable befopre putting them in a table?


The other (maybe superfluous) question is

2) Can I locally define a table as completely in math mode?

So I could type e.g.


A)
|---+---+---+---|
|   | M | l | k |
|---+---+---+---|
| M | - |   |   |
| l |   | - |   |
| k |   |   | - |
|---+---+---+---|

Instead of

B)
|-+-+-+-|
|     | $M$ | $l$ | $k$ |
|-+-+-+-|
| $M$ | -   |     |     |
| $l$ |     | -   |     |
| $k$ |     |     | -   |
|-+-+-+-|

and when I export a table like A) to Latex I have the aspect of B) instead?


Daniel

2011/11/22 Michael Brand 
>
> Hi Daniel
>
> On Tue, Nov 22, 2011 at 15:26, Daniel Martins  wrote:
> > Thank you very much!!!
> > Just one point
> > In my case at least M- does not insert a new line!
>                      ^
>
> Yes, my fault. Corrigendum:
>
> 1) M-S- to add the new row
> 2) mark the region from "t" down to any char from the field below
> 3) M-Ret
>
> Michael

Re: [O] HTML export and Zotero-friendly headers

[Christian Moe]

On 11/22/11 3:44 PM, Erik L. Arneson wrote:

Do I then understand correctly that what you want to do is simply to
generate one COinS snippet with metadata about the document itself
(author, title, etc.)?


Yes, though it doesn't need to be only COinS.  Zotero supports a number
of different formats, but COinS looks like it may be the easiest and the
most concise.



Hi,

Does Org document header data include more than author, title, date, 
description and keywords. So I'd be inclined to go with Dublin Core 
for this, and just twin the ordinary META tags (which Zotero doesn't 
bother with, probably wisely) with DC equivalents.


Doing it as below, with a hook at the end of html export, is more than 
a little clumsy, but it will do for testing purposes. If people think 
it's a good idea to do this in HTML exports on a permanent basis, a 
non-clumsy version could be patched into org-export-as-html.


#+begin_src elisp
  (defun org-export-with-dc ()
   "Add Dublin Core metadata from Org document headers to exported
  HTML. Comma-separated keywords and multiple authors separated
  with ` and ' will be correctly imported into Zotero. Note: For
  testing purposes only. It is only called as a hook from
  org-export-as-html, where it gets TITLE, DATE, AUTHOR,
  DESCRIPTION, and KEYWORDS values."
   (let ((creators (split-string author " and "))
 (subjects (split-string keywords ", ?"))
 fdate)
 (when (string-match "[0-9]+-[0-9]+-[0-9]+" date)
   (setq fdate (match-string 0 date)))
 (goto-char (point-min))
 (when (re-search-forward "")
   (goto-char (match-beginning 0))
   (while creators
 (insert
  (format "\n"
  (car creators)))
 (setq creators (cdr creators)))
   (insert
(format
 "
  
  \n"
 title fdate description))
   (while subjects
 (insert
  (format "\n"
  (car subjects)))
 (setq subjects (cdr subjects))


  (add-hook 'org-export-html-final-hook 'org-export-with-dc)
#+end_src

Yours,
Christian

Re: [O] Updating Worg re standard source block syntax

[Sebastien Vauban]

Hi Nick,

Nick Dokos wrote:
> Martyn Jago  wrote:
>
>> There are literally hundreds of uses of #+srcname and #+source within
>> Worg - should I be updating these to #+name ? In other words, does Worg
>> reflect the last official release (the Emacs release), or the bleeding
>> edge (I tend to assume the latter because of the Org community spirit of
>> Worg), but I fail to find any specific notice regarding this.
>> 
>> Advice would be appreciated since I've found myself appreciating, and
>> adding to Worg more and more - and it seems to me it is a real quality of
>> Org that Worg can exist in the first place.
>> 
>
> Is there any way to find out what the org version is at the worg site?
> This is something that I've wondered about in the past, but I keep
> forgetting to ask the question. E.g. it would be good to know the
> version, so when I make a change to worg content and test the change by
> publishing the site locally, I can use the exact version that is going
> to be used on the real site. Right now, I test with whatever version is
> running on my machine, which can lead to false conclusions (both positive
> and negative).

IIUC, the answer is no. But the best place for such information should be in
the output log of the publish process, that is at
http://orgmode.org/worg/publishing.txt

Adding

(message "Org-mode %s on Emacs %s." org-version emacs-version)

-- or something alike -- in http://orgmode.org/worg/sources/emacs.el should do
it.

BTW, sorry, yes, the answer is yes: see section "What software is available on
Worg for Babel code execution?" on http://orgmode.org/worg/worg-setup.html.
But one can wonder if it's up-to-date. That's why adding it as proposed should
be done anyway.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [BUG] org-table: time difference delivers wrong results

[Nick Dokos]

Martyn Jago  wrote:

> Martyn Jago  writes:
> 
> Apologies I had a typo - please ignore the previous mail. So this looks more 
> sensible:
> 
> > Daniel Bausch  writes:
> >
> >> Anyone?  It might be a duplicate of what Gustav Wiktrom reported on 1st of 
> >> September, but his problem was not resolved, either.
> >>
> >> Daniel
> >>
> >> Am Dienstag 15. November 2011, 22:12:45 schrieb Daniel Bausch:
> >>> Hello list,
> >>> 
> >>> consider the following example:
> >>> |A | B | C |
> >>> |
> >>> |--+---+---|
> >>> |
> >>> | 07:11:00 | -08:00:00 | -01:11:00 |
> >>> 
> >>> #+TBLFM: $3=$1+$2;T
> >
> > [...]
> 
> 
> 
> 
> |   Data 1 |   Data 2 | Total |
> |--+--+---|
> | 00:00:00 | 00:00:00 |  00:00:00 |
> | 00:00:00 | 00:00:01 | -01:59:59 |
> | 00:00:00 | 00:00:02 | -01:59:58 |
> | 00:00:00 | 00:00:03 | -01:59:57 |
> | 00:00:00 | 00:00:04 | -01:59:56 |
> | 00:00:00 | 00:00:05 | -01:59:55 |
> | 00:00:00 | 00:00:06 | -01:59:54 |
> | 00:00:00 | 00:00:07 | -01:59:53 |
> | 00:00:00 | 00:00:08 | -01:59:52 |
> | 00:00:00 | 00:00:09 | -01:59:51 |
> | 00:00:00 | 00:00:10 | -01:59:50 |
> | 00:00:00 | 00:00:11 | -01:59:49 |
> | 00:00:00 | 00:00:12 | -01:59:48 |
> | 00:00:00 | 00:00:13 | -01:59:47 |
> | 00:00:00 | 00:00:14 | -01:59:46 |
> | 00:00:00 | 00:00:15 | -01:59:45 |
> #+TBLFM: 
> @2$3=$1-$2;T::@3$3=$1-$2;T::@4$3=$1-$2;T::@5$3=$1-$2;T::@6$3=$1-$2;T::@7$3=$1-$2;T::@8$3=$1-$2;T::@9$3=$1-$2;T::@10$3=$1-$2;T::@11$3=$1-$2;T::@12$3=$1-$2;T::@13$3=$1-$2;T::@14$3=$1-$2;T::@15$3=$1-$2;T::@16$3=$1-$2;T::@17$3=$1-$2;T
> 
> |   Data 1 |   Data 2 | Total |
> |--+--+---|
> | 00:00:00 | 00:00:16 | -01:59:44 |
> | 00:00:00 | 00:00:17 | -01:59:43 |
> | 00:00:00 | 00:00:18 | -01:59:42 |
> | 00:00:00 | 00:00:19 | -01:59:41 |
> | 00:00:00 | 00:00:20 | -01:59:40 |
> | 00:00:00 | 00:00:21 | -01:59:39 |
> | 00:00:00 | 00:00:22 | -01:59:38 |
> | 00:00:00 | 00:00:23 | -01:59:37 |
> | 00:00:00 | 00:00:24 | -01:59:36 |
> | 00:00:00 | 00:00:25 | -01:59:35 |
> | 00:00:00 | 00:00:26 | -01:59:34 |
> | 00:00:00 | 00:00:27 | -01:59:33 |
> | 00:00:00 | 00:00:28 | -01:59:32 |
> | 00:00:00 | 00:00:29 | -01:59:31 |
> | 00:00:00 | 00:00:30 | -01:59:30 |
> | 00:00:00 | 00:00:31 | -01:59:29 |
> #+TBLFM: 
> @2$3=$1-$2;T::@3$3=$1-$2;T::@4$3=$1-$2;T::@5$3=$1-$2;T::@6$3=$1-$2;T::@7$3=$1-$2;T::@8$3=$1-$2;T::@9$3=$1-$2;T::@10$3=$1-$2;T::@11$3=$1-$2;T::@12$3=$1-$2;T::@13$3=$1-$2;T::@14$3=$1-$2;T::@15$3=$1-$2;T::@16$3=$1-$2;T::@17$3=$1-$2;T
> 
> |   Data 1 |   Data 2 | Total |
> |--+--+---|
> | 00:00:00 | 00:00:59 | -01:59:01 |
> | 00:00:00 | 00:01:00 | -01:59:00 |
> | 00:00:00 | 00:01:01 | -01:58:59 |
> | 00:00:00 | 00:01:02 | -01:58:58 |
> | 00:00:00 | 00:01:03 | -01:58:57 |
> | 00:00:00 | 00:01:04 | -01:58:56 |
> | 00:00:00 | 00:01:05 | -01:58:55 |
> | 00:00:00 | 00:01:06 | -01:58:54 |
> | 00:00:00 | 00:01:07 | -01:58:53 |
> | 00:00:00 | 00:01:08 | -01:58:52 |
> | 00:00:00 | 00:01:09 | -01:58:51 |
> | 00:00:00 | 00:01:10 | -01:58:50 |
> | 00:00:00 | 00:01:11 | -01:58:49 |
> | 00:00:00 | 00:01:12 | -01:58:48 |
> | 00:00:00 | 00:01:13 | -01:58:47 |
> | 00:00:00 | 00:01:14 | -01:58:46 |
> #+TBLFM: 
> @2$3=$1-$2;T::@3$3=$1-$2;T::@4$3=$1-$2;T::@5$3=$1-$2;T::@6$3=$1-$2;T::@7$3=$1-$2;T::@8$3=$1-$2;T::@9$3=$1-$2;T::@10$3=$1-$2;T::@11$3=$1-$2;T::@12$3=$1-$2;T::@13$3=$1-$2;T::@14$3=$1-$2;T::@15$3=$1-$2;T::@16$3=$1-$2;T::@17$3=$1-$2;T
> 
> Best, Martyn
> 
> --
> 
> I _will_ engage brain before posting to the ML :(
> 
> 

I can't see straight at this time of the night, but aren't all these formulas 
equivalent to
a column formula?

#+TBLFM: $3 = $1 - $2;T

Assuming that's the case, the problem is that org-table-time-to-string assumes 
that it is given
a positive number and mishandles negative numbers, eg. the first row in the 
last table invokes:

,
| (org-table-time-seconds-to-string -59 nil)
| "-01:59:01"
`


I didn't check carefully, but it looks as if the other-way function,
org-table-time-string-to-seconds, deals correctly with "negative" time
strings.

Nick

Re: [O] [BUG] org-table: time difference delivers wrong results

[Martyn Jago]

Martyn Jago  writes:

Apologies I had a typo - please ignore the previous mail. So this looks more 
sensible:

> Daniel Bausch  writes:
>
>> Anyone?  It might be a duplicate of what Gustav Wiktröm reported on 1st of 
>> September, but his problem was not resolved, either.
>>
>> Daniel
>>
>> Am Dienstag 15. November 2011, 22:12:45 schrieb Daniel Bausch:
>>> Hello list,
>>> 
>>> consider the following example:
>>> |A | B | C |
>>> |
>>> |--+---+---|
>>> |
>>> | 07:11:00 | -08:00:00 | -01:11:00 |
>>> 
>>> #+TBLFM: $3=$1+$2;T
>
> [...]




|   Data 1 |   Data 2 | Total |
|--+--+---|
| 00:00:00 | 00:00:00 |  00:00:00 |
| 00:00:00 | 00:00:01 | -01:59:59 |
| 00:00:00 | 00:00:02 | -01:59:58 |
| 00:00:00 | 00:00:03 | -01:59:57 |
| 00:00:00 | 00:00:04 | -01:59:56 |
| 00:00:00 | 00:00:05 | -01:59:55 |
| 00:00:00 | 00:00:06 | -01:59:54 |
| 00:00:00 | 00:00:07 | -01:59:53 |
| 00:00:00 | 00:00:08 | -01:59:52 |
| 00:00:00 | 00:00:09 | -01:59:51 |
| 00:00:00 | 00:00:10 | -01:59:50 |
| 00:00:00 | 00:00:11 | -01:59:49 |
| 00:00:00 | 00:00:12 | -01:59:48 |
| 00:00:00 | 00:00:13 | -01:59:47 |
| 00:00:00 | 00:00:14 | -01:59:46 |
| 00:00:00 | 00:00:15 | -01:59:45 |
#+TBLFM: 
@2$3=$1-$2;T::@3$3=$1-$2;T::@4$3=$1-$2;T::@5$3=$1-$2;T::@6$3=$1-$2;T::@7$3=$1-$2;T::@8$3=$1-$2;T::@9$3=$1-$2;T::@10$3=$1-$2;T::@11$3=$1-$2;T::@12$3=$1-$2;T::@13$3=$1-$2;T::@14$3=$1-$2;T::@15$3=$1-$2;T::@16$3=$1-$2;T::@17$3=$1-$2;T

|   Data 1 |   Data 2 | Total |
|--+--+---|
| 00:00:00 | 00:00:16 | -01:59:44 |
| 00:00:00 | 00:00:17 | -01:59:43 |
| 00:00:00 | 00:00:18 | -01:59:42 |
| 00:00:00 | 00:00:19 | -01:59:41 |
| 00:00:00 | 00:00:20 | -01:59:40 |
| 00:00:00 | 00:00:21 | -01:59:39 |
| 00:00:00 | 00:00:22 | -01:59:38 |
| 00:00:00 | 00:00:23 | -01:59:37 |
| 00:00:00 | 00:00:24 | -01:59:36 |
| 00:00:00 | 00:00:25 | -01:59:35 |
| 00:00:00 | 00:00:26 | -01:59:34 |
| 00:00:00 | 00:00:27 | -01:59:33 |
| 00:00:00 | 00:00:28 | -01:59:32 |
| 00:00:00 | 00:00:29 | -01:59:31 |
| 00:00:00 | 00:00:30 | -01:59:30 |
| 00:00:00 | 00:00:31 | -01:59:29 |
#+TBLFM: 
@2$3=$1-$2;T::@3$3=$1-$2;T::@4$3=$1-$2;T::@5$3=$1-$2;T::@6$3=$1-$2;T::@7$3=$1-$2;T::@8$3=$1-$2;T::@9$3=$1-$2;T::@10$3=$1-$2;T::@11$3=$1-$2;T::@12$3=$1-$2;T::@13$3=$1-$2;T::@14$3=$1-$2;T::@15$3=$1-$2;T::@16$3=$1-$2;T::@17$3=$1-$2;T

|   Data 1 |   Data 2 | Total |
|--+--+---|
| 00:00:00 | 00:00:59 | -01:59:01 |
| 00:00:00 | 00:01:00 | -01:59:00 |
| 00:00:00 | 00:01:01 | -01:58:59 |
| 00:00:00 | 00:01:02 | -01:58:58 |
| 00:00:00 | 00:01:03 | -01:58:57 |
| 00:00:00 | 00:01:04 | -01:58:56 |
| 00:00:00 | 00:01:05 | -01:58:55 |
| 00:00:00 | 00:01:06 | -01:58:54 |
| 00:00:00 | 00:01:07 | -01:58:53 |
| 00:00:00 | 00:01:08 | -01:58:52 |
| 00:00:00 | 00:01:09 | -01:58:51 |
| 00:00:00 | 00:01:10 | -01:58:50 |
| 00:00:00 | 00:01:11 | -01:58:49 |
| 00:00:00 | 00:01:12 | -01:58:48 |
| 00:00:00 | 00:01:13 | -01:58:47 |
| 00:00:00 | 00:01:14 | -01:58:46 |
#+TBLFM: 
@2$3=$1-$2;T::@3$3=$1-$2;T::@4$3=$1-$2;T::@5$3=$1-$2;T::@6$3=$1-$2;T::@7$3=$1-$2;T::@8$3=$1-$2;T::@9$3=$1-$2;T::@10$3=$1-$2;T::@11$3=$1-$2;T::@12$3=$1-$2;T::@13$3=$1-$2;T::@14$3=$1-$2;T::@15$3=$1-$2;T::@16$3=$1-$2;T::@17$3=$1-$2;T

Best, Martyn

--

I _will_ engage brain before posting to the ML :(

Re: [O] [BUG] org-table: time difference delivers wrong results

[Martyn Jago]

Daniel Bausch  writes:

> Anyone?  It might be a duplicate of what Gustav Wiktröm reported on 1st of 
> September, but his problem was not resolved, either.
>
> Daniel
>
> Am Dienstag 15. November 2011, 22:12:45 schrieb Daniel Bausch:
>> Hello list,
>> 
>> consider the following example:
>> |A | B | C |
>> |
>> |--+---+---|
>> |
>> | 07:11:00 | -08:00:00 | -01:11:00 |
>> 
>> #+TBLFM: $3=$1+$2;T

[...]

At first I wondered if Calc was treating these numbers as angles
(degrees, minutes, seconds) but I really can't explain these results:

|   Data 1 |   Data 2 | Total |
|--+--+---|
| 00:00:00 | 00:00:00 |  00:00:00 |
| 00:00:00 | 00:00:01 | -01:59:59 |
| 00:00:00 | 00:00:02 | -01:58:58 |
| 00:00:00 | 00:00:03 | -01:59:57 |
| 00:00:00 | 00:00:04 |  00:00:00 |
| 00:00:00 | 00:00:05 | -01:59:55 |
| 00:00:00 | 00:00:06 | -01:58:58 |
| 00:00:00 | 00:00:07 | -01:59:53 |
| 00:00:00 | 00:00:08 |  00:00:00 |
| 00:00:00 | 00:00:09 | -01:59:51 |
| 00:00:00 | 00:00:10 | -01:58:58 |
| 00:00:00 | 00:00:11 | -01:59:49 |
| 00:00:00 | 00:00:12 |  00:00:00 |
| 00:00:00 | 00:00:13 | -01:59:47 |
| 00:00:00 | 00:00:14 | -01:58:58 |
| 00:00:00 | 00:00:15 | -01:59:45 |
#+TBLFM: 
@2$3=$1-$2;T::@3$3=$1-$2;T;@4$3=$1-$2;T::@5$3=$1-$2;T;@6$3=$1-$2;T::@7$3=$1-$2;T;@8$3=$1-$2;T::@9$3=$1-$2;T;@10$3=$1-$2;T::@11$3=$1-$2;T;@12$3=$1-$2;T::@13$3=$1-$2;T;@14$3=$1-$2;T::@15$3=$1-$2;T;@16$3=$1-$2;T::@17$3=$1-$2;T

|   Data 1 |   Data 2 | Total |
|--+--+---|
| 00:00:00 | 00:00:16 | -01:59:44 |
| 00:00:00 | 00:00:17 | -01:59:43 |
| 00:00:00 | 00:00:18 | -01:58:58 |
| 00:00:00 | 00:00:19 | -01:59:41 |
| 00:00:00 | 00:00:20 |  00:00:00 |
| 00:00:00 | 00:00:21 | -01:59:39 |
| 00:00:00 | 00:00:22 | -01:58:58 |
| 00:00:00 | 00:00:23 | -01:59:37 |
| 00:00:00 | 00:00:24 |  00:00:00 |
| 00:00:00 | 00:00:25 | -01:59:35 |
| 00:00:00 | 00:00:26 | -01:58:58 |
| 00:00:00 | 00:00:27 | -01:59:33 |
| 00:00:00 | 00:00:28 |  00:00:00 |
| 00:00:00 | 00:00:29 | -01:59:31 |
| 00:00:00 | 00:00:30 | -01:58:58 |
| 00:00:00 | 00:00:31 | -01:59:29 |
#+TBLFM: 
@2$3=$1-$2;T::@3$3=$1-$2;T;@4$3=$1-$2;T::@5$3=$1-$2;T;@6$3=$1-$2;T::@7$3=$1-$2;T;@8$3=$1-$2;T::@9$3=$1-$2;T;@10$3=$1-$2;T::@11$3=$1-$2;T;@12$3=$1-$2;T::@13$3=$1-$2;T;@14$3=$1-$2;T::@15$3=$1-$2;T;@16$3=$1-$2;T::@17$3=$1-$2;T

|   Data 1 |   Data 2 | Total |
|--+--+---|
| 00:00:00 | 00:00:59 | -01:59:01 |
| 00:00:00 | 00:01:00 | -01:59:00 |
| 00:00:00 | 00:01:01 | -01:58:58 |
| 00:00:00 | 00:01:02 | -01:58:58 |
| 00:00:00 | 00:01:03 |  00:00:00 |
| 00:00:00 | 00:01:04 | -01:58:56 |
| 00:00:00 | 00:01:05 | -01:58:58 |
| 00:00:00 | 00:01:06 | -01:58:54 |
| 00:00:00 | 00:01:07 |  00:00:00 |
| 00:00:00 | 00:01:08 | -01:58:52 |
| 00:00:00 | 00:01:09 | -01:58:58 |
| 00:00:00 | 00:01:10 | -01:58:50 |
| 00:00:00 | 00:01:11 |  00:00:00 |
| 00:00:00 | 00:01:12 | -01:58:48 |
| 00:00:00 | 00:01:13 | -01:58:58 |
| 00:00:00 | 00:01:14 | -01:58:46 |
#+TBLFM: 
@2$3=$1-$2;T::@3$3=$1-$2;T;@4$3=$1-$2;T::@5$3=$1-$2;T;@6$3=$1-$2;T::@7$3=$1-$2;T;@8$3=$1-$2;T::@9$3=$1-$2;T;@10$3=$1-$2;T::@11$3=$1-$2;T;@12$3=$1-$2;T::@13$3=$1-$2;T;@14$3=$1-$2;T::@15$3=$1-$2;T;@16$3=$1-$2;T::@17$3=$1-$2;T

Best, Martyn