On Tue, Aug 02, 2005 at 06:54:14AM -0400, David Roundy wrote: > ... You shouldn't read defaults yourself, the code's already written that > does that. If you want to use the *remote* defaults, that's another > issue. But you shouldn't ever stick anything in defaults that isn't a > valid flag. (Users could mistakenly do so, and we should be forgiving in > parsing the file, but darcs shouldn't ask them to do so.)
Sorry, I realized I was a bit abrupt there, and that you aren't an old darcs coder. Defining new flags is done in DarcsArguments (there are many examples there to follow), and then one imports the new flag into the actual command. That's all that's needed to make defaults work with a given flag (or to make it acceptable on the command line). Then one checks for the new DarcsFlag constructor that was added to see whether the flag was given (either on command line or in defaults), and to see what the flag argument was (the hook itself, in this case). Each darcs command specifies which flags it wants in its command_darcsoptions, but doesn't necesarily need to do anything itself to implement that command. In this case, I'd implement it at a higher level, in DarcsCommands.consider_running. Pre-hooks are easier than post-hooks (and also very useful), so if you're not confident in your exception-catching skills, you could implement pre-hooks first to make sure you understand the flag-handling part. Actually, if you want to pass interesting information (e.g. lists of patches) to the hook, a prehook would actually be harder than a post-hook, but I would start with the generic sort of prehook. -- David Roundy http://www.darcs.net _______________________________________________ darcs-devel mailing list [email protected] http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
