Hi Nicolas,
On 04/07/2020 03:58, Nicolas Goaziou wrote:
I'm sure this PLOT extension is useful.
My point is that complexity should be moved to Org Babel, if possible,
not into affiliated keywords. IOW, it would be nice if gnuplot source
code blocks were as easy to use as your extension.
I do
Hello,
Mario Frasca writes:
> I'm happy it exists. it has a very low entrance threshold, just use
> it and tweak it bit by bit. the other methods, apart from gnuplot
> itself, are out of reach on my system, a Maemo-freemantle N900. it's
> not my original system, just a recent replacement,
Good morning Nicolas,
On 01/07/2020 05:46, Nicolas Goaziou wrote:
There are multiple ways to draw a diagram from a table. […]
I didn't check but I think Org Plot predates Org Babel. It probably
wouldn't exist otherwise.
I'm happy it exists. it has a very low entrance threshold, just use it
Hello,
Mario Frasca writes:
> IMO, we are keeping org-plot artificially basic.
Exactly.
There are multiple ways to draw a diagram from a table. One could use
gnuplot, or asymptote, or R, or, matplotlib… From a design point of
view, there is no particular reason to favor one way or the other,
On 29/06/2020 13:36, Nicolas Goaziou wrote:
IMO, Org Plot should be very basic, and complexity
should go into Babel code blocks, which are more capable.
IMO, we are keeping org-plot artificially basic. But you know what?
I'm just happy with my additions, my point was to share them with the
Mario Frasca writes:
> again, my idea is that we're describing something new, and I'm
> wondering what lisp construct could be used to describe a table like
> this one:
>
> | h1 | h2 | h3 |
> |++|
> | 11 | 12 | 13 |
> | 21 | 22 | 23 |
> | 31 | 32 | 33 |
> |++|
> | a1 | a2
Hi Nicolas,
sorry for not explaining it clearly. see, I'm considering from the
point of view of a user, who organizes a table in terms of logical
units, like a header, one or more body blocks, and a summary line.
these concepts are not yet all supported by the org-table code, and
again,
Hello,
Mario Frasca writes:
> not only this … it could also be like (:header HEADER :body BODY :body
> BODY), that is, repeating block.
I'm not sure about what you mean.
> I don't know, just doubting how to be more general.
>
> in practice, I'm thinking of the case when I have a header, a
On 28/06/2020 18:17, Nicolas Goaziou wrote:
This could be extracted as an independent function, which would return
the header, or nil. We can also imagine a function returning a cons cell
(HEADER . BODY), both HEADER and BODY being list of rows (possibly
empty).
not only this … it could also
Hello,
Mario Frasca writes:
> On 24/06/2020 02:19, Nicolas Goaziou wrote:
>>
This could be extracted as an independent function, which would return
the header, or nil. We can also imagine a function returning a cons cell
(HEADER . BODY), both HEADER and BODY being list of rows
Hi Nicolas and the whole world,
On 24/06/2020 02:19, Nicolas Goaziou wrote:
This could be extracted as an independent function, which would return
the header, or nil. We can also imagine a function returning a cons cell
(HEADER . BODY), both HEADER and BODY being list of rows (possibly
Hello,
Mario Frasca writes:
> On 13/06/2020 17:18, Nicolas Goaziou wrote:
>> Unit tests are not worth a formal definition. However, "test-ox.el"
>> contains unit tests.
>
> I'm not sure what you mean by the first sentence
I mean that, even though unit tests are great, and certainly welcome,
Hi Nicolas,
On 13/06/2020 17:18, Nicolas Goaziou wrote:
Hello,
Mario Frasca writes:
I can leave existing loops in peace, or edit them keeping them
cl-loop-free. as for myself, I find it practical and readable.
Then you'll enjoy reading, e.g., `org-contacts-try-completion-prefix'.
FWIW, I
Hello,
Mario Frasca writes:
> is there an agreement on cl-lib usage within the project?
Using cl-lib is OK, even though I wish we could use "seq.el" instead.
> I was hinted at cl-loop in this mailing list, and I liked it, in
> particular the `collect' clause, the destructuring feature, and
what about these two groups of tests, and the header collapse function?
>From ceb21024159a75dbdb9fef32eebe1fc8c7076d2f Mon Sep 17 00:00:00 2001
From: mfrasca
Date: Fri, 12 Jun 2020 11:42:34 -0500
Subject: [PATCH] lisp/org-table.el: Allow collapsing header into single line
* lisp/org-table.el
hi Nicolas,
is there an agreement on cl-lib usage within the project? I was hinted
at cl-loop in this mailing list, and I liked it, in particular the
`collect' clause, the destructuring feature, and less parentheses. I
had no exposure to cl-loop before the hint received here.
I can leave
Hello,
Mario Frasca writes:
> (org-table-to-lisp): simplify code, changing a `while' to a
> `cl-loop', remove leading `hline' symbols from result, edit
> documentation to reflect change.
Please don't. Even if it has its uses, cl-loop is a complicated
non-Lispy beast, and introducing it
it misses unit tests, I need to make the collapse optional, and I need
to hear from users what they think of it. this patch allows me to write
a table like the following, having a three-lines header:
| n | data | prove, | casi, | ratio | prove, | casi, |
| | | valore | valore |
18 matches
Mail list logo
