emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Eric S Fraga <e.fraga@ucl.ac.uk>
To: Achim Gratz <Stromeko@nexgo.de>
Cc: emacs-orgmode@gnu.org
Subject: Re: using gnuplot's "splot" and "every" commands on org-mode table data
Date: Thu, 9 May 2013 13:54:56 +0100	[thread overview]
Message-ID: <87zjw4xqhr.fsf@ucl.ac.uk> (raw)
In-Reply-To: <87r4hkuebb.fsf@Rainer.invalid> (Achim Gratz's message of "Mon, 6 May 2013 20:57:12 +0200")

Achim Gratz <Stromeko@nexgo.de> writes:

> Eric Schulte writes:
>> If you really wanted to be fancy, gnuplot will let you specify shell
>> transformations as part of the plotting command which would allow you to
>> forego the intermediate code block.
>
> As a side-note, if we'd drop the convention that the first separator
> defines the heading of the table and introduced a proper heading
> separator, then the following would be a table that Babel languages
> could interpret more easily:
>
> | a | b | c  |
> |~~~+~~~+~~~~|
> | 1 | 1 |  2 |
> | 1 | 2 |  5 |
> | 1 | 3 | 10 |
> |---+---+----|
> | 2 | 1 |  5 |
> | 2 | 2 |  8 |
> | 2 | 3 | 13 |
> |---+---+----|
> | 3 | 1 | 10 |
> | 3 | 2 | 13 |
> | 3 | 3 | 18 |
>
>
> Regards,
> Achim.

I would like to second this and actually possibly generalise the idea a
little further.

One of the problems with org tables, at the moment, is that the line
separators have two distinct functions:

1. they are used for presentation, both within org mode and for export
2. they provide key points for cell references in calculations

The two functions often coincide but not always.  For instance, the
following table is a reduced extract from a recent paper I wrote:

#+begin_src org
* Example table with multiple lines

  |   | Strategy | Average performance |
  |---+----------+---------------------|
  | / |          |                8.69 |
  | / |          |                9.72 |
  | / |          |                9.03 |
  |---+----------+---------------------|
  |   |        1 |                9.15 |
  |---+----------+---------------------|
  | / |          |                9.15 |
  | / |          |                7.60 |
  | / |          |                7.46 |
  |---+----------+---------------------|
  |   |        2 |                8.07 |
  |---+----------+---------------------|
  #+TBLFM: @5$3=vmean(@-I..@-II);%.2f::@9$3=vmean(@-I..@-II);%.2f
#+end_src

The (text) export consists of a three line table with lines separating
every line and one at the bottom as well:

   Strategy  Average performance 
  -------------------------------
          1                 9.15 
  -------------------------------
          2                 8.07 
  -------------------------------

Interesting aside: the export has only three lines whereas the original
table had 5 so the exporter is doing some intelligent work here!

Nevertheless, what I would like as the output would be

   Strategy  Average performance 
  -------------------------------
          1                 9.15 
          2                 8.07 

Unfortunately, because of the use of line separators to make
calculations easier to define, the exported table has more lines than I
would want.

At present, there is no mechanism for selective deletion of these line
separators upon export (that I know of: I would be happy to be corrected
on this!).  For the paper I submitted last week for publication, the
only post-org editing I had to do was delete a number \hline
specifications in the exported LaTeX file.  Not a major problem,
obviously, but it would be nice to not have to do even that!

Maybe there is a need for three different line separators: ~ for headers
(to be used as Achim indicates above but possibly helpful for exporters
as well), = for lines that should appear in exported output and - for
those that will not appear.  Header lines would typically export as
well.  All three would be used for formula definitions (i.e. @I
references) but would solely differ in how they are processed by the
exporters.

For upwards compatibility, should that be desired, the meaning of = and
- in the previous paragraph could be exchanged but would not be as
visually appealing (in my opinion).

Anyway, I will stop ruminating here and will get back to work...

Thanks,
eric
-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_8.0.2-68-g40635b

  reply	other threads:[~2013-05-09 12:55 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-01 14:39 using gnuplot's "splot" and "every" commands on org-mode table data Paul Stansell
2013-05-03 16:09 ` Eric Schulte
2013-05-06 18:57   ` Achim Gratz
2013-05-09 12:54     ` Eric S Fraga [this message]
2013-05-09 20:23       ` Achim Gratz
2013-05-09 20:42         ` Eric S Fraga
2013-05-11 10:39           ` Achim Gratz
2013-05-11 12:20             ` Rick Frankel
2013-05-21 12:36             ` Eric S Fraga
2013-05-07 17:14   ` Paul Stansell
2013-05-07 18:25     ` Eric Schulte
2013-05-07 18:39       ` Paul Stansell
2013-05-08 12:46         ` Eric Schulte
2013-05-08 15:48           ` Paul Stansell
2013-05-13 21:43             ` Eric Schulte
2013-05-17 15:00               ` Eric Schulte
2013-05-17 20:18                 ` Paul Stansell
2013-05-17 20:39                   ` Eric Schulte
2013-05-17 21:33                     ` Paul Stansell
2013-08-30 17:16                       ` Paul Stansell
2013-08-30 19:13                         ` Achim Gratz
2013-05-07 18:19   ` Paul Stansell
2013-05-08 12:41     ` Eric Schulte
2013-05-08 16:00       ` Paul Stansell
2013-05-12 18:55       ` Achim Gratz
2013-05-13 21:38         ` Eric Schulte
2013-05-14  7:06           ` Achim Gratz
2014-03-25 18:42           ` Achim Gratz
2013-05-11 10:51   ` Achim Gratz
2013-09-23 14:54   ` Paul Stansell
2013-09-23 23:32     ` Eric Schulte
2013-09-24 12:05       ` Paul Stansell
2013-09-25 18:21         ` Eric Schulte
2013-09-25 20:01           ` Paul Stansell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zjw4xqhr.fsf@ucl.ac.uk \
    --to=e.fraga@ucl.ac.uk \
    --cc=Stromeko@nexgo.de \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).