GNU bug report logs - #5135
[PATCH] rcirc: Option to sort NAMES listing

Previous Next

Full log

Message #19 received at 5135 <at> debbugs.gnu.org (full text, mbox):

From: Deniz Dogan <deniz.a.m.dogan <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 5135 <at> debbugs.gnu.org, Ryan Yeske <rcyeske <at> gmail.com>
Subject: Re: [gnu.org #565169] Deniz Dogan EMACS Assignment
Date: Thu, 3 Jun 2010 17:53:43 +0200

2010/6/3 Chong Yidong <cyd <at> stupidchicken.com>:
> Deniz Dogan <deniz.a.m.dogan <at> gmail.com> writes:
>
>> This patch adds the user option to sort nickname listings in the way
>> that many other IRC clients sort them.
>>
>> Details:
>> * Added rcirc-nickname<, a function which acts like string< but for
>> IRC nicknames, making  <at>  less than + and comparing case-insensitively.
>> * Added rcirc-sort-nicknames-join, a function which takes a string of
>> IRC nicknames and a separator, sorts the nicknames and returns the
>> result.
>> * Added rcirc-sort-nicknames, a customizable variable which when
>> non-nil will make rcirc sort any NAMES responses. nil by default.
>> * Changed rcirc-handler-366 (RPL_ENDOFNAMES) to respect rcirc-sort-nicknames.
>
> If most IRC clients sort nicknames this way, it may not be necessary to
> create a new option `rcirc-sort-nicknames'.  We should just perform the
> sorting automatically.  What do you think?  (I don't know enough about
> "typical" IRC behavior to say).
>

I'm all for making this option the default - I see no reason why
people would not want to sort the nicknames. Pretty much every IRC
client used today sorts the nicknames like this. I just figured maybe
some people get annoyed by the (almost infinitely small) overhead it
takes to perform the actual sorting. rcirc users like to keep it
minimalistic I have found.

> Also, your docstrings need work.  Please read the Documentation node in
> the Elisp manual:
>
>     When you write a documentation string, make the first line a
>     complete sentence (or two complete sentences) since some
>     commands, such as `apropos', show only the first line of a
>     multi-line documentation string.
>

Sorry about that, I will take that part of the manual into account in
any future patches.

By the way, it seems Stefan already applied this patch, so I don't
know where to go from here...

Cheers,
Deniz

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.