On Wed, Jan 16, 2013 at 6:54 PM, j. van den hoff <[email protected]>wrote:
> thanks for clarification. I understand that empty arguments can make sense > in some cases > (whether empty commits really do, we don't quite agree, obviously...) but > I nevertheless don't understand > what > We probably do agree - i despise empty commit messages, but they are not strictly prohibited, neither technically nor philosophically. It was just an example of why fixing this at a "global" level (in the main app setup) would break at least one use case in a very undesired way. so maybe this should still be decided on a per-command base (and an empty > value to an option is also > a different thing (or at least could be handled differently) then an empty > string as argument, right?). > i agree that it's "broken", but not broken enough to inspire me to fix it ;). Patches are welcomed :). Fixing this in most of the current code (that which uses position parameters as opposed to -flags) would be a real pain in the neck. Not impossible, just tedious. Fixing it properly would probably require that when one encounter an empty argument in a spot where it should be ignored/skipped, that one update g.argv and g.argc to remove the argument at the "bad" position, and then re-start the currently-running command (using 'goto'). -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
