From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: [GSoC] org-merge-driver weekly update Date: Wed, 6 Jun 2012 15:56:08 +0200 Message-ID: <87C9FA23-FD18-4BEF-9644-5BEBA3650F41@gmail.com> References: Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:59910) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScGik-00009d-OK for emacs-orgmode@gnu.org; Wed, 06 Jun 2012 09:56:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ScGid-00059S-HS for emacs-orgmode@gnu.org; Wed, 06 Jun 2012 09:56:22 -0400 Received: from mail-we0-f169.google.com ([74.125.82.169]:55965) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScGid-00056U-8L for emacs-orgmode@gnu.org; Wed, 06 Jun 2012 09:56:15 -0400 Received: by wefh52 with SMTP id h52so5471594wef.0 for ; Wed, 06 Jun 2012 06:56:11 -0700 (PDT) In-Reply-To: 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: Andrew Young Cc: emacs-orgmode@gnu.org On 6.6.2012, at 15:50, Andrew Young wrote: > Hi Robert Horn, >=20 > On Mon, Jun 4, 2012 at 11:30 AM, Robert Horn = wrote: >> Another area that would be nice to address is taking advantage of the >> information in date-trees so assist with merging. This is similar to >> the logic around keeping headlines in order. With date trees there = is a >> date and sometimes time tag to help. >>=20 >> In addition to the occurrence order, there is also an ordering = constraint on date trees that can be used to determine the proper delta. = You can use the date and time information in the headlines to determine = the proper sequencing. >>=20 >> For example, the delta/merger for two files of the form: >> File 1: >> * Year >> ** Year-Month >> *** Year-Month-Day >> **** Y-M-D-Time1 stuff1 ... >> **** Y-M-D-Time2 stuff2 ... >> **** Y-M-D-Time4 stuff4 ... >> **** Y-M-D-Time5 stuff5 ... >> **** Y-M-D-Time9 stuff9 ... >> File 2: >> * Year >> ** Year-Month >> *** Year-Month-Day >> **** Y-M-D-Time1 stuff1 ... >> **** Y-M-D-Time2 stuff2 ... >> **** Y-M-D-Time3 stuff3 ... >> **** Y-M-D-Time6 stuff6 ... >> **** Y-M-D-Time7 stuff7 ... >>=20 >> Should be: >> * Year >> ** Year-Month >> *** Year-Month-Day >> **** Y-M-D-Time1 stuff1 ... >> **** Y-M-D-Time2 stuff2 ... >> **** Y-M-D-Time3 stuff3 ... >> **** Y-M-D-Time4 stuff4 ... >> **** Y-M-D-Time5 stuff5 ... >> **** Y-M-D-Time6 stuff6 ... >> **** Y-M-D-Time7 stuff7 ... >> **** Y-M-D-Time9 stuff9 ... >>=20 >> This time aware merge logic will apply similarly to all levels of the = date tree. >>=20 >> Date trees are recognizable by the combination of headlines in this >> format. A date tree can occur anywhere in an org file, but it will >> begin with a level one headline of the form "* YYYY", etc. >>=20 >> R Horn >> rjhorn@alum.mit.edu >=20 > Thank you for the suggestion! The program should support date trees. >=20 > I wonder if date trees specifically should be aggressively resorted > during the merge (reordering more headings than necessary, without > regards to the in-file ordering). It is currently my opinion that the > program should try to retain the original ordering as much as > possible, only sorting the minimum number of headings necessary when > merging has made the ordering ambiguous. As a general remark, if you implement things like aggressive resorting, I think it would be good to have such features optional, in some way configurable. Turning off all bells would then do a simple stable outline tree inserting like you have in your prototype. Increasing complexity can and should be implemented, but I would like them optional for users (opt-out is OK). Greetings - Carsten >=20 > Sincerely, > Andrew Young