On Mon, Oct 09, 2006 at 01:05:32PM -0400, Zachary P. Landau wrote: > It might be nice if ignored patches are hidden, but their > dependencies are not. Then, if you selected a patch that depends on an > ignored patch, it could inform you that you can't until you unignore a > dependency. Or if ignoring/unignoring is eventually an option during > patch selection (which would be nice), you could unignore it there.
To be able to ignore patches with 'i' in the select dialogue, SelectChanges is definitely a place to hack in. :-) But it'll be a bit hard. The SelectChanges uses a data structure with Yes, No and Wait states for the patches in the dialogue. These states are updated in a... lets say non-trivial lazy way. I think it would be enough to have a special case No state that is No(+Ignore), that behaves exactly like No throughout the dialogue (but it shows as 'I' instead of 'N'). When the dialogue is finished, all the No(+Ignore) answers can be added to the ignore list. For the nice feature to see but not be able to select ignore-dependent patches, as suggested by Zachary, a No(+Forced) is also needed. But I think it might become very complicated to get the information into the state list, since it is evaluated lazily, so an easier way is to include also the ignored patches as yet another No(+Forced+Invisible) state. The idea is that Forced will prevent the user from altering the state, Invisible (and Ignored above) will affect the display (and jumping), and apart from that, Yes, No and Wait will work exactly as before with no extra changes needed. I think unignoring patches (with 'u') can wait until we get ignoring working. Removing patches manually from the ignore file might be good enough after all. There is also a feature request to change the behavior of Wait state to Maybe state. At present, a Wait state will switch to Yes or No as soon as any dependency requires it, and never go back to Wait again (unless the user hits 'w'). If I say Yes to a patch and some Wait patches become Yes because of this, and I change my mind and say No to the same patch, these extra patches will still be Yes, and I don't know which they are. The Maybe state should instead mean "No, unless required", so that each Maybe state in every new configuration is Maybe(+Yes) only if it is required by some Yes or Maybe(+Yes) state, and Maybe(+No) otherwise. It might be rather complicated to hack this, but it might also be efficient to try to do it at the same time, since both features requires active knowledge of the same piece of code. -- Tommy Pettersson <[EMAIL PROTECTED]> _______________________________________________ darcs-users mailing list [email protected] http://www.abridgegame.org/mailman/listinfo/darcs-users
