Re: Shorter/customized group names?

[David Abrahams <dave@boostpro.com>]

on Fri May 29 2009, David Engster <deng-AT-randomsample.de> wrote:

> David Abrahams <dave@boostpro.com> writes:
>> This is pretty cool, but it's also got a few problems.  It relies on
>> implementation details of Gnus like the order in which groups get
>> formatted, that Gnus always formats *all* the groups (it doesn't) and on
>> some secret variables.
>
> It's a hack, for sure. Maybe the reason it works pretty well for me is
> because I'm using topic mode?

I'm using topic mode too.

> Regarding the gnus-tmp- variables, I'd say those are unlikely to change
> in the future, but they should surely be made "official". The doc-string
> for gnus-group-line-format says for '%u'
>
> ,----
> | The function will be passed a single dummy parameter as argument.  The
> | function should return a string, which will be inserted into the
> | buffer just like information from any other group specifier.
> `----
>
> In the current form, this doesn't make sense, since it is not said how
> to obtain the group name and the corresponding method which should be
> inserted into the buffer.

Does that need to be reported as a bug?

>>  Also, I'm not sure what resets DE-format-previous-regexp back to nil
>> other than encountering a non-nntp group.  
>
> Exactly that.
>
>> Since I'd like this to work for non-nntp groups too, I don't think
>> that trick is going to work for me.
>
> I only have nntp groups which are separated by dots, so I tailored it to
> nntp only.
>
>> Here's what I've got so far as a tweak to the above, but since it relies
>> on the same assumptions, it doesn't quite work as well as it should.
>> This seems like the sort of thing for which we would need explicit
>> support from Gnus if it's not going to break with each release. 
>
> Yes, maybe this jusn't isn't possibly to do reliably at the moment. I'd
> have to look in gnus-group.el in how Gnus builds the Group buffer in
> detail.
>
> [... snipped your version ...]
>
> Could you give an example how this code fails for you in certain
> situations?

Here's my current *Group* buffer.  Note that gmane.comp.lib.boost.user
is reported as being gmane.os.lib.boost.user and
gmane.comp.file-systems.tahoe.announce has the same problem

[ Gnus -- 360190 ]
     391 | 1watch.committee
       2 | 0unsure
      17 |*INBOX
  [ Active -- 152317 ]
     152304 |*  .  .lib.boost.devel
         9 |   .os.solaris.opensolaris.indiana
         2 |*gmane.emacs.gnus.general
         2 |   .os.solaris.opensolaris.xen
  [ Occasional -- 49166 ]
     48143 |   .  .lib.boost.user
         2 |   .  .file-systems.tahoe.announce
      1021 |   .  .  .  .devel
  [ misc -- 158297 ]
       233 |   .  .lib.boost.announce
      3251 |   .  .  .  .asio.user
     20904 |   .  .  .  .build
       501 |   .  .  .  .cmake
      9071 |   .  .  .  .cvs
      3790 |   .  .  .  .documentation
        65 |   .  .  .  .interest
       152 |   .  .  .  .jam
       896 |   .  .  .  .langbinding
      6357 |   .  .  .  .testing
       383 |   .  .  .  .threads.devel
      5022 |   .  .  .  .ublas
     12231 |   .emacs.gnus.user
     95441 |   .comp.python.devel

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com