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: [PATCH] allow for multiline headers
Date: Sun, 14 Jun 2020 00:18:05 +0200	[thread overview]
Message-ID: <87tuzeehk2.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <f2f9160b-399c-71e3-357d-f1454e975b59@anche.no> (Mario Frasca's message of "Sat, 13 Jun 2020 15:20:01 -0500")

Hello,

Mario Frasca <mario@anche.no> 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 less
> parentheses.

That's exactly my point. It does way too much, and it is very far from
Lisp. Since it does so much stuff, it is tempting to use it all over the
place, for every single iteration. And then, your code doesn't look like
Lisp anymore. See how they defaced that poor "org-contacts.el" =/

> 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 don't.

> this is not a correct description of the current status, at least not
> within org-plot.
>
> (let ((table (org-table-to-lisp)) …
>
> in org-plot we expect either the first or the second element of
> `table' to be a list;
>
> any leading `hline' is removed;

I don't know Org Plot enough, but these expectations should be located
in "org-plot.el". I expect `org-table-to-lisp' to be as faithful as
possible. In particular, this function is used in `org-table-align'; as
such, it should not do anything fancy.

> a table looking like hline-header-hline-data is treated as having
> a header, while your description says it's all data, no header,
> because of the leading hline.

The manual states:

    Rows before the first horizontal rule are header lines.

But you are right, this is ambiguous. 

Moreover, I mis-remembered how I defined header lines in the export
framework. Per "ox.el", the header is the first row group. A row group
is a group of one or more data rows located between row separators or
table boundaries. This is more accurate than the above.

> but in my opinion if there's any problem or misunderstanding here,
> it's because there's no unit tests that describe the correct
> behaviour.  can we work at that?

Unit tests are not worth a formal definition. However, "test-ox.el"
contains unit tests.

> anyhow, what do you think of the multiple-lines-header option?

Multiple lines header are already a thing, at least in the export
framework. Try to export, e.g.,

    | a |
    | b |
    |---|
    | c |

in HTML. They are also assumed to be valid in the manual, per above.

So, if your question is: "should Org support multiple lines headers?",
I'd say that it already does, but it should definitely be made more
consistent across the various libraries (e.g., Org Plot).

Regards,

-- 
Nicolas Goaziou


  parent reply	other threads:[~2020-06-13 22:18 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-12 17:14 [PATCH] allow for multiline headers Mario Frasca
2020-06-12 22:44 ` Nicolas Goaziou
2020-06-13 20:20   ` Mario Frasca
2020-06-13 21:20     ` Mario Frasca
2020-06-13 22:18     ` Nicolas Goaziou [this message]
2020-06-13 23:03       ` Mario Frasca
2020-06-14 19:23         ` Nicolas Goaziou
     [not found]           ` <3e6ee551-4ef7-7d96-93dc-19a4973e1af8@anche.no>
     [not found]             ` <871rm5vslh.fsf@nicolasgoaziou.fr>
2020-06-27 15:39               ` Mario Frasca
2020-06-28 23:17                 ` Nicolas Goaziou
2020-06-29  0:27                   ` Mario Frasca
2020-06-29 12:50                     ` Nicolas Goaziou
2020-06-29 16:26                       ` Mario Frasca
2020-06-29 18:36                         ` Nicolas Goaziou
2020-06-29 22:01                           ` Mario Frasca
2020-07-01 10:46                             ` Nicolas Goaziou
2020-07-01 12:06                               ` Mario Frasca
2020-07-04  8:58                                 ` Nicolas Goaziou
2020-07-04 13:47                                   ` Mario Frasca

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=87tuzeehk2.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).