Shorter/customized group names?

Shorter/customized group names?

[David Abrahams]

Right now, my *Group* buffer looks like this:

[ Gnus -- 336279 ]
     370 | 1watch.committee
       4 | 0unsure
      12 | INBOX
  [ Active -- 160236 ]...
     152186 | nntp+news.gmane.org:gmane.comp.lib.boost.devel
      3787 | nntp+news.bytemine.net:comp.lang.c++.moderated
        10 | nntp+news.gmane.org:gmane.os.solaris.opensolaris.indiana
      4253 | nntp+news.gmane.org:gmane.os.solaris.opensolaris.xen
  [ misc -- 175657 ]
       233 | nntp+news.gmane.org:gmane.comp.lib.boost.announce
      3251 | nntp+news.gmane.org:gmane.comp.lib.boost.asio.user
     20879 | nntp+news.gmane.org:gmane.comp.lib.boost.build
       498 | nntp+news.gmane.org:gmane.comp.lib.boost.cmake
      9071 | nntp+news.gmane.org:gmane.comp.lib.boost.cvs
      3788 | nntp+news.gmane.org:gmane.comp.lib.boost.documentation
        65 | nntp+news.gmane.org:gmane.comp.lib.boost.interest
       152 | nntp+news.gmane.org:gmane.comp.lib.boost.jam
       890 | nntp+news.gmane.org:gmane.comp.lib.boost.langbinding
      6353 | nntp+news.gmane.org:gmane.comp.lib.boost.testing
       383 | nntp+news.gmane.org:gmane.comp.lib.boost.threads.devel
      5016 | nntp+news.gmane.org:gmane.comp.lib.boost.ublas
     64779 |*nntp+news.gmane.org:gmane.emacs.gnus.general
     12216 | nntp+news.gmane.org:gmane.emacs.gnus.user
     48083 | nntp+news.gmane.org:gmane.comp.lib.boost.user

Is there anything I can do to clean that up and make it easier to find
what I'm looking for?

Many thanks in advance,

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

Re: Shorter/customized group names?

[David Engster]

David Abrahams <dave@boostpro.com> writes:
> Right now, my *Group* buffer looks like this:
[...]
>      48083 | nntp+news.gmane.org:gmane.comp.lib.boost.user

> Is there anything I can do to clean that up and make it easier to find
> what I'm looking for?

Just a guess, but using %G instead of %g in gnus-group-line-format will
probably do what you want.

-David

Re: Shorter/customized group names?

[David Abrahams]

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

> David Abrahams <dave@boostpro.com> writes:
>> Right now, my *Group* buffer looks like this:
> [...]
>>      48083 | nntp+news.gmane.org:gmane.comp.lib.boost.user
>
>> Is there anything I can do to clean that up and make it easier to find
>> what I'm looking for?
>
> Just a guess, but using %G instead of %g in gnus-group-line-format will
> probably do what you want.

Well, thanks; it's definitely a start.  I'd like to do better, though. I
guess I can use a ~(...) clause and hand-code it, but I think there are
some things I wouldn't be able to do very easily that way.  For example,
I'm currently seeing:

       233 | gmane.comp.lib.boost.announce
      3251 | gmane.comp.lib.boost.asio.user
     20879 | gmane.comp.lib.boost.build
       498 | gmane.comp.lib.boost.cmake
      3788 | gmane.comp.lib.boost.documentation
        65 | gmane.comp.lib.boost.interest
       152 | gmane.comp.lib.boost.jam
       891 | gmane.comp.lib.boost.langbinding
      6353 | gmane.comp.lib.boost.testing
       383 | gmane.comp.lib.boost.threads.devel
      5016 | gmane.comp.lib.boost.ublas

which could be made as simple as:

       233 | gmane.comp.lib.boost.announce
      3251 |  .boost.asio.user
     20879 |  .boost.build
       498 |  .boost.cmake
      3788 |  .boost.documentation
        65 |  .boost.interest
       152 |  .boost.jam
       891 |  .boost.langbinding
      6353 |  .boost.testing
       383 |  .boost.threads.devel
      5016 |  .boost.ublas


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

Re: Shorter/customized group names?

[David Engster]

David Abrahams <dave@boostpro.com> writes:
> on Wed May 27 2009, David Engster <deng-AT-randomsample.de> wrote:
>> Just a guess, but using %G instead of %g in gnus-group-line-format will
>> probably do what you want.
>
> Well, thanks; it's definitely a start.  I'd like to do better,
> though. I guess I can use a ~(...) clause and hand-code it, but I
> think there are some things I wouldn't be able to do very easily that
> way.  For example, I'm currently seeing:
>
>        233 | gmane.comp.lib.boost.announce
>       3251 | gmane.comp.lib.boost.asio.user

[...]

> which could be made as simple as:
>
>        233 | gmane.comp.lib.boost.announce
>       3251 |  .boost.asio.user

[...]

Well, there's still the possibility to use collapsed group names (see %c
in gnus-group-line-format), but I never used that because then *all*
groups are collapsed; I like your idea much better. You can do that by
using a user-defined function. Put the following into your .gnus:

(defvar DE-format-previous-regexp nil)
(defvar DE-format-collapse-level 2)

(defun gnus-user-format-function-A (arg)
  (let ((group gnus-tmp-qualified-group))
    (if (eq (car gnus-tmp-method) 'nntp)
	(if (and DE-format-previous-regexp
		 (string-match DE-format-previous-regexp group))
	    (concat " ." (match-string 1 group))
	  (setq DE-format-previous-regexp 
		(if (string-match (format "\\(\\([a-z]+\\.\\)\\{%d\\}\\).+"
					  DE-format-collapse-level)
				  group)
		    (concat (regexp-quote (match-string 1 group))
			    "\\(.+\\)")
		  nil))
	  group)
      (setq DE-format-previous-regexp nil)
      group)))


Now just use %uA instead of %G in gnus-group-line-format. You probably
want to use a collapse level of "3" for your example above. Beware that
this may be buggy, but it works for me so far.

Regards,
David

Re: Shorter/customized group names?

[David Abrahams]

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

> David Abrahams <dave@boostpro.com> writes:
>> on Wed May 27 2009, David Engster <deng-AT-randomsample.de> wrote:
>>> Just a guess, but using %G instead of %g in gnus-group-line-format will
>>> probably do what you want.
>>
>> Well, thanks; it's definitely a start.  I'd like to do better,
>> though. I guess I can use a ~(...) clause and hand-code it, but I
>> think there are some things I wouldn't be able to do very easily that
>> way.  For example, I'm currently seeing:
>>
>>        233 | gmane.comp.lib.boost.announce
>>       3251 | gmane.comp.lib.boost.asio.user
>
> [...]
>
>> which could be made as simple as:
>>
>>        233 | gmane.comp.lib.boost.announce
>>       3251 |  .boost.asio.user
>
> [...]
>
> Well, there's still the possibility to use collapsed group names (see %c
> in gnus-group-line-format), but I never used that because then *all*
> groups are collapsed; I like your idea much better. You can do that by
> using a user-defined function. Put the following into your .gnus:
>
> (defvar DE-format-previous-regexp nil)
> (defvar DE-format-collapse-level 2)
>
> (defun gnus-user-format-function-A (arg)
>   (let ((group gnus-tmp-qualified-group))
>     (if (eq (car gnus-tmp-method) 'nntp)
> 	(if (and DE-format-previous-regexp
> 		 (string-match DE-format-previous-regexp group))
> 	    (concat " ." (match-string 1 group))
> 	  (setq DE-format-previous-regexp 
> 		(if (string-match (format "\\(\\([a-z]+\\.\\)\\{%d\\}\\).+"
> 					  DE-format-collapse-level)
> 				  group)
> 		    (concat (regexp-quote (match-string 1 group))
> 			    "\\(.+\\)")
> 		  nil))
> 	  group)
>       (setq DE-format-previous-regexp nil)
>       group)))
>
>
> Now just use %uA instead of %G in gnus-group-line-format. You probably
> want to use a collapse level of "3" for your example above. Beware that
> this may be buggy, but it works for me so far.

Hey, thanks!  

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.  Also, I'm not sure what resets
DE-format-previous-regexp back to nil other than encountering a non-nntp
group.  Since I'd like this to work for non-nntp groups too, I don't
think that trick is going to work for me.

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.  Or am I
missing something?

(require 'cl-seq)
(defvar DE-format-previous-group-name nil)

(defun gnus-user-format-function-A (arg)
  (let* ((current-group gnus-tmp-qualified-group)
         (common-prefix (substring current-group 0 (mismatch DE-format-previous-group-name current-group)))
         (common-dot-count (count ?. common-prefix))
         (prefix (mapconcat (lambda (x) x) (make-list common-dot-count "  .") ""))
         (suffix 
          (and (string-match
                      (format "\\([^.]*[.]\\)\\{%d\\}\\(.+\\)" common-dot-count) current-group)
               (match-string 2 current-group)))
         )
    (setq DE-format-previous-group-name current-group)
    (concat prefix suffix)))


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

Re: Shorter/customized group names?

[David Engster]

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?

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.

>  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?

-David

Re: Shorter/customized group names?

[David Abrahams]

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

Re: Shorter/customized group names?

[David Abrahams]

on Fri May 29 2009, David Abrahams <dave-AT-boostpro.com> wrote:

> 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.

A possibly-less-hacky approach might be to "after" advise the functions
that operate on the *Group* buffer to postprocess those strings.  Still,
I really think this (or the tools to support it) should be a built-in
feature.

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

Re: Shorter/customized group names?

[David Engster]

David Abrahams <dave@boostpro.com> writes:
> on Fri May 29 2009, David Abrahams <dave-AT-boostpro.com> wrote:
>
>> 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.
>
> A possibly-less-hacky approach might be to "after" advise the functions
> that operate on the *Group* buffer to postprocess those strings.  Still,
> I really think this (or the tools to support it) should be a built-in
> feature.

I couldn't exactly reproduce the problems you had, but I also noticed
some inconsistencies when the Group buffer is rebuild only partially
(e.g. when opening a topic). I agree that doing this as a postprocess is
the best way to go about this. Since there are more than enough hooks we
don't even need to advise anything. :-)

So here's yet another version, based on your already modified one. It
also uses an internal feature: the complete group name is saved in the
text properties at the beginning of each group line. Since many internal
Gnus functions use these, this isn't likely to change.

--8<---------------cut here---------------start------------->8---
(defun DE-collapse-group-names ()
  (save-excursion
    (let (previous-group current-group common-prefix
			 common-dot-count prefix suffix)
      (goto-char (point-min))
      (while (not (eobp))
	(when (setq current-group 
		    (get-text-property (point) 'gnus-group))
	  (setq current-group (symbol-name current-group))
	  (when (string-match "\\(.+\\):\\(.+\\)" current-group)
	    (setq current-group (match-string 2 current-group)))
	  (setq common-prefix (substring current-group 0 
					 (mismatch previous-group current-group))
		common-dot-count (count ?. common-prefix)
		prefix (mapconcat (lambda (x) x) 
				  (make-list common-dot-count "  .") "")
		suffix (and (string-match
			     (format "\\([^.]*[.]\\)\\{%d\\}\\(.+\\)" common-dot-count) 
			     current-group)
			    (match-string 2 current-group))
		previous-group current-group)
	  (unless (zerop (length prefix))
	    (when (search-forward current-group (point-at-eol) t)
	      (let ((props (text-properties-at (1- (point)))))
		(replace-match (apply 'propertize (concat prefix suffix)
				      props))))))
	(forward-line 1)))))

(add-hook 'gnus-group-prepare-hook 'DE-collapse-group-names)
(add-hook 'gnus-group-update-group-hook 'DE-collapse-group-names)
--8<---------------cut here---------------end--------------->8---

This code assumes that you use "%G" in your group line format.

I think you can even omit the last hook if you don't use a three pane
buffer configuration.

-David

Re: Shorter/customized group names?

[David Abrahams]

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

> So here's yet another version, based on your already modified one. It
> also uses an internal feature: the complete group name is saved in the
> text properties at the beginning of each group line. Since many internal
> Gnus functions use these, this isn't likely to change.
>
> (defun DE-collapse-group-names ()
>   (save-excursion
>     (let (previous-group current-group common-prefix
> 			 common-dot-count prefix suffix)
>       (goto-char (point-min))
>       (while (not (eobp))
> 	(when (setq current-group 
> 		    (get-text-property (point) 'gnus-group))
> 	  (setq current-group (symbol-name current-group))
> 	  (when (string-match "\\(.+\\):\\(.+\\)" current-group)
> 	    (setq current-group (match-string 2 current-group)))
> 	  (setq common-prefix (substring current-group 0 
> 					 (mismatch previous-group current-group))
> 		common-dot-count (count ?. common-prefix)
> 		prefix (mapconcat (lambda (x) x) 
> 				  (make-list common-dot-count "  .") "")
> 		suffix (and (string-match
> 			     (format "\\([^.]*[.]\\)\\{%d\\}\\(.+\\)" common-dot-count) 
> 			     current-group)
> 			    (match-string 2 current-group))
> 		previous-group current-group)
> 	  (unless (zerop (length prefix))
> 	    (when (search-forward current-group (point-at-eol) t)
> 	      (let ((props (text-properties-at (1- (point)))))
> 		(replace-match (apply 'propertize (concat prefix suffix)
> 				      props))))))
> 	(forward-line 1)))))
>
> (add-hook 'gnus-group-prepare-hook 'DE-collapse-group-names)
> (add-hook 'gnus-group-update-group-hook 'DE-collapse-group-names)
>
> This code assumes that you use "%G" in your group line format.
>
> I think you can even omit the last hook if you don't use a three pane
> buffer configuration.

Ah, but I do!  But this is fantastic; it really works.  Thank you for
all your help on this one!

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

Re: Shorter/customized group names?

[Ted Zlatanov]

On Thu, 28 May 2009 00:42:57 -0400 David Abrahams <dave@boostpro.com> wrote: 

DA>        233 | gmane.comp.lib.boost.announce
DA>       3251 |  .boost.asio.user
DA>      20879 |  .boost.build
DA>        498 |  .boost.cmake
DA>       3788 |  .boost.documentation
DA>         65 |  .boost.interest
DA>        152 |  .boost.jam
DA>        891 |  .boost.langbinding
DA>       6353 |  .boost.testing
DA>        383 |  .boost.threads.devel
DA>       5016 |  .boost.ublas

I think color would be a nice alternative to this sort of string
manipulation.  Maybe a version of %G that gives the group prefix a
dimmer color would be nice?  I don't think anything like that exists
now.

Ted