From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: [Feature Request] Cross headings in tables Date: Fri, 22 Feb 2013 21:33:00 +0100 Message-ID: <87txp4nl6r.fsf@Rainer.invalid> 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> <848BA974-1893-46B2-AA1E-E9837F1E6A0F@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:42627) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8zJ2-00008n-1n for emacs-orgmode@gnu.org; Fri, 22 Feb 2013 15:33:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U8zIv-0002dk-TH for emacs-orgmode@gnu.org; Fri, 22 Feb 2013 15:33:19 -0500 Received: from plane.gmane.org ([80.91.229.3]:53576) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8zIv-0002dc-MD for emacs-orgmode@gnu.org; Fri, 22 Feb 2013 15:33:13 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1U8zJD-0002gM-Fc for emacs-orgmode@gnu.org; Fri, 22 Feb 2013 21:33:31 +0100 Received: from pd9eb403c.dip.t-dialin.net ([217.235.64.60]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Feb 2013 21:33:31 +0100 Received: from Stromeko by pd9eb403c.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Feb 2013 21:33:31 +0100 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: emacs-orgmode@gnu.org Carsten Dominik writes: >> 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: >> >> #+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? I can see the appeal from a programmers' point of view, but from a user perspective this is extremely obscure, especially if that table spans a few pages and has many such extra header rows (hey, why not ask the user to write the table in XML to start with?). In any case, the current way of dealing with headers in org-element and the exporters doesn't admit either. > 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. Hindsight is 20/20. :-) But going this route takes us even further from "Your life in plain text." towards "Your life in another programming language." because you will need a special viewer or editor to make sense of it for all but the most trivial cases. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada