On 6.6.2012, at 15:50, Andrew Young wrote: > Hi Robert Horn, > > On Mon, Jun 4, 2012 at 11:30 AM, Robert Horn <rjh...@alum.mit.edu> 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. >> >> 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. >> >> 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 ... >> >> 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 ... >> >> This time aware merge logic will apply similarly to all levels of the date >> tree. >> >> 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. >> >> R Horn >> rjh...@alum.mit.edu > > Thank you for the suggestion! The program should support date trees. > > 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 > > Sincerely, > Andrew Young
