From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/58666 Path: main.gmane.org!not-for-mail From: Dave Love Newsgroups: gmane.emacs.pretest.bugs,gmane.emacs.gnus.general Subject: Re: Gnus issues Date: Thu, 30 Sep 2004 23:07:54 +0100 Sender: emacs-pretest-bug-bounces+gebp-emacs-pretest-bug=gmane.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1096582121 1477 80.91.229.6 (30 Sep 2004 22:08:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 30 Sep 2004 22:08:41 +0000 (UTC) Cc: Ding List Original-X-From: emacs-pretest-bug-bounces+gebp-emacs-pretest-bug=gmane.org@gnu.org Fri Oct 01 00:08:23 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CD966-0005Zk-00 for ; Fri, 01 Oct 2004 00:08:22 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CD9CV-0007Bd-NK for gebp-emacs-pretest-bug@gmane.org; Thu, 30 Sep 2004 18:14:59 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CD9CR-0007A0-ET for emacs-pretest-bug@gnu.org; Thu, 30 Sep 2004 18:14:55 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CD9CQ-00079e-Ib for emacs-pretest-bug@gnu.org; Thu, 30 Sep 2004 18:14:55 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CD9CQ-000794-62 for emacs-pretest-bug@gnu.org; Thu, 30 Sep 2004 18:14:54 -0400 Original-Received: from [148.79.80.39] (helo=albion.dl.ac.uk) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CD95f-0007eW-6e for emacs-pretest-bug@gnu.org; Thu, 30 Sep 2004 18:07:55 -0400 Original-Received: from fx by albion.dl.ac.uk with local (Exim 3.35 #1 (Debian)) id 1CD95e-0006ER-00; Thu, 30 Sep 2004 23:07:54 +0100 Original-To: emacs-pretest-bug@gnu.org User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) X-BeenThere: emacs-pretest-bug@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: emacs-pretest-bug.gnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-pretest-bug-bounces+gebp-emacs-pretest-bug=gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.pretest.bugs:3994 gmane.emacs.gnus.general:58666 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:58666 Reiner Steib writes: > Jesper Harder's recent changes fixed some of the issues you reported, > AFAICS. Sorry, I thought I had current source. >> gnus.el needs to require message when compiling (for macro >> `message-y-or-n-p'). > > This part of `gnus-read-group' is used rarely. Wouldn't ... > (autoload 'message-y-or-n-p "message" nil nil 'macro) > ... be sufficient? Well, I'd expect all macros to be compiled out, but I see that message-y-or-n-p calls another message function which will have to be autoloaded, so I guess autoloading the macro is reasonable. > Lars did like the suggestion to remove the fall-back entries: > > ,---- > | The point of the fall-backs is that Gnus should just work. If > | somebody sent you a jpeg, you should be able to view it without > | having to do anything in particular. > `---- My point is that that's likely not the effect it has. Suppose I don't have `display' or `ee' (whatever that is) installed, but do have `xloodimage'; then I lose in Emacs (especially as mailcap doesn't test whether a viewer is actually installed). With another program that doesn't override the system mailcap, viewing the image works on a properly-configured Debian system. Also, the viewers in mailcap.el normally won't work under Windows. The system mailcap is likely to be right, and mailcap.el is likely to be wrong, as it is for me. [Emacs isn't even internally consistent, e.g. gnus-audio.el looks for `play', which isn't in mailcap.el. Lisp that wants to select a program like that should ask mailcap for one (that exists).] By the way, the mailcap list should at least be purged of proprietary programs; I spotted `acroread', but I don't know what everything in the list is. >> pop3.el shouldn't use nnheader-accept-process-output, so it can be >> used outside Gnus. It should probably define its own function as a >> copy of that. > > It would need `nnheader-read-timeout', too. I assumed that would be a pop3- variable, but I don't understand its purpose anyway -- why is it different on Windows? > We are planning to keep the stable Gnus branch (v5-10) and Gnus in > Emacs in sync and make bugfix releases (starting with Gnus 5.10.7) > from that branch. As Gnus 5.10.* should run on Emacs 20.7 and Emacs > 21.[1-3], I think we must keep this. Oh. I thought support for Emacs 20 had been dropped. I didn't realize that branch was being maintained, either. It was dead last time I looked, and I couldn't get help with bugs in it. Should reports go to bugs@gnus or emacs-pretest-bug? > I found nothing but the following (quite old) article on this: > > ,---- > | From: bill@attmail.com > | Subject: vm-pop and NTemacs heap > | newsgroups: gnu.emacs.vm.bug > | Date: 1996/12/30 > | Message-ID: <9612302016.AA22907@lynxhub.ho.att.com> > | reply-to: bill@attmail.com (WJCarpenter) > `---- > > Maybe we should disable the `sleep-for' stuff by default, but keep the > code in case some users need it: I'm sure it should be disabled -- it made downloading a pop mailbox pretty painful for me, and the explanation in that message doesn't make any sense to me. (Thanks for finding that -- I think I'd looked for an explanation without luck.) >> rfc2047.el should autoload `mm-qp-or-base64'. > > I cannot find `mm-qp-or-base64' in `rfc2047.el': rfc2047-encode: ;; For the charsets that don't have a preferred ;; encoding, choose the one that's shorter. (save-restriction (narrow-to-region b e) (if (eq (mm-qp-or-base64) 'base64) 'B 'Q))))