From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: [Feature Request] Cross headings in tables Date: Fri, 22 Feb 2013 13:31:28 +0100 Message-ID: <848BA974-1893-46B2-AA1E-E9837F1E6A0F@gmail.com> References: <87ocb96ebn.fsf@Rainer.invalid> <87eic4le49.fsf@Rainer.invalid> <87d3nwzo22.fsf@Rainer.invalid> <87ei7qxiuf.fsf@Rainer.invalid> <87wrlakxcv.fsf@Rainer.invalid> <87zkm3yk96.fsf@Rainer.invalid> <87tyc1xwam.fsf@Rainer.invalid> <87obfk12uh.fsf_-_@Rainer.invalid> <87y5enpcc9.fsf@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:53368) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8rmo-00075N-6j for emacs-orgmode@gnu.org; Fri, 22 Feb 2013 07:31:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U8rml-0002wK-8t for emacs-orgmode@gnu.org; Fri, 22 Feb 2013 07:31:34 -0500 Received: from mail-ee0-f41.google.com ([74.125.83.41]:64145) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8rmk-0002wA-Tr for emacs-orgmode@gnu.org; Fri, 22 Feb 2013 07:31:31 -0500 Received: by mail-ee0-f41.google.com with SMTP id c13so298119eek.0 for ; Fri, 22 Feb 2013 04:31:30 -0800 (PST) In-Reply-To: <87y5enpcc9.fsf@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Nicolas Goaziou Cc: Achim Gratz , emacs-orgmode@gnu.org On 17 feb. 2013, at 09:35, Nicolas Goaziou wrote: > Hello, >=20 > Achim Gratz writes: >=20 >> I've just looked at how to implement this using org-element and the >> new exporter. Much to my dismay I found that table headers are not >> a separate row or row group type and the new exporter is still using >> this "everything before the first separator is a heading" kludge. >=20 > I wouldn't call that a kludge. That's where most of the mere mortals > expect the heading to be anyway. Also, it's somewhat back-end = specific. >=20 >> It's easy enough to introduce a second type of separator in >> org-element (BTW, I don't think that 'rule is a particularly good >> symbol name for this) by adding another type of table rows, but then >> these lines get ignored by the new exporter. While the logic used >> there is amendable (not as easily), it would be more hackish than >> I hoped. >=20 > You only need to modify org-element if Org syntax has been changed. >=20 >> Also, it appears that each element can have only one property or did >> I miss something? It seems that having a way to get the (main) >> property and then asking if there are sub-properties on that element >> would allow simpler code in this particular instance and likely >> elsewhere. Maybe I missed how to do it, though. >=20 > I don't understand that part. For example: >=20 > --8<---------------cut here---------------start------------->8--- > * TODO Headline :tag: > --8<---------------cut here---------------end--------------->8--- >=20 > In the following buffer, you can have: >=20 > (org-element-property :priority (org-element-at-point)) > (org-element-property :tag (org-element-at-point)) > (org-element-property :todo-keyword (org-element-at-point)) > (org-element-property :todo-type (org-element-at-point)) > (org-element-property :level: (org-element-at-point)) > ... >=20 > So there is more than one property. See: >=20 > http://orgmode.org/worg/dev/org-export-reference.html >=20 > for a list of all properties associated to a given element or object > type. >=20 >> The cleanest way to implement this would be if being a header would = be a >> property of the row group (maybe returnable as the sign of the row = group >> number). There'd be two types of separators, "|-" and "|~". If the >> line past the end of a row group is "|~", then it is a header group, >> otherwise it is a normal group. This is incompatible with tradition, >> but it would allow to use row groups in formulas without introducing >> unwanted headers. >>=20 >> Thoughts? >=20 > I think the cleanest way to implement this would be to _not_ modify = Org > syntax, because it is export back-end very specific. Something like: >=20 > #+attr_html: :header-groups (1 3) > | This | will | > | be | a header | > |-----------+-----------| > | This | won't | > |-----------+-----------| > | This will | be too | > |-----------+-----------| > | This | won't too | I really like this approach, to mark the header groups in an attribute - = maybe an backend-independent attribute? The reason why I prefer this = approach is that I am weary of new syntax in Org-mode that will take up = new characters of character chains. For the case of tables, if I could = go back, I would even remove some of the syntax I introduced, for = example for defining the values of constants - that should have been an = attribute-link thing as well. Probably even row and column naming, = could have been done in this way. - Carsten