<br><br><div class="gmail_quote">On Sat, Sep 19, 2009 at 8:31 AM, Peter B. West <span dir="ltr"><<a href="mailto:lists@pbw.id.au">lists@pbw.id.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5"><br>
On 19/09/2009, at 5:18 AM, Nicolas Pouillard wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Excerpts from Eric Kow's message of Fri Sep 18 09:14:25 +0200 2009:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Thu, Sep 17, 2009 at 22:52:30 +0100, Ganesh Sittampalam wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This is an initial attempt at adding interactive editing of hunk<br>
patches. I don't necessarily expect this sequence to be applied<br>
as-is, though it could be.<br>
</blockquote>
<br>
What a treat! I'm going to push the easy patches first<br>
<br>
* add "parallel pairs"<br>
* break out and export run_editor utility function<br>
* Add utility code for editing text<br>
<br>
And leave the meat of this bundle for later (perhaps somebody else<br>
wants to tag themselves in?)<br>
</blockquote>
<br>
I have a question about the hunk editing feature.<br>
Does it leave the pristine tree as is (like git), or not?<br>
<br>
[...]<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
break out and export run_editor utility function<br>
------------------------------------------------<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
+run_editor :: FilePath -> IO ExitCode<br>
+run_editor f = do<br>
+ ed <- get_editor<br>
+ exec_interactive ed f<br>
+ `ortryrunning` exec_interactive "emacs" f<br>
+ `ortryrunning` exec_interactive "emacs -nw" f<br>
+ `ortryrunning` exec_interactive "nano" f<br>
+#ifdef WIN32<br>
+ `ortryrunning` exec_interactive "edit" f<br>
+#endif<br>
</blockquote>
<br>
I think all new functions should be camelCase. It's not that I care,<br>
it's just that I want it to stop even being a question. The desired<br>
outcome is that we never get anybody having to scratch their heads<br>
looking for a deeper meaning or conventions behind the case.<br>
</blockquote>
<br>
I think (if my memory serve me well) that it is one of David's convention;<br>
that is: camel case for exported values and underscores for internal ones.<br>
Which would make sense since you are exporting a previously internal thing,<br>
right?<br>
<br>
</blockquote>
<br></div></div>
I'm a mere user of darcs, waiting for the day when I can unreservedly recommend it for all SCM users, but...<br>
<br>
CamelCase is one of my pet loathings. It dramatically impacts readability in long names, consequently discouraging their use. That much, I think, is unexceptionable.<br>
<br>
If you would argue against long names, fair enough.<br>
<br>
IMO, CamelCase has a general negative impact on readability. I have heard the argument that it draws the eye to the functions and variables, which I take to support my point.<br></blockquote><div><br>Hi Don,<br><br>CamelCase is the defacto standard in the Haskell Community. For example, the Haskell Prelude uses CamelCase instead of other conventions. In the Darcs project we currently use several styles and this creates confusion and generates discussions like this one. Without reiterating the rationale, the majority of the Darcs developers feel that sticking with one convention, camaleCase in this context, is beneficial.<br>
<br>I'm sorry this convention is not your favorite, but please realize we would like to follow the style guidelines of the larger Haskell Community when we can.<br><br>When you say that it draws the eyes to functions and variables, what argument are you referring too? I find the psychology of programming to be an interesting topic so if you know of a research paper about this I would like to read it. Finally, since Haskell is emphasizes functions and named values (variables rarely exist in Haskell), it is not clear to me how CamelCase is a detriment here. Do you think you could explain what you mean?<br>
<br>Thanks,<br>Jason<br></div></div>