"hg log --style=changelog" has a couple of features I miss in "darcs
changes", listed below.  The first I care about, the other is listed
more incidentally.

If a sequence of patches have the same author and day (date), they are
listed under a single author/date timestamp.  For example,

  Mon Jun 16 14:11:21 EST 2008  Trent W. Buck <trentbuck@gmail.com>
    * Add clarifications from meeting.

  Mon Jun 16 12:28:09 EST 2008  Trent W. Buck <trentbuck@gmail.com>
    * Generate ODF; use more quotes.

  Mon Jun 16 12:27:51 EST 2008  Trent W. Buck <trentbuck@gmail.com>
    * Simple gmake interface to Build.sh and Clean.sh.

simplifies to

  2008-06-16  Trent W. Buck  <trentbuck@gmail.com>

    * Add clarifications from meeting.

    * Generate ODF; use more quotes.

    * Simple gmake interface to Build.sh and Clean.sh.

Emacs' change-log-mode marks up this date/user header correctly,
unlike the current darcs changes output.

Secondly, it automatically adds "changed file" leaders.  For example,
instead of

  * Generate ODF; use more quotes.

it prints (approximately)

  * Build.sh, Clean.sh: Generate ODF; use more quotes.

This latter feature is FAR LESS important to me than the former,
because "darcs changes --summary" is more informative and more
readable in a generic pager.  However, Emacs' change-log-mode
understands the file links in the "hg log --style=changelog", but not
in "darcs changes --summary".

Another feature that might be nice is to automatically list, in
standard notation, the changed procedures / sections (detected by a
heuristic similar to GNU diff -p).  That is, instead of

  * Simple gmake interface to Build.sh and Clean.sh.

it might print

  * GNUmakefile (all, clean, distclean): Simple gmake interface to
    Build.sh and Clean.sh.

this might be a bad idea, because the heuristic is bound to get things
wrong.  In any case AFAIK the point is moot with the current patch
format, since it doesn't contain the right information.

Finally, I anticipate that people will complain their scripts parse
the output of "darcs changes" and they don't want to update them to
accommodate "gratuitous" changes.  My response is the hard line that
those scripts should probably be parsing the output of --xml, since
the default format is for *humans*.

2008-06-16  Trent W. Buck  <trentbuck@gmail.com>

    * Add clarifications from meeting.

    * Generate ODF; use more quotes.

    * Simple gmake interface to Build.sh and Clean.sh.

Hmm... and what should we do about long comments?

On Mon, Jun 16, 2008 at 11:55:25AM -0000, Eric Kow wrote:
> Hmm... and what should we do about long comments?

I haven't really thought about it, but I imagined they'd just be
printed beneath the patch name, basically as they are now.  E.g.

2008-06-16  Trent W. Buck  <trentbuck@gmail.com>

	* bookmark.el: Give a better name to part of the bookmark interface.

	This was originally a much larger change, but halfway through I
	updated and discovered that Stefan Monnier had done the rest.
	It looks like he anticipated the new name too, because he used
	`the-record' instead of `the-cell' for some internal variable names.

This will obviously screw up people who use asterisks in the long
description, so perhaps they should be further indented by about two
spaces.

	* bookmark.el: Give a better name to part of the bookmark interface.

	  This was originally a much larger change, but halfway through I
	  updated and discovered that Stefan Monnier had done the rest.
	  It looks like he anticipated the new name too, because he used
	  `the-record' instead of `the-cell' for some internal variable names.

Oops, I forgot to include a URL to the GNU coding standards.

  http://www.gnu.org/prep/standards/standards.html.gz#Change-Logs

I also notice, from looking at GNU Emacs changelogs, that the
changelog comments are indented with a single literal tab, rather than
some spaces.

Also, is this request primarily motivated by compatibility with Emacs
change-log-mode (as opposed to more general UI issues)?  

If so, would it be reasonable to suggest instead that a clever piece of Elisp be
written to parse the darcs changes --xml output and make it emacs-friendlier?

With a bit of googling, I notice that there is this thing called darcsum, though
I'm not sure what it does: http://chneukirchen.org/repos/darcsum/darcsum.el

On Mon, Jun 16, 2008 at 12:20:44PM -0000, Eric Kow wrote:
> Eric Kow <eric.kow@gmail.com> added the comment:
> 
> Also, is this request primarily motivated by compatibility with Emacs
> change-log-mode (as opposed to more general UI issues)?  

Not for the first point; I think it makes the output more readable,
and its more in line with GNU standards (which are popular outside of
GNU, too).

> With a bit of googling, I notice that there is this thing called darcsum, though
> I'm not sure what it does: http://chneukirchen.org/repos/darcsum/darcsum.el

It is an interface for darcs record, and it's broken for darcs-2.

I was resisting triaging this bug out of my usual conservatism and fear of
increasing feature set.

I think the best is just to submit a patch for changes (no new flag) to
implement the behaviour where "[i]f a sequence of patches have the same author
and day (date), they are listed under a single author/date timestamp."

I wouldn't worry about the date format; that's issue140.
I also would just make this *the* behaviour rather than trying to make it
parameterisable.

Darcs-users can argue about this once the patch is available.

On Sun, Aug 23, 2009 at 01:16:35PM +0000, Eric Kow wrote:
> I think the best is just to submit a patch for changes (no new flag)
> to implement the behaviour where "[i]f a sequence of patches have
> the same author and day (date), they are listed under a single
> author/date timestamp."

We already have TWO flags for to control style: --xml-output and
--human-readable.

> I also would just make this *the* behaviour rather than trying to
> make it parameterisable.

I have no problem with that.  I didn't propose it because I expected
resistance.

Maintaining the changelog is miserable manual work and we simply don't 
have the man power to conform to any de-facto standards here.