Can't process mark all articles in summary

Can't process mark all articles in summary

[Bob Newell]

Aloha,

I'm on Emacs 26.2/Gnus 5.13. I access gmail through gnus and have done
so for quite a long while.

The following problem occurs: I want to process mark all articles in the
(say) Trash summary buffer (though the issue is not limited to any one
summary). So I try (gnus-uu-mark-buffer) or other
desperate things like (gnus-summary-mark-as-processable 10000) from the
top of the buffer.

But every time only a handful of articles get marked, like the first
four to seven or so.

Of course I can mark them one by one with a little bit of elisp, but it
seems the 'mark all' commands should, well, mark all.

It may be significant that I have no local groups.

Can anyone give me insight into this frustrating issue?

Mahalo for any help,

-- 
Bob Newell
Honolulu, Hawai`i
* Via Gnus/BBDB/Org/Emacs/Linux *

Re: Can't process mark all articles in summary

[Bob Newell]

Brief follow-up.

> The following problem occurs: I want to process mark all articles in the
> (say) Trash summary buffer (though the issue is not limited to any one
> summary). So I try (gnus-uu-mark-buffer) or other
> desperate things like (gnus-summary-mark-as-processable 10000) from the
> top of the buffer.

I found that I can mark all articles if I turn off threading and
regenerate the summary buffer in unthreaded mode.

But who runs in unthreaded mode? And why shouldn't we be able to mark
all articles in threaded mode? I have yet to figure out /why/ this is
the case ... it's getting a bit on the deep side for me!

> Of course I can mark them one by one with a little bit of elisp, but it
> seems the 'mark all' commands should, well, mark all.

Alas, not so, again, unless I turn off threading.

-- 
Bob Newell
Honolulu, Hawai`i
* Via Gnus/BBDB/Org/Emacs/Linux *

Re: Can't process mark all articles in summary

[Christian Lynbech]

Strange, it works for me (eg. using M P R .) even with threaded summary.

Can you have added some configfuration/package that interacts with the
function?


--

------------------------+-----------------------------------------------------
Christian Lynbech       | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic@hal.com (Michael A. Petonic)


-----------------------
On Wed, Jul 03 2019, Bob Newell wrote:

Brief follow-up.

> The following problem occurs: I want to process mark all articles in the
> (say) Trash summary buffer (though the issue is not limited to any one
> summary). So I try (gnus-uu-mark-buffer) or other
> desperate things like (gnus-summary-mark-as-processable 10000) from the
> top of the buffer.

I found that I can mark all articles if I turn off threading and
regenerate the summary buffer in unthreaded mode.

But who runs in unthreaded mode? And why shouldn't we be able to mark
all articles in threaded mode? I have yet to figure out /why/ this is
the case ... it's getting a bit on the deep side for me!

> Of course I can mark them one by one with a little bit of elisp, but it
> seems the 'mark all' commands should, well, mark all.

Alas, not so, again, unless I turn off threading.

-- 
Bob Newell
Honolulu, Hawai`i
* Via Gnus/BBDB/Org/Emacs/Linux *

Re: Can't process mark all articles in summary

[Bob Newell]

> works for me (eg. using M P R .) even with threaded summary.

> Can you have added some configfuration/package that interacts with the
> function?

Not that I am aware of or can point to.

In your own check of this, was it on an IMAP group? As I stated in an
earlier posting, I have my suspicions about that, but no evidence as
yet.

-- 
Bob Newell
Honolulu, Hawai`i

Via Linux/Emacs/Gnus/BBDB.

Re: Can't process mark all articles in summary

[Lars Ingebrigtsen]

Bob Newell <bobnewell@bobnewell.net> writes:

> The following problem occurs: I want to process mark all articles in the
> (say) Trash summary buffer (though the issue is not limited to any one
> summary). So I try (gnus-uu-mark-buffer) or other
> desperate things like (gnus-summary-mark-as-processable 10000) from the
> top of the buffer.
>
> But every time only a handful of articles get marked, like the first
> four to seven or so.

I'm unable to reproduce this in Emacs 27.  Do you have any fun threading
options set, like false roots or something?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Can't process mark all articles in summary

[Bob Newell]

Lars Ingebrigtsen <larsi@gnus.org> writes:


> I'm unable to reproduce this in Emacs 27.  Do you have any fun threading
> options set, like false roots or something?

Certainly no threading options that I've deliberately set on my own.

But I'll do two things here 1) I'll grab Emacs 27 and see if this goes
away and if not 2) I'll purge the database and see if this recurs later
on.

I still have a sneaking suspicion it has to do with gmail, but nothing
to back that up as yet.

-- 
Bob Newell
Honolulu, Hawai`i
* Via Gnus/BBDB/Org/Emacs/Linux *

Re: Can't process mark all articles in summary

[Bob Newell]

> But I'll do two things here 1) I'll grab Emacs 27 and see if this goes
> away and if not 2) I'll purge the database and see if this recurs later
> on.

Tried these both, same problem. I'll further investigate the idea about
the issue possibly being specific to gmail or more generally to IMAP.

-- 
Bob Newell
Honolulu, Hawai`i
* Via Gnus/BBDB/Org/Emacs/Linux *

Re: Can't process mark all articles in summary

[Bob Newell]

Aloha,

Figured it out but the fix doesn't seem to be easy.

Turns out nothing to do with IMAP, everything to do with my use of
gnus-summary-prepare-hook, in which I call a function that compacts the
lines in the summary buffer.

The docs (in gnus-sum.el) call this "A hook called after the summary
buffer has been generated.  If you want to modify the summary buffer,
you can use this hook."

So I did. But the problem is that gnus-newsgroup-data has already been
computed (from within functions called earlier by gnus-summary-prepare),
and that data structure saves buffer locations for members of
threads. Unfortunately modifying the summary lines in my 'hooked'
function invalidates the location of some of those saved buffer locations.

To make a long story (not all that) short, I did a lot of tracing and
found that gnus at times, but not always, positions to the wrong place
in the summary buffer after doing things like setting the process mark
(among other actions). Interestingly, the correct article number is
pushed onto the 'processable' list, but the wrong article might get
visually marked because of the wrong mark location, and sometimes this
just causes gnus to stop marking (if you're doing a series, like trying
to mark the whole buffer).

The solution would be to regenerate gnus-newsgroup-data AFTER calling
the gnus-summary-prepare-hook. But I can't see how to easily do that.

Is this truly a bug? I'd humbly suggest that it is, at least based on
the docstring for gnus-summary-prepare-hook, which invites you to monkey
with the summary buffer.

-- 
Bob Newell
Honolulu, Hawai`i
* Via Gnus/BBDB/Org/Emacs/Linux *