On Tuesday 03 February 2009, Eric Kow wrote: > On Tue, Feb 03, 2009 at 19:56:57 +0200, Dan Pascu wrote: > > I agree. It's an absolute NO to impose someone's view on style on > > everybody else. > > Okay, that's three comments, all pointing in the same direction. > Thanks all!
As I said, I do think there can be some merit to the idea if done right. Say we have some functions to check specific predefined rules, but by default they do not enforce anything. Then let's say I have a way to indicate per repository that want to use certain rules that I find useful. Say something like: darcs setpref patch_naming_rules "length=10:70,capitalize,end_with_dot" Which means that in that project I want patch names to not exceed 70 chars or be shorter than 10 chars, I want to have a capital first letter in the patch name and I want it to end with a dot. Of course the last 2 can even be smart, so instead of just warning me that I didn't followed those rules, to automatically capitalize the first letter and add a dot at the end if missing. However this "smartness" is debatable as it can easily turn against you. Now I'm not sure how easy would be to implement something like this in darcs, but in this form it can become useful without being annoying. These rules should enforce the style, i.e. if you do not follow it, they won't just warn you they will simply refuse to do the operation. But then, they were added with consent by the people working on the project with the purpose of enforcing a certain style, so they will not be perceived as annoyances, but as reminders. > > As for issue1000, how do you define a "strange" name and where do you > > stop? > > Well, in the case of issue1000, I'll point out that the intention is > not to trap user style errors, but to preserve user intention. That > is, most likely, the user did not mean to enter '.' or '-l' as a patch > name, so I think it's acceptable to do something. On the other hand, I > also agree with the UI principle an undo mechanism is far better than a > confirmation dialogue I agree that trying to trap some user errors can be helpful to prevent a more costly undo/redo operation. However this approach only works well if you can made the false positives approach zero. In this case the user can really perceive it as helpful because it warned him of a real issue before it happened, avoiding a more costly undo/redo after the problem is noticed. However if the false positive rate is high then the warnings will be perceived as annoyances instead and the user will quickly learn to ignore them, even when they may be valid. Say for example you warn for a dash at the beginning of the patch name. Now assume someone always uses a dash at the beginning of every patch name because he thinks it looks better than way. In this case you have 100% false positives and the warnings will be annoying. This is why I asked how do you define these cases and where do you stop. Probably there are some cases that can be defined without problem, for example no patch name should be an option name from the preceding command. Or consist of a single character. However predicting what is an user error and what is just someone's idea of how is best to operate his repository is not that easy and can turn back to bite you. OTOH having the ability to undo never does that as it moves the responsibility of fixing the error to the entity that generated it (the user) and knows better if it's an error or not and how to fix it. -- Dan _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
