vpatch: update status counters when we save a file.
[wiggle/upstream.git] / TODO
blob09af8d6710e643f5f9c194480e866ac007f39735
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
5   the next chunk
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
9 + discard merge.c
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
15 - document 'p' DOING
16 - can find_best be optimised more?
17 - --verbose flag ?? what should it do?
18 - review commented code and discard some of it
19 - test on raid code
20 - possibly encourage "###...####" onto line by itself in diff output
21 - possibly remember match information while reading patch/merge
22   to help matching.
23 - is there anything useful to be done with linenumber information?
24 - document diff algorithm
25 - document best-match algorithm
26 - document merge algorithm
27 - enhance 'p'
28   - editmail?  reviewmail
29   - review wiggle failures
31 - Application of patch-03-MdRaid5Works caused some odd matches
33 - possible verbosity:
34      report lines at which each patch was applied.??
35 - add examples to man page
37 - Design viewer.
38    Maybe:
39     3 windows: before, patch, after
41 -----------------------------------
42 p - md.c - wait_event_interruptible
43   The preceeding tabs aren't noticed as being the same...
46 -----------------------------------
47 31 March 2005
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
54  - modified
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
60 other things
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,
69     x->x->y or p->q->q
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?
74    This is a sentence
75     (is -> was)
76    This was a sentence
77     (a -> my)
78    This was my sentence
80    Commutine the patches give
81    This is a sentence
82     (a -> my)
83    This is my sentence
84     (is -> was)
85    This was my sentence
87    That seems safe enough.  How about insertions and deletions?
88     This a sentence 
89      (add is)
90     This is a sentence
91       (remove a)
92     This is sentence 
94     This a sentence
95       (remove a)
96     This setence
97       (add is)
98     This is sentence
100     Seems ok... Maybe the fact that we have perfect matches (no extraneous stuff)
101     make it easier....
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
114        and may even merge.
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 ----------------------------
121 27May2006
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?
138 Grouped:
139    - AAA
140    - BBB
141    + aaa
142    + bbb
143 Interleaved
144    - AAA
145    + aaa
146    - BBB
147    + bbb
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.
162 If whole line is in
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
174 Grouped diff:
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.
182 TODO
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
190  - better movement:
191      DONE   top
192      DONE   bottom
193      DONE   next/prev diff
194         next/prev conflict
195         incr-search
196         find char pos in search and highlight
197         multiple finds per line
198         search to loop around
199         switch from forward to reverse.
200      DONE   page up/down
201      DONE   beginning/end of line
202         left-right to handle line breaks.
203  - handle single .rej file
204  - allow updates to be saved
205  - allow editing???
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
211 - document 'p' DOING
212 - can find_best be optimised more?
213 - --verbose flag ?? what should it do?
214 - review commented code and discard some of it
215 - test on raid code
216 - possibly encourage "###...####" onto line by itself in diff output
217 - possibly remember match information while reading patch/merge
218   to help matching.
219 - is there anything useful to be done with linenumber information?
220 - document diff algorithm
221 - document best-match algorithm
222 - document merge algorithm
223 - enhance 'p'
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
233 - Design viewer.
234    Maybe:
235     3 windows: before, patch, after
237 -----------------------------------
238 p - md.c - wait_event_interruptible
239   The preceeding tabs aren't noticed as being the same...
242 -----------------------------------
243 31 March 2005
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
250  - modified
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
256 other things
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,
265     x->x->y or p->q->q
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?
270    This is a sentence
271     (is -> was)
272    This was a sentence
273     (a -> my)
274    This was my sentence
276    Commutine the patches give
277    This is a sentence
278     (a -> my)
279    This is my sentence
280     (is -> was)
281    This was my sentence
283    That seems safe enough.  How about insertions and deletions?
284     This a sentence 
285      (add is)
286     This is a sentence
287       (remove a)
288     This is sentence 
290     This a sentence
291       (remove a)
292     This setence
293       (add is)
294     This is sentence
296     Seems ok... Maybe the fact that we have perfect matches (no extraneous stuff)
297     make it easier....
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
310        and may even merge.
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