Re: Gnus: Thread notes?

[Eric Abrahamsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> The "&" might not be showing up simply because the gnorb function
>> doesn't re-draw the Gnus summary buffer. I've found that mildly annoying
>> in the past, I'll try to add that, too.
>
> `gnus-summary-update-article' maybe? (at least, seems this is what
> `gnus-registry--set/remove-mark' is doing)

Oh, weird, apparently when this annoyed me in the past I already added
this code. I don't know why it's not working...

>> > Then I `gnorb-gnus-incoming-do-todo' on the other messages in this
>> > thread that seemed important to add notes about them.  That worked, and
>> > I also got the "&", though I wished these notes where explicitly linked
>> > with the corresponding message ids in the org buffer - can I let Gnorb
>> > do this automatically?  I can C-c v on the note, but that doesn't show
>> > me which note corresponds to which message, and vice versa.
>>
>> This is something I wanted right from the beginning (to annotate
>> individual messages), but have never come up with a good UI for it.
>
>> Any ideas?
>
> At least for the start, it would be enough I think if (1) adding a note
> would insert the message id into the org buffer and (2) C-c v over a
> message id would put the cursor over the according message.  Or
> something like that...keep it simple.

Sounds good, I'll start with that. I'll add actual "gnus:" links to the
log note, that way you can make use of them in the normal way, as well.

>> > When I opened the group again, the relevant messages were not
>> > visible (because they now were "old").  I had to / o in the summary
>> > buffer (btw, is there a way to let A T fetch and show also "old"
>> > messages so that I get the complete thread without / o?), I then
>> > marked the relevant messages "important" ("!") so that they were
>> > shown the next time.
>>
>> Avoiding the need to tick messages was one of the points of Gnorb! But I
>> see what you mean -- active Org projects are not automatically
>> visible...
>>
>> Hmm, ideal behavior would be that all messages associated with TODOs not
>> in a "DONE" state would always be visible. That would be nice!
>
> FWIW, I would even find it acceptable if Gnorb would just silently tick
> the relevant messages.  It's easy enough to untick them again, and maybe
> the need to do that explicitly would integrate well with people's work
> flow.  The idea is that messages you have operated on with Gnorb are all
> important.

I'd be annoyed by that behavior, but I can provide a customization
option that will do it. I still like the idea of the Gnorb-specific
limit function, though.

[...]

>> This is a dumb artifact of how Gnus currently works, and this
>> requirement will go away if we can ever get the feature/gnus-select
>> branch to land. The backend is currently necessary so that nnir uses the
>> correct Gnorb function to retrieve the messages. Have you added a
>> "nngnorb" server to your `gnus-secondary-select-methods'?
>
> Yes.
>
>> I'm not sure why simply entering the server buffer would do anything.
>>
>> Hmm, did you add the nngnorb server via "a" in the server buffer? I've
>>  never tried doing that, probably safer to add it to
>>  `gnus-secondary-select-methods'.
>
> I think I did both.  AFAIR only adding to
> `gnus-secondary-select-methods' did not work, and I didn't get it work
> before adding a server for it.  FWIW, this is what I do:
>
> #+begin_src emacs-lisp
> (add-to-list 'gnus-secondary-select-methods '(nngnorb "my-nngnorb-server"))
> #+end_src

This has been a multi-year headache. Right now I'm checking the value of
`gnus-server-method-cache', and I don't know why your server isn't added
to that. I'll add an explicit check for `gnus-secondary-select-methods',
too.

Thanks,
Eric