]> git.neil.brown.name Git - wiggle.git/blob - TODO
Disable *all* backups when --no-backups used
[wiggle.git] / TODO
1
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
10
11
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
30
31 - Application of patch-03-MdRaid5Works caused some odd matches
32
33 - possible verbosity:
34      report lines at which each patch was applied.??
35 - add examples to man page
36
37 - Design viewer.
38    Maybe:
39     3 windows: before, patch, after
40
41 -----------------------------------
42 p - md.c - wait_event_interruptible
43   The preceding tabs aren't noticed as being the same...
44
45
46 -----------------------------------
47 31 March 2005
48 Some possible targets:
49
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
59
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?
73
74    This is a sentence
75     (is -> was)
76    This was a sentence
77     (a -> my)
78    This was my sentence
79  
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
86
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 
93
94     This a sentence
95       (remove a)
96     This setence
97       (add is)
98     This is sentence
99
100     Seems ok... Maybe the fact that we have perfect matches (no extraneous stuff)
101     make it easier....
102
103
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.
111
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
119
120 ----------------------------
121 27May2006
122
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.
135
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...
151
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.
154
155 For Grouped diff, we need to locate a group. Maybe we flag newlines as
156 group-begin and group-end.
157
158 Need to think this through..
159
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
167
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
173
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 '+'
179
180  We need to allow for all of this when walking up and down for drawing lines.
181
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?
207
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
226
227 - Application of patch-03-MdRaid5Works caused some odd matches
228
229 - possible verbosity:
230      report lines at which each patch was applied.??
231 - add examples to man page
232
233 - Design viewer.
234    Maybe:
235     3 windows: before, patch, after
236
237 -----------------------------------
238 p - md.c - wait_event_interruptible
239   The preceding tabs aren't noticed as being the same...
240
241
242 -----------------------------------
243 31 March 2005
244 Some possible targets:
245
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
255
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?
269
270    This is a sentence
271     (is -> was)
272    This was a sentence
273     (a -> my)
274    This was my sentence
275  
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
282
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 
289
290     This a sentence
291       (remove a)
292     This setence
293       (add is)
294     This is sentence
295
296     Seems ok... Maybe the fact that we have perfect matches (no extraneous stuff)
297     make it easier....
298
299
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.
307
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
315
316  - move to left in tabs doesn't work right
317  - check out md.c and 383MDBlocked in demo directory
318