TODO

   1
   2 - extract.c should be able to extract half of a word-diff
   3 - extract.c should work on word-merges
   4 - review all test output to make sure it looks right
   5 - document 'p' DOING
   6 - can find_best be optimised more?
   7 - --verbose flag ?? what should it do?
   8 - review commented code and discard some of it
   9 - test on raid code
  10 - possibly encourage "###...####" onto line by itself in diff output
  11 - possibly remember match information while reading patch/merge
  12   to help matching.
  13 - is there anything useful to be done with linenumber information?
  14 - document diff algorithm
  15 - document best-match algorithm
  16 - document merge algorithm
  17 - enhance 'p'
  18   - editmail?  reviewmail
  19   - review wiggle failures
  20
  21 - Application of patch-03-MdRaid5Works caused some odd matches
  22
  23 - possible verbosity:
  24      report lines at which each patch was applied.??
  25 - add examples to man page
  26
  27 - Design viewer.
  28    Maybe:
  29     3 windows: before, patch, after
  30
  31 -----------------------------------
  32 p - md.c - wait_event_interruptible
  33   The preceeding tabs aren't noticed as being the same...
  34
  35
  36 -----------------------------------
  37 31 March 2005
  38 Some possible targets:
  39
  40  - check new marge code on all tests
  41  - output merge as a diff from original
  42  - handle multi-file patchs, producing new patch or updating files
  43  - improve diff3 markers
  44  - modified
  45  - preserve permissions in created file
  46  - allow output to have just one stream selected of conflicts.
  47  - allow 'output' to include .rej files
  48  - fix "produced this was" -> "produced this way" in man page
  49
  50 other things
  51  - Read a series of patches and determine dependancies
  52    Then push a given patch forward or backward in the list.
  53    Possibly full determination of dependancies isn't needed.
  54    Just pust the target patch until it hits a wall, then
  55    push the wall as far as it goes.
  56    A potential 'wall' happens when inserted text is deleted.
  57    We refine A -> B -> C and see if it can be broken up with
  58    common a->a->a sections and between them,
  59     x->x->y or p->q->q
  60    There can then become x->y->y and p->p->q
  61    But suppose we find x->x->y and p->q->q with no
  62    a->a->a in between.  Are we allowed to handle that?
  63
  64    This is a sentence
  65     (is -> was)
  66    This was a sentence
  67     (a -> my)
  68    This was my sentence
  69
  70    Commutine the patches give
  71    This is a sentence
  72     (a -> my)
  73    This is my sentence
  74     (is -> was)
  75    This was my sentence
  76
  77    That seems safe enough.  How about insertions and deletions?
  78     This a sentence
  79      (add is)
  80     This is a sentence
  81       (remove a)
  82     This is sentence
  83
  84     This a sentence
  85       (remove a)
  86     This setence
  87       (add is)
  88     This is sentence
  89
  90     Seems ok... Maybe the fact that we have perfect matches (no extraneous stuff)
  91     make it easier....
  92
  93
  94     So: first sort the blocks (well, the files) and see if there is any overlap
  95     of after-A with before-B.
  96     If not, we update offsets.  Maybe store each chunk as offset-from-end-of-last.
  97     If so, we extend both blocks, possibly including other blocks, to get two blocks
  98     that start and end at the same place.
  99     Then run a word-wise merge-like thing.  If there are no conflicts, extract the new
 100     intermediate file and create the new diff from that.
 101
 102     So: each patch is a list of files with hunks
 103       the hunks may grow extra context as it is found in other hunks
 104        and may even merge.
 105      To commute two patches:
 106         If a chunk doesn't match any chunk in other file, just retain it.
 107         If it does, expand both chunks with common data from the other
 108          then run the diff code, then extract the new middle
 109
 110 ----------------------------
 111 27May2006
 112
 113 I need to improve the browsing mode. Displaying before and
 114 after on the one line doesn't work very well.
 115 I think both the orignal/result and the before/after views need to
 116 to have  -/+ lines for any difference.
 117 So, for each newline we need to record whether there are any differences
 118 on the line or not.  If there are, we will need to display that
 119 line twice, once before and once after.
 120 This means we need to acknowledge two 'line' cursor positions?
 121    Yes, if we are ever to have an edit cursor...
 122   But don't we only need to edit the 'after'
 123    Probably safer to provide for editing both as we might want to
 124    do that before reapplying the diff.
 125
 126 When we have consecutive newlines that are flagged, how do we display them?
 127 Grouped or interleaved?
 128 Grouped:
 129    - AAA
 130    - BBB
 131    + aaa
 132    + bbb
 133 Interleaved
 134    - AAA
 135    + aaa
 136    - BBB
 137    + bbb
 138 Grouped is what 'diff -u' generally does, however we know more about the
 139 content of the lines an whether it is a line that has been changed or a larger
 140 chunk.  Maybe try one and see...
 141
 142 If a line only has additions, or only has deletions it might be safe to just
 143 display the more complete line.. maybe leave that for wait-and-see too.
 144
 145 For Grouped diff, we need to locate a group. Maybe we flag newlines as
 146 group-begin and group-end.
 147
 148 Need to think this through..
 149
 150 A 'pos' is the end of a line.  We only 'sit' on eols that are visible
 151 We know the merger entry that covers this eol, and a position in one stream.
 152 If whole line is in
 153     Unmatched, Unchange, Extraneous,
 154 Then we just show the line undecorated.
 155 If the line contins Changed, we show orig/result as separate lines.
 156 If line contains Changed, AlreadyApplied or Conflict, we show before/after as separate lines
 157
 158 We, when we 'draw_mline'. We first do the 'before/orig' lines.
 159 If there is a Changed we signal that we need a RESULT and put in a '-'
 160 If there is a Changed, AlreadyApplied or Conflict, we signal the need for
 161         an AFTER and put in a '-'.
 162 If either were needed, we put in another line
 163
 164 Grouped diff:
 165  as well as 'pos' we have start and end, and 'side'.
 166    start is the first line in the set containing pos that have CHANGES set.
 167    end is the last line in the same set
 168    size is either 0 if row is a ' ', -1 if a '-' or 1 if row is a '+'
 169
 170  We need to allow for all of this when walking up and down for drawing lines.
 171
 172 TODO
 173  - what is 'cleanlist' meant to do - it seems to badly break things.
 174 DONE - implemented Grouped diffs
 175 DONE - at same time, lines with no diff should show no diff.
 176  - put line/col number is status bar
 177 DONE - allow cursor to move left/right and scroll-on-demand.
 178  - If we have selected 'before', then don't show 'after' lines..
 179 DONE - blank after end and before begining
 180  - better movement:
 181      DONE   top
 182      DONE   bottom
 183      DONE   next/prev diff
 184         next/prev conflict
 185         incr-search
 186         find char pos in search and highlight
 187         multiple finds per line
 188         search to loop around
 189         switch from forward to reverse.
 190      DONE   page up/down
 191      DONE   beginning/end of line
 192         left-right to handle line breaks.
 193  - handle single .rej file
 194  - allow updates to be saved
 195  - allow editing???
 196  - better colours? configurable?
 197
 198 - extract.c should be able to extract half of a word-diff
 199 - extract.c should work on word-merges
 200 - review all test output to make sure it looks right
 201 - document 'p' DOING
 202 - can find_best be optimised more?
 203 - --verbose flag ?? what should it do?
 204 - review commented code and discard some of it
 205 - test on raid code
 206 - possibly encourage "###...####" onto line by itself in diff output
 207 - possibly remember match information while reading patch/merge
 208   to help matching.
 209 - is there anything useful to be done with linenumber information?
 210 - document diff algorithm
 211 - document best-match algorithm
 212 - document merge algorithm
 213 - enhance 'p'
 214   - editmail?  reviewmail
 215   - review wiggle failures
 216
 217 - Application of patch-03-MdRaid5Works caused some odd matches
 218
 219 - possible verbosity:
 220      report lines at which each patch was applied.??
 221 - add examples to man page
 222
 223 - Design viewer.
 224    Maybe:
 225     3 windows: before, patch, after
 226
 227 -----------------------------------
 228 p - md.c - wait_event_interruptible
 229   The preceeding tabs aren't noticed as being the same...
 230
 231
 232 -----------------------------------
 233 31 March 2005
 234 Some possible targets:
 235
 236  - check new marge code on all tests
 237  - output merge as a diff from original
 238  - handle multi-file patchs, producing new patch or updating files
 239  - improve diff3 markers
 240  - modified
 241  - preserve permissions in created file
 242  - allow output to have just one stream selected of conflicts.
 243  - allow 'output' to include .rej files
 244  - fix "produced this was" -> "produced this way" in man page
 245
 246 other things
 247  - Read a series of patches and determine dependancies
 248    Then push a given patch forward or backward in the list.
 249    Possibly full determination of dependancies isn't needed.
 250    Just pust the target patch until it hits a wall, then
 251    push the wall as far as it goes.
 252    A potential 'wall' happens when inserted text is deleted.
 253    We refine A -> B -> C and see if it can be broken up with
 254    common a->a->a sections and between them,
 255     x->x->y or p->q->q
 256    There can then become x->y->y and p->p->q
 257    But suppose we find x->x->y and p->q->q with no
 258    a->a->a in between.  Are we allowed to handle that?
 259
 260    This is a sentence
 261     (is -> was)
 262    This was a sentence
 263     (a -> my)
 264    This was my sentence
 265
 266    Commutine the patches give
 267    This is a sentence
 268     (a -> my)
 269    This is my sentence
 270     (is -> was)
 271    This was my sentence
 272
 273    That seems safe enough.  How about insertions and deletions?
 274     This a sentence
 275      (add is)
 276     This is a sentence
 277       (remove a)
 278     This is sentence
 279
 280     This a sentence
 281       (remove a)
 282     This setence
 283       (add is)
 284     This is sentence
 285
 286     Seems ok... Maybe the fact that we have perfect matches (no extraneous stuff)
 287     make it easier....
 288
 289
 290     So: first sort the blocks (well, the files) and see if there is any overlap
 291     of after-A with before-B.
 292     If not, we update offsets.  Maybe store each chunk as offset-from-end-of-last.
 293     If so, we extend both blocks, possibly including other blocks, to get two blocks
 294     that start and end at the same place.
 295     Then run a word-wise merge-like thing.  If there are no conflicts, extract the new
 296     intermediate file and create the new diff from that.
 297
 298     So: each patch is a list of files with hunks
 299       the hunks may grow extra context as it is found in other hunks
 300        and may even merge.
 301      To commute two patches:
 302         If a chunk doesn't match any chunk in other file, just retain it.
 303         If it does, expand both chunks with common data from the other
 304          then run the diff code, then extract the new middle
 305
 306  - move to left in tabs doesn't work right
 307  - check out md.c and 383MDBlocked in demo directory
 308