From: Simon Josefsson <jas@extundo.com>
Cc: ding@gnus.org
Subject: Re: Need suggestions for changing agent's downloadable mark.
Date: Tue, 20 Jan 2004 12:38:33 +0100 [thread overview]
Message-ID: <ilusmiargsm.fsf@latte.josefsson.org> (raw)
In-Reply-To: <uk73nz8ht.fsf@xpediantsolutions.com> (Kevin Greiner's message of "Mon, 19 Jan 2004 19:58:22 -0600")
Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
> Simon Josefsson <jas@extundo.com> writes:
>
>> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>>
>>> Simon Josefsson <jas@extundo.com> writes:
>>>
>>>> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>>>>
>>>>> Any idea where I could find this functionality? I thought that
>>>>> gnus-update-marks (gnus-sum.el) would be appropriate as it updates the
>>>>> info structure but no luck. The same was true of
>>>>> gnus-gnus-to-quic-newsrc-format (gnus-start.el). I think that your
>>>>> suggestion is reasonable, I just don't know where to start with the
>>>>> implementation.
>>>>
>>>> gnus-adjust-marked-articles? I don't understand why it doesn't
>>>> already work, though.
>>>
>>> Thanks that's it. The behavior of gnus-adjust-marked-articles is
>>> determined by gnus-article-mark-to-type which returns the result of
>>> looking up gnus-article-special-mark-lists.
>>>
>>> gnus-article-special-mark-lists's value is
>>> ((seen range)
>>> (killed range)
>>> (bookmark tuple)
>>> (score tuple))
>>>
>>> So, all I need to do is add (download list) or (download range) to it.
>>
>> If download is a list, it shouldn't be added to
>> gnus-article-special-mark-lists. Only non-list mark list types should
>> be added. See the definition of gnus-article-mark-to-type.
>>
>> (gnus-article-mark-to-type 'downloadable)
>> => list
>
> Hmmm. Are lists unsorted or, at least, not sorted by ascending
> numeric value?
Hm, I'm not sure. The docstring for the gnus-newsgroup-* variables
does not mention anything about sorting, though.
> I think that range is better but someone wrapped ALL of the range
> logic in a cond block that is only true for the mark seen. Was that
> correct? Shouldn't we trim killed and bookmark marks as they go outside
> of the active range?
I'm not sure. Maybe add another cond case?
next prev parent reply other threads:[~2004-01-20 11:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-18 5:36 Kevin Greiner
2004-01-18 17:13 ` Simon Josefsson
2004-01-19 3:33 ` Kevin Greiner
2004-01-19 6:15 ` Simon Josefsson
2004-01-19 12:50 ` Kevin Greiner
2004-01-19 14:49 ` Simon Josefsson
2004-01-20 1:58 ` Kevin Greiner
2004-01-20 11:38 ` Simon Josefsson [this message]
2004-01-19 11:46 ` Harry Putnam
2004-01-18 18:06 ` Kai Grossjohann
2004-01-19 3:41 ` Kevin Greiner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ilusmiargsm.fsf@latte.josefsson.org \
--to=jas@extundo.com \
--cc=ding@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).