From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: [Feature Request] Cross headings in tables Date: Sat, 23 Feb 2013 13:26:36 +0100 Message-ID: <87k3pzw70j.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> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:35936) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U9ECM-00078o-TY for emacs-orgmode@gnu.org; Sat, 23 Feb 2013 07:28:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U9EBx-0000LM-1K for emacs-orgmode@gnu.org; Sat, 23 Feb 2013 07:27:26 -0500 Received: from plane.gmane.org ([80.91.229.3]:50984) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U9EBw-0000LE-NY for emacs-orgmode@gnu.org; Sat, 23 Feb 2013 07:27:00 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1U9ECD-0000ub-NW for emacs-orgmode@gnu.org; Sat, 23 Feb 2013 13:27:17 +0100 Received: from pd9eb4683.dip.t-dialin.net ([217.235.70.131]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Feb 2013 13:27:17 +0100 Received: from Stromeko by pd9eb4683.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Feb 2013 13:27:17 +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 Nicolas Goaziou 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 | > > You are talking about formulas, so, perhaps you have plans for the > spreadsheet. Anyway, if Org syntax changes, org-element.el will have to > be updated accordingly, and so will have all the back-ends. I've been thinking about this some more. We've had enough inquiries on how to import tables from R or other programs and give it headers and other decorations, maybe even formulas without having to construct the table as Org syntax in the other language. If we made such attributes _table_ attributes (i.e. extend the table model of Org and not just some decoration in the export) then this would become an easy thing to do. So if a modification in this direction is in the cards, I certainly support this proposal. Defining a more user-friendly syntax for the main features so that most of that complexity would be out of sight most of the time shouldn't be too difficult. It adds an extra step to the normalization of tables before import/export, but the added functionality should make up for that many times over. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds