GNUS hide group from *Group* buffer when there no unread messages...

[Oleksandr Gavenko]

If I want to post to some group I firstly enter to it and press 'a' in
*Summary* buffer. Why? Just because I simple don't remember full group names.
Only some part of names which I look by C-s in *Group* buffer until not find
desired group...

But GNUS hide groups from *Group* buffer when there no unread messages...

After reading "C-h m" I found command to show it back by:

A u

but it show all groups (killed, etc)

So I read this file lisp/gnus/gnus-group.el and make such solution:

(eval-after-load 'gnus-group
'(progn
(define-key gnus-group-mode-map (kbd "l")
(lambda nil (interactive) (gnus-group-list-groups gnus-level-subscribed t)))
))

Default key binding "l" make same but invoke:

(gnus-group-list-groups gnus-level-subscribed nil)

--
Best regards!

[Oleksandr Gavenko]

I forget complete my message...

Having such switch is sweet but I want to make

(gnus-level-subscribed t)

settings permanent for *Groups* buffer... This internal variable

gnus-group-list-mode

used to store such settings bat if I set it manually they are overridden by
GNUS...

Please help!

--
Best regards!

[Adam Sjøgren]

On Tue, 14 Aug 2012 12:17:33 +0300, Oleksandr wrote:

> But GNUS hide groups from *Group* buffer when there no unread messages...

Does L do what you want?

,----
| L runs the command gnus-group-list-all-groups, which is an interactive
| compiled Lisp function in `gnus-group.el'.
|
| It is bound to L, A u, <menu-bar> <Groups> <Listing> <List
| (un)subscribed groups>.
|
| (gnus-group-list-all-groups &optional ARG)
|
| List all newsgroups with level ARG or lower.
| Default is `gnus-level-unsubscribed', which lists all subscribed and most
| unsubscribed groups.
`----

I usually use L and l to toggle between seeing all groups and only the
ones with unread articles.


Best regards,

Adam

--
"You know, if the sun was an oboe, what would you do?" Adam Sj�gren
as...@koldfront.dk

[Eric Abrahamsen]

On Tue, Aug 14 2012, Adam Sjøgren wrote:

> On Tue, 14 Aug 2012 12:17:33 +0300, Oleksandr wrote:
>
>> But GNUS hide groups from *Group* buffer when there no unread messages...
>
> Does L do what you want?
>
> ,----
> | L runs the command gnus-group-list-all-groups, which is an interactive
> | compiled Lisp function in `gnus-group.el'.
> |
> | It is bound to L, A u, <menu-bar> <Groups> <Listing> <List
> | (un)subscribed groups>.
> |
> | (gnus-group-list-all-groups &optional ARG)
> |
> | List all newsgroups with level ARG or lower.
> | Default is `gnus-level-unsubscribed', which lists all subscribed and most
> | unsubscribed groups.
> `----
>
> I usually use L and l to toggle between seeing all groups and only the
> ones with unread articles.
>
>
> Best regards,
>
> Adam

And 'j' for `gnus-group-jump-to-group' will find any group, visible or
not! This is my main method for *Group* buffer navigation, and for your
exact use-case: 'j' to find a group, then 'C-u a' to compose a message
to it.

--
GNU Emacs 24.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.24.11)
of 2012-08-06 on pellet
Ma Gnus v0.6

[Kevin Brubeck Unhammer]

Eric Abrahamsen <er...@ericabrahamsen.net> writes:

> And 'j' for `gnus-group-jump-to-group' will find any group, visible or
> not! This is my main method for *Group* buffer navigation, and for your
> exact use-case: 'j' to find a group, then 'C-u a' to compose a message
> to it.

Is it possible to make that use "ido" type completion?

--
Kevin Brubeck Unhammer

GPG: 0x766AC60C

[Eric Abrahamsen]

On Tue, Aug 14 2012, Kevin Brubeck Unhammer wrote:

> Eric Abrahamsen <er...@ericabrahamsen.net> writes:
>
>> And 'j' for `gnus-group-jump-to-group' will find any group, visible or
>> not! This is my main method for *Group* buffer navigation, and for your
>> exact use-case: 'j' to find a group, then 'C-u a' to compose a message
>> to it.
>
> Is it possible to make that use "ido" type completion?

But of course!

(setq gnus-completing-read-function 'gnus-ido-completing-read)

I have problems with this, largely because nnmairix (for reasons I will
never understand) creates dummy copies of all your groups. So when you
hit 'j' you're suddenly confronted by a sea of nonexistent groups that
get in the way of where you want to go. Someone in this group, I
believe, once provided me with this:

--8<---------------cut here---------------start------------->8---
(defadvice gnus-group-completing-read (before remove-nnmairix-groups activate)
(unless collection
(mapatoms
(lambda (g)
(unless (string-match "\\(nnml\\|archive\\)" (symbol-name g))
(push g collection)))
gnus-active-hashtb)))
--8<---------------cut here---------------end--------------->8---

Unfortunately this also filters out all my nnml+archive groups, even
though it looks like it shouldn't. Probably I could fix it myself
without too much work, but I haven't bothered…

Anyway, hope that helps.

E

[Kevin Brubeck Unhammer]

Eric Abrahamsen <er...@ericabrahamsen.net> writes:

> On Tue, Aug 14 2012, Kevin Brubeck Unhammer wrote:
>
>> Eric Abrahamsen <er...@ericabrahamsen.net> writes:
>>
>>> And 'j' for `gnus-group-jump-to-group' will find any group, visible or
>>> not! This is my main method for *Group* buffer navigation, and for your
>>> exact use-case: 'j' to find a group, then 'C-u a' to compose a message
>>> to it.
>>
>> Is it possible to make that use "ido" type completion?
>
> But of course!
>
> (setq gnus-completing-read-function 'gnus-ido-completing-read)
>
> I have problems with this, largely because nnmairix (for reasons I will
> never understand) creates dummy copies of all your groups. So when you
> hit 'j' you're suddenly confronted by a sea of nonexistent groups that
> get in the way of where you want to go. Someone in this group, I
> believe, once provided me with this:
>

> (defadvice gnus-group-completing-read (before remove-nnmairix-groups activate)
> (unless collection
> (mapatoms
> (lambda (g)
> (unless (string-match "\\(nnml\\|archive\\)" (symbol-name g))
> (push g collection)))
> gnus-active-hashtb)))
>

> Unfortunately this also filters out all my nnml+archive groups, even
> though it looks like it shouldn't. Probably I could fix it myself
> without too much work, but I haven't bothered…
>
> Anyway, hope that helps.

Sure does, thanks :-) I guess I'll be jumping to relatively unique names
till I figure out that nnmairix thing …

[XeCycle]

Oleksandr Gavenko <gave...@gmail.com> writes:

> If I want to post to some group I firstly enter to it and press 'a' in
> *Summary* buffer.

You can C-u a on that group, without entering it.

> Why? Just because I simple don't remember full group names.
> Only some part of names which I look by C-s in *Group* buffer
> until not find desired group...
>

> But GNUS hide groups from *Group* buffer when there no unread messages...
>

> After reading "C-h m" I found command to show it back by:
>
> A u
>
> but it show all groups (killed, etc)
>
> So I read this file lisp/gnus/gnus-group.el and make such solution:
>
> (eval-after-load 'gnus-group
> '(progn
> (define-key gnus-group-mode-map (kbd "l")
> (lambda nil (interactive) (gnus-group-list-groups gnus-level-subscribed t)))
> ))
>
> Default key binding "l" make same but invoke:
>
> (gnus-group-list-groups gnus-level-subscribed nil)

--
Carl Lei (XeCycle)
Department of Physics, Shanghai Jiao Tong University
OpenPGP public key: 7795E591
Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591

[Oleksandr Gavenko]

On 2012-08-14, Eric Abrahamsen wrote:
> And 'j' for `gnus-group-jump-to-group' will find any group, visible or
> not! This is my main method for *Group* buffer navigation, and for your
> exact use-case: 'j' to find a group, then 'C-u a' to compose a message
> to it.
>

Thanks for explaining of your workflow. I try it but seems that I need to use
ido completion or something similar as default completion require entering
many symbols and TAB pressing, for this:

nntp+news.gmane.org-ephemeral:gmane.emacs.gnus.user
nntp+news.gmane.org:gmane.comp.window-managers.fvwm
nntp+news.gmane.org:gmane.emacs.help

TAB : TAB e TAB RET

As I avoid using IDO-mode until have time to learn it dipper I still use such
approach: C-s KEYWORD and C-s C-s ... as many time until find looked group in
*Groups* buffer.

That's why I look (and still look!!) for way to prevent hiding groups with
zero unread articles.

Also thank to any mentioned about "C-u a", today I search for separate
function for this purpose but it was build-in for:

gnus-group-post-news ("a")!!

--
Best regards!

[Oleksandr Gavenko]

On 2012-08-14, Adam Sjøgren wrote:

>> But GNUS hide groups from *Group* buffer when there no unread messages...
>

> Does L do what you want?

In some way yes, but this command (gnus-group-list-all-groups) also shown
unsubscribed and killed groups. But for my purpose it is not a harm.

My redefinition:

(define-key gnus-group-mode-map (kbd "l")
(lambda nil (interactive) (gnus-group-list-groups gnus-level-subscribed t)))

more suitable for my purpose but as I wrote recently about my workflow to find
group for reading or posting:

C-s KEYWORD and C-s C-s ... as many time until find looked group and then
RET in *Groups* buffer.

When some groups hidden due to:

> But GNUS hide groups from *Group* buffer when there no unread messages

I can't post to this groups with my workflow. So I look for way to preserve
all groups in *Groups* buffer discarding read or unread it.

I think that "defadvice" around "gnus-group-list-groups" will give me desired
behaviour. I am not expert of defadvice style of elisp programming but this
code seems work as I want (I use it for half day only...):

(eval-after-load 'gnus-group
'(progn
(defadvice gnus-group-list-groups (before with-read-groups (&optional level unread lowest))
(unless level
(ad-set-arg 0 gnus-level-subscribed))
(ad-set-arg 1 t)
)
(ad-activate 'gnus-group-list-groups)
))

My previous code:

(define-key gnus-group-mode-map (kbd "l")
(lambda nil (interactive) (gnus-group-list-groups gnus-level-subscribed t)))

no longer necessary.

--
Best regards!

[Andy Moreton]

On Fri 24 Aug 2012, Oleksandr Gavenko wrote:

> On 2012-08-14, Eric Abrahamsen wrote:
>> And 'j' for `gnus-group-jump-to-group' will find any group, visible or
>> not! This is my main method for *Group* buffer navigation, and for your
>> exact use-case: 'j' to find a group, then 'C-u a' to compose a message
>> to it.
>>
> Thanks for explaining of your workflow. I try it but seems that I need to use
> ido completion or something similar as default completion require entering
> many symbols and TAB pressing, for this:
>
> nntp+news.gmane.org-ephemeral:gmane.emacs.gnus.user
> nntp+news.gmane.org:gmane.comp.window-managers.fvwm
> nntp+news.gmane.org:gmane.emacs.help
>
> TAB : TAB e TAB RET
>
> As I avoid using IDO-mode until have time to learn it dipper I still use such
> approach: C-s KEYWORD and C-s C-s ... as many time until find looked group in
> *Groups* buffer.
>
> That's why I look (and still look!!) for way to prevent hiding groups with
> zero unread articles.

Try this:

(setq gnus-permanently-visible-groups ".*")

and if you use topics:

(setq gnus-topic-display-empty-topics t)


HTH

AndyM

[Oleksandr Gavenko]

On 2012-08-28, Andy Moreton wrote:

>> That's why I look (and still look!!) for way to prevent hiding groups with
>> zero unread articles.
>
> Try this:
>
> (setq gnus-permanently-visible-groups ".*")
>
> and if you use topics:
>
> (setq gnus-topic-display-empty-topics t)
>

Last close my issue! Thanks for help. My previous code to defadvice
'gnus-group-list-groups' no longer needed.

--
Best regards!

[Randal L. Schwartz]

Is there a workaround for "Hiding the thread moved us backwards,
aborting!" bug in GNUS v5.13, or do I have to wait for an upgrade now?

Driving me nuts.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

[Lars Ingebrigtsen]

mer...@stonehenge.com (Randal L. Schwartz) writes:

> Is there a workaround for "Hiding the thread moved us backwards,
> aborting!" bug in GNUS v5.13, or do I have to wait for an upgrade now?

I'm pretty sure this has been fixed for Emacs 24.3. At least I remember
working on it, so I assume that it's fixed. :-)

Let's see...

Oops. Nope, this bug still hasn't been fixed. But there's a pretty
good case how to reproduce it now:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11404

--
(domestic pets only, the antidote for overdose, milk.)
http://lars.ingebrigtsen.no * Lars Magne Ingebrigtsen