No Gnus v0.13 is released

No Gnus v0.13 is released

[Lars Ingebrigtsen]

The last release was (kinda) mistagged, so here's a new release with the
proper tags.

This release also includes a fix to the nntp bug that some people were
experiencing, where the new async parallel NNTP fetching code would hang
if you had some (somewhat degenerate) nntp backend definitions.

Get it by saying

  git clone http://git.gnus.org/gnus.git && cd gnus && git checkout n0-13

ChangeLog since last release:

2011-02-22  Lars Magne Ingebrigtsen  <lars@ingebrigtsen.no>

	* gnus.el: No Gnus v0.13 is released.

2011-02-21  Lars Ingebrigtsen  <larsi@gnus.org>

	* nnimap.el (nnimap-open-connection-1): Revert last change, since
	auth-source now accepts numbers.

	* auth-source.el (auth-source-netrc-parse): Accept a number as the port
	spec, too.
	(auth-source-ensure-strings): New function.

	* gnus-art.el (gnus-article-update-date-headers): Doc fix.
	(gnus-article-setup-buffer): Always restart the date timer so that user
	changes to the frequency is respected.

	* nnimap.el (nnimap-open-connection-1): auth-source expects strings as
	port numbers, so make sure it gets that if nnimap-server-port is
	explicit.

2011-02-21  Simon Josefsson  <simon@josefsson.org>

	* nnimap.el (nnimap-inbox): Doc fix.

2011-02-21  Chong Yidong  <cyd@stupidchicken.com>

	* color.el (color-name-to-rgb): Rename from color-rgb->normalize.
	Autoload.  Add optional arg FRAME, and pass it to color-values.
	(color-complement): Caller changed.  Doc fix.
	(color-gradient): Rewrite for better clarity and efficiency.

2011-02-20  Chong Yidong  <cyd@stupidchicken.com>

	* shr-color.el (shr-color->hexadecimal): Use renamed function names
	color-rgb-to-hex, color-name-to-rgb, color-srgb-to-lab, and
	color-lab-to-srgb.

2011-02-20  Drew Adams  <drew.adams@oracle.com>

	* color.el: First part of merge from hexrgb.el.
	(color-rgb-to-hex): Rename from color-rgb->hex.
	(color-rgb-to-hsv): Rename from color-rgb->hsv.  Force hue and
	saturation to zero if the value is too small.
	(color-rgb-to-hsl): Rename from color-rgb->hsl.
	(color-srgb-to-xyz): Rename from color-srgb->xyz.  Doc fix.
	(color-xyz-to-srgb): Rename from color-xyz->srgb.  Doc fix.
	(color-xyz-to-lab): Rename from color-xyz->lab.  Doc fix.
	(color-lab-to-xyz): Rename from color-lab->xyz.  Doc fix.
	(color-lab-to-srgb): Rename from color-lab->srgb.  Doc fix.
	(color-cie-de2000): Doc fix.

2011-02-21  Lars Ingebrigtsen  <larsi@gnus.org>

	* nntp.el (nntp-finish-retrieve-group-infos): Add a kludge to use the
	given method as in the group name if we're using an extended method.
	(nntp-finish-retrieve-group-infos): Wait for the end of the LIST ACTIVE
	command, if we're using that, instead of waiting for the beginning.

	* gnus-start.el (gnus-get-unread-articles): Extend the methods so that
	we're sure to get unique server names, and we don't output two async
	commands in the same buffer.  This fixes an NNTP hang for some users.



-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: No Gnus v0.13 is released

[Lars Ingebrigtsen]

Oh, gitweb is pretty cool.  It actually makes a release snapshot zip
file when I tag something:

http://git.gnus.org/cgit/gnus.git/tag/?id=n0-13

So I'll include that link in the announcement mails, too, for people who
just want to download the announced version.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: No Gnus v0.13 is released

[Ted Zlatanov]

On Mon, 21 Feb 2011 16:33:24 -0800 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Oh, gitweb is pretty cool.  It actually makes a release snapshot zip
LI> file when I tag something:

LI> http://git.gnus.org/cgit/gnus.git/tag/?id=n0-13

LI> So I'll include that link in the announcement mails, too, for people who
LI> just want to download the announced version.

s/gitweb/cgit/

Although gitweb has very comparable functionality :)

Ted

Re: No Gnus v0.13 is released

[Harry Putnam]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> The last release was (kinda) mistagged, so here's a new release with the
> proper tags.
>
> This release also includes a fix to the nntp bug that some people were
> experiencing, where the new async parallel NNTP fetching code would hang
> if you had some (somewhat degenerate) nntp backend definitions.
>
> Get it by saying
>
>   git clone http://git.gnus.org/gnus.git && cd gnus && git checkout n0-13

That doesn't appear to work here, maybe I've done something wrong?

Using the exact posted command:

,----
| You are in 'detached HEAD' state. You can look around, make experimental
| changes and commit them, and you can discard any commits you make in this
| state without impacting any branches by performing another checkout.
| 
| If you want to create a new branch to retain commits you create, you may
| do so (now or later) by using -b with the checkout command again. Example:
| 
|   git checkout -b new_branch_name
| 
| HEAD is now at f68a008... No Gnus v0.13 is released
`----

Re: No Gnus v0.13 is released

[Lars Ingebrigtsen]

Harry Putnam <reader@newsguy.com> writes:

> That doesn't appear to work here, maybe I've done something wrong?

[...]

> | HEAD is now at f68a008... No Gnus v0.13 is released

I think this means that it worked.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: No Gnus v0.13 is released

[Harry Putnam]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Harry Putnam <reader@newsguy.com> writes:
>
>> That doesn't appear to work here, maybe I've done something wrong?
>
> [...]
>
>> | HEAD is now at f68a008... No Gnus v0.13 is released
>
> I think this means that it worked.

Egad... after all this time the `No' can still throw my pea brain

Re: No Gnus v0.13 is released

[Raphael Kubo da Costa]

Harry Putnam <reader@newsguy.com> writes:

> That doesn't appear to work here, maybe I've done something wrong?
>
> Using the exact posted command:
>
> ,----
> | You are in 'detached HEAD' state. You can look around, make experimental
> | changes and commit them, and you can discard any commits you make in this
> | state without impacting any branches by performing another checkout.
> | 
> | If you want to create a new branch to retain commits you create, you may
> | do so (now or later) by using -b with the checkout command again. Example:
> | 
> |   git checkout -b new_branch_name
> | 
> | HEAD is now at f68a008... No Gnus v0.13 is released
> `----

Contrary to what's usual with git, this message seems to be quite clear
;)

In this case, 'git checkout n0-13' has checked out the contents of the
n0-13 tag. However, you have not created a branch that is really
tracking this tag.

`git checkout -b foo n0-13' would create a branch called `foo' based on
the contents of the n0-13 tag. Perhaps the documentation should be
updated?

Re: No Gnus v0.13 is released

[Jeremy Hankins]

I haven't been following the (bleeding?) edge, so this is a big jump for
me.  I apologize if I haven't rtfm'd adequately, but after the switch
the message read status seems to be stored locally rather than on the
IMAP server, or something.  I've got multiple machines running gnus
which all connect to the same IMAP server, but they're all suddenly
showing tons of unread messages, which I have read.  My other imap
client (an iphone) continues to show those messages as read.  I'll look
into this some more when I get a chance, but in case someone goes "Aha!"
I thought I'd mention it here.

Other (minor) issues I've run into during the switch:

 - I had to replace gnus-user-date-format-alist with
   gnus-summary-user-date-format-alist
 - the %U format in gnus-group-line-format doesn't seem to be working --
   I haven't done a lot of troubleshooting but it looks like it's
   returning a number instead of a string.  For now I've done the
   quick-and-dirty thing of using a user-format-function.
 - Gnus failed to start for me until I disabled diminish for
   gnus-agent-mode.  Not a gnus problem, obviously, but it took me a
   while to realize what was going on.

On the plus side: Wow, blazing fast updates!  With multiple imap sources
and nntp I suspect that the asynchronous connection helps a lot, but the
improvement is dramatic whatever the source.  And the improved auth
(storing auth info encrypted) is nice as well.  Thanks!

-- 
Jeremy Hankins <nowan@nowan.org>

Re: No Gnus v0.13 is released

[Steinar Bang]

>>>>> Jeremy Hankins <nowan@nowan.org>:

> I haven't been following the (bleeding?) edge, so this is a big jump
> for me.  I apologize if I haven't rtfm'd adequately, but after the
> switch the message read status seems to be stored locally rather than
> on the IMAP server, or something.  I've got multiple machines running
> gnus which all connect to the same IMAP server, but they're all
> suddenly showing tons of unread messages, which I have read.

Try doing M-g on the nnimap group from the different gnusen and save the
.newsrc.eld files afterwards.  See if that helps them "get in sync".

Re: No Gnus v0.13 is released

[Jeremy Hankins]

Steinar Bang <sb@dod.no> writes:
>>>>>> Jeremy Hankins <nowan@nowan.org>:
>
>> I haven't been following the (bleeding?) edge, so this is a big jump
>> for me.  I apologize if I haven't rtfm'd adequately, but after the
>> switch the message read status seems to be stored locally rather than
>> on the IMAP server, or something.  I've got multiple machines running
>> gnus which all connect to the same IMAP server, but they're all
>> suddenly showing tons of unread messages, which I have read.
>
> Try doing M-g on the nnimap group from the different gnusen and save the
> .newsrc.eld files afterwards.  See if that helps them "get in sync".

Thanks, that did the trick.

-- 
Jeremy Hankins <nowan@nowan.org>

Re: No Gnus v0.13 is released

[Steinar Bang]

>>>>> Jeremy Hankins <nowan@nowan.org>:

> Steinar Bang <sb@dod.no> writes:

>> Try doing M-g on the nnimap group from the different gnusen and save
>> the .newsrc.eld files afterwards.  See if that helps them "get in
>> sync".

> Thanks, that did the trick.

Once all of your .newsrc.eld files are in sync, they should continue to
stay in sync, just using the normal `g' to get new articles for all
groups.  At least that was the case for me.

I _think_ this behaviour has something to do with gnus caching the
current state client side to be able to use QRESYNC to get a quicker
response from the IMAP server, when asking for whether it has new
articles.  But I'm not sure.  Lars can say.

Re: No Gnus v0.13 is released

[Lars Ingebrigtsen]

Jeremy Hankins <nowan@nowan.org> writes:

> I haven't been following the (bleeding?) edge, so this is a big jump for
> me.  I apologize if I haven't rtfm'd adequately, but after the switch
> the message read status seems to be stored locally rather than on the
> IMAP server, or something.  I've got multiple machines running gnus
> which all connect to the same IMAP server, but they're all suddenly
> showing tons of unread messages, which I have read.

Hm.  The first time you use the new Gnus, it should do a complete resync
of all the article marks from the IMAP server.

Hm...  ah, I think I now understand why that fails.  It only does the
complete resync in the non-QRESYNC case.  The QRESYNC code has been
added later, and doesn't have the proper logic to avoid doing that the
very first time.

I've now pushed out something I think should fix this.

> Other (minor) issues I've run into during the switch:
>
>  - I had to replace gnus-user-date-format-alist with
>    gnus-summary-user-date-format-alist

Oh, it's a user-visible variable?  I've now renamed it back to
gnus-user-date-format-alist.

>  - the %U format in gnus-group-line-format doesn't seem to be working --
>    I haven't done a lot of troubleshooting but it looks like it's
>    returning a number instead of a string.  For now I've done the
>    quick-and-dirty thing of using a user-format-function.

Hm...  it seems to work for me.  What does %U display for you?

>  - Gnus failed to start for me until I disabled diminish for
>    gnus-agent-mode.  Not a gnus problem, obviously, but it took me a
>    while to realize what was going on.

What's diminish?

> On the plus side: Wow, blazing fast updates!  With multiple imap sources
> and nntp I suspect that the asynchronous connection helps a lot, but the
> improvement is dramatic whatever the source.

Great!  Nice to hear that.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen