From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/58651 Path: main.gmane.org!not-for-mail From: Reiner Steib Newsgroups: gmane.emacs.gnus.general,gmane.emacs.pretest.bugs Subject: Re: Gnus issues Date: Wed, 29 Sep 2004 23:52:55 +0200 Sender: ding-owner@lists.math.uh.edu Message-ID: References: Reply-To: Reiner Steib NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1096497868 12420 80.91.229.6 (29 Sep 2004 22:44:28 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 29 Sep 2004 22:44:28 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org, Ding List Original-X-From: ding-owner+M7189@lists.math.uh.edu Thu Sep 30 00:44:13 2004 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13] ident=mail) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CCnBF-0008VM-00 for ; Thu, 30 Sep 2004 00:44:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu ident=lists) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1CCnAw-0007xx-00; Wed, 29 Sep 2004 17:43:54 -0500 Original-Received: from util2.math.uh.edu ([129.7.128.23]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1CCnAo-0007xr-00 for ding@lists.math.uh.edu; Wed, 29 Sep 2004 17:43:46 -0500 Original-Received: from justine.libertine.org ([66.139.78.221] ident=postfix) by util2.math.uh.edu with esmtp (Exim 4.30) id 1CCnAo-00019U-8e for ding@lists.math.uh.edu; Wed, 29 Sep 2004 17:43:46 -0500 Original-Received: from mail-new.rz.uni-ulm.de (mail-new.rz.uni-ulm.de [134.60.1.1]) by justine.libertine.org (Postfix) with ESMTP id 8E2B03A003F for ; Wed, 29 Sep 2004 17:43:42 -0500 (CDT) Original-Received: from lumberjack.physik.uni-ulm.de (lumberjack.physik.uni-ulm.de [134.60.10.173]) by mail.uni-ulm.de (8.13.1/8.13.1) with ESMTP id i8TMhJLe009033; Thu, 30 Sep 2004 00:43:19 +0200 (MEST) Original-Received: from me (lumberjack.physik.uni-ulm.de [134.60.10.173]) by lumberjack.physik.uni-ulm.de (Postfix) with SMTP id 9B8A418178; Thu, 30 Sep 2004 00:43:17 +0200 (CEST) Original-Received: (nullmailer pid 31071 invoked by uid 170); Wed, 29 Sep 2004 21:52:55 -0000 Mail-Followup-To: Dave Love , emacs-pretest-bug@gnu.org, Ding List Original-To: Dave Love X-Face: mtjf/D:es1T0wHO:&CJ'ZXe"l;3C--rw\z!{`eFwL){|]RpI+4{u25L=5C /0>KuGeTsk<~<&NE-AKV1560e!+RJeyWmSskkrJm?[vUV#66{T_m|Ae<||Ku#Mk5`y&O`n~z2;n8eP J5#2h@2eQgV@E70IY_0WlEx!"&giy{+\%h1LJox$zv@/l%ZmU4^tZA>xQpnkUBVC5.jpg#0'(+2?Rs )NAr:>3<=WxHE$ktbLysDIM5TbmHu*3 Most of these things are shown up by compilation warnings, which it > seems people aren't getting attention. (It seems more sane to bundle > these together rather than making individual reports.) Jesper Harder's recent changes fixed some of the issues you reported, AFAICS. > The use of `caddr' in gnus-diary.el should be replaced (or use CL). > > gnus-picon.el uses `ignore-errors' without CL. Fixed by Jesper's change. > 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? > imap.el uses `assert' incorrectly -- I guess the second arg should be > nil. I will replace "(assert (eq (char-after) ?\)) t" with "(assert (eq (char-after) ?\)) nil". > mailcap.el shouldn't define non-Lisp methods in > `mailcap-custom-mime-data'. They should be picked up from the system > mailcap file, so that Emacs is consistent with other programs. > (That's especially relevant on Debian, where /etc/mailcap reflects the > programs actually installed.) Then it's probably worth customizing > the variable. [I should have sorted this out in the past...] There has been some discussion related to this on the Gnus list some time ago in the thread "Disable mailcap support", see the following references: 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. `---- > mml-smime.el needs to require cl when compiling. > > nnml.el and nnfolder.el call assert and error incorrectly. Fixed by Jesper's change. > 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. > It can assume md5 is available, 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. > and I think its user variables should be customized. Agreed. Any volunteer? > I think the bizarre `(if (> (buffer-size)...' clauses in `pop3-retr' > can safely be removed -- I've run without them for some time. 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: ,---- | (defvar pop3-delay-on-large-messages nil) | [...] | (when pop3-delay-on-large-messages | ;; bill@att.com ... to save wear and tear on the heap | ;; uncommented because the condensed version below is a problem for | ;; some. | (if (> (buffer-size) 20000) (sleep-for 1)) | [...] | (if (> (buffer-size) 500000) (sleep-for 1))) `---- > rfc2047.el should autoload `mm-qp-or-base64'. I cannot find `mm-qp-or-base64' in `rfc2047.el': ,---- | grep -nH -e mm-qp-or-base64 *.el | mm-bodies.el:155: (mm-qp-or-base64)))) | mm-encode.el:177: (mm-qp-or-base64) | mm-encode.el:184:(defun mm-qp-or-base64 () `---- > spam.el calls error incorrectly. Fixed by Jesper's change. > In mml.el, I think the second and third calls of `completing-read' > should have t for the fourth arg (REQUIRE-MATCH) since only the listed > completions are meaningful. I tend to type `a RET' and expect it to > complete to `attachment', but it just makes the mml stuff in the > buffer invalid. [ See my other reply. ] Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/