[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Gnus issues
From: |
Reiner Steib |
Subject: |
Re: Gnus issues |
Date: |
Wed, 29 Sep 2004 23:52:55 +0200 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) |
On Mon, Sep 27 2004, Dave Love wrote:
> 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:
<URL:http://thread.gmane.org/gmane.emacs.gnus.general/54148>
<URL:http://thread.gmane.org/gmane.emacs.gnus.general/54091>
Lars did like the suggestion to remove the fall-back entries:
,----<URL:http://article.gmane.org/gmane.emacs.gnus.general/54255>
| 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: address@hidden
| Subject: vm-pop and NTemacs heap
| newsgroups: gnu.emacs.vm.bug
| Date: 1996/12/30
| Message-ID: <address@hidden>
| reply-to: address@hidden (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
| ;; address@hidden ... 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/
Re: Gnus issues,
Reiner Steib <=