<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.emacs.gnus.general">
    <title>gmane.emacs.gnus.general</title>
    <link>http://blog.gmane.org/gmane.emacs.gnus.general</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.gnus.general/83180"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.gnus.general/83175"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.gnus.general/83173"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.gnus.general/83160"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.gnus.general/83159"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.gnus.general/83158"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.gnus.general/83153"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.gnus.general/83151"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.gnus.general/83144"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.gnus.general/83142"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.gnus.general/83133"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.gnus.general/83128"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.gnus.general/83125"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.gnus.general/83124"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.gnus.general/83120"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.gnus.general/83117"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.gnus.general/83108"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.gnus.general/83102"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.gnus.general/83101"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.gnus.general/83096"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.gnus.general/83180">
    <title>"browse the repository" link: web site vs. Gnus source</title>
    <link>http://comments.gmane.org/gmane.emacs.gnus.general/83180</link>
    <description>&lt;pre&gt;http://gnus.org/resources.html has this bullet under "Development":

* Development takes place in git, and you can browse the repository. 

The "browse the repository" link takes me to
http://git.gnus.org/cgit/gnus-html.git/.  Shouldn't that be
http://git.gnus.org/cgit/gnus.git/ instead?

cheers,
mike


&lt;/pre&gt;</description>
    <dc:creator>Mike Kupfer</dc:creator>
    <dc:date>2013-05-20T00:51:47</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.gnus.general/83175">
    <title>XEmacs builds failing - gnus-spec.el</title>
    <link>http://comments.gmane.org/gmane.emacs.gnus.general/83175</link>
    <description>&lt;pre&gt;  Hi.


It looks like the XEmacs runs on the buildbot:

 * http://www.randomsample.de:4456/waterfall

have been failing since a21954c3 "Prefer UTF-8 when the encoding
shouldn't matter and changes are small".

The 21.5 build fails with:

    Compiling /var/lib/buildbot/slaves/debian/build-xemacs21.5/build/lisp/gnus-spec.el...
    While compiling gnus-parse-complex-format in file /var/lib/buildbot/slaves/debian/build-xemacs21.5/build/lisp/gnus-spec.el:
      !! error (("reference to free variable �"))

while the 21.4 compile times out after 1200 seconds, ending with:

    Generating autoloads for lisp/gnus-spec.el...
    command timed out: 1200 seconds without output, attempting to kill
    process killed by signal 9

The commit looks quite innocent:

 * http://git.gnus.org/cgit/gnus.git/diff/lisp/gnus-spec.el?id=a21954c3

I have tried reproducing the problem with the XEmacs 21.5 I happen to
have installed (XEmacs 21.5  (beta31) "ginger" 10f179710250+), but I
don't seem to be able to.

Any ideas?


  Best re&lt;/pre&gt;</description>
    <dc:creator>Adam Sjøgren</dc:creator>
    <dc:date>2013-05-19T19:23:47</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.gnus.general/83173">
    <title>problem with an imap folder (gmail label) and article counts</title>
    <link>http://comments.gmane.org/gmane.emacs.gnus.general/83173</link>
    <description>&lt;pre&gt;I use nnimap to read mail from gmail.  When I try enter one group, I'm
prompted with the message "How many articles from blah (574 available,
default 200): ".  However, when I hit enter I'm told "No unread news".
If I don't accept the default of 200, but put 574 it will give me a list
of articles, although it's not 574, it's 121, the number Gmail reports
through the web interface.  How can I diagnose this problem?  Moreover,
the message counts reported when I try to enter a group often don't
match the summary buffer or what the Gmail web interface reports.  Is
there a solution to this?

Joseph



&lt;/pre&gt;</description>
    <dc:creator>Joseph Mingrone</dc:creator>
    <dc:date>2013-05-18T16:10:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.gnus.general/83160">
    <title>digest format used by google groups</title>
    <link>http://comments.gmane.org/gmane.emacs.gnus.general/83160</link>
    <description>&lt;pre&gt;Hello

I am subscribed to a mailing list (about pandoc) which uses googlegroups,
however the digest format used by google cannot be opened by gnus the
way other digest format are opened (via C-d).
Are there plans to support this format?

thanks

Uwe Brauer 



&lt;/pre&gt;</description>
    <dc:creator>Uwe Brauer</dc:creator>
    <dc:date>2013-05-16T21:35:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.gnus.general/83159">
    <title>several issues with non ascii characters in group names</title>
    <link>http://comments.gmane.org/gmane.emacs.gnus.general/83159</link>
    <description>&lt;pre&gt;(there was an encoding problem with the previous message, here again
with the right encoding)


Hi,

Sometimes, I use accented characters in group names. There are several
problems with such groups:

1.) No completion on Gcc: line in message buffer

For example, if I type "Gcc: st" and then press the TAB key, I get this
completion buffer:

--8&amp;lt;---------------cut here---------------start-------------&amp;gt;8---
Possible completions are:
steph
st\303\251phane
--8&amp;lt;---------------cut here---------------end---------------&amp;gt;8---

But it should be "steph" and "stéphane".

And there is no completion, when typing "sté" and then TAB.



2.) Several entries in server buffer for the same group

For the group "stéphane" for example, I have these lines in the server
buffer:

U      8: stéphane
U      1: stéphane
U      1: stéphane
U     10: stéphane

Not a big problem, just strange.



3.) Some messages are not displayed in summary buffer

For example in my group "stéphane" there are 10 messages. There are also
10 lines &lt;/pre&gt;</description>
    <dc:creator>Peter Münster</dc:creator>
    <dc:date>2013-05-16T19:24:54</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.gnus.general/83158">
    <title>several issues with non ascii characters in group names</title>
    <link>http://comments.gmane.org/gmane.emacs.gnus.general/83158</link>
    <description>&lt;pre&gt;Hi,

Sometimes, I use accented characters in group names. There are several
problems with such groups:

1.) No completion on Gcc: line in message buffer

For example, if I type "Gcc: st" and then press the TAB key, I get this
completion buffer:

--8&amp;lt;---------------cut here---------------start-------------&amp;gt;8---
Possible completions are:
steph
st©phane
--8&amp;lt;---------------cut here---------------end---------------&amp;gt;8---

But it should be "steph" and "stÃ©phane".

And there is no completion, when typing "stÃ©" and then TAB.



2.) Several entries in server buffer for the same group

For the group "stÃ©phane" for example, I have these lines in the server
buffer:

U      8: stÃ©phane
U      1: stÃ©phane
U      1: stÃ©phane
U     10: stÃ©phane

Not a big problem, just strange.



3.) Some messages are not displayed in summary buffer

For example in my group "stÃ©phane" there are 10 messages. There are also
10 lines in the Mail/stÃ©phane/.overview file, but only 8 are displayed
in the summary buffer&lt;/pre&gt;</description>
    <dc:creator>Peter Münster</dc:creator>
    <dc:date>2013-05-16T19:17:34</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.gnus.general/83153">
    <title>isync plus dovecot?</title>
    <link>http://comments.gmane.org/gmane.emacs.gnus.general/83153</link>
    <description>&lt;pre&gt;I'm finally trying to ditch nnml for mail reading, and move to imap.
Offlineimap plus dovecot seems to be a popular solution (I am offline a
lot), but I also saw a lot of complaints about offlineimap, and the
suggestion of isync/mbsync as a replacement.

Has anyone done that? I realize this isn't quite a gnus question, but
I'm having a bit of trouble wrapping my head around this, and google
isn't helping any.

Specifically, you tell offlineimap to deliver to dovecot with a line
like:

preauthtunnel = /usr/lib/dovecot/imap -o mail_location=maildir:$HOME/Maildir

I can't find the equivalent command for mbsync. I don't know if it's
possible, and worse I don't really understand what's going on well
enough to really figure it out logically.

Is it enough just to have mbsync dump to a Maildir directly, and then
tell gnus to access that maildir via dovecot?

Any pointers very welcome!

Eric



&lt;/pre&gt;</description>
    <dc:creator>Eric Abrahamsen</dc:creator>
    <dc:date>2013-05-16T06:30:53</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.gnus.general/83151">
    <title>delete CC</title>
    <link>http://comments.gmane.org/gmane.emacs.gnus.general/83151</link>
    <description>&lt;pre&gt;Hello

Sometimes I hit gnus-summary-followup instead of gnus-summary-reply and
then I have a unwanted CC field. There seems to be no function which
allows me to delete it, without jumping to the field. I mean something
like

(defun my-eliminate-cc ()
  (interactive)
  (save-excursion
(goto-char (point-min))
   (flush-lines "^cc: \\|^Cc: \\| ^CC:")))

Or do I miss something?

thanks

Uwe Brauer 



&lt;/pre&gt;</description>
    <dc:creator>Uwe Brauer</dc:creator>
    <dc:date>2013-05-10T08:00:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.gnus.general/83144">
    <title>SSL problems on dovecot 2.1.7</title>
    <link>http://comments.gmane.org/gmane.emacs.gnus.general/83144</link>
    <description>&lt;pre&gt;When I upgraded my debian-based imap server from squeeze to wheezy
yesterday, SSL stopped working.

I am using a http://cacert.org signed server sertificate, and I am
reusing the certificates that were used on the 1.x dovecot of debian
squeeze.

My three MUAs that worked against the previous 1.x dovecot with the same
certificate, now fails in various ways.

Any hints and guesses as to how to debug this further will be highly
appreciated.  Even more appreciated will be a pin point of the issue. :-)

Here are the error messages from the MUAs:
 - Emacs24(w/linked-in gnutls)/Ma Gnus 0.8 (Gnus git HEAD) on Windows 7 says
   "imap.mydomain.com certificate could not be verified."
 - Emacs23/Ma Gnus 0.8 (also Gnus git HEAD) on debian testing (with
   Emacs23 gnutls-cli is run in a subprocess), says:
   "Opening connection to imap.mydomain.com via tls...
    Opening TLS connection to `imap.mydomain.com'...
    Opening TLS connection with `gnutls-cli --insecure -p 993 imap.mydomain.com'...done
   Opening TLS connectio&lt;/pre&gt;</description>
    <dc:creator>Steinar Bang</dc:creator>
    <dc:date>2013-05-09T09:53:44</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.gnus.general/83142">
    <title>opening local nnimap server through shell stream fails at startup</title>
    <link>http://comments.gmane.org/gmane.emacs.gnus.general/83142</link>
    <description>&lt;pre&gt;When I first start gnus, the connection to a local IMAP server (dovecot)
via 'shell fails. It appears that 'nnimap-stream' is set to its default
'undecided', which means it first tries to use 'ssl, leading to the
following error:

--8&amp;lt;---------------cut here---------------start-------------&amp;gt;8---
Unable to open server nnimap+dovecot due to: dovecot/993 System error
--8&amp;lt;---------------cut here---------------end---------------&amp;gt;8---

Of course, this doesn't happen when dovecot is listening on
localhost:993/ssl (but it *does* happen on localhost:143/network), but
I'd rather use the tunnel method.

Here is the relevant configuration:

--8&amp;lt;---------------cut here---------------start-------------&amp;gt;8---
(add-to-list
 'gnus-secondary-select-methods '(nnimap "dovecot"
                                         (nnimap-address "localhost")
                                         (nnimap-stream shell)
                                         (nntp-authinfo-file "~/.authinfo.gpg")
                                         (n&lt;/pre&gt;</description>
    <dc:creator>Pedro Silva</dc:creator>
    <dc:date>2013-05-08T11:56:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.gnus.general/83133">
    <title>nnimap unable to open server unknown service 993</title>
    <link>http://comments.gmane.org/gmane.emacs.gnus.general/83133</link>
    <description>&lt;pre&gt;Platform: Windows 7,
           emacs 24.3.1,
           Ma Gnus v0.8 (git HEAD),
           GNU TLS gnutls-3.0.9-w32-bin.zip from  
http://sourceforge.net/projects/ezwinports/files/

Summary: I haven't found a solution for the problem yet.  Any  
assistance/ideas/guesses will be appreciated.

What follows are my experiments and results.

When connecting I get the following messages in the minibuffer:
  Opening nnimap server on privat...
  Opening connection to imap.mydomain.com via tls...
  Unable to open server nnimap+privat due to: Unknown service: 993
  Opening nnimap server on privat...failed:

Connecting to the same IMAP server with Opera on the same computer,  
succeeds (so there should be no firewall issues).

The nnimap server is defined as a secondary select method:
  (setq gnus-secondary-select-methods
        '((nnimap "privat"
           (nnimap-address "imap.mydomain.com")
                 (nnimap-authenticator cram-md5)
                 (nnimap-stream ssl))
          (nntp "news.gmane.org")
 &lt;/pre&gt;</description>
    <dc:creator>Steinar Bang</dc:creator>
    <dc:date>2013-05-07T11:00:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.gnus.general/83128">
    <title>message-send-and-exit</title>
    <link>http://comments.gmane.org/gmane.emacs.gnus.general/83128</link>
    <description>&lt;pre&gt;
Subsequent to a recent git commit:

,----
| commit1d2c4fbb9bdc1078d1727b27139e4df5ba7cb2cb (patch) (side-by-side diff)
| tree17f735797a5312b5366f1ed9bccf3380c179ed26
| parent0fceb665e268e9749e51e72f453b785b1a1ee596 (diff)
|
| message.el (message-bury): Make `buffer' optional; HEAD master
| (message-send-and-exit): Don't pass `buf' so as to hide the buffer (bug#14085) 
`----

I seem to get the error

  message-send-and-exit: Wrong type argument: stringp, nil

every time I send a message.

The message is sent, but subsequently something breaks.

Here is what shows up in the *Backtrace*:

,----
| Debugger entered--Lisp error: (wrong-type-argument stringp nil)
|   message-bury()
|   message-send-and-exit(nil)
|   call-interactively(message-send-and-exit nil nil)
|   command-execute(message-send-and-exit)
`----

Let me know if I should give more info...

best,
-gm


&lt;/pre&gt;</description>
    <dc:creator>George McNinch</dc:creator>
    <dc:date>2013-05-05T21:49:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.gnus.general/83125">
    <title>html email, math formula as pictures are not displayed.</title>
    <link>http://comments.gmane.org/gmane.emacs.gnus.general/83125</link>
    <description>&lt;pre&gt;
Since I cannot see my message on gmane, I resend it:

Hello

I cc this to the orgmode list, since it might be relevant. The function 
org-mime-htmlize allows me to send LaTeX math formula as png images. 

However when I receive mails, generated by thunderbird or gmail, which
provide a similar functionality I can see in thunderbirds the png of the
generated formulas, however in Xemacs, Ma gnus 0.6 I only see things
like 
[+]
instead of 
[+]

Is there anything in my gnus configuration I show change?
BTW (gnus-article-show-images) did not work.

The most relevant setting is 
(setq
 mm-discouraged-alternatives nil
 gnus-buttonized-mime-types '("multipart/alternative" ".*/signed")
mm-text-html-renderer 'w3m
 mm-url-use-external t)


thanks

Uwe Brauer 



&lt;/pre&gt;</description>
    <dc:creator>Uwe Brauer</dc:creator>
    <dc:date>2013-05-06T08:01:00</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.gnus.general/83124">
    <title>commit 1d2c4fbb9bdc1078d1727b27139e4df5ba7cb2cb</title>
    <link>http://comments.gmane.org/gmane.emacs.gnus.general/83124</link>
    <description>&lt;pre&gt;Hi Thierry,

it seems your latest commit broke burying the message buffer after
sending a message for me.  I use

  (setq message-kill-buffer-on-exit t)

and now I get this error after sending messages:

--8&amp;lt;---------------cut here---------------start-------------&amp;gt;8---
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  message-bury()
  message-send-and-exit(nil)
  call-interactively(message-send-and-exit nil nil)
  command-execute(message-send-and-exit)
--8&amp;lt;---------------cut here---------------end---------------&amp;gt;8---

The problem is that `with-current-buffer' doesn't work if the given
buffer is nil?

This simplified definition of `message-bury' works for me:

--8&amp;lt;---------------cut here---------------start-------------&amp;gt;8---
(defun message-bury (&amp;amp;optional buffer)
  "Bury this mail BUFFER."
  (when message-return-action
    (apply (car message-return-action) (cdr message-return-action)))
  (bury-buffer buffer))
--8&amp;lt;---------------cut here---------------end---------------&amp;gt;8---

However, I don't &lt;/pre&gt;</description>
    <dc:creator>Tassilo Horn</dc:creator>
    <dc:date>2013-05-06T07:40:57</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.gnus.general/83120">
    <title>keeping to-header addresses in wide mail replies</title>
    <link>http://comments.gmane.org/gmane.emacs.gnus.general/83120</link>
    <description>&lt;pre&gt;Hi All,

I wonder if there is a possibility to keep addresses in to: and cc:
headers where they are when composing a wide reply to an email. When I
do a wide reply, in the to: header remains only the address of whom I
reply to , all other addresses go to cc:

What I want is that all addresses in to: are kept in to:
Is there an option to get such a behavior ? Maybe I have to play with
message-wide-reply-to-function ?

Thx for suggestions!
Mario



&lt;/pre&gt;</description>
    <dc:creator>Mario Peter</dc:creator>
    <dc:date>2013-05-05T12:17:23</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.gnus.general/83117">
    <title>keeping to-header addresses in wide mail replies</title>
    <link>http://comments.gmane.org/gmane.emacs.gnus.general/83117</link>
    <description>&lt;pre&gt;Hi All,

I wonder if there is a possibility to keep addresses in to: and cc:
headers where they are when composing a wide reply to an email. When I
do a wide reply, in the to: header remains only the address of whom I
reply to , all other addresses go to cc:

What I want is that all addresses in to: are kept in to:
Is there an option to get such a behavior ?

Maybe I have to play with message-wide-reply-to-function ?

Thx for suggestions!
Mario



&lt;/pre&gt;</description>
    <dc:creator>Mario Peter</dc:creator>
    <dc:date>2013-05-05T14:42:44</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.gnus.general/83108">
    <title>Updates to sieve-manage.el</title>
    <link>http://comments.gmane.org/gmane.emacs.gnus.general/83108</link>
    <description>&lt;pre&gt;Hi all,

I tried to get sieve-manage working with my dovecot/pigeonhole server.
It didn't quite work out of the box, so I made a few adjustments to the
code.  The result is in my github-repo at
git://github.com/tarleb/gnus.git (in the "sieve" branch).

Most noticable changes:
 - Added support for starttls
 - Allowing multibyte-process buffers (couldn't get
   string-parsing/encoding working without it)
 - Slightly nicer looking code (IMHO of course)
 - An ugly workaround which I intend to fix by the end of
   next week.

Any feedback on the code or advice on how to get this upstream would be
highly appreciated.

Thanks,

Albert


&lt;/pre&gt;</description>
    <dc:creator>Albert Krewinkel</dc:creator>
    <dc:date>2013-05-04T14:48:28</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.gnus.general/83102">
    <title>How to alter behavior of 'gnus-summary-next-article'</title>
    <link>http://comments.gmane.org/gmane.emacs.gnus.general/83102</link>
    <description>&lt;pre&gt;When opening a group and using gnus-summary-next-article ('N') to find
first unread gnus finds the message but then opens it too. I'd like to
just find the next new message but NOT open it.

Is there an existing command that does that? If not how might I piece
together something that would allow me to do that with a minimal
key press? 



&lt;/pre&gt;</description>
    <dc:creator>Harry Putnam</dc:creator>
    <dc:date>2013-05-04T01:29:00</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.gnus.general/83101">
    <title>Coaching on attachment proceedure</title>
    <link>http://comments.gmane.org/gmane.emacs.gnus.general/83101</link>
    <description>&lt;pre&gt;Running a month or so behind latest gnus. On Emacs-24 

Need some coaching on attaching images.

I know the basic commands and how to attach images 1 by 1, but
wondering if there is a way to attach a bunch of images all at once. 

Maybe attach a directory containing multiple images?

I realize I could do this by zipping or raring etc but wondering if
there is a way with no compression.  

There are occasions when the person on receiving end might be
flummoxed by receiving a zip, rar etc attachment.



&lt;/pre&gt;</description>
    <dc:creator>Harry Putnam</dc:creator>
    <dc:date>2013-05-04T01:22:29</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.gnus.general/83096">
    <title>Ma Gnus v0.7 is released</title>
    <link>http://comments.gmane.org/gmane.emacs.gnus.general/83096</link>
    <description>&lt;pre&gt;Let's celebrate May 1st by doing another Ma Gnus release!  Just one year
since the last one, which also happened to be on May 1st.  Funny
coincidence.

What's new?  Er...  some bugs were fixed...  and the notifications stuff
was added...

And stuff.

Get it by saying

  git clone http://git.gnus.org/gnus.git &amp;amp;&amp;amp; cd gnus &amp;amp;&amp;amp; git checkout m0-7

or download the release from

  http://git.gnus.org/cgit/gnus.git/snapshot/gnus-m0-7.zip

ChangeLog since last release:

2013-05-01  Lars Magne Ingebrigtsen  &amp;lt;lars&amp;lt; at &amp;gt;ingebrigtsen.no&amp;gt;

* gnus.el: Ma Gnus v0.7 is released.

2013-05-01  Katsumi Yamaoka  &amp;lt;yamaoka&amp;lt; at &amp;gt;jpl.org&amp;gt;

* gnus-util.el (gnus-emacs-completing-read): Fix a filter for XEmacs.
(Bug#14304)

2013-04-27  Glenn Morris  &amp;lt;rgm&amp;lt; at &amp;gt;gnu.org&amp;gt;

* gnus.el (gnus-list-debbugs):
Use require rather than autoload.  (Bug#14262)

2013-04-27  Julien Danjou  &amp;lt;julien&amp;lt; at &amp;gt;danjou.info&amp;gt;

* sieve-manage.el (sieve-manage-authenticator-alist): Update the sieve
port to "sieve" now that it has an official IANA port assigned.

2013-04-26  Katsu&lt;/pre&gt;</description>
    <dc:creator>Lars Magne Ingebrigtsen</dc:creator>
    <dc:date>2013-05-01T20:14:58</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.gnus.general/83086">
    <title>gnus-summary-insert-articles and fetching headers</title>
    <link>http://comments.gmane.org/gmane.emacs.gnus.general/83086</link>
    <description>&lt;pre&gt;
In 'gnus-summary-insert-articles, headers for the articles to be
inserted are fetched:

(setq gnus-newsgroup-headers
  (gnus-merge 'list
      gnus-newsgroup-headers
            (gnus-fetch-headers articles)
               'gnus-article-sort-by-number))

But since the force-new argument to 'gnus-fetch-headers is nil these new
headers are discarded for any message-id that is already present in the
dependencies table (even if that header has not previously been
fetched). This seems wrong, and I'm tempted to set the force-new arg to
'gnus-fetch-headers to t.

Here is the problem I encountered with the current calling:

I enter a group that has a thread with some articles ticked and others
not. The ticked article headers are retrieved and, with my threaded
display, lines of pseudo-articles are created for the non-ticked
articles in the thread. The message-ids of these non-ticked articles are
entered into the dependencies table as part of the threading. 

Now if I do '/ o' to include all articles, the headers fo&lt;/pre&gt;</description>
    <dc:creator>Andrew Cohen</dc:creator>
    <dc:date>2013-04-21T19:12:45</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.emacs.gnus.general">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.emacs.gnus.general</link>
  </textinput>
</rdf:RDF>
