[PATCH 0 of 2] hgeditor: make vim close the diff window automatically when :wq'ing

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH 0 of 2] hgeditor: make vim close the diff window automatically when :wq'ing

Itamar Ravid-3
Hi list - as per issue #2124, currently when using hgeditor with vim, the diff window isn't automatically closed when
:wq'ing in the commit message window. These two patches abstract the functionality of calling an editor into an edit function,
and change the arguments vim is called with to make the diff window a help buffer (shamelessly stolen from the wiki).

I am aware that users are supposed to change hgeditor to fit their needs, but this default functionality makes hgeditor
more useful and is a feature most users would like.

Comment away! :-)
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

[PATCH 1 of 2] Abstract the functionality of calling an editor into the 'edit' function to prevent

Itamar Ravid-3
# HG changeset patch
# User Itamar Ravid <[hidden email]>
# Date 1270307531 -10800
# Node ID 2272a05026eb11f2d52067606729df6d86f18627
# Parent  cd0c49bdbfd9edab18c3656d8a8a0bd27a9aa82a
Abstract the functionality of calling an editor into the 'edit' function to prevent
users from having to mess with the code responsible for generating the temporary
commit message and diff files.

diff -r cd0c49bdbfd9 -r 2272a05026eb hgeditor
--- a/hgeditor Thu Apr 01 17:51:59 2010 -0500
+++ b/hgeditor Sat Apr 03 18:12:11 2010 +0300
@@ -3,19 +3,22 @@
 # This is an example of using HGEDITOR to create of diff to review the
 # changes while commiting.
 
-# If you want to pass your favourite editor some other parameters
-# only for Mercurial, modify this:
-case "${EDITOR}" in
-    "")
-        EDITOR="vi"
-        ;;
-    emacs)
-        EDITOR="$EDITOR -nw"
-        ;;
-    gvim|vim)
-        EDITOR="$EDITOR -f -o"
-        ;;
-esac
+# Edit a file, optionally opening another one as reference within the editor.
+# If you want to pass your favourite editor some other parameters only for Mercurial,
+# modify the 'case' statement within this function.
+edit() {
+    case "${EDITOR}" in
+        "")
+            vi "$1" "$2"
+            ;;
+        emacs)
+            emacs -nw "$1" "$2"
+            ;;
+        gvim|vim)
+            $EDITOR -f -o "$1" "$2"
+            ;;
+    esac
+}
 
 
 HGTMP=""
@@ -45,9 +48,9 @@
     MD5=$(which md5 2>/dev/null)
 [ -x "${MD5}" ] && CHECKSUM=`${MD5} "$HGTMP/msg"`
 if [ -s "$HGTMP/diff" ]; then
-    $EDITOR "$HGTMP/msg" "$HGTMP/diff" || exit $?
+    edit "$HGTMP/msg" "$HGTMP/diff" || exit $?
 else
-    $EDITOR "$HGTMP/msg" || exit $?
+    edit "$HGTMP/msg" || exit $?
 fi
 [ -x "${MD5}" ] && (echo "$CHECKSUM" | ${MD5} -c >/dev/null 2>&1 && exit 13)
 
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

[PATCH 2 of 2] Make g/vim treat the diff window, if it exists, as a 'help' buffer, thereby

Itamar Ravid-3
In reply to this post by Itamar Ravid-3
# HG changeset patch
# User Itamar Ravid <[hidden email]>
# Date 1270307628 -10800
# Node ID 5fc5fafcbcd7a66fe6354dddee8241d52997a776
# Parent  2272a05026eb11f2d52067606729df6d86f18627
Make g/vim treat the diff window, if it exists, as a 'help' buffer, thereby
closing it automatically when :wq'ing the commit message window.

diff -r 2272a05026eb -r 5fc5fafcbcd7 hgeditor
--- a/hgeditor Sat Apr 03 18:12:11 2010 +0300
+++ b/hgeditor Sat Apr 03 18:13:48 2010 +0300
@@ -15,7 +15,11 @@
             emacs -nw "$1" "$2"
             ;;
         gvim|vim)
-            $EDITOR -f -o "$1" "$2"
+            if [ x$2 != "x" ]; then
+                $EDITOR "+e $2" "+set buftype=help" "+split $1"
+            else
+                $EDITOR "$1"
+            fi
             ;;
     esac
 }
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1 of 2] Abstract the functionality of calling an editor into the 'edit' function to prevent

Mads Kiilerich
In reply to this post by Itamar Ravid-3
Itamar Ravid wrote, On 04/03/2010 05:17 PM:
> # HG changeset patch
> # User Itamar Ravid<[hidden email]>
> # Date 1270307531 -10800
> # Node ID 2272a05026eb11f2d52067606729df6d86f18627
> # Parent  cd0c49bdbfd9edab18c3656d8a8a0bd27a9aa82a
> Abstract the functionality of calling an editor into the 'edit' function to prevent
> users from having to mess with the code responsible for generating the temporary
> commit message and diff files.
>    

I don't know where it is documented, but the first line of the commit
message is special by convention supported by Mercurial. IIRC it should
be a summary of the change, no more than 80 characters, and preferable
prefixed with (in this case) "hgeditor:".

[crew: Should the exact guideline (whatever it is) be added to
ContributingChanges? (Perhaps together with some advice of content and
language)]

> diff -r cd0c49bdbfd9 -r 2272a05026eb hgeditor
> --- a/hgeditor Thu Apr 01 17:51:59 2010 -0500
> +++ b/hgeditor Sat Apr 03 18:12:11 2010 +0300
> @@ -3,19 +3,22 @@
>   # This is an example of using HGEDITOR to create of diff to review the
>   # changes while commiting.
>
> -# If you want to pass your favourite editor some other parameters
> -# only for Mercurial, modify this:
> -case "${EDITOR}" in
> -    "")
> -        EDITOR="vi"
> -        ;;
> -    emacs)
> -        EDITOR="$EDITOR -nw"
> -        ;;
> -    gvim|vim)
> -        EDITOR="$EDITOR -f -o"
> -        ;;
> -esac
> +# Edit a file, optionally opening another one as reference within the editor.
> +# If you want to pass your favourite editor some other parameters only for Mercurial,
> +# modify the 'case' statement within this function.
> +edit() {
> +    case "${EDITOR}" in
> +        "")
> +            vi "$1" "$2"
> +            ;;
> +        emacs)
> +            emacs -nw "$1" "$2"
> +            ;;
>    

vi and emacs will now be called with an empty 2nd parameter in some
cases (such as "hg qref -e"). vi will fail and emacs will complain.

> +        gvim|vim)
> +            $EDITOR -f -o "$1" "$2"
> +            ;;
> +    esac
> +}
>    

The old behavior was that other values of $EDITOR could be used (such as
vi) - that should be preserved.

>   HGTMP=""
> @@ -45,9 +48,9 @@
>       MD5=$(which md5 2>/dev/null)
>   [ -x "${MD5}" ]&&  CHECKSUM=`${MD5} "$HGTMP/msg"`
>   if [ -s "$HGTMP/diff" ]; then
> -    $EDITOR "$HGTMP/msg" "$HGTMP/diff" || exit $?
> +    edit "$HGTMP/msg" "$HGTMP/diff" || exit $?
>   else
> -    $EDITOR "$HGTMP/msg" || exit $?
> +    edit "$HGTMP/msg" || exit $?
>   fi
>   [ -x "${MD5}" ]&&  (echo "$CHECKSUM" | ${MD5} -c>/dev/null 2>&1&&  exit 13)
>    

It seems like this refactoring isn't a good idea.

Perhaps there is no simple way to achieve what you want, so perhaps it
isn't a good idea to include it in Mercurial?

Or perhaps do it in a different hackish way: Define a "vim" function
which handles the second argument in this special way and calls out to
the binary.

/Mads
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1 of 2] Abstract the functionality of calling an editor into the 'edit' function to prevent

Benoit Boissinot
On Sun, Apr 4, 2010 at 12:03 AM, Mads Kiilerich <[hidden email]> wrote:

> Itamar Ravid wrote, On 04/03/2010 05:17 PM:
>>
>> # HG changeset patch
>> # User Itamar Ravid<[hidden email]>
>> # Date 1270307531 -10800
>> # Node ID 2272a05026eb11f2d52067606729df6d86f18627
>> # Parent  cd0c49bdbfd9edab18c3656d8a8a0bd27a9aa82a
>> Abstract the functionality of calling an editor into the 'edit' function
>> to prevent
>> users from having to mess with the code responsible for generating the
>> temporary
>> commit message and diff files.
>>
>
> I don't know where it is documented, but the first line of the commit
> message is special by convention supported by Mercurial. IIRC it should be a
> summary of the change, no more than 80 characters, and preferable prefixed
> with (in this case) "hgeditor:".
>
> [crew: Should the exact guideline (whatever it is) be added to
> ContributingChanges? (Perhaps together with some advice of content and
> language)]

I remember reading very good guidelines from Matt at some point,
explaining how to write a commit message in a meaningful way. Sadly I
can't find it (maybe it was on IRC?).

Benoit
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1 of 2] Abstract the functionality of calling an editor into the 'edit' function to prevent

Steve Borho
On Sat, Apr 3, 2010 at 4:33 PM, Benoit Boissinot <[hidden email]> wrote:

> On Sun, Apr 4, 2010 at 12:03 AM, Mads Kiilerich <[hidden email]> wrote:
>> Itamar Ravid wrote, On 04/03/2010 05:17 PM:
>>>
>>> # HG changeset patch
>>> # User Itamar Ravid<[hidden email]>
>>> # Date 1270307531 -10800
>>> # Node ID 2272a05026eb11f2d52067606729df6d86f18627
>>> # Parent  cd0c49bdbfd9edab18c3656d8a8a0bd27a9aa82a
>>> Abstract the functionality of calling an editor into the 'edit' function
>>> to prevent
>>> users from having to mess with the code responsible for generating the
>>> temporary
>>> commit message and diff files.
>>>
>>
>> I don't know where it is documented, but the first line of the commit
>> message is special by convention supported by Mercurial. IIRC it should be a
>> summary of the change, no more than 80 characters, and preferable prefixed
>> with (in this case) "hgeditor:".
>>
>> [crew: Should the exact guideline (whatever it is) be added to
>> ContributingChanges? (Perhaps together with some advice of content and
>> language)]
>
> I remember reading very good guidelines from Matt at some point,
> explaining how to write a commit message in a meaningful way. Sadly I
> can't find it (maybe it was on IRC?).

The TortoiseHg developer wiki [1] has a nice link back to the
Mercurial Wiki [2].

1 - http://bitbucket.org/tortoisehg/stable/wiki/developers/contributing
2 - http://www.selenic.com/mercurial/wiki/index.cgi/SuccessfulPatch

Though the hg wiki page doesn't describe the commit message conventions.

--
Steve Borho
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1 of 2] Abstract the functionality of calling an editor into the 'edit' function to prevent

Itamar Ravid-3
In reply to this post by Mads Kiilerich
On Sun, Apr 4, 2010 at 1:03 AM, Mads Kiilerich <[hidden email]> wrote:
Itamar Ravid wrote, On 04/03/2010 05:17 PM:

# HG changeset patch
# User Itamar Ravid<[hidden email]>
# Date 1270307531 -10800
# Node ID 2272a05026eb11f2d52067606729df6d86f18627
# Parent  cd0c49bdbfd9edab18c3656d8a8a0bd27a9aa82a
Abstract the functionality of calling an editor into the 'edit' function to prevent
users from having to mess with the code responsible for generating the temporary
commit message and diff files.
 

I don't know where it is documented, but the first line of the commit message is special by convention supported by Mercurial. IIRC it should be a summary of the change, no more than 80 characters, and preferable prefixed with (in this case) "hgeditor:".

[crew: Should the exact guideline (whatever it is) be added to ContributingChanges? (Perhaps together with some advice of content and language)]


diff -r cd0c49bdbfd9 -r 2272a05026eb hgeditor
--- a/hgeditor  Thu Apr 01 17:51:59 2010 -0500
+++ b/hgeditor  Sat Apr 03 18:12:11 2010 +0300
@@ -3,19 +3,22 @@
 # This is an example of using HGEDITOR to create of diff to review the
 # changes while commiting.

-# If you want to pass your favourite editor some other parameters
-# only for Mercurial, modify this:
-case "${EDITOR}" in
-    "")
-        EDITOR="vi"
-        ;;
-    emacs)
-        EDITOR="$EDITOR -nw"
-        ;;
-    gvim|vim)
-        EDITOR="$EDITOR -f -o"
-        ;;
-esac
+# Edit a file, optionally opening another one as reference within the editor.
+# If you want to pass your favourite editor some other parameters only for Mercurial,
+# modify the 'case' statement within this function.
+edit() {
+    case "${EDITOR}" in
+        "")
+            vi "$1" "$2"
+            ;;
+        emacs)
+            emacs -nw "$1" "$2"
+            ;;
 

vi and emacs will now be called with an empty 2nd parameter in some cases (such as "hg qref -e"). vi will fail and emacs will complain. 
The old behavior was that other values of $EDITOR could be used (such as vi) - that should be preserved.


That's true - I've overlooked those cases :-) Perhaps something like the suggestion below could be better?
 

 HGTMP=""
@@ -45,9 +48,9 @@
     MD5=$(which md5 2>/dev/null)
 [ -x "${MD5}" ]&&  CHECKSUM=`${MD5} "$HGTMP/msg"`
 if [ -s "$HGTMP/diff" ]; then
-    $EDITOR "$HGTMP/msg" "$HGTMP/diff" || exit $?
+    edit "$HGTMP/msg" "$HGTMP/diff" || exit $?
 else
-    $EDITOR "$HGTMP/msg" || exit $?
+    edit "$HGTMP/msg" || exit $?
 fi
 [ -x "${MD5}" ]&&  (echo "$CHECKSUM" | ${MD5} -c>/dev/null 2>&1&&  exit 13)
 

It seems like this refactoring isn't a good idea.

Perhaps there is no simple way to achieve what you want, so perhaps it isn't a good idea to include it in Mercurial?

Or perhaps do it in a different hackish way: Define a "vim" function which handles the second argument in this special way and calls out to the binary.

/Mads

edit() {
    case "${EDITOR}" in
        "")
            EDITOR="vi"
            ;;
        emacs)
            EDITOR="$EDITOR -nw"
            ;;
        gvim|vim)
            # Note special case when opening two files below
            EDITOR="$EDITOR"
            ;;
    esac

    if [ -z "$2" ]; then
        "$EDITOR" "$1"
    else
        if [ $EDITOR = "vim" -o $EDITOR = "gvim" ]; then
            # Handle irregular arg-ordering when calling g/vim
            "$EDITOR" "+e $2" "+set buftype=help" "+split $1"
        else
            "$EDITOR" "$1" "$2"
        fi
    fi
}
 
This, I believe, handles the problems discussed while still containing the edit logic within the function. What do you think?

Regarding the commit message convention, I'll resubmit the patchbomb with a proper one once we iron out the code issues.

_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1 of 2] Abstract the functionality of calling an editor into the 'edit' function to prevent

Mads Kiilerich
Itamar Ravid wrote, On 04/04/2010 01:07 PM:

> edit() {
>     case "${EDITOR}" in
>         "")
>             EDITOR="vi"
>             ;;
>         emacs)
>             EDITOR="$EDITOR -nw"
>             ;;
>         gvim|vim)
>             # Note special case when opening two files below
>             EDITOR="$EDITOR"

why?

>             ;;
>     esac
>
>     if [ -z "$2" ]; then
>         "$EDITOR" "$1"

AFAICS you haven't tested this (and the following) with "emacs -nw"?
Here we want $EDITOR to expand to a command with some arguments, so it
shouldn't be quoted.

>     else
>         if [ $EDITOR = "vim" -o $EDITOR = "gvim" ]; then
>             # Handle irregular arg-ordering when calling g/vim
>             "$EDITOR" "+e $2" "+set buftype=help" "+split $1"
>         else
>             "$EDITOR" "$1" "$2"
>         fi
>     fi
> }
> This, I believe, handles the problems discussed while still containing
> the edit logic within the function. What do you think?

I think that this is a nice-to-have, but also that it complicates the
code and makes it harder for the next guy to customize the code to fit
his need. The more I look at the code the more I think the cost in
increased complexity is too high.

Anyway, why not do something like this:

--- a/hgeditor
+++ b/hgeditor
@@ -12,11 +12,15 @@
      emacs)
          EDITOR="$EDITOR -nw"
          ;;
-    gvim|vim)
-        EDITOR="$EDITOR -f -o"
-        ;;
  esac

+vim() {
+    if [ "$2" ]; then
+        "$(which vim)" "+e $2" "+set buftype=help" "+split $1"
+    else
+        "$(which vim)" -f -o "$1"
+    fi
+}

  HGTMP=""
  cleanup_exit() {


/Mads
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1 of 2] Abstract the functionality of calling an editor into the 'edit' function to prevent

Itamar Ravid-3
On Mon, Apr 5, 2010 at 1:07 AM, Mads Kiilerich <[hidden email]> wrote:
Itamar Ravid wrote, On 04/04/2010 01:07 PM:

edit() {
   case "${EDITOR}" in
       "")
           EDITOR="vi"
           ;;
       emacs)
           EDITOR="$EDITOR -nw"
           ;;
       gvim|vim)
           # Note special case when opening two files below
           EDITOR="$EDITOR"

why?


           ;;
   esac

   if [ -z "$2" ]; then
       "$EDITOR" "$1"

AFAICS you haven't tested this (and the following) with "emacs -nw"? Here we want $EDITOR to expand to a command with some arguments, so it shouldn't be quoted.

Yes, the emacs has not been tested, but I am running with the version I submitted as my hgeditor :) I don't have emacs installed, so I trust codereview and other testing to catch these errors...

   else
       if [ $EDITOR = "vim" -o $EDITOR = "gvim" ]; then
           # Handle irregular arg-ordering when calling g/vim
           "$EDITOR" "+e $2" "+set buftype=help" "+split $1"
       else
           "$EDITOR" "$1" "$2"
       fi
   fi
}
This, I believe, handles the problems discussed while still containing the edit logic within the function. What do you think?

I think that this is a nice-to-have, but also that it complicates the code and makes it harder for the next guy to customize the code to fit his need. The more I look at the code the more I think the cost in increased complexity is too high.

Anyway, why not do something like this:

--- a/hgeditor
+++ b/hgeditor
@@ -12,11 +12,15 @@

    emacs)
        EDITOR="$EDITOR -nw"
        ;;
-    gvim|vim)
-        EDITOR="$EDITOR -f -o"
-        ;;
 esac

+vim() {
+    if [ "$2" ]; then
+        "$(which vim)" "+e $2" "+set buftype=help" "+split $1"
+    else
+        "$(which vim)" -f -o "$1"
+    fi
+}

 HGTMP=""
 cleanup_exit() {


Nice! This is elegant and fine by me - as long as we get the functionality in :) I do tend to think that trapping the areas other customizers need to touch within a single function is preferable, but this does seem less complex.

Should I submit another patch or will you push this change?

/Mads


_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1 of 2] Abstract the functionality of calling an editor into the 'edit' function to prevent

Mads Kiilerich
Itamar Ravid wrote, On 04/05/2010 01:06 AM:

> On Mon, Apr 5, 2010 at 1:07 AM, Mads Kiilerich <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     I think that this is a nice-to-have, but also that it complicates
>     the code and makes it harder for the next guy to customize the
>     code to fit his need. The more I look at the code the more I think
>     the cost in increased complexity is too high.
>
>     Anyway, why not do something like this:
>
>     --- a/hgeditor
>     +++ b/hgeditor
>     @@ -12,11 +12,15 @@
>
>         emacs)
>             EDITOR="$EDITOR -nw"
>             ;;
>     -    gvim|vim)
>     -        EDITOR="$EDITOR -f -o"
>     -        ;;
>      esac
>
>     +vim() {
>     +    if [ "$2" ]; then
>     +        "$(which vim)" "+e $2" "+set buftype=help" "+split $1"
>     +    else
>     +        "$(which vim)" -f -o "$1"
>     +    fi
>     +}
>
>      HGTMP=""
>      cleanup_exit() {
>
>
> Nice! This is elegant and fine by me - as long as we get the
> functionality in :) I do tend to think that trapping the areas other
> customizers need to touch within a single function is preferable, but
> this does seem less complex.
>
> Should I submit another patch or will you push this change?

I'm not convinced this change is a good idea at all, so please take what
you can use and improve on it and advocate it ;-)

(Perhaps it would be prettier if the function was called something like
vimwrapperfunction and the gvim|vim case changed EDITOR to that. And we
need gvim handling as well. And the -f -o options should considered. Are
they needed now, why, and why not in the two-file-case?)

/Mads
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1 of 2] Abstract the functionality of calling an editor into the 'edit' function to prevent

Itamar Ravid-3
On Mon, Apr 5, 2010 at 2:21 AM, Mads Kiilerich <[hidden email]> wrote:
Itamar Ravid wrote, On 04/05/2010 01:06 AM:

On Mon, Apr 5, 2010 at 1:07 AM, Mads Kiilerich <[hidden email] <mailto:[hidden email]>> wrote:

   I think that this is a nice-to-have, but also that it complicates
   the code and makes it harder for the next guy to customize the
   code to fit his need. The more I look at the code the more I think
   the cost in increased complexity is too high.

   Anyway, why not do something like this:

   --- a/hgeditor
   +++ b/hgeditor
   @@ -12,11 +12,15 @@

       emacs)
           EDITOR="$EDITOR -nw"
           ;;
   -    gvim|vim)
   -        EDITOR="$EDITOR -f -o"
   -        ;;
    esac

   +vim() {
   +    if [ "$2" ]; then
   +        "$(which vim)" "+e $2" "+set buftype=help" "+split $1"
   +    else
   +        "$(which vim)" -f -o "$1"
   +    fi
   +}

    HGTMP=""
    cleanup_exit() {


Nice! This is elegant and fine by me - as long as we get the functionality in :) I do tend to think that trapping the areas other customizers need to touch within a single function is preferable, but this does seem less complex.

Should I submit another patch or will you push this change?

I'm not convinced this change is a good idea at all, so please take what you can use and improve on it and advocate it ;-)

Well, using your version of the change impacts the code rather minimally, and I can attest (as a sworn vim user... ;) that I wouldn't be able to use hgeditor without this feature.
 
(Perhaps it would be prettier if the function was called something like vimwrapperfunction and the gvim|vim case changed EDITOR to that. And we need gvim handling as well. And the -f -o options should considered. Are they needed now, why, and why not in the two-file-case?)

gvim handling, afaik, would be handled cleanly with the same arguments as vim, so yes - setting EDITOR to the wrapper func in the gvim|vim case would be best. The -f option prevents gvim from forking, so it is needed; -o instructs g/vim to open stacked windows for the files given. It's harmless since we're giving it one file, but could be dropped. 
/Mads


_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial