Leo | 1 Oct 2007 01:01
Face
Picon
Gravatar

Re: Is this patch of gnus/pop3.el reasonable?

On 2007-09-30 23:38 +0100, David Kastrup wrote:
> I am currently cleaning through unchecked changes in my Emacs tree.  I
> found that I have made the following change, presumably in order to
> stop pop3 fetching from hanging in some cases with a possibly patchy
> pop3 server.  Could also be related to coding system translation or
> something.
>
> Now the question is whether this is a bad idea to check into upstream.
> I can't see that it will affect operation where the server is correct,
> and it might avoid hangs where it isn't.
>
> What do you think?

It might have something to do with: <m23ax2cq6j.fsf <at> cam.ac.uk> in
emacs-devel.

--

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

       Use the most powerful email client -- http://gnus.org/
Katsumi Yamaoka | 1 Oct 2007 01:22
X-Face
Favicon
Gravatar

Re: [mail.list.steel.mental <at> gmail.com: chinese group names can not displayed properly in *Complation* buffer]

>>>>> Richard Stallman wrote:

> Handa thinks this has to do with how Gnus saves data in .newsrc.eld.
> Would you please investigate it and DTRT, then ack?

The non-ASCII group names handling of Gnus was much improved in
the Gnus CVS trunk[1], not in the v5-10 branch which is being
synchronized with Emacs CVS.  Why I did it is that some people
(almost Chinese) reported that Gnus doesn't work with such groups
perfectly and I confirmed it.  Because that's a major change, I
don't want to merge it into the v5-10 branch hastily.  So, people
who really need to subscribe to such newsgroups now have to use
the development version of Gnus (a.k.a., No Gnus v0.7)[2].

[1] http://news.gmane.org/group/gmane.emacs.gnus.general/thread=64934/force_load=t
[2] http://gnus.org/distribution.html
    or ftp://ftp.gnus.org/pub/gnus/snapshots/

>>>>> sTeeL wrote:

> (setq gnus-select-method '(nntp "news.newsfan.net"))

I've verified that the most recent No Gnus works with just this
news server.  Please read carefully the new Info section:

(info "(gnus)Non-ASCII Group Names")

Regards,

(Continue reading)

Katsumi Yamaoka | 1 Oct 2007 01:55
X-Face
Favicon
Gravatar

Re: URIs wrapped in angle brackets are not extracted correctly

>>>>> Reiner Steib wrote:

> <http://www.faz.net/s/Rub560251485DC24AF181BBEF83E12CA16E/Doc~E990108D4B
> D2D4C29A2BA6460BE3F10EC~ATpl~Ecommon~Scontent.html>

> I don't see this patch in CVS.  Is there any problem with it?

That does not support wrapped and cited urls like the one above.
But I have a plan to improve it.  It will hopefully work also with
such one:

ky> <http://www.faz.net/s/Rub560251485DC24AF181BBEF83E12CA16E/Doc~E990108D4B
ky> D2D4C29A2BA6460BE3F10EC~ATpl~Ecommon~Scontent.html>

I'm going to do it in the near future (after the next emacs-w3m
release?).

Regards,

Katsumi Yamaoka | 1 Oct 2007 02:29
X-Face
Favicon
Gravatar

Re: Huge memory consumption on accessing large newsgroup

>>>>> Ted Zlatanov wrote:

> On Sat, 29 Sep 2007 22:04:18 +0100 Gaute Strokkenes <gs234 <at> srcf.ucam.org> wrote:

GS> I wonder if it would be possible to make Gnus work solely with
GS> compressed ranges (i.e. lists where dotted pairs are used to represent
GS> runs of consecutive integers)?

GS> Unless there is some deeper reason why this cannot work, I might have a
GS> stab at it (eventually).

> I think this would be a good idea.

> Consider using inversion lists.  They don't require pairs of integers;
> each value represents a flip.  They have other nice properties too,
> though it's been a while since I looked at them so I can't name them.  I
> think Kim Storm posted a sample Lisp implementation of the data
> structure in emacs-devel a while ago; I can dig it up if you're
> interested.

I don't see what you are going to do but it's very nice if we
can read the gnu.emacs.gnus newsgroup in news.motzarella.org[1]
with no extra work.  Please consider abolishing the variable:

`gnus-newsgroup-maximum-articles'

Regards,

[1] http://article.gmane.org/gmane.emacs.gnus.user/9647
    http://news.gmane.org/group/gmane.emacs.gnus.user/thread=9638
(Continue reading)

Richard Stallman | 1 Oct 2007 03:36
Picon
Picon

Re: Gtk+ stock tool bar icons

    >     (a) A consistent icons style within Emacs (like in Emacs 22.1)
    > 
    > For Emacs 22.2, let's not change this.

    Let's not change what?  Let's not change what is already checked in for 22.2 
    or let's not change this so it differs from 22.1?

Let's not change it from Emacs 22.1, at least not by default.

I would also prefer not to install the source changes for stock icons
into Emacs 22.2 unless they are very simple.
The goal for 22.2 is to fix the bugs and release it
soon.
Zhang Wei | 1 Oct 2007 08:32
Picon

Re: Is this patch of gnus/pop3.el reasonable?

David Kastrup <dak <at> gnu.org> writes:

> I am currently cleaning through unchecked changes in my Emacs tree.  I
> found that I have made the following change, presumably in order to
> stop pop3 fetching from hanging in some cases with a possibly patchy
> pop3 server.  Could also be related to coding system translation or
> something.

The current version of pop3.el is quite different from that of xemacs,
it still didn't support UIDL command, which is quite urgent to prevent
gnus from fetching the same message repeatedly while messages are kept
on the server.
Stainless Steel Rat | 1 Oct 2007 02:06

Re: Is this patch of gnus/pop3.el reasonable?

On Sep 30, 2007, at 6:38 PM, David Kastrup wrote:
> Now the question is whether this is a bad idea to check into upstream.
> I can't see that it will affect operation where the server is correct,
> and it might avoid hangs where it isn't.
>
> What do you think?

I think it breaks spec.  POP3 responses are terminated with CRLF (\r 
\n).  That's not an option.  My dim recollection of the POP3 specs  
are that lone CRs or LFs are not prohibited in responses so searching  
for something other than the in-spec terminator could be bad.

Does such a buggy, standards-breaking POP3 server exist?  If so then  
I think that the correct way to address it is to make the terminator  
a variable that can be changed on a per-user basis rather than making  
a global static change that could adversely affect everyone else in  
the world using in-spec POP servers.  Otherwise leave it alone.  It  
does what the POP3 RFCs say it should.
--

-- 
\m/  (--)  \m/
Elias Oltmanns | 1 Oct 2007 09:50
Picon

Serious IMAP problems because Gnus doesn't behave RFC compliant

Hi all,

it would appear that Gnus currently by design cannot possibly comply
with RFC 3501. The problem is that according to RFC 3501 a UID may be
any 32bit unsigned integer, whereas ELisp only supports 28bit signed
integers---on my system anyway.

This has the rather unpleasant consequence that I can't even open one of
my IMAP mailboxes in Gnus since messages appear to have negative UIDs
just because of an integer overflow. So, the question is: What can be
done about it?

Regards,

Elias

Nicolas KOWALSKI | 1 Oct 2007 14:36
Picon

ngnus 0.6, msmtp, sending exits with value 78

Hello,

I am using msmtp to send mail, so I defined in my ~/.gnus the two
variables:

 ;;
 ;; gmail with msmtp
 ;;
 sendmail-program "/usr/bin/msmtp"
 message-sendmail-extra-arguments '("-a gmail")

With Gnus 5.10.8, this works well, but with ngnus 0.6, sending mail
fails with the message "Sending...failed with exit value 78".

What am I doing wrong ?

Thanks,
--

-- 
Nicolas

Nicolas KOWALSKI | 1 Oct 2007 15:25
Picon

Re: ngnus 0.6, msmtp, sending exits with value 78

Nicolas KOWALSKI <niko <at> petole.dyndns.org> writes:

> I am using msmtp to send mail, so I defined in my ~/.gnus the two
> variables:
>
>  ;;
>  ;; gmail with msmtp
>  ;;
>  sendmail-program "/usr/bin/msmtp"
>  message-sendmail-extra-arguments '("-a gmail")
>
>
> With Gnus 5.10.8, this works well, but with ngnus 0.6, sending mail
> fails with the message "Sending...failed with exit value 78".
>
> What am I doing wrong ?

After writing a short shell script wrapper to msmtp, I found that
message-sendmail-extra-arguments variable was wrong (msmtp complained of
a non-existent " gmail" account), so this variable must be set to:

(setq message-sendmail-extra-arguments '("-a" "gmail"))

Not sure why it worked with 5.10.6, but now it works with both.

--

-- 
Nicolas


Gmane