emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Mario Frasca <mario@anche.no>
Cc: emacs-orgmode@gnu.org
Subject: Re: tables, positioning of `#+Plot:' lines
Date: Fri, 05 Jun 2020 22:08:04 +0200	[thread overview]
Message-ID: <873679p97f.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <f798a70b-d64a-b3b1-a35e-a59f2c56e2f5@anche.no> (Mario Frasca's message of "Fri, 5 Jun 2020 14:49:43 -0500")

Hello,

Mario Frasca <mario@anche.no> writes:

> I was wondering about the position of the `#+plot:' lines.  we have
> a table, and if we want to have formulas, we put these in a `#+TBLFM:'
> line following the table.  the documentation of org-plot states that
> `#+PLOT:' lines are looked for: following, or preceding the table

Then the documentation needs to be fixed.

> but then only the "preceding" strategy is implemented.  I tried just
> out of curiosity, what happens if I put my `#+PLOT:' lines following
> the table but before the `#+TBLFM:' line.  in this case also the
> `#+TBLFM:' line is not found.
>
> I see a couple of problems with this approach and in the current
> implementation:
>
> - only one single `#+TBLFM:' line is recognized,

IIRC, this was a feature request, even though we could allow multiple
TBLFM lines. Why some users requested to have only one active TBLFM line
at a time, I don't know.

> it must follow the table, there cannot be any other meta information
> in between the table and the `#+TBLFM:' line.

What kind of meta information?

You don't need to create monster-tables. You may simply write a table,
and use it as input in a dedicated gnuplot source block.

> my main doubt is that if we acknowledge meta lines at both ends, we
> end up with an unmanageable mess, where similar information can be
> very distant in the document.  I think it was a mistake to let PLOT
> directives be placed elsewhere than formulas, but I don't know if it's
> still worth changing this.

Since TBLFM lines are the odd ones, the mistake was to allow them after
the table, while every other affiliated keyword in the Org universe goes
before the object it applies to.

IOW, I don't think also allowing PLOT affiliated keyword at the end of
the table is a good idea, and I'm sure that allowing it on both ends is
a bad one.

Regards,

-- 
Nicolas Goaziou


  reply	other threads:[~2020-06-05 20:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-05 19:49 tables, positioning of `#+Plot:' lines Mario Frasca
2020-06-05 20:08 ` Nicolas Goaziou [this message]
2020-06-05 20:16   ` Mario Frasca
2020-06-05 21:16     ` Nicolas Goaziou

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=873679p97f.fsf@nicolasgoaziou.fr \
    --to=mail@nicolasgoaziou.fr \
    --cc=emacs-orgmode@gnu.org \
    --cc=mario@anche.no \
    /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).