2 - search should go to right column and highlight
3 - do we always recenter top when we split - what if near but not at bottom
4 - side-by-side sometimes shows last line of a chunk with
6 - '|' should go from sidebyside to merge
7 - sometimes the split page gets white spaces - 'int bl_count'
8 - use next_mline in print_merge2
12 - extract.c should be able to extract half of a word-diff
13 - extract.c should work on word-merges
14 - review all test output to make sure it looks right
16 - can find_best be optimised more?
17 - --verbose flag ?? what should it do?
18 - review commented code and discard some of it
20 - possibly encourage "###...####" onto line by itself in diff output
21 - possibly remember match information while reading patch/merge
23 - is there anything useful to be done with linenumber information?
24 - document diff algorithm
25 - document best-match algorithm
26 - document merge algorithm
28 - editmail? reviewmail
29 - review wiggle failures
31 - Application of patch-03-MdRaid5Works caused some odd matches
34 report lines at which each patch was applied.??
35 - add examples to man page
39 3 windows: before, patch, after
41 -----------------------------------
42 p - md.c - wait_event_interruptible
43 The preceding tabs aren't noticed as being the same...
46 -----------------------------------
48 Some possible targets:
50 - check new marge code on all tests
51 - output merge as a diff from original
52 - handle multi-file patchs, producing new patch or updating files
53 - improve diff3 markers
55 - preserve permissions in created file
56 - allow output to have just one stream selected of conflicts.
57 - allow 'output' to include .rej files
58 - fix "produced this was" -> "produced this way" in man page
61 - Read a series of patches and determine dependancies
62 Then push a given patch forward or backward in the list.
63 Possibly full determination of dependancies isn't needed.
64 Just pust the target patch until it hits a wall, then
65 push the wall as far as it goes.
66 A potential 'wall' happens when inserted text is deleted.
67 We refine A -> B -> C and see if it can be broken up with
68 common a->a->a sections and between them,
70 There can then become x->y->y and p->p->q
71 But suppose we find x->x->y and p->q->q with no
72 a->a->a in between. Are we allowed to handle that?
80 Commutine the patches give
87 That seems safe enough. How about insertions and deletions?
100 Seems ok... Maybe the fact that we have perfect matches (no extraneous stuff)
104 So: first sort the blocks (well, the files) and see if there is any overlap
105 of after-A with before-B.
106 If not, we update offsets. Maybe store each chunk as offset-from-end-of-last.
107 If so, we extend both blocks, possibly including other blocks, to get two blocks
108 that start and end at the same place.
109 Then run a word-wise merge-like thing. If there are no conflicts, extract the new
110 intermediate file and create the new diff from that.
112 So: each patch is a list of files with hunks
113 the hunks may grow extra context as it is found in other hunks
115 To commute two patches:
116 If a chunk doesn't match any chunk in other file, just retain it.
117 If it does, expand both chunks with common data from the other
118 then run the diff code, then extract the new middle
120 ----------------------------
123 I need to improve the browsing mode. Displaying before and
124 after on the one line doesn't work very well.
125 I think both the orignal/result and the before/after views need to
126 to have -/+ lines for any difference.
127 So, for each newline we need to record whether there are any differences
128 on the line or not. If there are, we will need to display that
129 line twice, once before and once after.
130 This means we need to acknowledge two 'line' cursor positions?
131 Yes, if we are ever to have an edit cursor...
132 But don't we only need to edit the 'after'
133 Probably safer to provide for editing both as we might want to
134 do that before reapplying the diff.
136 When we have consecutive newlines that are flagged, how do we display them?
137 Grouped or interleaved?
148 Grouped is what 'diff -u' generally does, however we know more about the
149 content of the lines an whether it is a line that has been changed or a larger
150 chunk. Maybe try one and see...
152 If a line only has additions, or only has deletions it might be safe to just
153 display the more complete line.. maybe leave that for wait-and-see too.
155 For Grouped diff, we need to locate a group. Maybe we flag newlines as
156 group-begin and group-end.
158 Need to think this through..
160 A 'pos' is the end of a line. We only 'sit' on eols that are visible
161 We know the merger entry that covers this eol, and a position in one stream.
163 Unmatched, Unchange, Extraneous,
164 Then we just show the line undecorated.
165 If the line contins Changed, we show orig/result as separate lines.
166 If line contains Changed, AlreadyApplied or Conflict, we show before/after as separate lines
168 We, when we 'draw_mline'. We first do the 'before/orig' lines.
169 If there is a Changed we signal that we need a RESULT and put in a '-'
170 If there is a Changed, AlreadyApplied or Conflict, we signal the need for
171 an AFTER and put in a '-'.
172 If either were needed, we put in another line
175 as well as 'pos' we have start and end, and 'side'.
176 start is the first line in the set containing pos that have CHANGES set.
177 end is the last line in the same set
178 size is either 0 if row is a ' ', -1 if a '-' or 1 if row is a '+'
180 We need to allow for all of this when walking up and down for drawing lines.
183 - what is 'cleanlist' meant to do - it seems to badly break things.
184 DONE - implemented Grouped diffs
185 DONE - at same time, lines with no diff should show no diff.
186 - put line/col number is status bar
187 DONE - allow cursor to move left/right and scroll-on-demand.
188 - If we have selected 'before', then don't show 'after' lines..
189 DONE - blank after end and before begining
196 find char pos in search and highlight
197 multiple finds per line
198 search to loop around
199 switch from forward to reverse.
201 DONE beginning/end of line
202 left-right to handle line breaks.
203 - handle single .rej file
204 - allow updates to be saved
206 - better colours? configurable?
208 - extract.c should be able to extract half of a word-diff
209 - extract.c should work on word-merges
210 - review all test output to make sure it looks right
212 - can find_best be optimised more?
213 - --verbose flag ?? what should it do?
214 - review commented code and discard some of it
216 - possibly encourage "###...####" onto line by itself in diff output
217 - possibly remember match information while reading patch/merge
219 - is there anything useful to be done with linenumber information?
220 - document diff algorithm
221 - document best-match algorithm
222 - document merge algorithm
224 - editmail? reviewmail
225 - review wiggle failures
227 - Application of patch-03-MdRaid5Works caused some odd matches
229 - possible verbosity:
230 report lines at which each patch was applied.??
231 - add examples to man page
235 3 windows: before, patch, after
237 -----------------------------------
238 p - md.c - wait_event_interruptible
239 The preceding tabs aren't noticed as being the same...
242 -----------------------------------
244 Some possible targets:
246 - check new marge code on all tests
247 - output merge as a diff from original
248 - handle multi-file patchs, producing new patch or updating files
249 - improve diff3 markers
251 - preserve permissions in created file
252 - allow output to have just one stream selected of conflicts.
253 - allow 'output' to include .rej files
254 - fix "produced this was" -> "produced this way" in man page
257 - Read a series of patches and determine dependancies
258 Then push a given patch forward or backward in the list.
259 Possibly full determination of dependancies isn't needed.
260 Just pust the target patch until it hits a wall, then
261 push the wall as far as it goes.
262 A potential 'wall' happens when inserted text is deleted.
263 We refine A -> B -> C and see if it can be broken up with
264 common a->a->a sections and between them,
266 There can then become x->y->y and p->p->q
267 But suppose we find x->x->y and p->q->q with no
268 a->a->a in between. Are we allowed to handle that?
276 Commutine the patches give
283 That seems safe enough. How about insertions and deletions?
296 Seems ok... Maybe the fact that we have perfect matches (no extraneous stuff)
300 So: first sort the blocks (well, the files) and see if there is any overlap
301 of after-A with before-B.
302 If not, we update offsets. Maybe store each chunk as offset-from-end-of-last.
303 If so, we extend both blocks, possibly including other blocks, to get two blocks
304 that start and end at the same place.
305 Then run a word-wise merge-like thing. If there are no conflicts, extract the new
306 intermediate file and create the new diff from that.
308 So: each patch is a list of files with hunks
309 the hunks may grow extra context as it is found in other hunks
311 To commute two patches:
312 If a chunk doesn't match any chunk in other file, just retain it.
313 If it does, expand both chunks with common data from the other
314 then run the diff code, then extract the new middle
316 - move to left in tabs doesn't work right
317 - check out md.c and 383MDBlocked in demo directory