Re: Canonical list of marks with and without gnus-agent

[Lloyd Zusman <ljz@asfast.com>]

I solved the problem.

I had bound the "@" key to my my-gnus-summmary-mark-as-killed-forward
function, but that binding was overridden to gnus-agent-toggle-mark when
the agent was running.

The reason I didn't catch this is because if I'm in the summary buffer
and type `C-h k' followed by the "@" key, gnus incorrectly tells me that
this key is still bound to my-gnus-summmary-mark-as-killed-forward.  For
some reason, the gnus-agent bindings that are in affect don't show up
when I query a key binding via `C-h k' in the summary buffer.

So once I realized this, all I needed to do was to install a
gnus-agent-summary-mode-hook which binds "@" to my function and "J@" to
gnus-agent-toggle-mark.  Now, everything works the way I want.

This begs the question as to why the gnus-agent keybindings don't show
up when a key is queried in the summary buffer, but now that everything
is working for me again, this is merely an academic question.  :)

Thank you very much for your help.


Lloyd Zusman <ljz@asfast.com> writes:

> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>
>> Lloyd Zusman <ljz@asfast.com> writes:
>>
>>> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>>>
>>>> Lloyd Zusman <ljz@asfast.com> writes:
>>>>
>>>>> [ ... ]
>>>>>
>>>>> Well, it's actually a group of functions, and it's easier if I just
>>>>> explain verbally.
>>>>
>>>> No. It's easier to zip them up and either post or email them.  I can't
>>>> help at all with just a verbal description.  To put it simply, the
>>>> agent isn't supposed to introduce the effect that you are describing.
>>>> That means that either a) there is an obscure bug in the agent or b)
>>>> there is a bug in your functions.  In either case, a verbal
>>>> description will not let me reproduce the error here.
>>>
>>> OK.  Here's the function that marks the article:
>>>
>>>   (defun my-gnus-summary-mark-as-killed-forward ()
>>>     (interactive)
>>>     (save-excursion
>>>       (gnus-summary-mark-article-as-read gnus-killed-mark))
>>>     ;; I forget why I had to do this, but when I wrote this
>>>     ;; deletion system, it didn't work unless I made the
>>>     ;; article processable.  But that was eons ago ...
>>>     (gnus-summary-mark-as-processable 1))
>>
>> Well I'll be, you may just be right.  The
>> gnus-summary-mark-article-as-read method actually performs several
>> actions to remove the article from various lists then calls
>> gnus-request-update-mark to have the backend update the mark.  I'm
>> going to assume (because I can't remember your ever stating this) that
>> when you say you're using the agent, you mean that you're unplugged
>> from the net.  If that is the case, the unplugged backend is nnagent
>> NOT the nnimap that you expect.  This means that the new mark is
>> queued for future synchronization.
>
> Well I'm not running unplugged ... I'm always using a live net
> connection.  I recently started using gnus-agent solely because its
> caching capabilities speed up nnimap.
>
> So ... I think my solution might be to find a way to set a mark on an
> article without going through all that logic in
> gnus-summary-mark-articile-as-read.  In this case, I just want to put a
> mark on an article, and that's it.
>
> So now, I'm going to dig through gnus-sum.el and try to find a
> lower level way to mark an article.
>
>
>> I'm not at all familiar with the actual queuing code.  It is quite
>> possible that calling (gnus-data-find article) as shown below will
>> return some value other than gnus-killed-mark UNTIL synchronization
>> has occurred.
>
> That sounds likely.
>
>
>>> [ ... ]
>>
>> What happens if you use the process mark then call
>> gnus-summary-delete-article without a prefix?  Did it delete the
>> processable articles? Does this always work for you?
>
> I'll check this out a little later and post my results.
>
>
>> If it works, then these may be of use to you.  Pls note that I simply
>> typed these into the message.  These functions have not been compiled,
>> tested, or validated in any way.
>>
>> [ ... etc. ... ]
>
> Thank you very much.  I'll check this function out a little later, as
> well.
>
> Stay tuned ...
>
>
> -- 
>  Lloyd Zusman
>  ljz@asfast.com

-- 
 Lloyd Zusman
 ljz@asfast.com